7 Lessons From The Software Craftsman

After many decades of software engineering that produced all the advanced tools and methodologies, many software projects continue to fail. The Software Craftsman, a book written by Sandro Mancuso, aims at helping us understand why this is the case and what we can do to change it. It introduces the idea of software craftsmanship as a remedy for viewing software development as just another production line.

Let's explore 7 lessons from The Software Craftsman that can help us become better developers and deliver successful and higher-quality products. 🚀

Quality over quantity

One of the main points of the book is the emphasis on the importance of quality. We tend to focus on whether the code works, but the quality of the solution shouldn't be of less importance. At the end of the day, if a piece of software is meant to work for more than a couple of weeks or months, skipping the quality aspect in hope of saving time is a pure illusion. 🪄

Lack of time should never be an excuse for not doing certain things. We all have time. We all have the exact same amount of time. We just have different ways of using that time. Ultimately, even if your product is packed with features, nobody will use this if it is also filled with bugs and lacks quality.

Continual improvement

The software industry is evolving very rapidly. There are high expectations of how quickly and how often the products should be delivered to clients. To keep up with the pace, software engineers need to focus on life-long learning. 📈

If you think a piece of code you wrote a little while ago is still good, it means you haven't learned much since then. You should continually question why you do what you do. Can I do something better? Do these practices suit this project? What's their value? Should I try something different?

Ability to say "no"

Being a professional doesn't mean saying yes to everything. As an engineer, you are there to help the client discover what their real needs are first, and then how to fulfill them. 🎯

You probably have seen enough to know that something is unlikely to work or is not feasible. But just saying "no" is not enough. Instead, try to dig deeper to really understand and clearly formulate the problem, so that you can suggest alternatives and give convincing reasoning.

Intentional career building

As engineers, one of the things we do over and over is structure things. That applies to code, documentation, and projects in general, across time and space.

You should think about your career the same as any multi-phase project. Once you have a broader vision, you get the main requirements, split them into smaller portions, and iterate on them. You re-evaluate as you go and modify if needed. It's a good idea to try this structured approach for your career development.

That attitude has a direct result in the way you approach interviews. Remember that you're not asking for a job. You are conducting business negotiations. On one side, there is a company with its business goals, on the other - there's an engineer who can help it reach these goals. It is both a really freeing and powerful mindset. 🧠

Building great teams

Software engineering is inherently a team effort. Even if you are one of the very few developers that started the project, if the project is successful, soon there will be a lot of developers contributing to the codebase. The same applies to you as a professional - if you've been successful in your engineering job, sooner or later, you'll responsible for more than just your own work.

When hiring or leading teams, don't try to look smarter than other people. Don't intimidate them. Don't try to impress them with your title or skills. Instead, be honest and humble. Treat others as your equals and lead with a sense of mutual respect. Emphasize being able to clearly communicate your intentions, and, most importantly, know how to get people's trust. 🙌

Optimizing for change

As mentioned previously, successful projects get to live long. The code is read and changed by many people after being first committed. It runs in production perhaps longer than initially assumed. And is often expected to do different things than initially assumed. 🙃

Everyone that builds software should think about those who will maintain and further expand it in the future. They should consider what problems someone needing to change this piece of software might encounter. Aim for code that is easy to understand and easy to change.

Less is more

Well-written code is simple, short, testable, easy to understand, and, most importantly, works as expected. But it isn't easy to write code that satisfies all of the above. Code can also be filled with bugs, causing developers to be miserable. So the less code there is, the better. 📉

There is always a caveat, though. Generic code, despite being more flexible, is always more complex than a tailor-made solution. Instead of trying to write generic code everywhere, start with code that solves a particular problem, and later make it generic only if there are enough reasons to do so.

Conclusion

To summarize, here are the 7 lessons from The Software Craftsman:

Focus on continual improvement and never stop learning.
Quality is just as important as the fact that your solution works.
Learn to say "no".
Build your career intentionally.
Learn how to build great teams.
Optimize for change.
Keep things simple.

The book goes deep into each of these topics, providing many stories and outlining how to implement these lessons. If you want to learn more and become an even better software engineer, definitely give it a read! 📖

If you liked the article or have a question, feel free to reach out to me on Twitter, or add a comment below!