If you’re a half-decent programmer, you’ve probably worried about the quality of your code at some point. I say “half-decent” because there was a time when I wasn’t, and back then, I didn’t worry about it at all. You don’t know what you don’t know, right?
Looking back, one thing stands out to me: I was incredibly good at shipping value — and at incredible speeds, too. So it got me thinking: Do we, as developers, sometimes pay too much attention to code quality? What’s the best way to walk that fine line between code perfection and product delivery speed?
In this post, we’ll see how the best code strikes a balance between complexity and value. Because maybe, just maybe, messy code can lead to a great product after all.
Before we go any further, let’s make sure we’re on the same page about what we’re talking about. I like to define messy code as code that leads to a suboptimal developer experience. If “developer experience” is a new term for you, it’s simply the ease with which a developer can hop onto a project, pick up an existing piece of code, understand it, make changes, and maintain it going forward.
That said, if you think about it, the term “code quality” has less to do with the functionality of the code itself and more to do…