Should developers adopt habits of their compilers? In the world of modern programming languages, a new paradigm of laziness has emerged. In this essay, we exploit what this means at a slightly higher level and see what implications could be brought forth in terms of programmer’s attitude. Just to give a clarification about what laziness we are referring to, suffice to say that it’s not about programmers being lazy but rather the language itself – So if your language is lazy, what would being a lazy programmer look like?
For those familiar with the C# compiler, words such as “Just-in-time compiler” or “Lazy loading” should ring a bell. I should add that this is not only pertaining to the C# and .Net folks, just an example. Also to be noted, what I’m interested in here is not another torture explanation of how these compilers accomplish those tasks or the design of such features. But rather, what implications, if any, should these features carry to the developer’s mindset. Ok, so that's a bit handful. Allow me to expand a little more.
Perhaps you may be scratching your head by now, wondering where this is going. Am I really suggesting that programmers adopt “Laziness” from their compilers? To your surprise, the short answer is yes. So how would this be productive? You may ask. After all, you are in the business of shipping working solutions to your costumers on time and within budget. Let us exploit these questions below.
Lazy. A lazy programmer implements the bare minimum in the simplest terms possible to get a working solution. Quite often, you find complicated solutions involving a gazillion third party references and complex notions to a business problem that could have been solved using excel spreadsheet for instance. Or, my favorite one, optimizing solutions that command no optimization. Being lazy in this instance, forces the programmer to dig deeper into the problem itself and consider all aspects surrounding the problem at hand before writing a single line of code.
A lazy programmer procrastinates and has no problem throwing away lines of code. This is a good thing. Have you ever met one of those programmers with an attachment to their code to the point of madness? At times it may even seem though as they are willing to go as far as inventing non-existing business problems just to keep their code around. Being able to throw away your lines of code implies that the software is so modularized to the point where new ideas can be realized without affecting the whole system.
So should you adopt laziness as a programmer? Absolutely. I hate to say think before you write, but in a sense, that's the point. Learning to distinguish business or customer’s needs versus programmer’s thirst for new tools and tricks can go a long way in satisfying your clients. Note that by any means, I'm not suggesting you stop expanding your skill set but rather understand the problem at hand before attempting to solve it. More importantly, prefer simpler solutions to complex ones. Take your time!
Top comments (11)
One of the things I will forever remember one of my teachers saying was "Programmers are lazy, we're very good at reducing the amount we have to write".
The context at the time was with functions and modularising code but with the shear amount of frameworks nowadays I think it's more true than ever!
This is fantastic! I agree with the point entirely. We need to stop building heaping piles of unnecessary junk and build simple solutions to solve problems. Of course, some things require more thought, code, testing, etc. But most things most of us working on applications don't.
Nice post! Reminds me of the spirit behind BDD and Lean Startup's MVP. But have to note that laziness has been a programmer virtue for a long time... 😊
threevirtues.com
Three virtues was immediately where my mind went. :)
@loicniragire : In a tech world that dangerously embraces the 'daily grind' mentality, I think this article serves a very valuable purpose. Great post.
Thank you:-)
Haven't got much into BDD but I appreciate the reference!
I agree with the sentiment, but calling this "Lazy" isn't correct. Truly lazy programmers do things like not understanding the requirements first, sloppily copy-pasting code, failing to write any kind of tests, or even failing to test it once themselves. The truly lazy programmer alos make no attempt at generalization, or comparing to existing code.
I agree that it can be misinterpreted to call it "Lazy", but hopefully the idea is clear after reading the post. Thanks for pointing it out!
Excuse my Markdown formatting here, just getting used to it!
I swooped in and made some adjustments for you. If you check out the changes, it should be a bit clearer.
I noticed that, thank you!