16 Sep
2017
16 Sep
'17
1:10 a.m.
... He made the point that a good program never dies,
and many
people will read it and modify it and try to understand it, and
it's almost a professional duty to make sure that you
make this as easy as possible for them.
This is true of many good programs.
On the other hand, many programs are not good programs. And it
winds up being true of many bad programs too. :-)
Maybe a guild is a bit too stuffy, but being mentored
by someone
with their head screwed on straight, and consequently making a
point to seek out excellent examples of the programming art and
learn from them had a profound effect on my skill as a programmer
and my career.
I don't think I would have found this in a book or
long midnight
hours hacking away...
I'm not so sure: I learned some of this myself when working on my
Z80 assembler written in (some Microsoft variant of) BASIC.
Because it was such a terrible language, I had to keep a master
"notes" table giving each subroutine's line numbers, input
variables, and output variables (no call-by-anything in BASIC so I
had to stuff a register name like "BC" "DE" "HL"
"IX" "IY" into
one global variable, "GOSUB 10100", and take the result back in
more global variables).
Nonetheless, it's true that seeing / recognizing "good" vs "bad"
software is a valuable pattern matching skill. As with all such
things, the best trick I've ever discovered is not just to learn
from my own mistakes, but to learn from *other people*'s mistakes
too!
Chris