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'm about to graduate college, and my limited experience with offices and "networking" have convinced me it's something I really dislike. Is it better in small companies? non-profits? Or am I just being naive about human nature. Thanks.
I argue sometimes that corporations and 8 layers of politics are a bad place to design software.
But it's infeasible to get the kind of resources like a tape library, a giant SAN devices or an expensive switch in your bedroom.
At the end of the day open source programmers are happy, but they will always be limited by their own wallet.
Am I the only one still boycotting Amazon?
(cue chirping crickets)
-- http://frobnosticate.com
Someone must has a deal. The review I sent in pointed to Amazon, and it was one of the things that got "edited" before being posted. If I'm wrong, one shouldn't have to go back too far to find a review that points to Amazon for purchase info. Right?
*** Sigs are a stupid waste of bandwidth.
I'm sorry.. maybe it's just me. This reads more like an advertisement than a book review. Did the reviewer say one critical thing about the book at all?
...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.
Like "computer science" or "Microsoft Works".
...
I've been convinced for some time that the best programs are not written by career "programmers" but by people looking for innovative ways of solving problems. If you understand the problem *inside out* - and you would if you work with the problem every day - then programming a solution is a series of fairly well defined steps.
Of course, this approach won't necessarily scale up to big problems, because such non-professional programmers will have to read round the topic to optimize make their solution solve the problem efficiently - but a common-all garden problem solver can learn this skill.
My job title is "e-Commerce Analyst" but I spend a lot of my time writing programs to solve problems. My boss decided that this was preferable to the "career programmer" who might not always know the particulars of the problem but knows a great way to show a tree-view of a relational database with editable nodes
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
I call bullshit. If a company has it's headquaters in the US, pays US taxes (which are lower than alot of taxes in european countries), and sells mostly to the US market they should employee US programmers. Outsourcing to a third world country where %25 of the population starve to death is not ethical. If you want programmers from India so badly fly them over here and make them citizens so at least there tax dollars are in the US.
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...
If Mr. Gates could distribute reliable products, there'd be alot less jobs available.
-- Stephen.
Learning to cope with a manger who does not allow sufficient time for gathering requirements, design, or testing is a defensive strategy. The pro-active worker will realize that such a manager is incompetent and fire him.
Here are some strategies for firing your boss that I have seen work:
1. Undermine him. If your colleagues are all convinced your boss is incompetent then you can collectively pound on him. Petition him for more time to do your job right. If he gives in, then he is learning and maybe not so dumb after all. If he continues, then you can collectively proceed to step 2.
2. Go around him. If you can make an ally of a senior employee, such as the CTO, and convince him that your boss is incompetent then you are home free. It's just a matter of time before he is fired.
3. Smack him around. Be nice to your boss when nobody else is around. But in meetings, especially when his superiors are present, bring up a concern that your group could do much better work if a better process were in place. You are setting a trap. If your boss makes the mistake of defending the current process, you have to be ready to convince everyone in the room that the current process is amateur, foolish, and symptomatic of an incompetent manager. In order to pull this off, you will need to be much smarter than him, be able to refer to successful development projects in your other jobs, and perhaps have a few allies in the room who can do the same.
If a group of programmers succeeds in firing their boss, it is very likely that their new boss will be selected from their own ranks. This can be a positive step forward for the group. Work together to find someone who understands process and is also skilled at diplomacy.
...if you have a security clearance.
There is development going on here that will never EVER be shipped overseas.
I am very small, utmostly microscopic.
I've been working in the computer industry since 1978, which included long stints at HP and Sun in the HP-UX and Solaris Networking/Operating Systems Organizations From my perspective the scenarios that are dicussed in this thread and many others are due to both the flexibility of software development and the rigidity required to develop the desired software, resulting in a continuous conflict that few teams are ever able to resolve. The processes and practices used by most companies in silicon valley are still stuck in the 1980's. The infratructures used to support development efforts at most companies are also stuck in the 1980's. Case in point: Most popular source control tools are based on SCCS, RCS and ClearCase (think Apollo DSEE from the 80's). Most popular editors are based on Emacs, Vi. Most popular IDEs are based on Microsoft and Borland from the 1980s. Most user interfaces are based on 1970's and 1980's look and feel (think HTML forms, think Microsoft, think Apple) One other key issues I've observed in silicon valley when it comes to software development: We have architects of technology but we don't have architects of product. To test this out in your situation, try to determine who owns the software development lifecycle and who owns the product. BigusKramicus
This is a really interesting and insightful comment, but I have a few additions and points I'd like to make.
I think you make an excellent case for the first point. I think you are right on target that many an experienced developer might sign on to do a fast-cheap project but in the end be unable to sacrifice quality to do so. The temptation to do just a bit of user input checking, to make that data screen load a tad faster, would be irresistable, and would quickly add up.
I think you ultimately miss out on the second case, the fast-good scenario. Inexperienced developers would not be working on a project that had to be delivered fast and good, because the funds would be there for the best programmer with the most experience using the best tools available.
And the last case, cheap-good, I think you miss out, not because of an incorrect understanding of the developer view point as in the fast-good case. Your first exception doesn't seem to be an exception at all. On a cheap-good project, time should be taken to polish and improve, and there should be no time constraint that would halt this process before it was completed. The second exception is a case of the client going back on their word and adding "fast" to the cheap-good stipulation, which wrecks the whole equation. Or, I guess if I read the second objection another way, you are saying the developer would get bored of the project and not take the time to make it "good". That seems to be a problem of a developer's maturity level or dicipline, which is unfortunately a widespread problem.
Anyway, excellent review, and excellent comments to go with it. If only Slashdot was this interesting all of the time.
Like my comments? Try my podcast: http://www.baldmove.com
Now that I've had a bit more experience, my line more frequently goes like this:
Fast, Cheap, Good, you pick ONE then I'll pick one. And, by the way, if you leave 'Good' on the table, I'll be picking that one.
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
...things just aren't the way you'd imagined them to be you can (1) Accept and learn to enjoy the fact that you have a job where you are reasonably well paid to keep sharp at programming (or whatever your skill is) during the day and live the dream at night by working on Linux or just enjoying time with your family or (2) Recognize that this isn't a utopia and you might need to sacrifice a little to live the kind of life you want. Which means ... taking a risky cut in pay for a smaller company or even taking the plunge and starting your own, waiting tables or working at a temp service typing to pay the bills during the lean times.
...just my humble, soon to be modded down, two cents...
Amen brother! Preach on!
The thing that is really shocking me (it shouldn't, I know...) as I read these comments is how entrenched all of the coders seem to be in their prima donna mindsets. "I am a programmer, I want to be able to apply my artistic and creative flair," as if the marketing department managers don't want to push the envelope and do something really off the wall like they've seen in this month's trade journal... or the human resources people don't want to do the sort of in depth interviewing and cutting edge personality screening they read about happening at the best companies... or the accountants don't want...
You all* work for companies -- in a recessession, with global competition nipping at your heels. Companies that have clear objectives that they set. They may be "corporate". They may seem "unrealistic". They may feel impossible.
* (Except for those of you who are currently pursuring non-corporate paths... but then this thread isn't about you, is it?)
You want impossible? My city is dealing with a $40 million budget shortfall. (Hell, in California they have a $40 billion (with a b) dollar budget defecit!) They've slashed the library hours. They've stopped projects. They've cut services. They've cut the number of firefighters that we have on the streets to fewer than any other major US metro area. I don't agree with the funding cuts. I don't think the library board or fire chief agreed with having to reduce their staff to an impossibly low level. But the directive came down.
Remember, you are given a salary and health care and whatever else by company X in exchange for your performing service Y. They don't care that you secretly dream of doing something aesthetically pleasing. They want to get something out the door. They believe you can help with this so they hired you. You are part of their overall plan. If you can honestly see yourself as a visionary who can help them do something even better... something that will make their widget** an even better widget... by all means do this. Don't go "under the radar"... Don't sneak around breaking rules. Do things the right way -- and if you have to do something different, make a business case for it. Explain how this will make their widget better. Just like Rebecca from accounting or Pete from sales would do.
** Face it, what your company produces is a widget... unless you believe otherwise, but if you do, then you don't need this pep talk!
If you are working with a corporation (school/government/etc.), understand that you are one piece of a team. Non-programming things will always get in the way. That's the way it works. You don't have to work in the corporate world but that is the way it works for most of the real world. What you choose to do with that knowledge is up to you.
And if, in the end, things still don't sit right
I would have to say that explosives are the most abused technology in all of history.