Teach Yourself Programming in Ten Years

Peter Norvig, Director of Research at Google, has published a very interesting article about the huge amount of IT-related books titled something like "Teach yourself XXX in Y days". Having read my share when I was younger, so much younger than today, I really agree with him, today more than ever.

"Day" is not the correct unit of measure when you talk about mastering something - as the article quotes, researches talk about ten years of effort: that's why you must (should) have fun with programming, because it will take you a huge amount of time. To get along with Mr. Sang Shin, you need passion.

Peter proposes a recipe for programming success, and I'd like to comment about it (I'll skip the parts on which I completely agree and I don't have anything else to add).

Program. The best kind of learning is learning by doing.

I'd like to stress the "deliberate efforts to improve" part: spending ten years programming does not necessarily mean you have ten years of experience, because you could as well count each day as the first one. I know many so-called experienced professionals who are in this situation, some of them because I caught them in the act. 

About the education: it is true that with a lot of work you could skip it, but university exposes you to a wide series of subjects, many of which might not look appealing at first glance (some of them not even after many glances), but it really pays off, as many things will come out useful later or help you to lay the foudations of your future professional growth. Moreover, you get exposed to the judgment of many experts on the field, talented people who can counsel and guide you. It's not that easy when you get to your workplace, where many people only look after their own interests (hey it just so happens that not everybody works at Google!). Unluckily (or luckily, it depends...), there's no direct relation between academic achievements and salary (sigh!). 

Work on projects with other programmers.

That sounds easy. Unluckily, sometimes you just have to rely on yourself, or on a very few other people: many customers of ours have just one to three developers, one of which is tipically a "legacy programmer". But it is a great advice, and this is where external groups (e.g. JUGs or XPUGs) come in use.

Work on projects after other programmers.

Far too easy not to follow this one. Browncode represents a huge percentage of a programmer's job, so everybody should know what we're talking about. But crap is not always the best source for knowledge, so it is also important to study and try good code - there's plenty of good open source projects out there, and if you have the time getting involved in one of them you get a very good opportunity to learn a lot.

Learn at least a half dozen programming languages.

IMHO that's hardly feasible or doesn't have the right ROI, particularly in small realities such as ours. My idea is based on the fact that a language that does not need a shift of paradigm is not worth studying (as quoted in the article) and on the necessity to optimize costs and resources. How much does it take to really understand and correctly use a functional language? is it worth the effort? In my particular case it is not, at least for the time being. Should there arise a different need, things would obviously be different. So, I would translate into "have a look at not less than half a dozen programming languages, so that you can select the one that best fits your needs on a case by case basis".

Sorry really have to go... to be continued!