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
| Principle | One-liner |
|---|---|
| Simplicity | Remove everything unnecessary; less is more |
| Boy Scout | Leave code cleaner than you found it |
| DRY | Single authoritative representation for each piece of knowledge |
| SRP | One reason to change per class/module/function |
| Comments | Comment only what code cannot say - explain why, not what |
| Tech debt | Pay immediately or track the compounding interest |
| Testing | Non-negotiable professional obligation |
| Errors | Always check, always handle, every time |
| Next commit | Know exactly what you're committing before you start |
| Users | You are not the user - observe, don't assume |
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.