

Who are you coding for? - pquerna
http://journal.paul.querna.org/articles/2010/09/24/who-are-you-writing-code-for/

======
chewbranca
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.

~~~
TheSOB88
Consulting?

~~~
chewbranca
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?

------
JoeAltmaier
Coding for the customer is fine, but they don't know the difference between
crap and art; as long as it runs.

I code for me, later, when I'm trying to figure out what the heck I did.

~~~
J3L2404
The difference between crap and art.

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.

~~~
JoeAltmaier
Hey! I've written to a deadline before; sometimes it works too. At least at
first.

------
trustfundbaby
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.

------
defdac
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.

God, I love to program..

------
jsankey
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.

------
edw519
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.

~~~
TheSOB88
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?

Customers don't read your code.

~~~
mechanical_fish
_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.

------
chegra
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.

------
mahmud
Today, I am coding for opportunity. A siren's call in my analytics report.
Market Driven Development.

------
jacquesm
Myself, and very rarely for customers, usually long time friends that need
helping out in stuff that I'm comfortable with (backend).

I love optimizing code and fixing things, front end stuff brings out the worst
bouts of procrastination imaginable.

------
sbov
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.

------
sahillavingia
I code for myself: the only customer and beta tester that will endure me.

