Perfectionism – one of the biggest productivity killers in the eng industry
Perfectionism hinders productivity in engineering, causing stress and burnout. Engineers advocate for prioritizing progress over perfection, emphasizing that accepting imperfection enhances mental health and efficiency in projects.
Read original article
Perfectionism is identified as a significant productivity hindrance in the engineering sector, leading to stress and burnout. Engineers Gregor Ojstersek and Jordan Cutler share their experiences, emphasizing that striving for perfection often results in unfinished projects and wasted time. Cutler reflects on his early career, where he prioritized perfecting code over delivering value, realizing that focusing on progress would have been more beneficial. He now emphasizes shipping smaller, functional units and seeking early feedback to enhance productivity. Ojstersek recounts his struggles with perfectionism, noting that his desire for flawless outcomes in learning, design, and coding hindered his progress. He learned that aiming for "good enough" is often more effective and less stressful. Both engineers advocate for prioritizing progress over perfection, suggesting that accepting imperfection can lead to better mental health and productivity. They conclude that recognizing the non-existence of perfection can significantly improve efficiency and output in engineering tasks.
40 commentsI think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
Give the engineers clear requirements and let them interact with the stakeholders. Get rid of the intermediaries and knowledge brokers.
"You know, the whole thing about perfectionism — The perfectionism is very dangerous, because of course if your fidelity to perfectionism is too high, you never do anything. Because doing anything results in … It’s actually kind of tragic because it means you sacrifice how gorgeous and perfect it is in your head for what it really is." - David Foster Wallace
Anyone that has built and shipped something has likely struggled with it. You have a great idea. You build it and it's never as great as it was in your head. You need to ship it anyway, but doing so means getting over that perfectionism. Some can. Most can't.
The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
Now that the prevailing school of thought is that shipping crap is OK we have a checks notes Boeing Starliner.
The thing that's killing productivity is the pushing out of half baked garbage.
There's simply no solid foundation to build upon.
OK short game but horrible long game.
On an organizational level, perfectionism is a red herring. Yes, there is such thing as debilitating perfectionism, but 95% of "perfectionists" are really just people who care a lot about doing things properly (providing all the benefits that begets), but who aren't 10x greybeards, so they take longer to do it than a cheap dev would to shit out what looks like the same product at first glance.
(You can say the same thing about "premature optimization", perhaps to a lesser extent.)
Nothing wrong with “perfectionism” but it should be achieved as a team and that requires getting good people around you. Unfortunately, in my experience, that’s where it usually falls apart.
Clueless management continues to think hiring at the bottom of the barrel and “training” them is the right way to go. There’s a reason why they are taking the lowest possible bid…
Half the nation's personal data is breached every week and we're over here talking about how we need more productivity and less perfection.
Last year's CrowdStrike crapware incident made critical infrastructure crash, flights delayed, hospital appointments delayed.
I'd say to the business people to f*ck off and leave the engineering to us, the engineers. Stop trying to squeeze every drop of "productivity" from everything.
It's done when we say so, and it's good enough when we say so. Go sit in some Zoom meetings or something, and leave us to work.
I would also say being able to identify where you should be consistent can be itself a huge productivity enabler.
In this case, how do we know it is an exponential chart at all or there is not discontinuous jumps in value at “perfect”?
We are not even close to having any noticeable perfectionism in the industry.
Over-engineering is not a form of perfectionism, it is a lack of empathy and lack of professionalism.
- Write down your priorities
- Deliver small units of value
- Seek feedback early
Are solid bits of advice. I felt the rest can be skipped.
Blaming people for not being perfect - no.
Software done right from 30+ years ago is still in broad use. There is huge value in that
Doing things right involves prototypes, iterations, and experiments, so high velocity is good. However, if a prototype ships, you often get on trouble.
While perfectionism is not good, I've rarely seen this be an issue except in maybe young engineers. But part of the problem with perfectionism in them is that they don't even know enough to understand the whole picture and the reality is that "perfect" doesn't actually exist. Solution spaces are too complex so recognize global optima are rare.
Instead, what I see far more of is not understanding what "good enough" is. Not paying attention to details. AND dismissing details with some comment about how you shouldn't be a perfectionist. This is a much more nefarious problem because shittiness builds over time. But the damage it does is incredibly costly. The temporal component and the fact that you yourself are often not impacted by your own actions make this much harder to recognize. Worse, people often get rewarded for short term shortcuts that lead to catastrophic failure in the future. But I hope we all know that a little maintenance is far cheaper than repair. It's why insurance companies want you to do a yearly checkup and get your teeth clean. They know its cheaper.[0]
What really matters is a very difficult balancing act. You need to balance your short term progress with your long term progress but humans are bad at long term planning. You need to move fast enough to meet your short term goals and deadlines but you cannot forget what the end goals are. This is hard because the end goals are fuzzy, change, and only come into resolution as you progress. So you should "move fast and break things" BUT you also need to slow down and fix things. This is part of why the software world is ruled by the lovecraftian god of spaghetti and duct tape[1].
I'll give a quick example: You can write sloppy code to get something working, but spending a bit of time to clean it up and add a few comments is always worth the effort. The problem is you might not feel the pain from the lack of cleanup or comments. What's the worst thing that happens? You spend an extra hr because you realize there's a logic flaw when writing up the doc? Or if no problems, 10 minutes to write words? We've all been stuck trying to understand what something does and why (sometimes we wrote that code[2]), especially when onboarding to a new codebase (think about the connection to the 80/20 rule). Which takes more time? Doing cleanup and commenting as you code or the time lost by every person who gets stuck on that line? If you've ever onboarded into a codebase that is well documented I know you know. And you can probably see how the costs are outsources from you, but not necessarily your company. It's the inverse side of what makes software so powerful: scale.
Perfectionism is rarely a problem and is a junior problem that's about not realizing there's no global optima. But (not)-goodenoughism is common and rampant at all levels. If it wasn't, we wouldn't have daily comments on HN about enshitification[3]. But if we were better at understanding the latter I'm sure the former would also be less common. Move fast, but also make sure you slow down. Never forget details, especially when you need to disregard them to move forward.
[0] I have one example at a company where I worked where I was told I was being a perfectionist and then months later our product literally exploded. An engineer wanted to extrapolate data, I said he was extrapolating too far to be reliable, boss overrode because he was more stressed over the timeline.
[1] Duct tape is a terrible tape and you have no reason to own it. Fight me.
[2] At the time of writing only god and I knew what this code does. Now only god knows.
[3] Enshitification is not happening because people are being malicious. It is because "good" exists in unstable equilibria and part of long interacting chains that all have to go right.