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
| 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.