Live data from Hacker News

We are retiring our bug bounty program

turso.tech

121–130 of 303 posts

Re: We are retiring our bug bounty program

#121
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

Context is everything for massive PRs. If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". So the question is, what's the context of the massive PR and how should it be handled? * Mature product making money, intermediate engineer just refactored everything so it's "better"? Shut the fuck up, kindly please, you will have to demonstrate that you unde…

> you will have to demonstrate that you understand why things are this way and why it's better before we even have this conversation

I can fling that back to you: very often the team hates the conclusion I arrive at, which is "It worked during your initial crunch and then everyone is just afraid to change it, which means your test coverage is far from good -- why is it not enriched?"

I am not trying to be an arse on purpose but the inertia and cargo-culting and tribe-defending practices I've seen during my contracting years (10-11) made me almost physically sick. Programmers are a fiercely territorial bunch and it's often to the detriment of the organization.

Of course the reverse cases exist: where the domain is difficult and ugly hacks had to be done so the project works and makes money. Absolutely. I love receiving this knowledge and integrating it; makes for interesting engineering discussions.

> Greenfield dev, trusted engineer getting from 0 -> 1 on something big? Maybe it shouldn't be held up in committee for 2 weeks. Maybe most objections will be superficial stylistic concerns.

Yep, full agree. And often times these stylistic concerns are not even that; they are often "I suffered here at the beginning, this green-horn should suffer as well!" which is honestly pathetic and it also happens quite a lot.

Re: We are retiring our bug bounty program

#122

Closing the program is totally reasonable. However, there is another option: Make submitters pay a nominal fee that is returned in the case that a real bug is found.

> Make submitters pay

Asking people to pay to submit bugs would start a firestorm of internet drama about asking people to do free work for the company and pay for the privilege. It doesn’t matter if the program actually paid out.

If they got even one report closed incorrectly we would never hear the end of it.

Re: We are retiring our bug bounty program

#123

Good time to mention this fantastic repo acting as a bot honeypot: https://github.com/UnsafeLabs/Bounty-Hunters The corresponding leaderboard: https://clankers-leaderboard.pages.dev

I don't understand this. If that project is not offering a bug bounty, why are they getting so many PRs? What possible incentive is there to spend real money on tokens just to push junk PRs? Are the PRs spamming a product or something?

My mind absolutely doesn't bend that way but I'd suppose clout and popularity?

Re: We are retiring our bug bounty program

#124
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.

No, it's that quite literally the PR submissions are SPAMmed. Whoever made them is acting like a SPAMmer, sending out lots of garbage and hoping it sticks. IE, they're not doing their part in reviewing what the AI found and generated.

Re: We are retiring our bug bounty program

#125
post #25

Earlier quoted context omitted.

AI can be the ultimate tactical tornado.

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…

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.

Re: We are retiring our bug bounty program

#126
post #19

Earlier quoted context omitted.

I think people would be more interested in listening to "AI skeptics" if they offered realistic solutions to the problems they predict. Pandora's box has been opened, let's deal with the consequences now instead of trying to shut the box which cannot be shut.

> I think people would be more interested in listening to "AI skeptics" if they offered realistic solutions to the problems they predict. AI is the fucking problem. Yes, it has (some) uses. It is not nearly the number advertised. And more and more the median use case seems to be, again, overloading people actually trying to do work with an avalanche of bullshit. The solution is exactly what the linked article says: s…

[dead]

Re: We are retiring our bug bounty program

#127
post #75

Earlier quoted context omitted.

This response is incredibly annoying and insufferable. It's only "impossible" at this point because people continually ignored skeptics and anyone warning about exactly these outcomes. Now that doom is here, it's too late to do anything about it. Just accept the doom!

The critics didn't do themselves any favors. Part think the Terminator has something useful to say on the subject, part invent contrived scenarios like self-driving cars having to resolve trolley problems. Reality turned out to be much more boring. But yes, what you said but unironically. Like it or not it's here, it's not going away, so all the remaining options have to assume that.

> The critics didn't do themselves any favors. Part think the Terminator has something useful to say on the subject, part invent contrived scenarios like self-driving cars having to resolve trolley problems. Reality turned out to be much more boring.

You do very well in battles against straw men.

Re: We are retiring our bug bounty program

#128
post #67

Earlier quoted context omitted.

Admirable effort. But why did you have to do it in one PR?

As per the other person's comment, yeah basically I could have broken it up but it would've been an arbitrary demarcation. I just deleted our functions and fixed everything that yelled. Admittedly that could've been one and then leveraging the libraries better could've been another, but they would've been 2 PRs that changed almost every line. So done as one to mitigate review time.

Arbitrary demarcations can still be valuable! Just because something is arbitrary doesn't mean that it's not helpful. Working in chunks will let you take more time to review each callsite individually, and increase your confidence in the changes

In the future, I would definitely encourage you to explore a more iterative solution—fix the first 50 occurrences first, or maybe all the occurrences of a handful of functions. For example, if you have utility functions A, B, C and D, maybe fix functions A and B first, and then C and D second.

Ultimately, at the end of the day it's going to depend on how much code you're touching. If you're only touching 100 library calls, then it's probably easy to do them in one PR. But if you're updating 1000 library calls, you'll need to take a more iterative approach. Building those skills now will serve you well in the future when working on bigger codebases and harder refactors.

Re: We are retiring our bug bounty program

#129
post #25

Earlier quoted context omitted.

AI can be the ultimate tactical tornado.

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…

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.

Post reply on HN