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.

In the third chapter of Mancuso of The Software Craftsman, he goes over what it is to be a software craftsman and the basic manifesto of it. After reading The Clean Coder, a lot of this chapter just felt repetitive. The just repeated what “Uncle Bob” said in the previous book; make sure code is working, but also easy to maintain and predict, make sure code can cater to the clients/industries changing demands, but make sure the code stays clean and is designed for a long lifespan, make sure to help other developers in need to build a better community for everyone, and understand that software development isn’t only about producing code, but understanding who you are making the code for and why they need it. The one thing that I like about this book more than The Clean Coder is Mancuso acknowledges that some companies will only see software developers as assembly workers and sometimes you can’t change their way of doing things. In this case, Mancuso wisely advise that you start looking for another place to work if that is the case.

In chapter 4 of The Software Craftsman, Mancuso goes on the top of “Who should be the one to advance your career?” Just like “Uncle Bob”, Mancuso points out that it is every software developer’s responsibility for them to continuously teach themselves new technologies in their field and not the companies responsibility to train them. As I might have said before when reading the The Clean Coder, I think that it depends on the company you work. If you work for a company that uses proprietary software or coding language, I believe that the company is responsible for making sure their developers get proper training on what they are using or provide material for them to learn about it. However, this does not discount the fact that developers still need to keep up on new concepts or behavioral techniques that they need to develop on their own. What I did like much better then The Clean Coder was that Mancuso delved into some of the different ways software developers could acquire the knowledge they need to keep up to date on their careers. He also took the time to create a small list of where to start acquiring this knowledge, and how to properly view this different ways (ex. types of books vs blogs vs technical websites). After that it goes into what The Clean Coder already stated; make sure to create pet projects for yourself and find “katas” you can do everyday or free period, paired programming/learning from other developers, contributing to open source projects to practice, and he also repeats the same “make time outside of work to work on these things” and the “25 minutes of work/5 minutes of break” technique that Martin spoke about.

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

In chapters 1 of The Software Craftsman by Sandro Mancuso, it talks about how developers need to adopt to the changes that are constantly happening in the software field. It states that developers can no longer be only about coding. Instead they need to know about multiple different disciplines and techniques to be successful in the field now-a-days. This is nothing new to me. Lots of companies will not bother to look at your resume if you do not have at least some knowledge of different languages and frameworks, or even if you only have one degree. Also if a developer has no idea what the Agile process is, then they are going to have a hard time in this industry, so most of that part and the next chapter just seemed repetitive to me.

In chapter 2, Mancuso goes over what the Agile process is and how some companies fall into the trap of only transforming their process into a partial Agile process. Again there was nothing really new to this chapter for me. It’s already been driven in how the Agile process works, and how it’s not just making meetings and Sprints shorter, or how to deliver code and receive feedback faster. The other half is making sure that you produce code that is readable and can be easily changed if needed. If other developers are intimidated by the code that you are producing, whether that means that they don’t know how it works or if it’s badly written, then you need to go back and fix the code you are writing right then and there. If you neglect to do this, it means that that piece of code will most likely cause issues down the line because other professionals can not go back and easily change it if there is a issue that pops-up with the section that you’ve written.

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

In chapter 13 of The Clean Coder, Martin goes over why teams should not be formed around projects. Instead a team should be put together with the objective being for that team to gel together and stay as a team for a long time. This makes sure that you have people that understand one another and can easily work with each other on multiple projects that they get. If this doesn’t happen, it may take longer for an makeshift team to get a project done rather than one that is already gelled. Martin also points out that it is also time consuming and expensive for a business to be constantly breaking up teams to work on different projects because of that fact. Again this just makes common sense to me. If you constantly have to predict how your teammates will act and never get into a rhythm, then you will be wasting time and effort on those predictions rather than getting your work done.

The last chapter of the book is directed towards those that are already in the field. Martin talks about how universities can only teach the next generation of programmers so much, and the rest falls to mentors that know what it’s like working in the real world. He talks about how, ideally, companies would know not to give recent graduates high level work that could possibly lose the company money. Instead there would be a hierarchy set-up that would make sure people with 10+ years experience would oversee people with less experience, and those people would train graduates on concepts and designs for a year before they are able to work on code. Even though this is technically in place – with project managers, older team members who over look younger team members, etc.  – there isn’t enough supervision and mentoring. I definitely agree with Martin on this point. While I have been learning a lot at college – about design patterns, different types of testing , etc. – I have not ingrained all of these teachings into how I program. I also know that there are tons of other things that I have yet to come across and learn because computer science is a huge field and I can’t possibly learn everything. Most of the stuff that I have absorbed has been from someone helping me personally with a project, or talking with a teacher or a professional on how to get some bit of code to work. This is why I think it is very important for people that are already in the field to remember to work and communicate with graduates, so that they can become better at what they do and, in turn, help the next set of graduates that come in.

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