Last night I was brushing up my CV which brought back memories from my past work environments. I've been in the software industry for 10 years now, from data analyst (I don't have a CS degree) - to junior programmer - to software developer - to senior developer - to tech lead (still programming and liking it), mostly C & C++ with a few errands into different realms. And here's what doesn't give me rest:
I don't recall anyone who got fired over bad code.
No-one. What's more, I don't even know anyone who heard of anyone getting fired over bad code.
I'm emphasising bad code because I did witness people fired (or at least pressured to leave) over no code -- guys who couldn't solve simple tasks at all; no matter how much time given nothing was even remotely working.
But as soon as someone is able to write anything that can be hand-waved as "ready" or "done", a force field seems to surround them. And it doesn't matter if the "done" code is teeming with easy to avoid errors that bite us back in QA or by angry customers, or is constantly re-inventing routines present in the standard library, or is grossly over-complicated (pages of code that could be reduced to a few dozen lines, no exaggeration), or doesn't put the slightest effort into factoring out commonly used routines (just copy-pastes boilerplate), or has variable names that have nothing to do with the values they hold. Even if some of the above bleed numerous man-days out of a project for bug-fixing, additional QA cycles, added hours for debugging because other team members can't figure it out, added hours for refactoring because some team member wants to figure it out -- no heads roll.
To be clear, I'm no fan of pulling guns on people because they made a mistake. Everyone makes them, even the best devs I seen stumble often at the beginning (seldom later on). I'm talking of select cases who make this kind of mistakes over and over again despite being pointed out in code reviews. And I'm deliberately setting aside "petty" issues like not following code conventions to concentrate on things that cause real damage.
That perplexes me. On every project I've been, time, quality, and in consequence profitability was always emphasised but people who repeatedly hinder all three were not eliminated. At first I thought it's because technical knowledge is usually distributed along the bottom of the org chart but I noticed bad apples fail not only at writing code. They often write illegible documentation, raise low-quality bug reports (missing basics like software versions or even what the problem the problem was), have poor email communication skills -- are poor workers overall. So management can see it and that information does trickle higher up (been hinted many times during small talk that they know who "is useless").
In all of my 10 years of experience, programmers who write bad code have been constantly reminded (and made fun of) by peers that what they do hurts, encouraged and reprimanded by mid-management to do better, but never fired. In cases where poor skills are paired with tendency to stir up conflict, their careers sometimes stagnated. But if they are superficially co-operative, they do just fine and sometimes get promoted to senior and architect positions.
Is it normal industry-wide that people don't get fired for writing bad code? If so, why? And more importantly, how to deal with repeat offenders if eliminating them is not an option?