Journal Articles

CVu Journal Vol 29, #4 - September 2017 + Journal Editorial
Browse in : All > Journals > CVu > 294 (10)
All > Journal Columns > Editorial (221)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Editorial: The art of laziness

Author: Bob Schmidt

Date: 10 September 2017 16:52:17 +01:00 or Sun, 10 September 2017 16:52:17 +01:00

Summary: 

Body: 

I'm often moved to remark that being lazy, as a programmer, can be a virtue. I see it as a (rather trite, I admit) variation on the equally clichéd adage that it’s better to work smarter than to work harder. The goal of laziness is to avoid the need to work harder at some point in the future, rather than to evade working now. In that respect, the distinction is very much like the difference between tax avoidance and tax evasion, although with less drastic consequences for contravening the laws that apply.

A simple example of avoiding (unnecessary) work would be to automate something that has to be repeated, such as a software deployment script or even a build, if they are tasks with several steps. It’s easy to make mistakes when doing these things manually, partly because they’re generally boring to do. Putting effort in to creating a script that can be run with a simple command-line (or a single click) saves time, effort and possibly embarrassment later. For complex tasks, the effort of automating can be significant, but the payoff is commensurately large, because the more complicated a thing is, the more opportunity there is to get it wrong.

A simple example of evading work would be to copy some code (say from the Internet) that does almost what you need right now, and then to bang it with a hammer until it’s just right. A more subtle version would be to use some freely available third-party library, without paying sufficient attention to how active the code-base is, and without considering the burden of how and when upgrades should be introduced, and the testing that goes with that. You might have to fix any bugs you discover yourself, and even if you do not need to re-publish the fixes you make, there is the added burden of merging changes back to your own version of the code.

Doing something because it’s expedient might not necessarily be beneficial in the long run. There is a fine line between convenience and imprudence. If you want to be lazy, it’s worth making the effort to do it right.

Notes: 

More fields may be available via dynamicdata ..