30 May 2007

Choices, choices

I've been thinking about the choices programmers have to make eventually. I guess this assumes that you're somewhat talented, ambitious, and thoughtful, because I'm sure a lot of coders can just sit happily at a desk and not ask themselves this. Also, it's just one way to divvy up the options, there are probably better ways.

I don't feel like writing pros and cons, so I'll just give cons and you can use your imagination.

Product company or Consulting?



Product company


You will have to work on the same thing for a long time. At first, when the product is under development, there are a lot of cool things to try and big decisions to make. But then it gets boring, you have production support to do, and some of those decisions turn out to have been wrong and can't be easily corrected. The bottom line for the business at this point depends more on sales of the existing products, so the emphasis on cool technologies is diminished.

Because you're supporting existing code, it's hard to find a chance to learn new stuff. Maybe you can deceive your manager into using the stuff you want to learn about, under the guise that the system needs to be re-written and this technology will save a lot of money or fix a lot of problems.


Consulting


You'll have to work with "non-ideal" client's employees. If the client hired a lot of really smart developers, they wouldn't need the consultants. Or maybe the really smart developers know to stay away from working there, so they need to pay the people who are willing to work anywhere as long as it's only for a year or less at a time. This makes it harder to be challenged by your peers to improve - if you're spending most of your time working with people who are not smart, you tend to go down to their level instead.

You're pretty much guaranteed to work on junky code. Again, if they had to hire consultants, they need your help to solve the challenging problems. It's probably not an interesting new business idea being implemented, more likely it's a self-created problem with their monster spaghetti codebase and vendor-provided toolset.

You have to give up some of your ideals about the quality tools/platforms you prefer. If your company gets a .NET contract, and your client insists you use Windows, then guess what? You're going to use a closed platform with second-rate versions of your favorite tools (if there is an 'N*' of your tool) and you're not going to use your Mac even though it's your more productive environment without a pile of bugs. And if the client is using the Oracle J2EE app server, then you're going to be decompiling it. This is a tough one, since a good developer stays agnostic about the tools and platform - but sometimes you have that ideal for a reason.

Many people don't want you there. Sometimes this includes your client-side supervisor, who was told to bring in consultants by their boss but thinks they could handle it fine on their own. If you produce a report that supports their pre-conceived ideas, then maybe they'll be excited about having you there, but more likely you'll be creating work for them and telling them things they don't want to hear. And of course the client's employees are mistrustful and think you'll make them look bad. And they probably value job security more than you do.

Keep coding or move to management?



Keep coding


You may get stuck as a "line programmer". This is like modern factory work. Your job is outsourcable or offshorable because there's a heavy reliance on "requirements" as an excuse to do waterfall, so the programmer doesn't have an interactive role and anyone can do it. This happens because many people think programming is typing and will never understand the art of it.

There are few places where you can move up the pay grades as a programmer. The Java Posse did a listener feedback question on this once, and said if your company doesn't promote really good developers as highly as managers, then you should move to another company. Problem is, Sun, Apple, and Google are mostly doing this work in the Bay area so that leaves a lot of people out. I'm still hoping there are more places like this.

Also, you may not get a chance to be a leader or promote your ideas. Developers don't have much decision-making power.

Management


You will probably become a bullshitter. Since you are disconnected from coding, you won't know exactly how the software behaves in a corner case, or how difficult a feature would be. So you make stuff up and make educated guesses that become random guesses over time.

You'll have to give up the dream of being the next Gavin King or Craig McClanahan or other coder hero. Instead, you will be driven to improve non-programming skills like corporate finance and negotiating.

The business environment is cutthroat, which doesn't match well with hacker ethics.

Worst, you won't do what you love, you will write proposals and performance reviews and project plans and push tickets and schedule releases instead.

Use left-side or right-side of your brain?



Right-brained - the Artist


It's hard to find a paying gig where you can invent the next great thing (or be a part of it), so you have to do one-off contracts and either manage a lot of business stuff yourself, or be a starving artist type. Until you get your job at Apple, where I think most of the programmers are the artist type.

It's not clear how to pursue an artist/hacker ethic. You can work on your brilliant idea at home, but where are the interviews for this sort of work? Perhaps there are not many openings and a lot of applicants, like aspiring to get in the NBA.

You have to gain true respect of your peers, for example, become open source committer on a well-known project. The artist rejects unearned corporate rank and title, especially when bestowed by someone who doesn't recognize quality.

Left-brained - the Analyst


You won't "save the world" - you will create predictable products that mimic others.

There may be pressure to create average-quality products, since there is no business need to exceed customer expectations, especially if it makes development more expensive.

No comments: