The essential skills of a developer

I was re­cent­ly ap­proached by a man­ag­er work­ing in a large (more than a thou­sand em­ploy­ees) com­pa­ny. Aside his man­age­ment job, he was also ac­tive­ly con­tribut­ing to the hir­ing in­ter­views. He have read the se­ries of ar­ti­cles I wrote on the sub­ject back in 2014 (part 1, part 2, part 3 and part 4), and lis­tened to my the­o­ries about the ob­ses­sion for tech­nolo­gies and the lack of un­der­stand­ing of the skills that mat­ter the most, but found that there was some­thing sub­stan­tial miss­ing. The dis­cus­sion that fol­lowed be­tween us is worth shar­ing.

My vi­sion of the hir­ing process was that hir­ing in­ter­views for soft­ware de­vel­op­ment po­si­tions overem­pha­size tech­nolo­gies. A usu­al three hours in­ter­view hap­pens this way: a bunch of gener­ic stu­pid ques­tions for a start, such as “where do you see your­self in five years?” or “what are your strong and weak points?” fol­lowed by tech­ni­cal ques­tions which can be more or less spe­cif­ic, such as “In which case would you use JSON over XML? Why?” fol­lowed in turn by ex­er­cis­es. At the same time, the in­ter­view lacks com­plete­ly the as­sess­ment of the nec­es­sary skills of a de­vel­op­er—the abil­i­ty to work in a team, the abil­i­ty to com­mu­ni­cate ef­fec­tive­ly, the will­ing­ness to learn, the abil­i­ty to learn fast, in­clud­ing out­side the com­fort zone, the abil­i­ty to un­der­stand peo­ple from oth­er do­mains and pro­fes­sions. A few traits are nec­es­sary as well, such as the dis­ci­pline, the re­spect of oth­ers, etc.

The man­ag­er finds my vi­sion clear­ly ide­al­is­tic. All those skills are in­deed nec­es­sary for an ide­al team in an ide­al com­pa­ny work­ing on an ide­al pro­ject. In re­al­i­ty, no­body cares about those skills, and they have ab­solute­ly no rel­e­vance to the pro­duc­tiv­i­ty of a de­vel­op­er.

The abil­i­ty to work in a team? Come on! Those are just a bunch of guys work­ing on their re­spec­tive tick­ets. If they are able to talk to each oth­er, it's nice. If they don't, it wouldn't mat­ter much, since man­agers mi­cro-man­age any­way.

Com­mu­ni­ca­tion skills? Who cares! No­body has time to read any­thing in an av­er­age com­pa­ny. Nor lis­ten. And why would I lis­ten to an­oth­er col­league, es­pe­cial­ly when his opin­ion dif­fers from mine? With peo­ple from Twit­ter gen­er­a­tion re­plac­ing step by step old­er gen­er­a­tions, com­mu­ni­ca­tion re­mains only in a form of a Twit­ter post. Even if you make an ef­fort writ­ing some­thing, most per­sons won't make an ef­fort to read it, more­over to un­der­stand it cor­rect­ly.

Our dis­cus­sion con­tin­ued on oth­er points, but I sup­pose you get the pic­ture. An av­er­age em­ploy­ee don't need those skills, and some of them would even be an is­sue of mak­ing a per­son an out­sider, his cul­ture be­ing fun­da­men­tal­ly dif­fer­ent from what is ac­cept­ed in the in­dus­try.

Then what are the skills that ac­tu­al­ly mat­ter? If we look at what is be­ing mea­sured in an av­er­age com­pa­ny, it ap­pears that punc­tu­al­i­ty is the only thing that mat­ters. Of course, to re­tain your po­si­tion and pos­si­bly get a pro­mo­tion, you should be strong at pol­i­tics—in the case of de­vel­op­ers, it's not about be­ing “strong” but rather the least bad at—and some­times look skill­ful. This is a vague idea of mak­ing sure that if pro­mo­tion is avail­able, the man­ag­er choos­es you, and not some­one else from the team. In prac­tice, this could be en­sured by dif­fer­ent means, in­clud­ing the it­er­a­tive process of cre­at­ing a prob­lem and solv­ing it.

On av­er­age, un­less you are good at pol­i­tics, you also need to give an im­pres­sion that you do your job. Some­times, this means that you need to ac­tu­al­ly ac­com­plish some tasks, for in­stance to de­liv­er fea­tures. While you don't need them to be bug free and you don't need to do it fast, you still need, at a giv­en mo­ment, to de­liv­er the thing. This, in turn, means that you have to cope with the ag­gres­sive en­vi­ron­ment where every­thing is de­signed to pre­vent you from re­leas­ing any­thing: con­stant noise, phone calls, peo­ple walk­ing near your desk, talk­ing to your col­leagues sit­ting near­by, wrong work­ing sched­ule, wrong light­ing, in­ap­pro­pri­ate hard­ware, wrong­ly con­fig­ured ther­mo­stat. So we're back at hir­ing some­one who can work un­der stress, with the sole dif­fer­ence that here, we in­ten­tion­al­ly de­signed an en­vi­ron­ment which pre­vents any form of in­tel­lec­tu­al work, and won't change that any­time in the fu­ture.

Putting hypocrisy aside, a job post­ing should be de­scribed as this:

We're look­ing for a per­son who is able to work in a crap­py en­vi­ron­ment. You'll share your desk with a smelly guy—he still takes a bath once per month—at your left and a sales­per­son with hear­ing im­pair­ment at your right. Work­ing in our main of­fice is as pleas­ant as go­ing to a beach—at least the tem­per­a­ture is com­pa­ra­ble, be­cause we can't use air con­di­tion­ing, since one of our guys starts cough­ing a lot (with­out air con­di­tion­ing, he coughs as well, since he's near­ly al­ways sick). Just for you, we re­cent­ly or­dered a PC with In­tel Celeron—be glad, a few folks here still work on a Pen­tium 4.

You'll be work­ing on our flag­ship prod­uct which is al­ready late (that's why we hire you). You'll be the lead de­vel­op­er (that's prob­a­bly why you got a Celeron), and you'll be work­ing with four In­di­an guys (they don't speak Eng­lish, but it doesn't mat­ter, since our broad­band con­nec­tion makes Skype com­mu­ni­ca­tion with In­dia re­al­ly fun!)

The last thing: you should ab­solute­ly be able to de­liv­er the prod­uct two months ago. Don't lose our trust.

Such hon­est job post­ing means that, in­deed, the only cri­te­ria which mat­ter for a can­di­date is, once again, pol­i­tics and the abil­i­ty to re­lease any­thing de­spite the con­text.

Then why wouldn't we see more em­pha­sis on that dur­ing the in­ter­views? It's sim­ply be­cause it re­quires that the com­pa­nies stop ly­ing to them­selves. Such com­pa­ny would need to face its own prob­lems, and work to solve them. The both steps, how­ev­er, are tremen­dous­ly dif­fi­cult, and it's much eas­i­er to pre­tend that every­thing goes well and that we are look­ing for high­ly mo­ti­vat­ed and high­ly skilled in­di­vid­u­als. Then, it re­al­ly doesn't mat­ter what should be em­pha­sized dur­ing the in­ter­views—the skills which would mat­ter for a com­pa­ny which strives pro­duc­ing high qual­i­ty soft­ware, or the tech­ni­cal skills. Not sur­pris­ing that most hu­man re­sources chose the lat­est: it is much eas­i­er to pre­tend to know how to mea­sure tech­ni­cal skills than the ac­tu­al skills: “I spent five years work­ing with Java” sounds bet­ter than “I spent five years be­ing re­spect­ful.” It is es­sen­tial­ly the same thing, but it sounds dif­fer­ent.

While I find this vi­sion ex­treme­ly pes­simistic, I can't re­ject the fact that this trans­lates well enough the soft­ware de­vel­op­ment ecosys­tem I study for years. I'm just sad look­ing at the peo­ple who may be able to do great things if they were per­mit­ted to do them, and won­der­ing what a cor­po­ra­tion which would care about the em­ploy­ees could achieve in terms of prod­uct qual­i­ty and in­di­vid­ual pro­duc­tiv­i­ty of de­vel­op­ers.