Slashdot Mirror
The Career Programmer
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
- Software Development in an Imperfect World
- Welcome to Corporate America
- Business Is War. Meet the Enemy.
- Good Coding Skills Are Not Enough
- Guerilla Tactics for Front Line Programmers
- Preventing Arbitrary Deadlines
- Getting Your Requirements Etched in Stone
- Effective Design Under Fire
- Practical Estimating Techniques
- Fighting for Quality Assurance
- Keeping the Project Under Control
- Managing Your Management
- Corporate Self-Defense
- 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.
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.
Visualize the world of wine
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.
Stop by my site where I write about ERP systems & more
They pay the bills, and you work for them. Is that why they blocked /. on the firewall?
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Sadly, the title of the book is becoming an oxymoron in the USA.
nohup rm -rf ~/. >& zen &
or is that in the next revision?
Step 1. College
Step 2. Job
Step 3. Realize job sucks
Step 4. Write Book
Step 5. Profit
Were those too many steps?
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 is available at
v iewGuerilla.htm
e erProgrammer.htm
Interview with the Author
http://www.vbrad.com/pf.asp?p=Reviews/books/inter
Book Review
http://www.vbrad.com/pf.asp?p=Reviews/books/brCar
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..
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
Vacancy for signature. Apply 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...
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.
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
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.
Life is like a web application. Sometime you need cookies just to get by.
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.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
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.
...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.
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.