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.

The Software Craftsman, Chapter 9 & 10

For this week, I read Chapter 9 Recruitment and Chapter 10 Interviewing Software Craftsmen, from the book title The Software Craftsman by Sandro Mancuso. Chapter 9 takes a look at the picking process of hiring the best developers. Best developer’s identification is that developer must be passion for the craft. Chapter 10 explains the interviewing process that works both ways, the interviewer (who represents the company) and the interviewee (potential hiring candidate) looks for compatibility with each other. The interviewer checks whether the candidate is best fit for the company and the interviewee try to find out whether the company is best fit for him/her.

Chapter 9 explains in detail on attracting software craftsmen to a company. It also walks the reader on a journey on how to craft a job description. I feel like this chapter is the best read for anyone who would like to recruit or looking for the best developer for his/her company or organization. After reading this chapter, I would recommend this sole chapter reading to anyone who carries out the recruiting or hiring process at a company or organization. I believe the author did a fantastic job on covering and perfecting attracting and putting out description for a target and ideal candidate for a job.

In chapter 10, author covers the interviewing part of the hiring process. One emphasis of the author that I liked was when the author explains asking questions in the interview. According to the author, interview should not be only the company asking questions from the potential candidate, but rather the question process should be from both sides. If the candidate is a craftsman, then he/she must have questions for the company too. This way the company and candidate will insures that they both are best fit for each other.

This was very informative read especially on the job description and interviewing.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapter 7 & 8

For this week, I read Chapter 7 Technical Practice and Chapter 8 The Long Road, from the book title The Software Craftsman by Sandro Mancuso. Chapter 7 explains adoption of extreme programming (XP) like Test-Driven Development (TDD), pair programming, refactoring, simple design, and continuous integration. Chapter 8 explains how to approach job choice and what it takes to have a job/career where you would be happy.

In chapter 7, the author describes and explains all aspects of extreme programming. For example, Test-Driven Development (TDD), pair programming, refactoring, simple design, and continuous integration etc. The best thing that I learn from this chapter was when the author states “Being pragmatic is one of the best quality that a software craftsman can have.” This explains that professionals are not limited to following certain practices and processes where they would always receive optimum results. But rather, as professionals we need to keep looking and searching for ways of doing our jobs better and satisfying the needs of our customers. Whatever it takes, at the end of the day what matters are happy clients. We should follow any practice that we believe will give us this result and we should be accountable for whatever decision we make and always take responsibility for the outcomes.

In chapter 8, I like when the author breaks down job choice base on three criteria: autonomy, mastery, and purpose. Craftsman must look and consider these three things before choosing a job. I believe that this is a good criteria to have, but to be able to choose based on these criteria, individual needs to overcome a lot of obstacle and challenges. You need tremendous focus and determination in order to excel and expand your knowledge and skills.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapter 5 & 6

For this week, I read Chapter 5: Heroes, Goodwill, and Professionalism and Chapter 6: Working Software, from the book title The Software Craftsman by Sandro Mancuso. Chapter 5 explains the need and urgency of when and how to say “No”? Chapter 6 explains the effects of technical debts on companies and stabilization of existing code, and improving it.

In chapter 5, author explains one of the hardest thing to say in general which is saying “No”. As a professional, one must have the courage to say “No” when he/she does not think that his/her client or boss is not being reasonable or does not understand the scope of what he/she is demanding. As a professional it is our duty to stand up for ourselves and make people around us aware of the entire situation as transparently as we can. Always, be clear and careful at your decision and commitments. Be sure what you have been asked and what you are committing is achievable. I believe saying “No” is one of the hardest thing about being a professional and I hope that I don’t have to be the first one to say “No” as I am stepping into the real world. I wish that I see my senior say it first then I will follow.

Chapter 6 was my favorite chapter because it talks about a topic most software developers and companies ignore to pay attention to once they complete a job or project. I believe for any successful software company or business needs to constantly work on its old code and try to make it better in order to increase its adaptability. Companies need to hire craftsmen to refactor its existing code. I like how the author puts in the book, “rather than construction, programming is more like gardening.” this quote explains that rather than keep producing new code every time, it is more efficient to make existing code better so it is more adaptable. It can save companies time, money, and maintenance in the long run.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

The Software Craftsman, Chapter 3 & 4

For this week, I read Chapter 3 Software Craftsmanship and Chapter 4 The Software Craftsmanship Attitude, from the book title The Software Craftsman by Sandro Mancuso. Chapter 3 describes what Software Craftsmanship is? Chapter 4 put emphasis on the importance on how to keep learning and develop yourself over time?

In chapter 3, author defines a software craftsmanship. One of the definition that I liked was when the author stated that “Software Craftsmanship is about professionalism in software development.” This definition explains what software craftsmanship or field craftsmanship should be all about. Software Craftsman must care about his/her clients and help them achieve whatever they want to achieve, always try to make himself/herself better at his/her craft, learn from other in the field, share his knowledge and best-of-all mentor less-experience individuals in the field.

In chapter 4, author put focus on learning by yourself and make the right and wise decision for yourself. Just like in The Clean Coder book this author also suggests that you should never rely on your employer to give you all the training and resources in order to improve your knowledge and skills. You should take charge and responsibility for your own learning, and develop your skills by yourself over time. Author offers many useful strategies to improve and keep yourself up-to-date with the changing industry. I personally like all these suggestions from The Clean Coder book and have implemented some already.

Both chapters were very enlightening in order to be successful in the software industry. I have already plead to follow all these suggestions from the previous book.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.