Three virtues of a great programmer

Larry Wall’s famous “three virtues” of a programmer—laziness, impatience, and hubris—are revisited as developers debate whether reframing vices as virtues still makes sense today. Commenters argue over the meaning of “hubris,” propose alternatives like curiosity, fear, and pride, and explore how these traits can drive automation, performance, and code quality when balanced properly. Others reflect on how these ideas relate to burnout, communication skills, changing tooling (Perl, Python, Ruby), and the difference between hacking for fun and building maintainable systems in professional environments.

Reframing the Three Virtues

  • Many see “laziness” as a drive to automate tedious work, deliver minimal viable solutions, and avoid overcomplication; for some, this has become their best professional trait.
  • “Impatience” is linked to wanting faster build/test cycles and more performant systems, but others see it as overlapping with laziness rather than distinct.
  • “Hubris” is the most contested: interpretations range from pride in one’s work, wanting code others won’t criticize, or believing one can push beyond standard “don’t roll your own” rules, to seeing it as destructive arrogance that rejects valid criticism.

Alternative or Supplementary Virtues

  • Suggestions include: curiosity (as the driver of learning and improvement), fear of complexity (to restrain hubris), hesitation (careful upfront design), stupidity/forgetfulness (motivating tests, types, and documentation), discernment, wisdom, humility, and communication skills.
  • Some argue the original framing as “vices turned virtues” is rhetorically important; others prefer more conventional positive terms.

Design, Rewrites, and YAGNI

  • One view: more time spent on planning and discussion would avoid costly rewrites caused by incomplete initial designs.
  • Counterpoint: hindsight and survivorship bias; you can’t get it perfectly right up front, so favor simple designs, reversible decisions, and refactoring over “comprehensive” upfront architecture.
  • YAGNI is emphasized: avoid building for speculative future requirements, but beware “naively simple” designs that block growth.

Work Habits, Burnout, and Motivation

  • Overwork framed as a genuine weakness, contributing to burnout and health issues; some differentiate “working hard” from “spending a lot of time” and point to work meaning and personal traits as factors.
  • Several comments note that loving coding leads some to keep programming after hours; others push back on unpaid corporate overtime.

Perl, History, and Other Languages

  • Discussion recalls how these virtues fit Perl’s culture: powerful, terse, good for automation, often used by non-“official” programmers.
  • Perl is criticized as “write-only” and undisciplined; some describe replacement in practice by tools like awk/sed, Tcl, Ruby, and Python.
  • Python is praised for ubiquity and scripting convenience, but also criticized as enabling a large volume of poor-quality code.

Communication and Meta-Discussion

  • Programming is framed as fundamentally about clear written communication; mastery of language (any tongue) is seen as strongly correlated with good programming.
  • Classic interview questions about strengths/weaknesses are mocked; glib “virtues as flaws” answers are seen by some as red flags.
  • Giving advice online is viewed as risky because it attracts criticism, though this can also surface better approaches.