Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

For the last few months we’ve been doing pair programming at work. And not just pair programming, but full extreme programming with test-driven development, continuous integration, collective code ownership, customer-driven stories, team co-location, etc. It has been a fascinating experience and it has been working out better than I even imagined.

I felt that all the extreme programming books I had read just touched on the subject but were light on the specifics. What’s more, it’s one thing to read about it, and something completely different to actually do it. Once we started doing it, there were some very basic questions that immediately popped up: What do we do with an odd number of people? How often should we rotate pairs? How are pairs formed? How often should we be switching drivers? Is it normal to be exhausted after several hours of pairing? etc, etc, etc. With questions like that in mind, I decided to pick up a copy of Pair Programing Illuminated. I was hoping it would provide me with the tips and experience of veteran pair-programmers and jump-start our experience.

Unfortunately, it failed in that respect.

Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

First I started to warm up to the idea by observing how useful it was to sit down with someone and work with them on a piece of code, either debugging it or working through the initial design. Then it finally hit me when I realized that most of the problems that we have as programmers are not due to lack of skill or technology, but rather to lack of communication. Two programmers who communicate well and work very closely with each other will get a lot further than two people who shut themselves in their office, refuse to talk, and are hostile about anybody touching their code. When you only have a couple of people, it might not matter. But as teams grow and we have eight, ten, or more programmers, then communication becomes a much bigger issue.

But pair programming goes much further then just increased communication. It spreads knowledge through the team like wildfire. And that knowledge is not just of the code you’re writing, but also programming languages, design approaches, standards, tools, debugging techniques, etc.

Pair programming is also a key step towards having collective code ownership: code that everybody feels is his or her own and is willing to modify whenever it’s necessary. I’ve said it many times and I’ll say it again: the quality of a code base is directly related to how easy it is to modify. The more people feel that they know what’s going on, the more willing they will be to modify it whenever it’s necessary (and it’s much better to modify it in small steps than to take a huge hit and try to do a huge modification at once). The main ingredient of a healthy, easily modifiable codebase is unit tests, but that’s a whole other story.

Another consequence of pair programming is the reduction of sloppy or bizarre or just plain wrong code. It’s a lot harder for horrible code to happen when two people are at the computer writing something. Whenever the driver starts getting lazy and writing sloppy code, the other person immediately asks “What the hell are you doing? Shouldn’t we be doing this instead?” That’s usually enough to spur the driver into doing the right thing. Otherwise, he can always pass that keyboard and say “Fine, you do it.” I’ve been on both the giving and the receiving end of that situation, and it really works. In the end, you end up with a much better code base.

Finally, a consequence of pair programming that should not be underestimated is that it really fosters team spirit. Sometimes it’s hard to see that we’re all in the same team working towards the same goal. Extreme programming helps a lot in this regard, but pair programming helps a huge amount to get close and personal with your teammates and get to know them a lot better.

All right, going back to the book, where does it fit in? It has a fairly narrow focus, but somehow it tries to appeal to many people. In the introduction, they claim they are targeting developers who are thinking of trying pair programming (or convincing their bosses to do so), developers currently doing it, managers, QA, and even educators! I’m afraid that they over-reached a bit and spread themselves too thin on the ground.

The book is divided in four parts:

Part 1: Benefits of pair programming and how to sell it to your bosses and organization. This is the best-developed part, and this is where the strength of the book really is. Unfortunately, that’s not what I was looking for since we had already sold the idea of pair programming, but it could be useful for people hoping to roll it out in their organizations.

Of most interest are the studies that make a business case for pair programming and show how it really is not a wasteful use of resources. Just recently I was telling a friend how I was doing pair programming at work and his first comment was “Wow! I can’t imagine us doing that for budget/time-constraint reasons, but that sounds interesting.” But the whole point of pair programming is that it’s supposed to be better in the long run (and “long run” can be as short as a few months, and certainly less than one project cycle). This part will give you ammunition to debate this point.

Part 2: Getting started. This is what I really wanted to read a whole book about. It covers some things like the work environment and pair rotation. Unfortunately, it’s way too short and elementary. It covers a few of the basics and quickly moves on. This leaves the door wide open for another book on pair programming. If anybody knows of one that covers this topic, let me know.

Part 3: Tips and tricks. This section is completely forgettable. The book spends almost 100 pages (out of a slim total 260 pages) discussing different pair personalities: introvert-extrovert, introvert-introvert, gender and race issues, etc. Frankly, I didn’t get a single thing out of this section, which is very disappointing.

Parts 4 and 5: Miscellaneous stuff and case studies. I guess the book had to be bulked up a bit more, so it dedicates a chapter to extreme programming (go read Extreme Programming Explained instead) and another to Collaborative Software Process. Not much else of interest here either.

Given the lack of literature in pair programming, the book is definitely worth a quick read if you’re thinking of rolling out pair programming in your company. Part 1 will give you some good arguments to discuss with your managers and ease their fears. Otherwise, if you’re already doing pair programming there really isn’t much of value. It’s maybe worth a quick leafing through, but that’s about it.

In any case, if you haven’t tried pair programming, I really encourage you to give it a try. You don’t need to make it a sanctioned activity in your company. As long as you have somebody else willing to try it, you can both try the experiment of doing pair programming with each other working on both your tasks. You might be surprised that you manage to do both sets of tasks in the same amount of time it would have taken before, but with better quality, and, most importantly, you had a really good time in the process.

Exactly a year ago today, I put up the first article on Games from Within. It was a review of Tom DeMarco’s book Slack. I thought it would make for a nice, symmetrical bookend to wrap the year up with a review for another book by DeMarco: Waltzing with Bears.

As the subtitle indicates, Waltzing with Bears deals with managing risk in software development projects. Managing risk, not reducing risk, or removing risk. Do you think that low risk or even no risk is a good thing? Think again. One of the central points of the book is that a project with no risk is not worth doing. Yes, you read that correctly. Intrigued? Go and read the book right now.

I have to admit that the idea caught me by surprise as well. Maybe because I was used to the high-risk environment of game development, I always thought the best thing you could do for a project was to minimize the risk. But, as the authors point out, a project with no risk is not worth doing. It’s not going to enrich you in any way, and anybody can do it anyway. Their point is that risk and benefits are tied together. A project with a certain amount of risk will come with a certain amount of benefits.

Now that I’ve gotten quite a bit into playing poker, I see it very much like the analysis of expectation in poker. You want to bet when there’s a positive expected value, that is, when the potential benefits you’ll get from the bet outweigh the potential loss of money. As with poker, you can choose little risk and little benefit situations, or you can aim for high risk but huge potential payoffs (especially in no-limit poker). What you want to avoid are dead-end situations with high risk and very little payoff.

In particular, the authors single out death march projects as being of extremely low value.

Sounds strangely familiar, doesn’t it? The book then goes on to say:

Next time you’re deep into your third 60+ hour week in a row, think about those statements again and try to look at the big picture of your project in a new light. That just adds more fuel to the fire to my arguments against extended overtime and death march projects in general.

There are some things you need to watch out for if you’re going to start directly managing risk in your organization. The biggest problem you might encounter is that to manage risk you need to be brutally honest about the current situation of the project and possible negative outcomes. In a company where risk management is not a usual activity, it may come across as being overly negative, and you might scare away developers or even upper management. It can be particularly dangerous to do in a company with a very macho, “can-do” attitude (also described in the book as testosterone-based decision making), which is unfortunately all too familiar in the games industry.

One of the tools used throughout the book to describe projects and risks is probability curves. This emphasizes how things are not black and white. You don’t necessarily answer the question “when is the project going to be completed?” with a firm date, but with a probability curve. Looking at it tells you how likely the project is of being completed by a particular date (assuming the analysis was done correctly). The more “noise” and uncertainty there is in the project, the wider the curve is going to be. Unfortunately, it seems that it’s describing the games industry to a T again, because we tend to have a lot of uncertainty in our projects with moving technology targets and a somewhat whimsical market.

Another very interesting observation brought up in Waltzing with Bears is the concept of “early delivery.” Of all the games you worked on, how many of them were delivered early? Yeah, that’s what I figured. Same thing with me. Not a single one. Early delivery is seen as somewhat of a taboo. As if you didn’t work hard enough or you could have done a better job otherwise. So clearly, companies will never deliver a project earlier than the commit date. At best, they’ll do it by the exact deadline. At worst, the project will slip. As long as the two only possible outcomes are “on time” or “late,” then projects are very likely to keep being late. That’s some food for thought.

Later in the book, in the chapter about risk mitigation strategies, the authors make one very astute observation that I’ve seen repeated over and over in the projects I’ve worked on: projects that finish late are almost always projects that started too late. Truer words were never spoken. There are often very good reasons why a project can’t get started when it should (helping out another project, lack of funding, etc), but those weeks or months lost early on would be precious towards the end.

Perhaps it’s because I have a hopeless breadth-first personality, but I hate when books try to cover every single insignificant detail from the very beginning before giving you the big picture. I would much rather get a couple of passes, each building on what I learned in the previous one. That’s exactly what Waltzing with Bears does, with the first 50 pages dealing with an introduction and motivation to risk management, and the remaining 140 pages covering the same material in more depth and giving it a more advanced treatment. More books should learn from that organization.

Just go ahead and read the book and then pass it on to your manager. It’s short and well worth the read. The important thing is that somebody in your project should be actively managing risk and balancing how much risk you take versus what the potential benefits will be. Otherwise you might run into some very ugly situations that might lead to the cancellation of the project itself.

May 2005 be everything you hope for, and may your projects be managed wisely, with just the right amount of risk. Happy holidays to everybody!

Have you read Effective C++ also by Scott Meyers? No? Go buy it right now, read it, reread it, and then come back here. I guarantee that it will make a huge difference in the way you work.

This review was first published in the January 2002 issue of Game Developer Magazine.
Printer-friendly format.

OK, welcome back. Here is the good news: Effective STL is to STL what Effective C++ is to C++. It’s equally great and it’s written in the same light, conversational Scott Meyers style that makes reading it a pleasure. It assumes that you have basic knowledge of STL (and C++) and builds on that to show you how to use it effectively and avoid common pitfalls.

Those of you unfamiliar with STL must be wondering what it is and how is it useful for game development. STL stands for Standard Template Library: A library of generic data structures and algorithms that you can use across many compilers/platforms, including most of the current consoles. The library is implemented with templates so the resulting code will be quite efficient, possibly even more than your hand-coded structures and algorithms. Additionally, it has been implemented, tested, debugged and optimized by thousands of people, so it’s code you can usually rely on. STL also empowers you by putting very powerful constructs at your fingertips. Maybe before you would have thrown a bunch of objects in an array and searched through them in linear time (does that sound familiar?), but now you can just as easily put them in a hash table and have constant-time access to them.

Effective STL starts out with a fairly thorough discussion about containers (vector, list, map, etc) and iterators. It immediately goes beyond the typical description of the containers and their O(n) performance characteristics. Instead it deals with many real-world questions: Is the memory for the elements allocated contiguously? Are the iterators invalidated when the elements change? What the most efficient way of removing elements for a specific container? Those are not issues you’ll see addressed in most STL books.

It then moves on to algorithms and functors. Just like with the containers, instead of listing all the available algorithms, it points out common mistakes and how to deal with them. For example, it will discuss the different ways of sorting elements, or how std::remove really works (and why it doesn’t really remove anything).

The final chapters present more general, but very useful, information on the STL that will save you a few headaches along the way: When to use STL algorithms and when to use your own, style guidelines, or even how to deal with Microsoft’s Visual C++ broken STL implementation and template support.

But STL is not perfect. Reading the book will give you some ideas of where STL is lacking, but it won’t spell them out for you. Sometimes you’ll need to read between the lines and think about how things will apply to game development. For example, memory allocation can be an issue, especially if you’re developing for a console, so you’ll probably want to end up writing your own allocators. The book has a brief couple of items discussing what you can and can’t do with allocators, but not enough to write your own. You’ll need to look elsewhere for that.

Another issue often brought up when dealing with STL is the difficulty debugging STL code, from cryptic multi-line error messages to the difficulty viewing the elements of a container in the debugger. The book will help you a bit by showing you how to “parse” the intimidating error messages and directs you to some STL resources on the Internet.

Effective STL works very well both as a book to read cover to cover and as a reference later on. It only uses source code where it has to; it won’t bore you with pages and pages of pointless code. As a matter of fact, it won’t bore you at all since it packs a lot of information in a mere 250 pages. Overall, you simply must read this book before you decide to use (or not to use) STL in your next game or tools. If you’re already using STL, then it should already be on your bookshelf.

Even though I read a lot of technical books, either I must have pretty good instincts or the publishing quality bar is quite high, because I never read one I thought was totally worthless. Until now that is.

I’m not even sure where to begin. As soon as I try to put my thoughts together, a whole rush of negative points immediately comes up and prevents me from even organizing them in some sort of coherent way. I suppose I’ll start with the easy part and share the only two useful bits of content that I was able to glean from the book:

• Logic doesn’t prevail in the corporate world.
• Programmers need to understand managers and managers need to understand programmers.

Both of those are very valid points, and understanding them will help anyone developing software for company. There, no need to buy the book anymore. I’ve just saved you $29.99 + tax, a few hours of your life, and medication costs from elevated blood pressure.

OK, now that we’ve gotten that out of the way, why was this book a complete waste of time? The first problem is one of style. The author is probably a very entertaining speaker. He might even be a passable column writer. He has a light-hearted style and is ready to make a joke at moment’s notice. I like jokes as much as the next guy. I also like chocolate fudge, but I would throw up if I were forced to eat several pounds straight for dinner. That’s how this book feels.

The problem with the jokes is more than just a style issue. All the funny remarks and irrelevant (and mostly incomprehensible) jokes about chihuahuas are just a cover-up for the total lack of content. Reading a chapter of the book is like eating cotton candy: You go through the motions, it takes a while, but in the end you haven’t really eaten anything.

Then there’s the attitude. I think that’s probably what most got to me. The author has a “cowboy” attitude that permeates the whole book. You know the type I’m talking about. Coding is the coolest thing in the world, and, left to his own devices, he’d just spend all day and all night in his office hammering away at the keyboard. His ideal vision of programmers is that of “professional athletes and rock stars.” He also naturally assumes that everybody reading the book feels the same way.

His distinct dislike of everything academic is very telling about the general attitude. He couldn’t possibly learn anything of value from those ivory-tower mad scientists. He goes as far as to be totally disrespectful and referring to people as “terminally educated” and implying they’re worthless in the workplace.

With that attitude he forges ahead and starts spewing horrible advice. Not a word on how to improve a project, not a word on how to deliver a better product. It’s all about saving his butt and enjoying his coding. Everything else is secondary. He doesn’t go beyond that and assumes everything will remain the way things are. For example, he takes for granted that you’re going to spend most of your time in the debugger tracking down bugs. Hello, how about minimizing those bugs and taking steps towards catching them in other ways? I wonder if he’s ever heard of unit tests, test-driven programming, or agile methodologies. There’s certainly not a mention of them anywhere. Too busy coding I suppose.

As if things weren’t bad enough, the overall message of the book is to try and put up with evil Corporate America, deal with it and do your coding job, and if things go bad, quit. Nothing wrong with quitting, but that seems to be the motto of the book. Not surprisingly, the author’s biography lists his claim to fame being a consultant for a bunch of companies without any particular accomplishments. Just a string of failed projects after failed projects. No wonder he’s burned out and jaded. Is this the guy we want to be taking advice from?

Finally, the most of the advice he gives is either outdated, ridiculous, or just plain wrong. He pretty much advocates a waterfall approach to development, and “getting your requirements etched in stone”. I really couldn’t believe it when I saw it. I thought it was a joke. Maybe that works for consultants getting paid by the hour trying to make a fat check and do their coding undisturbed, but it doesn’t work for those of us trying to create a good product. Or maybe that’s a technique that works in corporate America? I think not.

The only saving qualities of the book were that it was relatively short (just a bit over 200 pages), so the pain didn’t last for too long, and the fact that I actually had fun writing this review. This was the first book I read by this publisher (a! APress), so I’m going to be very cautious with any of their other books in the future. Stay far away from this book unless you’re masochistic or your idea of an ideal workplace is something like The Office.

Over the years I’ve read hundreds of technical books. Some of them had some great new ideas, others were great introductions to specific topics, and others had a knack for explaining some complex topic in a very easy to understand way. But in the end, which books had the most impact on me? If I had to go back and pick only a handful of books, which ones would I pick? This is that list.

If there’s a book here on a topic you’re interested in and you haven’t read it, don’t think about it twice, buy it right away and bump it up to the top of your reading queue. You won’t regret it.

On the flip side, feel free to recommend to me any books you feel very strongly that should be here. I make no guarantees, but if it’s a total knock-out, maybe it’ll make it to this list in a couple of weeks.

Project management

Rapid Development by Steve McConnell

Simply put, if you’re a lead or manager for any project, you must read this book. Not doing that is simply irresponsible. This book is packed with no-nonsense advice on how to run a project. If almost 700 pages is a bit too much, you can start with the Software Project Survival Guide also by McConnell. It covers the same ground but concentrates on the “whats” as opposed the “whys”.

Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco

A new look at what it means to be really efficient and why that’s not the same thing as being really effective. Along the same lines of this book is the classic Peopleware, by Tom Demarco and Timothy Lister.
[Read the full review]

Extreme Programming Explained: Embrace Change by Kent Beck

Even if you’re not doing Extreme Programming, you should at least know what it is and why some people are so excited about it. Considering how unpredictable game development is and how much design, technology, and publisher preferences change from day to day in game development, any book that encourages us to “embrace change” is heading in the right direction.

C++/STL

Effective C++: 50 Specific Ways to Improve Your Programs and Design by Scott Meyers

After you’ve put in a year or two of C++ under your belt, this book will singlehandedly catapult your C++ learning curve ahead by a couple of years. Once you’ve memorized it you can move along to More Effective C++ (also by Scott Meyers, of course). Incidentally, Scott Meyers is probably one of the best technical writers I’ve ever had the pleasure of reading, so you’ll have a great time along the way as well.

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library by Scott Meyers

Scott Meyers applied the same formula once again and came up with this book. Just like Effective C++, it highlights the major pitfalls, common idioms, and recommended techniques when working with STL. Again, this is not to learn the STL, but to take your skills to the next level.

Large-Scale C++ Software Design by John Lakos

It’s starting to get a bit outdated, but it’s one of the few books that deals with the real-world issues of C++ development. Is your program starting to take too long to compile? Are you finding it hard to separate the different sections of your code base? Then you need to read this book. Warning: This is one heavy, slow-going book with lots and lots of content. Don’t hesitate to put it down for a while and then come back to it. [Related article]

Software design

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

This book was an eye-opener for me when I first read it. It put a name to and helped consolidate and formalize many ideas that I already had in my head, as well as plant lots of new ones. This could easily be the book that has most influenced me in the last 10 years. It is also one of the ones that I regularly skim through and I always learn something new I had missed before.

Game development

Game Programming Gems edited by Mark DeLoura

Take equal parts of the best technical articles from Game Developer Magazine, the most interesting GDC presentations, and the cleverest tricks you read online, and you have an idea of what this book is all about. This is a collection of small articles written by professional game developers. It covers a large variety of topics, but you’re guaranteed to find something directly relevant to whatever you’re working on at the moment.

Game Programming Gems 2 edited by Mark DeLoura

More gem goodness.

Game Programming Gems 3 edited by Dante Treglia

Another worthy addition to the Gems family. The bookshelf is starting to get full by now.

Game Programming Gems 4 edited by Andrew Kirmse

And who said sequels are bad, uh? Besides, did you notice the really cool cover?

Computer architecture

Computer Architecture: A Quantitative Approach by John L. Hennessy, David A. Patterson, David Goldberg

If you’re a typical, well-read game developer, I suspect you will have nodded your way down this list. You will have read, or at least heard of just about every book here. Until this one. This is not a typical recommendation in a game development book list. Why is it here? Perhaps is my computer engineering background, but I found this book simply fascinating when I first read it in college, and I’ve referred to it often since then. If you want to get a good grasp on both the fundamentals and the details of CPUs, cache systems, or disk IO, this is the best book on the subject. Next time a console manufacturer says their system has an 8-way set associative L1 data cache with write-back, and no-write allocate, you’ll know exactly what they mean.

History

Hackers: Heroes of the Computer Revolution by Steven Levy

OK, I admit it, I’m a converted hacker. Even though I’m now a big proponent of software engineering methods and a well-defined development process, I fell squarely in the third generation of hackers (the 80s) described in the book. This book just holds a very special spot in my heart as my dog-eared paperback copy can attest. Not only does Steven Levy manage to present a very complete history of software and game development following some exceptional individuals, but he manages to make it into an extremely gripping and entertaining book. No self-respecting geek should miss this one!

Masters of Doom by David Kushner

This book is the spiritual successor of Levy’s book. It picks up in the mid-eighties, just where Hackers left off, and it describes a new generation of hackers, this time concentrating on a smaller subset of people (John Carmack and John Romero, the founders of id). Be warned, this book is even harder to put down than Hackers and it’ll have you questioning your life choices for weeks afterwards.

Here’s a book I wish every manager would read, especially the managers in charge of my project (pure self-interest in my part, I admit it). It’s short, focused, to the point, and it drives home a very powerful message: By being constantly busy working you’re probably hurting your project and your company.

The whole book revolves around that idea, provides explanations, examples, and the consequences. It’s also a very short book, just over 200 pages of large print and easy reading (intended to be read in a two-hour flight as the author put it), which is good considering it’s aimed at busy managers. Ironically, the people who need to read the book most won’t even know it exists or won’t be able to make the time to read it. A while back, I forced a copy upon one of my managers and I said to him “Here, you must read this.” Supposedly he started reading it but never finished it. I don’t think the book really did it for him (and he still has my copy, oh well).

So how can adding time that is not set aside for specific tasks, or “slack”, in the schedule of a manager or a lead or even a senior staff member help the project? Shouldn’t everybody be grinding away with their noses down and fingers glued to their keyboards? When someone is working all the time, he’s more efficient because he gets more units of work done in a fixed amount of time. However, he can be less effective than someone with slack into his schedule.

DeMarco very effectively argues that slack allows some very important things to happen. First of all, it allows an individual (and therefore the company) to react more quickly. The manager can take an hour right away and fix something that will benefit the whole team. Otherwise, he might not get around to doing it for another week or two, or after the milestone… or ever. The second benefit is that it allows people to stop and think about what they’re doing, why they’re doing it, and how they can do it better. In other words, it allows for constant process improvement.

And if you’re starting to think of making up slack time by putting in more hours, stop right there. Go read DeMarco’s other book, Peopleware, before you get any bright ideas. The conclusion is that putting in more time beyond a certain amount doesn’t make the project go any faster (but it makes your employees unhappier and go away a lot faster!). No, we’re talking about true free time. It doesn’t mean that people are going to be twiddling their thumbs during that time though. They’ll be researching new ways of doing things, trying out new tools and techniques, reading new books (!!), learning a new language, or helping out with some emergency that came up.

Two gems from the book that are worth the price of admission by themselves:

The First Law of Bad Management (actually from another source, but mentioned in the book): If something isn’t working, do more of it.

Sounds ridiculous, doesn’t it? Yet, how many times have we seen that happening all around us? “We’re putting all this overtime and we keep missing milestones. We must put more overtime!” Next time things start heading south in your project, stop for a moment and think about this again. It won’t feel so funny anymore.

The Second Law of Bad Management: Put yourself in as your own utility infielder.

In other words, a manager shouldn’t also be doing work for the project he’s managing. Even though it feels very tempting, and there are even managers out there who pride themselves in it, it’s usually a bad idea all around. It ties up the manager’s time instead of having “slack” time to react to any unexpected events. It also means that the work done by the manager isn’t supervised by anybody other than himself. People in general, and programmers in particular, tend to be overly optimistic about their own work, so, without any external checks, that work could easily slip big time or quality can suffer. You need to have nerves of steel to tell your boss that he’s writing crappy code and he shouldn’t be doing it.

I’ve seen this situation happen several in my time in the games industry, and never with a good ending. It’s usually because managers are just programmers who have put in their years in the ranks and have been “upgraded” to a management position. They claim they’ll do 60% management and 40% programming. Buzzz! Wrong answer! Unless they’re managing only one or two more people, that’s not going to happen; they’re going to do both jobs half way and neither one well.

The other very common situation is when a team member leaves half way through the project (a topic for another article) and the manager decides he’s going do take up the job Bob was doing. Next thing you know, the manager is locked in his office doing Bob’s work (poorly since he doesn’t fully understand it and he’s out of practice) and not managing the project as he should.

Even if you’re not a manager, you can greatly benefit from reading the book. Maybe one day you’ll be in charge of other programmers, and in the meanwhile you can take a copy and give it to your boss. Tell him what you want, but make him read the book. It’s even really cheap, so you have no excuse not to buy a copy now. Just make sure you write your name in it; hopefully you will get your copy back.