> I would rather implement a self-service e-commerce platform for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks.<p>Sounds like the author is trying to justify building new stuff without being responsible for any of it.<p>Whatever delusions they have about the "non-linear", the big ideas are almost certainly not going to come from an engineer who doesn't have a seat at the table with the people actually running the business.<p>If one did they would hear all kinds of stuff that would not only wreck their self-esteem, but not have any obvious technical solutions. Engineers are not smarter than anyone else. Imagine that.<p>It's not so much about finding the non-linear but about finding what actually matters to the business you work for first. It's almost never going to be more software.
<i>Most engineers will tell you that the transition from a junior engineer to a senior engineer, or the truly transformational work in our careers, does not come from just crushing tickets non-stop for extended periods of time.</i><p>Of course it doesn't. And that's because "the transition" he refers to is an illusion at best, and a lie we tell ourselves at worst. It's all about politics and getting on your boss' good side. Toot your own horn and you'll move up the ladder of made up titles. Congratulations. It's not more complicated than that.<p>Most managers don't look at code, and even when they do, they can't distinguish <i>good work</i> from CRUD boilerplate. Most managers don't know what it is you do, only what you <i>say</i> it is you do.<p>And the reason why we're in this situation in the first place is because our management class is filled with people who just want things to work without issue so they can collect a paycheck off of someone else's labor and provide for their families.<p>Managers don't care about your work, and you are being tricked into caring about your work so that managers don't have to.
To me it seems like the author is saying “An important decision is a nonlinear one, where a nonlinear decision is one that might have a big impacts.”<p>So this whole post boils down to something like: “only debate decisions that might have big impacts.” I don’t really see what’s interesting about that idea.
Love this article, hope it becomes a foundational piece in some tech org cultures, that reward engineers to focus on "better than linear improvements", vs. pedantic debates I've seen teams that strive for improvement grow so used to for the cheap feeling of improvement they provide.<p>nit: (so I don't lose the habit) that flashing gif in the middle causes a more than linear nuisance while I'm trying to read the article, otherwise LGTM!
> “optimizing for the first derivative” played well with this approach<p>That's... still linear?
If the concept of non-linearity is supposed to add anything to this article, arguably this should be at least the second derivative!
I spent the weekend trying to decide if I should bother trying to change a technical decision recently made at work, and this piece was useful because it gave me a new categorization to think through. The phrase from the article that jumped out at me was "eliminate whole swaths of work".<p>I'm coming in to the project at a point where a couple of dev-months have already gone into learning and spinning up [the unsupported infrastructure we will have to maintain that has nothing to do with our actual app], and I'm confident nobody wants to scrap it all - but that sunk cost is nothing compared to maintaining everything for the next x years. There are zero functional challenges or business costs from using [the existing supported infrastructure from another department], and it would immediately eliminate the six highest items on the project list of risks. And it's not that they thought about this and decided not to: as far as I can tell from specs, design docs, etc., it has simply not occurred to anyone on the project.
My key takeaways:<p>>"Only debate the non-linear. If there is a strong case to be made that a proposal will create some non-linear [positive] impact, then it is worth debating at some length. [...] As a concrete example, I would rather implement a self-service e-commerce <i>platform</i> for a company’s merchandising team, rather than make it easier for engineers to service a ticket to build a /products/hat/:id endpoint every 6 weeks."<p>Reminds me of the Joel Spolsky story about one of his employees, Noah Weiss:<p>"Thanks or No Thanks - A young employee came up with an idea that added a million dollars to our bottom line." (Inc. Magazine, Jan 2009)<p><a href="https://www.inc.com/magazine/20090101/how-hard-could-it-be-thanks-or-no-thanks.html" rel="nofollow">https://www.inc.com/magazine/20090101/how-hard-could-it-be-t...</a><p>Apparently Noah debated creating a job board with Joel (Joel was originally against it) -- until he eventually got his way... and added a million dollars to Joel's company's bottom line...<p>Related: "Pick your battles"
I usually don't like this kind of article with too abstract or general advice. But this one's nice: the good old "choose your battles wisely" + useful heuristic.
TL;DR; summary from ChatGPT:<p>The author reflects on their struggle to discern whether a debate is worth having in a work context, leading them to identify the need to find an equilibrium level of conflict, which can increase efficiency and morale of a team. They argue that this level is rooted internally in an individual's confidence level and emphasise the importance of periodic debates, which can outweigh occasional critical discussions. To find this equilibrium, the author advises a personal principle to only debate the non-linear, i.e., issues that can have a non-linear impact on the organisation, as opposed to those that add incremental value.