This article is adapted from my book, Solving for Technology: how to quickly learn valuable new skills in a madly changing technology world.
Everyone dreams, and some dreams eventually translate to plans. Once in a while, it must be said, a plan even inspires some soft stirrings of movement. But achievement? Let’s not get carried away.
Growth is hard. Nevertheless, there are things that we can control that can help the process along. You’ll always need a certain mental toughness and discipline — things I’m not sure can be taught — so that’ll be your responsibility. But there are techniques and tricks specific to technology learning for staying motivated and finding the right frame of mind. Those, as illustrated in the figure, are what we’ll talk about in this chapter.
Before plunging head first into your next learning adventure it’s worthwhile taking a moment to ask yourself a few questions. Being clear about why you’re doing something can improve the way you go about it. The idea is to design a learning plan for yourself that’s a comfortable fit both with where you are now and where you want to be in a year or two.
First off, what exactly do you hope to gain from this new technology? What’s currently missing in your career or knowledge stack that this skill will fix?
Are you a system administrator who sometimes struggles to understand the needs of the developers you serve, or a developer who sometimes wants to launch your own test environments to see how your application will actually run? Can you hear the clock ticking on your current job and you’d like to leverage your existing skills to quickly pick up new ones?
How can this kind of clarity help? Well, for one thing, it’ll certainly make it less likely that you’ll end up wasting time by investing in something that won’t end up being helpful. But the big “savings” will come from knowing how deep you should dig.
Here’s an obvious example. If you’re considering a career in Linux administration, then you should look for a curriculum covering a full range of Linux tools (like my Linux in Action book, for instance). But if you’re only interested in picking up the tools you need to safely provision and launch your web application, then you might be better off with a simple how-to guide — the kind that a web search for install web app on lamp server might uncover.
You should also try to calculate the potential payoff: if learning a particular new technology will likely get you a job with a considerably higher salary, then it might be worth spending the time and money on longer courses and even studying for certification exams. But if, on the other hand, the benefits are less dramatic, then you might want to limit the scope of your studies and pursue them in your spare time.
Perhaps most important of all, you should make sure that your new learning project is a good match for your particular strengths and background. Ambition is great, and pushing yourself out of your comfort zone can be rewarding for a thousand reasons. But if, say, the day-to-day work of a sysadmin — or of a Java developer — has never attracted you, then it’s foolish to allow an unrealistic ambition to push you into something that you’ll probably regret.
I don’t know about you, but I’ve known plenty of people whose dreams drove them to catastrophic failures. Take a cousin of mine as an example of doing it right. He really thought he’d love to be a dentist and he had the intelligence and drive to do it. But before making his final decision, he spent a week sitting in a dentist’s office and watching. At the end of the week, his mind was set: the work wasn’t for him.
Contrast my cousin with the many professionals — including a nice handful of dentists — I’ve known who chose badly and, within a few years, usually end up washing out.
Again: when everything is said and done, the plan has to fit the problem — your problem — that it’s meant to solve.
If you’ll bear with me just a bit longer, I’d like to explore a few more thoughts on choosing. We’ll get to actual study tools and best practices later in the book, but some things simply work better when they’ve been fully planned in advance - and education is one of them.
Let’s imagine that you’ve narrowed your next-tech options down to a short list of topics that nicely match your background, needs, and understanding of market trends. What kind of filters can you now apply to single out the best choice?
All things being equal, these considerations should show you that all things are not equal.
You know how it goes. A few days after starting a new learning project, you find yourself stuck in the weeds of complex syntax and confusing layers of folders and configuration files. Your exciting long-term dreams feel a long way off and your enthusiasm is beginning to fade. Well I never told you it would be easy, right? Expect tough times and plan for them.
Here are a couple of ideas you can incorporate into those plans.
Consider breaking some rules. Don’t work through all the topics and domains of your technology sequentially, moving from simple to complex and memorizing abstract details stripped of their practical context. Instead learn the details, but only as they become useful as part of practical and fun projects.
Really? Is that something you can get away with? Can you seriously avoid rote learning and memorization when trying to grasp a new technology? Aren’t there just too many fundamental details you need to know up front before you can get any real work done?
Perhaps. Unless, of course, you find a way to keep track of the details while working on practical, satisfying, and compelling tasks. As long as you end up covering all the bases, no one gets hurt.
This was the philosophy I employed while writing my Learn Amazon Web Services in a Month of Lunches and Linux in Action books with Manning. The idea was to introduce the reader to real-world projects pretty much right from the first chapter, while making sure that, by the time the book’s done, we’ve checked all the boxes. Here’s how I described it in Linux in Action:
Don’t worry, all the core skills and functionality needed through the first years of a career in Linux administration will be covered — and covered well — but only when actually needed for a practical and mission critical project. When you’re done, you’ll have learned pretty much what you would have from a traditional source, but you will also know how to complete more than a dozen major administration projects. And be comfortable tackling dozens more.
See if you can’t find a way to do that with your learning projects.
Break large projects down into smaller, logical steps. That way, even if you haven’t yet managed to produce a final working product, you’ll nevertheless be able to confidently point to the components you did complete. Having successfully worked through 80% of the task sounds and feels a whole lot better than staring at a pile of half-baked failed attempts. And it gives you a solid foundation from which you can move on to the next 20%.
A variation of this approach is to spend a few minutes/hours before starting a project taking a good bird’s-eye-view look at all the things you’re going to need to do. Pick out the low-hanging fruit — the things that you already mostly understand or for which you’ve found easy documentation — and focus on those first. If you properly document your successes the way I’ll show you in the next chapter, you can take some satisfying and effective shortcuts.
You know: eat and sleep well, exercise, get out from time to time, stay in close touch with family and friends…and call your mother. You promised you would.
This article is adapted from my book, Solving for Technology: how to quickly learn valuable new skills in a madly changing technology world (also available in an online version).
Create your free account to unlock your custom reading experience.