How to approach learning a new technology

Written by dclinton | Published 2018/02/04
Tech Story Tags: programming | linux | learning-to-code | technology | education-technology

TLDRvia the TL;DR App

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.

A decision flow that might produce smart learning choices

Identifying the problem that needs solving

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.

Squeezing the most out of your learning

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.

  • Just anticipating that you’ll enjoy the learning is important. Naturally, other factors like previous familiarity with a technology’s larger environment can make a difference. As an example, a background in Linux LXC containers will make learning Docker easier. But there’s nothing like enthusiasm to help push back the darkness. So if the only distinguishing characteristic between two options is your excitement for one of them, choose excitement every time.
  • Old is the new new. Sure, everyone loves working with cutting edge stuff. But getting up to speed quickly on your own will require documentation, and a technology that’s already been around for a while is probably going to have more wikis, guides, how-to’s, and Stack Overflow threads than something just out of the gate. Even a vendor’s official documentation tends to be a bit rough during its early stages. Getting in early to help out with bug reporting and documentation is wonderful, but if you’re looking to make a fast start, stick with a more mature product. Remember: your time is also a significant cost.
  • There’s another benefit with learning at least some mature technologies: unexpected employment opportunities. There may not be a broad and sustained market for COBOL programmers, but if there’s a company (or, more likely, government department) in your neighborhood who happens to be running legacy infrastructure whose admins recently retired, then someone with COBOL experience might just find a happy landing. that’s not to say that you should necessarily invest too much time in a technology as old as COBOL, but it does illustrate another potential benefit of working with older platforms. A little creative planning might sometimes pay off.
  • Not enough spare time to learn? Ask your boss: your company might just let you take an online course or do research on their time. Some companies actively encourage such studying, often earmarking a set percentage of your monthly work hours to learning new skills. Even better, many organizations have enterprise accounts with the more established online learning platforms — like Pluralsight.com, where my courses live — providing their employees with unlimited access to courses and other tools.
  • A good certification can make it easier to convince employers or clients that you know what you’re doing. But it could also help get you to the point where you actually do know what you’re doing. That’s because, as I often like to say, a well designed certification is it’s own reward. More often than not, carefully working through a cert’s published exam objectives will automatically connect you with the core topics you’ll need through real-world daily use of the tool, and introduce you to the features and functions you’re likely to need. Having said that, certs have historically worked best within the IT domain — for system administration, networking, and security tasks — more than for programming languages.

Staying inspired

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.

Learn it backwards

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.

Learn it in pieces

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.

Maintaining a balanced, healthy lifestyle

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).


Written by dclinton | AWS Solutions Architect and Linux server administrator. Books, courses, and other tech content.
Published by HackerNoon on 2018/02/04