Thoughts after Software Craftman book

I recently read Sandro Mancuso's book “The Software Craftsman” I came across this title in search of ways to improve my basics and habits as a programmer.

Who is this Software Craftsmen?

Approaching software developers in terms of craftsmanship has changed the way of I think about the role. We are like a blacksmith or a layer or a physician. That is, we are the person who knows. Who knows better what is possible, what are the ones seeing the potential drawbacks or what is possible. We are specialists in our craft and with a good conversation and good understanding from our side, we can come up with a product that will satisfy the customers - whether they are clients or managers or other people.
☝️ This in particular has made me think and rethink everything.

There are few things I take behind this mindset:

• Sharing - whether it's my knowledge or the knowledge of others, I want to be a person who doesn't hesitate to take and give.
• Continuous improvement - I want to develop my skills throughout my life.
• Help client to reach their goals
• Take care of what I do - whether it is code or partnerships, everything should be handled professionally.

Of course, we have a manifesto, which can be seen below:

The idea is to extend the Agile way of doing things. One sentence per value:

1. Think of people that will work on it and with it in the future.
2. Continuous refactoring and improvement of the code.
3. Sharing the knowledge and help the newbies.
4. Be actively involved in the success of the project by challenging requirements, understanding the business, suggesting improvements and working productively with our clients or employers.

That's how I see it.

Sharing is caring

The number of pages related to sharing, knowledge and development is enormous. One thing that surprised me the most was Swaps - the idea where you swap teams or projects for few hours to few days to relieve boredom out of your work and learn from others. Because, as it should be obvious, but it is not - every team does something better than other teams.

What does it mean to be professional?

First of all, you should be accountable for the code, how does it work, what technologies you think are good fit or what architecture to choose should be on your side as a developer. Clients or managers are often not as competent as you are, so if they suggest something you know is not a good idea, don't be afraid to tell them so.

This brings us to the second point, which is honesty. Whether you have concerns or you know that something won't be delivered in a certain time. Just be honest about it, often the people you work for will understand if you have arguments for it, they will probably prefer to give it some more time, when they understand the reasons behind it.

The last thing that's kind of related to the previous two is alternatives. Every "no" should come with a list of alternatives. At the end of the day, our focus is on problem-solving.

Now, we know how to act, but how do we take care of the code? Sandro says that it is a garden, and we as developers are gardeners. If we take care of it, it will grow beautifully. But if we stop for a while, the longer the time, the harder it is to make it look good again. The same thing happens with the code - if we make bad code, if we overlook some principles or ideas, if we try to do just the bare minimum, everything will hurt us in the long run, we should think twice about it.

Below chart shows the relationship between quality of the code and the time needed for a new feature.

Going further and looking at my experience and working with legacy code the idea of just changing the code I am working with, refactoring just that part is something that deeply touched me, here I understood that during my first ever job I failed as a programmer not to do so. Every bug found by the QA team is a failure as a programmer.

How to learn this or what tools to use?

First of all be ready to find better ways of doing things, as this book is 10 years old it may be obsolete. But main things are:

• TDD
• Pair programming
• Refactoring
• Simple designs
• Continuous integration

All of them allow us to prepare background that will be readable by future developers and easy to work with. Each feature can be tested within minutes if it fits into the existing code, and we are constantly learning as developers.

Test Driven Development

But why TDD? We can think about what we want to achieve before we write the code, we focus on one thing - the result. Working with this practice allows us to prepare small increments and not overcomplicate the code beforehand - we write just enough to cover our tests. Isn't that perfect? It may take some time to learn this way of coding, but I think it's worth it. The side effects might be: test coverage for our code, if we have problems writing tests, we probably over-engineer code, so it's a win-win situation.

Pair programming

Before this book, I never saw it as a valuable thing to do. I just ignored it. Now, with the context of the book, I see it as an easy way to get better. Writing code with someone else is not a waste of time, it's the opposite - we can learn a lot of things: new shortcuts, new solutions to known problems, different approaches, practices, technologies, etc. Remember that the number of things you can learn on your own is much smaller than the number of things you can learn with others.

Refactoring

As a professional developer, constant learning is a second nature, which means getting better and better with every piece of code you write. What once was a good code could be improved after some time, revisiting places, adding new features should include constantly improving the code that is there, don't just add new code, prepare the code for new thing, improve it, change it a bit. That's how we can preserve the quality of it.

Simple designs

I think that's something that's easy to overlook - simple designs, what does that even mean? I often think I write code to make things happen, I don't think about other people using it in the future, which is wrong, we don't write code for machines, we write code for other developers. And I think that’s the one thing that sums it up.

Continuous integration

Automation of processes between code writing and deployment cuts the time. But what time?

• Time to production.
• Time to verify whether our changes collide with current solutions.
• Time QA needs to test manually.
• Time we might block others if we have single environment for testing.

How to incorporate learning attitude in your current company?

That's the part that never occurred to me before. That you can be the one to create opportunities within the company to share knowledge, to make learning collective. To start the whole mindset change: book clubs, tech lunches, group discussions, group code reviews, hands-on sessions, communities, etc.

I'm amazed to learn that it's in my hands as a developer, not as a manager, but as a developer. For me, this is a new concept, that I think everyone should embrace. Still, there are guides on how to do it within the book, with the examples and context to help you to not give up. Next to developing yourself, I think this is the most important part of the book.

My favorite quotes

I think they best illustrate what are my key takeaways from the book.

Always leave your code cleaner than you found it.

And the second is the story of how the developer should face obstacles:

Saying no without providing options does not help much because the person receiving our answer will not be able to do much with it. I remember a tale I used to hear when I was younger where the boss, who had just arrived in town, asked two of his assistants to buy him an orange juice. The first one rushed outside to the juice shop around the corner, asked for an orange juice, and within five minutes she was back saying to her boss that the shop did not have oranges. The second one took around 20 minutes to come back, and before she said anything, the boss said, “I already know that the shop does not have orange juice, so why did you take so long to come back to me?” “Yes,” she said. “They don’t have orange juice but they have pineapple and apple juice. The pineapple juice is fresh but the apple juice is bottled. I also asked around and discovered that there is a supermarket a little bit further away where I could buy some fresh oranges and could make you a fresh juice. I can get you a pineapple or apple juice in five minutes or, if you prefer, I can make you a fresh orange juice in 30 minutes. I just need to know which one you prefer.”

Final words

There's a lot of more content in the book that I didn't cover. The things above are my key takeaways. I found it enlightening how much real life examples are in the book, how much step-by-step guidance there is, how broad the topic is covered. There are things I didn't mention: the culture, company process and many more. I highly recommend checking the book and find your way.

Right now, I am looking for a way to incorporate this attitude and way of thinking into game programming. The ideology mentioned by Sandro Mancuso sounds to me like a perfect match for games, because it's rapidly evolving, kind of never-ending prototypes where we have to meet the changes in the matter of days or even hours.