How to be a Guru level developer. What personality traits are important.

1. How to become a Guru Coder
Michael Smith
TeraTech, Inc.
michael@teratech.com
http://www.teratech.com
301-424-3903 x110
Copyright TeraTech
1/23
www.teratech.com

2. What is a Guru Coder?
2/23
www.teratech.com

3. 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?
3/23
www.teratech.com

4. Speaker Information
Who am I?
• Michael Smith
• President of TeraTech, Inc
• MDCFUG, CFUnited, Fusebox Conf
• Articles in CFDJ, Fusion Authority
• Winner CFDJ award Best Consulting
4/23
www.teratech.com

5. Programming Experience
• 30+ years programming
• 15+ years with ColdFusion
• Also work with SQL, JavaScript,
HTML, VB, Oracle, Access
• Teach one-on-one and custom
classes
• custom development
• Fusebox and Process Methodology
5/23
www.teratech.com

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

7. What human factors does a Guru
Coder Have?
7/23
www.teratech.com

8. Guru Coder Character
• Humble
• Curious
• Honest
• Communication
• Coding conventions
• Lazy
• Thinking and Planning
8/23
www.teratech.com

9. 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
9/23
www.teratech.com

10. 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
10/23
www.teratech.com

11. 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 11/23
www.teratech.com

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

13. 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
13/23
www.teratech.com

14. 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
14/23
www.teratech.com

15. Communication skills
• WORM code, not WMRO code (spaghetti)
• Write code for humans to read, not for
computer to run
• Clear emails
• 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
15/23
www.teratech.com

16. 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
16/23
www.teratech.com

17. 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
http://www.cfug-md.org/articles.cfm#code
17/23
www.teratech.com

18. 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
18/23
www.teratech.com

19. Planning
Plan before you Code before you Debug
Think before you Document before you
Code before you Run
Test as you go
19/23
www.teratech.com

20. 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
20/23
www.teratech.com

21. 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
21/23
www.teratech.com

22. 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
22/23
www.teratech.com

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, email to self
• Take a break, take different approach
• Use multiple catches
23/23
www.teratech.com

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

25. Questions?
Ask now or
Email me at
michael@teratech.com
25/23
www.teratech.com