The 3rd chapter “Saying Yes” from the book “The Clean Coder” by author Robert C. Martin, revolves around the language of commitment. Martin introduces one of his colleagues, Roy Osherove in order to give a better judgement and analysis of the words Martin said during his workdays “I’m committed . . . I guess.” Osherove thoughts clearly indicates that the statement as a bad one. He talks about the three main points of commitment.

1. You say you’ll do it.

2. You mean it.

3. You actually do it.

For most of the times, till now when I, myself commit to do a certain task I just thought to do it at some point in time. But, now I came to realize that I was just following step 1 and step 2 at most. From now onwards, I will be very sure on my own commitment that I actually Say, Mean, and Do.

Furthermore, Osherove clearly defines signs of non-commitment such as the words: Need\should, Hope\wish. Luckily, I wasn’t using those for making my commitments, so I considered to be on the safe side. Although making a dialect commitment may sound somewhat unnerving, it can help take care of a significant number of the correspondence issues. On the off chance that you can’t make your commitment, the most critical thing is to raise a warning as quickly as time permits to whoever you focused on.

Moreover, chapter 3 has more to offer on learning how to say “yes”. Professionals are not required to state yes to everything that is asked of them. However, they ought to strive to discover innovative approaches to make “yes” conceivable. After reading this portion of the chapter, I will bear the responsibility to maintain certain standards. I learned where to draw the line of professionalism with regard to family (hopefully in future) and my working time. I should be clear about the work-load, overtime, and ultimately the cost of it.

Chapter 4: “Coding” discusses the act of coding, and the context that surrounds that act. The main theme of this chapter is that, “Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.” Author Martin has different way of coding, so do I. He believes his creative output are usually generated with driving home and while taking the shower. Meanwhile, he doesn’t mix his music with coding. Writing about myself, I found myself productive when I am more close to nature and its surrounding.

With that being said, coding does requires many competing factors at once. First and foremost is that the code must work, and must fit well into the existing system. It also must be easy to read by other programmers. Some of the times I found myself not writing the complete code and just leaving in the middle just because it’s too hard. For this, from now I will seeking for a help to get my project move forward. Furthermore, a simple external force interrupts my coding time. Next time, as the author suggests pairing can be very helpful as a way to deal with interruptions, I will find a partner to reconstruct the mental context I usually have before interruption.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

In chapter 3 of clean code, it was interesting to read his thought on switch statements. As someone who uses a lot of switch statement, it does look very ugly when it is inside your larger code class. It was a common mistake for me in the beginning of coding to have these huge switch statements inside the code. When things need to be changed, I would have find the switch statement inside my code and change it. The solution in the book is to use an abstract factory to hide the switch. However, even then it says the statement are only tolerated if they appear once and are used to create polymorphic objects.

In chapter 4 on comments, the book states that comment does not make up for bad codes. I chuckled when reading that as it was something that I’m guilty of doing.  There are codes I written where I comment that the code is a mess here and I will fix it later. Of course, I rarely ever go back and change it. It is a hard habit to fix especially since you know the code works, although it looks ugly and maybe a bit inefficient. Cleaning it up will benefit you and people who will read the code in the future.  The more you put it off, the less likely you will go back and change it. Commenting with a “will clean up later” just further exacerbate that problem. It is something I should work on in the future.

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

This week in the software capstone, I went through the AngularJS tour of hero tutorial. It was an enjoyable and well-made tutorial that introduce beginners to Angular.  The tutorial basically goes through the design of a small part of a video game. You are basically building an UI with data driven application to manage different heroes, hence the name tour of hero. It goes through both the HTML elements of the UI and how to bind our data to the template.

It also goes through using services and also navigating our UI through routing. Finally, it goes through providing HTTP services and connecting to an API server. However, in this case it is just a simulated API server. Overall, it was a very well made and fun tutorial to do. It is good for people who have no Angular or JavaScript experience. It is also interesting enough that if you want to refamiliarize yourself with Angular or JS. This tutorial is great for that also.

Other minor things that were done includes introducing to the OpenMRS team and setting up Trello.

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

In the first two chapters of Clean Code, the author talked about using meaningful names in your code. In many codes, you will see arbitrary names that will make no sense at all unless you are the author.  This is especially a troublesome thing in legacy codes where there is no way to reach the author of the code. The person that was brought on for maintenance or update then must spend a huge amount of time to understand the code. It becomes even harder when the code has syntax that is hard to understand.

Sometimes syntax usage is unavoidable especially in a corporate setting. When going into an existing project as a new member of a team, there is going to be a lot of company jargons that will be present that you must read up on and understand.

Most of what is written is basically common knowledge for me at this point, don’t use slangs, or random symbol, etc. However, in the final paragraph of chapter 2, it also says that good names require a shared cultural background many times. This is interesting as it is not something I have really thought of. Many tech sectors employ people from many different nationalities, especially India. The different cultural background may affect how to comment and name your code, since something that is common knowledge in America may not be elsewhere.

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

Week 1 there were just some initial set up of Slack and learning what we are going to do for this project. Set up with Slack was simple. We decided not to have any leaders at first since we are currently not even sure what project we are doing. We know we are going to use AngularJS so we should plan and learn/refamiliarize with the framework.

Once we are more involved with the OpenMRS project, we will figure out what to do with Scrum, meetup, deadlines, etc.

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