After 14 years in the industry, I still find programming difficult
Even after decades of experience, many developers say programming remains mentally exhausting—not because of syntax or algorithms, but because of growing system complexity, shifting requirements, and the need to continually learn new tools and domains. Commenters draw a sharp line between “writing code,” which often does get easier, and software engineering as a whole, which includes modeling fuzzy problem domains, integrating with brittle systems, and navigating office politics and process overhead. Opinions range from those who still find the craft intrinsically fun and rewarding to others who feel increasingly burned out, but most agree that the real difficulty lies in managing complexity and working effectively with other people, not in typing code.
Is programming “hard” or “easy”?
- Many agree programming remains mentally exhausting even after decades; difficulty shifts rather than disappears.
- Others say coding itself is easy or enjoyable; the hard part is everything around it (systems, people, process).
- Some report it feels harder now because they see more failure modes and complexity than when they were junior.
- A minority claim it’s mostly easy if you’re naturally inclined and/or stay within familiar problem domains.
What actually makes it hard
- Managing complexity: large codebases, deep abstraction layers, distributed systems, kernels, state machines, mission‑critical domains.
- Poor or shifting requirements, fuzzy problem domains, and discovering you’re building the wrong thing.
- Integrations with unstable or badly designed APIs and legacy systems.
- Understanding and safely modifying old, undocumented, or “hot” code paths.
Career progression & challenge level
- As experience grows, work tends to move toward gnarlier, less-defined, higher-impact problems.
- Some embrace this continuous challenge; others caution that pursuing “LeMond-style” constant difficulty leads to burnout and needs pacing.
- A recurring theme: you can and should sometimes choose “zone 2” work where things are comfortably easy.
Tools, languages, and modern stacks
- Tools and languages are more expressive and beginner‑friendly, but overall stacks feel more bloated and fragile.
- Environment setup, slow or flaky builds/tests, and complex deployment pipelines are cited as major pain points.
- Rapid churn in frameworks, mobile APIs, and AI tooling makes “keeping up” exhausting for many.
Organizational and “soft” factors
- Office politics, management churn, meeting load, process overhead (JIRA, OKRs, TPS reports), and dysfunctional architectures often dominate the difficulty.
- “Soft skills” (often relabeled “professional skills”)—communication, requirements discovery, stakeholder management—are described as crucial and hard-won.
- Large-team coordination, context switching, and mentoring weaker engineers are repeatedly named as draining.
Quality, correctness, and “good code”
- Good code is described as understandable (to future readers and to the author), close to the problem domain, and correct.
- Many emphasize that correctness is under-valued; we normalize shipping systems with latent defects.
- Code quality is heavily shaped by evolving requirements and organizational history, not just technical choices.
AI’s role
- Several see AI as only marginally affecting their day; code is a small part of the job.
- Others imagine AI handling meetings or acting as agents, but note the real bottlenecks are human and organizational, not typing speed.