What do you think?
Rate this book
The Career Programmer: Guerilla Tactics for an Imperfect World
The Barnes & Noble Review
For years, The Career Programmer has been the definitive guide for programmers who want to succeed in the workplace. It's still that. But in today's age of outsourcing, when you're lucky to even have a pointy-haired boss, it's more. This Second Edition is a terrific guide to getting hired, evading age discrimination, even hanging out your own shingle and "flying solo."
For years, The Career Programmer has been the definitive guide for programmers who want to succeed in the workplace. It's still that. But in today's age of outsourcing, when you're lucky to even have a pointy-haired boss, it's more. This Second Edition is a terrific guide to getting hired, evading age discrimination, even hanging out your own shingle and "flying solo."
Christopher Duncan's the same joy to read as ever: wry, sometimes flat-out funny, always real. You can tell he's been there. Is there. You can tell it when he's writing about wrangling corporate bureaucracies, or managing your time, or estimates, or requirements, or QA. You can tell it when he's writing about resumes, job interviewing, or overcoming fear of change. If you want to take control of your programming career, instead of griping about it (or mourning it), read this book. Bill Camarda, from the March 2006 href="http://www.barnesandnoble.com/newslet... Only
576 pages, Paperback
First published January 17, 2002
8 people are currently reading
135 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 9 of 9 reviews
October 16, 2012
"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.
January 7, 2020
Avoid, except when referring it as some sort of anthropological study. A campsite story of the us-and-them times when software was as flexible as hardware (requirements were set in stone, there was a design phase, estimates were relevant and we shipped on CD). From author who doesn't suggest relevant literature and ignores industry moving towards closer cooperation with business (agile and lean aren't words you are going to see here, quite a few obsolete practices are suggested instead). If you happen to work for company that's even slightly relevant to what's covered - run, it's a trap (toxic environment).
'Pragmatic Programmer' or even Weinberg's 'Understanding the professional programmer' from 1982 are way better use of your time.
'Pragmatic Programmer' or even Weinberg's 'Understanding the professional programmer' from 1982 are way better use of your time.
June 13, 2024
Most of the content is still practical over 20 years later. Worth taking notes and reflecting on work habits and approaches as you go through.
But, definitely one of the least readable tomes I have had to go through. Reading speed would slow grind downwards going through pages - there were weeks thinking about reading the next chapter was more emotionally deflating than uplifting.
Would be interesting to see if other found readability an issue as well. Shame since the content is pretty good. Maybe a modern update to fix the flow or break it up to make it more readable?
But, definitely one of the least readable tomes I have had to go through. Reading speed would slow grind downwards going through pages - there were weeks thinking about reading the next chapter was more emotionally deflating than uplifting.
Would be interesting to see if other found readability an issue as well. Shame since the content is pretty good. Maybe a modern update to fix the flow or break it up to make it more readable?
July 30, 2010
Super summary: Technical skills are important. However, they are not sufficient, and you may need to engage in politics. Be nice to people. Have sufficient sleep. Be honest. Be prepared. Have proper time management. Be pro-active in asking for deadlines to be adjusted together with change in requirements, and in making the coding process better (hiring testers etc...). Other options besides being a programmer include going solo, being a tester, vertical industry, sales...
These are the main messages of the book. Reading the book will give you an appreciation of what goes on in the career of a programmer. At the end of it, what is important is not the individual stories in it, but the main messages this book is trying to bring across.
These are the main messages of the book. Reading the book will give you an appreciation of what goes on in the career of a programmer. At the end of it, what is important is not the individual stories in it, but the main messages this book is trying to bring across.
This entire review has been hidden because of spoilers.
January 13, 2014
I enjoyed the read and would recommend it to any programmer. Gives good advice on perceiving the culture of your organization and learning the warning signs that signal either you've overstayed your welcome or that it's time to abandon ship like any good rat would.
I've seen these situations play out several times.
I've seen these situations play out several times.
August 22, 2010
It was an OK-reading. Definitely a tactical book for a developers -- to be smart in dealing with corporate politics.
March 29, 2013
A should-read book on office politics which will happen to you and around you whether you participate in politics or not.
Read
October 12, 2013True
January 2, 2016
This book is for people who would rather write estimates and requirements documents than code. If the tactics described within sound helpful, you need to get a new job.
Displaying 1 - 9 of 9 reviews