Thinking it through

In this chapter, you're going to learn about...
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 figure 2.1, are what we'll talk about in this chapter.
A decision flow that might produce smart learning choices

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. (In case you're wondering, for the past twenty five years or so, he's been practising successfully as a physician.)
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 soon enough, 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.

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.

Case study

You've all been good kids so far, perhaps I'll tell you a story to help illustrate what we've been discussing.
Kevin has been a senior developer with a small retail grocery chain for a couple of years. Until now, he's primarily been responsible for the internal inventory tracking system. But his company has now grown so large and complex that it makes sense for them to directly integrate their Linux-based inventory system with the supply chain infrastructure used by their vendors. To get that done, Kevin will need to hire a few more developers and assign them individual tasks.
We don't care about all the dirty details that Kevin will need to address to make everything work. But his desire to learn how DevOps tools might make the job more efficient and effective does interest us. Thinking it through, Kevin has three distinct motivations to explore DevOps:
At his point, Kevin made a wise choice (which I suppose you'd expect, considering that he's a fictional character created by someone as wise as your humble author). He decided to do some informal research up front to see if he could at least figure out what tools and platforms existed and which of them might work best for his needs.
Considering the dozens of options and the many learning resources available, this is no simple task. If he were really smart, I suppose he might have consulted chapter 16 from my Linux in Action.
At any rate, Kevin learned about the continuous integration and continuous deployment methodologies and the ways they can integrate deeply with Git (a tool with which he was already very familiar). He also noted that, whatever he chose, it would very likely turn out to be more than happy playing with the Linux servers the company already used.
Kevin then narrowed his platform options to Amazon's AWS Code Deploy, the Ansible orchestration tool, and simple Bash scripts. Good documentation and plenty of peer support seemed to exist for all three, and they were all "future friendly." How to choose between them?
Although what he read was promising, Kevin quickly eliminated Code Deploy simply because he knew his boss wasn't yet ready to seriously consider migrating company infrastructure to the Amazon cloud. Perhaps one day, though...
That left Ansible and Bash. Ansible had the advantage of being purpose-built for just the kind of projects the company needed done and the was choice most people would probably make. But the learning curve felt a bit steep and, in any case, Kevin isn't most people.
But there was something else that drew Kevin to Bash: Linux administration. Kevin had long been fascinated by the open source operating system's secure, stable, and accessible interface, and he'd always sought to learn whatever he could about it whenever the opportunity arose. Well, here was a prime-time opportunity just staring him in the face...and implementation would cost nothing more than time.
Add to that the chance to learn some deeper Bash scripting skills that could be useful in a thousand ways, and it sounds like a done deal. Kevin cornered his boss in between meetings and told him about his research and the possibilities it had presented. He then asked whether he might be able to use some company time to get up to speed on the relevant skills and if the company happened to already have an account with an online technology training service (like Pluralsight).
One or two green lights later, Kevin dove in. Eager to get a good start and not wanting to bog down in details that weren't immediately necessary, he fired up a virtual Linux environment using VirtualBox where he could freely experiment without worrying about breaking anything important. If something did crash, he'd simply shut down and delete the virtual machine and have another one up and running in a few seconds. Curious about how that works? Be patient. There's more coming in chapter 5.
Kevin used his virtual environments to launch test deployments and work out the configuration parameters one at a time. He would only need to worry about putting it all together and pulling the trigger on a real deployment at the very end of the process, once he'd mastered all the steps.