All means are fair except solving the problem

Hacker News Top News

Summary

A blog post describing how an industry veteran's code misuse warning caused critical workflows to fail, but instead of fixing the misuse, colleagues suggested various workarounds like adding more output handlers or suppressing warnings—highlighting the common engineering tendency to avoid solving root problems.

No content available
Original Article
View Cached Full Text

Cached at: 05/09/26, 12:31 AM

# All means are fair except solving the problem Source: [https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html](https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html) An industry veteran in my circles has recently made the rookie mistake[1](https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html#fn1)of printing a warning from his code upon misuse\. Surprisingly to nobody experienced, critical workflows soon came to a screeching halt\. It turned out that a program using his code prints something like “yay, done” upon exit, and scripts expect it to be the last thing it says\. But now those warnings occasionally got printed from destructors or such,*after*the “yay, done”, making the scripts think the program failed\. One might think that this prompted people to fix the reported misuse, and that thought would be another rookie mistake\. Instead, they were quick to point out that it’s hard to know where these warnings could come from, and we cannot risk all those critical workflows failing when some case of misuse surfaces in a new context\. I mean, you could grep to get an upper bound, and if you did, not that many places would come up\. But one could then say, as some in fact*did*, that maybe you haven’t grepped everywhere you should have, and even the cases you did find are owned by many different teams, so we won’t get the fixes quickly enough, etc\. Several solutions were suggested by helpful high\-ranking people: - You could add a destructor printing “yay, done”*again*if a warning was printed during the destruction sequence \(opening an interesting technical debate about the differences between a destructor, \_\_attribute\_\_\(\(destructor\)\), an atexit handler and other unspeakable horrors\)\. In fact, our industry veteran would later learn, and I swear that I’m not making this up, that*this was already implemented by someone else*who printed something during the program termination sequence, and had to appease the scripts\. - You could suppress the warnings by default, and enable them upon request \(opening a debate about the runtime method to enable them, and the appropriate circumstances to do this\)\. - You could write those warnings to their own file, and… When I was done scrolling his work chat with these helpful suggestions, our unfortunate industry veteran put on a melancholy smile and summarized the situation: “All means are fair except solving the problem\.”[2](https://yosefk.com/blog/all-means-are-fair-except-solving-the-problem.html#fn2)

Similar Articles

@systematicls: https://x.com/systematicls/status/2072975573287379194

X AI KOLs Timeline

This article discusses the critical role of loops in agentic engineering, explaining how throwing more tokens at a problem improves solution quality while addressing the pitfalls of naive loop implementations like compounding errors and lack of meaningful iteration.

Stop trying to engineer your way out of listening to people

Hacker News Top

An essay arguing that software engineers and product designers often avoid genuine user listening by over-engineering frameworks and systems, instead outlining seven common pitfalls that prevent effective listening to users and stakeholders.

The Final Bottleneck

Armin Ronacher

A reflective blog post on how AI acceleration in code generation overwhelms review processes, creating a new bottleneck in software engineering. Draws parallels to historical industrial bottlenecks and suggests throttling input as a necessary response.

The User Doesn't Care - But you should

Lobsters Hottest

A blog post arguing that while users don't directly care about code internals, good code quality is essential for performance, bug fixes, and feature delivery, contrary to the common cliché that only user-facing results matter.