CFUN-04 Homepage
Central Location of ColdFusion Conference and Seminars
Home
Topics
Schedule
Sessions
Speakers
Directions
Spread The Word
Register Exhibitor Information Survey News Faq's blog Share cfun-04 photos




Professional Web Tools



















More Sponsors:












Speakers
   Charlie Arehart
   Jo Belyea-Doerrman
   Tim Buntel
   Raymond Camden
   Christian Cantrell
   Sandra Clark
   Joey Coleman
   Sean Corfield
   Robert Diamond
   Michael Dinowitz
   Steve Drucker
   David Epler
   Joseph Flanigan
   April Fleming
   Ben Forta
   Shlomy Gantz
   Mark Gorkin
   John Hamman
   Hal Helms
   Simon Horwith
   Larry Hull
   Jeff Houser
   Chafic Kazoun
   Matt Liotta
   Tom Muck
   Rey Muradaz
   Nate Nelson
   Samuel Neff
   Jeff Peters
   Bogdan Ripa
   Neil Ross
   Margarita Rozenfeld
   Stephen Shapiro
   Michael Smith
   Geoff Snowman
   Jeff Tapper
   Dave Watts


LINK TO CFUN & CFUN WILL LINK TO YOU!


Ben Forta




LouLex CFUG
Colder Fusion - Twin Cities ColdFusion User Group
SacCFUG - Sacramento, California ColdFusion Users Group
MMUG-Dublin UserGroup Meeting
 
1  |  2  |  3  | 4  | 5  | 6  | 7  | 8  | 9 | 10  | 11  | 12  | 13  | 14  | 15  | 16  | 17  | 18  | 19  | 20  | 21  | 22  | 23  | 24  | 25  | 26  |  27  | 28  | 29  | 30  | 31  | 32  | 33  | 34  | 35  | 36  | 37  | 38  | 39  | 40  | 41  | 42  | 43  | 44  | 45

Back To Interview list

Michael Smith: I am talking with myself about my talk "How to be a Guru Coder" at CFUN-04. So why does it matter to be a Guru Coder?

Michael Smith: I think that Guru Coders get the fun projects to work on, get paid more and of course are mobbed by groupies at conferences!

MS1: Well I think I could use two out of three of that. But aren't Gurus born rather than made?
[invoke copy of object MS1]

MS2: That is an interesting question and while I think many programmers have a natural ability to code it is possible to learn skills that can make a regular coder into a guru coder. And by Guru Coder I mean someone who works well in a team, writes code that is bug free, can communicate clearly with end-users and creates great software solutions.

MS1: So what kind of things can we learn to become Guru Coders?

MS2: I hear that the ability to talk with yourself is useful! But seriously there are several skills that you can learn that will make you a better coder. For example being Lazy.

MS1: Lazy? I would have thought that hard work is required!

MS2: Yes Lazy, but in a good way. Not wanting to do repetitive work and writing a program or macro to do the same thing faster. Using tools to save time. Reusing code in modules rather than cutting and pasting code to be lazy about extra maintenance work.

MS1: Ok, that makes sense now. What else is important do you think?

MS2: I think being humble matters too. For example I have learned that my brain can’t take in a whole large program at once, so I use coding crutches such as comments and modules to help me get around easier. There is also the concept of Egoless programming - that is that I am not personally attached to my code and if someone else suggests an improvement then instead of being defensive I accept the change. I think being able to put the quality of the code ahead of my own ego is a mark of a guru. At TeraTech we even do peer code reviews to improve code and reduce bugs. Keeping code simple is the key to quality in my view.

MS1: So how do you keep code simple?

MS2: Well the main way is thinking before you code. But a few other things help, such as avoiding global data because with a global variable who know where else it is modified? Also, with modules I think it helps to keep the code short and have few parameters. Better several modules that each do one job well rather than one mega module that is a jack of all trades and is a b*tch to maintain! How you name things in a program can really help - from using named constants rather than magic numbers to descriptive names for variable, databases and files. Modularizing your code helps too.

MS1: What exactly does that mean and how does it help?

MS2: Modularizing means splitting up the program into smaller pieces (or modules) that each do a little piece of the work. Each one should just do one task and be a black box - in other words the other modules (and you as the maintenance programmer) shouldn't have to know what the code inside the module looks like to be able to use it in a bug-free way. If most of the code is put into modules, it becomes very easy to get an overview of a program just by reading the modules that it calls. In ColdFusion the modules might be custom tags, or CFCs or just CFINCLUDES. Each provides a different level of black box- ness, protecting the module's code from other code in your program. For example, an include's variables can be overwritten by variables with the same name elsewhere in your program while ones in CFCs can not.

MS1: That is cool - so are there any other things I should know?

MS2: Yes I think Curiosity, Honesty, Communication, Coding conventions and Thinking and Planning are all important.

MS1: Can you tell me more?

MS2: Well I can see that you have curiosity down, but you will have to come to my session to hear the rest!

MS1: Ok, I will be there!

| Home | Topics | Speakers | Directions | Spread the Word | Register |
© Copyright TeraTech Inc 2003
405 East Gude Drive Ste 207 Rockville MD 20850
301.424.3903  Fax 301.762.8185  www.teratech.com
Please send comments/questions to michael@teratech.com
For sponsorships or registration, please send comments/questions to liz-cfun04 (at) teratech.com