That's well written. I think that requiered 2+ code review could also help because with time more people will gain knowledge of the dark parts of the codebase, just by reviewing the PR of “Martin” when he work on them.
That entirely depends on how well code reviews are managed. I've worked with a "Martin" in the past and we did manage to move to a system where 2+ reviewers were required but it simply got to the point where no one would "rock the boat" because he'd simply brush off every comment made, or call you up to have a long rambling conversation as to why he made the decision he did and how you're wrong and he's right, and given his position in the company you couldn't complain to anyone else about him because he was more valuable to them than you were.
We tried to put more and more blockers in front of him to attempt to encourage him to play nicer, but these were only temporary solutions to the bigger problem of "Martin" himself.
If the code base is arcane enough, code reviews won't matter. You just won't understand at all what is happening there. And the "Martin" will probably pressure you to accept anyway by telling the bosses "I can't work, they won't accept my code reviews".
That's true. But at least you will have evidence that Martin doesn't conform to the team rules.
I've been where this article describes, so has the author. Excellent article.
Great article.
And for those wondering, yes, Martin does quit with two weeks notice, eventually. Then business leadership get to embark on the "find out" phase.
Where do we stand on hoarding code to protect against outsourcing? I have a friend who is encouraging his team to do everything he can to hoard and make it impossible for recently onboarded individuals in a "cheaper cost center" to mess with it.
I think it's the right call, for both the team and the company. The team wants to keep their job, and to keep building the thing they worked so hard on. But I think it's also best for the company. Management can't control themselves when they see that they can get literally 10 engineers for the price of 1 local engineer. They know that each of the 10 is going to be less good than than a local engineer, but they always fall for "but still, they're not that much worse and for that price how can I lose!".
Of course, the damage of 10s of mediocre-bad engineers is far more costly, especially when outsourcing an existing project. So I'd say it's the right thing for everyone for the team to protect their code ownership anyway they can.
If your hierarchy is trying to destroy the product you create, just leave. You are not the main stackholder, and do not get benefits from the well-being of your product. The only things that should be importants as and an employee are “is my job interesting” and “are the work conditions great”. If you have to fight your management, they have already lost you because they just broke your trust, as well as the second point.
That's well written. I think that requiered 2+ code review could also help because with time more people will gain knowledge of the dark parts of the codebase, just by reviewing the PR of “Martin” when he work on them.
That entirely depends on how well code reviews are managed. I've worked with a "Martin" in the past and we did manage to move to a system where 2+ reviewers were required but it simply got to the point where no one would "rock the boat" because he'd simply brush off every comment made, or call you up to have a long rambling conversation as to why he made the decision he did and how you're wrong and he's right, and given his position in the company you couldn't complain to anyone else about him because he was more valuable to them than you were.
We tried to put more and more blockers in front of him to attempt to encourage him to play nicer, but these were only temporary solutions to the bigger problem of "Martin" himself.
If the code base is arcane enough, code reviews won't matter. You just won't understand at all what is happening there. And the "Martin" will probably pressure you to accept anyway by telling the bosses "I can't work, they won't accept my code reviews".
That's true. But at least you will have evidence that Martin doesn't conform to the team rules.
I've been where this article describes, so has the author. Excellent article.
Great article.
And for those wondering, yes, Martin does quit with two weeks notice, eventually. Then business leadership get to embark on the "find out" phase.
Where do we stand on hoarding code to protect against outsourcing? I have a friend who is encouraging his team to do everything he can to hoard and make it impossible for recently onboarded individuals in a "cheaper cost center" to mess with it.
I think it's the right call, for both the team and the company. The team wants to keep their job, and to keep building the thing they worked so hard on. But I think it's also best for the company. Management can't control themselves when they see that they can get literally 10 engineers for the price of 1 local engineer. They know that each of the 10 is going to be less good than than a local engineer, but they always fall for "but still, they're not that much worse and for that price how can I lose!". Of course, the damage of 10s of mediocre-bad engineers is far more costly, especially when outsourcing an existing project. So I'd say it's the right thing for everyone for the team to protect their code ownership anyway they can.
If your hierarchy is trying to destroy the product you create, just leave. You are not the main stackholder, and do not get benefits from the well-being of your product. The only things that should be importants as and an employee are “is my job interesting” and “are the work conditions great”. If you have to fight your management, they have already lost you because they just broke your trust, as well as the second point.