What Mindset Should I Bring to Building Software?

I recently read Sandro Mancuso’s The Software Craftsman. The book left a strong impression on me, so in this post I want to share what Mancuso is trying to convey and my own thoughts along the way.

Clean and handsome cover design

What Mancuso emphasizes throughout the book is, as the title suggests, professionalism. In the first half, he draws out the craftsman’s attitude through questions like: as a developer and technical expert, what kind of satisfaction should I provide to non-technical clients? What do clients actually want from me? In the second half, he explains practical methods developers can use to meet those expectations.

I started reading without any particular expectations, but before I knew it, I was hooked — nodding along at some points and pushing back at others. The situations Mancuso describes are ones developers frequently encounter, and many of the topics overlap with things I’d already been thinking about. That’s what made it such an engaging read.

So I’d like to introduce a few of the topics I found most interesting and thought-provoking.

Who Owns Your Career?

Many developers prefer companies that actively support their growth — paying for conference attendance, buying books, lending office space for study groups. Some companies even officially allocate work hours for learning.

These companies understand that an employee’s growth ultimately drives the company’s growth. Naturally, such cultures attract great developers. Who wouldn’t want a company that invests in your development?

But if you’re at a company that doesn’t offer these perks, you might start to grumble:

The company down the street covers conference fees and everything. Why doesn’t my company do that…?

I’ve had these thoughts too. But Mancuso argues that this kind of complaint is misguided.

Think about it: when a developer studies new technology or attends a conference, that’s essentially an investment in providing better service to clients. Imagine going to the hospital and the doctor tacking on a 10% “research fee” to your bill. Mancuso argues that developers demanding their company subsidize their self-improvement isn’t all that different.

The company pays for your technical expertise — not for your personal growth. Of course, when companies do support learning, it benefits everyone. But it’s a courtesy, not an obligation. A developer’s self-improvement is a personal investment — something you should be doing regardless of whether your company supports it.

Early in my career, I thought companies were obligated to support developers’ growth by covering conference and book expenses. I believed that companies without such support didn’t care about their employees’ development, and that I couldn’t grow in such environments. I was already doing side projects and studying new technologies after work, but I felt that company support would accelerate my growth — hence the frustration.

Looking back, that was a naive and embarrassing perspective. Company support is nice to have, but even without it, as a software professional, I should always deliver the best possible results to my clients. (Though I’d still appreciate the support.)

Mancuso reportedly asked a team member who harbored similar complaints: “Who owns your career?” It’s a question that cuts right through everything I’ve been saying. Ultimately, you’re the one building your career, and you’re the one who benefits most from your own growth.

Act Like a Professional

Mancuso argues that the employer-employee relationship is a model that hinders creative work. To be specific, he’s not talking about the relationship itself, but the top-down command structure it often entails — the system where you do what you’re told, even when you think it’s wrong.

This command-and-control dynamic exists to some degree even in companies that pride themselves on flat culture. Organizations where employees can genuinely push back are rarer than you’d think — not just in any particular country, but globally. (The CEO and HR will tell you theirs is one such company, but you need to hear from the actual employees.)

But when you think about it, we’ve entered into a contract with the company. And that contract didn’t say “I will be your slave.” The company wants your technical expertise, and you, as a technical professional, provide it. It’s a partnership.

At the end of the day, a professional is someone who sells their expertise.

This is why Mancuso says the company is also the developer’s client. We’re selling our technical skills to the company — just like you go to a doctor when you’re sick or call a plumber when your drain is clogged. When a company needs software built, they hire a developer.

And true professionals, when they know a client’s request would harm the client, don’t simply comply if it goes against their professional judgment. For example: after surgery, when the anesthesia wears off and a patient is in pain, they might ask for more painkillers. If the patient’s condition can’t handle more medication, the doctor won’t administer it. The patient doesn’t know what that medication would do to them — but the doctor does.

The same applies to developers. As technical experts, if we see technical concerns, we must communicate them to the company. That’s precisely why they hired us — to provide that technical insight. A classic example is project timelines.

If a PO or CEO comes to you with a project that clearly needs at least a month and asks you to finish it in two weeks, what should you do? Many developers would say “I’ll give it my best shot. Let’s go!” Because when the CEO is earnestly asking, saying “that’s not possible” makes you feel like you’re incompetent or being difficult.

So how do you finish a month-long project in two weeks?

Overtime, of course. Anyone want to order dinner?

Developers in this situation are basically forced into overtime. Another option is to cut corners — patching potential problems with quick fixes, hardcoding things you know will break later, implementing data models without proper schema design.

Mancuso calls this kind of behavior “unprofessional.” (Ouch.)

I’ve done this at work myself. I thought meeting the deadline was the top priority, so I’d leave potential issues unresolved, make things barely work, and rush to the next feature. Developers with deep experience might produce decent quality even when cutting corners, but unfortunately I wasn’t at that level — and some of the code I wrote was genuinely terrible.

But we all know what happens when you work this way: as the application grows, technical debt accumulates and problems inevitably surface. Even with overtime, there’s no guarantee you’ll meet the deadline. And even if you do, code written under these conditions won’t be high quality — and low-quality code breeds bugs.

If you shipped on schedule but the bugs caused a poor user experience, can you really call that project a success? Mancuso says developers should firmly tell the company: “We can’t proceed with the project this way.”

In other words, developers are the people who most accurately understand what problems today’s code will cause tomorrow. As professionals, we have an obligation to inform our client — the company — about these potential issues. How to make non-technical people understand is a separate challenge, but I agree that speaking up is the right thing to do.

By raising these concerns, the PO, CEO, or other non-developer team members can properly assess the situation, and new solutions may emerge — reducing scope, extending the timeline, or other alternatives.

Ultimately, what Mancuso wants to convey is that we’re providing technical expertise to the company as software professionals. We should be able to articulate the risks of unreasonable timelines and propose reasonable alternatives. Don’t work with the mindset of “they’re paying me, so I’ll just do what I’m told.”

And from the company’s perspective, when a developer pushes back, don’t assume they’re trying to slack off. Recognize that they’re raising the issue because something genuinely concerns them, and carefully weigh what you stand to gain versus lose by forcing the project forward.

How Developers Should Treat Code

I touched on this in a previous post about agile, but the agile methodology originates from the Agile Manifesto, which includes this item:

Working software over comprehensive documentation

The definition of “working software” varies from developer to developer. Some think it just needs to run. Others believe it should have clean architecture and comprehensive unit tests. But in practice, most people get caught up in the “agile = move fast” mentality and default to the former.

However, code that merely works — written without proper design, abstraction, or patterns — might be quick to write now, but will cause problems every time a new feature is added.

Think about how it feels when you encounter a mess of legacy code.

The code is hard to understand, and you’re afraid to touch it because you don’t know what might break. Every small change requires testing the entire feature set to feel safe. And none of it is automated, so you test everything by hand. Technically, this still falls under “working software.”

Now imagine you need to add a new feature or improve an existing one in this legacy codebase. Can you move as nimbly as agile intends? I don’t think so.

It might look nimble at first because feature development is fast, but as technical debt accumulates, the team eventually grinds to a halt. And agility in agile doesn’t mean “finish development quickly.” It means being nimble enough to flexibly respond to constantly changing requirements.

Mancuso says that a software professional should pursue not just working software, but well-crafted software.

Well-crafted software means code written long ago that a new hire can immediately understand — with clear, simple design. It means software where adding or modifying features takes roughly the same effort as the initial development.

In other words, predictable and maintainable software. Mancuso presents unit testing, pair programming, and continuous integration as concepts needed to achieve this. But even without all of those, just having solid code reviews can prevent the worst-case scenario of an application’s code spiraling into chaos.

Writing working code is the bare minimum for any developer. A professional developer goes further — writing well-crafted code.

“I Didn’t Have Time”

I did a lot of soul-searching on this topic, because it’s something I said frequently at work. The closer I got to a project deadline, the more I tended to reach for this excuse.

One thing I reflected on was that I’d been treating unit test writing and business logic development as completely separate tasks. I thought finishing the business logic was more important than writing tests — which is exactly why I could make excuses like “I didn’t have time, so I’ll write the tests later.”

Mancuso strongly emphasizes unit testing, and for good reason: manual testing is manageable at first, but as the application grows, the time required for testing grows with it.

A significant portion of hard-to-diagnose production bugs could be caught during development simply by writing unit tests. Mancuso argues that unit tests reduce repetitive, wasteful work — which directly translates to increased productivity.

You might be thinking:

Writing unit tests means more code to write, plus more time spent defining clear functionality… won’t that make development take longer?

That’s true — it will take longer than just writing the code without tests. Which is exactly why you should factor test writing into your timeline from the start. Business logic and tests aren’t separate tasks — they’re both part of the feature development process.

Beyond skipping tests, there’s another context where “I didn’t have time” comes up: writing unstructured code. In plain terms, sloppy coding. I’ll be honest — I’ve said “let’s just ship this and clean it up later” more times than I’d like to admit. Situations where the code probably won’t cause bugs but is hard to read or structurally unclear, and you move on because of time pressure — I’m sure most developers have been there.

Mancuso criticizes this bluntly: doing this is nothing more or less than a developer inserting low-quality code into the application without any guilt. This guy really knows how to hit you where it hurts.

This topic stuck with me longer than the others. It made me wonder whether I’d been rationalizing sloppy code with “I don’t have time” and “finishing the project is more important.” While the other topics were enlightening, this one genuinely made me feel ashamed.

Wrapping Up

If you’ve read The Software Craftsman, you know that Sandro Mancuso doesn’t mince words. He’s sharp in his criticism of what he sees as wrong, and he backs it up with solutions. (He hits you in the ribs more than once.)

The book also strikes a good balance between the hard skills and soft skills needed to become a professional developer, which keeps it from ever getting dull. The soft skills section covers topics you won’t find in most other books — like how to interview as a software craftsman — which makes it fun to read.

And since the book also addresses people who work alongside developers in other roles, it’s worth a read even if you’re not a developer yourself.

That wraps up this post on what mindset I should bring to building software.