You're not a senior engineer until you've worked on a legacy project (2023)

Original Article ↗ Hacker News Discussion ↗

What Counts as a “Legacy Project”

  • Many note that “all successful projects become legacy,” but disagree on when that label applies.
  • Heuristics mentioned: no original authors remain; stack/language used nowhere else in the company; migration cost is enormous; outdated practices and little/no tests or docs.
  • Some use a stricter definition: legacy is code without automated tests; others emphasize accreted special cases and fear of changing it.
  • Distinction is drawn between merely “existing code” and true legacy with high coupling, age, and organizational baggage.

Legacy Work and Seniority

  • Common view: you’re not really senior until you’ve worked deeply on legacy code, especially under constraints (time, risk, business dependence).
  • Stronger claim: the real step-change is maintaining your own code as it ages, seeing your past design decisions fail in production, and then doing a second system without overcorrecting.
  • Counterpoint: seniority also requires greenfield experience—choosing technologies, designing for availability, avoiding over‑complexity. “Bit of everything” is seen as ideal.
  • Several criticize title inflation and gatekeeping; “senior” in job ads often just means a few years’ experience.

Why Legacy Work Matters

  • Legacy systems often carry the “river of money” and hardest production constraints; careers are “made” here.
  • Working on them builds:
    • Understanding of real-world tradeoffs and historical constraints.
    • Empathy for previous teams (vs reflexively disparaging “shitty code”).
    • Appreciation that v1 always has flaws and that rewrites usually repeat old mistakes.
  • Watching a greenfield system turn into legacy is seen as the best teacher of cause and effect in architecture.

Pain Points and Risks

  • Slow, mentally taxing debugging in poorly tested, poorly documented, sometimes decades‑old code (VB6, Fortran, COBOL, weird build chains, etc.).
  • Organizational issues: separate ops/QA, ticket handoffs, long lead times, little authority to change infrastructure.
  • Career risk: becoming the sole expert can be a moat or a trap—easier to cut a “cost center” than fund modernization.
  • Greenfield rewrites that fail or coexist indefinitely with old systems are cited as common, expensive anti‑patterns.

Effective Approaches and Mindsets

  • Recommended attitudes: curiosity, humility, asking “why” (Chesterton’s Fence), not defaulting to rewrites or trendy stacks.
  • Tactics: add tests around fragile areas; refactor incrementally; respect existing conventions; avoid drive‑by framework changes for résumé padding.
  • Some argue that real seniority includes the courage to change risky legacy code and the judgment to do only what’s safe and necessary while keeping the business running.