Lazy Programmer Excuses
“I didn’t have time to code it right.”
“That’s not in scope for this sprint.”
“I didn’t write that code, so it's not my problem.”
Excuses, excuses. At many times as technical lead, I have heard these excuses from programmers trying to skirt around difficult tasks. It can be very frustrating to hear the things you know will lead to poor quality code: code that will be smelly, code that will cause technical debt, or code that will need to be refactored in the future. This frustration was one of the key reasons I wrote the book Lazy Programmers: The Good, the Bad and the Ugly.
Recently on youtube, this same frustration was expressed by the Handmade Hero developer, Casey Muratori. Casey expressed frustration at the many excuses given to him on why the Microsoft terminal was so slow. So, he wrote his own version in a few days that exposed all those excuses as empty and a sad commentary on the acceptance of such poor code by our profession. One of the excuses he heard was “you would have to rewrite ALL the code to fix the poor performance.” As Casey proved, that is just false most of the time. In fact, on the big data project that I support, I often joke that we are in level 0 of optimization which is “Don’t do stupid sh*t”! The result of cleaning up horribly designed code via simple mechanisms like caching often results in an order of magnitude performance improvement.
That brings me back to my motivation for writing a book on Lazy Programming — to fairly examine a controversial issue from all sides. Many programmers, like Larry Wall of Perl fame, view lazy programming as a virtue. On the other side, there are just as many bloggers and YouTubers that vehemently oppose this by focusing on the traditional definition of Laziness as avoiding work. Besides a detailed analysis of the arguments (with examples that demonstrate all the points), the book strives to raise our level of professionalism. But we must go further than that and ask “why should we be professional?” Why are the excuses listed at the start of this article an offense to that professionalism? The answer is that we support our aspirations towards excellence with a purpose. So, what is our purpose in writing code? Here is one reason as quoted from Chapter 4:
“In the end, supporting the mission of our end-users is the most important thing. Crafting code that is useful. Getting the code into the hands of users to better their lives. Code that performs the purpose it was designed for and performs it well. As professionals, we take pride in our performance, our software products, and their role in shaping the future.”
