I don’t begrudge high salespeople commissions because that means things are pretty good, just don’t let them run the company (see Steve Jobs ‘lost’ 1995 interview with Cringly).

1) until the restaurant goes under

But don't get me wrong, I'm not saying we should try to quantify the efficacy of SW devs more. I had a PM do that once in the form of ticket quantification as a KPI. I had to expend a lot of political capital to opt out from that nightmare.

His code was atrocious, but we'd put up with that until the IMAP incident because getting the CEO to understand that his code was bad enough for him to actually be a net loss in performance for the team didn't work until we had to scramble to recover what we could of the corporate e-mail.

Last I saw he was a senior developer somewhere more prestigious than the position he was fired from. Maybe he's improved. Or maybe he's just managing to stay above the threshold they'd fire him for.

A lot of bad developers just learn to fly sufficiently under the radar and hunker down and accept that they probably won't get many raises until they move jobs and can point to X years of service in company Y, aided by lack of willingness at many companies to stick their neck out when it comes to giving bad references (a lot of places I've worked, HR policy has been clear that we were only allowed to confirm dates of employment).

The key difference between good and bad engineers is that good ones deliver the product/finishes the projects (add bonus points if on time) and bad ones don't. Quality makes much less business sense and is usually only important to the engineer himself and his peers than managers that pay his wage. That's especially true in current "move fast and break things" environment. I have seen a fair share of bad engineers (by this definition) fired, even though they had decent technical skills.