Clever code is probably the worst code you could write (2023)

Original Article ↗ Hacker News Discussion ↗

Meaning of “clever code”

  • Often used to mean dense, non-obvious, or “code-golfy” solutions.
  • Several argue cleverness is relative to familiarity: what’s opaque to one team can be mundane to another.
  • Distinction proposed between:
    • Smart code: simple, clear, efficient, easy to read.
    • Clever code: tricky, surprising, reliant on uncommon language features or invariants.

Seniority, incentives, and job security

  • Common trope: juniors write naive/simple, mids write clever, seniors return to simple.
  • Some attribute mid-level cleverness to survival incentives (e.g., job security, visas), others to overconfidence and excitement about new techniques.
  • Seniors report avoiding “new hotness” after being burned during on-call incidents; they favor YAGNI, duplication over over-abstract reuse, and early exits over elaborate recovery.

Language idioms and readability debates

  • Big subthread on loops vs higher-order functions (e.g., for vs std::accumulate/reduce, JS for vs forEach, Python loops vs list comprehensions, C# LINQ .Sum(), Rust iter().sum()).
  • Some prefer explicit loops as universally recognizable; others see standard algorithms/comprehensions as clearer once idiomatic in that ecosystem.
  • Python, Ruby, FP style, and metaprogramming are seen as especially prone to “too clever” one-liners and magic; others say these are fine when used idiomatically and sparingly.

Performance vs clarity

  • Disagreement over whether functional/iterator style is faster or slower; examples show engine- and implementation-specific results.
  • C++ std::reduce vs accumulate discussed: potential for vectorization vs floating-point pitfalls.
  • Several note compilers often transform both “simple” loops and higher-order wrappers into similar optimized code.

Abstraction and where cleverness belongs

  • Widely accepted: deep cleverness is appropriate inside well-documented, well-tested abstractions (DB engines, allocators, kernels), not scattered through business logic.
  • Good abstractions can be “poem-like”: simple at the surface, with deeper power revealed later (Git cited).

Maintainability, debugging, and style discipline

  • Kernighan’s law repeatedly invoked: debugging clever code is harder than writing it.
  • Cleverness tolerated only with heavy comments, docs (“here be dragons”), tests, and clear interfaces.
  • Tools and linters (e.g., favoring comprehensions or ternaries) can push toward certain “clever” idioms; some welcome this, others resist on readability grounds.

Process, culture, and management

  • Hiring for timed puzzles is criticized as selecting for puzzle-solvers over pragmatic engineers.
  • Education and community norms strongly shape what’s seen as “simple”.
  • The article’s manager, who penalized simple-looking code and wanted visible complexity for performance reviews, is viewed as especially dangerous.