In this book, Bob Martin defines what professionalism is in the software industry. This is a “soft” book because its focus is mainly on people,work ethic, relationships and attitude (soft skills) and the impact that they have on code, technology and business. I would dare to say that for Bob Martin technology is not the principal issue for writing good code. The issue for Bob Martin is work ethic, which is reflected in the professionalism of individuals.
For Bob Martin, professionalism is about taking responsibility. This should manifest in several areas: first, we (as developers) should be responsible for the bugs that we create. Although making perfect code is impossible, we are still accountable for the code we produce and we should make sure that past errors should not be repeated. Instead, we should test our code as much as possible to ensure that, to the best of our knowledge and efforts, it works and it will work in the future. Taking responsibility also applies to architecture choices. The idea is that every intervention in the code should make it more flexible so that the code might be changed easily and without incurring exorbitant costs. So for Bob, we should strive for continuous improvement in the code and the architecture – something he calls the “Boy Scout rule” (always leave the camp cleaner than how you found it) or simply “merciless refactoring”.
Perhaps what was most interesting for me in the book was the second way that developers should take responsibility: we should take responsibility for our careers. It is not our employer’s responsibility to make us marketable; neither is our employer’s responsibility to train us nor sponsor conferences or buy books for us. Neither is our employer’s responsibility to give us time to learn. We should be grateful when that happens, but the employer is not obligated to do it. The responsibility for our careers is on ourselves.
Hence, Bob Martin comments that we should spend 40 hours working for our employer, but at least 20 hours working for ourselves. The first 40 hours should be spent solving our employer’s problems exclusively! While in the other 20 we should read, practice, learn and enhance our career.
Part of enhancing our careers (i.e. improving ourselves) involves 1) knowing our field and 2) knowing our domain. Knowing our field means that we should possess basic knowledge of programming. This involves topics like mastering the 24 design patterns; mastering the SOLID principles; understand methods like Scrum, Lean, Waterfall etc.; Test Driven Development, CICD, Object-Oriented Programming etc. Besides, in knowing your domain he argues that programmers should understand the sector of the economy for which they are building solutions. This means we should be versed in the construction business if we are doing software for a construction company.
And of course, Bob stresses the necessity of continually practicing our tech skills: “when performance matters, professionals practice”. However, the author is emphatic in that professional programmers practice on their own time! It is not our employer’s job to help us keep our skills sharp for us. It is not our employer’s job to help us keep our resume tuned. Basically, “Practice is what you do when you are not getting paid.” As a consequence, professional programmers distributed their time to make sure that their time at the office is as productive as possible.
Besides, he also comments that we should identify with our employer and our customers. The first responsibility for a programmer is to meet the needs of his employer and hence collaborate as much as possible with other team members, managers, analysts, QA, etc. It is very easy to fall into the false dichotomy of “us versus them”: developers versus managers. Instead, we should look for the welfare of our employer, his company and our team. We should architect and code solutions that benefit the enterprise, not necessarily ourselves. And we should always look for the benefit of the company we are working in.
However, Bob also teaches that developers need the courage to “say no” to their managers. He mentions something very interesting: For developers, an “estimate” is a guess of how much time some task or project will take, but for managers, an estimate is a commitment. Several problems between developers and managers arise due to that simple difference. One of the most interesting advice that Bob gives to developers is to beware of managers asking the “at least can you try?” question. I let you read that part of the book by yourself.
However, when you need to give an estimate, Bob provides several techniques to improve your and your team’s ability to estimate the time a task will take. For this, he recommends using the PERT method, Flying Fingers, Planning Poker or Affinity Estimation. PERT consists of splitting the project into several smaller tasks, evaluate how much time they will take in the best, the most likely and worst scenario, and then estimate the expected value assuming a triangular distribution (he give the formulas). The other methods involve discussing with your team every task and try to arrive at a consensus of the time the activity would take.
Finally, I would recommend this book to all software developers. I think the author does a great job sharing the insights he has acquired in his 42 years of experience. What I think the most important contribution of the book is that it helps us see that there is a wide room for work ethic in the software engineering field. Being professional is about ethics, and ethics is displayed in our behavior, in our code, and in our relationships with other developers, managers and the company we work for.
