Software Craftsman, The: Professionalism, Pragmatism, Pride

Welcome in everyone to our deep dive this time into software craftsmanship.

Oh interesting.

Yeah, and our main source material today is going to be selections from Sandral Mancuso's book The Software Craftsman, right, which came out you know, almost ten years ago now, back in twenty fourteen, wow, but still really relevant today. And you know it's part manifesto per practical guide. Yeah,

Development, Wild West days.

I love that and yees. So he's seen it all. He's seen the rise of agile, he's seen you know, all these different trends come and go.

Yeah.

And he's not author, he's also a practitioner. He co founded a software craftsmanship consultancy and the London software craftsmanship community.

That's great.

So he's really you know, putting these ideas into practice. Yeah. So I'm really excited to dive into this book with you and yeah, me too, see what we can kind of extract in terms of the key principles of software craftsman show and what it really means to be a software craftsman today in twenty.

Twenty four you know, in the modern world.

In the modern world, Yeah, because I think things have changed quite a bit even since twenty fourteen.

Yeah, definitely.

So one of the things that really jumped out of me reading through this was Mancuso's description of the early days of his career in the nineties, where he talks about how, you know, back then, seniority was often measured by how complex and how difficult to understand your code was.

Oh wow, so.

It's almost like, you know, job security through obfuscation. Really kind of a crazy concept when you think about it, it's wild, but that was kind of the mentality back then. And he tells this story about working on this project where there was this one senior developer who wrote this incredibly complex piece of code that no one else could understand, and he was like the hero, you know, because he was the only one who could fix it.

Oh, so he was the only one who could maintain it exactly.

He was the only one who could maintain it, and so he had all this power and everyone kind of looked up to him. But Mancuso realized that that was actually a really unsustainable way to build software.

Yeah, I can imagine, because.

What happens when that person leaves or it gets hit by a bus, Like, look, what do you do? The whole project falls apart. Yeah, So that was kind of a turning point for him, I think, in terms of realizing that there had to be a better way.

So how did he start to see things differently? What was that turning point?

Well, I think he started to realize that software development is not just about writing code. It's about building software that is maintainable and understandable and that could be worked on by a team of people. Right.

It's a collaborative process exactly.

And it's about, you know, delivering value to the client, not just impressing your colleagues with your cleverness.

Yeah, that makes a lot of sense.

So it's about shifting the focus from individual ego to the collective good of the project and ultimately the client. Right.

So it's not about being a hero developer, it's about being a team player.

Yeah, exactly. I like that, and I think that's really at the heart of software craftsmanship, is this idea of being a professional, okay, and taking pride in your work and really caring about the quality of the software that you produce.

And seeing yourself as a craftsman as opposed to just like a code monkey exactly.

And I think that's a really important distinction because I think for a long time, software development was seen as this kind of you know, geeky, hobbyist kind of thing.

Yeah, just something that people did in their basement.

Yeah, but I think in recent years there's been a real shift towards recognizing it as a profession, a true profession, yeah, with its own set of ethical standards and best practices, right. And I think software craftsmanship is a big part of that movement.

Okay, so it's not just about the technical skills, it's about the mindset, the attitude.

Absolutely, Yeah, It's about how you approach your work and how you interact with your colleagues and your clients, right.

Like a true prof I like it. So it sounds like software craftsmanship is really about raising the bar for the entire software development industry.

Yeah. I think that's a great way to put it. It's about saying, you know, we're not just hackers, we're not just code monkeys. We're professionals, and we're going to take pride in our work. And we're going to build software that is high quality and that meets the needs of our clients.

That's a great goal to strive for.

Yeah, and I think it's a really important goal because you know, software is everywhere these days.

It runs the world.

Yeah, it runs the world. It's in our phones, it's in our cars, it's in our homes, it's everywhere. Yeah, and so the quality of that software really matters.

It affects all of us.

Yeah, it affects all of us. It affects our lives, it affects our safety, affects our privacy.

Absolutely.

So I think it's really important that we as software developers take that responsibility seriously. I agree, and I think software craftsmanship is a great framework for doing that.

Okay, So I'm curious about this idea of the agile hangover that you mentioned earlier.

Right, Yeah, that's a really interesting concept.

What is that exactly?

So Mancuso talks about how a lot of companies adopted agile methodologies, but maybe you didn't fully embrace the underlying principles I see of quality and craftsmanship.

So they got the process, but not necessarily the substance exactly.

They were going through the motions of agile, but they weren't really changing the way they built software.

So what were they missing.

I think they were missing that focus on technical excellence, on building software that is well designed and maintainable, right, And I think that's where software craftsmanship comes in. It's about filling that gap.

So it's not agile versus software craftsmanship. They actually work together exactly.

They complement each other.

Okay.

Agile focus is on the process on delivering software incrementally getting feedback from the client, but software craftsmanship focuses on the craft of building software that is high quality.

So it's like having a great engine in a race car. You need both to win.

That's a great analogy.

You need the speed and the reliability exactly.

You need both agile to he help you deliver software quickly, and you need software craftsmanship to help you build software that is well built and that will last.

So it's about building software that's not just functional but also beautiful.

I love that. Yeah, I think that's a really important point. It's not just about making it work, it's about making it work well, yeah, and making it something that you can be proud of.

It's about craftsmanship exactly. So how does this all tie into the Software Craftsmanship Manifesto, Right.

So the Manifesto is kind of like a set of guiding principles for software craftsmen. Okay, and it lays out four key values and we're going to dive into those in just a bit. But before we do that, I just want to kind of set the stage a little bit, sure, because I think it's important to understand where these values

I like that. So it's about raising the level of professionalism in the software development industry exactly. I'm on board of that.

All right. So let's dive into those four key values of the Software Craftsmanship Manifesto.

Okay, let's do it.

So the first one is not just working software, but well crafted software.

Okay, well crafted software? What does that mean?

Exactly? So it's about building software that is not just functional, but also well designed, easy to understand, easy to change, and build.

A last, so it's not just about getting it to work, it's about making it work.

Well exactly, and making it something that can be easily maintained and extended over time.

Right, because software always changes, exactly. Requirements change, technology changes, everything changes, so.

We need to build software that can adapt to those changes.

That makes a lot of sense.

Yeah, so well crafted software is about building software that is flexible and resilient that can stand the test of time.

Okay, I like that.

So the second value the manifesto is not just responding to change, but steadily adding value.

Okay. So it's not just about keeping up with the changes. It's about making things better exactly.

It's about delivering value to the client with every iteration.

So it's about focusing on the outcomes, not just the outputs exactly.

And it's about thinking long term about the sustainability of the software that we're building.

Right because sometimes a quick fix can create more problems down the road.

Absolutely.

So it's about making sure that every change we make is actually adding value to the product exactly.

And that's not always easy, No, it's not. Sometimes it's tempting to just hack something together to get it working.

Yeah, I've been there.

But a software craftsman resists that temptation.

We take the time to do it right exactly.

They invest in quality even if it takes a little longer.

Because they know that it will pay off in the long run.

Exactly. Okay, I like that. So what's the third value?

So the third value is not just individuals and interactions, but a community of professionals.

Okay, So it's about working together exactly.

It's about recognizing that software development is not a solitary pursuit. It's a team sport.

Yeah, it takes a village exactly.

And it's about sharing knowledge and learning from each other and raising the bar for the entire profession. So it's about mentorship and collaboration.

Absolutely, And it's about building a community of practice where we can all support each other and grow together. I like that. Yeah. So it's not just about you know, me writing my code in my little silo. It's about us working together to build something great.

It's about the collective good exactly. Right. So what's the fourth and final value?

So the fourth value is not just customer collaboration, but productive partnerships.

Okay. So it's about more than just getting requirements from the client.

Right, It's about building a relationship with the client based on trust and respect, and mutual understanding.

So it's about working with the client, not just for the client exactly.

It's about seeing the client as a partner in the software development.

Process and under standing their business goals.

Absolutely and working together to find the best solutions.

So it's a much more collaborative approach.

Exactly.

I like that.

Yeah. So those are the four key values of the Software Craftsmanship Manifesto.

Well crafted software, steadily adding value, a community of professionals, and productive partnerships.

Exactly.

Those are some great principles to guide our work.

Yeah, I think so, and I think they're really relevant today, even more so than they were back in twenty fourteen when the book was first published.

Yeah, I agree. So how do we actually put these values into practice? What are some of the specific practices that Mankus advocates for.

Right, Well, that's a great question, and that's what we're going to dive into in our next segment.

Awesome, I'm looking forward to it me too.

Okay, so we've talked about the technical side. You know, the practice is the principles, right, But what about that mindset? What makes a software developer a true craftsman beyond just writing clean code?

Well, you know, I think it's about approaching your work with a certain level of intentionality and ownership. You know, a true software raftsmen sees themselves as a professional, not just a code monkey.

Right.

They take pride in their work. They strive to constantly improve their skills.

It's interesting you say that because Mancuso talks about this idea of owning your career and it's not just about you know, keeping up with the latest JavaScript frame, right. It's about taking control of your professional development and constantly seeking out opportunities to learn and grow.

It's about recognizing that your career is your responsibility, not your employers. It's about setting your own goals, seeking out mentors, building a network of peers who can support you along the way.

And he even shares his own story, right yeah, about wanting to work in London and how he had to adapt and teach himself new skills. Wow, to make that happen. That's impressive and it really highlights I think the importance of being proactive and taking ownership of your career path.

Absolutely, and that actually ties into another key aspect of the craftsman's mindset, which is embracing a culture of learning. It's about being curious, constantly asking questions, and actively seeking out knowledge.

He talks about you know, blogs, conferences, open source projects, even just like informal conversations. Yeah, with other developers.

It's all about learning.

It's all part of that that learning process.

Yeah. And you know, it's interesting to think about how this connects to the bigger picture. You know, by sharing our knowledge and experiences, we all benefit and the craft of software development as a whole continues to evolve.

It raises the tide for everyone exactly. One thing that really struck me was Mancuso's emphasis on finding purpose and meaning in your work. It's not just about you know, punching the clock and collecting a paycheck. It's about feeling like your work has a real impact.

Absolutely, a true craftsman sees their work as more than just writing code. They understand how their work fits into the bigger picture, okay, and how it contributes to the success of the client and the end us.

And he even talks about, you know, having the courage to say no, oh, yeah, which I think can be really difficult for.

Developers, especially early in their careers.

Especially early in their careers.

Yeah, yeah, you want to please everyone.

You want to please everyone. You want to take on every project you want to You want to prove yourself, prove yourself exactly.

But sometimes saying no is the most professional thing you can do.

He makes a really good point there.

Yeah, a software craftsman understands that taking on too much work or agreeing to unrealistic deadlines can ultimately compromise the quality of the software, right and damage their reputation in the long run.

So it's about being honest with yourself and your clients, yes, about what you can realistically achieve.

Exactly, And it's about having the courage to stand up for what you believe in.

Okay, So all of this sounds great in theory, right, but how does this whole translate to the real world of software development? Let's face it, you know, we're not all working on greenfield projects, yeah, with unlimited budgets.

And right, the real world is messy.

The real world is messy, it is. So how does software craftsmanship help us deal with the messy realities of legacy code, tight deadlines and demanding stakeholders.

Well, that's where the rubber meets the road, right, Yeah, and Mancuso doesn't shy away from these challenges. In fact, he offers some really practical advice for navigating those choppy waters.

So let's start with legacy code. Okay, I think most developers have had to deal with that beast at some point in their careers.

Oh yeah, for sure.

How does software craftsmanship help us approach that challenge?

Well, Mancuso encourages us to see legacy code as an opportunity for growth, not just a burden.

Okay.

He says working with legacy code can be a great way to hone your skills in refactoring, testing, design.

He doesn't sugarcoat it, though, No, he doesn't. He acknowledges that it could be incredibly frustrating, time consuming.

Of course, but he argues that by approaching legacy code with a craftsman's mindset, we can slowly but surely make it better.

Okay.

It's about making small, incremental improvements over time, rather than trying to boil the ocean.

So it's about pragmatism as well. Yes, absolutely, it's not always about achieving perfect code, but about making things better within the constraints of the project.

Exactly. You have to balance your desire for clean code with the practical realities of the project. Sometimes you have to make compromises, but you should always strive to leave the code base better than you found it.

He gives the example of working on a startup where the business needs are constantly changing. In that context, it might make sense to build a thin slice of functionality first to get feedback quickly, and then add more robust testing and structure as the requirement solidify.

Exactly, It's about adapting your approach to fit the context, and sometimes that means being pragmatic and making trade offs.

Another challenge that Mancusu addresses is the issue of low morale.

Oh yeah, that's a big one.

He uses the term agile hangover to describe the disillusionment that some companies experience after adopting agile methodologies.

So it's not all sunshine and rainbows with agile, not always no, So what are some of the causes of this agile hangover?

Well, he argues that low morale is often a symptom of a deeper problem. Okay, a lack of autonomy, mastery, and purpose in the work.

I see.

Developers can feel like cogs in a.

Machine, yeah, just churning out code.

Rather than valued professionals who are making a real.

Contribution, right, they lose that sense of ownership and that can be really demotivating.

He shares a story about joining a team where the project was in chaos, deadlines were looming okay, and the developers were completely demotivated.

That sounds like a nightmare, it does. Yeah, So how did he turn things around?

Well, what's interesting is that he didn't come in and try to impose his ideas on the team, okay. Instead, he focused on building relationships, fostering a culture of collaboration, and empowering the developers to take ownership of the project.

So he gave them back that sense of ownership.

Exactly, And that seemed to be the key. Right. By giving the developers more autonomy and a sense of ownership, their morale improved and they started to care about the quality of their work against is they.

Felt valued exactly, And that's so important.

And this is where I think software craftsmanship can be a really powerful antidote to low morale.

Okay.

I see that by focusing on the craft of software development, fostering a culture of learning, and giving developers a sense of ownership, right, we can create a work environment where people are not just coding Okay, they're crafting.

I love that analogy.

It's about taking pride in your work, Yeah, and seeing yourself as a craftsman.

So this all sounds great, but how do we actually bring about this kind of change in our own teams and organizations? Right, especially when you consider that not everyone is going to be on board with this software craftsmanship thing right out of the gate.

Yeah, that's the million dollar question, isn't it?

It is?

How do we actually drive change and create a culture of craftsmanship in our organization?

That's the challenge.

It's definitely not easy, but Mancuso offers some practical advice. Okay, good on how to approach this challenge.

Well, let's dive into that in our next segment.

So we've talked about, you know, the challenges, the mindset, the practices, but how do we actually bring about change within our teams and organizations?

Right? It's one thing to read about these ideas, but it's another thing entirely to actually implement them exactly.

Yeah, how do we convince our colleagues, our managers, maybe even ourselves that this software craftsmanship approach is worth pursuing.

Yeah, it's a valid question, and Mancuso acknowledges that. Okay, you know there will be resistance, right, You won't win everyone over immediately, of course not. He even breaks down the types of skeptics to encounter.

All right, let's hear about these skeptics.

Which I found incredibly helpful.

Who are we dealing with here?

So he talks about the uninformed? Okay, these are folks who simply aren't aware of the benefits of practices like TDD or pair programming.

Okay.

Then you have the burned who've tried some of these things in the past but had negative experiences, maybe due to poor implementation or a lack of support.

I've been there.

And then there's the time crunched who feel like they don't have time for anything beyond just getting the code out the door.

We've all worked with that person, and.

Of course we can't forget the cynic Oh.

Yeah, who believes that nothing will ever change right, and that we're all doomed to a life of spaghetti code and endless bug fixes.

It's not going to get any better.

He even mentions the Ivory Tower architect, Okay, who's more interested in abstract designs and buzzwords than the practical realities of building maintainable software.

Sounds like we've got a whole prast of characters to contend with here, we do. So how do we approach these skeptics? Do we just like bombard them with articles and conference talks about the virtues of software craftsmanship.

Well Mancuso suggests a much more subtle and effective approach.

Okay.

He emphasizes the importance of leading by example. Okay, instead of just talking about the benefits of TDD, actually do TDD in your own work, right, Let the results speak for themselves, don't tell exactly, and be patient. Change takes time, especially within organizations. Yeah, start small, focus on building trust, and gradually introduce new practices and ideas.

So it's a marathon, not a sprint, exactly.

Don't try to force it on anyone. And he also talks about choosing your battles wisely.

Right, Absolutely, you don't have to win every argument.

Yeah, sometimes it's better to just let it go.

Focus your energy on the changes that will have the biggest impact. Okay, and don't get bogged down in debates about minor details. Right, Sometimes it's better to pick your battles and focus on making incremental progress now.

And Kuso also talks about technical leadership, yes, and how it plays a crucial role in driving change. What are some of the key takeaways for those in leadership positions who want to foster a culture of software craftsmanship.

Well, he makes a distinction between being a boss and being a leader. Okay, a boss might dictate solutions and micromanage every detail, while a leader focuses on empowering their team. Okay, it's about guiding the team toward a shared understanding and enabling them to make their own decisions.

He also stresses the importance of communication right.

Absolutely, It's not enough to be a technical whiz.

Right.

You also need to be able to communicate your ideas clearly and persuasively to your team, to your stakeholders, even to those skeptical colleagues we talked about earlier.

So it's about being able to articulate the why.

Behind the what exactly. And he also talks about humility okay, which I think is often overlooked in technical leadership.

Right.

Humility is crucial. It's about recognizing that you don't have all the answers and being open to learning from others, including those who might be less experienced than you.

Now before we wrap up, I want to circle back to something we touched on earlier, this idea of the software craftsman as a role model. What does that actually look like in practice?

Well, it goes beyond just writing clean code. It's about embodying the values of software craftsmanship in everything you do, from how you approach your work to how you interact with your colleagues and clients. It's about integrity, honesty, and a commitment to excellence. It's about setting a high bar for yourself and inspiring others to do the same.

Menkuso uses this really powerful phrase. He says, a craftsman is never missed for the wrong reasons. What does that mean to you?

It means that true craftsmen leave a positive legacy. Okay, they are not missed because they were bottlenecks, hoarding knowledge or creating mountains of technical debt. They are missed because they made a real difference. They elevated the craft, and they helped others to grow and develop their skills.

That's a beautiful way to put.

It, and it's something we should all aspire to.

So as we wrap up this deep dive into the world of software craftsmanship, what are the key to acoways, you hope our listeners are walking away with.

Well, I hope they're walking away with a deeper understanding of what software craftsmanship is all about. It's not just about writing clean code. It's about approaching software development with a certain level of intentionality, professionalism, and a commitment to continuous improvement.

It's about elevating software development from a job to a craft, and it's about realizing that we as developers have a responsibility to ourselves, to our clients, and to the world to create software that is not just functional, but also well crafted, maintainable, and truly valuable.

It's about taking pride in our work and striving to leave a positive legacy behind. It's about being more than just coders. It's about being craftsmen.

What a fantastic note to end on. Thank you so much for joining us on this deep dive into software craftsmanship. We hope this has inspired you to continue exploring this fascinating philosophy and to keep honing your craft. And remember, a craftsman has never missed for the wrong reasons.