recently wrote an editorial
in which I listed my personal picks for the 10 most important technologies for developers to know. At the end of that editorial, I asked readers for their input: What did I miss? Where would readers place the technologies in relative importance?
I received a lot of e-mail in response to that editorial, but surprisingly few respondents wanted to debate my choices; instead, many notes simply asked 'how do I learn all those things?'.
We've decided to respond with two approaches. There's a huge amount of information available, but it's not arranged very well for learning, so Associate Editor Erin Gannon has compiled a great list of existing articles and resources, broken down by technology, and in some cases, by aptitude.
|| The 10 Technologies that Will Help You Stay Employed|
While that will direct you to some specific resources for learning, it's only part of the solution where to find learning materials, not how to absorb them. The how is more problematic. How do you acquire the energy, time, and focus necessary to learn a new technology? How can you approach the learning process so that you end up mastering the topic rather than giving up in frustration? How can you know whether the effort you put forth will be worthwhile?
Unfortunately, there's no step-by-step procedure that will let you absorb new technology easily. For that matter, there's no technique that will let you learn anything easilyand there's nothing special about learning technology that makes it different from learning other skills. For example, most adults who try to learn to play the piano fail because they want to play like Mozart. When they're unable to achieve that level relatively quickly, they get frustrated and quit. In contrast, children learn to play the piano because they have low expectations: They're happy to be able to make the sounds, and they're ecstatic when they learn something new. In other words, they succeed because of their low expectations, not in spite of them. Of course, having a parent who nags them to practice doesn't hurt either. (I doubt your mother nags you to learn new technology, though.)
But even absent that motivation, you can simplify the process of learning new technologies if you approach them the right way. So, even though I don't have the answers, I have a number of suggestions that may help.
Choose a ProblemA Small Problem
One common mistake people make when approaching a new technology is that they tend to focus on the technology itself. That's completely backward, and makes the process tedious. Instead, the first step is to pick a problem. Want to learn XML? Pick a problem that you think might require XML, and then learn enough XML to solve it. Want to learn XSLT? Think of the types of documents that you might want to transform, and then figure out how to do it. Want to learn Java? Rewrite something you've already written in another language. Want to learn SQL? Design a database, and then figure out what SQL commands you need to retrieve data and update the values.
When you select a problem first, you have a reason to learn the technology, and whatever you learn, you can apply it immediately. In contrast, if you set out to learn the technology first, you won't have any way to apply it immediately; it will seem abstract and complex, and you'll forget it very quickly. Why? Because there's no good measure of success for "learning a technology." How will you know when you've succeeded? The real goal is not to learn a technology, it's to learn how to apply a technology to solve problems.
Make sure your problem is small. When asked to choose a problem, people often immediately pick their current task at work. But that's usually far too complicated. Pick a simple problemthere are thousands to choose from. Simplicity is the key; even very simple problems can be difficult when you're completely unfamiliar with a technology.
The best problems for new technologies are usually ones you've already solved with technology you know. You want to focus on solving the problem with a specific technology, not worry about the complexities of the problem itself. So make sure your problem is both familiar to you and non-critical. When you're doing it right, it will rarely take you more than a couple of days to reach a successful conclusion. If you find your problems usually take longer than that to solve, pick simpler problems.
For each problem, your goal is to be able to reach a successful conclusion as quickly as possible so that you can focus on the next problem. Eventually, you'll be so comfortable with the tool or technology and you'll have solved so many simple problems that you'll be able to write more complex applications naturally.