In this sprint we are staying up to date with all the tasks we need to get done. We ran into a problem in issue APTS 271 where we could not find the back to drafted form button. There is a form tab on the left hand side of ampath, where we believe the button would be located, but we cannot open any of the forms. This is stopping us from getting anything done. We ended up sending the developers a message in an attempt to fix this issue. In response, we got assigned a test server to work on in which the forms were working so we are able to progress on our issue. Next sprint we can hopefully resolve the issue completely. I think we are starting to work better as a team compared to previous sprints. We are communicating a lot better than we were before this sprint, this helps to get work done in a quick, more efficient manner.

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

Chapter 13 is about teams and projects. It focuses on how work should be distributed through the team and how you actually need to work together as a team rather than focusing on your own problems. It is hard to build a good team, it is better to form persistent teams that move forward from one project to another. To start with, team members start by forming relationships. They learn others strengths and weaknesses and over time the team will start to “gel”. Personally i have experienced what it is like working on a team that doesn’t fit well together. It is a rough time and operations definitely don’t go as smoothly as they should. This is why it is important to have a good team that you are comfortable working with.

Chapter 14 is about mentoring, apprenticeships, and craftsmanship. While it is true that school can teach you the theory of programming, this does not mean that you know everything there is to know about it. School cannot teach the discipline, practice and skill of being a craftsman. The only way to acquire these skills is to practice and to gain them through work. A craftsman is a professional who works in an efficient quick way, and knows when to say no when necessary. This chapter helps put it into perspective what you need to do to become a master programmer. the only way to achieve this is to practice and learn through work experiences.

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

Being a software professional, you need to accept the fact that you will constantly have some sort of pressure on you. Weather that is pressure to meet a deadline or pressure to do something else. Your best option here is to try to minimize it. A couple different ways you can do this is by making reasonable commitments. Do not make a commitment that you are not able to keep, this will make it so that you do not have to stress about not being able to make it, which is a good way to cut down the pressure. If pressure is unavoidable it is important that you don’t panic, and stay calm. Something i thought that was interesting about this is when the book says “Sleepless nights won’t help you get dont any faster. Sitting and fretting won’t help either.” This is a lot easier said than done, it is hard not to stress about something, but if you can adopt this mindset then it will help you out in the future.

Collaborating is also a huge part of being a professional. Most software is created by a team of people rather than one individual. It is true that sometimes working with other people may be a struggle. Working with another person can be unpredictable, and may slow you down in the end. Another problem is when programmers feel like they own the code, and they will not let other people work on it or even see it. This is one of the worst symptoms of a dysfunctional team member. When people think of a software engineer or developer, they often think that they sit in front of a computer screen and all they do is produce code by themselves all day. This is not true. Part of being a software engineer is having to work with people. Even if you do not like it, this is something you will have to accept if you are going to call yourself a professional.

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

Chapter 9 in The Clean Coder is about time management. The first thing it goes over is meetings. While meetings are very important and worth your time to go to , this is not the case with all meetings. In fact, it is actually  considered unprofessional to go to too many meetings, which would not leave time for you to do other stuff. If you find yourself in a meeting that is not worth your time, it would be wise to find a polite way to exit. Time management is important outside of the workplace also. It is important that you are getting enough sleep at night to ensure that you are ready for the next day of work. Caffeine and short breaks can help you keep focused if you are having trouble. It is important for a software professional to keep their options open by keeping an open mind about alternate solutions to their problems. It is not wise to become so vested in a solution that you are not willing to abandon it for a better solution.

Chapter 10 is about estimates. Something that was interesting to me about estimations is when the author said, that business like to view estimates as commitments while developers like to view them as guesses. The problem with the business looking at them as commitments is that the estimates may not always be correct. This may require a developer to work extra hours in order to fulfill this “commitment”. Developers should not make commitments that they cannot meet. When they make a commitment, it is expected that they will honor this commitment at all costs. This is why when developers give an estimate it should be a very well thought out estimate to avoid any complications.

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

We all managed to get the OpenMRS and AMPATH running and working together, every though it took us a while. We did not finish modifying the angular code for the login page, so we will have to throw this back on our sprint tasks. As of now we are all on the same page.

This sprint was a little bit unorganized. Rather than working as a group we kind of did out own thing, and left others behind. In the future i think we should have one person project their screen, and have the group follow what they are doing. This way we make sure that everyone is on the same page. During this sprint some people finished almost all of the tasks, and others finished them almost a week later. This made it hard to progress as a group.

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

This week we were assigned to read chapters 7 and 8 in The Clean Coder. Acceptance testing ensures that the code is working to standards according to the customer’s needs. This is important because sometimes requirements may be ambiguous and up for interpretation. These tests are put in place to set some sort of framework down so developers have something to work around. Sometimes after discussing with the customer, developers may have different ideas than what the customers actually want. Putting these tests in place is necessary because they act as “the perfect requirements document”.

Chapter 8 is about testing. Just because you have a QA department, does not mean you can leave all the errors in your code for them. You should aim for your code to be 100 percent error free when you pass it off the QA. It would be wise to work with QA to create unit tests, component test, integration test, system tests, and exploratory tests. It is important that you use all of these testing strategies to make sure your code stats bug and error free, and it working to standard.

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

Chapter 5 in The Clean Coder is about Test Driven Development. There are three laws when it comes to Test Driven Development. They are:

1.) you are not allowed to write any production code until you write a failing test.

2.) you are not allowed to write more of a unit test than is sufficient to fail, and not compiling is failing

3.) and you are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Following these steps makes it so that you have to test the code every step of the way. This can avoid all the errors being thrown at you at once if you don’t test till you are done writing your code.

Chapter 6 is about practicing your coding. It is true that it is your job to keep your skills sharp and not your employers. Therefore practicing should be done on your own time. The example of a surgeon not being paid by a patient to practice before going in to the surgery room was made, and it helps put things into perspective. Keeping your skills sharp, and your resume tuned, should be done on your own time.

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

This week we reviewed what we did last sprint. We completed our peer evaluations, which were all good, but at this point it is hard to tell how our peers are doing because we haven’t done much collaborating. We all did a good job keeping up with the tasks that needed to be completed for this sprint. We also god a overlook on what we were going to complete next sprint, this next sprint was all about setting up AMPATH and OpenMRS and modify some existing code to get it working. Next week i plan to successfully re structure the code and get it working, as well as getting AMPATH and OpenMRS working. This week was kind of slow in terms of work that needed to be completed, so i looked at some more angular stuff.

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

This week was a productive week for me. Last week I got a basic understanding of what AMPATH and OpenMRS are. This week I focused on Angular 2, and getting up to speed with the language. I noticed that a lot of things are similar to HTML which i know a decent amount of. The fact that these two languages tie together will help me learn it faster in the long run. A couple things that held me back in the beginning were setting up my programming environment, and a couple things in the Hero’s tutorial that took me little while to figure out. But it was all part of the learning experience and I feel like I came out of those problems more knowledgeable than I was before. In weeks to come I plan to master Angular 2 to prepare for the projects to come.

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

This week we were assigned to read chapters 3 and 4 in “The Clean Coder” book. These chapters brought some things that I didn’t realize I did to my attention. First of all, in chapter 3 it talked about key words that people use that implied that they can’t or won’t get something done. Saying something like “I’ll try to get it done” is a lot different than “I will get this done”. I fall victim to saying I will try to do something or I should do something, and knowing in the back of my mind that I will most likely not get it done. 

In chapter 4 something that surprised me was when the author said to avoid the zone. It makes sense why he would say this. In the zone, you are focused on one thing, and that is to get as much code done as possible. The setback with this is that you lose sight of the bigger picture and in the end, the code will come out with a lot more bugs than if you were not in the zone. For this reason, developers should try to stay out of the zone. 

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