How to punish competence

Here is a recurring pattern I've noticed. As soon as a coder grows a little bit competent at coding he or she usually starts to have oppinions about the structure supporting coding. Programmers are by nature problem solvers and strive to make things more effective and less repetetive.
Many programmers, as they mature, starts to form ideas on how, for example, project leadership could be improved (Scrum, RUP, XP), tools could be better (IDEas, build systems, languages) or infrastructure could be improved (SOAP, Application servers).
What then happens is that "the man" assignes these persons to improve the stuff above in projects. The problem is that "the man" has no understanding for that these things costs a lot of money to improve. "The man" has no knowledge at all at providing the necessary preconditions to succeed at these tasks.
I don't know how many projects I've been in where the best programmer (and for the record I'm not talking about myself) has been assigned to fix the build system, install the issue tracking and holding the hands of noobs and loosers to try to make them more productive.This for the simple reason that "no one else knows these things" but the more experienced developers.
This leads to project staffing where the noobs and general loosers do the actual coding, the experienced programmers do maintenance tasks and no one does what they are good at.
Usually the more experienced a programmer is the less they have to do with the actual craft of coding. They spend time in meetings with third party providers endlessly hashing over protocol details, following up on orders of insfrastructure equipment or explaining to money people that "things cost money".

It kills the joy, the spirit and the quality in any programmer that gets the least bit competent.


  1. Code monkey :-)


  2. I, for one, would much rather write my own build system from scratch in QBASIC than use something maintained by people who don't know what a build system should be like.

  3. Which kind of proves my point in that you now spend your time building build systems instead of doing that other voodoo that you do so well.

  4. Yes but someone has to =) The problem is as you point out that that leaves the actual work to people who shouldn't be doing it, but I don't think the problem is to put them to work at the infrastructure but simply not to have them around. A team of five good programmers can change the world. A team of five good programmers and twenty incompetent ones can barely make a mainatainence release.