CI does nothing to prevent bad developers checking in bad code. You just end up with equally poor unit tests.

If it doesn't "prevent" people from checking in code (in the strictest sense of the term) that breaks lots of other code, it certainly does some combination of slowing them way down, notifying other people way sooner, or forcing them to be a great deal more skilled in how they check in their breaking code (in the "if you make something idiot-proof, someone will build a better idiot" sense of skilled).

It's not perfect, but it's better than most of the alternatives, and perfect isn't actually on the table anyhow.

True. Code reviews and standards are the tools to use in this case.

I've found that code reviews are one of the best ways to increase code quality. Even just talking with other developers about why they've done things is helpful in thinking about simpler options and keeping things closer to the architectural vision.

Just questioning the implementation is enough to improve quality. Plus it helps people grow without putting them on the spot (if done right).

Who cares about poor unit tests in this case? It's all about the INTEGRATION tests that run on CI to make sure your bad developer can only fuck their shit up and not anyone else's. And if you have bad developers building your integration testing framework, you have bigger problems.

If someone checks in code that breaks a bunch of tests, then you know right away. And the underlying assumption is that tests are written by multiple people with varying degrees of quality. Can bad code sneak through the tests? Of course! But to say it does no good at all is wrong.

Sometimes they are in politically privileged positions and you can't get rid of them, ask me how I know.

How do you ... know?

That is quite sad. In this case you are not firing for the wrong reason.

I get that HR might need to verify that this person is being fired for the right reason and that no discrimination is in play (which might happen unwittingly), but just keeping someone employed because they are a minority is not a good solution.

On a related note. If I was a minority, I would think that I was just being hired or kept on the team because I am a minority and not for my technical ability. This behaviour from HR would further encourage that thinking.

Solution is easy there -- promote away.

Please no. That might get them out of your hair (maybe), but then you've just put someone incompetent in a position where they can exercise it even further.

I think people doing this is the direct cause of some head-scratchingly awful middle managers I've had to deal with..

Most middle managers are awful though, because they get no training.

Dilbert's Principle?

If HR can't get rid of an underperforming employee because they're too lazy to do their homework, the company is fucked anyway. At least the dude is out of your hair.

Agreed. The article mentions influential developers like this who are stuck in the past.

Because you are one ?

One of our (now ex) developers would write tests that setup a mock, and test the properties of the mock, so if you deleted the source code, the test would still pass!

His pull requests sucked up hours of other devs time, but bad stuff still leaked through simply because the other devs didn't have time to rewrite his PR. He was fired eventually, but the ongoing cleanup still continues...