Programming Techniques (that you won't find in textbooks)
By the Silver Ghost

CAUSE FOR CELEBRATION:  Thieve's World FIDO is back up! (cavort cavort cavort)
616/344\2718 @ 3:1200, 24 hours, a haven for hackers and many other minorities

   Perusing many modern-day textbooks, you'll find advice for the programmer
along the lines of "always follow the One-Entrance, One-Exit rule for
subroutines," and "write clear, commented code."  As a graduate of a few
classes that have used these textbooks, I'd like to point out several pieces
of information, show some handy tidbits, and debunk some myths.

Information
-----------
   * Nine out of ten graduates of "structured programming" classes go back to
writing any old way after they're out of the class.
   * Eight out of ten professors do, too.
   * Every programmer has a point of complexity.  Beyond this point, the pro-
grammer will be unable to efficiently debug an unstructured program.
     - Structured programs have this point, too.  But it's a lot higher.
     - For some people, this point is incredibly high in the first place.
     - Ergo: for some people, and for most purposes, structure is unnecessary.
     - Few people can take a six-month vacation and expect to find the point
       unchanged.
   * If you're sceptical, try writing only structured programs for a month,
and then try writing only unstructured programs for a month.  (Make sure no
programs overlap.)  Compare months as to (A) enjoyment, and (B) efficiency.
   * Programmers have emotions too.  If you get pissed at the computer and find
yourself punching inanimate objects (or worse, animate objects), take a break.
   * Some techniques are like knowing Geometry--they may seem worthless, but
they're nice to know, and you never know when you may need them.
   * For relatively unimportant applications (mailing label programs etc.), the
capabilities of the machine may actually matter less than your appreciation of
it.  If an Amiga's graphics aren't really necessary, and if you feel more
comfortable on an Apple, by all means write it on the Apple.
   * Grammar and spelling mistakes don't impress prospective employers.
   * If you have eliminated the impossible, what remains, however improbable,
must be true.  But usually you've overlooked something.
   * Gremlins exist.

Tidbits
-------
   * Keep a pack of dental floss near the computer.
   * If you chew your fingernails, coat them in vinegar and let dry.
   * True Hacking Enjoyment comes from deftly solving a tight problem. However,
you will frequently be in search of a paycheck, in which case T.H.E. can be
ignored.  Therefore:
     - Fix bugs on hunches...you're good enough to guess at what's going wrong,
so guess.  Play hunches until you're stuck, then get methodical.
     - It may be faster to start over.
     - When looking for specific combinations: it is a helluvalot faster (in
programming time) to generate random combinations and throw the bad out than to
write code that only generates the right combinations.
     - If the program doesn't run in real time, don't bother optimizing code for
speed if it isn't repeated more than 10,000 times.
     - If you're the only one reading your code, fuck beauty.
   * Don't keep a record-book of techniques you want to learn.  If they're
important enough, you'll learn them on your own.  If they're hard, use them
until they're almost commonplace.
   * Always make room for an hour's worth of equipment failure at the most
inopportune time.
   * Hacking is personal and spur-of-the-moment.  You can't do any serious
hacking in an hour when you're at a friend's house.
   * Find background music that requires little thought, Muzak or country or
something.
   * Wear comfy clothes--no shoes, short sleeves.  Make sure you're warm.
   * Make backups frequently.  Switch between using the backup and the original.
   * Find someone who knows more than you.  Call that person when you're stuck.

Myths
-----
   * Whoever writes a book obviously knows more than you do.
   * All PASCAL programmers are the same; thus, they should all use the same
PASCAL textbook.
   * You should memorize the basics of a language before you get to the fun
parts.
   * Certain languages you should never use (BASIC, f'r instance).
   * It doesn't matter what you're writing, you should get in the habit of
writing structured programs.
   * You don't need to learn how to structure programs; good hackers can always
get along without structure.
   * You can be a specialist without having a general education.

 -:-