This is inspired by an article by chromatic from ages back, about your programming force multipliers. I think improving your learning is a major “force multiplier”, so this is about how to do that.

Observation 1: Most programmers are on a life-long learning mission.

Actually, all programmers are. Programming is about solving problems. You must pick up something from that.

Observation 2: Learning happens at different speeds, both between individuals and within the same individual.

One day you get the point of mod_perl and burst forward, after making CGI-scripts in the same way for three years. At the same time your colleague kept discovering new cool skills every week.

Accordingly, most programmers should be concerned not about their learning, but also their learning velocity. Your skill level is not only based on what you know, but how long it took you to learn it and how much more you can manage to squeeze in during your programmer life-span! If you’re ambitious, but your learning curve is slow or stuck, someone will put you on the sidelines. If your goal is to really understand something, you will be able to reach a deeper understanding if you can fit more learning into a short timespan.

So, this isn’t about using mind-maps, role-plays or fancy games at a training course. Rather, this is about tactics and strategies for life-long learning, or the kind of ten-year long learning it takes to create world-class expertise. I want to share something about what Psychology knows about making us learn more, faster, better and deeper – as well as some personal experiences – and hopefully get some feedback about people’s own experiences about increasing their learning rate.

So here are some points:

Avoid Arrested Development

You start a new job. You have an amazing learning curve while you pick up knowledge and skills from your new colleagues. Six months in you’ve found the comfort level at which you can do your job well. Six years later you are still at that level. Meet Arrested Development. This is why some people are Formula 1 drivers, while most people drive their car good enough to get them to work and the beach.

Getting out of arrested development might not be easy. One key is to avoid automatic behaviours. In coding, this is to be aware of your habits and trying to break them up. Starting every day with opening a secure shell to the server and starting vim? How about learning to use Padre instead? Always firing up CGI::Application for every new web application? Learn Catalyst, HTML::Mason, even Ruby on Rails.

Or push your limits. Try taking on larger responsibilities. Take on a project that is larger, more complex or more difficult than anything you’ve built before.

The problem with getting out of arrested development is that it might take unlearning of the comfort level, and actually decrease your productivity and even understanding temporarily. It’s actually quite easy to explain in a programming setting: If you’re moving on from CGI::Application to Catalyst, your first web application is going to take longer than normal to develop. But your next one might be a big step forward for both you and human-kind.

(Although probably mostly for you)

Take Risks

It is found, again and again, that taking risk is a driving force in learning. In experiments in controlled learning environments, it is regularly found that being willing to try out more, click more buttons and do individual try-and-see experimenting is clearly correlated with higher outcomes in learning. And it’s just because the risk-takers will get more learning opportunities, they will simply see more of how things work.

So make sure you have a safe testing environment, a box for experiments and wild ideas. Try to break things that work, find edge cases or do things in a new way. Have a machine you can re-install without losing your precious collection of photos. Write some crazy ideas on your blog. Try and see what happens. But most important: Create a technical environment that is conductive to risk-taking, just as much as a social environment. If your development server is a sacred cow or people are dependent upon it, set up a crash-test server.

I think a reason Test Driven Development is working is also because it forces you to think about and try out your software. Writing tests is also a great way to get to know new packages or software suites, you can take risks you would never imagine doing while developing code. This method takes two scalars? I wonder what happens if I give it a 10.000 element list of japanese characters!

And let me repeat this: Take on a project that is larger, more complex or more difficult than anything you’ve built before.

Learn the right things

Some knowledge needs pre-requisite knowledge. It’s just a fact of life. If you try to learn how to make 3d graphics, it will take you a lot longer if you don’t know vector mathematics. (And you might want to look at something other than Perl for implementation..)

It’s pretty obvious stuff.

What is less obvious is what the optimal learning direction in computer programming actually is. In Perl, is there a learning run that is better than others? A sequence of reading perldocs that is more effective than another? I can certainly imagine some bad and good places to start, but everyone can do that. What is more unclear is what happens after that start. When you’re half-good and can do what you want, but want to expand, what is the most optimal directions to follow?

I actually don’t have a good answer to that yet. My only advice would be that if the terminology is getting too tricky, it is time to go back a step. And not only to..

Learn the terminology

When you meet a new term, don’t fill in it’s meaning from the context. One of my own most immediate improvements in learning came from always immediately looking up words I don’t understand. I believe there usually is a reason I don’t know the word, and often I’ve had some surprises where my “context fill-in” actually was way off.

Also, as suggested above, it you’re missing too much terminology, it might be a hint you are in over your head and need to gain the pre-requisite knowledge.

Learn something new outside Perl

Everyone will tell you this. Stuck on Perl? Get some new vibes from Ruby. Your C-coding is getting you down, try Scala (should get you back to C soon enough). And you can go further. Adam Kennedy says he gets inspiration from places like TED conferences, New Scientist or Economist. Some people will suggest just learning anything can get you out of a rut.

However, there is a condition. If it is going to help your programming, it must involve some sort of domain-transferable skills. Not everything new you learn will necessarily do that. I’ve been doing digital photography for nearly ten years and have gotten to a decent level. It has absolutely not improved my programming in any way. It is far too domain-specific. Getting a degree in psychology, however, has plunged me forward on a lot of levels, from new learning skills to seeing new ways of solving problems and learning about how the brain does biological information processing. Studying Zen sometimes provides me with a focus that is very conductive to understanding difficult subjects. The same with learning mathematics, particularly discrete mathematics.

So consider well what you learn. Pick the right thing, and you might gain a unique perspective on programming or just sharpen your thinking. Pick the wrong thing and you are wasting good learning time on taking vacation shots.

Of course, you might want a whole and fulfilling life filled with culture and art too, but that’s not what this text is about.

Accessing other peoples experience

Talk with people, and talk with them, not to them. Unless you are Ada Lovelace or Charles Babbage and invented this stuff, learning programming involves transferring knowledge from another human’s brain into your brain (I know some of you will lament this fact). One of the most effective ways of doing this, and the one way we are the most biologically disposed to, is talking combined with listening. Reading is a hard-learnt skill that is piggy-backed on top of the visual system the last some-thousand years. Conversation, on the other hand, has a significant part of your head dedicated to it. Use that!

Study the code of excellent programmers and learn from it. Avoid the code of bad programmers, and if you have to look at it, don’t learn from it. Perl is fantastic for this. As well as being a great code repository, CPAN is also a fabulous learning resource. In addition, the core modules are often very good and thorough code that has been optimized and looked after a lot. If you bring your laptop on the train and lose the connection to the net, study a core module.

The problem of tacit knowledge. A problem of accelerating training towards an expert level is that the real expert knowledge is not the same as the knowledge written down in documentation and books. Rather, what actually sets a novice or an expert apart is unknown, or at least not explicitly known, to either. If you just squeeze 10 years worth of reading into someone in five years, they might just still be at the 5 year level in real skill, but with a lot of knowledge they don’t really know how to apply. This is related to the concept of declarative or procedural memory, or that what you read and what you do is remembered in completely different ways and places in your brain.

That, for example, is what things like the “variable roles” mentioned in a previous post try to encode. They find how experts understand and use variables, and try to teach that to beginners instead of giving them the basic intro and letting them get the experience the hard way. How do this apply in a life-long learning perspective? Study the how and what people do, not only what they say (or write). Also: Study design patterns. Don’t necessarily base your own software designs on them, but know them, as they encode expert experience that previously was tacit.

Increase your physical learnability

Up until recently, we thought you grew new neurons (brain cells) up to certain age, then it stops and from then on it went down hill. It is not the case. At least in the hippocampus, which is the center of forming new memories, neurogenesis is found to take place all through life.

But there is a condition…

It takes physical exercise, namely aerobic training – that means running, biking, rowing or anything that makes you pant and sweat for an extended period of time.

I’m sorry… but it will increase your learnability…

Furthermore, your brain needs the right chemicals to actually form new neurons. One major compound that can’t be synthesized by your body from normal foodstuffs is omega-3 fatty acids. Omega-3 is found repeatedly to increase general cognitive ability (meaning higher processing power in your head) under many conditions. And you know you want more processing power as well as increased memory. Omega-3 fatty acids can usually be bought as pure capsules, or they can be found in salmon and walnuts if you want to eat that every day.

But be careful with the portioning. Too high Omega-3 dosages can lead to thinning of the blood, and while you might want to accelerate your Perl learning until your gum bleeds, you didn’t read that here.

And the last, but not least, point, is to be well rested. The code-all-night pattern might work when you are teenager or young adult and physically don’t need as much sleep. After that, it will effectively decrease your hard-won cognitive abilities.

And more?

Believe it or not, but I would actually like to expand on most of the points above and provide some more evidence and put some numbers to the claims above. But I have to post my Perl Ironman 10-day post and that effectively limits the time.

So, please share how you learn, or your advice to increase your learning rate. I know some rather able Perl-programmers drop by here occasionally. If you managed to become a guru, please share what you have done different. Is it just a lot of years of experience? Or do you have a unique approach?