Fragments of the book, “The Software Craftsman. Professionalism, Pragmatism, Pride”, written by Sandro Mancuso.
The Software Craftsmanship Attitude
“In all these years, they never bought me a book. Never sent me on a training course, and never gave me a project using modern technologies. They never gave me a promotion neither”, he said. “I haven’t learned anything new for quite a long time”, he complained.
I was not quite sure what to think or say about his comments. I had two promotions during that period, worked on quite a few good projects, and learned many new things. “Who owns your career?”
We should use our own time and money to get better at what we do. We should own our own careers and be in control of what we learn and when we learn. Developers who rely on their companies to provide them knowledge are not professional software developers. They are just factory workers in disguise.
In creative work, the employer/employee model is the wrong model.
Deliberate Discovery
Not knowing that we don’t know is also called second-level ignorance. Accepting that we have a lot to learn is a sign of maturity and one of the first steps towards mastery.
Ignorance is constant. Ignorance is the single greatest impediment to throughput, meaning that if we reduce the level of our ignorance as fast as we can, we can be far more productive and efficient.
Work-Life Balance
Quite often, lack of time is used as an excuse for our own laziness.
Time should never be used as an excuse for not doing certain things. Ever. We all have time. In fact, we all have exactly the same amount of time. The difference is how we choose to spend our time.
Learning To Say No
Chad Fowler says that saying yes to avoid disappointment is just lying. He even goes further to say that saying yes is an additive and destructive habit. It’s a bad habit masquerading as a good one.
Providing Options
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 juice and apple juice. The pineapple juice is fresh but the apple juice is bottled. I also asked and discovered that there is a supermarket a little bit further away where I could buy some fresh oranges and could make you fresh juice. I can get you a pineapple or apple juice in 5 minutes, or if you prefer, I can make you fresh orange juice in 30 minutes. I just need to know what you prefer.
The second assistant gave him options and now he could make a call which one was the best alternative for him. A can-do attitude is always appreciated and, even when we say no, we should always be striving to say yes.
The Wrong Notion of Time
The biggest problem here is that bad code is invisible to everyone besides the developers.
Dedicated QA teams are anti-patterns. Testers should find nothing. Zero. Nada. Testers can be extremely valuable to explore our applications in unexpected ways, ways that just a human can do. But testers should not waste their time executing test plans that could be automated by the development team.
Pragmatism
Refactoring without pragmatism can be a dangerous practice. Dogmatic thinking is bad. The best way to know if one practice is better than the other is to compare the value they both bring to the project, then compare how long their feedback loops are. Nothing else should matter. For practices that give us similar value, we should choose whatever the team is more comfortable with. Nothing should be set in stone. Choosing to adopt a practice does not mean using it forever.
The Long Road
“You’ve got to be careful if you don’t know where you’re going because you might not get there”. We, software craftsmen, value and control our careers. We understand that a career is a life-long journey that, depending on the choices we make, may or may not lead us to mastery.
“The Peter Principle”: employees tend to be given more authority until they cannot work competently. In other words, through political games, misappropriation of credit, hiding incompetence by blaming others, and often unprofessional and dishonest attitudes, some people are promoted to positions for which they are totally incompetent.
People whose skills are obsolete worry about not finding another job where they can keep their salaries and personal life stability. Only incompetent people are scared to lose their jobs.
Culture of Learning
Let’s not underestimate a manager’s ability to make things worse. To make sure people would comply with the new (and imposed) way of working, managers would make them part of people’s objectives and bonuses. However, when it comes to software development, this approach can lead to disastrous consequences.
We will never change an organization by forcing people to adopt a new process or different practices. Instead, we should create a culture of learning, where people can find their own motivation to make things better.
Creating a culture of learning is one of the most efficient ways of injecting passion into a company.
- Conduct Group Code Reviews: group code reviews are another very interesting way to create a culture of learning.
Driving Technical Challenges
Real software professionals understand that responsibility should always come with accountability. If you want to be responsible, be prepared to be accountable. If you are accountable, make sure you are also responsible for the decisions.
Ivory-Tower Architects are usually scared of their own decisions, hiding behind bureaucracy and politics in order to succeed in their careers. If you want them out of your way, try to make them accountable for their decisions.
Pragmatic Craftsmanship
Regardless of which decision you make, even if you choose the low-quality one, you will always hope for quality. You will always hope to not have any problems with the service you paid for. And that is exactly how managers and clients think when paying for a software project. They may decide not to pay for quality and ask for a quick and check solution, but deep inside, they will always be expecting quality and won’t be happy if they don’t get it.
Improving your system with small but constant refactorings, justified by necessary changes to the system, is a good and more pragmatic way to improve an application.