History repeats itself...

I'm finishing up my first "real" programming project for work. An integration tool to automate user account synchronization between our ticketing application and our knowledge-management app. Ok, synchronization is really too kind a word. It's a one-way create only bulk load that happens daily.

I'm very much indebted to my current reading list for actually getting this thing started. (and finished!) It's amazing how much universal truth you can find between genre's. Stuff that you weren't really looking for, it just jumps out and smacks you over the head with a wet noodle and says "Surprise!".

HeadFirst Design Patterns is just awesome. I even actually (sorta) used an Observer pattern in the app. And saw where I could have really benefited from others. (that I've only skimmed so far) One of those books that I read and went "Where were you when I took OO design in college?!!"

Coder to Developer was helpful too. Mostly for referring me back to Joel's Painless Software Schedules. And reminding me much of what I already knew from 8 years of doing QA on other people's code. (thou shalt spend time doodling a design, test often, automate, redesign. Oh, and don't worry about doing it "right", as "right" is merely a set of compromises that best fit the current circumstances..)

If You Want to Write was something I stumbled upon while surfing Presentation Zen. I laughed, I cried...it moved me.

Peopleware helped me understand just how much I really did need silence to work.

Oh, and I finally bought Zen and the Art of Motorcycle Maintenance. And restarted it. And am about...oh...1/3 of the way through. (better than the 20 pages my first attempt netted. Ah well) I'm not sure I can put my finger on what it contributed, but then it's a zen-sorta thing anyway.

Back to software. I got to experience all the joys and pains of bringing a new piece of software into the world. And (re)discovered a few things.

So without furthur fanfare:

Key Learnings
Forehead Slappers
and other Things Not To Forget

1. Don’t put business rules/logic in btn_click events
   
2. Robust logging is harder than it looks
3. Logging is important, even with a nifty IDE to help debug
4. Good OO design is hard.
5. I won’t get the design right the first time.
6. Unit testing the set/get methods of a class is the easy part
7. It’s hard to stay disciplined and write unit tests
   It’s easier to add spaghetti code than refactor.
8. It gets harder to refactor the more spaghetti you put in.
9. When the code runs red with marinara, I most need to refactor. And that’s when it’s hardest.
   
10. Faster computers really do help.
11. Dedicated QA really does rock. (especially when you don’t have it)
12. Correction: Clued-in dedicated QA.
13. Coding without source control is like driving without a seatbelt, windshield, gas gauge, and brake pedal. While drunk.
14. Prototyping with “silly little apps” to work out implementation details really is worth the time.
15. Mind-maps and general paper scribbling work really, really well for me.
16. Thou shalt be patient with thyself.
17. Don’t be afraid to refactor.
18. Balance that against “working code that’s not perfect is better than beautiful, non-working code”.
19. The app didn’t look at the end nearly what I thought it would be like.
20. Feature bubbles, bug lists, goals work well to help keep me on track. (“What did I want to work on today?”)