Because I read both books around the same time and they have quite a bit in common, I'm going to compare and contrast this book with Tina Fey's BossypBecause I read both books around the same time and they have quite a bit in common, I'm going to compare and contrast this book with Tina Fey's Bossypants.
Both books deal with the lives of writers producing television shows, so it's easy to compare them.
Fey's book is lighthearted, self-deprecating, and extremely funny. Gurvitz's book, on the other hand, is angry, bitter, and completely unfunny.
Now, I'm not saying it's unfunny BECAUSE it's angry and bitter. I love angry bitterness as much as the next guy, I love Lewis Black, Louis C.K., and many other dark comics. Ian Gurvitz's book isn't unfunny because it's mean, it simply happens to be both.
Considering that the book is written by a comedy writer, as well as the fact that Gurvitz is clearly trying to be funny, it says a lot that this book induced nary a single laugh from me. Fey's book, on the other hand, had me laughing out loud while reading it in public on numerous occasions.
The reason this is so interesting to me is that Fey's book is largely about success - she was the head writer on a few seasons of Saturday Night Live, and went on to be the head writer of 30 Rock, an excellent comedy show. She's one of the most successful female television writers today, and her story is one of triumph.
Gurvitz's book, however, is largely about rejection and failure. Constantly his work is being rejected - in fact a sizable portion of the book is devoted to him trying to get some pilot scripts sold, only to be told over and over that his shows are too dark and bitter. He concludes from this that television producers are stupid assholes, but I can't help but wonder if maybe they were telling him to lighten the scripts up in a desperate attempt to eek some comedy from him.
30 Rock is one of the funniest shows on TV. Gurwitz is responsible for obnoxious multi-camera sitcoms such as Wings, Becker, and the abominable "The Exes" (the creation of which provides much of the book's content). 30 Rock's jokes are clever, while Wings, Becker, and The Exes all aim for broad audiences with run-of-the-mill humor. It's interesting to read two perspectives on Hollywood TV. Fey is genuinely funny and talks a lot about those to whom she owes her success, while Gurvitz is a humorless prick who blames everyone else for his failures.
Every chapter opens with Gurvitz talking about the news at the time of writing, which almost always centers on George Bush or the Michael Jackson trial. The jokes he makes in these openers are the sorts of things that aren't even fit for Jay Leno's monologues. The humor is so predictable and embarrassing, it's amazing that Gurvitz actually has good taste in humor, talking about other TV shows that he finds genuinely funny.
One of my favorite parts of the book is how Gurvitz talks about how there aren't that many original TV show ideas, but it's all about execution. He's right, Friends was just "young people in the city" which had the same basic plot as dozens of other TV shows, but Friends was a huge success because of how well it was executed. Later in the book he discusses some of his ideas for TV shows that he's trying to sell to various networks, including a show about prostitutes. None of the networks go for it, but towards the end of the book he talks about how a network just picked up a show about a group of call-girls, noting with a tinge of bitterness that it was almost the exact same idea he pitched the very same network earlier. Most people, especially those who had realized the "execution is everything" point he made earlier, would take this as valuable criticism of their writing ability, but instead Gurwitz refuses to realize this, and blames the network for being dumb.
The book is very interesting, with lots of insider information about how TV shows are written and produced. Extracting these facts can be informative and entertaining, but it's a shame that it's surrounded by Gurvitz's relentless bitterness. I'm sure he wants the reader to feel like Hollywood just turns people bitter, but I came away from the book feeling like Gurvitz just kind of sucks as a writer and blames the world for it. The painful humor of his book and the TV shows he's so proud of writing solidify this view for me.
If you're willing to wade through Gurvitz's self-pity and misdirected anger, the book is a mildly interesting read, though I don't recommend the audiobook, as it's read by the author and even he is clearly bored to death with his own words, reciting his prose with a detached monotone....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"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. ...more