But also I have no idea how that situation arises unless the slower folks are just auto-approving PRs. You kind of did that to yourself if you let the new person get away with it.
I knew one engineer who came in every Sunday night to process missed orders from an e-com system they wrote. They were unable to actually fix the problems with their code, so they just fixed the problems by hand. Every week...for years on end. Management thought he was a star who worked hard. The devs knew he was the worst engineer they have ever worked with. He still works at that same company 25 years later.
The correlation between what management thinks and reality can be pretty large at times.
(Thank you.)
A tornado is something big and temporary.
Someone who makes a mess but stays to fix it cannot be described as a tornado.
I worked with actual TT and with people fitting the profile of your guy.
To me they are quite different and have a different impact on the teams they work "with".
I would say your guy is more a Sisyphus.
The ones I met where thought as hard working by management, because they actually were.
If your guy works extra on Sunday for free, they're working hard in my books.
They were not thought as stars, but they were more liked than average 9-5ers. "I know he's not great, but at least he's compensating by working harder".
In the end, if they make something not great, but the work expected from what they do is actually achieved, that's more than most.
And I honestly prefer the Sisyphus to the TT. At least I know they'll own what they do. Not drop it on everyone else to go chase their next "miracle".
Working hard on the wrong thing: endlessly manually processing things the software should be taking care of. Investing that time in fixing the code would be better. Working hard only matters when the effort is well spent.
In my case, it's worse than that. They usually get promotions, raises and move up the ladder. The business only cares about thing: making cash. This means pumping out feature as soon as possible because the sales team closed a million dollar contract, which includes features we don't have.
The engineers who deliver the features are noticed by managers and win big. No one cares about code quality and half the time, the code is rewritten or thrown away anyway..
I'm sure there exists organization where code is treated as art, but I sure as heck haven't worked in one. Over the years, I've given up trying to cleanup crap code, now I just get the work done as best as I can and call it a day.
You start by rejecting those PRs, saying "write more maintainable code, not quick hacks".
Management starts pressuring the original developer "why is it not merged yet, I thought you had it working".
That developer hits back with "well, it failed code review, they want me to refactor it".
Management goes back to the reviewer, "why did you fail this? It meets coding standards right? Pipeline is green".
Reviewer says "Well, yes it technically meets coding standards but it's full of hacks and is not future proof, it will bite us."
Management says "If we coded for tomorrow we'd never get anything done. Don't be so awkward". And then code gets merged.
Then you learn to just let these people go wild. If it hurts in the future you have a nice little "I told you so". But in my experience, management doesn't actually care if it hurts us in the future, it's not their problem. They just say "Well give me bigger estimates if you need to refactor". Fair enough, it's not a big deal but it is a pointless slog of picking up the pieces.
The other way it comes about is when the original developer just isn't really that good of a developer. So you end up in such an endless feedback loop trying to get the code in a good state that you piss everyone off and it's just easier to merge it.
Some hills just aren't worth dying on. And these guys can be exploited for your own advantage if you want to get code merged quickly ;)
How do you go about that when for example, my previous employer just allowed any software developer to commit to any branch, and there was never any code review happening?
IME the manager just approves the PR themself to "bias for action", someone else will pick up the pieces
Restricting changes to PR's is nowhere near universal.
The problem is allowing this kind of frantic tactical development even in "peace time".
In theory, sure, but in practice, to echo the others, you often don't have a choice, because of power dynamics/politics.
Its easy to say "its management's fault", but the principle is the same - these guys are spammers and quacks (and deserve nothing less than to be confined to the level of hell reserved for spammers), they just have to spam long enough and something will get through (volume over quality). And after their "success" i.e. fraud, they can ditch the company and move onto the next. I've seen multiple "seniors" like this, not actually very good at the work, but great at pushing half-baked slop.