97-dev: Programmer's Wisdom

Distilled principles from 97 Things Every Programmer Should Know. Apply when writing, reviewing, or making design decisions.

Core Philosophy

Code is design. Software development is a creative discipline requiring craftsmanship, not mechanical construction.

The code tells the truth. Documentation lies, comments decay - only executable code reveals actual behavior. Make code self-explanatory.

Care about your code. Excellence stems from attitude, not just knowledge. Craft elegant code that is clearly correct.

Quick Principles

Detailed References

Load these when you need deeper guidance on specific topics:

references/simplicity.md

When: Refactoring bloated code, making architectural decisions, deciding what to remove, questioning if features are needed. Covers: Beauty in simplicity, reduction over addition, improving by removing, code as design.

references/quality.md

When: Code review, enforcing standards, improving maintainability, designing APIs and interfaces. Covers: Boy Scout Rule, DRY principle, Single Responsibility, interface design, code as truth.

references/professionalism.md

When: Career decisions, team dynamics, handling pressure, technical debt discussions, attitude check. Covers: Professional responsibility, caring about code, long-term thinking, prudent debt management.

references/testing.md

When: Writing tests, handling errors, debugging issues, arguing for test coverage, writing comments. Covers: Testing as engineering rigor, error handling discipline, debugging strategy, comment guidelines.

references/learning.md

When: Professional development, skill building, code reading sessions, understanding complexity limits. Covers: Continuous learning strategies, deliberate practice, reading code, knowing your limits.

references/workflow.md

When: Planning work, commit strategy, user research, daily development practices. Covers: Know your next commit, you are not the user, version control practices, breaking things safely.

Checklist

Writing code:

• Single responsibility per function/class?
• Any duplication to extract?
• Anything removable without losing functionality?
• Names descriptive enough to skip comments?
• Would I maintain this for years?

Reviewing code:

• Leaves codebase cleaner?
• Error cases handled?
• Interface easy to use correctly?
• Matches existing patterns?

Debugging:

• Ruled out my own code first?
• Isolated problem systematically?
• Testing assumptions, not seeking confirmation?

Source

97 Things Every Programmer Should Know - O'Reilly, Creative Commons.