The curse of knowing how, or; fixing everything

Original Article ↗ Hacker News Discussion ↗

Identification with the “curse”

  • Many commenters saw themselves in the essay: endless side projects, half-finished tools, and the compulsion to “rewrite it properly” from first principles.
  • This isn’t limited to software: people mentioned cars, woodworking, home repair, even politics and life-organization as similar arenas for over-fixing.
  • Several contrasted youthful idealism (“everything can be made elegant”) with mid‑career fatigue and acceptance that everything is at least slightly broken.

Rewrites, minimalism, and first principles

  • Reimplementing systems (static site generators, OSes, languages) is widely acknowledged as both fun and educational, but rarely “the solution.”
  • Minimalist stacks (Forth, Oberon, boring embedded systems) are admired for longevity and simplicity, but Forth in particular is cited as not socially scalable without better abstractions.
  • Some argue that deleting and standardizing (using defaults, avoiding custom build/deploy scripts) is more powerful than adding — but also harder and more emotionally costly.

Ego, identity, and emotional regulation

  • Several tie the urge to fix everything to ego and self-worth: praise for tools becomes validation; procrastination often comes from fearing that code reflects one’s value.
  • “Technical work as emotional regulation” resonated strongly: people admit to building tools to avoid facing health, relationship, or existential problems.
  • A few call out a hidden sense of superiority; others defend it as simply having higher standards in a low-effort world.

Boundaries, over-responsibility, burnout

  • Strong agreement that knowing how to fix things creates a moral weight—especially once others depend on your code or know you “know how.”
  • Burnout is framed variously as:
    • Over-responsibility (feeling you must fix everything you can see),
    • Misaligned effort (pouring energy into low-meaning work),
    • Or both.
  • Parenting and non-programming hobbies are repeatedly mentioned as brutal but effective constraints that force prioritization and acceptance of “good enough.”

AI, “vibe coding,” and lowered friction

  • Some say that knowing ChatGPT/Claude could produce a quick, ugly solution makes it easier to leave problems unsolved (“I could always hack this later”).
  • Others find that AI just lets them fix more things and deepens the curse.
  • “Vibe coding” is criticized as delivering neither speed, quality, nor maintainability unless tradeoffs are understood; it can accelerate mess as easily as value.

Change, yak shaving, and system design

  • A long subthread treats change as a probabilistic process: every fix risks spawning further fixes, leading to “yak shaving” in both software and daily life.
  • Discussion of geometric-series models for expected change highlighted failure modes when each change, on average, causes more than one new change (runaway complexity).
  • Several suggest designing systems specifically to be easy and low-risk to change, rather than aiming for timeless perfection.

Standardization, “good enough”, and perfectionism

  • With age, many report shifting from customization to standardization: defaults, boring tech, and long-lived tools over clever personal systems.
  • Prioritization and “knowing what ‘done’ looks like” are presented as learned, hard-won skills.
  • Tension emerges between:
    • “Optimizers” who chase better abstractions and deeper understanding, and
    • “Satisficers” who stop at “good enough” and are often happier but (arguably) less technically ambitious.

Social burden of competence

  • The “curse of other people knowing you know how” appears in stories of family tech support, corporate over-reliance on one person, and open-source maintainers drowning in expectations.
  • Views split on obligation: some feel deep duty once others rely on their work; others fall back on licenses and boundaries to keep guilt in check.

Broader reflections: software rot, world-weariness, mortality

  • There’s debate over “software rots”: pinned environments and offline, self-contained tools can last a long time, but hardware, protocols, business context, and laws still change.
  • Several tie the essay to stoic or Buddhist-like themes: accepting limits, letting go of unfixable things, and distinguishing where care is actually effective.
  • A few push back, calling the tone melodramatic or just “perfectionism with good prose,” but the dominant reaction is uneasy recognition and a search for healthier balance.