There's no question that, to be successful, web designers and developers have to continuously learn and refine their craft. The web is a very different place than it was five years ago, and what's expected of us today is different than it was then. Learning on the job is a no brainer. But what is the most effective time to learn?

I was working on a fun personal project in Rails for a few minutes before dinner last night. In the time span of about 30 minutes a bunch of concepts, conventions, and principles that are essential to understanding Rails clicked. It was a serious turning point. I've been trying to learn Rails off and on for a few years, and nothing was really sticking. At that moment I understood that in most cases, I approach my work and my learning wrong: I train while I'm running the race.

Wikipedia says this about hurdling technique: Generally, the efficient hurdler spends the minimum amount of time and energy going vertically over the hurdle, thus achieving maximum speed in the horizontal race direction.

Designers and developers should approach projects like a well-trained hurdler: thoroughly equipped for the race, able to go from start to finish with ease, prepared and anticipating the hurdles he needs to jump without slowing down.

Since forever, I have instead approached projects like this: Run as fast as you can, and when you get to a hurdle, stop to analyze it and figure out how best to jump over it. I've always thought it was a good thing to learn during a project, and I've always enjoyed accepting challenges for the sake of learning them.

I think I was horribly wrong in this approach for two reasons:

1. It's easier and faster to train/learn when you're not already out of breath. If you're trying to train in the middle of the race, you're already tired from running. When I was learning Rails last night, I wasn't in the middle of a project… it was at my leisure, in my own “gym”, and because of that my training was far more productive.
2. Anticipation alone isn't enough for accurate estimation. You can look down the track and see all the hurdles, but you're still going to make guesses at the level of effort to jump over them if you haven't already done so in the past.

Given these reasons, there emerged a few practical outcomes for work:

1. Projects are not always the right place for training. Clients need you at your peak performance to run the race without stopping.
2. Set aside dedicated training time. If you're unencumbered by deadlines, requirement documents, feedback cycles, etc., the learning process is vastly more productive.
3. To the best of your ability, only take projects where you're familiar with the hurdles. Swallow your pride. Few projects will be completely exempt from challenges, but don't take on something you have no previous experience with at all. The fun part of engaging in a challenge should be in the time you've set aside for training. Tackling a challenge unencumbered by the various aspects of a real-world project will free you up to be more creative, flexible and innovative.