By Justin James
Friday, June 12 2009 11:22 AM
URL: http://www.zdnetasia.com/techguide/webdev/0,39044903,62054971,00.htm

In my recent post 10 tips to go from a beginner to intermediate developer, my #1 tip is to learn another language. Since I've had a lot of experience learning programming languages, I want to share what techniques have and have not worked for me.

For the record, we ran a poll in August 2008 asking how TechRepublic members learned to program. From the 4,716 readers who took the poll, 45 percent used a mix of various learning techniques; 35 percent were self taught; 20 percent learned in school; and only 1 percent were taught by a friend or family member.

Shoot from the hip
Sometimes you have no choice but to jump right in feet first into a new language with no preparation; sometimes we get so excited about a new language that we do the same thing--even when it isn't necessary.

In my experience, this is one of the worst ways to learn a language. You often end up with some bad habits that may take a long time to unlearn, and you actually spend more time learning like this than you would with a more disciplined approach.

The funny thing is the first time I tried this approach, it worked out fairly well. The HTML 2 spec had just come out, and I was learning HTML. It was a different world then; HTML could not do much, and it was fairly easy to deal with provided you had low expectations.

My next attempt with this technique did not work out as well. I was running an online store, and the software was written in Perl. I learned Perl's syntax in about 30 minutes, but it took approximately six months of intense work later on to feel like I had learned it well enough to live without having the documentation open in another window all day long. Luckily for me, I did not have to do much in the system.

This experience set the tone for years to come. I convinced myself that 30 minutes to learn syntax was "good enough", and any learning beyond that amount of time was just memorization that could be replaced by handy documentation. Later on, I discovered that what made me so successful in Perl (and unsuccessful in Java) was that I was doing enough work with it to learn the paradigm of the language--its strengths, weaknesses, etc. I made a lot of messes until I gained that kind of knowledge.

Learn with human help
I learned my first programming languages--BASIC, COBOL, Scheme, and Pascal--in high school from an instructor. We were gently eased into a language, taking baby steps and doing projects of increasing complexity, until we had enough knowledge to write a full-fledged application from top to bottom.

This was a great way to learn, particularly for the first few languages because those languages shaped my thinking for a while. Unfortunately, there are three issues with it for a working developer:

• It might take longer than you have to learn the language.
• No school or facility offers a class to teach just one programming language.
• It might be too expensive.

If you have a good instructor and a good workbook of appropriate exercises, this is the best way to learn your first few languages, but it is unrealistic to use it once your formal education is complete. (Maybe this is a possible business idea for a reader?)

Study the language before touching it
Another strategy I've used is to study a language in-depth before trying to write any code in it. You can watch online tutorials, read books, study source code, or whatever strikes your fancy, but no matter what, the learning should be at least partially structured (such as reading a quality book).

The idea is to seed your mind with a lot of ideas so that when you start to write code (while you may not consciously remember everything you learned), the concepts are kicking around deep down and helping you out.

A technique I haven't tried but I know people who have is to essentially craft your own learning program. By putting together a disciplined program for yourself instead of doing research first and then trying to write code, you can create appropriate "assignments" for yourself during natural breakpoints in your study session.

I used this technique the first time I had to learn a language on my own. It was my college summer break, and I had the good sense to contact the CS department to find out what language the Data Structures class was in instead of assuming that it was in Pascal like the previous class. The Data Structures class used C, and students were responsible for learning C on their own. I bought a book that said it would walk me through learning C (I seem to recall the phrase "24 hours" in the title), and I read it about a month before classes began.

While the language is fairly simple, C requires a ton of work to use it safely and well. I didn't touch C until the second week of class, but when I did, I understood it enough to do everything necessary. I breezed through the class and watched most of my classmates struggle; their problems weren't with the concepts taught in class but rather with trying to learn C with the "shoot from the hip" strategy.

I'm currently using this strategy to learn Ruby (I know...I've been saying this for nearly six months). I still have not touched any code, but I'm almost finished reading a book on the subject. And you know what? I feel like I already know Ruby better than C# and probably VB.NET.

My knowledge of VB.NET and C# were learned without any discipline or rigor, and there are gaps in my knowledge. I see things all of the time that have me scratching my head because I know enough to do my daily work, but my knowledge probably only entails a small subset of the languages' capabilities. I know that I am not as good in those languages as I could be because of these gaps.

Though I don't think I'll get to use Ruby any time soon for actual work (.NET implementations do not seem ready for prime time yet, and we're a VB6 and .NET shop), I'm glad for this experience. From now on, I intend to use this strategy for any new language I learn--except for something I just need to stumble through to make a few minor changes.

Justin James is an employee of Levit & James, Inc. in a multi-disciplinary role that combines programming, network management, and systems administration. He has been blogging at TechRepublic since 2005.