Last week half of civilization came to a grinding halt because of the crappy engineering practices of a single company. I don't know if now is the right time to complain about perfectionism in IT.
I have very rarely run into the situation where I have put too much polishing into a piece of software to the point where its had a material impact on the project. However the opposite where there is pressure to rush and push out something that isn't really ready has been a very common problem to have to manage.<p>I think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
This is just the "engineers are ADHD children and need an adult (manager) to keep them on task" schtick.<p>Give the engineers clear requirements and let them interact with the stakeholders. Get rid of the intermediaries and knowledge brokers.
My favorite quote on perfectionism and one I often think about,<p>"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<p>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.
This feels a little like confusing early career learning with perfectionism. The stories involve their own junior career where they were learning what good code should be and trying to apply it. Later, as they write better code without needing to learn they are shipping higher quality code faster.
That depends. Shipping too much too fast without making the base that can handle it properly results in a ton of tech debt that will bite you in the end one way or another. So there must be some balance about it.<p>The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
Also the reason we can cross rivers without the bridges collapsing, why we have skyscrapers that withstand earthquakes in Japan, and we were able to launch an international space station into orbit.<p>Now that the prevailing school of thought is that shipping crap is OK we have a <i>checks notes</i> Boeing Starliner.
Something to consider is that if you cut quality to the point that your colleagues believe you are pushing a half-baked product, or they have to spend even a small amount of time fixing what they know could have never been a problem in the first place, their morale is going to tank - and the brightest are going to leave first.
I vehemently disagree...<p>The thing that's killing productivity is the pushing out of half baked garbage.<p>There's simply no solid foundation to build upon.<p>OK short game but horrible long game.
On an <i>individual</i> level, if you are prone to perfectionism, take heed of its dangers to your mental health and productivity.<p>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.<p>(You can say the same thing about "premature optimization", perhaps to a lesser extent.)
I’m more of a 75-80% perfect guy at most Fortune 500 companies. That 90-95% perfectionism is very hard to achieve and honestly not worth the effort.<p>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.<p>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…
My experience with software is 80% or more is slop that could have used more perfectionism. Most engineers couldn’t create a perfect piece of software even if they wanted to. Get to the point where you have that ability and then dial it back as needed. Don’t spend your entire life writing slop that users hate but makes your managers look good because they hit some arbitrary shipping KPI.
Jordan says that a high volume of changes early in their career was a waste. Maybe for the team, but I would argue the experience gained from many low impact changes was probably better in the long run. It’s better to overshoot and dial back than be lacking, especially early on in a career.
Is there any cliche in this industry that sets up a strawman faster than "productivity over perfection"?<p>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.
Absolutely guilty of that! Although the article mainly focuses on software that I also assume isn’t critical, sometimes you have to get the work done perfectly, or it’s a major risk or an overall issue for the project success. For example, if you are designing, building, and programming a drone, the margin for error is slim. A single issue that you are not even directly responsible for can jeopardize the whole project, like if a cellular drone control link (C2) is down. Or you are working on an ICS that controls utilities or nuclear plants. So, you have to perfect all scenarios and outcomes, plus all possible testing too.
Don't even want to read this, especially considering software nowadays is not nearly as good or even close to perfection.<p>Last year's CrowdStrike crapware incident made critical infrastructure crash, flights delayed, hospital appointments delayed.<p>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.<p>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.
Article resonates with me a lot. I've worked on countless projects where I put a lot of effort in designing things cleanly and correctly, only to find out afterwards that it wasn't really necessary. In many cases they were R&D projects that might have turned into concrete products but didn't. It's hard to design software systems and architectures in such a way that perfection is added incrementally as needed. But I think it's in the core of being productive.
I think optimal level of perfectionism depends on impact of the decision and how hard it will be to change in the future. I think it's worth to be perfectionist when it comes to architecture, which is hard to change. So you want to make sure you do things right (or extensibly), and consistently. However, in minor things like method names or code structure, it's OK not to be consistent.<p>I would also say being able to identify where you should be consistent can be itself a huge productivity enabler.
Back of the napkin graphs that are not based on any collected data have grown to aggravate me. Although it shows the mental model of the author, it adds an air of empiricism that gives it more authority.<p>In this case, how do we know it is an exponential chart at all or there is not discontinuous jumps in value at “perfect”?
There is only a handful of software products in the whole world that you can sincerely call “almost perfect”.<p>We are not even close to having any noticeable perfectionism in the industry.<p>Over-engineering is not a form of perfectionism, it is a lack of empathy and lack of professionalism.
It's kind of needed, see this problem... <a href="https://news.ycombinator.com/item?id=41095279">https://news.ycombinator.com/item?id=41095279</a>
Strange article. The three things listed near the top:<p>- Write down your priorities<p>- Deliver small units of value<p>- Seek feedback early<p>Are solid bits of advice. I felt the rest can be skipped.
Yeah, no. Most software is cludged together with little design and grows organically. Overall, putting on the time to do it right -- if possible -- parts give dividends.<p>Software done right from 30+ years ago is still in broad use. There is huge value in that<p>Doing things right involves prototypes, iterations, and experiments, so high velocity is good. However, if a prototype ships, you often get on trouble.
This “Jordan Cutler” guy has a nice grift going, makes money writing a newsletter about career advice when according to his resume, he only has five years of programming experience at best: <a href="https://jordancutler.net/assets/images/JordanResume.pdf" rel="nofollow">https://jordancutler.net/assets/images/JordanResume.pdf</a>
I HATE articles like this and I think they are counterproductive.<p>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.<p>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]<p>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].<p>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.<p>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.<p>[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.<p>[1] Duct tape is a terrible tape and you have no reason to own it. Fight me.<p>[2] At the time of writing only god and I knew what this code does. Now only god knows.<p>[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.