masterbriefs
0Read Progress 97 Things Every Programmer Should Know 15 15 min left
Programming ⏱️ 15 15 min read
97 Things Every Programmer Should Know

97 Things Every Programmer Should Know

by Kevlin Henney
97 Things Every Programmer Should Know 🎙️ Studio Voice · Kokoro
0:00 --:--

FOUNDATIONAL THESIS

Software engineering suffers from a perpetual amnesia where each generation of developers relearns the same painful lessons through production failures.

Kevlin Henney curated essays from dozens of industry veterans to capture timeless truths that transcend specific programming languages, frameworks, or temporary technology fads.

The central paradox of programming is that simple solutions are extraordinarily difficult to design, while complex solutions happen by default through undisciplined additions.

This Executive Masterbrief distills those 97 insights into 8 foundational pillars of elite software craftsmanship, giving you the mental models required to build resilient systems and lead high-performing technical teams.

Code for the Human Reader

Optimizing clarity over cleverness

Source code is fundamentally a communication medium directed at other human beings, with execution by a machine being merely a secondary byproduct.

When you write code, you are having a asynchronous conversation with the maintainer who will debug it at 3 AM.

Code is read much more frequently than it is written, so plan accordingly.

Clever, dense one-liners might stroke the ego of the original author, but they impose an insurmountable cognitive tax on everyone else. Professional developers optimize for readability by making intent transparent and minimizing extraneous mental load. You must treat naming, formatting, and structural simplicity as first-class architectural concerns rather than cosmetic afterthoughts.

  • Intentional Naming: Choose descriptive, domain-aligned names that reveal intent without requiring inline comment translation.
  • Cognitive Reduction: Break down nested conditionals and complex boolean logic into self-documenting extracted methods.
  • Style Consistency: Subordinate personal stylistic preferences to the established idioms and conventions of the collective codebase.
  • Explicit Boundaries: Clearly delineate data structures and functional transformations so the reader can trace execution flow intuitively.

Simplicity and the Enemy of Complexity

Resisting the gravitational pull of over-engineering

Complexity enters codebases incrementally, disguised as future-proofing, flexibility, or architectural sophistication.

Left unchecked, this accidental complexity suffocates development velocity and turns routine maintenance into high-risk engineering.

Everything should be made as simple as possible, but not simpler.

Resist the urge to build generalized frameworks when a concrete, specific solution will suffice for current requirements. True architectural mastery is demonstrated by subtraction and simplification rather than the accumulation of clever abstractions. If a requirement does not exist today, do not pay the compounding interest on code designed to support it.

  • YAGNI Principle: Refuse to implement features or abstractions until they are strictly required by current business use cases.
  • Abstraction Audit: Regularly evaluate existing abstractions to ensure their operational benefit outweighs their maintenance overhead.
  • Direct Solutions: Favor straightforward, procedural code over deeply layered object hierarchies when domain logic is simple.
  • Refactoring Discipline: Treat the removal of dead or redundant code as an essential part of keeping systems lean.

Testing as a Design Driver

Using automated verification to shape architecture

Automated tests are frequently misunderstood as a quality assurance gate applied at the end of a development cycle.

In elite engineering cultures, tests act as a primary design instrument that exposes tight coupling, hidden side effects, and poor modularity.

If code is difficult to test, it is a glaring symptom of flawed architectural design.

Writing tests before or alongside implementation forces you to consume your own APIs from an outsider's perspective. When an interface requires complex mocking setups, it tells you immediately that your dependencies are too entangled. Embrace test-driven workflows to ensure your codebase remains decoupled, modular, and structurally resilient against regressions.

  • Test-First Perspective: Write unit tests to clarify expectations and validate interface usability prior to implementation.
  • Coupling Detection: Treat test setup friction as a direct diagnostic signal indicating excessive dependencies.
  • Regression Immunity: Build a comprehensive test suite that acts as a safety net for fearless refactoring and continuous delivery.
  • Behavioral Focus: Test observable outputs and behaviors rather than internal implementation details to ensure test resilience.

Domain Modeling and Language Alignment

Bridging business reality and technical implementation

Software fails when there is a translation gap between how domain experts talk about a business problem and how developers model it in code.

Aligning your code's vocabulary with the real-world business domain eliminates ambiguity and prevents catastrophic misunderstandings.

The limits of your language mean the limits of your world, both in natural speech and software architecture.

When your data structures, methods, and variables use the exact terminology of the business domain, the code becomes self-documenting for non-technical stakeholders. Ubiquitous language transforms code from a collection of technical primitives into a living model of the business domain. Avoid technical jargon in domain layers and ensure your abstractions mirror real-world workflows.

  • Ubiquitous Vocabulary: Adopt the exact terminology used by business stakeholders throughout your domain models and APIs.
  • Domain Purity: Keep business logic completely decoupled from database schemas, UI frameworks, and external transport protocols.
  • Bounded Contexts: Explicitly define the boundaries within which specific domain models and terms are valid and consistent.
  • Model Evolution: Refine domain models continuously as deeper insights into the business requirements emerge.

Continuous Refactoring and Technical Debt

Maintaining structural integrity over time

Codebases are subject to digital entropy, where minor design compromises accumulate into systemic decay if left unaddressed.

Refactoring is not a special project or a reward for finishing features; it is an ongoing, daily hygiene practice.

Leave the campground cleaner than you found it whenever you touch legacy code.

Introducing technical debt is sometimes a rational tactical compromise to hit a critical market deadline. The fatal mistake is failing to pay down that debt through deliberate, scheduled refactoring before it incurs crippling interest. Cultivate a culture where code improvement is woven into every pull request and feature ticket.

  • Boy Scout Rule: Always leave every file, module, and class slightly better structured than you found it.
  • Incremental Improvement: Refactor in small, safe, continuous steps backed by automated test verifications.
  • Debt Tracking: Make technical debt transparent and prioritize its repayment alongside new product feature development.
  • Root Cause Analysis: Address the systemic causes of architectural decay rather than just patching recurring symptoms.

Error Handling and Defensive Robustness

Expecting failure and failing gracefully

Systems operating in production will encounter hardware faults, network partitions, malformed inputs, and cascading dependencies.

Robust software does not pretend failures will not happen; it anticipates them and handles them with surgical precision.

Hope is not a strategy, and exceptions should represent genuinely exceptional circumstances.

Using return codes or catching generic exceptions masks underlying system faults and obscures failure modes. Robust error handling requires failing fast, providing actionable context, and protecting system boundaries from corruption. Design your error pathways to be just as clean, tested, and reliable as your happy paths.

  • Fail Fast: Detect and reject invalid states and malformed inputs at system boundaries before they propagate.
  • Contextual Errors: Wrap and enrich exceptions with relevant debugging context without exposing sensitive internal state.
  • Exception Discipline: Reserve exceptions for true, unexpected anomalies rather than expected operational branching logic.
  • Graceful Degradation: Design systems to degrade functionality gracefully when downstream dependencies experience outages.

Collaboration, Ego, and Team Dynamics

Building psychological safety and collective ownership

Software engineering is fundamentally a team sport where human communication bottlenecks dwarf technical challenges.

Elite technical execution requires dropping personal ego, embracing peer review, and fostering radical psychological safety.

You are not your code, and criticism of your implementation is never a personal attack.

Code ownership should be collective across the team rather than siloed within individual developers who guard their turfs. Peer reviews and pairing sessions are powerful alignment mechanisms that elevate team capability and eliminate single points of failure. Cultivate an environment where asking questions, admitting mistakes, and sharing knowledge are celebrated norms.

  • Collective Ownership: Eliminate individual code silos by encouraging cross-team contributions and shared codebases.
  • Empathetic Reviews: Conduct code reviews with kindness, focusing on objective principles rather than subjective style preferences.
  • Psychological Safety: Foster an environment where team members can admit ignorance and surface risks without fear of retribution.
  • Knowledge Sharing: Actively mentor peers and document architectural decisions to prevent knowledge concentration.

Professionalism, Ethics, and Continuous Learning

Treating software engineering as a disciplined craft

As software permeates every critical facet of modern infrastructure, healthcare, and finance, the ethical responsibilities of programmers increase exponentially.

Professionalism means taking personal responsibility for the quality, security, and societal impact of the systems you build.

Professionalism is defined by doing the right thing even when no one is watching.

Technology evolves at a relentless pace, rendering static skillsets obsolete within a few short years. A true professional commits to lifelong learning, continuous self-auditing, and uncompromising ethical standards. Never ship code you know is dangerously fragile simply because management failed to understand the technical risks.

  • Ethical Responsibility: Evaluate the privacy, security, and societal implications of the software systems you design and deploy.
  • Lifelong Learning: Dedicate consistent time to studying foundational computer science principles, new patterns, and emerging tools.
  • Risk Transparency: Communicate technical risks and trade-offs clearly and honestly to non-technical stakeholders.
  • Craft Pride: Take pride in disciplined execution, clean architecture, and rigorous testing standards.

Executive Synthesis & Monday Morning Action

The collective wisdom of Kevlin Henney’s contributors reveals that software engineering is ultimately an exercise in human communication, discipline, and empathy.

The technical tools and languages we use will inevitably change, but the core challenges of managing complexity, writing readable code, and collaborating effectively remain constant.

Mastery is not achieved by memorizing syntax or adopting the newest framework, but by internalizing timeless principles of simplicity, testing, and professional responsibility.

By treating code as a medium for human collaboration and prioritizing architectural clarity over cleverness, you insulate your systems against decay and position yourself as an elite engineering leader capable of delivering enduring value.

STAGE 2: ACTIVE RECALL 3-Minute Practical Drill
Check What Stuck

97 Things Every Programmer Should Know Knowledge Check

Test your mastery of the core principles.

Question 1 of 4
According to the principles of readable code, why is source code written?
Explanation: Code is read far more often than it is written, making human communication and readability its primary purpose.
Question 2 of 4
What is the primary architectural diagnostic value of automated testing?
Explanation: When code is difficult to test, it signals that dependencies are tangled and modularity is poor.
Question 3 of 4
How should technical debt be managed in a professional software engineering lifecycle?
Explanation: Technical debt must be managed through continuous refactoring and scheduled repayment to prevent crippling interest.
Question 4 of 4
What defines true professional responsibility in software engineering?
Explanation: Professionalism requires uncompromising standards in quality, ethics, and honest communication of technical trade-offs.
STAGE 3: EXECUTIVE EXECUTION Action Worksheet
Put One Idea To Work

97 Things Every Programmer Should Know Action Plan

Design a specific system you can start today.

1

Baseline Audit

Audit your current codebase for readability bottlenecks, complex abstractions, and tight coupling.

Auto-saved
2

Friction Point Elimination

Identify the top 2 sources of technical debt or testing friction currently slowing down your team.

Auto-saved
3

Implementation Protocol

Define the daily or weekly cadence for applying the Boy Scout Rule and refactoring during pull requests.

Auto-saved
⚡

Your Immediate Next Action

Declare the single immediate physical action you commit to taking today.

Auto-saved
Implementation Card

97 Things Every Programmer Should Know — Implementation Card

Masterbriefs Action
Fill in the steps above to generate your customized action card.
EXECUTIVE FAQ & SEARCH INTELLIGENCE

Frequently Asked Questions: 97 Things Every Programmer Should Know

What is the core thesis of 97 Things Every Programmer Should Know? +

An executive analysis and summary of 97 Things Every Programmer Should Know by Kevlin Henney.

What are the key takeaways and chapter frameworks? +
Can I download the 1-page executive summary PDF? +

Yes, this Masterbrief includes a structured, high-resolution 1-page executive printable PDF containing all core pillars, mental models, and implementation worksheets.