In this week’s chapters of The Clean Coder, Robert Martin talks about the importance of meetings and when to determine that a meeting is worth your time. He also talks about  the tools we can use to make accurate, sound, and effective estimations.

According to Martin, not all meetings require your time. If you find out that your time could be spent on something more productive, you can politely refuse the invitation. Even if your presence is demanding by someone of higher authority, you still have to determine whether that authority is more significant than your work schedule. Ultimately, your project is priority over many things and you have to manage your time well in order to complete that project accordingly. Martin also talks about “focus-manna” which programming requires a lot of. Essentially, focus-manna is your ability to concentrate and maintain your focus and unfortunately its limited. It is essential that you use your focus-manna appropriately and recharge by doing activities that doesn’t require much focus.

In chapter 10, we learned about estimations. There is a profound difference of how programmers and businesses understand estimations. Businesses sees them as a commitment and programmers view them as guesses. However in reality, it is difficult for an individual to understand the true nature of an estimation. There is an equation used by the Program Evaluation and Review Technique (PERT) to calculate estimations. This was done with trivariate analysis which is consisted of three numbers: Optimistic, Nominal, and pessimistic estimate.

Given these three estimates, we can describe the probability distribution as
follows:
• μ = O+ 4N + P
6

This scheme is designed to help prevent optimistic expectations.

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

In chapter 7,  Robert talks about the communication between professional developers and Businesses. When it comes to a project, there are a lot of information that is needed from both parties. Developers want to know exactly what they’re suppose to do for a project and businesses want to know exactly what they are going to get. This known as premature precision and most of the time this can never be communicated well. Robert mentions that that the best way to remove all ambiguity from the requirements is by doing acceptance tests. This is where stakeholders and developers collaborative writes a test to define when all requirements are actually done.

In opinion, i believe that acceptance testing is an effective solution to eliminate ambiguity between stakeholders and developers. If both parties can come to a consensus of what “done” actually means, then the communication should be great.

Chapter 8 talks about testing strategies. A developer’s should write their program well enough so that QA doesn’t find any bugs in them. Even though QA’s job is to help developers improve their code, developers should always strive to write clean code. It is a great mindset to maintain. This chapter also covers the benefit of the Test Automation Pyramid which list all the test that a professional organization need to write quality code. It includes Unit, component, integration, system, and manual exploratory tests. These tests covers all aspects of a program to ensure their cleanliness.

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

There wasn’t much activity going on this week since our first sprint was over and now we are just waiting for the second sprint to start. I was not in class during the last sprint review and retrospective due to my absence to a religious holiday but from what I have experienced with my group thus far, everything is going fairly smooth. I can’t really say much about the actual lack of work during this first sprint because we are still getting started with everything but I know that future sprints will be far more work-heavy once we start to dive into our portion of the OpenMRS project. For the actual individuals within our group, I think we have a pretty diverse group of students in the sense that there are a lot of different personalities and programming styles so that will definitely come in handy in thinking of creative ways to solve problems.

This next sprint is when we start working on some real programming so I’m really excited for that and I can’t wait for the next sprint review and retrospective because since I wasn’t able to attend the last one, I’m interested to see what its actually like.

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.

This week we finished our sprint with only one task that has to be carried over to the next sprint and that is the angular tour of heroes. We also took the time to review each other based on communication, participation, reliability, and attendance. Ultimately our group was rated well with some room for improvement. For the rest of the week we just had to continue working on angular and openMRS. I did not learn anything new this week however, my team and I are ready for the next sprint.

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

In this week’s chapters of The Clean Coder, Robert C. Martin talks about the importance of test driven development and ways that programmers can practice their art. Robert talks about the first time he became acquainted with TDD. Although he was skeptical at first, he soon realize that TDD had a lot more to offer than just shortening cycle time. There are three crucial laws one must follow when practicing TDD. One, You are not allowed to write any production code until you have first written a failing unit test. Two, You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. Lastly, You are not allowed to write more production code that is sufficient to pass the currently failing unit test. even though these laws does not guarantee perfection in any program,  It is a discipline that enhances certainty, courage, defect reduction, documentation, and design. As professional coder, it would be foolish not to follow these laws because of those benefits.

Moreover Robert explain the importance of practicing. Practicing allows us to keep our mind and skills sharpened and stay up to date. As coders, we should be excited about coding therefore, practicing should be done for the enjoyment. After all, as the author, mentions “Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you. It is not your employer’s job to help you keep your resume tuned”. We are responsible for mastering our craft and the best way to do that is practicing.  Additionally, Robert correlates Coding and martial arts with a series of activities he calls the coding dojo. In a dojo there are several activities such as Kata, Wasa, and Randori. The purpose of these activities are to synchronize the mind and the body to practice the movements and decision involve in solving a problem.

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

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.