Post #913600
2026-04-01 19:21 UTC
Replies (6)
-
@jakobmiksch@mastodon.social 2026-04-04 11:58
thanks for your thoughts. Indeed I was not planning to do this. It reminded me to chaos engineering just for code review. Of course approaches like this should be agreed on with all devs
-
@EvenRouault@mastodon.social 2026-04-01 20:00
@jakobmiksch Likely, but always ask for consent beforehand. Realizing you've served as a guinea's pig to someone else social experiment always live a bad taste. Anyway the outcome is known: if you try hard enough, you'll succeed in introducing bugs not found during review. Review is not about preventing all bugs to be introduced but catching at least a few of them..
-
@rkaravia@mastodon.online 2026-04-01 20:11
@jakobmiksch I only know of a similar concept of a PhD thesis where someone wrote something like "if you have read this far, come ask me for a chocolate bar at the thesis defense". I believe nobody asked for the chocolate...
-
@HaraldKi@nrw.social 2026-04-01 20:26
@jakobmiksch I thought you put some blatantly silly stuff in, to avoid the more subtle discussions on whether to throw or to log or whether enum or int or whether make it immutable or not ...🤣
-
@Hyperlynx@aus.social 2026-04-02 03:47
@jakobmiksch I think it's a terrible idea, to be blunt. Reading other people's code is hard work. You're asking people to expend more effort for no actual gain. Presumably you're talking about open source and voluntary reviewers (I'm sure I don't need to point out this would be nonsensical in a business), and this just makes life harder for people who are already volunteering out of the goodness of their hearts. Why would I burn my limited energy playing stupid games? Besides, people miss things (that's what reviews are for). That means they might pick up some mistakes but not all of them; that's still valid. But by your scheme, they might pick up only the mistakes you put there and not the real ones, and that would still be valid. Next: how are your actually going to introduce errors in the system you're changing that are actually relevant? If your errors are introduced in a different system, you've wasted everyone's time by getting them to digest and understand two unrelated systems. If you error is in the same system, it's quite reasonable for someone to go "yeah, this isn't going to work due to this one error I've found" and simply stop there, and not even look for further errors. Finally, you have to remember to remove your own errors before the merge, which introduces a possible point of failure (and more work for you). Although, presumably with your scheme, they must be found by someone before you'll accept the whole change anyway, so perhaps not as big as issue. But, I mean, if I found out someone was doing this to me, I'd never look at their code again.
-
@sebhans@hachyderm.io 2026-04-02 22:04
@jakobmiksch My wife has worked as a supermarket test buyer. This means you go shopping and try to sneak as much stuff as possible past the cashier to test if they catch it (hide things in the corners, put expensive wine in a carton of the cheap stuff and so on). So yes, the concept exists. I haven't applied it to pull requests, though.