Chapter 15: Pragmatic Craftsmanship

Pragmatic – “Dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations” This chapter is about encouraging mastery of skills. Stating that Quality is not expensive and doesn’t slow things down.  But Mastering skills is a bottle neck. It is your job to master these skills to provide quality software every time.

Chapter 16: A Career as A Software Craftsman

This chapter details that a software craftsman is dedicated, passionate, and driven. The software craftsman masters their skills and every day is excited to learn new things. Every day they wake up and not only go to work for a paycheck but also try to change the world one block of quality code at a time.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 13: Culture of Learning

Some think that a culture of learning is hard to create or it cost a lot of money and time. But in this chapter, the author details some simple ways to do it. One thing that can help is hiring passionate developers. This step is the most important because passionate developers love learning new things and this can accelerate this process a lot. When you are passionate about something it doesn’t feel like a hassle to learn new things.

Chapter 14: Driving Technical Changes

One thing that is difficult with driving technical change is dealing with people. Everyone has a different stand on what you are trying to change or improve and one of the difficulties is changing the minds of all that you encounter to proceed with your project. One thing that can help change people’s minds is being able to communicate clearly what you are trying to change.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 11: Interview Anti-Patterns

In this section, the author details some things that interviews do and some things that you should not do when looking for a developer. A classic example is the difficult programming problem to get the awesome development job but the author looks down on this. He states that there is no point in haveing a brain teaser or coding on paper without the internet because this does not make any sense. If you think about it this doesn’t help anyone. You should observe the interviewee in their best conditions not make them look like a fool. I completely agree with this.

Chapter 12: The Cost of Low Morale

Low morale is always a problem. In so situations, it can be the cause of the death of a company. Unmotivated people don’t want to do productive things or think out of the box. Companies need innovation to be competitive. Innovation is spawned by passion and drive but low morale can kill this.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 9: Recruitment

In this chapter the author details some interesting facts about recruitment agencies. The author states that they should only be used as a last resort. This is because they are only looking at some skills on paper and don’t really care about the career development of the individual. The author says some interesting things about how to recruit for your own company. His statements are the direct opposite from what I have noticed when looking for a job. He states that you should detail culture and passion and never required experience or academic background. This makes sense when looking for a valued member of the team but has been the complete opposite of my experience so far.

Chapter 10: Interviewing Software Craftsmen

In this chapter, the author elaborates on some interesting skills to learn from your interviewers and what they will learn from you. If in an interview they are very strict then you might be able to pick up how the developers are treated within the company. He also states that developers look for more than just the technologies and the money. They look for a good environment, including a good team, a good atmosphere, and sometimes the technology. In some of my interviews I have picked up on some of these things but this chapter gives me a few more things to think about during an interview.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 7: Technical Practices

This chapter discusses some techniques that can help save time, money, and headaches for all involved if developers can convince management that they help. Some of these techniques are:

• Test Driven Development- Write tests have them fail, write code to make them pass, repeat
• Continuous Integration- requires developers to integrate code into a shared repository multiple times a day to detect problems early.
• Pair Programming- Programming with someone else to bounce ideas back and forth
• Refactoring- restructuring code to make it more efficient

Chapter 8: The Long Road

This chapter illuminates some potential missteps when choosing a career path. One of these such missteps is allowing your career to be directed by your job and not letting your career choose what job you get. Sometimes the skills that you would like to learn are not used in your job. If this separates too much from your desired path then maybe you should look for a better fitting job.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 5: Heroes, Goodwill, and Professionalism

This chapter is very similar to the chapter in clean coder titled when to say no. The author of The Software Craftsman details some situations that require a skilled and professional Software Craftsman to tell the client no. Some of these include situations where the client does not know the full extent of implementing their wants into the product. This could result in a dangerous situation for the client and it is our responsibility to enlighten them on the full context of the situation.

Chapter 6: Working Software

This chapter boils down to how good your software is. As a company and as an individual. As a company, the quality of you software can directly be linked to your flexibility. The ever-changing marketplace requires the need to be flexible to those changes for companies. This means that you need easily changeable and upgradeable software.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 3: Software Craftsmanship

This chapter delves into software craftsmanship. The author states that it is all about professionalism. Like most jobs professionalism is very important. It is always important to provide the best that you can. This is the short summary of the chapter and I believe it to be true when applied to most facets of your life. Who wants sub-par coffee in the morning? or a half toasted bagel, or even a raw donut. I might be hungry but the point still stands no one wants less than perfect. Try to make everything that you do capture and exceed the thing you were trying to accomplish.

Chapter 4: The Software Craftsmanship Attitude

In this chapter, the author details an attitude that is always learning and progressing. This is interesting because I believe that this what I strive for from day to day. Every day I try to tinker with anything and find out how it works whether it’s my mechanical keyboard or the vending machine at my work I love learning how things work. He applies this attitude to a career. In your career, you should always be learning new things. I feel like I am on the path to this applied attitude.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 1: Software Development in the Twenty-First Century

Due to the ever-changing nature of software development seniority is not exactly the best way to check someone’s skills. The field itself needs more flexible coders and having skilled individuals that know nothing about new and upcoming techniques is the opposite. I definitely agree with the way the author approaches the topic of seniority and its lack of correlation to skill set. I do not have much experience in this field in a job sense but abstractly it makes sense.

Chapter 2: Agile

The agile method is one way for businesses to obtain the flexible nature looked for when trying to be competent. But this can be a bad way to think about it because in practice companies tend to give attention to the processes and the meeting but forget that they still need good software craftsmen and craftswomen to turn out good software. If you adopt the meeting but not the necessary mastery then you will still have bad software but get to go to scrum meetings. This to me is a clear cut way to look at agile. Like in one of the scrum books that detailed a story about indigenous people trying to get plans to come back it makes sense that having meeting does not always get you the things you are looking for.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 13: Teams and Projects

Chapter 13 is one of the shorter chapters in the book. This chapter is all about teamwork. In my own experience, like most I have come to find out that just because you get along with someone does not mean you will work well with them. The author states that teams need a long time to start working together, he states it is on the magnitude of months. He also starts that giving one person more than one teams doesn’t work great but giving one team more than on project works well. I am one of the people that likes to work alone so I need to work on my team skills like communication.

Chapter 14: Mentoring, Apprenticeship, and Craftsmanship

This chapter is one of the most important or rather most relevant chapter to my current professional status. My thoughts on Software design used to be that you learned the skill then got a full-time job doing said skill. But more realistically is the way the author describes the transition into a professional Software Developer where you would train through years of work. I rather like his idea of using crafting trade rankings like master, journeymen, and apprentice. He also states that the profession of Software Development is missing the elders teach the young. Though I have not experienced the profession to this extent yet I hope that this is not the case.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Chapter 11: Pressure

Chapter 11 is titled pressure and well it is quite straight forward. Every person deals with stress,  and all professions have a certain degree of pressure thrust upon them and being a professional Developer is no different than those other professions. The key in life is to learn how to be cool and clam under pressure. One great way to deal with presser that is detailed in the book is to properly assign your time as to allow for time to deal with crisis if it comes up. Another thing is to code cleanly (which was the title of the last book he wrote) Yet another way to deal with a problem of disaster proportions is to pair up. This is a useful technique to quickly and efficiently quiet the problem.

Chapter 12: Collaboration

This category is one of the ones that I feel like I need the most amount of help in, Collaboration. I definitely am one of the programmers who would like to work completely alone. I feel as though I could be more efficient by myself. But, This is not a good habit ad most of programming stems from collaboration with others. Some of these are clients and business people who know more about the situation you are coding for than you might. Therefore it is most beneficial to collaborate and communicate with other around you get the best end product that you can. Collaboration could even prevent future disasters that you have previously not even thought about.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.