The Career Programmer

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

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

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

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

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

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

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

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

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

Table of Contents

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

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

Comments

Great Review

[mjmalone]

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

Re:Great Review

[Ian Wolf]

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

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

Re:Great Review

[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 his tasks so you can continue. Don't get upset at so and so. Instead, hold a blowtorch to their ass with management's hand.

I used to try to be mr. nice guy and give them a chance. Now if they are scheduled to get something done and it isn't done, the minute it is due, it gets reported as a roadblock, and my project timeline gets extended until they get their job done. Talk about pressure! Move it to where it belongs.

save all email, CYA (including sent items) and the world will turn.

I am absolutely stress free with regards to people standing in my way now. Hold up my projects? I don't think so. If you do you are always going to burn yourself. Now my stuff always gets done on time: )

l8,
AC

Sounds like a great read

[TopShelf]

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

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

man, i never knew that

[b17bmbr]

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

Pricing

[Mondoz]

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

Oxymoron

[Carbon Unit 549]

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

Re:Oxymoron

[kisrael]

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

I don't know that it is.

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

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

Chapter 10: Learning Hindi or Russian

[Hairy_Potter]

or is that in the next revision?

Re:Chapter 10: Learning Hindi or Russian

[markom]

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

Re:Chapter 10: Learning Hindi or Russian

[swb]

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

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

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

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

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

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

Re:Chapter 10: Learning Hindi or Russian

[mfrank]

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.

Re:Chapter 10: Learning Hindi or Russian

[Jack Greenbaum]

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.

Obviously swb has never worked in Silicon Valley.

-- Jack

Small companies too?

[jonhuang]

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.

Re:Small companies too?

[Anonymous Coward]

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

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

Re:Small companies too?

[bmj]

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

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

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

Re:Small companies too?

[ahodgson]

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

Re:Small companies too?

[dollar70]

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

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

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

Re:Small companies too?

[Khomar]

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

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

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

Just my two cents.

Re:Small companies too?

[khendron]

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

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

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

Re:Small companies too?

[gonzo_bozo]

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

Re:Small companies too?

[buckeyeguy]

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.

Re:Small companies too?

[bismarck2]

This is *very* true!

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

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

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

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

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

Re:Small companies too?

[Ian Wolf]

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.

Chapter 1

[riotstarter]

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

Were those too many steps?

This is debatable

[superpulpsicle]

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.

Another review and interview with the author...

[rgelb1]

Another review and interview with the author is available at

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

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

Fast, Cheap or Good; pick 2

[Speare]

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

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

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

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

Re:Fast, Cheap or Good; pick 2

[EvilTwinSkippy]

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.

Death match?

[Anonymous Coward]

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

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

Christopher Duncan Articles

[benjiboo]

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

Pro Developer: Creating Your Dream Project

Pro Developer: Throwing Money Out the Window

Pro Developer: Improving Your Career In Any Economy

Pro Developer: This is Business

Pro Developer: Delivering Quality Software

A lot of Programming isn't programming

[Badgerman]

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

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

Cuts both ways

[Anonymous Coward]

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

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

Re:Cuts both ways

[HeyLaughingBoy]

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

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

IMHO, the best career programmers....

[Anonymous Coward]

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

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

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

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

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

I put this in a speech once...

[anvilmark]

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

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

Plenty of US programming jobs... forever....

[gatkinso]

...if you have a security clearance.

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

Re:Sounds like a rant

[LoFat ByLine]

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.

Etched in Stone

[Javagator]

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

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

Amen Brother!

[uptownguy]

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