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

Original Article ↗ Hacker News Discussion ↗

Many developers argue that “clever” code—dense, highly abstract, or hyper-optimized implementations—is often harder to understand, debug, and maintain than simple, straightforward solutions. Commenters contrast the instincts of juniors, mid-levels, and seniors, highlight how language features (like list comprehensions, lambdas, or metaprogramming) can encourage or hide complexity, and note that what counts as “clever” is highly dependent on experience and ecosystem norms. Several point out that organizational incentives and performance reviews can perversely reward complexity, even though long-term reliability and team productivity benefit most from clear, boring code with carefully isolated pockets of necessary sophistication.

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.