Comment by stouset
20 hours ago
The number of times I've heard that phrase used to justify shipping absolute crap utterly dwarfs the times it's been used to prevent over-engineering something that's already in a good state.
In a thirty year career of software engineering, I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software and never releases it. I have, however, worked at multiple companies that have collapsed under the weight of their unmaintainable spaghetti tech stacks.
I was one of those initiators of a rewrite. And I was facing a real problem: the codebase was in C, all C developers except me left, I was going to leave too, and both our HR department and an external consulting firm failed to find a competent C developer to replace me.
So I said: screw performance, we are rewriting this thing into Go, as that's what our existing developers were willing to work with - with the intention of leaving when this would be done.
And the day I finally submitted my resignation letter, a competent C developer was found, and later I heard that the Go rewrite was scrapped.
> I haven't once come across one of these mythical perfectionists that everyone is constantly retelling cautionary tales of, who endlessly rewrites perfectly serviceable software and never releases
Oh, I have. A LOT! In my friend group theres at least 5 of these right now. They work day jobs (that they dislike), they try to build a side hustle but never get it off the ground because they endlessly rewrite perfectly serviceable software and never release, the reason is:
- they believe that running a startup only requires writing a good product
- they avoid releasing because thats "judgement day" and might flop
- they think if they code it "just right" a money Waterfall will open up magically like a lottery ticket win and be instant success
- they believe that because theres the occasional exception to these rules above, it will happen to them too (everyone thinks they are the special exception,) because thats easier than accepting building a successful business takes discipline, hard work, and doing the tasks you dont want to do.
You havent come across them because by definition they never release and they dont share (they are embarrassed it might fail) so theres thousands and thousands of them, grinding away under false assumptions. They enjoy the act of building (which is totally cool!) but think thats all there is to it. Convinced that just one more rewrite is the thing holding them back from success - because they'd rather rewrite than talk to users. Millions of people doing this, millions of dreams that will die, because /just one more rewrite/
Just because you havent seen them, doesnt mean they aren't there
I'm just like that, but minus the expectation of release/money/success. To me, the building and programming itself is the reward, and I have no motivation or desire to release anything I work on--or any belief that it would/should make money for me. To me, the hours spent fine sanding down and polishing my code, always approaching but never achieving perfection, is its own reward.
I would say thats a different thing entirely, an amateur in the original sense of the word
Latin amator, French amateur, means lover.
In this sense, it means somebody who is doing something because he/she loves it, not as his/her profession. It is not a large semantic shift to infer that he/she is not as skilled.
I couldn’t care less about solo developers who never release their hobby projects. The cautionary tales are always about potential coworkers, and as far as I can tell that stereotype simple doesn’t exist in the business world.
I have not just worked with but had code rejected by these people. “Don’t fix that bug, we are going to write an entire new structure that will make it irrelevant”, “don’t upgrade that library, we are going to rewrite our code to not use it”, “don’t improve exception handling, fix all the bugs that throw bad exceptions”. Not at all surprisingly, all of those planned upgrades took at least two years after my attempted improvement was rejected (the library I didn’t upgrade stuck around for six years).
I'm that perfectionist and it is constantly preventing me from shipping. Basically everything I'm working on requires me to cut losses at some point because it would take twice or three times as long if done perfectly and there is no guarantee that it is actually perfect in the end.
I don't really feel it collapsing under the weight of unmaintainable spaghetti tech stacks, I'm mostly thinking that writing the missing features of the tech stack would require months of work and hard thinking that in the end might simply get rejected and now I would be stuck maintaining it myself so nothing has changed other than that there are even more things to maintain.
All of this for the sake of clean architecture that seemingly has no impact on users in the end... Like the users complain about completely different things.