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.
When midnight strolls by and I'm in the zone hacking, then I'm programming for me. When I wake up early and tired mon-fri to go program all day, then I'm programming for my family. I love what I do so I'm not complaining and I'm very thankful I am able to use programming to provide for my family, I just wish I could figure out a way to do that without sucking up all my programming energy and leaving me useless for the late night hack sessions I love so much.
Yeah I've been thinking about moving in that direction. I'm currently halfway through an 18 month contract, so its going to be some time before I'll be able to change some things up.
I'm not entirely sure how to break into the consulting market, I've been doing misc contract jobs for several years now. Any recommendations on how to migrate to consulting?
A crap finish product runs like crap because it IS crap. A good finish product fools the user into thinking that the finish product is simple but on examination reveals the purposeful intent of the builder.
I found the writer's comparison of programming to art a bit offbase. I think I'd compares better with writing.
You know ... things like copy writing, elaborate works of fictio, essays?
While the particular thing you're working on (thesis, class essay, fiction, biography) might restrict your ability to be more expressive with your writing. There are some people that can just 'write'.
Doesn't matter what they're writing about, you can read their stuff and enjoy it, largely because they keep things simple, don't use big words unnecessarily or deploy obscure grammatical devices, and focus on getting their point across to you.
There are also some world reknowned writers who nobody can follow because they use complicated grammar and words (Wole Soyinka for example) ...
What I am (clumsily) trying to say is, by making that comparison (of programmers to writers) it becomes clearer that separating good programmers from bad ones might not be as hard as he makes it out to be.
I have the philosophy that "I am what I create". To me programming is art and the possibility for me to express myself. I also like reading other peoples code, not only to learn more - following other peoples line of thinking is awesome and a great inspiration.
Seeing the end result done by some really wierd, and perhaps even buggy, code is much more inspiring than seeing endless green unit test of perfect, sterile and vast plains of code written by the book.
I also like hunting bugs and performance and refactoring non-cemented funny code more than just flipping a unit test from red to green.
But the killer is seeing code implementing solutions to mathematical, biological and physical problems and how lines of code can tie them together into a beautiful whole.
I like what the author has to say about commenting, as a counter-point to those that think comments are a sign of bad code:
... I think by focusing on this communication, the code becomes inhertitly (sic) better, because you think more deeply about the abstractions and layering you are doing ...
Explaining a problem (or solution) definitely helps me understand it better (or even realise that I don't fully understand it). Interestingly, you might find that the act of commenting refines your code to the point where some or all of the commentary becomes unnecessary - it's served its purpose. So sometimes the feedback loop might have a few iterations to get to the most clear and concise form of code + commentary.
Love it. This is the same thing I was thinking, but I had only gotten around to thinking that the major reason for bad programming was deadlines.
I think programmers should focus on the long term, good serves you decades, bad code is one time use.
Ignore the extra 20% time it takes to get right.
I find myself coding for deadlines or myself all too often, which is why I would like to start open sourcing some of my projects - even if no-one uses them, it will keep me honest.
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.