The previous chapters in the Clean Coder book talked about professionalism and saying no. This week, the book zooms in how “saying yes” and coding principles that might be useful to follow. Before going into the chapters, something I’ve realized that I hate but also love about this book is the fact that is partially opinionated. What I mean by that is, for example, in chapter 3 the author talks about the different situations and scenarios in which you would say yes and really mean it and other situations where you might not want to say yes because you know you might not be committed to it. In this case, its pretty much straight facts in the sense that the chapter only talks about saying yes and the commitment that comes with it. There’s not really anything that is up for debate. On the contrary, in chapter 4 the author talks about coding principles that he believes one should follow to become a better professional and to write good-clean code. However, in this chapter it is more opinionated because not everything he talks about is applicable to all programmers. There are some tips that he gives that may work for one programmer but may not work for other programmers.

Going back to my original thought; the reason why I hate and love this style of book is because even though it provides facts, there are also times where you as a reader have to determine for yourself if what he is saying is applicable to your style of programming so its not just another book that is just a computer science textbook, its somewhat like a conversation where sometimes you agree and sometimes you disagree.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

In our last chapter we focused on the importance of saying No as well as when and how to say no. Well, this chapter shows that knowing how to say yes in certain situation can also solidify our title as professionals. Saying “yes” is a verbal commitment and Roy Osherove splits it into three parts:  saying you’ll do it, meaning  it, and actually do it. The first part is easy for an individual to say. Saying you will do a certain task doesn’t not always signify that you mean it and it doesn’t always lead to completion. So how do we know who is actually committed? Well, we can confirm whether an individual is actually committed by  identifying their choice of words. Using phrase like “We need to get this done”, “I hope to get this done”, or “I Wish i had time for that” are all phrases that shows signs of non-commitment.  A person who is actually committed and takes responsibility for things would avoid using words like need, should, and wish. Instead, they will start their sentences with “I will” to express their commitment. Thus, putting them in a situation where they are obligated to getting the task done.

When saying “yes” we must consider all the possibilities such as deadlines, estimations, and our well-being. As a professional we can’t just simply say “yes” when we have to sacrifice discipline. Breaking discipline will only make things harder. The book gave an example of an employee named peter who was in a situation where he was considering sacrificing discipline to meet a deadline. It states that:

 as a professional he has a responsibility to maintain certain standards. His code needs to be tested, and needs to have tests. His code needs to be clean. And he has to be sure he hasn’t broken anything else in the system.

We have responsibilities as developers to make sure under any circumstance, that our code is near perfection before release.

This leads to chapter 4 of the book which talks about coding and rules that can be followed. I can agree that working working when you are tired will not lead to a clean and applicable code. The best time to code is when your head is clear, when you’re well-rested, and in a decent mood. I listen to music all the time while coding. It was a surprise to see that the book mentions that it is actually not productive to listen to music while coding. I find it funny that the author accident wrote the lyrics of a song in the comments of his code. Even though that hasn’t happen to me, I’m sure it can happen in the future.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

In this weeks reading of The clean Coder, we read Chapter 1&2 which talks about the importance of professionalism and saying “no”. In the software development field ,some important aspects of professionalism are taking responsibility, being knowledgeable about your field, and having work ethic.

So what does it mean to be a professional?. A professional knows their job is as important as it gets and all their actions can lead to certain consequences. As developers, we must be responsible for staying up to date on our profession and continuously keep growing. No matter how tough and frustrating our job gets we are responsible for getting the job done right. The book makes a good point by mentioning that “The human body is too complex to understand in it’s entirety, but doctors still take an oath to do no harm. If they don’t take themselves off a hook like that, how can we? Doctors knows the consequences of mistakes and fights to prevent them. If we are truly considered professionals,  we can do the same.

Moreover, as a professional, we are required to be extremely knowledgeable about you field. Customers will expect you to know what you are doing and do your job flawlessly. We are held accountable for the quality of our work. As professionals, we have no rooms for mistakes; we must minimize our flaws as our careers advances. The way developers can ensure that there mistakes stays at a minimum is to test their work over and over again. Quality assurance is a huge part of professionalism.

I never knew the importance of saying “no” in the software development field, until i read about it in the book. During our career there  will be times where we are pressured into doing things that are just not feasible. It is up to a professional to stand their ground and face confrontation in order to make the right decisions. It is important to be realistic on the difficulty of our job and to be upfront about it no matter how tough it may be. It is better to let your boss know that a project is not ready than to delivering the project knowing that it’s not fully complete or tested. This will save a lot of money and avoid having pissed of clients in your hands. As the book mentions, it is foolish to deliver function at the expense of structure.

From the blog CS@Worcester – Site Title by adestinyblog and used with permission of the author. All other rights reserved by the author.