The Career Programmer

BanzaiBill writes with the review (below) of Christopher Duncan's The Career Programmer: Guerilla Tactics for an Imperfect World, writing "When this book came out a year ago, I bought it, but was in the middle of massive death march. Frankly, the first three chapters depressed me! It hit a little too close to home. Of course, I wasn't sleeping either, and that turned out to be more important than reading. After a few months of recuperation, I picked it up again. So many of the points this book makes were on the money that I felt I needed to spread the word." Read on for BanzaiBill's review of a book that addresses aspects of programming success not listed on job requirements. The Career Programmer: Guerilla Tactics for an Imperfect World author Christopher Duncan pages 211 publisher Apress rating 9.5 reviewer BanzaiBill ISBN 1590590082 summary A funny, pragmatic guide to successful software development

What's with the title? The Career Programmer: Guerilla Tactics for an Imperfect World is a gem of wisdom in a sea of dry, academic books on the software development process. It seems to mix equal parts of any software process book, Dilbert, and Sun Tzu's The Art of War. The development "process" that most developers find themselves enduring today isn't too dissimilar from the "process" that developers have endured for the life of our industry. Management specifies deadlines before they specify requirements, and frown when programmers start designing instead of immediately typing. There are a lot of things wrong with this, but the problem persists.

For this problem, there is at last a real answer. Duncan, a developer himself, brings the wisdom he's gathered during the course of his career to bear on the problem. Surprisingly, he succeeds. With exquisite humor and wry wit he prescribes remedies for the variety of ailments that beset the software development process. The Career Programmer helps software developers in the areas where they are often weakest, from dealing with the politics of an organization, providing estimates that are real, and coping with the realities of management driven timelines. In short, all of the things you never learn in any school except the school of hard knocks. If you want to avoid the endless death march, have a life outside your job, and gain credibility by delivering your software on time and under budget, this book is for you. This book is intended for software developers of all skill and experience levels, no matter which language or operating system they might use.

The Career Programmer differs from most books on the development process in several ways. First, and most importantly, it is a pragmatic book. There are no pretensions to developing the "one, true process" that is better than all of the rest. It concentrates on strategies that work. Different environments require different strategies, and this book doesn't ignore the impact of office politics on the development process. Many developers already know how to develop software in a perfect world, but few are allowed to gather requirements in sufficient detail, take adequate time for design, develop test plans or any of the other important aspects of development. There are a variety of reasons for this, and this book covers them well.

Second, this book provides much-needed balance to books that focus only on the development process, by reminding the reader why the company they work for is in business. Obviously, it's not to let you play with the latest cool tools, despite the attitudes of many developers I've known. Learning to appreciate what motivates the managers and executives at your company is vitally important if you want to succeed. They pay the bills, and you work for them. That makes them important, even if they can't code a bit. Last, succeeding in spite of your boss sometimes requires you to fly under the corporate radar to be successful. Like any good guerilla, you do your best work when you aren't noticed.

What's in the book? The first section of the book, "Software Development in an Imperfect World," introduces the reader to the realities of the corporate world. For someone just out of college, this section is bound to be a rude awakening. They probably didn't understand why Dilbert is so funny, either. However, there is a lot of information in this section that will be useful for veteran developers, especially those who feel that they shouldn't have to "play politics." Playing the political game doesn't have to mean you stab people in the back, but it sure helps if you don't want to be on the receiving end. This section lays out the issues and problems that are dealt with on a daily basis in many companies. If that sounds depressing, never fear, help is on the way.

The second section of the book, "Guerilla Tactics for Front Line Programmers," examines the development process, step-by-step over the life of a project, and provides useful, practical information on how to succeed in spite of the hurdles placed in your path. The reader is guided through requirements gathering, design, estimation, development and testing with an eye toward fixing the perceptions management often has about the development process. If you can convince the people you work for that it is in their best interest to let you gather requirements, design and test, in addition to writing code, you have achieved a great deal.

The best parts of this book are the chapters "Effective Design Under Fire," and "Managing Your Management." Again, both are practical approaches to real problems. "Effective Design Under Fire" alone is worth the price of the book. This is a tremendously pragmatic approach to the problem of limited time for design. I wish every developer I knew understood the concepts here. Frankly, the approach used in the book can make you look like a guru, both to your coworkers, and to your boss. Simply put, it works. "Managing Your Management" is also very valuable, with an emphasis on learning to speak the language of the folks you work for. Sometimes a good guerilla must blend in.

The Summary Something different than the run-of-the-mill development process book, The Career Programmer: Guerilla Tactics for an Imperfect World will allow you to gain control of your software projects. It provides pragmatic, useful information that will allow you to push your organization toward successfully delivering software on time. Even junior programmers can affect the development process when they follow the guidelines in this book. Chris Duncan's humorous writing style makes this a very enjoyable read.

Table of Contents

1. Software Development in an Imperfect World
2. 1. Welcome to Corporate America
   2. Business Is War. Meet the Enemy.
   3. Good Coding Skills Are Not Enough
3. Guerilla Tactics for Front Line Programmers
4. 1. Preventing Arbitrary Deadlines
   2. Getting Your Requirements Etched in Stone
   3. Effective Design Under Fire
   4. Practical Estimating Techniques
   5. Fighting for Quality Assurance
   6. Keeping the Project Under Control
   7. Managing Your Management
   8. Corporate Self-Defense
   9. Controlling Your Destiny

You can purchase The Career Programmer: Guerilla Tactics for an Imperfect World from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Great Review

[mjmalone]

Good job, finally a good book review on slashdot that I actually read completely and enjoyed. This book seems like it would be good for a lot of slashdoters who come online and complain about corporate politics and stressful situations in the workplace. I think a lot of tech people have trouble dealing with business types who don't understand the technical difficulties they face daily. I am still in college, and I have spent this summer as an intern in an IT department and have learned a lot about corporate politics, it's a bitch. I'm buying my copy now.

Re:Great Review

[Ian Wolf]

I agree, but surely you must concede that some people just like to play the victim just a little to often. We've got one programmer here who complains about how overworked he is, while he's hanging on my cube wall, coffee in his hand jabbering for 20 minutes until he moves on to the next person in the row. He's always working weekends and late nights because he can't manage his time, but in his mind its not his fault. We have some pretty good managers who try and set reasonable deadlines, but this dolt argues over every single one, including the easily obtainable ones. He's convinced himself that he is the only reasonable person in the company and that our managers are persecuting the programmers. Granted he's the worst I've ever had to work with, but there are a couple others that can get pretty close. The majority, however are well adjusted team players.

All I was saying was that most programmers could probably benefit from this book, but some are lost causes that will never be able to get control of their environment because they can't get control of themselves.

Sounds like a great read

[TopShelf]

I think most techies would agree that the political & managerial aspects of IT/IS projects are by far the most difficult. Under the pressure that management brings to "get this up and running," it's only natural for budgets and estimates to be built around what are really best-case scenarios. The hard fight has to be taken on early, though, to make management understand that they can ask for a quick, well done, and cheap project, but they'll only get 2 out of those 3 qualities at best - they can't have it all.

A $10 million dollar project that was budgeted for $8 million is usually considered a failure - if that same project had been estimated up front at $11 million, it would be hailed as a success. And while management may balk at those estimates ("it has to come under $X"), that's when the techie has to dig in his/her heels and say that in their professional judgement that's what the cost will be and at that point whether the project is worth doing is for managment to decide.

man, i never knew that

[b17bmbr]

They pay the bills, and you work for them. Is that why they blocked /. on the firewall?

Pricing

[Mondoz]

It's more expensive at bn.com. Amazon has it for 10 bucks less.

Oxymoron

[Carbon Unit 549]

Sadly, the title of the book is becoming an oxymoron in the USA.

Re:Oxymoron

[kisrael]

Sadly, the title of the book is becoming an oxymoron in the USA.

I don't know that it is.

Surely, the offshore issue is going to be larger and larger. For large "death march" projects, the chance it's going to be outsourced. I may be optimistic here, but I think there's going continue to be room for people here doing smaller, tighter, leaner projects; ones where the 6-12 hour time difference and language/dialect issues will prove to be a big obstacle in the communication that kind of work needs.

"Don't think of it as programming. think of it as warfare." --Dmitry Orlov, 99-5-13

Chapter 10: Learning Hindi or Russian

[Hairy_Potter]

or is that in the next revision?

Re:Chapter 10: Learning Hindi or Russian

[swb]

[ considering you're an average english speaking person who is unaware that other languages, except perhaps spanish, exist, at all. ]

That's kind of a cheap shot. For most Americans, even those motivated to learn another language, there's little practical ways to get and stay proficient (ie, carry on colloquial conversations, read/write), since almost nobody speaks the 'other' languages, excluding Spanish.

In the Southwest, Spanish is probably viable, and in parts of the Northeast Quebecois might be viable. Otherwise your hundreds if not thousands of miles from any speakers of these languages, and if those languages aren't interesting to you, then GOOD LUCK finding other speakers, media in those languages and more than the occasional newspaper.

Yes, I know you could go out of your way to do this: join a language club, subscribe to a newspaper, get a shortwave radio, etc, but for the most part that's not something most people would do or it would supplant something else they already need to do (raise the kids, tend the home, etc).

Europeans can be polyglots because just about any point in Europe is a few hundred km at most from 2-3 other major population centers where those languages are spoken. Remove that, and I'd wager most of those people wouldn't bother, either, or wouldn't have gone to the extra effort.

Even where there are multiple languages *requried*, the locals aren't always hot to it. A friend grew up in South Africa in the 70s; of English extraction, he didn't want anything to do with learning Afrikaans, even though it was required, and to this day can remember/speak little of it.

Chapter 1

[riotstarter]

Step 1. College
Step 2. Job
Step 3. Realize job sucks
Step 4. Write Book
Step 5. Profit

Were those too many steps?

Re:Small companies too?

[Anonymous Coward]

Politics are universal. It's generally worse in the larger corps. but human nature is unavoidable.

In smaller companies you've got cliques that develop to deal with. If you're on the outside, you've got no place to go.

Another review and interview with the author...

[rgelb1]

Another review and interview with the author is available at

Interview with the Author
http://www.vbrad.com/pf.asp?p=Reviews/books/interv iewGuerilla.htm

Book Review
http://www.vbrad.com/pf.asp?p=Reviews/books/brCare erProgrammer.htm

Re:Small companies too?

[bmj]

Small companies have their disadvantages as well. I'm a career small company guy, but I've done consulting work for larger companies, so I've seen both sides...

It can be much harder to avoid and deal with political issues at a smaller company. If there's a good, open, honest environment, then issues are easier to deal with, but if the people there have a hard time getting on with one another, it can be really bad, as there's nowhere for you to "hide."

But, on the bright side, there's less of a chance you'll just be a code monkey at a smaller company who is constantly put on death marches with no input. But that doesn't mean that management won't be unreasonable, either. Just do your homework if you get a job offer -- really find out what type of people you'll be working with. Again, if you don't discover that another developer (or manager) at the small shop is a jerk, you're probably worse off than if it was a big place.

Re:Small companies too?

[ahodgson]

If your organization is bigger than 2 people you will encounter politics.

Fast, Cheap or Good; pick 2

[Speare]

Though I agree with the sentiment, make management understand that they can ask for a quick, well done, and cheap project, but they'll only get 2 out of those 3 qualities at best, there's often a complicating component of the developer's temperament and experience.

Many experienced developers will not accept an answer of, "Okay, I want Fast and Cheap, because I don't care about quality." They might sign on to the project expecting to blast out some code, but find it hard to cut corners on quality.

Many inexperienced developers will not accept an answer of, "Okay, I want Fast and Good, because the ultimate customer won't quibble about cost." They are probably not yet capable of developing a high quality product (above a certain complexity) without considerable care.

Many developers of any experience level have trouble delivering when offered the answer, "Okay, I want Cheap and Good, because we're not in the critical path of another schedule." Work on the project will expand to fill the time available, honing and polishing and improving. Or the project will be rushed to get it out of the way to do more interesting things with other projects.

Death match?

[Anonymous Coward]

When this book came out a year ago, I bought it, but was in the middle of massive death march. Frankly, the first three chapters depressed me! It hit a little too close to home. Of course, I wasn't sleeping either, and that turned out to be more important than reading.

I need more coffee... I read "death march" as "death match" and it still made sense, what with the "wasn't sleeping" and all..

Christopher Duncan Articles

[benjiboo]

Christopher Duncan has wrote a few articles over at CodeProject on similar topics. He's a great writer - I've been meaning to pick up a copy of this book.

Pro Developer: Creating Your Dream Project

Pro Developer: Throwing Money Out the Window

Pro Developer: Improving Your Career In Any Economy

Pro Developer: This is Business

Pro Developer: Delivering Quality Software

Re:Small companies too?

[dollar70]

Sometimes small companies are worse than larger ones when it comes to politics. Many small companies are family owned and operated. I've learned that this means that as a valued employee, you will never be considered a part of the family. It's like being the maid/butler who's always suspected to be stealing the silver when no one is looking, so they always watch you like a hawk. Living under a microscope can be hell. It's best to find medium to large companies that you can become anonymous within.

Another great alternative is to find people you get along with and form a partnership.

--
I forgot where I put my collection of tag lines...

Re:Small companies too?

[Khomar]

As a disclaimer, I have worked for very small companies (<50 employees) and a moderate sized company (300+ employees). I currently work for a company with about 40 employees. The smaller companies, I have found, are far more enjoyable to work for. You are given a lot more freedom to design and develop without getting lost in a quagmire of beauracracy and red tape. In the larger company, most of our time was spent in mettings are fighting with marketing/sales. There is much better communication in smaller companies between groups because it is actually possible to know everyone.

The advantage of big companies come in stability and security (in general). They generally offer better benefit packages (dental, medical, etc.) due to the better deals they get with insurance companies and investment firms. Smaller companies involve more risk since often times the company is not as established and therefore is more likely to fail. There is also generally a greater wealth of talent to draw from in getting help for problems you cannot solve. There will be a wider range of skills and expertise in a larger company simply because there are more employees. For example, I am basically the UNIX expert in my current company because I am the only one with any experience (not because I am anything close to a guru), so when there is a UNIX problem I do not know how to fix, I have no one in house that can help me. Thank God for the Internet!

I would highly recommend a smaller company, especially if you are single. You do not have the need for stability like a family man does. They are typically much more fun to work in, and there is a good potential to be high up in the company (one of the lead developers/management/whatever suits you) should it become successful. You also get a better feel for how the entire company operates from development to marketing to sales since you know people from every department.

Just my two cents.

Re:Small companies too?

[khendron]

By my definition, "bad office politics" occurs when you spend more of your time working to solve problems coming from inside the company than working to towards what the company actually does for its business. The problem is pretty universal. I've dealt with insane policies and nasty politics in both small and large companies.

The best place to be is a small to medium sized *growing* company. In a growing company, you get to be the one who defines the policies. Things are changing so fast that people are open to new ideas, so you generally get to do the type of work you like best.

Avoid the small company that has been around and small for years. Such companies are often run by a clique of "founders" who like things done exactly they way *they* want and will not listen to any other suggestions (even if the survival of the company is at stake). A stagnant company has the worst politics.

A lot of Programming isn't programming

[Badgerman]

I'm probably going to pick this book up because I'm not only curious as to what I'll learn, but curious as to what similar and dissimilar lessions the author and I may have had.

The hardest lesson for me was that a lot of being a Programmer (job) has NOTHING to do with being a Programmer (activity). Once you realize it and even embrace it, you can do quite well, perhaps even better than you expected. But the hard fact is that all the coding and programming ability in the world won't save you from non-programming issues.

Cuts both ways

[Anonymous Coward]

I think a lot of tech people have trouble dealing with business types who don't understand the technical difficulties they face daily.

In many companies, developers restrict themselves to the development environments only. Many have never had to support the product they develop and most have never talked to an actual customer of the product they develop. I worked for a team that rotated developers into support, sales, and put some on a real, live customer site. In the beginning, we were hated, but many developers came to appreciate what they learned and became better developers because of it. Developers seem just as unwilling to understand the business side as the business side seems unwilling to understand developers. Both camps benefit from understanding the other.

Re:Cuts both ways

[HeyLaughingBoy]

Developers seem just as unwilling to understand the business side as the business side seems unwilling to understand developers. Both camps benefit from understanding the other

Yup. I was lucky in that my first job out of school included a heavy dose of customer support, a lot of contact with "management" and even order-taking (it was a ~10 person operation). Although I absolutely hated it at the time, I now realize it made me a better developer and gave me a much wider perspective on technology business as a whole. 15 years later, at a multibillion dollar corp, part of my job is supporting internal customers and occasionally external beta test users. It's eye-opening to see how they view the machines vs. how we, the developers do. It's difficult to be a good high-level developer without a lot of domain knowledge and an understanding of how the product will be used. For low-level, bit-twiddling stuff you can just sit in a corner all day and never talk to anyone.

IMHO, the best career programmers....

[Anonymous Coward]

...realize the world doesn't begin and end with the development environment.

...are willing to actually talk to customers and realize they are the sole reason for the developer's existence.

...are willing and able to support their own products.

...have actually implemented and customized in a production environment.

...have at least one good friend in the sales and support force.

Re:Small companies too?

[gonzo_bozo]

If you are a rookie, beware of small companies. They are black holes in disguise. If possible, make sure there are a few seasoned veterans for both the technological and business aspects. Otherwise, you may learn much slower and be part of a big ugly blunder generator, which is extremely frustrating.

Re:Small companies too?

[bismarck2]

This is *very* true!

I've worked at a small company where the founders were nice likeable people at first but in hindsight after three years of working there I realized they really were very selfish and didn't want anyone to get any credit for good work or any stake in the company.

Before I left I worked three months of brutal slave-driven seven day weeks. At the time I thought I was doing some good people a favor and they had promised me advancement. After I got *huge* amounts of work done, they pulled back the advancement promises and made steady hints that I could be replaced by a cheaper candidate from the current job market. I literally would leap out of bed screaming in the middle of the night after some bad days at work. Life was really miserable.

I took another job offer from another old client. Small company (15 people) but I'm happy as could be. We're growing, there's loads of new opportunity and I'm already getting 3% of revenue on top of salary.

Of course this is all subjective, but my old boss just didn't want anyone around that was as smart as him or might want a piece of his pie. They wanted their employees as replaceable as possible; even at the expense of long term growth of the company.

You really don't want to work for someone like that.

I put this in a speech once...

[anvilmark]

I was invited, by the CS department at my alma mater, to come back and speak a year after my graduation. They wanted me to give a talk about the 'real world' to those getting ready to graduate and enter the market. I remember covering many of the topics outlined in the chapter titles of this book. I was really honest.

When I got done the students where kind of "ashen faced". Oddly, I never got invited back to speak again...

Etched in Stone

[Javagator]

I haven't read the book but I noticed one of the chapters is "Getting Your Requirements Etched in Stone". I have been adding last minute requirements to my programs my entire career. At first I thought we were doing something wrong. But after a while I realized that people are fuzzy about what they want, they communicate imperfectly, and requirements change. The more accurate your requirements, the better, but unless you are writing a compiler or something, incorrect requirements are a fact of life. If your requirements are etched in stone, you are writing shelf-ware that nobody wants.

Over time, I've learned to write more modular, object oriented code so that a change in requirements can often be dealt with in one object rather than requiring a large scale re-write. Changes in requirements doesn't bother me as much as it use to.