Category Archives: cswsu

Week 10: The Software Craftsman, Ch. 5 & 6

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.

Week 9: The Software Craftsman, Ch. 3 & 4

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.

Week 8: The Software Craftsman, Ch. 1 & 2

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.

Week 7: The Clean Coder, Ch. 13 & 14

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.

Week 6: The Clean Coder, Ch. 11 & 12

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.

Week 6: The Clean Coder, Ch. 11 & 12

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.

Week 5: The Clean Coder, Ch. 9 & 10

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.