Hacker News Reader

Comment by chapinb | Hacker News Reader

Sounds a like a tactical tornado, made me think of this paragraph:

“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” - John Ousterhout, A Philosophy of Software Design

View on HN

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.

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.

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

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

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

(Thank you.)

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

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

>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?

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.

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

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.

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

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.

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

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

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

AI can be the ultimate tactical tornado.

Yup, this was my first thought. Tell an LLM that there's a bug, and it will _happily_ add 200 lines to the project, usually wrapped in if statements so that it all interleaves with existing code. Then it will write twice as many lines in tests, run it all, and be done. Your bug is fixed. All the tests run, and test coverage went up. Now do that a couple dozen more times. :shudder:

But it really doesn't have to be like this.

For their bug bounty program, the company can just charge 5-10$ per submission to guarantee everything you send gets thoroughly reviewed by a human, and so it completely eliminates bot slop DDoS submissions overnight. If your bug and PR was actually good, then you get 10 + 1000$ back, and if it wasn't good, then you need to do better due diligence next time, and the skilled human feedback you received on why it wasn't good, was a valuable lesson for your engineering career, and it only cost you the price of a Starbucks latte, and it also cut out all the scammers polluting the system. This way everyone wins.

I said it before and I'll say it again, for opportunities open to the entire world on the internet, adding monetary friction is THE ONLY (anonymous) WAY to filter out serious people from bad actors doing spray-and-pray hoping they'll make some money, or get that job, by weaponizing AI bots. You can't rely on honor systems and a high trust society on the anonymous open internet, you need to financially gatekeep to save yourself and your sanity, and make sure the honest serious people you want to engage with don't end up drowning in the noise of the scammers and unscrupulous opportunists.

But we can't shut ourselves down just because we refuse to apply solutions to AI slop DDoS.

The bots spam even when there's no bug bounty program. The emails start out with "I received $500 for a similar reported on another site"

Thankfully the number of beg bounties I've seen has been stable so far. Maybe they're just devoting most of their time on the places that openly promise money.

  > monetary friction is THE ONLY (anonymous) WAY to filter out serious people from bad actors

How are monetary transactions anonymous?

It's not fully anonymous but partly.

I said it before and I'll say it again, for opportunities open to the entire world on the internet, adding monetary friction is the only way to filter out serious people from bad actors doing spray-and-pray hoping they make some money or get that job through weaponizing AI bots and sucking all the air in the room.

So many problems can be solved that way, including customer support. Instead of having to post a sob story on Twitter and HN when the AI at BigCo bans my account for no reason, why not charge me $100 for access to human support that is empowered to triage and escalate genuine issues? Then, issue a refund if the problem is on their end.

I don't understand why this isn't a thing.

$100 is way too much. Maybe $5 to get people to spend 30 seconds on google to solve the easy problems instead of calling. But I wonder if even that would be enough to significantly incentivize claiming everything is intended behavior / user error just for another revenue stream.

$100 for someone in SV isn’t much. $100 USD for someone in Africa, India, some parts of Asia could be a week or even months salary.

You could probably adjust the cost per region, but then you open yourself up to spam bots again because it’s trivial to spoof one’s location.

>$100 for someone in SV isn’t much. $100 USD for someone in Africa, India, some parts of Asia could be a week or even months salary.

That's kinda irrelevant. A Macbook Pro is still around $2k USD whether you're in US, EU, LATAM, Africa or India. They don't sell it cheaper to people in developing nations just because they earn less money.

You do know that there are ways online without a MBP?

And that developing countries do have access to the internet too.

That's offtopic form what I was replying to.

Then that would make your comment off topic from what everyone else was talking about.

My guess is there is no easy way to deal with chargebacks and they would probably be bad.

It would almost need to be analog. Fill out this form and drop it in the mail with 10 bucks inside.

Placing holds on money on a credit card is totally normal. Hotels do that all the time.

My guess is there is no easy way to deal with chargebacks and they would probably be bad.

Sure there is. That would be casus belli for a real ban.

It’s hard to forecast this. Support calls occur chaotically. So staffing to support them is difficult to do in a way that keeps a steady margin.

I wonder if transaction costs get in the way. Someone has to pay the payment provider in both directions.

Then who arbitrates the inevitable dispute over whose end the problem was?

For the times when it actually saves the company from going through arbitration, $100 is cheap.

This is a great strategy idea, I like it. I'm not good at thinking out the curse of the monkey's paw, so I'm curious if folks can think of any downsides.

That paragraph uses the word tactictal a lot without explaning what "in a totally tactical fashion" means

When I was being trained in Team Software Process (https://en.wikipedia.org/wiki/Team_software_process) our TSP coach mentioned someone on an adjacent team that Management loved because he stayed late, worked weekends and was generally seen as a hero by them.

The problem, as the coach pointed out, was that that kind of behavior was pathological and showed poor planning and bad project management. Cheering on someone, even someone with the best of intentions, who was working like that was sending exactly the wrong message and reinforcing the wrong behavior.

But we already knew that!

This is profound and beautiful description. Thank you for sharing. Totally can relate to that. Been there, seen that.

Do people like that exist?

Totally.

But seriously, I guarantee you the opposite is more common- the incompetent devs which can't manage shipping anything, keep trying to do "surgical and small edits" after 1 week of thinking about them and then have them blow up in prod for someone else to fix quickly because if it's up to them, it'll take 2-3 sprints

10 years ago I was a lot closer to what y'all talking about. After having more and more colleagues I can no longer agree and suspect this is mostly the opinion of incompetents which try to discredit regular devs.

Another thing they always lack is the ability to see when a large change is necessary because that's just what is necessary to achieve the feature in a stable manner. Sorry to say this, but starting of this discussion while trying to discredit large change sets in the age of ai is incredibly inept.

When you wrote your software well, large changes are possible and increase stability when you actually need to add a fundamental change of behavior. Which can come from a miniscule requirement.

But to close off on the topic of this article: they made the right call. In the open source context you cannot have this kind of incentive anymore with openclaw continuously shitting out one PR after another

Amen. There has to be some people like that statistically but literally every prolific programmer I know is also pretty damn good. Proficiency tends to be a function of practice.

From the excerpt it sounds like the author is just describing one specific archetype from within a list of others included in the book and doesn't make any claims about it being a uniquely common type within every org, or the most common type of bad engineer in general.

In fact it gives the opposite impression by specifying "at least one", which implies the category is supposed to be distributed widely enough to be recognizable in an org of sufficient size, but not dominating the ranks of software developers in droves. That seems more like a strawman you're arguing against.

A True Engineer(TM) knows it is better to accomplish nothing correctly than to achieve something imperfectly.

too real

Reply on news.ycombinator.com