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.
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
Sadly, the title of the book is becoming an oxymoron in the USA.
nohup rm -rf ~/. >& zen &
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.
Trust me, non-profit making sounds reall interesting until it's you that's not making the profit.
--This isn't a man who is leaving with his head between his legs.
The smaller the company the less the politics.
In my experience small companies don't tolerate or attract politicians. There is also a much sharper focus on who is in charge.
Large companies where the right hand doesn't know who the left hand is, is where politics run rife.
If your organization is bigger than 2 people you will encounter politics.
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.
[
You could start your own company, but the "networking" thing would be important if you were to do that. Remember it's not what you know, but who you know that oftentimes matters.
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
Some of us don't live our lives based on what some organization tell us to do, and organization which has its own problems and idiosyncracies. I'd prefer to save $10, and do something useful with it, like donating to groups pushing for modernizing patent laws.
To be more concrete on the issue: The problem is not that Amazon obtained a patent to one-click shopping. The problem is with the system for granting them the patent. If I were to boycott every company that holds broad patents, I would be left with very few commercial choices. I won't boycott a company for doing everything they can legally do to gain competitive advantage, that is their responsiblity to their shareholders.
-- Fighting mediocrity one bad post at a time.
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.
I'm not a programmer (DBA) and I'm thinking I need to pick this one up. I do an OK job interfacing with managers, but I can't help but feel that there is room for improvement.
I can think of a few programmers I need to loan it to after I purchase it. Although, I doubt it will help, they seem to enjoy their life in their "Poor Persecuted Programmer" bubble.
"The words of the prophets are written on the Slashdot walls."
[ 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.
Dick. :)
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.
That's about it. Have fun.
I'd have a personalized plate on my car, but "toxic bachelor" won't fit into 7 letters.
Politics are at least very different in small companies.
Having been on both sides myself, I think the biggest problem with a small company is that if you get a bad manager, or one you can't work with, it's likely there's no one you can go to for help.
Depending on your temperament, it can be anything from difficult to impossible.
Make sure things are spelled out -- especially anything to do with compensation. If you are salaried, yet might receive OT, make sure something is written down about how OT pay is calculated. I mention this because it bit me to the tune of several thousand dollars once.
Sean.
"Fast, Cheap or Good. Choose One"
You would be amazed at the level of paranoia that can exist in some small companies. Like the above poster stated, you can't escape human nature. Granted, there are going to be a good number of small companies where the infighting, backstabbing, and empire building is small enough to not worry about, but just because a company is small does not mean it doesn't have its share of politics. At the company I work for, we have about 30 employees. About 5 of them are Machiavellian whores. We have hired and then lost (layoffs, quitting) more than 30 people in the last 3 years. It's lke a third of the company comes and goes every year. There was a time when we had more Director of XXX and Senior YYY Managers than we had developers.
Anyway, there are good companies and bad companies. At large companies there are good divisions and bad divisions. Within large divisions there are good teams and bad teams. You can have a really good group of people that work for a bad company. Do not expect that situation to last.
If you are graduating from college and haven't yet had a job, be more worried about getting your first job than whether or not that job is at a good company. Even bad companies will have some people that are good to work with (you can't avoid any part of the human nature bell curve). If you wind up in a bad company early in your career, focus on learning from those people and then about getting a new job.
Be careful not to fall for the fallacy of sunk costs. If you are in a bad company, the odds are against it ever turning around. It doesn't happen. Either accept that you work for a bad company or move on.
Creating jobs in countries where 25% of the population is starving to death is not ethical? I think you need to fine-tune your argument a little, man.
I read this a year or so ago. The book makes some good points, but the poor writing makes the book a struggle to get through (and I wouldn't consider the good points presented worth it). You'd be much better off reading Debugging the Development Process and learning more about how your bosses are looking at you.
--dan p.
I am getting my money back a year later since IT sales have gone south. I have been on the bench for 6 weeks. Best tan for and Irish/Italian American who works in IT and lives in the Northeast, I might add. :)
Despite the grim sales forecast HQ still plans to retain me based on my performance last year. Which in large part I owe to the concepts I found in the book. Previously in years past, I found my interest in the industry waning because of draconian tactics used by management. This book rejuvenated me. It gave me the mental tools to deal with the PHB's and brought me a whole great deal more understanding of my situation as a trench programmer. Can't say enough about the book and have reread parts since I first purchased.
A hand up and a foot on every chest...
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.
"The words of the prophets are written on the Slashdot walls."
Note the capital "W".
"Your bosses took risks." What a crock of Young Republican cheerleading. In every large company which I had internal exposure, what was promoted was low-risk mediocrity. No surprises, you are promoted. Surprises, good or bad, are not liked. A good surprise gets you a end-of-year plaque at the Christmas party, and a bad on gets you fired. In the end there are people who are expert at covering up, adjusting numbers, and a few smart ones who are lazy but can turn up the heat when necessity calls.
Independant work in a startup or as a consultant / contractor is the way to go. Don't get yourself into a position where one big company is more than 1/3 your work though, because then the organization poison starts doing it's work.
It is more likely that your boss will become a big advocate of Indian outsourcing. You can't change these organizations from the inside. There is a reason why you have a dumb boss; his bosses picked him. The only way to fire your boss is to quit and start your own business.
How can you possibly equate bosses and entrepreneurs? Some bosses are entrepreneurs, no doubt about it, but most bosses (especially middle management) took no more risks than anyone else; they just have the kind of education/background that tends to lead to management-type work. (eg. MBA, CA, relevant experience).
And in reality, these people are no more deserving of respect than anyone else. Some do their jobs well, lots more are merely competent, and far too many are frankly incompetent.
Incompetent people in positions of authority are not reasonable in any society, capitalist or otherwise, if for no other reason than their bad decisions will ultimately affect the stability of your income and the fullness of your head of hair. It may be politically necessary to put up with their abuse from time to time, but it is never reasonable.
Thinking of yourself as a grunt with no leverage is a cop out! You don't have to bet your house on a business deal to be capable of independent thought, and your leverage resides in your skills, your ideas, and your record of achievement.
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.
Following these suggestions should really create a great political environment to work in. It won't get you backstabbed the next time you turn around, really. Shortsighted foolishness.
woah man... I can feel the vibes coming off your text... ummm... I wouldn't hire you at this point.
You need to learn to relax(you'll have a heart-attack, no really). Stuff happens, move on. There's no need to show-up your old company, who cares, what's important is you, you, and you. Smile, there's more money out there, you'll find it. Plan it, do it.
Cheers!
(your guardian angel)