Coming back from spring break not much was done on my end regarding issue 184. However, our team have decided that each member should pick there own issue to solve. After I’ve updated the module from the team’s repository, i came across an issue and couldn’t connect to the server. Because of that, i spent some time trying reconnect to the server. I received help from Haider who was familiar with this problem.

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

During this sprint i spent most of my time navigating through the ng2 module to get a strong understanding of it. Our  team spent time solving  issue NGPOC-184 and unfortunately we did not finish on time for the sprint. For me personally, i need to get a better understanding of Angular 2 to actually contribute significantly. Since this is a senior level course, we are given a lot of freedom with the expectation that we would be responsible enough to learn, communicate, and produce meaningful results within our groups. However, that is not the outcome of our team as a whole. We are about halfway through the semester and it’s not to late to pick up some of the slack.

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

Nowadays every is all about being agile. I’m sure that if we were to look at a scale of how technology has grown within the last decades, the rate of growth is exponential. This is what makes agile so important; the ability to adapt and change with the nature of software projects. In order to effectively be agile, you need to master BOTH the methodologies and the craftsmanship. To me, this chapter was relatable because as of lately, I do feel as though I’ve only been doing one out of the two; which is the methodologies. I would say I have the Scrum methodology followed pretty religiously but yet there is barely any progress because I am missing the craftsmanship. I am not doing enough research and coding to help better deliver the software we are working on and after reading Chapter 2 I truly realize what I have been doing wrong all this time. Even the author said it, “improving the process without improving technical excellence is pointless”, and he’s absolutely right.

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.

We have reached the final chapters of the book. The last two chapters talks about teams, projects, mentoring, apprenticeship, and craftsmanship. Even though these two chapters are very brief, there are a lot of important facts and key points that we can take into our careers.

The first chapter talks about working in teams that will sometime consist of programmers, project managers, analyst, and testers. The book explains a concept called “gel” where each members of the team learn each others weakness, strengths, and quirks. It can take a really long time a team to really gel. I can relate to this because i work in teams all the time during school and we don’t always work effectively during the beginning stages. This why a team working on short projects that requires a portion of your time never really learn how to work with each other efficiently. And this is why it is important to form the team before the project; the collaboration will be much more effective depending on the teams experience with each other.

The last chapter of the book starts with the fact that it easy to wiggle through the system and graduate with a degree in Computer Science. Nowadays, Most of the curriculum doesn’t really prepare students for what they will face in the industry. It is important to have a mentor with years of experience working as a software engineer that can teach us what to value and how to behave. This chapter separate programmers into three categories master, journey, and apprentices/interns.  Newly graduates should always start as interns or apprentices. From there they can learn, grow, and gain experience to work on complex projects.

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

In Chapter 11, Robert Martin talks about pressure and the methods we can follow to handle pressure as software engineers. Being under pressure is something that can either make or break an individual. It is how we handle pressure that defines us as professionals; even in the toughest times a professional must not show signs of distress. Some of the ways that Martin suggests we can manage pressure are avoiding it to began with, not making reckless commitments, and staying clean. Now, I am kind of puzzled that Martin says to avoid pressure because I don’t think anyone purposely tries to put themselves in situations that causes them unmanageable pressure. If we avoided we won’t have to deal with it however, pressure will always find us. These advice are not only applicable to professionals and software engineers, we can also use them in our daily lives to keep manage the distress that derives from being under pressure.

Moreover, Martin talks about collaboration in chapter 12. Collaboration is an essential part of being a software engineer. Most of the programs that engineers works on will always consist of a group of people because there will always be a ton of thing to do. Within that group, there has to be great communication, teamwork, and most important professionalism. Even though at times there will be people that are tough to work with, we have to find a way to strengthen the teamwork. Ultimately, working alone is not always the best choice; when we put our heads together the outcome should be much greater.

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 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.