Dealing with the perfectionism trap as a developer
jebraat.com
jebraat.com
A few quotes to contextualize the thought (ones that I reference when I try to weasel out of doing something properly):
“An important part of making good things—it’s extremely underrated in current day society—is having a critical eye for the things that you’re making and assessing ‘are these things of an appropriate quality, do these live up to the standard of what I’m trying to create?’ That’s why it’s not fun sometimes. But it’s also what enables it to be a peak experience in the end when you succeed.”
- Jonathan Blow
---
“Doing something quickly is not the same as doing it well.”
- John Hegarty
---
“Any suppression is regression.”
- Kapil Gupta
---
“If you walk the path of mastery, you’re going to have to walk it all alone. There is no one who is going to accompany you because no one has been taught that. No one believes that. That’s not in the water and in the food and in the air. You’re basically going to have to breathe a different sort of oxygen.”
- Kapil Gupta
A bad overall architecture is unmaintainable.
An ugly 30 line pure function that has unit tests and hasn't needed changes in 5 years is just meh. 50 of those ugly pure functions are still not going to break a project. They could be untangled at any time as needed.
50 decent but not great functions are definitely not going to break a project.
So much perfectionism is at the level of functions and variable names. Some makes things worse, when people reinvent nontrivial functionality instead of using widely trusted libraries, like as if work projects are their personal playground of weekend educational stuff.
If gymnastics make the code easier to understand and prove things about, then we should limber up.
The author is going through the management phase of the career where they have other stakeholders to contend with (or their own constraints), so regressing is an appropriate.
https://www.adama-platform.com/2022/07/02/the-path-of-the-mo...
Yes! I spent a year iterating on my prototype for my startup for precisely this reason. The data model kept changing and that had repercussions through every other part of the prototype. Often leading to reworking entire components.
The data model is that the core of everything for my prototype, so it was more than worth the time spent.
> Yes! I spent a year iterating...for precisely this reason
Seems like you're presenting a counter-point while simultaneously agreeing.
It definitely a first for me.
The impulse to get the instant gratification of cracking into those first few lines of code should never supplant thoughtful design, but I've seen things go really wrong in the opposite direction, too. I reckon it's all about doing a good risk analysis, considering the costs of having to rework something down the road, and not letting your fear of getting that wrong stop progress longer than it needs to.
When faced with such constraints, it's really, really important to get this right from the beginning.
Absolutely. Take a look at git. It's basically just a Merkle tree which is an ingenius data structure with a very simple set of entities and invariants. Almost every feature of git can be viewed as merely manipulating this structure. If you rolled your own, you may get a fast mvp, but chances are that your data model will be very inefficient or complex for coming features.
This goes both ways. Git doesn't have eg tracking of empty dirs, as a result of the data model (to my understanding). Saying no when it doesn't fit the model is also an important aspect.
As such, the data model can't be decoupled from almost anything else, including the UI. It's well worth spending some serious time researching and planning that. Or, if you're still not confident, you can always prototype a quick-and-ugly POC which contains your main features – that usually helps inform and build intuition about the problem.
As hard as it is to resist, I would argue that if you other modules to make work, move on and leave making the current module beautiful for later.
That said it's really hard to leave working but ugly code alone
I find a lot of freedom in coding for myself. In other words code that no one else is ever going to see. This goes a long way to silencing my inner critic. If I ever want to open source it, I can make it perfect at that time. This is why I don't keep my code on github. When I write code for myself I can express myself the way I want to, which is not necessarily the "standard way" that someone later might a "code smell"
I 100% understand the "it's really hard to leave working but ugly code alone" sentiment", as I get the same feeling a lot of the time. That is one of the reasons I wrote this article.
I often have to fight myself to move on to do work on other things.
I can't count the times I've looked at ugly code, fired off `git blame`, and found out it was me.
Sometimes I come up back after years, having learnt how to organize certain kinds of programs better, and can instantly see that the problem was much deeper than that. I now think that as a rule of thumb, if it is hard to make a piece of code tidy at a superficial level, there is a deeper underlying issue. If I manage to find a good architecture, I try to keep the bad code as minimal as possible instead of investing more time in a dead end.
Sorry, but no. As a user, this is the bane of “modern” software.
IMO the beautiful thing about software is, that we can push updates and improvements pretty much instantaneously. Whether that is adding features to a working product, or fixing bugs that slipped through during development.
The argument is not against enhancing and improving the software, it’s against delivering a “draft” (as you say) to end users, it’s against constantly changing the design and working of features. Delivering a “draft” (or prototype) is only acceptable for beta users, or in an initial design phase involving the future users in the design process. It is not acceptable for released software intended for productive use.
Users want stability. They want the software to get out of their way as much as possible, to be reliable and unsurprising, to remain working in the familiar way.
If requirements change, then this has to be carefully coordinated with the affected users, in particular if they aren’t the ones defining the requirements, or if the user base is not uniform and the requirements may only change for a portion of them. In any case, requirement changes affecting how users operate existing functionality shouldn’t be a frequent occurrence.
It is, but that directly results in garbage software being released, because „we can fix problems later“. And it also means you can now perfectly balance perfecting your software with providing the resulting support for your pile of garbage. Which I guess is the reason I have to call support every third time im I’m trying to use an EV charging station because their software shit the bed again. </rant>
Architecture-level designs are important to get right as they can constrain your future self's ability to scale or adjust how the product works. However, it's also possible to spend way too long making a very open-ended architecture whose features you never actually use. (It may turn out you "build it to throw away" if you learn even more about the space you're working in as you go along.)
If you're working on a product and don't even know if it's something customers would use or want, I would say erring on velocity is more important than necessarily getting everything "right" in the design or even making the code beautiful. The thing that will most likely "go wrong" for you is that you built a product nobody wanted and not that the code just wasn't perfect enough. Better to get it in front of people sooner so you know if it's worth pursuing. Obviously, making that nuanced trade-off between "high quality" and "good enough" depends on your skill level and being able to recognize where things could blow up in your implementation if you do get it wrong.
Writing code is not done in a vacuum. We don't get to just write the most beautiful, optimal things with endless amounts of time. There are real business constraints and objectives we need to meet, and the trade-offs we make in terms of time spent should take the context into account. Unfortunately, most of are so separated from the real business objectives of the company leaders at the top, making it difficult to make the appropriate trade-offs (or even caring one way or the other). It often simply turns into "My boss wants this done in 2 weeks, but I would like to do it right and that will take at least a month."
Find the balance between thinking of a better way, and the time it takes to coding it.
Personally I've found codebases that could be simplified enormously just by using a different library, which I found just by searching a few minutes before touching it. You and future developers will probably be grateful.