Who are you coding for?
journal.paul.querna.org
journal.paul.querna.org
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?
I code for me, later, when I'm trying to figure out what the heck I did.
I hate it when that happens. I'll read some code and think, "What idiot wrote this?" Then I svn/git blame and find out I wrote it 6 months ago.
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.
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.
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.
God, I love to program..
... 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.
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.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!Customers don't read your code.
No. But the people hired by your customers do.
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.
I love optimizing code and fixing things, front end stuff brings out the worst bouts of procrastination imaginable.