Lazy programmer fallacy

Arseni Mourzenko
Founder and lead developer
177
articles
February 29, 2020
Tags: rant 34 short 50 management 34 quality 36

There is, among pro­ject man­agers, a think­ing that pro­gram­mers are lazy. Pro­gram­mers—they say—don't want to work; they pre­fer play­ing games or just do­ing noth­ing at all.

This is all but truth. Ac­tu­al­ly, many pro­gram­mers en­joy pro­gram­ming. They have cho­sen this field be­cause they en­joy chal­lenge, and be­cause they en­joy solv­ing prob­lems through code. For them, a day spent writ­ing code and be­ing pro­duc­tive is a day well spent.

How­ev­er, it is not un­usu­al to see pro­gram­mers not do­ing ex­act­ly that. There are three sit­u­a­tions which lead to that.

The first one is that the pro­gram­mer is not an ac­tu­al pro­gram­mer, but rather a guy who have cho­sen this ca­reer by mis­take or be­cause he had no idea what else to chose. They come to their job with no en­joy­ment what­so­ev­er, and do that only to get their mon­ey at the end of the month. If they could do some­thing else, they would. If you have this type of per­sons at your com­pa­ny, you should re­view your hir­ing process­es, be­cause spot­ting pro­files such as this is ex­treme­ly easy, and if you are un­able to do such ba­sic things, you shouldn't hire in the first place.

The sec­ond one is that the pro­gram­mer is tem­porar­i­ly not feel­ing well. There can be life events which make every­thing ir­rel­e­vant, es­pe­cial­ly the pro­ject the pro­gram­mer is work­ing on; there are events which make it dif­fi­cult to fo­cus, dif­fi­cult to solve prob­lems, dif­fi­cult to re­main in the same chair eight hours per day. It can hap­pen to every­one, and if hap­pens to a pro­gram­mer you hire, you should spot it, and give your help.

The third one, fi­nal­ly, is that many pro­jects are not about pro­gram­ming at all. In oth­er words, there is no real tech­ni­cal chal­lenge. For pro­gram­mers, those pro­jects are lit­er­al­ly ex­haust­ing. Since they can't do the ac­tu­al work, they spend most of the time won­der­ing what they are do­ing here, why can't they seek an­oth­er job, and how can they make it look like they are work­ing in the first place. All those tasks take a great deal of ef­fort, much more than the ac­tu­al pro­gram­ming. In­deed, an av­er­age pro­gram­mer would pre­fer spend­ing time pro­gram­ming, rather than try­ing to fig­ure out how to solve a com­mu­ni­ca­tion is­sue with an­oth­er team which pre­vents him from us­ing their API, or how to de­vel­op a fea­ture with­out in­tro­duc­ing a ton of bugs like he did the oth­er time, while man­age­ment told there would be no mon­ey spent on test­ing or refac­tor­ing.

For a man­ag­er or a lead de­vel­op­er, claim­ing that pro­gram­mers are lazy is tempt­ing, be­cause it frees them from a feel­ing that they didn't do their own job cor­rect­ly. Af­ter all, it be­longs to them to build around a pro­gram­mer the en­vi­ron­ment he needs in or­der to be ef­fi­cient: it's up to them to deal with ter­ri­ble work­ing con­di­tions, it's up to them to ex­plain to the up­per man­age­ment that tech­ni­cal debt, if kept un­solved, would only grow, etc. Nev­er­the­less, it's still their fault if a team is not per­form­ing as ex­pect­ed.

When your ex­pec­ta­tions are un­met, don't be­lieve that this is the fault of lazy pro­gram­mers. Start by check­ing what could make their life dif­fi­cult, what could force them to do noth­ing in­stead of do­ing what they like the most. Chances are, you'll find the cul­prit much faster. Pro­gram­mers are lazy in only one sense: they don't like bor­ing, man­u­al and te­dious things which dis­tract them from pro­gram­ming.