6 ms·
Perfectionism – one of the biggest productivity killers in the eng industry
- PaulKeeble 2y agoI 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. I think we see the results of rushing in all the software around us much more than we see the delays of perfectionism.
- actionfromafar 2y agoWhen you are the one calling the shots yourself, it can be easy to procrastinate by way of polishing. (Depending on the kind of temperament you have.)
- rafaelmn 2y agoDepends on who's calling the shots. Last few years dev market was so crazy management walked on eggshells to avoid pissing off engineers in most places I've worked at. As a result I've seen plenty of situations where abstractions and tech choices lead to delivery delays and business impact - followed by engineers responsible scramming for next position with latest buzzwords added to CV. Thankfully the market correction made this much less of an issue.
- TylerE 2y agoYes, but what if you'd just...finished and started working on something else? I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months.
- lolinder 2y ago> I'll take a 95% solution delivered in 2 weeks over a 99% one delivered in 2 months. This depends a lot on the context. If I deliver the 95% in 2 weeks can I ship an update in 2 months that delivers the 99%, or are we stuck forever at 95% (due to technical limitations or business reality)? If I'll be able to deliver the 99% soon, then sure, let's ship the 95% sooner rather than later. But if for whatever reason I realistically cannot do that, then you have to consider the context. What is left out in the 95%? How soon will it be a problem that we're missing that remaining 4%? Who will notice the missing pieces? Will they be able to work around their absence? Many times you may still come to the conclusion that the 95% is the right move, but sometimes it's better to not offer the two-week plan as an option if the fallout from that missing 4% is going to be high.
- rectang 2y agoThis is exactly the analysis that is missing from the article and any facile, absolutist statement decrying “perfectionism”. Productivity is an optimization problem. There are tradeoffs which have to be managed. Depending on the context (e.g. prototype phase vs mature, widely used software) you manage those tradeoffs differently.
- shrimp_emoji 2y ago> are we stuck forever at 95% (due to technical limitations or business reality)? E.g., the Twitch codebase They can't change it or add new features or fix problems because it's too much of an unholy startup crack-fueled mess. Not even companies who stole the leaked codebase can improve the horrible user experience on their Twitch clones whatsoever.
- ryandrake 2y agoYes, most places I've seen could barely get a minimally functioning product out. There is never even the opportunity to get to the point where an engineer's perfectionism might kick in. I've seen projects that spit out an average of 5 lines of compiler warnings for 1 line of source code, and that's when the code actually could be built successfully. The big open secret of the software industry is how barely everything works. I practice my perfectionism at home, on hobby projects, where I can run lint with every option if I want, and resolve every warning, static analysis issue, style issue, I can profile my code and find/fix slow parts. I can run valgrind on it and find memory leaks. And I never have to release the software! None of these things were common practice in any software job I've ever had. It was always "Get it to barely work and then ship ship ship!"
- Terr_ 2y ago> The big open secret of the software industry is how barely everything works. Maybe it's the pessimism of age, but it feels like that describes all biology, economies, politics, etc...
- arp242 2y agoI've seen many people treat software like some sort of art project, and spend much time refactoring things, rewriting perfectly functioning systems, and generally creating little to nothing of value and generating tons of meaningless churn. While the article doesn't offer specific examples, it's probably talking about this sort of stuff. e.g. "perfecting code, often code that hadn’t been touched in years and didn’t need to be touched". This sounds like a classic "oh, this isn't how I would have written it, so let me just refactor everything here". "Not how I would have written it" does not equal "bad". This isn't making the code better, less bug-free, or "more perfect" in any way. Actually, it often introduces bugs.
- shmerl 2y agoThat 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. The "we'll fix it later" turning into "no one ever fixed it" is way too common of a pitfall.
- GarnetFloride 2y agoYeah, that's a big one. In one case I reproduced a bug that had been plaguing us for a decade but could never seem to reproduce when it happened to a customer. Then the lore came out that the original programmer had slapped it together over a weekend. It worked in the lab, and mostly worked in the field but failed sometimes in weird ways. Then engineering tried fixing it. They failed three times, so they decided to replace that feature. It took two years to replace that one feature and get it to work right. It didn't kill the company, because it was a less used feature, but it reduced trust in the marketplace so growth took a hit that let other take and keep the lead.
- rectang 2y agoClassic problem: management hits workers for “perfectionism”… and then hits them again when things aren’t perfect.
- EatFlamingDeath 2y agoThis or the manager wants it perfect but complains when it takes longer
- rectang 2y agoIndeed. An article on “perfectionism” really needs to grapple with “good, fast, cheap: pick two”.
- Buttons840 2y agoThis article is fluff trying to fill up their blog so they can sell paid subscriptions and have "engagement". They even link to one of their paid blog posts.
- MathMonkeyMan 2y agoI had to opt out of giving an email address before seeing the article, which I stopped reading after a few seconds.
- dgb23 2y agoThe beatings will continue until morale improves.
- ozgrakkurt 2y agoThe bliss of deciding everything and taking no responsibility
- andsoitis 2y agoDon’t let perfect be the enemy of good.
- rileymat2 2y agoThis is complicated because it is almost a truism, but my problem is it often gets trotted out when defending the bad.
- oriolid 2y agoThe enemy of good is not perfect but "good enough".
- aaronarduino 2y agoIn my experience that saying usually is said to mean something that is “good enough” but that’s not the same as quality work.
- gchamonlive 2y agoWhy do we call overzealousness perfectionism? If perfectionism disregards context it is arguably NOT perfect.
- candiddevmike 2y agoThis is just the "engineers are ADHD children and need an adult (manager) to keep them on task" schtick. Give the engineers clear requirements and let them interact with the stakeholders. Get rid of the intermediaries and knowledge brokers.
- AmericanChopper 2y agoEngineers with decent social skills tend to get promoted into roles where they're managing stakeholder relationships.
- lolinder 2y agoAnd said engineers often end up wishing they hadn't. Interacting directly with stakeholders isn't all it's cracked up to be. Maybe I've just had good luck with product managers, but I tend to enjoy my work the most when someone else is filtering the stakeholders' long and constantly changing wishlist for me and turning it into something coherent and actionable.
- vishnugupta 2y agoThat's how it was in the initial days/years. However those days are long gone. Now there are these Product Managers who have absolutely no clue how software is built. Interestingly I'm seeing similar trend in many other fields; my car goes to servicing and there's some dude who just knows jargons interfacing with me, for the minutest of my questions he will "get back to me after consulting the line workers", same with my house construction. I had to get through 4 layers of people to finally get to the person who is actually doing the electrical wiring to clearly explain what is it that I wanted.
- candiddevmike 2y agoHopefully LLMs will replace all of the "I deal with the god damn customers so the engineers don't have to" folks
- SoftTalker 2y ago
- dexwiz 2y agoJordan 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.
- simonw 2y ago"Perfect is the enemy of shipped" is one of my favourite aphorisms.
- jsiepkes 2y agoLast 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.
- lostdog 2y agoAs always, there's a bunch of people who should seek higher perfection, and a bunch who should seek lower. And most people are wrong about which group they're in.
- PartiallyTyped 2y agoI think standards could be higher while perfectionism could be lower. I'd even go as far as to argue that perfectionism is a contraindicator to quality software and high standards. Perfectionism doesn't necessarily mean better implementations, good practices, or even doing the right thing. Chasing and stacking needless abstractions to make things appear clean is an example of such perfectionism that actually harms the industry and erodes standards.
- zelphirkalt 2y agoIn the second paragraph you name what seems to be your definition of perfectionism. I can't say I agree with it, because to me it seems to move away from perfect.
- PartiallyTyped 2y agoWhat I was alluding to, but perhaps should have communicated better, is that perfect within our domain, subjective.
- deleted 2y ago[deleted]
- no_wizard 2y agoIf we had a professional association for software engineers that was nationally recognized one benefit of this would be around standards and practices being set industry wide and having a professional association that advocates on behalf of engineers to have them enforced. Other engineering professions do have precedent shown for this.
- deleted 2y ago[deleted]
- mupuff1234 2y agoPerfectionism or just anxiety?
- dgeiser13 2y agoPeople who complain about perfectionism typically don't provide the proper software requirements.
- thelastparadise 2y agoI vehemently disagree... 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.
- js8 2y agoI 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. I would also say being able to identify where you should be consistent can be itself a huge productivity enabler.
- surfingdino 2y agoIt's kind of needed, see this problem... https://news.ycombinator.com/item?id=41095279 https://news.ycombinator.com/item?id=41095279
- dbg31415 2y agoBad requirements are the biggest productive killer.
- actionfromafar 2y agoIt's complicated. It can become an excuse too: "if only they (waves in the general direction of customer relations) could give us good requirements". Some stuff is just difficult to figure out.
- SoftTalker 2y agoAlso often times the customer does not know what they want, they only know that what they have isn't it.
- fefe23 2y agoAlso 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. Now that the prevailing school of thought is that shipping crap is OK we have a checks notes Boeing Starliner.
- rileymat2 2y agoBack 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. In this case, how do we know it is an exponential chart at all or there is not discontinuous jumps in value at “perfect”?
- rectang 2y agoFor starters, the graph would have been easier to intuit if time had been on the usual horizontal axis. That would better illustrate the “point of diminishing returns”, which is the theme they’re trying to explore. By presenting it in this confusing configuration it seems more profound than it is.
- rileymat2 2y agoYes, I interpreted it as a sum of total value over lifetime; but when you are building it, the software could live for 1 year or 20, in very unpredictable ways.
- grobbyy 2y agoYeah, 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. 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.
- sigotirandolas 2y agoSomething 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.
- Buttons840 2y agoIs there any cliche in this industry that sets up a strawman faster than "productivity over perfection"? 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.
- ath3nd 2y ago"Productivity" means shipping the first 3 features fast, then getting overwhelmed in spaghetti and unreliability, things slow down to a halt, and the features you shipped turn out to be buggy. The desire of money people to sell hack/slash/burn kind of products to customers is so pervasive nowadays, that there is no wonder why we have: - the Boeing travesty (people actually die because of this) - the CrowdStrike debacle (who needs functioning airports and hospital appointments?) - the AT&T hacks And some manager type (who probably did a 1 month business course and is also a certified Scrum master) is gonna tell you to "ship faster, value, value, value". The disdain I have for them has no bounds.
- jackblemming 2y agoMy 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.
- chewbacha 2y agoThis 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.
- tracerbulletx 2y agoCorporate disdain for quality of craft is the death of humanity.
- trentnix 2y agoI’m not sure it’s the death of humanity, but I find myself sharing a similar sentiment.
- xyst 2y agoI’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. 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…
- llmblockchain 2y agoMy favorite quote on perfectionism and one I often think about, "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.
- jiiam 2y agoThanks, I needed to have this thought formalized. I see now why I have a hard disk full of perfectly architured dead projects, and also why the live ones are never going to be perfect
- VoodooJuJu 2y ago[flagged]
- j45 2y agoPursuing excellence by shipping and doing a little beater each time is the antidote to hiding behind perfectionism
- deleted 2y ago[deleted]
- godelski 2y agoI HATE articles like this and I think they are counterproductive. 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.
- lo_zamoyski 2y agoThe tyranny of the nitpicker comes to mind.
- nine_zeros 2y agoSeeking perfection via automated systems - yes Blaming people for not being perfect - no.
- oliep 2y ago[flagged]
- tamimio 2y agoAbsolutely 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.
- scott_w 2y agoStrange article. The three things listed near the top: - Write down your priorities - Deliver small units of value - Seek feedback early Are solid bits of advice. I felt the rest can be skipped.
- slavapestov 2y agoThis “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: https://jordancutler.net/assets/images/JordanResume.pdf https://jordancutler.net/assets/images/JordanResume.pdf
- ath3nd 2y agoDon't even want to read this, especially considering software nowadays is not nearly as good or even close to 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.
- happytoexplain 2y agoOn an individual level, if you are prone to perfectionism, take heed of its dangers to your mental health and productivity. 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.)
- kennu 2y agoArticle 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.
- aristofun 2y agoThere is only a handful of software products in the whole world that you can sincerely call “almost 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.