Make sure you've read "Code Complete".
It's long and boring, but if there's anything in there you don't know,
you're an incompetent programmer.


MAIN goal of a programmer is to get it DONE.
     if your code won't deploy and not die RIGHT NOW,
        it's broke and you had better not leave it in this state longer than
        an hour or you risk pissing off your WHOLE TEAM.
     Any teeny tweak puts the code in a BROKE state.
        Unit test MUST be complete to turn it UNbroke.
        If you think your teeny code tweak doesn't need to be tried n tested,
           well, you're flat out wrong.  Always.
           CPUs will NEVER understand your intentions and MUST be baby'd.
     If your code hasn't been regression tested, it still could be BROKE.
        But regression test (testing every dang thing)
                       typically takes a while and can't be done per code tweak.
        But MUST be done (as completely as possible) before code delivery.

THEN meet spec
     it needs to do whatever the hi prio parts of spec are
     and eventually do everything
     Make sure you HAVE a spec, that it's kept up to date, and STAYS prioritized
     Specs always change and grow constantly.
        always update the spec FIRST,
           THEN take a specs "bite"
              put in code as comments and flesh out real code
              unit test & debug,
           THEN move spec bite to release notes.
           THEN (delivery) regression test and compile final overall user docs.
        LOG IT.  see steve's did.txt, do.txt, done.txt

THEN reduce complexity
     NO warnings
     comments are REQUIRED where required
        are written for competent programmers, not brain dead users.
        must be kept SHORT and up to date
     code logic and data REDUCED to lowest terms.
        code complexity is the enemy of all.  FIGHT IT.
        If it's not stated in SIMPLEST POSSIBLE way, it's lame.
        common (dup) code MUST be modularized to common functions.
        long code MUST be broken up.
        data should be localized, hidden and reduced as much as possible.
        code too.
     easily readable source  (see column nazi)

THEN optimize ONLY where needed (that may be nowhere)
   optimizations increase complexity - BAD.
   usually cause problems when specs change.
   code should be measured and FOUND to be slow before optimizing.


TIPS----------------------------------------------------------------------------


- code is RARELY YOURS.  It's =only= yours if...
     you are working on it at home,
     have written ALL of it, and
     nobody else will EVER touch it.
  (or if you left it BROKE - then it's your's until unbroke.)

  Starting from open source?    Not yours
  Working in a team?            Not yours
  Using copyrighted libraries?  Not yours  unless you own license.


- MUST train other programmers.  Regardless of their incompetence.
  MUST have a TRAINED backup when on a team.
  MUST use source control that is BACKED UP and can be RESTORED correctly.
     or some equivalent (there are few)


- TRY to keep their cool
  as specs change and increase (over and over),
  deadlines approach and go by
  debugging is chewing on your soul
  as others in team slack off or actively work against you
  etc, etc...

  But, eh, sometimes you just gotta say WHAT THE FUCK... (and get pissed off)
  Of course, apologize and set things right later.

  Some things we tend to lose our cool over but shouldn't:
     - os, text editor, hardware preferences
     - skill level
     - personality differences
  of course, poking fun is ok, as long as it's received ok.


- be a column nazi, but don't get mad at those who ain't.
  Steve's column nazi-izations (code standards):
     3 character indent
     spaces not tabs
     comments at column 40 or further right a multiple of 5
     open { on same line as if,while,etc
     short-ish variable/class/etc names.  WELL THOUGHT OF - use a thesaurus.
     names of similar length line up nice and can doc code well.
     similar code should line up if possible.
     ( and [ always have a space in front, not after
     etc, etc, etc :/

  team code standards can mess you up - deal with it as best you can.

  when I get new code to maintain,
     I always restructure it, unit test and start from there.
     restructuring takes a while, but helps you understand the code
        (which was probably written poorly).


- make sure you know a scripting language for messing with the dang test files
  and data files you come across.
  You MUST have a preferred OS, hex editor, text editor, reporting scripts,
  database scripts,
  web page making scripts,
  sorting, summarizing scripts, etc.
  I like perl


- specialize in SOME things.  But know a little bit about EVERything.
  You can't know everything, but if you don't know everything about SOME things,
  well, you're not a competent programmer - you won't be able to get SOME thing
                                                                           DONE.
  Are you an SysAdmin guy?  Network guy?  Script guy?  C++ guy?  Java guy?
  Win32 guy?  Unix guy?  Mac guy?  Gui guy?  Database guy?  Web guy?
  maybe  tech docs guy?  analyst/design guy?  tester guy?  delivery guy?


- debugging is your LIFE.  Deal with it.  Learn to enjoy the challenge.
  You're a programmer, and programming is 90% debugging.
  Debugging time is what keeps project managers pissed at you.  Oh well.

  When you FIRST notice you're stuck, ALWAYS get a second pair of eyes.
     Your code is broke and the broke timer just started ticking.

  Ok, now an hour has gone by and you're in broke crisis mode:
     don't be in a hurry (if at all possible).
     PRINT OUT the dang code and look at EVERYthing.

     Think.  About EVERYTHING for half a day.
     Including personal problems, what you need to get at the store,
        and anything that puts your brain into a
        "must think about it" state.
     ALWAYS SLEEP on it.  (ideally)

     Then, have a walk, drink a cuppa coffee, think more.
     NOW you're ready to debug.

  This is what seperates the awesome programmers from the inept.


- learning is also your LIFE.
  You should always be reading at least one book.  A =paper= one.
     Reference manuals are bonus points.

  You should always be working with SOMEone who knows SOMEthing that you don't.
     Even incompetents like me MIGHT know a thing or two that'll help ya out.
     It could happen.


- sometimes, work sucks.  deal with it.
  One way I do is by having my OWN UNSHARED project.
  PianoCheater restores my sanity and makes me feel good regardless of the
  current crappy job I may have or rotten project I get assigned to or
  lame boss/coworker I have to deal with.


- If a judgement is made about you, and you didn't make it, it doesn't apply.
  See if there's anything useful to take away from it.
  But your job ain't you.  Your team ain't you.
     The project you're on ain't you.
     Cuz other people can/will be incompetent.  As will you from time to time.

  Every criticism of you must be filtered through what YOU think is right.
  This implies that if you feel poorly about yourself, you're WASTING your time.
  Sure, you'll feel bad about yourself from time to time.
     But just realize that that's a complete and utter WASTE of time.

  No matter the roadblocks, you are a computer programmer.
  And (in general:) a computer programmer knows better than others
                                                what is right and what is wrong.