40 Years of Programming

Longevity and Joy in Programming

  • Many commenters report 30–50+ years of coding, from early home computers (C64, ZX Spectrum, Tandy, Amiga) to modern web and backend work.
  • A large subset still code daily and genuinely enjoy it, some even nearing or after retirement.
  • Others feel burnt out by modern “software development” culture despite still liking low-level or embedded work.

Impact of Experience on Skills and Hiring

  • Long experience is seen as valuable mainly for judgment: knowing what not to do, being able to explain tradeoffs, and reading unfamiliar code quickly (including one’s own old code).
  • Some report that by 50s, deep expertise often makes them hard to fire and opens consulting opportunities.
  • Others describe difficulty getting hired due to ageism and tech-stack fetishism, despite broad backgrounds.

Career Paths, Management, and Money

  • Several mid/late-career devs consciously avoid management or top “staff” levels to keep hands-on coding and reduce meetings and stress.
  • Some describe leadership roles as emotionally costly, with burnout and constant context-switching.
  • Discussion of pay bimodality: sub‑$100k vs $200k+; factors cited include FAANG vs other employers, geography/cost of living, and whether one optimizes for money vs joy of coding.

Evolving Technology and Practice

  • One major change noted: shift from shrink‑wrapped software to 24/7 services with on‑call and continuous updates.
  • Views differ on how much “programming itself” has changed; fundamentals and abstraction skills are seen as stable, while frameworks and paradigms churn.

Code Simplicity, Complexity, and Maintenance

  • Strong agreement that “simple, obvious” production code is hard to achieve; complex code is easy to write and easy to get wrong.
  • Veterans are frequently tasked with rescuing scary legacy code nobody else dares touch.
  • Many emphasize writing for “future me” with clear structure and documentation.

Solo vs Team Work

  • Debate over whether “interesting and significant” software must be built by teams.
  • Some argue most modern significant systems require teams; others cite historical and modern one‑ or two‑person successes (including games) and expect tools/LLMs to expand solo capability.

Meetings, Communication, and Process

  • Multiple stories of dysfunctional meetings: no notes, no decisions, large groups, and wasted time.
  • Some responders deliberately take and share concise notes or live-edit shared documents to align understanding.
  • A side thread ties “useless jobs/meetings” to arguments for universal basic income.

Diversity and Culture

  • The article’s stance on human rights and diversity sparks debate.
  • Some see a tension between embracing diversity and declaring certain moral views non‑negotiable; others think prioritizing basic human rights is compatible with diverse perspectives.

Broader Reflections

  • Several reflect on software’s growing societal impact, feeling that it increasingly controls rather than supports people.
  • Despite frustrations, many express gratitude for a lifelong, creative career in programming.