Book: The Software Craftsman
I learned about Software Craftsmanship from a colleague and was intrigued immediately because the values it stands for sounded very similar to values that I have been trying to follow myself in my career, but better structured and formalized.
Motivated to learn more, I decided to dive into it by reading “The Software Craftsman” book by Sandro Mancuso, and I really liked it! It feels like having a chat with passionate, experienced developer, talking about why do we do what we do, sharing anecdotes and advice on common situations in our work and discussing best practices.
Below I list the most important lessons from the book and my thoughts on them.
Software Craftsmanship
In short, book and Software Craftsmanship itself are all about empowering software engineers to be professionals that love their jobs, perfect themselves every day and are proud of what they do, while bringing value to the world.
Or, as the author put it shortly:
Software Craftsmanship is about professionalism in software development.
Agile + Software Craftsmanship = Win
The book starts with a more “formal” part, shortly explaining the concept of Agile, the idea, manifest and history of Software Craftsmanship, and how Agile and Software Craftsmanship fit together.
The main point here is that Agile is about processes that enable fast feedback loop, while Software Craftsmanship is about software quality, and you need both in order for your project to be successful.
Or, to put it in another way:
- Agile = Doing the right thing
- Software Craftsmanship = Doing the thing right
- Agile + Software Craftsmanship = Doing the right thing right = Success
Partnership
We should treat the relationship with our client/employer as a partnership of equals, that has to benefit both sides.
I really like this point, as it not only gives you more control but also makes your employer/client respect you more. Finally, it makes you take full responsibility for your actions in this relationship, making you a better professional.
Own your career
Our career is our own.
It is beyond a single company.
It is our responsibility to grow it, to educate ourselves and to improve.
Again, puts responsibility for educating ourselves into our hands, giving us no excuse for not advancing and learning what we want. The author mentions many different methods for this, like reading books, attending meetups, doing pet projects, going to conferences, and more. Personally, I enjoy reading books and doing pet projects! Interesting enough, both don’t include other people, unlike meetups/conferences :P.
Learn to say NO (or at least not say yes)
As professionals, we should always do what is best for our clients, even if that is not what they (initially) want (same as doctors and lawyers do).
I find this advice particularly important, as I have found myself multiple times in situations where I should have said NO but did not because I wanted to please the client.
A most common example is when you tell your the client/boss that it will take X time to do something, and they tell you that is too much, they want it done in half that time and that they believe in you and know that you can do it. Instead of trying to be a hero and giving promise that you will most likely not be able to keep (and which they will expect you to keep!), it is much better to try to simplify the task so it can be done in that time. Or, if there is no other option, to say NO. If you stand behind it, often they will adjust their requirements and another solution will come up.
Quality == speed
Unless a piece of software is extremely short-lived (< few weeks/months), trading off quality for speed does not work due to the slowdown that lack of quality eventually introduces down the road.
It is important to communicate this to the client/boss because they also don’t want the project to become slow. Instead of ditching practices like TDD and code reviews, it is often better to try to reduce the number of features or create a simpler version of the product for start.
Tip: If you are developing a feature and create a task for it, don’t make writing tests a separate task. If you do that, the manager could argue that you should skip the testing task in order to save time. In the end, those are not really separate tasks, you can’t say that a feature is complete without tests.
Therefore, make it all one task and account in it for the time you will need to write the tests.
Establish good practices
Establish practices like TDD, CI, code reviews, pair programming, …. They make software engineers feel good about their job while also improving the quality and speed of the project.
Again, here it is important to be able to communicate to client/boss the benefits these practices bring (e.g. fewer bugs, shared knowledge, speed).
Autonomy, mastery, and purpose
When looking for our next job, we should be looking for autonomy, mastery, and purpose. Those are more important than money or title.
Hiring
Hire for passion.
I liked this point a lot.
Often, when interviewing candidates whom I felt were not quite right for the role, I knew something was missing but could not find good words to explain it. I would say that they don’t feel like “hard-core programmers” or that I just don’t feel that they are excited.
The word I was looking for is “passion”.
You can see that developer is passionate when they have pet projects, they are excited to discuss their favorite technology, they know their programming environment well and have customized it and played with it a lot (OS, editor, …), they read and want to talk about the books and so on.
Ideally, you want the interview to feel like a nice, exciting chat between two passionate professionals. Don’t do Q&A with right/wrong answers.
And keep in mind that it is not just you interviewing the candidate, the candidate is also interviewing you (if he/she is a good candidate).
Culture of learning
Make sure to foster the culture of learning in your team/company. There are many different ways to do it: book club, tech lunch (less formal), tech discussions (more formal), encouraging pet projects, ….
Be an example! Passionate developers usually drive the culture of learning.
4 rules of simple design
- Passes all tests.
- Minimizes duplication.
- Maximizes clarity.
- Has fewer element.
The part I could especially connect with here was when the author said how when he was less experienced he was trying to use design patterns as much as possible, and how now, when he is more experienced, he uses them only when they are needed, preferring simplicity.
Quality is not expensive
TDD and other best practices should not be considered expensive, as they contribute to the project. If they do seem to take too much time, it is due to our inexperience and lack of skills. We should master our practices, be pragmatic and not lower our quality standards.
Mission
Software Craftsman is on a mission, to improve himself/herself, bring value, help others.
It is a lifestyle, not a job.
Conclusion
I myself enjoy being a Software Engineer / Computer Scientist and always strive to be professional and constantly improve myself. Also, I consider software engineering to be more than just a job, for me, it is more like an art or craft since it allows me to express myself, to create while having endless opportunities to improve and learn.
However, sometimes it can be hard to stay on the path and maintain those values, for example when under pressure due to business requirements, especially when the speed is a priority (and when is it not?). Then, you start wondering if maintaining and insisting on those values really does make sense, do they really bring value or are you just insisting on them for your own sake? Is this the project where you drop code reviews and write hackish code because that is better for the business/client?
This is where I found this book really valuable, as it encouraged me to not forfeit these values while providing me with good arguments as to why they are not negotiable (in most cases), arguments that are also understandable to other parties involved in the project, not just software engineers.
I expect to come back to this book multiple times through my career and would certainly recommend it!