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

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.