The core argument in “The Curse of Knowing How, or; Fixing Everything” is simple: technical fluency changes what you notice, and what you notice can become exhausting. The post treats programming not as a triumphant path toward mastery, but as a habit that makes every rough edge feel like a problem waiting to be solved.
The piece opens with small examples that most developers would recognize. A script renames files. A shell alias trims a command. A tiny helper formats JSON. None of that is remarkable by itself. The author’s point is that once a person crosses that threshold, the mind starts to see systems differently. The operating system, the editor, the website, the build chain, the shell prompt: all of it becomes fair game.
From there, the essay moves from irritation to responsibility. Software is described as something that never stays solved. Libraries deprecate, APIs change, scripts break when a site alters its HTML, and containers die when a mirror URL rotates. The emotional reaction is not just annoyance. It becomes guilt, because the person who built or fixed the thing now feels personally accountable when it rots.
The essay’s title phrase, the “curse of knowing how,” captures that shift. Once you know how to repair things, every flaw can look like a failure to act. The author describes this as an endless TODO list: every system can be improved, every inconvenience can be framed as an indictment, and every workaround can become the seed of a new project. That pattern, the essay suggests, is how technical skill can feed burnout rather than relieve it.
The post also draws a line between coding and emotional coping. Building things offers immediate feedback. A script either works or it does not. That can be comforting in a world where many other problems are messier and less tractable. But the same logic can become unhealthy if every source of friction starts to feel like a challenge to personal agency. The essay argues that the desire to make one more tool, or one more refactor, can be a way of self-soothing.
What makes the article work as a technology essay is that it avoids framing this as a bug in the individual. Instead, it treats the cycle as a consequence of competence itself. A person who learns how systems fail becomes more sensitive to failure. The more they can fix, the more they can imagine fixing, and the harder it becomes to stop.
That leaves the author with a practical conclusion: not everything broken belongs to you. Not every bad user experience is your responsibility. Not every imperfect tool needs to be replaced. The piece is less a technical critique than a reminder that skill changes perception, and perception can become a burden when it turns every corner of life into unfinished work.
