Book: The Software Craftsman: Professionalism, Pragmatism, Pride Author: Sandro Mancuso

At the title of the book says, we should treat coding as a craft rather than just another job. We should be deliberate about the code we write but also about everything in our careers from the companies we work for, the learning we do right to the time we should search for a new job. So many people, not just software engineers, go through life without fully considering these decisions ahead of time. This book aims to make you realise we should be deliberate about everything we do.

This book is mainly concerned with the general concepts of the craft rather than getting into the nitty gritty of technical details. I feel a lot of what the book has to say has become fairly common knowledge across the industry but it is still no harm to hear it said out loud. For example, he considers QA as a waste of time due to the use of unit testing should leave no surprises at the end.

Two key ideas of the book focus around software craftsmanship and continuous learning so I will outline those below

Software Craftsmanship

Software Craftsmanship is about professionalism in software development.

This is about mindset as much as anything else. Instead of treating writing code as just another job we should be deliberate about the decisions we make and follow best practices. Well crafted software does not only just work. It should be easy to understand and maintain. What it does should be predictable so changes can be done easily with confidence no other things will break as a result. We should be constantly adding value to the codebase, following scout rules of leaving it cleaner than we found it. This does not mean we should make changes for the sake of it though as there is no point refactoring a piece of code that has not been touched in years.

There’s two key rules for good code he lays out:

  1. Maximise Clarity
  2. Minimise Duplication

But it is about so much more than just writing code. For example, when dealing with clients we should have their best interests in mind and say no when they ask for something unreasonable or something that cannot be done.

For our careers in general, it is best when we think of them as a long multiyear project. We should first understand the long term goal then break into smaller goals and iterate on the smaller goals. As time goes on the goals may change so it is good to keep reevaluating those too.

An interesting point he makes is we should always be evaluating if our current job lines up with those long term goals. There always comes a time where our goals diverge and in that case it is better for both to part ways and look elsewhere. In general there’s three things required for a particular job to be good: autonomy, mastery and purpose. Autonomy means we’re in control of what we do, how we do it and when we do it. We’re not pressured into doing things at a sub-optimal way just to meet deadlines. Mastery means we’re constantly learning and evolving to get better and improve our work. Finally purpose means the job is important to us and we feel like we’re contributing to make something better. It’s being able to answer the question of why are we doing this. Once those three questions are answered then we have a good chance of being able to take a lot away from the job.

Continuous Learning

There’s a lot of ways we can learn to become better and the book gives a few concrete examples of how we can do this. I think the key to it all is to find one you like doing whether that is reading books or using new projects and use that to keep yourself improving. Use that as a base to build off and apply the knowledge you’ve gained. I do agree with him where he says how projects are the best way to actually learn things and put things into practice. A pet project is “a real project without pressure” so can experiment and try out new things with the fear of breaking something.

All software developers should have their own blogs, regardless of how much experience they have.

Blogs are a great way for continuously learning as it is a way for you to think out loud and get feedback on your thoughts. For software engineers starting out it is a great way for recording our learning progression. It makes improvements visible and easy to track over time. He says to write for ourselves first, which I think is best when we’re starting out and don’t have much or any audience. Once we’re in the habit of sharing our experiences and findings then maybe some will be useful for others in similar situations.

For collecting information, books can be a great source but be careful of the type of book as some are more useful than others depending on what you want to get out of them. For him there’s three types of books good for different situations. If you’re in a project using a specific framework then technology books are great for that specific case but as they go out of date quickly they are not widely applicable. Conceptual books are more broadly useful as they introduce you to new concepts, paradigms and practices. The downside here is they take time to digest and become useful so be prepared to put in the work before they become useful. The final type of book that might be useful to us are behavioural books which are focused on processes and people. They make us more efficient working with others.

Final Words

The aim of this book is to get you thinking about how software engineering should be more than just writing code that works. It gets you thinking about doing the right thing when writing code but also the wider aspects of the job when you are working with other people both on your team and stakeholders. All of this requires careful deliberate thought in order to get a good outcome for everyone involved for the long term.

The book is targeted at the Software Craftsman movement which is an organisation and ideology at making all these ideas of the book more widespread. Maybe if you’re involved with the movement than I am you might think differently of the book but it seemed to me to be a good introduction to it. There’s nothing groundbreaking in the book, at least from the perspective of an engineer with a few years experience, but it is nice to see things written down and said out loud to reinforce the important things.

All this is just theory though and is all well being said. The far more difficult task is to put this into practice.