What 10k Hours of Coding Taught Me: Don't Ship Fast

Ship Fast vs. Move Slowly

• Strong split in views: some argue “ship fast” is crucial for learning, finding product–market fit, and building developer skill via tight feedback loops.
• Others stress that fast shipping often leaves long-lived messes, especially in stable domains or where failure is costly (infra, safety‑critical systems, hard‑to-update environments).
• Several comments suggest pace should depend on context: risk of being wrong, domain maturity, and how hard updates are to deploy.

Refactoring and When to Do It

• One camp endorses “tidy first”: refactor early and continuously to keep change cheap and codebases sane.
• Another warns against heavy upfront refactoring or architecture before requirements are understood; premature abstractions can add constraints and waste time.
• A middle view: let “cut points” emerge from real use, then refactor incrementally.

Architecture, Abstractions, and Simplicity

• Skepticism toward elaborate service/repository patterns and generic interfaces when they outgrow real needs or become dumping grounds.
• Multiple commenters praise deleting code and favor minimal, clear implementations over scaffolding-heavy designs.
• Core heuristic: battle unknown future requirements by staying simple and decoupled, not by predicting everything.

APIs, Infrastructure, and Stability

• Consensus that public APIs and core infra warrant more upfront thought than internal UI code. Backward-incompatible changes are expensive.
• However, infrastructure should still be easy to change; “move thoughtfully but still ship often” is a recurring theme.

Technical Debt, Business Reality, and Risk

• Technical debt compared to financial debt: some is necessary and even advantageous; too much is crippling.
• Startups and “built to sell” companies often prioritize survival and growth over purity, expecting to refactor later—though “later” often never comes.
• High-risk domains (money, data loss, safety) are highlighted as needing more careful, slower development.

Developer Workflow: Tooling, Testing, and WIP

• Debate over pre-commit hooks: some see them as guardrails, others as barriers to saving WIP and collaborating on broken tests.
• Preference from several: test on push or before merge; allow messy local history, then clean it up before integration.

UX Changes and Work Environment

• Frequent UI churn is widely criticized; once a product is mature, constant “refreshes” that don’t add clear value alienate users.
• Several posts emphasize “thinking time” (walking, hammock time, away from the keyboard) as crucial to better designs, and note that office culture often misreads this as not working.