...
Show 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. Unfortunately, it comes across as an anachronism, like the book time-traveled out of the 80'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 10 years of experience in the industry, which is his basis for his advice. Well, I also have 10 years 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, and every one of my friends who programs for a living would likely agree with me about Duncan's worldview. 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." 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 working late.
He goes on to talk about vague requirements with tight deadlines. He even 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 utter 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 write code this way. We gather small numbers of isolated requirements in user stories, and get those stories finished. 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 real life. 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 10 years would attest.
The book constantly references the "maintenance programmer," the notion 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 imagine 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. Everyone but Duncan seems to know this.
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 garbage code and then bounces to another job before having to maintain it. Duncan seems like literally 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. Based on this book, I'm pretty sure I would hate working with Duncan, and I would never hire anyone that cited this book as any sort of inspiration. The attitudes in The Career Programmer are absolute poison for a good software engineering team.
When Duncan is explaining some tactics for good design, he advocates Big Design Up Front (wrong) but just to rush it as much as possible (doubly wrong). He argues for prototyping systems before actually building them (usually 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 acknowledges that accurate estimates are essential. He devotes a chapter to improving your estimation technique which boils down to "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." The project manager then goes on to "multiply the numbers he was given by two and turn the estimate in" (page 113). 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 2 process methodologies behind the times.
On page 145, Duncan advocated using Hungarian notation for variable naming, at which point the book devolved into self-parody. The book is well-written and entertaining, so at a technical level it is good, but the advice is presents is the worst possible.
Look, I don't mean to be too harsh on Christopher Duncan. 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 promptly quit the industry and became a full-time speaker and author. Maybe if Duncan had stayed in the industry, 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?
Everything about this book is wrong. If you want a book full of good advice for programmers, read The Pragmatic Programmer (Thomas, Hunt). If you want a book about how to best handle the design of your system, read Emergent Design (Bain). For a book on how to manage your career, read The Passionate Programmer (Fowler). If you need a book about estimation, Agile Estimating and Planning (Cohn) and if you need one for requirements gathering, User Stories Applied (Cohn) or Agile Software Requirements (Leffingwell) if you're really serious. And for the love of all that is holy, if you want a book on how to conduct yourself professionally, read The Clean Coder (Martin).
Do not, under any circumstances, read this book. It will bore and annoy you at best, and ruin you at worst.
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 10 years of experience in the industry, which is his basis for his advice. Well, I also have 10 years 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, and every one of my friends who programs for a living would likely agree with me about Duncan's worldview. 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." 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 working late.
He goes on to talk about vague requirements with tight deadlines. He even 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 utter 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 write code this way. We gather small numbers of isolated requirements in user stories, and get those stories finished. 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 real life. 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 10 years would attest.
The book constantly references the "maintenance programmer," the notion 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 imagine 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. Everyone but Duncan seems to know this.
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 garbage code and then bounces to another job before having to maintain it. Duncan seems like literally 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. Based on this book, I'm pretty sure I would hate working with Duncan, and I would never hire anyone that cited this book as any sort of inspiration. The attitudes in The Career Programmer are absolute poison for a good software engineering team.
When Duncan is explaining some tactics for good design, he advocates Big Design Up Front (wrong) but just to rush it as much as possible (doubly wrong). He argues for prototyping systems before actually building them (usually 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 acknowledges that accurate estimates are essential. He devotes a chapter to improving your estimation technique which boils down to "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." The project manager then goes on to "multiply the numbers he was given by two and turn the estimate in" (page 113). 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 2 process methodologies behind the times.
On page 145, Duncan advocated using Hungarian notation for variable naming, at which point the book devolved into self-parody. The book is well-written and entertaining, so at a technical level it is good, but the advice is presents is the worst possible.
Look, I don't mean to be too harsh on Christopher Duncan. 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 promptly quit the industry and became a full-time speaker and author. Maybe if Duncan had stayed in the industry, 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?
Everything about this book is wrong. If you want a book full of good advice for programmers, read The Pragmatic Programmer (Thomas, Hunt). If you want a book about how to best handle the design of your system, read Emergent Design (Bain). For a book on how to manage your career, read The Passionate Programmer (Fowler). If you need a book about estimation, Agile Estimating and Planning (Cohn) and if you need one for requirements gathering, User Stories Applied (Cohn) or Agile Software Requirements (Leffingwell) if you're really serious. And for the love of all that is holy, if you want a book on how to conduct yourself professionally, read The Clean Coder (Martin).
Do not, under any circumstances, read this book. It will bore and annoy you at best, and ruin you at worst.
