How to be a Guru Coder

1/23www.teratech.com

How to become a Guru Coder

Michael Smith

TeraTech, [email protected]

http://www.teratech.com

301-424-3903 x110

Copyright TeraTech


What is a Guru Coder?


Overview

• A guru coder…Writes great programs that users love to

useCode is easy to maintainWorks well in teamsHas few bugsIs good at solving problems in a simple

way

• Guru coder: born or learned?


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


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


Does character matter?

• Studies show that 85% of a programmers success is due to human factors rather than pure technical skills.


What human factors does a Guru Coder Have?


Guru Coder Character

• Humble

• Curious

• Honest

• Communication

• Coding conventions

• Lazy

• Thinking and Planning


Not as important

• Persistence – pigheaded

• Experience – is 10 years of experience or 10 x 1 year’s experience?

• Jolt programming – all nightersCode disappear can be good – chance to

rewrite

Tweaking forever for perfect code


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


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


Modularize to simplify

• Hide details – black box

• De-Couple routines

• Cohesion – do one thing well

• Test parameters as they come into each module


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


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


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 understandingGet extra information

• EQ. Listen to upsets, allow let off steam• Remember the user – actors, photo,

useability testing


Code for humans to read

• WORM code is easier to:UnderstandReviewLess errorsFaster to debugEasier to modifyFaster to develop overall

• Sets a good habit for team


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


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


Planning

Plan before you Code before you Debug

Think before you Document before you Code before you Run

Test as you go


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


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


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


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


Resources

• “Code Complete”

by Steve McConnell

• “The Mythical Man-Month”

by Frederick Brooks

• “Peopleware”

by Tom Demarco, et al


Questions?

Ask now or

Email me at

[email protected]

mailto:[email protected]

Documents

How to be a Guru Coder