DZone Top Article of 2011: Programmers are f***ing lazy
Think about it, biologists do all those experiments … giving a drug to hundreds of mice is can’t be automated. Doctors have to physically inspect their patients, professors have to give the same lectures year after year, architects draw their plans in all perspectives manually and until recently did hatching by hand.
Looking at more run of the mill professions it gets even worse, marketers give the same pitch over and over, hairdressers do practically the same thing day after day, store clerks handle the same groceries for customers in the same manner all the time … people in factories …
You get the picture, the world is full of people doing practically
the same thing day after day, hour after hour, for years on end,
sometimes their whole lives.

Image via Wikipedia
Enter programmers, stage left.
Whenever we do the same thing twice in a row – we try to think of a way to automate the process. Whenever you write code doing the same thing, you start looking for a library. Whenever you start projects on a similar foot, you go look for a boilerplate.

Image by Riebart via Flickr
Programmers’ lives are devoted to eliminating repetivity.
Removing menial tasks from our workflows, making lives easier for everyone. It’s a common joke that a programmer would rather spend a week making a bash script than copy paste the same file twice and be done with it in two minutes.
Hell, we even have the DRY (Don’t Repeat Yourself) principle, which basically states that it’s better to create a convoluted abstraction than to write different-but-very-similar code twice.
This of course leads to a lot of problems.
The average software project is so full of abstractions built on top of abstractions which are created on top of abstractions that it’s become virtually impossible to know what’s going on or even what your code is doing at all. Dizzying but invisible depth, touches upon this subject and is a really good short read.
On the other hand, laziness has proven itself as the driving force behind many of the most important scientific and engineering advances in history. It’s much easier to use a wheel than to carry things around, it’s a lot easier to use boats than it is to swim, hell, even dropping a single motherfucker of a bomb is a lot easier than dropping a thousand small bombs if you want to ruin a city for a few decades …
So maybe it’s not that programmers are lazy. Perhaps it’s really engineers who are lazy and it just so happens that in this point in history programmers are the most obvious sort of engineer working the most madly towards a better and brighter future. Most other fields have already sort of stabilised and/or take longer to adapt to new tools.
An important question to ask here is: Are programmers naturally lazy? Are smart lazy people drawn to programming or is this a social effect? Does laziness stem from the best programming practices? Or do the best programming practices stem from laziness?
A comparison
Recently I had a nice opportunity to compare how an architecture major goes about her day and how a computer science major such as me goes about his day.
Most of the architect’s life is filled with doing this or that labor intensive task as part of her homework. At any given time she is likely to be glueing some pieces of a model together, drawing the same object from fifty perspectives in autocad, or redrawing the same thing yet again in a 3D modeling software … which then gets imported into photoshop to become really pretty.

Image by Jon Olav via Flickr
It’s a constant barrage. By my estimates she probably spends twice as much time on coursework than she does actually attending class. [** she said it's actually 5-times more] And to make matters worse, getting better at this stuff doesn’t really speed up the process, it just means you know a few more keyboard shortcuts and make less mistakes when drawing.
Proficiency doesn’t optimize the critical section at all.
Contrast that with me. When I’m not attending class I’m usually working on my own projects. Because I can, because there’s plenty of time. When homework comes around, if it does, it can usually be dealt with in a matter of hours … even the most critically insane projects they give us rarely take more than a week of concentrated work, two weeks at most.
Proficiency in coding doesn’t mean typing faster (the equivalent of proficiency in architecture). It means thinking up solutions that are easier to implement, using tools that do half the work you’re supposed to be doing and so on. Eventually, as judged by internet dick measuring contests, implementation is the irrelevant part because everyone can do it. If you’ve got a day, you implement something, if you’ve got more time you also make it pretty and modular and reusable and so on.
Basically you’re done implementing the thing so quickly, most of your work is devoted to making the implementation prettier. But this isn’t really important to the task at hand, you do it because you can.
It almost seems like when programmers get bored of even making their implementations prettier, they turn to creating tools to make the implementation pretty right off the bat.
And the cycle repeats itself.
The next guy will use that new tool to implement something even quicker, then begin polishing it until he eventually gets fed up and creates a new even better tool.
So … hard work?
But to cycle back on my original point, how much does working hard even factor into programmers’ productivity? What does this mean for all those startups working 13 hours a day to gain an edge on the competition? Is this even an edge worth considering?

Image by Frodrig via Flickr
Hard work might even have a negative effect on programmer productivity. It obscures optimizations behind “Oh, I can do this by hand, it will only take ten minutes” (it takes 20). And the next time a similar task rolls around you have to do it manually again and so on.
Most importantly, hard work makes you stupid. Being tired leads to bad decisions, even making too many decisions leads to bad decisions (decision fatigue) as many studies have shown. In fact, that might be the best use of all the abstractions we like producing – let someone else to most of the decisions so I can focus on only the critical ones.
But I still don’t know if lazy people are drawn to programming, or does programming make them lazy …
Source: http://swizec.com/blog/programmers-are-fucking-lazy/swizec/2648
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Tim Drury replied on Fri, 2011/10/21 - 8:29am
Want some empirical evidence for this claim? Just yesterday I tried to update my gmaven-based maven plugin to output an XML header into an XML file. A class to do this was only available in groovy 1.8 so I spent three hours trying to coerce gmaven to use groovy 1.8 as it's advertised to do. Many google searches later, I finally determined gmaven isn't production-ready yet. I finally gave up and just forced the writing of the XML header into the output stream.
Thanks for making me feel less guilty and giving me a forum to rant about gmaven.
-tim
Seb Cha replied on Fri, 2011/10/21 - 9:34am
Andy Jefferson replied on Fri, 2011/10/21 - 12:06pm
Andrew Spencer replied on Fri, 2011/10/21 - 11:06am
The DRY principle doesn't exactly state "it’s better to create a convoluted abstraction than to write different-but-very-similar code twice". Rather, the principle is that every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Aside from that nitpick, and notwithstanding the disagreements from previous commenters, this article makes a worthwhile point, namely, that automation and removing redundancies often require abstraction, and abstraction can be deleterious.
Mitch Pronschinske replied on Fri, 2011/10/21 - 11:29am
John Esposito replied on Fri, 2011/10/21 - 11:38am
Lund Wolfe replied on Sat, 2011/10/22 - 3:32am
I think you can argue that an over-abstracted/over-engineered solution is actually less "lazy" than a simpler design, which, after further consideration, has reduced the unnecessary abstractions to an elegant, pragmatic, easily understood solution. It's better to allow time to consider the problem (if that's what you call "lazy"), get the design or fix right the first time, and move on (to the next new challenge to amuse your mind for a while).
Nicolas Marchildon replied on Sat, 2011/10/22 - 8:38am
Milos Silhanek replied on Sat, 2011/10/22 - 12:17pm
For all: Programmers are lazy in that meaning - they hate do the same work twice, they hate useless or boring or repeated work. The programmer (as a mathematician) thinks a half hour to spare time, typing or to make things more smart/elegant/beautiful. "Coding faster" is a trip to hell. May be typing faste.
Ingo Boegemann replied on Sun, 2011/10/23 - 6:18am
Agree - lazy is most definitly the wrong word.
At least once out of university, programmers work long hours. Worse - the real geeks do then continue afterwards to work on their own projects / contribute to OS, or just simply read more ...
Automation, removal of repetetive work is the job we do - ther very purpose of our job.
If it wasn't we would all still enter 0 and 1's on a daily basis ...
Shut Theory replied on Mon, 2011/10/24 - 4:49am
Milos Silhanek replied on Mon, 2011/10/24 - 7:52am
Jason Marshall replied on Mon, 2011/10/24 - 1:26pm
in response to:
Shut Theory
Laziness with apathy is probably one of the most dangerous combinations of personality traits that doesn't have a technical term (Or at least, I don't think Abnormal Psychology has identified it yet...)
Invention seems to come from two corners. You either have to be lazy, or be in a tight spot (Necessity), but you also have to have drive. Ambition. Energy. Passion. In the case of Necessity it surprises no-one that somebody will step up, overcome adversity, and Find a Way.
But Laziness plus ambition is trickier. It seems like the lazier you are, the better your solutions, until you get just a little TOO lazy and then you solve nothing. You become that gifted guy in highschool who never amounted to anything.
Otengi Miloskov replied on Fri, 2012/01/20 - 10:59pm
Christian Kulen... replied on Sat, 2012/01/21 - 7:01am
darryl west replied on Mon, 2012/01/23 - 12:41am
Carla Brian replied on Wed, 2012/04/25 - 12:33pm
Paul Russel replied on Sun, 2012/06/10 - 8:03am
All kind of people are attracted to programming. The spread of bums among professions is probably equal. But only the really lazy programmers get to shine. All others suck because they don't mind working hard, therefore they will constantly solve problems using more code. In time, some naturally hard working people get better at programming, and learn how to be lazy in a highly productive way. Does this answer your question?
Off topic: I've come across an interesting phenomenon recently: hire only hard working smart asses, and you can bet your life on getting an unmaintainable codebase after a few years. Hire a bunch of lazy bums, challenge their capacity to get something right, and you'll get the most elegant and compact solution in half the time.