[clug] July Programming SIG: the fourteen principles for new programmers

[Jack Kelly]

Paul Wayper wrote:
> 1) Don't reinvent the wheel if you can avoid it.  Try to use or contribute
> to another project rather than writing from scratch.

Related: Typing the same code twice is a warning, typing the same code 
thrice is a pretty good sign that there's something to abstract here.

> 4) Be as clear as possible as much as possible.  Use the simplest
> mechanism you can find to do the job, without being too obscure.
> Remember that the more complex your code is now, the harder it will be
> to debug later, and make it easy to read.  The extra time it takes to
> write 'username' rather than 'x' is much smaller than the time you will
> take to figure out what 'x' contains a hundred lines down.  Copy and
> paste or autocompletion is your friend.

I'd be careful saying "copy & paste is your friend" to a new coder. It's 
possible they could get the wrong idea.

> 5) Document your intentions in the code.  Document the situations that
> you've worked around in the past - to avoid repeating past mistakes
> and to explain particular lumps of hair.  Use Python's heredocs or
> your language of choice's equivalent to document the code for external
> inspections.

You mean docstrings, I think. Aren't heredocs things of the form:
cat <<EOF
foo
bar
baz
EOF
?

> 14) Beware of the old badness reinvented as the new hotness.  Shun
> sceptics who tell you that it can't be done, especially if their
> proof is dated more than two years ago.  Spot cycles in technology
> and work with them rather than against them.  Beware of listening to
> marketing and management rather than experts in forming your plans.
> Do not try to be all things to all people.

That sounds applicable to more than just programming.

I don't know if you're looking for more, but my favourite is something like:

Programming is applied laziness. If it's boring and/or repetitive, 
chances are you can make the computer do it for you. If you can't, maybe 
you need a better tool. Faced with spending an hour doing foo or 
spending a couple of hours learning how to automate foo, choose the 
latter. The time spent now will be more than saved when you run into 
foo-like problems later.

-- Jack