writing code

[Bob Dalgleish]

Most of the programs that I write are "old" - I have written them or
something like them many times.  Normally, only about 10% of a program
is new to an application.  Thus, as Marty suggests, I can block out
most of the program at the terminal in "memory dump mode".  Also, I can
test the parts that I have written because my file is on the computer
(even old programs need testing :-).  The part of the program that is
new does need to be designed, but I usually have the design blocked out
in my head before starting.  Even if I don't, clearing the "standard"
part of the program out of my head leaves room to concentrate on the
new part.

I think the process is similar to designing a mammal - the skeleton and
internal organs don't change very much, but you have to do a little
extra work to get the skin, muscalature and brains done correctly.

My most satisfying programs are written with paper and pencil.  I don't
do a lot of erasing either - a line through the offending code means
that I can go back and reuse the code if I backtrack.  Also, when too
much stuff changes or the code is just wrong, I recopy the entire block
of code by hand, implementing all of the fixes that I had been logging
mentally as I was writing.  I also keep the old pieces of paper for a
time for backtracking.  The program eventually evolves to the point
were running it is feasible and I am satisfied with it.  When I try
this approach on the computer, I have too much investment in what I
have written to change it.  This is really an odd thought - computers
should make it easier to change, not harder.  Maybe the problem is
backtracking - "undo" is chronological, I backtrack in "thought
order".

-- 
[Forgive me, Father, for I have signed ...]

Bob Dalgleish		...!alberta!sask!zaphod!bobd
			      ihnp4!
(My company has disclaimed any knowledge of me and whatever I might say)