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

2/20 2 Overview What makes a smart coder? Brains or communications skills? Does commenting matter to real programmers? My Code is my Comment. What tips can you learn to become a true programming guru?

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

4/20 4 Programming Experience 22 years programming 7 years with ColdFusion 4 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

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

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

7/20 7 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 Have challenging projects Google skills

8/20 8 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

9/20 9 Communication skills WORM code, not WMRO code Write code for humans to read, not for computer to run Clear s Use the phone correct understanding Get extra information Listen to upsets, allow let off steam Remember the user – actors, photo, useability testing

10/20 10 Coding conventions Save having to think about that part of code Variable naming Database naming Correct spelling propagates Indenting Case Avoid poor constructs Scope variables, avoid public

11/20 11 Coding conventions Save having to think about that part of code Variable naming Indenting Clarifies meaning Case Avoid poor constructs

12/20 12 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 instead of reinventing the wheel Write less code – copy existing code, searchable library of code Using template, existing document Consistent look between programmers and projects

13/20 13 Prioritize Plan before you Code before you Debug Think before you Document before you Code before you Run Test as you go

14/20 14 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 Avoid tweaking for ever for perfect code

15/20 15 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 Comment to relate distant open and close tags

16/20 16 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 Comment – see below rather than break up code Don’t make code or comments horizontally, printable

17/20 17 Modularize to simplify Hide details – black box De-Couple routines Cohesion – do one thing well Test parameters

18/20 18 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

19/20 19 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

20/20 20 Debugging If you can prove your algorithm must work It is less effort 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 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

21/20 21 Resouces “Code Complete” – Steve McConnell “The Mythical Man-Month” by Frederick Brooks “Peopleware” by Tom Demarco, et al

22/20 22 Questions? me at