[CoolGuySteve]

I used to think this way until I started working with someone who was nearly always the one who broke it. At some point we just had to face the fact that his work was unreliable even after significant mentoring.

If the tasks were difficult that would be one thing, but I'm talking about stuff like committing code to prod that was clearly never even executed once.

[vvanders]

Sure and those people exist. However what you're really looking for is remorse + understanding of the magnitude of the issue.

If you have those two things then someone is already motivated to learn from what happened and will probably never make that mistake again(which are the large majority of engineers in my experience).

[pnathan]

Most mistakes aren't problematic. But while we blame the code, not the writer - it serves well to quietly have a counter of "problematic errors" and to keep an eye on the people who increment it the most. After a while, and after a pattern has been established...

[jerrre]

You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

[pnathan]

> You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

Oh yes. Nothing I said should be read as precluding that. High-risk components cause more fallout when they break, that's how it works. Or fragile components break easily. Sure.

But it's wise to keep an eye out for people who are seriously problematic and to establish a pattern of problem-causing, for the purposes of remanding to HR.

[altano]

Sounds like you have a code review and automated testing problem and not a bad coworker problem.

[lawn]

Sounds like both.

[CoolGuySteve]

We have both of those setup, the guy is just an asshole.

[uoaei]

In that case, the "what broke" was the hiring process and the fix is them leaving that role.