pragmatic-programmer
Skill17 starsChanged 9 months agoMITView on GitHub
Software craftsmanship principles from The Pragmatic Programmer. Use this skill when discussing best practices, debugging strategies, career development, or pragmatic approaches to software development. Auto-activates for DRY violations, debugging sessions, and development workflow improvements.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Adhamxon/claude-code-skillstheir own version, first seen Jul 30, 2026
- wondelai/skillstheir own version, first seen Jul 16, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- wondelai/skills★ 2.6ksame name
- Adhamxon/claude-code-skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- clean-codeSkill
- clrs-algorithmsSkill
- dddSkill
- ddiaSkill
- gof-patternsSkill
- sicpSkill
- software-patternsSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Consider code duplication (DRY)
- Distinctive: line 27
Don't make excuses—provide options
- Distinctive: line 65
Provide Options, Don't Make Excuses: - Don't say it can't be done.
- Distinctive: line 68
Remember the Big Picture: - Don't get so focused you forget what you're doing
- Distinctive: line 71
Critically Analyze What You Read and Hear: - Don't be swayed by vendors or media hype
- Distinctive: line 76
Treat your knowledge like a financial portfolio:
- Distinctive: line 86
Read a technical book each month
- Distinctive: line 87
Read non-technical books too
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
The Pragmatic Programmer Reference
A comprehensive reference for pragmatic software development principles based on "The Pragmatic Programmer" by David Thomas and Andrew Hunt. This skill provides timeless advice for becoming a better developer.
When This Skill Activates
This skill automatically activates when you:
- Discuss software development best practices
- Need debugging strategies
- Consider code duplication (DRY)
- Think about tooling and automation
- Discuss project estimation or planning
- Review development workflows
Core Philosophy
"Care about your craft." "Think about your work."
Pragmatic programmers:
- Take responsibility for their career and work
- Don't make excuses—provide options
- Are agents of change, not victims of circumstance
- Continuously learn and adapt
Quick Reference
Foundational Principles
| Principle | Summary |
| DRY - Don't Repeat Yourself | Every piece of knowledge has a single representation |
| Orthogonality | Keep things independent and decoupled |
| Reversibility | Make decisions reversible; avoid lock-in |
| Tracer Bullets | Get feedback fast with end-to-end skeleton |
| Prototypes | Learn before committing; throw away prototypes |
| Domain Languages | Program close to the problem domain |
| Estimating | Learn to give accurate estimates |
Practical Techniques
| Practice | Summary |
| The Power of Plain Text | Keep knowledge in accessible format |
| Shell Games | Master the command line |
| Debugging | Fix the problem, not the blame |
| Text Manipulation | Learn text processing tools |
| Code Generators | Write code that writes code |
| Design by Contract | Define rights and responsibilities |
| Assertive Programming | If it can't happen, use assertions |
| Decoupling | Minimize dependencies between modules |
| Refactoring | Improve code continuously |
| Testing | Test early, test often, test automatically |
| Automation | Don't use manual procedures |
The Pragmatic Tips
Key tips from the book:
- Care About Your Craft - Why spend your life developing software unless you care?
- Think! About Your Work - Turn off autopilot and take control
- Provide Options, Don't Make Excuses - Don't say it can't be done; explain what can be done
- Don't Live with Broken Windows - Fix bad designs and wrong decisions when you see them
- Be a Catalyst for Change - Show people the future and help them participate
- Remember the Big Picture - Don't get so focused you forget what you're doing
- Make Quality a Requirements Issue - Get users involved in determining quality
- Invest Regularly in Your Knowledge Portfolio - Make learning a habit
- Critically Analyze What You Read and Hear - Don't be swayed by vendors or media hype
- It's Both What You Say and How You Say It - Communication matters
The Knowledge Portfolio
Treat your knowledge like a financial portfolio:
- Invest regularly - Learn something new routinely
- Diversify - Know many different technologies
- Manage risk - Balance safe tech with high-risk/high-reward
- Buy low, sell high - Learn emerging tech before it becomes mainstream
- Review and rebalance - Reassess periodically
Suggestions:
- Learn a new language every year
- Read a technical book each month
- Read non-technical books too
- Take classes
- Participate in local user groups
- Experiment with different environments
- Stay current (newsletters, blogs, conferences)
Communication
- Know what you want to say
- Know your audience
- Choose the right moment
- Choose a style
- Make it look good
- Involve your audience
- Be a listener
- Get back to people
- Documentation is part of the project, not after
Language Translation Notes
Examples use generic pseudocode. Adapt to your language:
- PHP:
class,function,->, type hints - JavaScript/TypeScript:
class, arrow functions,. - Python:
class,def,., type hints - Java/C#: Direct mapping with access modifiers
Based on concepts from "The Pragmatic Programmer: Your Journey to Mastery" by David Thomas and Andrew Hunt.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.