I’ve been intrigued for a while to find out what exactly this concept of Software Craftsmanship is.

It all started one afternoon at my current job, when my CTO asked me to join him on a meeting with a consultancy firm to whom we might be off-sourcing an internal project that we had no development capacity for. During the meeting, the guys kept talking about code and how important it was for them to do things the right way. They mentioned a couple of times the word “craftsmanship” and that each of their developers were actually craftsmen. They also said that some of them had apprentices that they were mentoring. All that naming was kind of new to me and, to be honest, at the time I thought it was weird.

After a bit of research, it turned out that one of those guys was Sandro Mancuso, the author of this book.

“The Software Craftsman” has clarified to me lots of these concepts, giving me a much clearer vision of what they meant with all that jargon they mentioned at the meeting.

Sandro covers a vast amount of topics, starting from his own story about how he became the passionate craftsman he is today.

He also explains what agile is, and where it fits in the software craftsmanship movement. Hint: they’re not exclusive! Furthermore, it describes different ways on how to become better at what we do, including techniques on how to maximise our processes for learning new languages, tools and frameworks, or tips on how to best find/block time to improve ourselves with the busy schedules we all have these days. He goes on with things like how saying ‘no’ (sometimes, and obviously with a ‘but’ afterwards!) is often times the more professional thing to do.

There are also a couple of curious chapters on how you can be better at interviews… and also interviewing! I’ve been interviewing developers for many years now, and I found that the advice in the book is spot on.

But for me, the most interesting chapters of the book were those explaining and reflecting about how you should always be in control of your own career. In the past, I was that guy complaining about how the company would not empower the employees to receive training or send us to conferences, when that was entirely my own responsibility. Also found very interesting the advice on constantly evaluating your alignment between your career aspirations and your current job. If they are not aligned, you can simply change jobs!

If I had to mention one thing that I disliked from the book it would probably be the amount of bashing that some roles that we’ll most likely be collaborating with on our daily basis get, like agile coaches/consultants, managers or architects. I’m sure that is a bit biased from what he might have experienced in the past but, like us developers, you can find all sorts of them: good and bad.

This is one of those books that one should re-read every few years. Depending on which stage of your career you are in at the time of reading it, you might find very useful advice to apply there and then that you didn’t need or paid attention to on your previous read.

I found this book pretty much as a natural continuation of “The Pragmatic Programmer” and I would highly recommend it to all those developers who want to become better at what they do, and stop just developing software to start crafting software instead.