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.
Coding for the customer is fine, but they don't know the difference between crap and art; as long as it runs.<p>I code for me, later, when I'm trying to figure out what the heck I did.
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?<p>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'.<p>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.<p>There are also some world reknowned writers who nobody can follow because they use complicated grammar and words (Wole Soyinka for example) ...<p>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.<p>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.<p>I also like hunting bugs and performance and refactoring non-cemented funny code more than just flipping a unit test from red to green.<p>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.<p>God, I love to program..
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:<p><i>... 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 ...</i><p>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.
Nice post, but your forgot the most important option of all: my customer.<p>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:<p><pre><code> - 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
</code></pre>
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.
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.
Myself, and very rarely for customers, usually long time friends that need helping out in stuff that I'm comfortable with (backend).<p>I love optimizing code and fixing things, front end stuff brings out the worst bouts of procrastination imaginable.
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.