smithery.ai

97-dev

Apply timeless programming wisdom from "97 Things Every Programmer Should Know" when writing, reviewing, or refactoring code. Use for design decisions, code quality checks, professional development guidance, testing strategies, and workflow optimization.

First seen Apr 17, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,907 B
  • docs SUMMARY.md 268 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

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