I'm generally fine with this principle so long as I get to pick all the linting rules.
In my ideal world, `lint --fix` on file save, every time.
Only Debate The Non-Linear
31–39 of 39 posts
Re: Only Debate The Non-Linear
#32To 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.” 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.
Tech writing could do with less "this is technical" signaling and more actual precision. Use ordinary words to express ordinary concepts ("big impact") and technical words for technical concepts ("nonlinear", "exponential"). Don't use technical words to fluff up ordinary ideas.
Sadly, it seems that people absolutely love doing this.
Re: Only Debate The Non-Linear
#33TL;DR; summary from ChatGPT:
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.
Re: Only Debate The Non-Linear
#34I 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".
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.
Re: Only Debate The Non-Linear
#35> 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. Sounds like the author is trying to justify building new stuff without being responsible for any of it. Whatever delusions they have about the "non-linear", the big ideas are almost certainly not going to com…
> 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.
From personal experience sitting with higher management I can assure you that they are one of the dumbest, most ignorant people I have ever met.
I know more about business and their products than they do. Their only qualifications are high self-confidence and social connections. I wouldn't trust them to do even simple manual labor.
Re: Only Debate The Non-Linear
#36I'm generally fine with this principle so long as I get to pick all the linting rules.
In my ideal world, `lint --fix` on file save, every time.
In my experience linter suggested fixes are good enough for suggestion, and it's probably worth setting up a key binding for accepting them in your IDE, but should absolutely never be applied blindly and automatically.
This quality possibly varies from linter to linter, YMMV.
Re: Only Debate The Non-Linear
#37> 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. Sounds like the author is trying to justify building new stuff without being responsible for any of it. Whatever delusions they have about the "non-linear", the big ideas are almost certainly not going to com…
> Engineers are not smarter than anyone else. Imagine that This kind of anti-intellectualism is extremely harmful. In reality engineers generally are smarter than average and that’s a good thing if you like things like safe aviation.
Smarter in the thing they know about, sure. Most people have some area where they're above average. Software engineers just happen to have that area intersect with a marketable and, recently, socially valued skill.
>> "if you like things like safe aviation."
Safety is less about intelligence and more about diligence. Brilliant doctors still balk at checklists even though they save lives. Most engineering disasters happen because someone skipped a safety measure.
Re: Only Debate The Non-Linear
#38Earlier quoted context omitted.
> Engineers are not smarter than anyone else. Imagine that This kind of anti-intellectualism is extremely harmful. In reality engineers generally are smarter than average and that’s a good thing if you like things like safe aviation.
Smarter in the thing they know about, sure. Most people have some area where they're above average. Software engineers just happen to have that area intersect with a marketable and, recently, socially valued skill. >> "if you like things like safe aviation." Safety is less about intelligence and more about diligence. Brilliant doctors still balk at checklists even though they save lives. Most engineering disasters ha…
The useful checklist is itself a product of higher than average intelligence. It’s entirely possible to diligently follow a useless or even harmful process.
Re: Only Debate The Non-Linear
#39Earlier quoted context omitted.
Smarter in the thing they know about, sure. Most people have some area where they're above average. Software engineers just happen to have that area intersect with a marketable and, recently, socially valued skill. >> "if you like things like safe aviation." Safety is less about intelligence and more about diligence. Brilliant doctors still balk at checklists even though they save lives. Most engineering disasters ha…
The useful checklist is itself a product of higher than average intelligence. It’s entirely possible to diligently follow a useless or even harmful process.
The useful checklist is a product of experience. Items come from death and disaster caused by not doing what the item says to do.