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

[Paul Wayper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

Jeff B, Jason Neilsen and I got together on a cold, windy Thursday and sat on
the couch in the (now bare) training room and talked.  Jason's great idea from
a couple of days before that was trying to answer the question "what would we
like new programmers to learn; what would we like to pass on to people
journeying down this path?"  Here are our thoughts:

The CLUG PSIG's principles for new programmers to learn:

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

2) If you do have to write from scratch, try to think of the large cases.
The more you build in limitations, the more you will inevitably have to
remove them later.  Your choices in the future will be harder than they
are now.

3) Write things to be modular.  Make them behave well.  Be liberal in
what you accept, and strict in what you output.  Use standards where
possible - after all, there are so many to choose from.

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.

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.

6) Test your program.  Validate its inputs and outputs.  Uses testing
suites where possible.  This may be the only way you find out about
regressions or security problems before your users criticise you for
them.

7) Premature optimisation is the bane of performance, unless you have
experience with writing exactly that kind of code before.  Learn to
use your available profiling tools, and avoid spending time optimising
if there's no reason for doing so.  Work of empirical evidence rather
than guesswork.

8) Security should be designed in.  Be paranoid about what your users
might feed you.  This works in with 3, but beware of breaking rule 4
in a mistaken attempt at 'security through obscurity'.

9) Watch the experts.  Learn from other people's mistakes to prevent
your own.  Find out what sets of tools other people use and familiarise
yourself with them.  Read other people's code.  If possible, find a
mentor.  Read outside your area.  Learn another programming language.

10) Program the first one to be thrown away, because you will anyway.
This works with 2 because you will learn more about what your program
needs to do by writing it than in theorising, and you want to produce
code not theorise.  You may find it easier to not tell your
management about the first one in case they want to keep it.

11) If you think you can build a better wheel, don't let others stop
you.  Not only will your name be on it but it'll be started (as
opposed to being vapourware).

12) Keep a track of your good ideas.  Write things up.  Don't let a
good idea go to waste.  Contribute to other people's ideas.  Open
Source your thoughts!

13) The sign of a good project is one that continually suggests new
ideas and new things to implement.  Each part should be small enough
to implement and see completed, and should be well defined rather
than untestable or unbounded.  Its requirements should be clear and
concise.  You should be regularly feeling the pleasure of completing
something yet still have things to do.

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.

We hope this is interesting for some of you here.

Have fun,

Jeff, Jason and Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkh8liwACgkQu7W0U8VsXYJGwQCcDGDWTh2LFDHbfc3o6OUiEOQ+
UwgAn3nck/KpnkRR4Z7ZtNURoDsiDeau
=BgGx
-----END PGP SIGNATURE-----