The fifth chapter reminded me of chapter 2 in The Clean Coder. I wrote about this in my blog https://rmurphy12blog.wordpress.com/2017/01/25/week-1-the-clean-coder-ch-12/ An important skill to master is the ability to say no. The act of saying no can save you from getting into trouble.

Chapter six is titled “Working Software”. In most cases the code you are working on is going to be around for a while. This means is is just as important to write code that is maintainable as it is to write code that preforms the required task. If code is written in hast, without proper planning it is going to end up costing more time in the long run. I have found this last statement to be true. I once wrote a piece of software rather hastily and did not write a single comment, a few months later I was asked to make some changes to the program. The changes should have been simple, I was just going to add a few features. When I started looking through the code to become familiar with the code I realized there was much I could not remember. I ended up spending a lot of unnecessary time on the project because the first time around I was in a rush.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

In the third chapter of The Software Craftsman, Sandro Mancuso discusses what it means to be a software craftsman. One of the first ideas brought up is to be a software craftsman you must be a professional. The topic of professionalism is covered in several of my earlier blogs as it was one of the main themes of The Clean Coder. As a craftsman you are always looking to hone or refine your skills.

The fourth chapter is all about the attitude of a software developer. A true craftsman really cares about there work, the take pride in it. I believe this is very important in all jobs. If you don’t take pride in your work you are more likely to have issues of all sorts.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

This week I began reading the second book of the semester. The book is titled The Software Craftsman and was written by Sandro Mancuso. In the first chapter the author speaks about two items. The first is how the field of software development has changed over time. The second topic covered is the idea of seniority. The author points out that seniority is not something you can earn and then just ware the rest of you life, seniority is relative. He also lays out a set of questions that relate to seniority, they are as follows; Senor to who? In what technology? In what context? This part seemed a bit obvious and way he explained we different than I have thought about in the past. I have always seen seniority as specific to a job or company. Your position in the company defines seniority. If some one is hired for a position that is above others one there first day they have some level of seniority even if the have no experience.

In the second chapter of the book the author writes about the agile development methodologies. It began with a group of seventeen members of the technology. The were looking to change the development process. This new set of methods centered around the team. Throughout this semester we have been working in Scrum teams, this is an example an agile development process. The experience this semester has been pleasant.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Chapter 13 continued with the theme of collaboration, more specifically team work. A lot the what I wrote in my last blog applies to this. There were two points that really stuck out to me. The first was the idea that a person should not try to split their time between two teams. The second idea is the team should not be put together an a project by project basis. You should build a team that works well together and keep them together on project after project. As the author says ” Teams are harder to build than projects.”

In the last chapter of this book the author talks about how he was disappointed be many CS grads he had spoken with. He said many college programs don’t do a good time preparing students for industry. I understand how it is hard to create a situation in class that emulates industry. Although, I do think this cap stone is coming as close as possible. I think the hardest part is time. This is on class, it is a lot different when you are working full time at a job.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

In chapter 11 of The Clean Coder, the author writes about pressure. Everyone handles pressure in there own way it can be a deciding factor in determining how professional some on is. A true professional should be able to keep calm under pressure, they should maintain the the ability to make decisions without panicking. I personally don’t mind working under pressure especially in the context of class assignments. This turns out to cause issues for me as I tend to wait until the last moment to start an assignment. I then use the pressure to force myself to focus. On some group assignments I have noticed how others react differently. In one example, I was working in a group with two others, one who procrastinated like myself and on how started panicking while we still had a week and a half. In this situation I really saw how pressure affects people differently. I have also watched some people react in extreme ways. At the small Internet company I worked at one of the employees had called out. Because of this I and another employee were asked to help with shipments. I knew how many shipments needed to go out and how much time I needed. I told the other person that I could handle it myself and not to worry about it. At one point my coworker started to help claiming I would not finish in time. Within a few minutes she started to panic and rush, this cause the packing process to become a mess. It came to the point where just decided to give up and ended up leaving the office early. I finished the packing with 45 minutes to spear. In many situations it is probably better to just avoid pressure. Many of the ideas in earlier chapters can aid in this, for example, not committing to a deadline you know is too short.

Chapter 12 was all about collaboration. I believe this is a very important topic in the field of computer science as most developers work in a team. I can see how working on a team can difficult and rewarding at the same time. There has been several times I have been working on a project and found myself stuck, in these situations it is good to have a team or at least a partner. Sometimes I just need a bit of help getting past a issue, other times the simple act of explaining the problem was enough for me to come to a resolution. I think the most important element with in a team is trust. For a team to function efficiently each member must be able to rely on the others.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

In chapter 11 of The Clean Coder, the author writes about pressure. Everyone handles pressure in there own way it can be a deciding factor in determining how professional some on is. A true professional should be able to keep calm under pressure, they should maintain the the ability to make decisions without panicking. I personally don’t mind working under pressure especially in the context of class assignments. This turns out to cause issues for me as I tend to wait until the last moment to start an assignment. I then use the pressure to force myself to focus. On some group assignments I have noticed how others react differently. In one example, I was working in a group with two others, one who procrastinated like myself and on how started panicking while we still had a week and a half. In this situation I really saw how pressure affects people differently. I have also watched some people react in extreme ways. At the small Internet company I worked at one of the employees had called out. Because of this I and another employee were asked to help with shipments. I knew how many shipments needed to go out and how much time I needed. I told the other person that I could handle it myself and not to worry about it. At one point my coworker started to help claiming I would not finish in time. Within a few minutes she started to panic and rush, this cause the packing process to become a mess. It came to the point where just decided to give up and ended up leaving the office early. I finished the packing with 45 minutes to spear. In many situations it is probably better to just avoid pressure. Many of the ideas in earlier chapters can aid in this, for example, not committing to a deadline you know is too short.

Chapter 12 was all about collaboration. I believe this is a very important topic in the field of computer science as most developers work in a team. I can see how working on a team can difficult and rewarding at the same time. There has been several times I have been working on a project and found myself stuck, in these situations it is good to have a team or at least a partner. Sometimes I just need a bit of help getting past a issue, other times the simple act of explaining the problem was enough for me to come to a resolution. I think the most important element with in a team is trust. For a team to function efficiently each member must be able to rely on the others.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Time management is a topic that spans all fields. I would argue it is one of the main keys to being productive. There were several items that stood out to me in chapter 9. Two of the biggest were about meetings and what the author called “Focus-Manna”. Working as a system administrator I couldn’t guess how much time I wasted in either pointless meetings or in meetings where the reason for the meeting had nothing to do with me. Most of the time I was forces to sit in the meetings by my supervisor and explaining why I did not need to be in the meeting was almost alway fruitless.

Time estimation is also a topic that applies many fields. Before returning to study computer science I went to school for cabinet making and carpentry. In the program there was a course dedicated to estimation. This course included the estimation of time(which is directly linked to cost) and material. One of the first things we were told as inexperienced estimators was to come up with the best estimate we could and then double it. Prior to taking this course I had been working in the field for about 2 years and found this to be pretty accurate. Now in the field of computer science I see the same issues with time estimation. I believe the root of most estimation issues is the tendency to over simplify the tasks. I like the point the author makes about making clear this is an estimate and not a commitment. One thing I learned in while working is to stand you ground on. Many times I would be working on a project and the supervisor would ask “How much longer until completion?”, I would then give an estimate of what I thought it would take me, the supervisor would then say “Well it shouldn’t take that long.” and proceed to explain why there time estimate is so much shorter. If I agreed that I should be able to complete the task within the shorter period of time I would almost never finish on time.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

This reflection wraps up the final sprint. At the beginning of the sprint I was excited, we had a full description of the issue, knew the requirements, and had decided where to move the button. During the end of the last sprint I worked on adding a new item to the top menu, this was very easy. I ended up putting a place holder in the menu. The next task was to look into the how to only allow the button to be seen if there was a drafted form, this was also easy as the was the original behavior of the button. With the first to tasks seeming rather easy my focus changed to what needed to be done to move the button. I used grep to look through all the files and made a list of files I thought needed to be altered. Once I had this list, I decided to try removing the button from its current location, this cause issues. When I removed the single line containing only an open and close tag for the button, the entire site stopped working. After a short discussion with a member of a different team I realized the element I removed was responsible for some of the routing. My next aim was to determine what I needed to do to import the back to drafted form module in to the main dashboard module where the top menu bar was held. I tried several things to move the button and its code but with each attempt I found it caused a new issue. One of the problems I thought I had caused was the button no longer brought you back to the drafted form. In fact, when you clicked the button, it prompted you with a message saying there was an unsaved drafted form, re you sure you want to continue. This message was clearly out of place as the whole reason for clicking the button was to bring you to the drafted form. On top of the message being out of place, clicking either yes or no destroyed the form and left you on the current page. Not being able to pinpoint what I had done to cause this problem I decided to pull from the original AMPATH repository. After doing that, I realized the issue was not my fault but an issue the main project had.  I had on other team member try on his computer just to rule out my machine as the cause I opened a bug report in JIRA.

Over all I have enjoyed my experience working on a Scrum team. The on regret I have is not being able to fully commit my time to this one project. Once I have graduated, I do plan to continue working on the AMPATH project. It is nice working on an open source project that will impact the lives of people around the word.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

After last sprint, we received more requirements about the issue we were working on. The task became move the “Back to Drafted Form” button to a more convenient location and fix it’s position relative to the screen so that it is always visible. This means the button should not move as the user scrolls on the page.Once we had the updated requirements wee needed to do a little bit of planning. The big question was where should it be located. The most simple option would have been to leave it in it’s current position, fix it’s location on the page, and bring it to the top. This option was quickly dismissed as the team did not think it would be aesthetically pleasing if it floated above the other content on the page. As we thought about it more we realized there was another factor to keep in mind, this application was going to be used primarily on an 8 inch tablet. An 8 inch screen does not provide much real estate to work with. With that thought in mind we realized there was only two places on the page that made sense. The first spot was in the top menu, this is where the main navigation was handled. Items like user settings and logout, location, and patient search. The second location was on the left menu. This is where information related to the current patient could be accessed. Both options shared a similar upside, they are both fixed on the screen as it is. This means we would not be waisting any more space. Because we did not see an obviously winner we turned to those who would be using the system, the response we got was “try both and see what we think”. After that response I thought about the problem a bit more, my first instinct was the side menu as that is where items related to the current patient could be found. The problem with this was, depending on the patient, the number of items in the list could change. There was also the issue of the menu being semi consolable, this would mean all you could see is an small icon. The more I thought about it the more I convinced myself the top menu was the best choice. The menu was not full and could easily fit the button. I also liked the idea of it being near the controls to navigate to a different patient and to logout. These are prime examples of times you would want to save a drafted form. With this rational, I explained conclusion to the team and started looking in to what code needed to be changed.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

This sprint started off well, then we experienced how the description of an issue don’t always convey the full story. Our team “finished” what we needed to do on the issue that started in sprint 3 and carried over to this sprint. The issue we chose had to do with the location of a button on the screen. The description read, “Users are requesting if the back to drafted form button can be moved to a more convenient place for easy navigation e.g near the control menu.” With this description in mind one of the team members moved the button. I then merged the change with the latest version of the AMPATH project, set up Travis-CI, and deployed the change. After program built on Travis-CI we put in a pull request. We received a response the next day stating that they would actually like the button to stay in a fixed location on the screen while scrolling like the top bar and side bar. I believe this was a good example of the importance of communication

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.