I first heard about the book “Code Leader” from this blog entry. What got me interested about it is that this is the first book I‘ve seen that tries to take the technical approach to teaching team leadership.

First, I think that this book is (at least from the table of contents) very much something that is missing in today’s book landscape – a book that talks about best practices and things that “work” without trying to be too “agile” driven. What I’d call “a book for the rest of us”.

But, as I looked at the Table of contents for the book, I tried to find something very specific that anyone talking about code leaders should be talking about.

Can you tell me what it is I was not finding in the TOC?

Chapter 1 (Buy, not Build) describes how to go about deciding which parts of your software project you need to write yourself and which parts you may be able to purchase or otherwise leverage from someplace else. In order to keep costs down and focus on your real competitive advantage, it is necessary to write only those parts of your application that you really need to.

Chapter 2 (Test-Driven Development) examines the Test-Driven Development (or Test-Driven Design) philosophy and some practical ways of applying it to your development lifecycle to produce higher-quality code in less time.

Chapter 3 (Continuous Integration) explores the Continuous Integration philosophy and how you can apply it to your project. CI involves automating your build and unit testing processes to give developers a shorter feedback cycle about changes that they make to the project. A shorter feedback cycle makes it easier for developers to work together as a team and at a higher level of productivity.

Chapter 4 (Done Is Done) contains suggestions for defining what it means for a developer to “finish” a development task. Creating a “done is done” policy for your team can make it easier for developers to work together, and easier for developers and testers to work together. If everyone on your team follows the same set of steps to complete each task, then development will be more predictable and of a higher quality.

Chapter 5 (Testing) presents some concrete suggestions for how to create tests, how to run them, and how to organize them to make them easier to run, easier to measure, and more useful to developers and to testers. Included are sections on what code coverage means and how to measure it effectively, how to organize your tests by type, and how to automate your testing processes to get the most benefit from them.

Chapter 6 (Source Control) explains techniques for using your source control system more effectively so that it is easier for developers to work together on the same project, and easier to correlate changes in source control with physical software binaries and with defect or issue reports in your tracking system.

Chapter 7 (Static Analysis) examines what static analysis is, what information it can provide, and how it can improve the quality and maintainability of your projects.

Chapter 8 (Contract, Contract, Contract!) tackles programming by contract and how that can make your code easier for developers to understand and to use. Programming by contract can also make your application easier (and therefore less expensive) to maintain and support.

Chapter 9 (Limiting Dependencies) focuses on techniques for limiting how dependent each part of your application is upon the others. Limiting dependencies can lead to software that is easier to make changes to and cheaper to maintain as well as easier to deploy and test.

Chapter 10 (The Model-View-Presenter Model) offers a brief descr...

 

--------------

can you tell what’s missing here?

Yes. these are all great subjects, but how can a book presume to talk about code leadership without having a chapter on, well, leadership?

• What makes a good team lead a great team lead?
• how does a team lead deal with personal issues in the team?
• People not working well with one another
• One developer that is slowing down the whole team
• How do you “grow” a team of great devlopers?
• What are the common pitfalls that team leads fall into time and time again?

These things are essential. To understand why, just think that even if you are a team lead who knows everything in this book, it does not matter if you cannot get your devs to do it right. it does not matter if you cannot find the inner strength to face a developer who is not up to par and get him up to par.

 

I hope I am mistaken and that somewhere in the book these ideas and more are addressed, but it does not look like it from the chapters. Instead, the book takes the easy road which is just talking technical. To me, a code leader is not just a technical beast. he or she needs to be so much more than that to make an OK team into a great team.

It does not matter one bit how good you are technically if you can’t drive the team.

I’ll start talking about what I think makes a good team lead in upcoming posts.