 |
 |
 |
 |
|||||||||||||||||
  |
|
|||||||||||||||||||
       
|
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
|
|
||||||||||||||||||
 |
| 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 [email protected]
For sponsorships or registration, please send comments/questions to liz-cfun04 (at) teratech.com