Only Debate The Non-Linear

&gt; 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 &#x2F;products&#x2F;hat&#x2F;: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 &quot;non-linear&quot;, the big ideas are almost certainly not going to come from an engineer who doesn&#x27;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&#x27;s not so much about finding the non-linear but about finding what actually matters to the business you work for first. It&#x27;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&#x27;t. And that&#x27;s because &quot;the transition&quot; he refers to is an illusion at best, and a lie we tell ourselves at worst. It&#x27;s all about politics and getting on your boss&#x27; good side. Toot your own horn and you&#x27;ll move up the ladder of made up titles. Congratulations. It&#x27;s not more complicated than that.<p>Most managers don&#x27;t look at code, and even when they do, they can&#x27;t distinguish <i>good work</i> from CRUD boilerplate. Most managers don&#x27;t know what it is you do, only what you <i>say</i> it is you do.<p>And the reason why we&#x27;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&#x27;s labor and provide for their families.<p>Managers don&#x27;t care about your work, and you are being tricked into caring about your work so that managers don&#x27;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 &quot;better than linear improvements&quot;, vs. pedantic debates I&#x27;ve seen teams that strive for improvement grow so used to for the cheap feeling of improvement they provide.<p>nit: (so I don&#x27;t lose the habit) that flashing gif in the middle causes a more than linear nuisance while I&#x27;m trying to read the article, otherwise LGTM!

&gt; “optimizing for the first derivative” played well with this approach<p>That&#x27;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 &quot;eliminate whole swaths of work&quot;.<p>I&#x27;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&#x27;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&#x27;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>&gt;&quot;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 &#x2F;products&#x2F;hat&#x2F;:id endpoint every 6 weeks.&quot;<p>Reminds me of the Joel Spolsky story about one of his employees, Noah Weiss:<p>&quot;Thanks or No Thanks - A young employee came up with an idea that added a million dollars to our bottom line.&quot; (Inc. Magazine, Jan 2009)<p><a href="https:&#x2F;&#x2F;www.inc.com&#x2F;magazine&#x2F;20090101&#x2F;how-hard-could-it-be-thanks-or-no-thanks.html" rel="nofollow">https:&#x2F;&#x2F;www.inc.com&#x2F;magazine&#x2F;20090101&#x2F;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&#x27;s company&#x27;s bottom line...<p>Related: &quot;Pick your battles&quot;

I usually don&#x27;t like this kind of article with too abstract or general advice. But this one&#x27;s nice: the good old &quot;choose your battles wisely&quot; + useful heuristic.

I&#x27;m generally fine with this principle so long as I get to pick all the linting rules.

That fits audiophile discussions to a tee. :)

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&#x27;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.