[hnthrow0287345]

I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else, sometimes for higher pay. The slower folks end up getting the worse code and no raises in exchange for comradery.

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.

[hunterpayne]

My experience is exactly the opposite. The TT ends up being the last engineer standing a lot of the time. The people who want to have better refactoring and more maintainable code are usually the ones who move on. The TT often stays in the same place for 25 years. Often correcting mistakes they themselves made in the past.

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.

[wiether]

The profile you describe is not a Tactical Tornado to me.

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".

[autoexec]

> If your guy works extra on Sunday for free, they're working hard in my books.

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.

[DANmode]

Fix your last sentence while there’s still time, an otherwise super strong comment.

(Thank you.)

[swat535]

> I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else

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.

[Philip-J-Fry]

I can tell you how that situation comes about.

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 ;)

[alexandra_au]

>You start by rejecting those PRs, saying "write more maintainable code, not quick hacks".

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?

[HeyLaughingBoy]

Set rules on the repo. For example, no one on my project is allowed to check in code unless it's on a PR that's been reviewed and approved by at least two people. Attempting to push to /main will just fail otherwise.

[pengaru]

wow, that's a charitable take

IME the manager just approves the PR themself to "bias for action", someone else will pick up the pieces

[jcgrillo]

They'll often exploit a power dynamic. If you're less senior than them, in some organizations it can be very difficult to stand up to that behavior. I experienced that at my previous employer as a relatively senior engineer, even. Top down organizations look unfavorably on feedback that runs upwards. Your pushback will be seen as standing in the way of progress.

[mrgoldenbrown]

> I have no idea how that situation arises unless the slower folks are just auto-approving PRs.

Restricting changes to PR's is nowhere near universal.

[basilgohar]

Sometimes the issues emerge later. The code doesn't scale well, it has subtle bugs that crop-up later, it doesn't handle edge cases well. Basically, it answers the immediate issue well, but it is poorly engineered and hence, why it causes problems for others down the line.

[pphysch]

In objective terms, these tactical tornadoes are among the most valuable headcount at a big company to the extent that they can rapidly patch production issues and restore service, by any means possible.

The problem is allowing this kind of frantic tactical development even in "peace time".

[alfiedotwtf]

You fix the environment so that proper code reviews are explicitly part of the process regardless of priorities, unless management sign off on taking on responsibility of the shitstorm if things break in production

[smaudet]

> You kind of did that to yourself if you let the new person get away with it.

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.