Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming Books Media Businesses It's funny.  Laugh. Book Reviews IT Technology

The Career Programmer 270

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
    1. Welcome to Corporate America
    2. Business Is War. Meet the Enemy.
    3. Good Coding Skills Are Not Enough
  2. Guerilla Tactics for Front Line Programmers
    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.

This discussion has been archived. No new comments can be posted.

The Career Programmer

Comments Filter:
  • Great Review (Score:5, Interesting)

    by mjmalone ( 677326 ) * on Thursday August 07, 2003 @11:00AM (#6635579) Homepage
    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 (Score:2, Informative)

      by Anonymous Coward
      Good job, finally a good book review on slashdot that I actually read completely and enjoyed.


      Agreed. It almost sounds like joelonsoftware.com, which also makes me want to buy the book. If you can't afford the book, go read Joel Spolsky's blog.
    • Cuts both ways (Score:5, Insightful)

      by Anonymous Coward on Thursday August 07, 2003 @11:39AM (#6635921)
      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 (Score:5, Informative)

        by HeyLaughingBoy ( 182206 ) on Thursday August 07, 2003 @01:21PM (#6637159)
        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.
    • Re:Great Review (Score:3, Insightful)

      by Ian Wolf ( 171633 )
      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.
    • Re:Great Review (Score:2, Interesting)

      by 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.

      This may also be related to the fact that a lot of tech people don't understand the complications of running a business which the business types face daily.
    • Re:Great Review (Score:3, Interesting)

      by Anonymous Coward
      >>complain about corporate politics and stressful situations in the workplace.

      I have found that a lot of stress can be generated by people who don't do their job and hold up your deadline.

      Way to cope (what is making my ulcer go away):
      Control your destiny and keep your shit wired tight.

      Don't give a crap about stuff that is not under your control. When you hit a roadblock, inform your manager, and tell the project manager that you are waiting for so and so to come in at his usual 11:30 AM and get to
  • by TopShelf ( 92521 ) * on Thursday August 07, 2003 @11:03AM (#6635611) Homepage Journal
    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.
    • by Speare ( 84249 ) on Thursday August 07, 2003 @11:21AM (#6635772) Homepage Journal

      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.

      • by EvilTwinSkippy ( 112490 ) <yoda@nOSpAM.etoyoc.com> on Thursday August 07, 2003 @11:32AM (#6635866) Homepage Journal
        Hey, don't forget about plain old managerial ineptitude. Every year I tell them that I need this, this, and this to be able to do my job effectively. They say "that's nice".

        Then they run me through a gauntlet every time something breaks. I'm used to it. My assistant still takes it personally.

        But regardless of how we techies need to do X, remember that many of us are not in a position to allocate resources. We have to work with the meager scraps that management deigns to pour into our bowl.

        • Your assistant?? Oh, those meager scraps. You poor thing. Want mommy to kiss the boo-boo and make it all better?

          (BTW, if you have an assistant, someone you manage, then aren't you 'management'? Remember, when you have one finger pointing at someone, there are 4 four more pointing right back at you.)

      • by Anonymous Coward
        Right. My new motto (no joking) is:

        "Fast, Cheap or Good. Choose One"

      • I've never seen anyone ask for Fast and Good myself, but I would assume my answer would be to spend shitloads of money for commercial products/licencing, and hire the best contractors you can find.
        • You've not been involved with military weapons contractors, then. They want the most lethal, most powerful, most robust, most effective weapons possible, and they want it yesterday. If the military thinks they can get both Fast and Good, then they're very willing to dismiss Cheap.
      • 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
        • Fast+Good doesn't give you time to "hire out" to achieve the best possible good. Money may be plentiful but hiring takes time. Sure, sometimes you have the best possible people on-staff already, but that's the exception, not the rule.
      • 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.

  • by b17bmbr ( 608864 ) on Thursday August 07, 2003 @11:06AM (#6635635)
    They pay the bills, and you work for them. Is that why they blocked /. on the firewall?
  • Pricing (Score:5, Informative)

    by Mondoz ( 672060 ) on Thursday August 07, 2003 @11:07AM (#6635651)
    It's more expensive at bn.com. Amazon has it for 10 bucks less.
    • Am I the only one still boycotting [gnu.org] Amazon?

      (cue chirping crickets)
      • Yes (Score:3, Insightful)

        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 wit
        • If Amazon was wearing a white hat, they could get the patent (which they did) and then tell everyone that they won't enforce it, go ahead and make the internet better. Granting a patent for one-click shopping is stupid and broken; enforcing it strips away any veneer of "nobility" they could have had on the issue.

          Anyway, I'm sure the FSF or EFF will appreciate your check for the amount you save every time you buy from Amazon.
          • Re:Yes (Score:3, Insightful)

            by Ian Wolf ( 171633 )
            I used to boycott Amazon, until I realized how much I could save and have saved.

            BTW, I donate to the EFF and many other charitiable organizations. Even at the height of the 'One-Click' brouhaha and everyone claiming they were going to boycott Amazon, they were doing quite alright. IMHO, its better to save some money and do some real good with it then to waste it on an ineffectual boycott.
    • 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?
      • If you haven't noticed, EVERY SINGLE /. BOOK REVIEW points to bn.com. I hope that /. collects either:
        1) a goodly chunk of the difference between bn.com's prices and Amazon's in its affiliate payments,
        2) a big fat lump-sum affiliate payment for always linking to bn.com

        At least that way we could rationalize how /. could do such a disservice to their readers. bn.com is almost always WAY more expensive than Amazon. How much more does bn.com pay its affiliates than Amazon ?
    • Re:Pricing (Score:3, Informative)

      by abischof ( 255 ) *
      Or, check it out at BestBookBuys [bestwebbuys.com] (think of it as PriceGrabber/PriceWatch for books). There, you can see that Buy.com has an even better price ($21.27 shipped).
    • Even less at Overstock.com only $16.99 + $1 shipping at overstock [overstock.com]
  • Oxymoron (Score:5, Insightful)

    by Carbon Unit 549 ( 325547 ) on Thursday August 07, 2003 @11:08AM (#6635655) Homepage
    Sadly, the title of the book is becoming an oxymoron in the USA.
    • Re:Oxymoron (Score:5, Insightful)

      by kisrael ( 134664 ) on Thursday August 07, 2003 @11:22AM (#6635780) Homepage
      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
  • by Hairy_Potter ( 219096 ) on Thursday August 07, 2003 @11:08AM (#6635665) Homepage
    or is that in the next revision?
    • Like someone smart said. If someone's speaking English with an accent, be sure he knows at least one more language than you do ;-)

      [ considering you're an average english speaking person who is unaware that other languages, except perhaps spanish, exist, at all. ]
      • by swb ( 14022 ) on Thursday August 07, 2003 @11:45AM (#6635975)
        [ 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.
      • by Anonymous Coward
        I was born in the U.S., and I know Gujarati (an Indian language) in addition to English (and a bit of Spanish).

        In any case, in India, English is much more of a common language than Hindi. Only educated people know Hindi (but English is more common even for educated people), many people only know their native languages (which is not Hindi). My cousin, after going to bording school for many years, almost forgot how to speak Gujarati (the native language in Gujarat), and only knew English really well.

        There
  • Small companies too? (Score:4, Interesting)

    by jonhuang ( 598538 ) on Thursday August 07, 2003 @11:09AM (#6635667) Homepage
    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.
    • by Anonymous Coward on Thursday August 07, 2003 @11:11AM (#6635681)
      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.
    • by bmj ( 230572 ) on Thursday August 07, 2003 @11:16AM (#6635729) Homepage
      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.
    • 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.
      • 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 i
    • by ahodgson ( 74077 ) on Thursday August 07, 2003 @11:20AM (#6635769)
      If your organization is bigger than 2 people you will encounter politics.
    • 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.
      • "Me too." I've been a self-employed I.T. consultant for seven and a half years, counting a few contract gigs where I mostly acted as an employee of the agency. (That was a hassle but it sure beat not being able to get health insurance.) As a self-employed person you have to be good at picking up the phone and talking to people, checking up on all your professional contacts from time to time, finding things in common to discuss, and generally helping people understand that they can trust you with problem

    • by dollar70 ( 598384 ) on Thursday August 07, 2003 @11:24AM (#6635805) Homepage Journal
      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...

    • by Khomar ( 529552 ) on Thursday August 07, 2003 @11:27AM (#6635826) Journal

      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.

      • by gonzo_bozo ( 652898 ) on Thursday August 07, 2003 @12:12PM (#6636310)
        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.
        • by Ian Wolf ( 171633 ) on Thursday August 07, 2003 @02:55PM (#6638472) Homepage
          Mod this guy up please.

          My first job as a DBA/System Admin was for a small 12 person company and it was the worst mistake I ever made. Sufficed it to say, I messed up and missed numerous warning signs, but I was young and naive. In my first week, I learned that my manager was a complete asshole who had single handedly driven away the last three DBA/SA's. He was extremely belligerent, a micro-manager, and an egotist. In the interview he was as nice as could be. I told him I was inexperienced in a lot of the areas he needed covered, but strong in some of the others. He assured me that there would be plenty of support for me in house to call upon. There was no internal support. I was supporting stuff I had only heard about and was finding myself sinking in quicksand. The job was way over my head and this guy never missed a chance to tell me that I had better get up to speed or they would have to let me go. Over the next two months he hired 8 people and 6 people left. I ended up putting my pager on his admin's desk, telling her goodbye and good luck and walked out with another individual.

          I've always worked in small companies, and they can be very rewarding places to work for. You can really start to feel like family. You just have to be extra careful that they don't want you to wear more hats than you can handle.

          Now I work for a 90,000+ company and I can tell you its got issues, but isn't all that bad. I think anywhere from 100 to 1000 is perfect.
    • by khendron ( 225184 ) on Thursday August 07, 2003 @11:31AM (#6635855) Homepage
      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.
      • by bismarck2 ( 675710 ) on Thursday August 07, 2003 @12:32PM (#6636530)
        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.
    • Is it better in small companies? non-profits?

      I had a wonderful time working for a small university, except the work was as boring as dirt. All I was doing was report programming.

      A small software house that wasn't too real well, staying alive, but not as profitable as the owners wished it was, things weren't great. Little politics, but there was no standardization, and you end up managed by whims or the most recent trendy manager's magazine article. In 11 months we went through C, Delphi, VB, DCOM, TCP/IP
    • by jfw25 ( 618692 )
      Having worked in companies sized from 15 to 150,000: There is a lot more opportunity for "office politics" in large companies, but it can be present in small companies, too. Pathological office politics can be much more obvious in a small company due to there being less background noise to mask it.

      A brand-new startup frequently doesn't have any serious competition for resources, which removes a fertile source of office politics, but once money gets tight things can go sour quite easily. Large companies

    • Smaller companies have a different variety of politics. In a large company if everyone hates the manager and thinks the director is a complete dipshit, through skilful political maneuvering they can be dealt with. In a small company you are screwed (it depends on what your definition of small is as well, I'm talking 25 or so). I currently work in a small game studio where the management has their collective heads firmly stuffed in their asses. It's not going to get any better unless we become a bigger studi
    • I would have to add that the nature of the people you work with is somewhat dependent on the industry you are in. For example, doing tech support in a tech firm is a very different experience than supporting an advertising agency. Similarly, working in a law firm is going to be relatively stuffy and conservative compared to working in a free-wheeling fashion house.

      One of the best reasons to network with other people in your field is to get a feel for how the job is different from place to place.

      ------

    • by buckeyeguy ( 525140 ) on Thursday August 07, 2003 @12:23PM (#6636424) Homepage Journal
      Here's the working-world guide for new graduates:
      1. Rent Office Space
      2. Watch it, carefully. Laugh a lot.
      3. Watch it again, and again, until the jokes wear thin. Imagine going to work at INItech, and dreading the inevitable future of becoming a Lumbergh or one of the two Bobs, or just being laid off for no good reason.
      4. Carefully ponder the notion that it doesn't get much better than what you've just seen.

      That's about it. Have fun.

    • for an entertaining and somewhat informative (if fictional) treatment of the difference between working for a big company and a small one, read Douglas Coupland's "Microserfs".

      Of course, if you are about to graduate, I'm sure you've already read it. It's on the required reading list, isn't it?
    • by esme ( 17526 )
      The problem with smaller companies is that there is little (if any) insulation from the whims of the owners and management. In large companies, universities, etc. there are generally several layers of management, unions, contracts, committees, etc. that really constrain what your supervisor can do to you.

      Not so at a small company. I worked at a 16-person company and inherited the job of running the office server and internet gateway. The owner of the company would often come in at 5:30 on a Friday and d
  • Chapter 1 (Score:5, Funny)

    by riotstarter ( 650328 ) on Thursday August 07, 2003 @11:10AM (#6635677)
    Step 1. College
    Step 2. Job
    Step 3. Realize job sucks
    Step 4. Write Book
    Step 5. Profit

    Were those too many steps?
  • This is debatable (Score:3, Interesting)

    by superpulpsicle ( 533373 ) on Thursday August 07, 2003 @11:12AM (#6635688)
    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.
    • From my experience managing programmers: the programmers themselves are more of a limiter than either the budget or the corporate environment around them.

      Even worse than arguing with management and not getting the time necessary to write a proper spec is getting the time to write the spec and then going to the programming team, asking for an estimate, and discovering that your senior programmers (10+ years experience) are unable to gauge how long it will take them to get the programming done. What really

      • As a professional developer with YEARS of experiance, I have to say I am so bloody tired of people trying to make a [bad!] analogy between software development and building houses.

        Building a house is not a complicated undertaking. In fact, often house building is undertaken with a considerable amount of unskilled and semi skilled workers. Perhaps this is the case with some software projects as well, but asside from this, the critical difference is that pretty much anyone can see progress when a house is
        • Most programmers work in the same problem domain from year to year. The point Humphrey makes is that from one similar project to the next a programmer should get better and better at their "craft". He is teaching programming and systems development as a discipline instead of an art.

          The house building analogy works much better than you argue it does. Have you looked at a house built today compared with a house built 50 years ago? In today's world, the trades have over-rotated in the direction you indica
  • by rgelb1 ( 472797 ) on Thursday August 07, 2003 @11:14AM (#6635708) Homepage
    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 [vbrad.com]

    Book Review
    http://www.vbrad.com/pf.asp?p=Reviews/books/brCare erProgrammer.htm [vbrad.com]
  • Yeah, I was gonna say pretty much what the first poster said, but I hate "Me, too!" posts.

    So, I'm telling honestpuck, who writes some of the shittiest reviews I've ever read, to study this review. It's good, almost perfect. In fact, it would be perfect if you cut it off at the "What's in the book?" section. Well, you could leave in the Table of Contents, but that isn't necessary.

    If you're thinking of writing a review for /., or for any forum for that matter, then read this review. Study it. Learn from it.
  • by Anonymous Coward on Thursday August 07, 2003 @11:21AM (#6635777)
    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..
  • by benjiboo ( 640195 ) on Thursday August 07, 2003 @11:23AM (#6635799)
    Christopher Duncan has wrote a few articles over at CodeProject [codeproject.com] 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 [codeproject.com]

    Pro Developer: Throwing Money Out the Window [codeproject.com]

    Pro Developer: Improving Your Career In Any Economy [codeproject.com]

    Pro Developer: This is Business [codeproject.com]

    Pro Developer: Delivering Quality Software [codeproject.com]

  • 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?
    • ..if he didn't find anything wrong with the book? It just wasn't a stinker. Very few people like reviewing stinkers anyway because they're usually boring, and there are a lot of them. Really, I think that's why most of the book reviews on /. tend to be positive. Now, I do think that a professional reviewer would be obligated to review stinkers too, but these guys are volunteers.
  • by Badgerman ( 19207 ) on Thursday August 07, 2003 @11:33AM (#6635874)
    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.

    • Amen Brother! (Score:4, Interesting)

      by uptownguy ( 215934 ) <UptownGuyEmail@gmail.com> on Thursday August 07, 2003 @06:40PM (#6640681)
      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

      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 ...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...

  • by shodson ( 179450 ) on Thursday August 07, 2003 @11:40AM (#6635926) Homepage
    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

    Sheesh, somebody get this man some Prozac!

  • by Anonymous Coward on Thursday August 07, 2003 @11:54AM (#6636076)
    ...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.
  • by BillsPetMonkey ( 654200 ) on Thursday August 07, 2003 @12:18PM (#6636372)
    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 ...
  • by anvilmark ( 259376 ) on Thursday August 07, 2003 @01:00PM (#6636902)
    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...
  • by Dumas ( 2331 )
    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.
  • 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 s
  • 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.
  • Sounds like a rant by someone who moved up a corporate ladder only to hit no-man's land and spend the rest of his days stuck doing the same thing, never moving up nor down.

    In reality, there are entrepreneurs and there are grunts. If you're not in the mood to bet your shirt, put your balls on the line, cash out your life's savings on a long shot, you're a grunt and can't expect to have any leverage. Your bosses took risks. For every one there were thousands who failed and lost everything. You on the oth
    • 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 peopl
  • by MongooseCN ( 139203 ) on Thursday August 07, 2003 @01:41PM (#6637478) Homepage
    How about a chapter at the end called "Transitioning your career from Software Engineer to McDonalds Burger Flipper". I think that applies to more programmers today than any of the other chapters.
    • You don't even have the luxury of THAT option anymore. McDonalds is working on high tech stores that only require two workers, will which lead to massive layoffs in fast food.

      So people with liberal arts degrees will have literally NO job future.
  • by gatkinso ( 15975 ) on Thursday August 07, 2003 @01:50PM (#6637621)
    ...if you have a security clearance.

    There is development going on here that will never EVER be shipped overseas.

  • Etched in Stone (Score:5, Insightful)

    by Javagator ( 679604 ) on Thursday August 07, 2003 @02:57PM (#6638492)
    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.

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Working...