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 Export to Word Export to PDF
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

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.

Quoting Mitchell Hashimoto

Simon Willison's Blog

Mitchell Hashimoto observes that most technical decision-makers prioritize job security over innovation, leading them to adopt safe, trendy solutions like AI context engines rather than building defensible technology.

When life gives you lemons, write better error messages

Hacker News Top

This article discusses Wix's initiative to improve thousands of error messages across its platform, defining characteristics of good versus bad error handling in UX design. It emphasizes clarity, empathy, and actionable solutions over technical jargon or blaming users.

Good architecture shouldn't need a carrot or a stick

Lobsters Hottest

Blog post argues that good software architecture should be self-evident and frictionless, advocating Netflix/Spotify-style “paved road” patterns over coercive governance boards or embedded architects.