In the early years of my career, I always focused on delivering a perfect product. I wanted my code to be maintainable, easily extensible, performant, and generic enough to be reused for undefined use cases.
I thought that was the way to be a great engineer.
I couldn’t be more wrong.
What I learned with more experience is that:
π₯ Poor engineers write dirty code.
π₯ Good engineers write perfect code.
π₯ Great engineers write code that is good enough.
It can sound counterintuitive: why is good enough better than perfect ? π€
The reason is that what matters is to deliver what is required, nothing more and nothing less.
There is no point in wasting time and resources to make something more than what is required. It is more important to deliver something that brings value to the business now and can be improved later if needed. π
I want to be clear that I am not advocating for writing dirty code. I am neither underestimating the value of maintainability nor reusability. Don’t let me even start with the importance of performance.
But all of that comes with a trade-off compared to time and effort.
The goal is to understand where to set the bar for good enough. And it can be very hard, more than spending days making the code perfect.
Great engineers can identify what matters and set the bar for good enough effectively.
Great engineers know that delivering a good enough product is better than not delivering a perfect product. π₯
photo by Kira auf der Heide