not just random

Some lazy browsing on google will lead to the Lazy Programmer’s Guide.

This essay raises some interesting points, but, more than anything, it got me started thinking about lazy programmers.

When I hear the label lazy programmer attached to a program, I typically think of a programmer, who took some (usually bad) shortcuts in his or her development of the code. Maybe it’s a complete hack. Variable names such as i, j, x, u, etc., poor class design, a complete lack of source code comments and so forth and somewhere in between: Lots of bugs, naturally.

This may be okay, if the program is a throwaway program, the programmer is the only one who will be reading the source code and positively will not have to look at it again after the day of its conception.

Most often this is not the case though.

This kind of laziness is then normally A Bad Thing and not really anything to be proud of. In most kind of cases you do not want this kind of lazy programmer in your team. Eventually they get fired and the new hires get to listen to legends (in a bad sense) about those infamous programmers with whom (or whose code) noone got along.

The aforementioned essay aims at the other, better kind of laziness. This other kind of laziness typically involves understanding the ideas of the pragmatic programmers.

The good, lazy programmer understands that it is A Good Thing to spend more time and effort on a programming task. Here are some reasons:

• Other people may have to understand the code. A lazy programmer will not want to spend much (if any) time explaining the code to anyone else.
• The code may have to be extended later. If the code is poorly written, someone needs to spend time to understand it. Then, the quick & dirty design may not lend itself to easy extension. Refactoring or rewriting may be necessary.
• The implemented solution may not be the best solution. An easy, brute force algorithm is often quick to write, but often ends up solving the problem very poorly.
• etc.

Lazy programming thus involves understanding were it makes sense to be lazy. It often does not make sense to be lazy about figuring out the most appropriate algorithm, meaningful documentation or using longer variable or function names to make easier understandable programs.

There are of course areas where it does make a lot of sense to be lazy: Use a powerful IDE instead of a text editor. Automate wherever possible. Develop your code on the fastest computer you can afford. Have your own fridge within swivel distance.

Anyway.

Lazy programmers can be great programmers - if it’s the right kind of lazy.