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 easily?and 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 Problem?A 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 problem?there 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.
Success Breeds Success
The more you succeed in learning new technology, the more likely you’ll be to succeed the next time. If you find yourself failing, take a step back and bite off a smaller chunk?or work on something else for awhile. Sometimes, after you back off from a subject for a while and then return to it, you’ll find that you’ve learned something during that hiatus. At the very least, you can approach the problem afresh.
Don’t Copy
I can’t count the number of times I’ve seen people look for code they can copy. They install some sample application, make a few changes, and feel they’ve learned something. Well, they probably have?they’ve learned how to alter an existing application. But that’s not the same thing as knowing how to write the application from scratch. Trying out and altering code samples is fine, but only if you then go back and recreate the functionality on your own. Pick something similar, but not identical to the sample. Use the sample code for reference and hints, but not as a template. You don’t really know the technology until you can write the code yourself.
Practice
This is by far the most important learning characteristic. When you finish one project, start another. It takes most people many repetitions before they truly know something. How many times have you finished an application knowing that if you could have written it again, it would be better? Well, now’s your chance. If you’re playing to learn, you’re perfectly free to start over and do it better. And you should.
Many people equate practice with repetition, but that’s incorrect. Repetition is only one aspect of practice. If repetition were the only factor, then mindless repetition would create masters. Repetition, by itself, is almost useless; to make it practice, you must combine it with analysis. When you practice, you have to watch yourself, become aware of how, what, and why you’re doing things a certain way. Practice involves a willingness to change and take chances. You can only improve if you are willing to change and know where the boundaries for failure occur. It involves self-criticism: You have to be willing to tell yourself that you’re not measuring up to your own standards. And yes, it involves repetition. You won’t attain perfection the first time, nor the tenth time, nor (usually) the hundredth time?but if you get that far, you’ll be a lot closer.
Read, Experiment, and Ask Questions
Don’t rely exclusively on your friends, peers, or instructors to give you the information you need to learn. The information you need is widely available through newsgroups, listserves, articles, and books. Keeping up often requires you to spend a little money as well as time. So what if that programming book costs $30 or $40? If it helps you learn something, it’s money well spent.
Don’t expect to get everything you need from a single source?there’s no such thing as a perfect resource. And don’t expect to understand everything you read right away. It’s easy to become intimidated because new technologies often arrive with their own unique terminology: Schema, nodes, DOM trees, streams, objects, methods, procedures, properties, classes, functions, subroutines, arrays, overloading, namespaces, polymorphism, classpath, keyframes, movies, actors, etc. Terms acquire meaning through familiarity.
Read the documentation, and don’t complain constantly about how the documentation is unreadable: It is what it is?a reference. Others learn, somehow. Figure out what they did and do that. Don’t rely exclusively on what you read either. Rely on experimentation. Try it out. See what happens. You will usually learn far more from building a test application yourself than from finding a solution in a book or newsgroup.
With that said, newsgroups are valuable tools. One of the first things you should do when approaching a new technology is to subscribe to the appropriate newsgroups and listserves and simply read them. You may not understand all, or even much, of what’s there, but you’ll remember bits and pieces of the simpler questions, and you’ll learn things to avoid.
It’s best to exhaust your own imagination before appealing to others for help, but sometimes asking a question is the right thing to do. Before you ask, search to see if your question has already been answered. As a beginner, you have a huge advantage. Any question you’re likely to have is equally likely to have been asked?and answered?many times.
At any given time, 50 percent or more of the people using a technology are beginners, so once you’ve gotten over the hump of the learning curve, don’t stop participating in newsgroups. Others will appreciate the time you spend helping them, plus, the process of answering questions and writing articles is often humbling: there’s no better way to find out how much you don’t know than to try to write it down.
Here again is the list of my picks for top technologies and the resource lists we’ve compiled on each technology. Pick one technology, one (small) problem, and start practicing today.
| ? | ?The 10 Technologies that Will Help You Stay Employed
| ||||
