Go ahead, write the “stupid” code

Value of “stupid” code for learning and progress

• Many commenters resonate with starting with simple, even “bad” code to:
  • Break paralysis and get momentum.
  • Expose wrong assumptions and refine mental models.
  • Learn new runtimes/languages (e.g., Deno, TypeScript) via small, throwaway projects.
• Several liken it to exercises or rehearsal: you’re not trying to write production-grade systems, you’re training your intuition and skills.
• Personal stories (kernel hacking, editors, hobby tools) emphasize joy, ownership, and deep learning over immediate utility or elegance.

“Stupid” vs truly bad code

• Some push back strongly on “there is no stupid code,” saying:
  • Truly awful code exists (e.g., cargo-culting keywords, ignoring edge cases, nonsensical abstractions).
  • It matters a lot when that code ships to production and others must maintain it.
• A recurring distinction:
  • “Stupid code” as exploratory, for yourself or early prototyping, is fine—even encouraged.
  • “Stupid code” as permanent production code is harmful, especially when authors move on and others inherit the mess.

Make it work / right / fast

• Many endorse an iterative pattern:
  • Get it working first (even if hacky).
  • Then improve structure, naming, architecture.
  • Optimize performance only when needed.
• Others warn that “optimization pass later” can be a myth:
  • Serious performance issues often require re-architecture, not small tweaks.
  • Low-level or performance-critical domains may need design thinking earlier.

Prototyping vs over-planning

• Strong criticism of “planning theatre”: weeks of tickets and diagrams before writing code can:
  • Bake in wrong assumptions.
  • Delay the feedback that only running code provides.
• Counterpoint: some up-front design is crucial for:
  • Core protocols, APIs, and shared services that are expensive to change.
  • Communicating progress and risk to management.
• Several advocate a blend:
  • A shared but rough mental model, quick prototypes as part of planning, and willingness to rewrite.

Tooling, compilers, and LLMs

• One thread notes that naïve “simple” code sometimes produces poor machine code, and LLMs can help generate more optimized patterns (e.g., SIMD).
• Kernighan’s “debugging is harder than writing” is invoked:
  • Overly clever or opaque solutions (including LLM-generated ones) can be hard to debug.
  • Cleverness should be used to make code easier to verify, not harder.