A bunch of programming advice I'd give to myself 15 years ago

Original Article ↗ Hacker News Discussion ↗

Scope and Audience of the Advice

  • Many feel the article’s advice is strong but skewed toward people already working as devs, not absolute beginners.
  • Several argue novices need more concrete, low‑level guidance (write more code, fewer tutorials; don’t over‑optimize; expect to be bad at first).
  • Others say high‑level posts are still useful as “sensitization”: you won’t fully apply them early, but they shorten the learning curve later.

Shipping Fast, “Bad Code,” and Complexity

  • Strong support for prioritizing shipping and learning over perfectionism, especially for juniors; perfection can paralyze.
  • Counterpoint: “stop caring about quality” is seen as dangerous if taken literally; better framing is “aim for clean within constraints and accept imperfections.”
  • The “bad code gives you feedback, perfect code doesn’t” idea resonates with people who struggled with over‑engineering.
  • The heuristic “if you can’t easily explain why something is difficult, it’s incidental complexity” is praised by some, but heavily criticized by others as wrong for genuinely hard problems; risk of blaming yourself instead of recognizing inherent difficulty.

Users, Business Value, and Criticality

  • Broad agreement: users care about outcomes, UX, and performance, not tech stacks or purity.
  • Several contrast “NASA/medical/financial” contexts (where rigor is crucial) with internal tools or low‑risk apps where speed matters more.
  • Some worry that “bugs are fine in 99% of web apps” underestimates hidden user pain when feedback channels are weak.

Learning, Fundamentals, and Experience

  • Repeated themes: less tutorial consumption, more building; reading others’ code is valuable but not a substitute for doing.
  • Many endorse learning fundamentals (data structures, networking, OS, security, Unix, math) and even low‑level concepts, though not necessarily coding in C/asm for a career.
  • Experience with consequences (staying in a role long enough, being on call) is viewed as irreplaceable for forming sound opinions.

Tooling, Editors, and Typing

  • Split views:
    • One camp: deep editor mastery, shell skills, and typing speed are huge long‑term multipliers; “sharpen the axe” pays off.
    • Other camp: endless editor tweaking is disguised procrastination; modern defaults (e.g., VS Code) are “good enough” and thinking dominates typing time.
  • Some nuance: learning a few high‑leverage shortcuts and automation can save years of small delays; diminishing returns after that.

Team Dynamics, Questions, and Org Constraints

  • Many value “ask instead of suffering alone,” but stress showing initiative first (read code/docs 10–30 minutes, then ask specific questions).
  • Fixing bugs “one layer deeper” and investigating history are seen as hallmarks of seniority—but often clash with management pressure for quick patches.
  • Several note that such process improvements only work in organizations willing to change; otherwise, leaving may be the rational choice.

Testing and Design

  • Multiple commenters argue integration and end‑to‑end tests on core flows often provide more real confidence than high unit‑test coverage.
  • Unit tests are seen as essential for core libraries, less so for typical product teams.
  • Simplicity, “dumb” consistent code, and clear data‑first thinking are widely encouraged over clever abstractions and premature design patterns.

Career, Impostor Syndrome, and Wellbeing

  • Impostor syndrome is common; some frame it as natural while you’re still learning, others reject normalizing incompetence in critical domains.
  • Advice recurs to separate identity from job, avoid toxic environments, and prioritize health, family, and life outside code.