IMO

Two separate events precipitated this posting. The first was my older son Jonathan, who's a sophomore in high school, saying that he was interested in maybe becoming a programmer, and what courses should he be looking into. The second was Gianugo Rabellino's excellent blog entry on Holub on Patterns. The former got me thinking about how I started to grow and develop as a programmer (and developer) and the latter got me thinking about how much more I want to learn. I'm a proceduralist at heart. This is, of course, due to my start in programming. In high school and college the main language was BASIC (BASIC-Plus) with (at Hopkins) a moderate amount of C. When I graduated and started software development at NASA GSFC, the only languages at my disposal were FORTRAN and Pascal, again, very procedure oriented. The 2 were different enough that it was relatively easy to switch between the 2, without a lot of shifting of mental gears. However, around the late 1980s, the computing infrastructure at Goddard (which had been VMS on VAX) started moving towards Unix on various platforms (At Hopkins, we were all Unix on PDP-11s). When that happened, C became the language of availability. The problem for me was that I found myself not programming in C, rather I would "think" in Pascal and then "translate" to C. Needless to say, that didn't work too well, and I would make stupid mistakes; mistakes I should have known better about (pointers are a good example). Eventually, of course, I learned the skill of being able to juggle a number of languages around in my head, without conflict (well, much conflict). So my first nugget of advice to my son was to never "translate" languages. Think it, and write it natively. He's taking Spanish in school and he understood immediately what I meant. He said that when he first started as a freshman, he would think of what he wanted to say in English, and then translate it in his head to Spanish. Now, he "thinks" in Spanish. But that's only the first step. The next one is to think "design" and "algorithm" in a mental, pseudo-code sort of way, and then "map" the language you're programming in to that. You see the problem, and work the solution, without any language in mind; instead, you let it exist as itself without being tainted by a potential language. This has the further advantage of letting you pick the right language for the task at hand (if you are lucky to do so). Of course, this brings me to the Holub on Patterns book, since it appears that this book helps you further refine and develop that mental image to remove (or at least, not require) a deep procedural frame of reference, which I still have. In fact, I almost think procedural and translate to OO. Almost. But I know I could be better. Anyway, it's worth a look, and for Christmas I got a Barnes and Noble gift card, so that's what I may be using it on. I also gave my son two other pieces of advice. One was that no matter how far along you are, you can always get better. You can always tweak and fine tune the code; you can always fine tune the programmer. The other was even more basic: Learn To Type. I sure wish I had.