4 ms·

Sounds a like a tactical tornado, made me think of this paragraph: “Almost every software development organization has at least one developer who takes tactica

by chapinb 5mo ago

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

abirch 5mo ago
AI can be the ultimate tactical tornado.
- joe_mamba 5mo ago
  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.
  - goalieca 5mo ago
    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"
    - autoexec 5mo ago
      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.
  - nathanielks 5mo ago
    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.
  - CamperBob2 5mo ago
    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.
    - thavalai 5mo ago
      I wonder if transaction costs get in the way. Someone has to pay the payment provider in both directions.
    - thfuran 5mo ago
      $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.
- pkulak 5mo ago
  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:
wg0 5mo ago
This is profound and beautiful description. Thank you for sharing. Totally can relate to that. Been there, seen that.
- ffsm8 5mo ago
  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
  - varjag 5mo ago
    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.
  - toraway 5mo ago
    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.
hnthrow0287345 5mo ago
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.
- Philip-J-Fry 5mo ago
  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 5mo ago
    >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?
selectedambient 5mo ago
too real
subarctic 5mo ago
That paragraph uses the word tactictal a lot without explaning what "in a totally tactical fashion" means
deleted 5mo ago
[deleted]
xnx 5mo ago
A True Engineer(TM) knows it is better to accomplish nothing correctly than to achieve something imperfectly.
HeyLaughingBoy 5mo ago
When I was being trained in Team Software Process (https://en.wikipedia.org/wiki/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!

by chapinb 5mo ago

abirch 5mo ago

AI can be the ultimate tactical tornado.

joe_mamba 5mo ago
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.
- goalieca 5mo ago
  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"
  - autoexec 5mo ago
    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.
- nathanielks 5mo ago
  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.
- CamperBob2 5mo ago
  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.
  - thavalai 5mo ago
    I wonder if transaction costs get in the way. Someone has to pay the payment provider in both directions.
  - thfuran 5mo ago
    $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.
pkulak 5mo ago
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:

wg0 5mo ago

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

ffsm8 5mo ago
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
- varjag 5mo ago
  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.
- toraway 5mo ago
  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.

hnthrow0287345 5mo ago

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.

Philip-J-Fry 5mo ago
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 5mo ago
  >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?

selectedambient 5mo ago

too real

subarctic 5mo ago

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

deleted 5mo ago

[deleted]

xnx 5mo ago

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

HeyLaughingBoy 5mo ago

When I was being trained in Team Software Process (https://en.wikipedia.org/wiki/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!