Reading and Learning 'Clean Code' by Uncle Bob #Day_4

Welcome to Day 4 of the clean series. On Day 3 we discussed points from chapter 2 of the book Clean Code. Today I'll be moving on to chapter 2 of the other book, The Clean Coder. If you are new to this series, please start from Day 1, You can also read this blog first and then go back to Day 1. Day 1 will help you to understand what I'm doing here and you'll also find the books I'm getting my content from. Chapter 1 of The Clean Coder was about defining professionalism and understanding its importance. Chapter 2 will further add on to it. Starting now, you'll better understand what you must consider to be seen as a professional. It is simple but important.

Chapter 2: Saying No

Boundaries. We are often taught that we should set boundaries and say no to things that can harm us. If you have no boundaries you are much more likely to be used and emotionally crushed by other people. Setting boundaries makes you a mentally healthy and stable person. In this setup you often have to say no, even in times when it is pretty hard or even worse you have to say it to a close friend or family member but none other than you know how much it is necessary. An unhealthy person cannot provide for others nor themselves and so everyone is obliged to keep themselves mentally healthy to function constantly. (Did we land on a psychology page? Oh give it a minute I'll connect it)

Similarly, we as developers understand our work better than anyone else can and so we must set boundaries for it too, by saying no. No to the deadline that wants a fully functioning website up in 15 days, No to the manager who keeps pushing you for the deadline of the website, and No to a customer who insists you take their project when you already have a lot on your plate like that website.

So we just straightforwardly say no? What's next? Be direct, and realistic and defend your points no matter how much the other party pressure you. Calmly convey your needs to them and be firm on that, do not compromise with your work simply to avoid confrontation or to escape the pressure. High chances are this would lead to a messy development. Managers will do their work, the business people will do their work, and they are obliged to do as this is their job. Your job is to deliver a good product or service and you know that to deliver a good product it must go through necessary phases. You are responsible for what you make and to protect it, you must learn to say no.

Of course this doesn't mean you have to be rude or stubborn. The book points out that when both parties defend, they can reach a solution that works for both of them. The book explains through a series of conversations between two people, one from the technical team and the other from the management. To sum up, one wants the login page for the demo urgently and the other informs them that it is not possible to get the login page fully working so quickly. Upon defends from both parties, it comes to light that the technical team doesn't have a login page that stores user info or has cookies but it can work as a simulation. The other party agrees to it because they just want to provide the demo to their customers. This particular conversation points out the following:

• By defending, we can get a clear and precise understanding of the priority and requirements.

• Saying no for the sake of the project is good behavior. Imagine customers seeing a messed-up demo (if they rushed to make everything work on the login page). At least whatever amount of work they get to see in the demo, it'll be clean and properly working.

• By defending, we are also defending our team and showcasing the fact that we are not just trying, we are already putting enough effort.

• A good defense is not always a good offense and so passive aggression is unprofessional. The person from the technical team could get offended and get their way back but they chose to find a common ground of working together.

• This is a way to be a team player, something which we hear every now and then but many barely know how to be a team player. The person values their team's work so they don't accept anything that can put pressure on their team and showcase their team effort.

I did not share the actual word-to-word conversation but this is what I learnt from it. I'll now sum up some more points from the rest of the chapter.

• Saying yes to the wrong things can turn out to be very costly. Being professional doesn't guarantee that you'll always be surrounded by professionals as well. Some people can be really hard to handle and they can be your managers or boss. And if we bend and say yes to something we know cannot be done properly, the bill is going to have our name on it.

• Saying 'we'll try' would mean we were not putting our complete efforts before. Saying so would imply that right now we are not putting in our complete efforts but if we do we can get this done. Do you see how that sounds? Why weren't you applying your complete efforts? Did you tell them you'll try and now you'll try by compromising with over-time and messy programs? Be factual and do not bend to something you know cannot be done healthily.

If I try my best and fail, well, I've tried my best.

- Steve Jobs

• In that conversation, the person from the technical team could've explained why they could not get the website up. Why they did not? Because that can be an invitation to the other to micro-manage the technical team. They'll try to tell them what they are doing wrong and how they should do it. Present facts, like the person from the technical team did. How and why are details and they invite for micro-management.

• You must say no when the stakes are higher. Be realistic and factual and even more of that when it comes to riskier and higher stakes. Remember from chapter 1, that you are responsible and accountable for your work.

That's it guys. Keep brushing your skills, ultimately professionalism blossoms from the roots of skills. We are artists, we create and we are the only ones who can understand what we have created and what value it bears. On Day 5 we'll again be discussing a chapter from the book Clean Code. Till then, Happy clean coding!