Chapter One tackles the question at the heart of this book and explains “Why Programmers Seem Unmanageable”. One of the reasons is provided by a quote from Fred Brooks setting out why programming is fun and the authors pointing out:

If having fun is what most programmers do, you may begin to understand why managing programming is so challenging. If you are being paid to have fun, why would you want to be managed? Being managed takes part of the fun out of the work!

Later in the chapter they ask “What is it that makes a great programmer?” and having provided a convincing discussion , and also providing us with the humorous aphorism “ Managing programmers is a lot like herding cats” they point out that one of the factors to take into account is that for programmers, the work itself and its environment is often more important than compensation.

In Chapter 2: Understanding Programmers, a variety of different ways to categorise programmers are explored, starting with programming disciplines for which four groups are identified:

• client
• server
• database
• web developers and other scripters

They also point to four types of programmer

• system engineers/architects
• system programmers
• app programmers
• not really programmers - scripters, those using GUI tools to generate user apps

Another distinction is between in house employees, geographically distant employees, contractors and outsourced contracted teams.

One categorization that I particularly like is “generational styles”. The four generations identified are Older Boomers (born 1945-55); Younger Boomers (born 1956-65); Gen X (born 1966-85) and Millennials (born 1986-2005) and a table shows how they differ in their characteristics and core values but also in the way they encountered and interacted with music, mass media and computer technologies.

The chapter also reviews personality styles, discussing for example left-brain versus right-brain people and night versus morning people. It also makes a distinction between cowboys versus farmers, and after exploring the qualities of heroes (those who achieve great things through superhuman effort) and introverts, it has advice about personality types that you should avoid hiring:

Some people are simply jerks. They are abrasive, caustic, toxic people . Of course, they may have some  redeeming qualities. They may be brilliant, technically talented, great programmers. But brilliance doesn't justify the price you have to pay for having them in your organization. Having them in proximity is the problem"

It concludes: Adopt a “no jerks” rule … Expand the rule to cynics and bozos as well.

There’s a lot of highly practical advice in this chapter and, to make it even more useful, the book’s website has downloadable Word documents and spreadsheets including sample job descriptions for programmer levels, a sample independent contractor agreement and a roles and ranking system.

The next chapter on hiring starts by quoting some studies that show huge productivity differences between individual programmers. On of the longest chapters in the book it covers a lot of ground from writing job descriptions, recruiting full time employees and contractors and the entire interviewing and offer making process and lots of sample materials are available for download from the website, as are tools associated with almost all the remaining chapters.  

Chapter 4 has the title “Getting New Programmers Started Off Right”. It spans the period before new hires actually start work and the initial few days including a Welcome Day timetable.

Chapter 5 opens with a section Earning Technical Respect and starts with how not to do it alluding to the Pointy-Haired Boss from Scott Adams’ Dilbert cartoon strip. Later it looks at managing different types of programmer with lots of anecdotes from both authors’ experience, Ron at Apple and Mickey at Broderbund. It covers performance reviews, including advice on handling terminations, and had advice for troubleshooting when things have already gone wrong.

Chapter 6 has advice on your relationships with your boss, with your peers and with those outside your immediate organization. In the section on Managing yourself it explores that idea that you are what you wear and looks at communications management, in particular email etiquette.

Chapter 7: Motivating Programmers is the longest in book. It starts by looking at three alternative theoretical frameworks: Maslow's Hierarchy of Needs; McGregor’ X-Y Theory and Herzberg's Motivation and hygiene Factors. It presents a modified version of Herzburg’s categories to make then more software-centric and discusses first the foundational factors that cause dissatisfaction when lacking and then the key motivational factors, working through each in turn in practical terms.

In Chapter 8: Establishing a Successful Programming Culture we are told:

An essential and significant role as a great manager is to create and nurture a successful programming culture.

We then learn that the characteristics required include mutual respect; fairness; professionalism, programming excellence, teamwork and collaboration, environment and no jerks and bozos, all of which are discussed.

The final chapter, Chapter 9: Managing Successful Software Delivery opens with a familiar cartoon describing how a software project can end up delivering something that is far removed from what users want and how each stage in the development process varies along the way. The anecdotes in the section about defining the project will chime with many readers. I particularly liked the following quotes:

"They don’t yet know what they want us to build, but they have given us a deadline they want it by"

“The business loves Agile. They think it means if they sit close to us so that they can answer our questions about the requirements, they don't actually have to give us any!"

As readers will have come to expect from this book, there’s lots of practical advice for defining and planning projects; for deciding when your project can be judged as successful and also for knowing when to cut your losses, all of which is backed up with anecdote and experience.

This is a very readable book and can be recommended to anyone in a software management role. For new managers it will save having to reinvent the wheel and for the more experienced it will help to know that others have faced the same struggle.