What "The Software Craftsman" Taught Me About Responsibility and Hiring

Some books teach you new techniques. Others change how you think about your work entirely.

"The Software Craftsman" by Sandro Mancuso did the latter for me. It's not a book about design patterns or architecture. It's a book about attitude — how you approach your craft, how you take responsibility for your work, and what separates developers who just write code from developers who genuinely care about what they build.

Two ideas from this book stuck with me and changed how I work: the concept of radical ownership over your code, and a different way of evaluating developers when I unexpectedly found myself needing to hire.

Stop Pointing Fingers

Early in my career, I was good at finding reasons why problems weren't my fault.

The requirements were unclear. The deadline was unrealistic. The previous developer left a mess. The client kept changing their mind. The framework had limitations. The team didn't follow best practices.

All of these things were often true. And none of them helped me become a better developer.

Mancuso's book reframes this completely. The craftsman mindset says: before you point fingers at anyone else, look at yourself first.

The requirements were unclear? Did you ask clarifying questions? Did you push back before starting? Did you document your assumptions and get confirmation?

The previous developer left a mess? What are you doing to improve it? Are you leaving the code better than you found it, or are you just adding to the mess while complaining about it?

The client kept changing their mind? Did you communicate the cost of changes? Did you help them understand tradeoffs? Did you build in a way that accommodates change?

This isn't about taking blame for everything. It's about recognizing that in almost every situation, there's something you could have done differently. Focusing on that — the part you control — is how you actually improve.

The Mirror Test

I started applying what I call the "mirror test" to problems I encountered.

Before complaining about a situation, I'd ask myself: what's my role in this? What could I have done to prevent it? What can I do now to fix it?

Sometimes the answer is genuinely "nothing" — some situations are outside your control. But more often than I'd like to admit, there was something. A conversation I avoided. A shortcut I took. A question I didn't ask. A refactoring I postponed.

This sounds harsh, but it's actually liberating. If the problem is always someone else's fault, you're powerless. If you can find your part in it, you have agency. You can do something.

The craftsman doesn't wait for perfect conditions. They work to create better conditions, starting with their own behavior.

Legacy Code Is Not an Excuse

One section of the book hit particularly hard: the discussion about legacy code.

It's easy to complain about legacy code. Everyone does it. "This codebase is a disaster." "Who wrote this garbage?" "We need to rewrite everything."

Mancuso's perspective: legacy code is an opportunity, not an excuse.

Every time you touch legacy code, you have a choice. You can add your feature in the quickest, messiest way — matching the existing chaos. Or you can leave that corner of the codebase a little better than you found it.

Write a test for the function you're modifying. Extract a method to make the logic clearer. Rename a variable so the next person understands it faster. Small improvements, compounded over time.

The developers who complain about legacy code while making it worse are not craftsmen. The developers who quietly, consistently improve what they touch — they're the ones who actually make codebases better.

I've tried to adopt this mindset. Not heroic rewrites, but consistent small improvements. Every PR leaves the code slightly better. Over months and years, this adds up.

When I Had to Interview (Without Much Experience Doing It)

I'm not someone who interviews developers regularly. But I found myself in a situation where I needed to.

I was team lead on a fast-paced delivery project. We needed to bring in developers who could hit the ground running — no time for lengthy onboarding, no room for someone who'd need hand-holding through the codebase.

The typical interview approach wasn't going to cut it. Asking about frameworks and running through coding challenges might tell me if someone knew Laravel, but it wouldn't tell me if they could jump into an existing project under pressure and actually deliver.

This is where "The Software Craftsman" helped me think differently about what to look for.

What Mattered for a Fast-Paced Project

When you need someone to contribute quickly, technical skills are table stakes. Everyone we interviewed could code. The differentiator was attitude and approach.

Ownership mentality. When candidates talked about past projects, I listened for how they described problems. Did they take responsibility for outcomes? Or was every failure someone else's fault? In a fast-moving project, I needed people who'd own their work, not people who'd spend time explaining why blockers weren't their problem.

Comfort with ambiguity. Our project didn't have perfect specs or complete documentation. I asked about times they'd worked with unclear requirements. The best answers came from people who'd figured things out, asked the right questions, made reasonable assumptions — not people who'd waited for someone to hand them perfect instructions.

Legacy code attitude. We had existing code. Some of it wasn't pretty. I asked candidates how they'd handled messy codebases before. The ones who talked about incremental improvement — leaving code better than they found it — those were the ones I wanted. The ones who only talked about rewrites and complaints? Red flag.

Honesty about limitations. I asked about technologies they weren't familiar with. The candidates who could say "I don't know that, but here's how I'd learn it" were more trustworthy than the ones who pretended to know everything. In a fast project, I needed people who'd ask for help when stuck, not people who'd spin their wheels silently.

The Questions That Helped

A few questions that revealed what I needed to know:

"Tell me about a project where you joined mid-stream. How did you get up to speed?"

This directly tested what I needed. Some people described systematic approaches — reading code, asking targeted questions, shipping small wins early. Others described waiting to be trained. Big difference.

"Describe a time when requirements changed significantly. How did you handle it?"

In our project, this would happen. I wanted people who'd adapted before, who saw it as part of the job rather than an outrage.

"What's something you'd do differently if you could redo a past project?"

This is the mirror test for candidates. Do they reflect on their own decisions? Can they identify their own mistakes without being defensive?

It Worked

The developers we brought on delivered. They jumped into the codebase, figured things out, asked good questions when stuck, and shipped work without drama.

I don't think I'm a great interviewer. But having a framework for what to look for — beyond just technical skills — made a real difference in a situation where hiring the wrong person would have hurt the project badly.

That framework came directly from Mancuso's book.

Applying This to Myself

The book didn't just help me evaluate others. It made me uncomfortable about my own behavior.

Was I taking ownership, or making excuses? Was I improving codebases, or just complaining about them? Was I honest about my limitations, or pretending to know things I didn't?

The honest answers weren't always flattering.

But that's the point. The craftsman mindset isn't about being perfect. It's about continuously reflecting and improving. Acknowledging where you fall short so you can work on it.

I still catch myself making excuses sometimes. The difference is now I notice it. I apply the mirror test. I ask what I could do differently.

The Book Is Worth Reading

If any of this resonates, read the book. My summary doesn't do it justice.

Mancuso writes from experience — he's lived the transition from "just a developer" to someone who genuinely cares about craft. The book is full of specific situations and how to handle them.

Some parts are about the software craftsmanship movement specifically, which may or may not interest you. But the core ideas about responsibility, continuous improvement, and professional attitude — those are universal.

It won't teach you a new framework. It might change how you approach your entire career.