The rainbow of disgust and joy
One experience common to coding is having to deal with a codebase that could be better designed for the task at hand. It’s very easy to be in that situation and second guess the initial design - “we should have taken more time”, “that was never a good design” etc.
But it’s usually with the benefit of hindsight, sitting on a successful product, that we have that perspective. It’s closer to reality to understand that the code had to get written fairly quickly to get to market ahead of competitors - in the moment, we didn’t know everything we know now. It’s very much as easy to fail by being too slow and “perfect” as it is to fail by being so fast and sloppy that the code melts down.
Failing to navigate this tension between speed and maintainability is one of the primary ways to fail in a software project. Many successful products and companies go through a period of crisis when the early hacks fail to scale, as the team or traffic gets too large. Spotting this and doing refactorings and maintenance early enough is a critical part of every large effort.
So how do you understand whether you are being too slow and neat, or too fast and careful? Enter the “rainbow of disgust”! There is a spectrum of emotions you can have about your code, roughly in some order from bad to good: terror, disgust, discomfort, embarassment, calm, happiness, pride.
The right place to be on that scale is roughly the middle - slightly embarrassed but not afraid, disgusted or terrified. Another way to visualize this is, if you’ve ever had to be in charge of a toddler, say a 3 year old - the sense of them running down a slight incline. Not entirely in control, but also not entirely hazardous - something to be watched and managed but not stopped.
Most projects that are successful have this sense of pragmatic tension between the need to get things done quickly, and the desire to make the code as clean as possible. There are lots of reasons why “too clean” is a mistake - mostly having to do with the fact that you won’t understand the problem as well as you think until you’ve solved some of it. And of course, the right place to be on the rainbow depends on the project - for some kinds of software “very slow and correct” is the right answer.
But more often than not, “slightly embarrassed and moving fast” is the right place to hang out.