Chapter 7 addresses a number of technical practices such as TDD, pair programming, SCRUM and their usefulness in improving our software delivery process. These agile methodologies are about delivering value to customers in the shortest time frame possible. Even though these practices are very effective in the software development process, it is difficult to convince manger to adopt them. Many companies do not use these practices because they fail to identify why they need them, when to use them, or simply does not believe that they are effective. It is not easy to get developers to adopt to these practices because there is a learning curve and it will take some time to understand. To figure out which practices to use, first we must know what area we need to improve and what we are trying to achieve.

Chapter 8 is titled “The long Road”. This chapter is perfect for aspiring developers because it talks about what to look for when choosing our careers. It summarized the career requirements into three things autonomy, mastery, and purpose. Having a successful career is not easy; we must figure out where we want to be and work hard to get there. We must treat every job as an investment to craft the career that will makes us happy. And if you are among the ones that do not know where they want to be, this chapter has a lot of suggestions to create options that can help decide the next step. Things like attending conferences, blogging, studying new things, and networking with other developers and business-people can open a lot of doors. Our career is important and carefully crafting it is the best way to reach where we want to be.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

Chapter 5 of The Software Craftsman titled “Heroes, Goodwill, and Professionalism” essentially covers the communication between the client and the programmer.

There is a limit to satisfying the clients needs. From their perspective, they are not aware of how difficult and elaborate the process for a software project is. They usually have a demand and expects immediate and accurate results because after all that is what they pay us for. However, how we handle situations like this in this field is what determines our level of professionalism. It is our job to communicate with our clients and say “no” when they have unrealistic requests. We need to be upfront on what is possible, what is not, and set realistic deadlines so we can have enough time to work with no pressure. If we fail to communicate, then we end up looking unprofessional.

Chapter 6 is title “Working Software” and it is about keeping the quality of our software as polished as it can be. We must never sacrifice quality for the sake of meeting a deadline; that is bad practice. Our software must be written well enough to adjust to changes, otherwise we will become “hostages of our own software”and that will hinder the business progress. This makes perfect sense because as technology advances, our software needs to be able to adapt quickly. Adding new features should be implemented into with ease if we have good quality software. I like how Sandro relates code to a garden. He mentions that ” with basic and regular maintenance, the garden will always look great but if we neglect it, even for a short period of time, it will require much more effort to make it look good again”. I think this comparison accurately describes how we should treat our code. The same thing can happen to our code if we neglect it; it will deteriorate or loose quality and will require more work to regain quality.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

Chapter 11 was a good follow-up chapter to chapter 10’s interviewing software craftsmen. After reading this chapter, i gained a better understanding of what type of company I would want to work for. The books makes an excellent point by stating that interviewers should test candidates according to the things they value and to what is important to the projects instead of asking close-ended questions that anyone can answer by googling the question. Although I haven’t been through a huge amount of interviews, I can tell that most companies care about the “technical skills” rather than the passion of a developer. I don’t know about you but I rather be a developer that doesn’t know much but is passionate and willing to learn, than a technically-knowledgeable developer who does not care much for improving his skill set.

Also, here’s the summary to the idea and basic solution of low morale. Bored developers become lazy. Lazy developers become unmotivated developers. Unmotivated developers start to not care about their jobs. When developers don’t care for their jobs, the company makes no progress. When the company makes no progress, employees feel as though they are not developing and are not making a difference. When employees feel this way, their morale dangerously drops very low. So, basically if you want to stop this vicious cycle, don’t become one of those developers who becomes “bored”. How do you do that? Invest in yourself, constantly sharpen your skills, and be a software craftsman. That way, you will always be learning new ideas and talents; there’s no way you could get bored from that!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Chapters 9 and 10 were especially interesting because it talks in depth about recruitment and interviews; and what better time to learn about those concepts than a senior graduating in 1 month! I found it so relatable when the author criticizes the job description of companies who are asking for qualities that are not even implemented at the workplace.

I would search for entry level software developer positions and one of the requirement for applying would be +2 years of career experience. Like, seriously?! I don’t understand how companies who are looking for entry level software developers are looking for candidates with +2 years of career experience. Correct me if I’m wrong but entry level does mean “introductory” or “basic” right?!

Chapters 9 and 10 encouraged me to not just follow the money, but rather, work for a company you feel passionate about, Work for some place where you feel you are being heard and can truly make a meaningful difference! There was a line in chapter 10 that completely left me mind-blown at how true it was. “During an interview, it is important to understand that we are not begging for a job. We are doing a business negotiation.” This made me realize that you, as a developer, have something to offer. You are not “asking” for a job, you are negotiating how much you believe your skill set can be worth to employers!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Chapter 3 of this book really translate what software craftsmanship is. It gave us a number of definitions including one from Wikipedia. Each definition shows a different perspective and what stuck out to the most was looking at software craftsmanship on a personal level. The book defines this as

a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves.

I see this being the most constructive definition or how software craftsmanship should be defined.  If we have this mindset then everything else like team work and professionalism should fall right into place. This also extends into chapter 4 because its about attitude and how software developers should represent themselves. No matter how much we rely on the workforce to gain experience, we have to realize that were in charge of our own careers and our advancement within it.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

Although chapter 7 was mostly review of concepts I already learned, I do think it’s important to at least restate the idea of the “boy scout rule” and the “broken windows theory”, which was mentioned in chapter 7 because it’s an important mentality to be aware of. The boy scout rule is to “always leave the campground cleaner than you found it” and the broken windows theory states that “the bigger the mess is, the bigger it will become”.

Something that I did find helpful in chapter 7 however was the idea that we should not follow practices just because someone said so. Like with everything else, we should take all agile practices with a grain of salt because each practice can be extremely efficient in some cases, but rationally useless in other cases so it is ultimately up to us as the developers to know when to use what practice.

Chapter 8 mentions that there are 3 main things that a craftsman should look for in each job; autonomy, mastery, and purpose. I think it is every developer’s goal to find a job that fits these three qualities, because if you did, then you would now be doing something you love to do, rather than doing something because it offers large paychecks.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The first chapter of software craftsman talks about how different being a software engineer is today. Knowing how to code is not sufficient to be considered a craftsman, we need to have the knowledge to aid a company in other areas as well. I can see how this is important because in the workforce we have to prove ourselves to be an asset to the company we work for. It is not just about mastering our craft, it is also about showing that we are flexible enough to learn new things and adapt to changes .  Like the book explains having experience in one area is not always the best route. Someone with less experience in the field maybe more knowledgeable in more areas. Chapter 2 Talks about the agile transformation which embraces processes and tools such as Scum and other methods. My experience with scrum has only been in my classes.  But i can see how practicing scrum and other tools alike really contribute to the Agile Manifesto.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.