Chapter 5 “Heroes, Goodwill, and Professionalism” discusses about learning how to say ‘No’ at the right time and how to be a professional.
At the beginning portion of the chapter, author Mancuso talks about his job in a big multinational company. He was intimidated by the skills of the developers on the team. Since his co-coworkers seemed much better than him, he used to feel like he had to prove himself. At that time, he used to work as an architecture. His team worked very hard for the project. They wanted to show what were they capable of. They wanted to be heroes. Eventually, they realized that they were not acting professionally because they never said ‘No’.
Later on, in the chapter, author teaches us ‘how to say No’. He states we need to say ‘No’ to our clients when they ask us for something we know is not going to work or that is not going to be done by a certain deadline. He makes it clear that every ‘No’ should be followed by a list of alternatives.
After reading the chapter, the biggest takeaway for me is to act professionally. I will not commit to anything that I could not do it. I will be honest with myself, with my team-mates, and with my managers and customers.
The next chapter “Working Software” revolves around the reasons behind why working software is not enough and the impacts of bad software.
Author makes analogy of garden and compares it with code. If we don’t look after our code constantly, the code starts to deteriorate as changes and new features are added. Bad design choices, lack of tests, and poor use of languages and tools will make the code rot faster. He states, as the quality of the code decreases, the amount of time to implement a new feature, fix a bug, or make a change increases. The lower the quality, the higher the number of bugs, and the harder it is to test. The lower the quality, the less robust and reliable the application becomes.
Furthermore, Mancuso talks about the concept of invisible threat which basically means bad code is invisible to everyone besides the developers. Other members of the team only realize that something is wrong when it is too late. That means it’s the developers responsibility to look after the quality of the code.
Moreover, author talks about legacy code towards the end of the chapter. He suggests when looking at legacy code, instead of moaning and getting frustrated, we should try to understand it and make it better, constantly applying the Boy Scout rule of making it better than how we found it.
I absolutely agree that code needs to be well managed over the course of time. We developers need to apply different tools, techniques, and methodologies to keep our code base up-to-date with the latest platform. Also, we developers are the first one to know then something wrong seems to happen with our code. I should fully take responsibility to fix the code in time, and keep the project move forward while keeping it clean.