1/23 How to become a Guru Coder Michael Smith TeraTech, Inc x110 Copyright TeraTech 2004

2/23 What is a Guru Coder?

3/23 Overview A guru coder… Writes great programs that users love to use Code is easy to maintain Works well in teams Has few bugs Is good at solving problems in a simple way Guru coder: born or learned?

4/23 Speaker Information Who am I? Michael Smith President of TeraTech, Inc Rockville MD ttWebReportServer, CFXGraphicserver MDCFUG, CFUN-04, Fusebox Conf Articles in CFDJ, Fusion Authority Winner CFDJ award Best Consulting

5/23 Programming Experience 25 years programming 8 years with ColdFusion 5 years with Fusebox Also work with SQL, JavaScript, HTML, VB, Oracle, Access Teach one-on-one and custom classes On site and custom development Fusebox and Process Methodology

6/23 Does character matter? Studies show that 85% of a programmers success is due to human factors rather than pure technical skills.

7/23 What human factors does a Guru Coder Have?

8/23 Guru Coder Character Humble Curious Honest Communication Coding conventions Lazy Thinking and Planning

9/23 Not as important Persistence – pigheaded Experience – is 10 years of experience or 10 x 1 year’s experience? Jolt programming – all nighters Code disappear can be good – chance to rewrite Tweaking forever for perfect code

10/23 Humble My brain can’t take in the whole program at once - use coding crutches Egoless programming, Rewrite complex code Code reviews Ask for help if stuck > 15 minutes Murphy’s law Examples in comments Reference Change Tracker issue# and Desc Document algorithm used

11/23 Reduce complexity Avoid global data Short routines, few parameters Limited nesting Data driven vs complex logic Named constants – rather than magic numbers Descriptive names – variable, database, files, short, no weird characters

12/23 Modularize to simplify Hide details – black box De-Couple routines Cohesion – do one thing well Test parameters as they come into each module

13/23 Curious How can I improve? Constantly learning Experiment Problem solving and planning skills Case studies - Programming Pearls, alphablox.com, open source sourceforge.net RTFM and magazines, websites Likes challenging projects Google skills

14/23 Honesty I don’t know I was wrong Fix bugs rather than covering up Understand code before you run it True status reports – including “bad” news Stand by accurate estimates

15/23 Communication skills WORM code, not WMRO code (spaghetti) Write code for humans to read, not for computer to run Clear s Use the phone, F2F meetings correct understanding Get extra information EQ. Listen to upsets, allow let off steam Remember the user – actors, photo, useability testing

16/23 Code for humans to read WORM code is easier to: Understand Review Less errors Faster to debug Easier to modify Faster to develop overall Sets a good habit for team

17/23 Coding conventions Save having to think about that part of code Variable and database naming Indenting clarifies meaning InCONsistent Case confuses Avoid poor constructs Bad spelling propagates Scope variables, avoid public

18/23 Lazy Write smart code instead of repetition of code Write or use a tool instead of repeating steps by hand Macros in your code editor Use a pre-built tool vs reinventing the wheel Write less code – copy existing code, searchable library of code Use a template/ existing document Consistent look between programmers and projects

19/23 Planning Plan before you Code before you Debug Think before you Document before you Code before you Run Test as you go

20/23 More good habits Code and understand before running End loops before coding the “filling” Don’t go long with code “broken” Plan before coding Figure out how you will test code before coding Take a break; sleep on problems “Telephone” review of problem to a buddy Write algorithm on whiteboard – diagram

21/23 Good Commenting Comment to relate distant open and close tags Comment – “see below” rather than break up code Don’t make code or comments go off the page horizontally - printable

22/23 Defensive coding If it can go wrong it will go wrong Check parameters exist and data type Throw errors if assumptions not met Always code the ELSE part of IF

23/23 Debugging If you can prove your algorithm must work It is less effort than to Debug. Test Parameters at and beyond their limits. (Some tests must show a failure) Keep it Simple, Stupid (Kiss) If you can’t remember and/or understand what it does, how can it be maintained? Use debug mode variable to get extra info, stop page execution, save to file, to self Take a break, take different approach Use multiple catches

24/23 Resources “Code Complete” by Steve McConnell “The Mythical Man-Month” by Frederick Brooks “Peopleware” by Tom Demarco, et al

25/23 Questions? Ask now or me at