Originally published by Robert Beisert at fortcollinsprogram.robert-beisert.com

Particular Brand of Lazy: What Makes Engineers Unique

I’ve alluded previously to a particular brand of laziness that separates a good engineer from the average person. It sounds disparaging at first, but there is an aspect to engineering laziness that is absent from almost every other kind of laziness:

Engineering laziness encourages progress

How can laziness encourage progress? When we think of laziness, we tend to think of slothful laziness, where people tend to be unwilling to do anything that vaguely resembles work. The slothfully lazy stereotype is the fat slob on the couch, Cheetos on one side and soda on the other, binging some television show. And, we all agree, no progress is being made by the sloth.

However, engineers are lazy in a different way: they hate to do work. Yet, at the same time, they love the work that they do and they love the feeling of accomplishment. This encourages engineers to find more and better ways to get things done so that they spend as little of their time working as possible, yet get more done. This breed of laziness encourages engineers to develop better and longer-lasting patterns that apply in more areas.

Scripting: Automating Boring Tasks

There are thousands of little things that everyone has to do in a day. For programmers, these things often include checking in code, cleaning up any whitespace issues, performing line counts, updating records, and many similar tasks. Sure, most of these things take a few simple commands and a few minutes to perform, but the lazy engineer hates to spend his time on such things. Instead, the lazy engineer will develop a simple script which, when executed, will do the task for him.

Time-Management is a vital skill that most people lack. Engineers tend to have an intrinsic understanding that life is a finite resource, and to spend it on inconsequential and boring tasks is a true waste. Scripts eliminate some of the tedium of the day, free up some mental resources that can be employed on other tasks, and give back a fraction of your life.

Library Code: Generic Solutions

The Scripture says, “The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.” (Ecclesiastes 1:9 – great read for philosophical types)

We see the same sort of problems over and over again. Odds are good that we’ll end up opening a bunch of tcp sockets (when doing network-related work), or that we’ll need to produce a number of storage elements, or that we’ll need to retrieve errors and store them in a log of some kind. A great many programmers will simply copy and paste their old solutions (assuming they can find them) and rework them to fit the particular new scenario. There’s nothing particularly wrong with that.

However, the engineer is too lazy to do such a thing more than once or twice. Engineers specialize in pattern recognition, so when we see the same problem we’ve seen before, we tend to rework the original solution in a way that is sufficiently generic to allow for any application. These generic solutions then find their way into our code-bases, which we then use to reproduce the generic solution any time we need.

Templates: Stop working on boilerplate

All code has some amount of boilerplate. The boilerplate can be legal notices, #ifndef wrappers on headers, or documentation standards. It’s a pain to reproduce the boilerplate over and over. Templates for blank files allow us to start with all of the boilerplate built in, which then allows us to focus our time and mental resources on the actual programming.

Another application for templates is to generalize a type of structure or class pattern. Thread-safe functions, for example, rely on some particular patterns to prevent issues of overlap. It makes sense to engineers to generate a generic “class” template which contains all those pattern pieces in a generic form. Then, when creating a new “class” that requires such patterns, all an engineer has to do is transform the generic into the specific, and it’s ready to go.

Journals: Keep records of your accomplishments and failures

Sad fact of industry: people care about how much you get done, and when. Some companies require all engineers to charge their time to particular project codes, while others require them to draw up a list of accomplishments in a given period. Because of the nature of human memory, we just don’t remember most of what goes on in a given day.

Journals, whether electronic or physical, allow us to record things that we remember in the moment, but which will likely get lost in time. In addition to the very real benefit of logging your accomplishments in real time (which allows you to fill your timecards or accomplishment boards quickly), journals are great for recording things that didn’t go as well as you had hoped. We develop patterns from such observations.

This is one thing that very few engineers think to do, but which is tremendously powerful for everyone. I join with basically everyone in the business/self-improvement field in recommending you to get a journal and use it. If you go with a physical journal or a pocket notebook, I’d highly recommend adding a space pen to your everyday carry.

Patterns: Get it done more reliably

Finally, we reach the crux of the matter. Engineers are pattern-identifiers and puzzle-solvers. We hate to repeat our old mistakes, because we usually have to recreate the old solutions to those old mistakes, and all of that wastes time. When we know that something does or does not work, we want that information to carry into our future development.

Patterns are techniques which we have found reduce errors, improve maintenance, speed up development, or fundamentally improve functionality. They’re so important that I have dedicated an entire book (and months worth of posts) to the subject. With the right patterns and an open mind toward their application, your productivity and code quality will skyrocket. And, what’s more, you will expend fewer mental and temporal resources on things which have already been reliably solved.

Lazy enough to appreciate this post? Then you should grab my book to augment the patterns you already use to complement that laziness.