Chapter 15 goes over why quality code doesn’t have to come with a big price tag. Mancuso discusses that while managers and clients want everything done as cheaply and quickly as possible, they still expect a decent amount of quality to be in the software they are getting. Mancuso explains that coding does not have to suffer from being or poor quality if people stick to simple practices that will continue to help keep the code clean and easy to test. Again, very similar to the last book and previous chapters, he re-iterates the importance of TDD and how much time it saves. He also goes into why it is important to refactor code when and where you can to make sure that it was cleaner than before. I think the best thing in this chapter is the Four Rules of Simple Design; passes all tests, minimizes duplication, maximizes clarity, and has fewer elements. Keeping these rules in mind would greatly help programmers on track for keeping code as clean and simple as possible, and keeps TDD in mind.

Chapter 16 basically just sums up what being a Software Craftsman means and how they look at furthering their careers. A good portion of this chapter is common sense; knowing that being a good developer requires passion, and the urge to want to learn more about the software development field. To that extent, Mancuso goes over how to build your career and how to look at jobs to make sure you are aiming for positions that will help you later down the line. I did find some of the questions that he asked himself before applying to a job useful (again probably later down the line when I’m able to be more picky about where I apply to). I have also come across many people that graduate from this profession and admit that they don’t know what they want to get into. Again Mancuso provides some good, even if obvious, advice on how to ix this issue; simply get out there and talk to people. Overall I think that this book has provided some very useful information from how to stay passionate about your work to some really good advice about help to further your career in the industry. I would definitely recommend this book to anyone thinking about getting into the software development field, or even to someone that may already have some experience in it.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Chapter 13 continues on the topic about how to keep people on your team motivated and interested in the software development field. I think this chapter has to be one of my favorites so far. All of the suggestions that are made about how to keep passion going in a team were interesting to go over, and just reading about them makes me want to give them a try. I think that my favorite idea, out of those suggested, was just switching projects for a few hours. This one is so simple and can be done a once a week, so it shouldn’t interfere with anyone’s work, but it is an easy way for team members to get invested in one another’s projects, and also encourage the learning and use of other softwares/ways of thinking in their own projects.

Chapter 14 mostly focuses on how to deal with different types of people that may end up on your team and how to encourage them to keep up with technical practices. I found that this chapter really just boils down to “know what you are talking about.” If you completely understand what you are trying to change, whether it is implementing TDD or trying to use a new language, the more you know about it the easier it is to explain it to everyone else. However, this doesn’t mean that everyone will except it just from your knowledge allow. Being able to also show your teammates and company how effective your change will be is also very important. In the end, to change the minds of the people that you work with, you want to make sure that you can clearly communicate with them, listen to what they have to say, and present these new changes in a way that will hopefully persuade most of your members to adopting them.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Chapter 11 was mostly for people that are the interviewer at their company. It basically went over what an interviewer should and shouldn’t do to a potential candidate. For example, brainteasers don’t work to attract good developers, and doing anything that makes a potential partner look like a fool will make it so they don’t trust working for you. Again this is a chapter that isn’t helpful to me right now, but the information in this book may be more helpful further down the line in my career.

Chapter 12 talked about how to low morale can kill productivity and passion in developers, and also talked about how to bring passion back into a company. Mancuso talks about how, after awhile, some developers just give up on projects and become lazy because they just see their job (as he put) as “just a job.” This type of thinking definitely becomes an issue because then people are not meeting deadlines and can lead to wasting tons of company money. However, I don’t see an issue with wanting to make sure that you have hobbies and time that are separate from your work life. As long as you maintain a balance between the two it should be fine because I believe that if you fill everyday with the same thing, that will burn you out faster than anything else might. He then goes onto say how to bring back motivation to a low morale team. I like his idea of talking with people at the end of the stand-up meetings about new things they found. This not only gives people the opportunity to discover new posts or websites they have never heard of, but it also brings the team closer together.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Chapter 9 goes into detail about recruitment for software development jobs and some of the issues with it. Mostly what I took away from this chapter is how to recognize what possible companies and business know what kind of developer they are looking for versus a company that is just looking for anyone who might fit their need. The rest of this chapter seemed to mainly target people that were in the position to hire people, and what their focus should be to make sure they attract and get the best developer that they can. For right now, I didn’t find those parts too useful, but hopefully this knowledge will be useful later on in my career.

Chapter 10 focuses on the interviewing process and what recruiters are looking for in a potential addition to their team. Mancuso list a bunch of useful things to be aware of when going into an interview. Some of the things that I found useful were ask questions about the company and the team, make sure to highlight your achievements as well as point out issues that you’ve dealt with, and make sure to talk about want you want to achieve in your career and how you believe that this position will help you. He also points out different ways to analyze an interview to see what they might be looking for and how they judge new candidates. Mancuso points out that, during an interview, it’s ok to make sure that you are being asked questions that are relevant to the position you want. There were also different ways that an interview could be held, from pair-programming interviews to even having pre-interview coding exercises. Some of these I’ve heard of before, but I thought that this book did a good job of pointing them out and explaining them so that graduates would be aware that they might end up in one of these scenarios. Overall this chapter was extremely useful for people that are just graduating, and I definitely took away some of the things to look out for in interviews (mostly about what to say ad bring up during an interview since I’ve done so few of them).

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Chapter 7 focused on how to make sure use technical practices at your place of work. For example, integrating techniques from TDD and using paired programming to help your team focus on what they are trying to do, while also making sure that less mistakes are made. This chapter also helped with ways to suggest to your team that using these practices will be helpful in the long run, if they are having issues adapting to them now.

Chapter 8 focuses on how to focus on career goals and how to create new opportunities to pursue in the field of computer programming. Mancuso stresses the point that new opportunities won’t just show up when you need them. Instead he says to create them yourself by learning new languages, expanding your network of people, blogging about interesting articles or projects you’re working on, and going to conferences. These are all wonderful suggestions that college graduates should definitely follow while in school and after they leave. Also look at jobs as an investment into what you want to learn because this will help in the long run of finding a job that is stable and secure in a field you want to be in; I found this kind of as an obvious statement since you want to make sure you don’t end up doing something you later dislike. I also agree with Mancuso’s observations of what a job should hold for a person (autonomy, mastery, and purpose) because with out these things than you would fall into the trap of having a boring job which might later lead into you not being able to care about the field your in anymore. This would obviously lead into the possibility of being fired from that job and not being able to find a new one. I think this whole chapter was a pretty useful one since it focused mostly on what a college graduate should know about applying for jobs after classes.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Chapter 5 of The Software Craftsman has the exact same message as Chapter 2 (about how to say “No”) of The Clean Coder. Basically boils down to make sure you understand what you and your team can handle in terms of projects, and stand up to management if your team cannot handle the task. Also make sure that what you are working on is transparent to, not only, your team, but the managers and business people as well.

Chapter 6 goes on to talk about how developers should be in the habit of writing clean and maintainable code that won’t have to be refactored later. If the code does end up needing to be refactored, the previous developer show have been professional enough to have made unit tests for that piece of code. This way new developers are not scared to break the system since they know that they can easily run some test to find out if the new code works the same (or better) as the old code. The main thing that I got out of this chapter (because most of it is repeated in The Clean Coder) was when he talked about working with legacy code. It feels like an obvious answer, but I never thought of taking a small portion of the code, figuring out what it is suppose to do, and then writing a unit test for it (if it doesn’t have one yet). Doing this will not only make it easier to understand the code, but it will let you clean and refactor the code easily.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.