Sitemap

Site

• Home
• All Guides
• About
• Contact
• Privacy Policy
• Terms of Use

Code Quality & Craft

• Clean Code: What “Clean” Actually Means When You Can't Agree
• Refactoring: Changing the Structure Without Changing the Behavior
• Code Smells: Naming the Problems Before You Can Fix Them
• Technical Debt: A Metaphor That Explains More Than It Should
• The Boy Scout Rule: Small, Constant Improvement vs Big Rewrites
• Naming Things: Why the Hardest Problem in CS Isn't a Joke
• Code Review: What a Good Review Actually Checks For
• DRY vs WET: When “Don't Repeat Yourself” Repeats Itself Into a Mess
• Legacy Code: Working With What You Didn't Write

Software Design & Architecture

• SOLID: Five Letters, Five Habits, One Overused Acronym
• Design Patterns: What the Gang of Four Actually Solved
• A Philosophy of Software Design: Complexity as the Real Enemy
• Coupling and Cohesion: The Two Numbers Architecture Is Built On
• Monoliths vs Microservices: A Trade-off, Not a Verdict
• The Mythical Man-Month: Why Adding People Slows a Late Project Down
• Conway's Law: Why Your Architecture Looks Like Your Org Chart
• Domain-Driven Design: Modeling the Problem Before the Code
• YAGNI: The Discipline of Not Building It Yet

Process, Testing & Delivery

• Continuous Delivery: Shipping Small Changes, Safely, Often
• Test-Driven Development: Writing the Test Before the Code
• The Testing Pyramid: Why Most Tests Should Be the Boring Kind
• Code Freezes and Release Trains: Two Ways to Manage Risk
• Postmortems: Writing Up a Failure Without Assigning Blame
• Feature Flags: Decoupling Deployment from Release
• Pair Programming: What Two People Actually Buy You
• The Cost of a Bug: Why It Gets More Expensive the Later You Find It
• Definition of Done: Making “Finished” Mean Something Specific

Developer Careers & Communication

• The Pragmatic Programmer: Craft Advice That Outlasted Its Examples
• The Clean Coder: Professionalism as a Practiced Skill
• Impostor Syndrome in Engineering: A Common Feeling, Poorly Named
• Writing an RFC: Making a Technical Decision Legible to Others
• Giving Feedback on Someone Else's Code Without Being a Jerk
• The Senior Engineer Question: What Changes Besides the Title
• Saying No to a Deadline: Estimation as a Negotiation Skill
• Mentoring Junior Developers: What Actually Transfers
• Burnout in Software Teams: Recognizing It Before the Sprint Does

Documentation & Developer Experience

• READMEs: The Most-Read File Nobody Budgets Time For
• API Design: Naming, Consistency, and the Cost of a Breaking Change
• Versioning: What Semantic Versioning Actually Promises
• Writing Docs Developers Actually Read
• Error Messages as a Design Surface, Not an Afterthought
• Changelogs: A Small Habit With an Outsized Payoff
• Onboarding a New Developer: What the First Week Should Teach
• Deprecation: Removing Something Without Breaking Everyone
• Developer Experience (DX): Treating Internal Tools Like a Product