The Worst Programmer I Know (2023)

Tim’s Role and What Managers Should Do

  • Many readers see Tim as a senior IC/tech lead, not a traditional “manager.”
  • There’s debate over what non-technical managers add: some list hiring/firing, performance reviews, prioritization, budgeting, conflict resolution, shielding teams from upper management, and regulatory constraints.
  • Others claim many managers are “MBA fluff,” good only at politics; pushback stresses that tech lead and people manager are full-time, different jobs.

Story Points, Jira, and Goodhart’s Law

  • Thread centers on the danger of judging individuals by story points/tickets.
  • Metrics are repeatedly described as easy to game, distorting behavior and destroying collaboration (“measurement dysfunction,” Goodhart’s/Campbell’s law, McNamara fallacy).
  • Some argue metrics can act as crude tripwires: a zero-score can flag “look closer,” not “fire automatically.”

Gaming, Visibility, and Survival

  • One camp suggests simply crediting Tim on tickets he helps with, or adding sub-tasks/“assists” so his work is legible to management.
  • Critics say this just legitimizes a bogus metric and entrenches a culture where everyone knows the numbers are fake but still optimizes for them.
  • Several people share experiences of being penalized for not playing the metrics game and conclude self‑promotion is necessary in many orgs.

Mentoring, Pair Programming, and Crutches

  • Many see Tim’s behavior (full‑time pairing, unblocking, teaching) as a huge force multiplier and exactly what senior engineers should do.
  • Others think 100% pairing is odd: they’d expect seniors to split between mentoring and owning difficult stories, and worry about teams that are constantly blocked.
  • Some warn that “Tim” can become a crutch for weak engineers or a single point of failure; others describe burnout from always being that person.

Developer Productivity: Measurable or Not?

  • Strong sentiment that individual productivity is incredibly context‑dependent: support work, refactoring, negative LOC, architecture, and knowledge-sharing don’t show up in simple counts.
  • LOC, PR count, and coverage deltas are seen as noisy signals at best; used naively, they reward tactical tornadoes and punish people who simplify or delete code.
  • A minority argues that top devs usually do commit a lot and that low-commit developers are often genuinely low-output, but even they warn against using raw counts as rankings.

Incentives, OKRs, and Organizational Culture

  • Story of individual OKRs tied to compensation destroying cross-team help: people refused to assist because it wasn’t on their personal goals.
  • Consensus that individual, hard‑linked metrics (story points, OKRs) tend to kill “Tims,” discourage mentoring, and turn teams into “lonely islands.”
  • Several conclude that good management, peer feedback, and business outcomes at the team level work better than fine‑grained individual KPIs.