Reinvent the Wheel

What “Don’t Reinvent the Wheel” Is Supposed to Mean

• Many commenters argue the phrase is business-context advice: optimize for time, reliability, and focus, not personal curiosity.
• Others say it’s overused as dogma, often thrown around online without understanding the specific problem or context.
• Several distinguish “reinventing a wheel” (starting from scratch) from “improving a wheel” or building a specialized variant.

Reinventing as a Learning Tool

• Strong agreement that reimplementing existing systems is an excellent way to gain deep insight—“you don’t really understand it until you’ve built it.”
• Debate over whether rewriting from scratch is the “best” way to learn:
  • One side: it’s expensive but uniquely effective.
  • Other side: you can learn progressively via reading, experimentation, and smaller exercises without full rewrites.
• Personal stories: people building their own ML libraries, web servers, schedulers, etc., report major conceptual gains.

Production, Work, and Startups

• At work, reinventing is usually constrained by deadlines, customer value, and runway.
• Common view:
  • Reinvent for core differentiating tech.
  • Reuse for commodity pieces (auth, crypto, date handling, web frameworks).
• Some note extreme NIH in enterprises and startups leading to fragile in-house “wheels” that never reach library quality or maintainability.

Dependencies, Complexity, and Bloat

• A major pro‑reinvention argument is avoiding unnecessary dependencies, transitive bloat, and opaque behavior.
• Examples: pulling huge libraries for trivial use, or frameworks that bring hundreds of packages for simple tasks.
• Suggested middle grounds:
  • Vendor and trim existing libraries.
  • Write small, targeted implementations when the general solution is overkill.
• Crypto is repeatedly cited as a domain where “don’t roll your own” still strongly applies.

When Reinvention Makes Sense

• Niche or tightly scoped problems where general tools are misaligned or overengineered.
• Cases where existing “wheels” encode bad assumptions, poor performance, or unfixable complexity.
• Practice in invention/innovation itself: solving “old” problems builds skill for future novel ones.
• One detailed example describes “delinking” binaries—essentially reversing linkers—to enable new forms of reverse engineering; offered as proof that challenging the standard approach can yield world‑class tools.

Risks and Nuance

• Rewriting often underestimates hidden complexity; many “new wheels” fail on edge cases, security, or long‑term maintenance.
• Chesterton’s Fence is invoked: understand why the old solution exists before tearing it down—but also recognize that some fences were built badly.
• Consensus: reinventing is valuable, but context, stakes, and humility matter; balance curiosity with responsibility.