Nice post, but your forgot the most important option of all: my customer.
My customers do great things. They often need my software, built and functioning properly for years to do these things. I love building stuff, but they are the real heroes. Just some of the things that they do:
- get the right drugs get to the right people
- get the ambulance to the right address
- get the right materials purchased and delivered
- get the right product built, on time and budget
- get the right product shipped accurately and on time
- make sure the parts going into that airplane are certified
- make sure your insurance claim gets processed properly
- make sure they make enough $, so they can keep doing it
I can go on and on, but you kinda get the idea. I love to learn, to optimize and refactor, and to build beautiful things. But what I do pales in comparison to what they need to do. I never forget that.
Don't get me wrong, customers are of paramount importance to every business; And in the startup / small business world, the programer is often directly building things for them, but that is not the role of a programer, and that is what I chose to focus on in this specific blog post.
The roles you describe are more often associated with Product and Program management; They are important, and in a startup, even where I work at Cloudkick, the roles all bleed together, but they are fundamentally different.
I'll close the comment with a quote from Office Space:
I'm a people person. I deal with the
customers so the engineers don't have
to. Don't you get that? What the hell
is wrong with you people!
I don't think this is quite what the author was getting at. It's kind of a separate issue. Obviously all code is written for some end-user in the end, but this piece was about how the code is written, not what it does. When he says "who are you writing code for?", he means, who is going to read it?
And your customers are keenly aware of that, because when you're gone from the scene they are either going to have to:
A) hire someone who can read your code, or
B) hire someone to rewrite it all from scratch.
They probably don't really know how to solve problem A, and they almost certainly can't afford to solve problem B even if they knew how, which they probably don't.
This is a vitally important consideration. It doesn't matter how elegant your code is if your customer can't figure out how to hire anyone to read it. If you solve your customer's entire problem in one super-elegant line of lets-call-it-Haskell, but your successor doesn't know Haskell and cannot maintain that line, he will recommend replacing your solution with a Blub app. Then your customer will tell all his friends that (a) "Haskell sucks because it is nonstandard" and (b) "Blub is the greatest language in the world because there are lots of certified Blub programmers around".
This is why it takes so much time and energy to get new platforms off the ground.
My customers do great things. They often need my software, built and functioning properly for years to do these things. I love building stuff, but they are the real heroes. Just some of the things that they do:
I can go on and on, but you kinda get the idea. I love to learn, to optimize and refactor, and to build beautiful things. But what I do pales in comparison to what they need to do. I never forget that.