|Just another Perl shrine|
In the years that I have been messing about with various languages, doing all kinds of different things in code I have noticed that a disparity exists in the world of computers.
Most of the time, when we talk of "Programmers" we mean someone who merely writes code. "Coder" seems to be the word people in our industry use more to imply someone who programs.
It has been my experience that many of the Programmers are learning the language Perl but aren't learning how to program. I recommend Learning Perl to people because it does seem to teach how to program as much as it teachs Perl.
There are some basic tools missing from people's mental toolboxes. In many cases these are the same tools that likely they failed to instill in Math classes.
Reduction, breaking a problem into components or stages, then further down to individual steps is the key one they missed. Learning how to attack a problem and what strategies let you chop it into perl-syntax sized chunks is a tricky thing. More than once I've felt the urge to ask someone what they were thinking when they approached a problem the way they did. (On both ends of the spectrum, merlyn and Anonymous Monk surprise me regularly =)
Further, multi-focus, the ability to keep the goal, the main loop of the program, the sub sections, and the individual line you are on all in your head at once seems to be a talent the best have. When coding, I often just go ahead and call sub routines I'm going to write later. I find I'm deciding what to break out into a callable or useful in multiple places routine even as I write the main body.
A final talent I've spotted in many real hackers is "phrasing". In Linguistics and Typesetting, when learning about reading behavior you find out that people read whole words as a single symbol. Fast readers read entire phrases that way. In the same way, the best coders seem to absorb sections of code at one gulp. The have gotten so used to the code that regular idioms have become simple symbols.
My worry is that we are failing to get how we derive our solutions across sometimes. That we are turning on the how to program light, but not the how to code one.
Any other "hacker" talent you've noticed? Could/should we try to teach programming as a skill of parsing a problem into language sized chunks, as well as how to code it in our favorite variety-pack-o-chunks language?
*whew* that was long =)