I recently read a book called The Career Programmer by Christopher Duncan. I typically don't post book reviews unless I really love a book and want to spread the word, but in this case I felt compelled to post in order to spread the warning. I can't remember a book I've hated more.
"The Career Programmer" is meant to be a dispensation of wisdom from a sage, a book that gives younger programmers keen insights from someone who has been in the industry for a long, long time. I tend to really enjoy books like this, so I picked up a copy. Unfortunately, it comes across as an anachronism, like the book time-traveled out of the mid-90's. While reading it, I felt compelled to double-check the publication year, and was absolutely astonished that it was printed in 2006. The "wisdom" of the book is so hopelessly out of date with the current state of software development that I cannot recommend it to absolutely anyone.
Duncan's view of software development is straight out of Dilbert. Managers are idiots that hold all the power, programmers are just lackeys that do what they are told. In his world, "shit rolls downhill" and programmers are at the bottom of the hill. Duncan has over a decade of experience in the industry, which is the basis for his advice. Well, I also have a decade of experience and I have never, ever worked in a place as dysfunctional as what he describes as typical. Perhaps I am extremely lucky or just extremely talented, but I doubt either of those are true. If I found myself at a company like those Duncan describes, I'd leave immediately and get a new job, I certainly wouldn't build a 10-year career stringing those experiences together.
As an example of what I'm talking about, Duncan describes that programmers are expected to "do whatever it takes" to get the job done, which means:
"Now would be a great time to rent out your house because you're not going to be seeing much of it until after the deadline. You will code, eat, and do everything but bathe in your cube for as many consecutive hours as you can manage to stay conscious."
Duncan's book is meant to contain tips for avoiding this scenario, but I've avoided this scenario my whole life without them. In my 10-year career, I have worked late on exactly 3 occasions, each lasting no longer than one week. On these occasions, I was home by 9pm. On 2 of those 3 occasions, my team and I worked late not because it was expected of us, but because we had messed up and supplied a commitment we shouldn't have, and we felt honor-bound to meet it. Any other work outside of office hours has typically been a midnight deployment, and the expectation has always been that I'd be sleeping in and coming in late the following day.
Pointy-haired bosses have never demanded I work late to meet a deadline. In my experience, programmers that habitually work late are the worst programmers, constantly digging themselves into spaghetti code nightmares that result in them making up for lost time. Working late is an admission that you suck too much to get your job done during business hours, and most managers know this. I don't think my experiences are the exception, I think they are the rule. Most companies simply don't operate this way anymore, and those that do tend not to have developers for long.
He goes on to talk about vague requirements with tight deadlines. He states:
"It's almost completely unheard of in our business for management to ask us for a system without attaching a timetable of some sort."
This is nonsense, and can come only from a programmer who has had absolutely no experience with agile development. This kind of death march was common in a time when people were all-Waterfall, but in the post-agile-manifesto world, this kind of thing is vanishingly rare. Almost every project I've worked on has either had a fixed delivery date with variable scope, or fixed scope with a variable delivery date; very rarely are both dimensions fixed.
Duncan confirms that his view of the world is based in Waterfall when he talks in Chapter 2 about how management often shortchanges the "Analysis and Design Phase" - terminology right out of Waterfall. Chapter 4 talks about gathering requirements in an official requirements gathering phase, and getting them "set in stone". He argues that a formal requirements document gives you "ammunition further down the road when someone comes along and wants you to add additional features." This kind of thing is dinosaur-talk, people who know what they are doing don't develop software this way. They gather small numbers of isolated requirements in user stories, and get those stories finished and in the hands of users. In real life, software requirements are going to change - pretending you can get requirements set in stone to protect yourself later on is simply divorced from reality. It's far better to embrace a process that allows for that kind of shift, as virtually any professional software developer I've met in the last ten years would attest.
The book constantly references the "maintenance programmer," the concept of a programmer that takes over maintaining the system after the Serious Developers have built it. This type of development is such a glaring antipattern I can hardly have imagined someone mentioning it in any positive context in 2006. The programmers that write the system should maintain it, end of story. All programming is maintenance programming, developing a system and throwing it over the wall is a recipe for long-term disaster. Again, I haven't heard anyone talk this way in a long, long time. Duncan's notions of software are a blast from the past.
The real clincher for me was Duncan's chapter on Effective Design Under Fire. Duncan acknowledges that there are many "excellent books on the software design process lining your shelves" but that he has "rarely been in a shop in which management gave the developers even a fraction of the time necessary to fully implement these methodologies." First of all, writing well-crafted, maintainable, high-quality code is not management's call, it's yours as a professional. To shirk your professional responsibility because of deadlines is to be professionally negligent. Duncan confirms my worst suspicions when he states:
"I'm about to ... destroy my reputation in the eyes of credible and respectable professionals everywhere. However, I've got deadlines to meet, and I've always been more interested in that than looking respectable."
Combine this attitude with Duncan's belief in the "maintenance programmer" and the fact that he spent most of his 10-year career as a contractor and a pretty clear portrait is painted: Christopher Duncan comes off as someone who writes crappy code and then bounces to another job before having to maintain it. Duncan seems like the worst type of programmer: the guy who doesn't worry about writing quality code because there's Just No Time and then believes it's someone else's job to clean up after his mess.
When Duncan is explaining some tactics for good design, he advocates Big Design Up Front (wrong) but suggests to basically rush it as much as possible (doubly wrong). He argues for prototyping systems before actually building them (often wrong) but describes prototypes that are fully-functional UIs (wrong) with nonfunctional implementations (wrong). If you're going to build a prototype, you should build a steel-thread prototype with a garbage UI - there is literally no point to the kind of prototype Duncan describes except to mislead your stakeholders about the progress of the system. His view couldn't be more wrong.
Duncan argues that accurate estimates are essential. He devotes a chapter to improving your estimation technique which boils down to this:
"just to be on the safe side and make sure we have a little cushion in case things go wrong, we multiply [our estimates] by two and give it to the project manager [who then will] multiply the numbers he was given by two and turn the estimate in"
Duncan's strategy for estimates is to pad all estimates by a factor of 4. Why 4? Why not 2, 3, or 8? What a completely unprofessional stab in the dark. How is possible to be this criminally unaware of scrum, sprints, story points, and velocity in 2006? For crying out loud, as our industry has matured and improved, even Scrum is out of date in favor of a more metrics-oriented planning within a Kanban framework - Duncan is two process methodologies behind the times.
The book is well-written and entertaining, so at a technical level it is good, but the advice is presents is the worst possible.
I really don't mean to be too harsh on Christopher Duncan. He seems like a genuinely funny, nice guy, and my issue is not with him personally, but with the advice contained in this book. He was a Windows C++ programmer who spent most of his career developing software that shipped on CDs. Towards the end of his career, he saw a sudden shift toward the Web for delivery, and attempted to learn Web-related technologies, then soon after quit the industry and became a full-time speaker and author. Maybe if Duncan had stuck with it, he would have matured and grown along with the rest of us rather than stay stuck in his antiquated notions of professional software development. But the fact of the matter is, he didn't, and the world has changed without his awareness. To publish a book full of outdated wisdom as though it had any applicability to today seems borderline careless. I shudder thinking of young programmers reading his book for career advice, taking it to heart, and then joining a team I'm on. Is it illegal to screen out any job applicants who like it? *The attitudes in The Career Programmer are absolute poison for a good software engineering team. *
Everything about this book is wrong. Every aspect of The Career Programmer is covered better, by people who know what they are talking about, in other books. Here's my list of suggestions for similar books that are all vastly superior to this one:
- The Pragmatic Programmer - Full of general tips for programmers to improve their skills.
- Emergent Design - Describes the ACTUAL way to handle design under pressure: by organically growing and evolving the design of the code as needed.
- The Passionate Programmer - Covers how to handle your career development.
- Agile Estimating and Planning - Describes how to estimate work well within an agile framework.
- User Stories Applied - Talks about how to gather requirements properly. Another good one is Agile Software Requirements, which is quite a bit more in depth.
- The Clean Coder - All about how to conduct yourself professionally, how to interact with the business and handle "politics".
The Clean Coder is the one that is most similar to The Career Programmer in terms of purpose, but in almost every way it is the polar opposite. I think every programmer should read The Clean Coder, but even moreso if one finds him or herself tempted to read The Career Programmer.
Do not, under any circumstances, read this book. It will bore and annoy you at best, and ruin you at worst.