In the content I create, I primarily teach things (with the occasional rant), but in this post I'm going to be covering something that hopefully will help you teach yourself: my process for learning things. Specifically, how I learn new technologies such as programming languages, frameworks, cloud infrastructure, and so on. And yes, there is a systematic approach to all of it.

Now before you gloss over, I do want to explain that this is not some hodgepodge process that I came up with by chance. One of the ways that I paid for my grossly under-utilized Economics education in college was by tutoring all levels of Economics courses. And by tutoring, I mean I was a nationally-certified master tutor. Part of this was helping teach others how to learn, not just the subject itself. This meant discovering their learning style, adapting to it, and of course, not losing patience.

In doing so, I also learned about my own optimal learning style. I found that I was a heavy auditory learner. Whether there's complete truth and science to various learning styles, gearing my focus towards audio greatly helped my own learning and prepared me for aiding others in finding their own styles. And so, to this day, I try to mix in Visual, Auditory, Kinesthetic, and Read/Write learning to make sure I cover all the bases for anyone regardless of their style...well, except in blog posts where I can't really read it to you. Though if you do want some kinesthetic mixed in you can highlight each line you read as you go.

I say this, not to brag by any means since it was exceptionally nerdy, but so that you know it's coming from a place from authenticity. So without further adieu, let's dive into it.

First - Decide on a Goal or Project

What's a goal or project that you can use as a focus?

In school this is very easy - to pass a test. Unfortunately, this goal is extremely detrimental because filling in multiple choice questions is a very poor way to test knowledge, let alone build anything significant. BUT. Between that and paying 5 to 6 figures to take that test, you at least have a focus to channel your learning into. However, when it comes to learning independently, stopping at "I'm going to learn AWS" won't take you nearly as far as someone with a clear reason for learning it.

"But Cole, it's to get a job."

Okay yes, that's better, but that can also have its own problems in the sense that you can trade the means for the ends and indirectly sabotage the ends. In plain English, I mean it's where you rush to learn something in order to achieve a goal and, in doing so, fail to learn or retain it. For example, trying to swim so that you can stay alive vs. trying to swim in a safe pool where you can refine technique...well, the results are going to be very different. Though I could harp on this all day, we also know how detrimental binge learning is as well.

Therefore, the type of goal that I prioritize is one that is both a means and an ends. Why would I learn something like AWS?

"To get a job?"

Okay, now you're just being ridiculous. No. You learn it, and any other technology skill, to BUILD something.

Oddly enough, despite the fact that I'm sure you're nodding your head right now, how often do you, beyond learning, actually set out to independently build something? Whatever your answer is, my point is that because it's much easier to passively consume knowledge, this is what we tend to do. It's also what we've more or less been conditioned to do through years of education that prioritizes that style.

And so, for myself, deciding on something I'd like to build with what I'm going to learn is the first step.

Why do I need something to build?

For the same reason an archer needs a target to shoot at. To refine their direction and accuracy. For FOCUS.

The often unseen benefit of having a project up front is that your mind goes into an active lookout mode for anything related to it. In your mind, the project, its topic, and any other thoughts you've had about it become a framework upon which you can hang newly acquired and related knowledge. Without this foundation in place, you have to build this foundation with the new knowledge itself or by relating it to knowledge you already have (analogy).

For example, before diving into something like JavaScript, come up with a simple idea to build out. Maybe an image uploading application. Think through what it would be like. Make a small mockup, even if it's just in pure text.

With that done, as you navigate through the sea of information, your mind will be on the lookout for things that will explicitly help you build this project. "Oh, FormData? Perfect, that looks like what I can use to upload images" or ".sort()? Nice, now I know what I can use to order that feed of images" or "this??? Maybe I can make a meme out of it for the app's front page..."

When you give yourself a nexus that you can interlace new ideas and facts upon, they'll ingrain themselves far deeper in your mind and accelerate your learning process. And it'll also make tolerating whatever outdated tutorial you're digging through more bearable.

Second - Read Until You Understand "How to Think" About It

There's a time for textbooks, courses, deep tutorials, and the like. But for me, the beginning is not that time. After I've figured out a project, I will read posts, introductions, and soft articles until the 50,000 ft view of what I'm doing makes sense. By this I mean a rule of thumb. A catch-all focus. A guiding light. Something simplified that helps me break through the inevitable army of details that can lead to analysis paralysis.

For example, when I was getting into DevOps and automation, my 50,000 ft view was this: all I'm doing is figuring out what steps I'd need to take manually, scripting them, and then setting up something to manage and execute those scripts. With that simplified thought process, dealing with the overwhelm and not getting lost in the massive rabbit hole of technology selection, made everything easier. If I got lost in a gargantuan script, I'd step back and say, "Okay, where the hell would I be right now if I was just doing this manually?"

Or another example is with GraphQL. As someone who's primarily done REST forever, it took me a bit to wrap my head around how to think about this new paradigm. After all, if you go searching through official documentation, or most articles on the topic, you'll get dry terminology, ridiculous marketing, or just the nuts and bolts. The 50,000 ft view that helped me grasp it was this: with REST I'm forming my response based on which of my many endpoints a user hits; with GraphQL I have one endpoint and respond based on what payload they send me.

"But Cole, how do you find this 50,000 ft view?"

Read a handful of introductory articles from independent contributors. Folks that have actually done work with the technology you're looking to learn have often formed an intuition about it that you will never find in official documentation. This mental model you're seeking to acquire is like a compass - you can get lost, not understand the map in front of you, but still find your way.

"How do I know when I've found this 50,000 ft view?"

See if you can turn around and explain it in lay terms to someone who knows nothing about it. If you can make it humorous, all the better.

Third - Read For Awareness

It's at this point that I'll dive into a textbook or documentation. I have both a goal and a guiding light on which I can associate new information and so now it's time to start crunching it all up. HOWEVER...

...when I make this pass, I'm not reading to memorize or with the intention / expectation that, after slogging through this poorly written documentation, I'm going to be able to do anything. This is CRITICAL in order to set your expectations correctly and not get demotivated. Otherwise you'll come out of a week-long reading spree confused as to why you can barely write a "hello world" program.

Instead, what I'm seeking to acquire is AWARENESS of this technology's capabilities and what can be done with it. I'm trying to get to the point where, when I go to build my project, I know what tools are available to me. No, I might not know exactly how to use them, but that's not the point right now.

Think of it like this - you're a carpenter setting up your work bench. This part of the process is getting all of the tools in front of you and knowing what it is that they're capable of. You're not building anything yet. But had you started building before you understood that the hammer isn't the only tool at your disposal, you'll either be limited in what you can build, or your entire creation will be a Frankenstein of hacks and workarounds.

"Okay, so how do I read for awareness?"

Go to the documentation, or whatever textbook, and read it like a novel. Chances are the plot will be bad and the characters will be named Example A and Example B, but at least you can take solace in knowing thousands of others are suffering with you. Whenever you come to related terms, be sure to give them a respectable look-through...but don't get too lost in related topics.

While you're in this part of the process, you HAVE to be honest with yourself. Did you ACTUALLY read what you just saw? Or have you started developing temporary blindness from reading "Cloud security at AWS is the highest priority" for the 50th time? Remember, you don't have to memorize anything at this point but you DO need to process it.

Fourth - Build for Learning

Now is the time to build. Not to take multiple choice tests. Not to get stuck in reading even more. Build.

Just as it'd be insane to think that acing the written portion of a driving test would prepare you to drive on the highway, so too is the idea that you can just read, fill in bubbles, and be able to execute. To put it how one of my Economics professors used to say, "I've watched my wife cook for years but I still can't cook!"

At this point you have your goal, your guiding light, and a very loose web of information all interwoven together. But it's fragile. In fact, if you stop at this point and leave for a few weeks, when you come back, you'll be lucky to remember anything beyond the basics. It's this process of building that takes the gaseous knowledge you've acquired and turns it solid.

But why? Well, looping back to the beginning of the post, it's because when you go to build something a number of things occur to strengthen the knowledge:

1) First, you start mixing in all of the various learnings styles in context of an active process.

You're hearing things - everything down to the voice in your head working through issues and the profanity when things mess up. You're seeing things - the changes in code, the workflow patterns, the general look and structure of what you're building. You're touching things - just as it's important to get your hands on the wheel when you drive, it's also important to get the keystrokes of what you're building under your finger tips. You're reading things - obviously. And you're feeling things. If there's one way to ensure that information sticks, it's to associate an emotion with it. The accomplishment of getting through something or the absolute devastation of dealing with a bug for hours that turns out to be a typo...those are the types of events that will take your learning to a different level. For every one of these things that you do, understand that those events and actions are also being added to that web of knowledge you're trying to weave together. More and more associations build up to make sure that what you're doing is not forgotten.

2) Second, the sheer repetition of actions is, of course, necessary in any type of skill.

Each time you define a function. Each time you create a VM. Each time you stretch your mind over some tricky loop or algorithm...the easier it gets. Not only do the neural pathways related to what you're trying to learn strengthen, but, more importantly, your "fear" of taking risks in context of the skill dissipate. You know what I mean, "Well, I'd like to rename that file...but I don't know what will happen if I do..."

3) Third, you'll encounter edge cases, bugs, and nuanced details that will test your understanding and extend your capabilities.

Among other things, being able to deal with these issues will give you a massive speed boost in future projects. Regardless of what you think of the previous two points, this one is often the litmus test of how well you've mastered a particular technical skill set. If everything worked exactly like the documentation and its contrived "hello world" examples, then technologists wouldn't be nearly as in-demand.

4) Finally, since you've hopefully picked a project that isn't a cake walk, you've given yourself a reference for the future.

I want you to consider how TRULY different, in functionality, any given modern software application is from the next. Think about it. How many applications use a database? An authentication process? Email sending functionality? SSL? When you think about modern software...any software...what makes it individual and special is usually a very small percentage of the application. The majority of it is integrating that singular special part with all of the usual suspects that power it. In a sense, software is a lot like us humans in that we're immensely similar from a biological standpoint, and yet those similarities are overshadowed by the infinitesimal differences between us. My point is: when you go to build future projects, you'll have a physical manifestation of your experience (the project) that you can review and reuse.

Fifth - Repeat and Lightly Memorize

At this point it's about doing it again. Find another goal / project. Expand your compass and intuition by looking through what others have done. Read through other sources to figure out what's possibly changed and what other techniques are available. Build your project.

The difference is that, during this next pass, you'll notice things that are of higher priority and things that are rarely used. When I first got into JavaScript, some 10 years ago, Douglas Crockford's JavaScript: The Good Parts was a breath of fresh air. Realizing that, yes, there's a ton to this, but in practicality you'll only use this smaller 20%, was a massive accelerant to my productivity. This same thing holds true in almost any technology. There's what CAN BE USED and then there's what's PRACTICALLY USED. When you find the latter, that's when it's worth some time to start memorizing things.

"How do I know when I should memorize something?"

This can only be found in the 4th step of building a project. When you're building it will be painfully obvious what you should be memorizing simply because you'll find yourself looking it up so often. A lot of my posts on here are the result of this pain. I do things a bunch, find myself constantly looking them up, and then realize that opening that documentation page one more time is the line between sanity and insanity. Which leads us to the 6th step...

Sixth - Teach It

The truest test of your understanding is how well you can impart your knowledge upon another person...and them actually understand it. Any old fool can get up and spout terminology, step-by-steps, and unintentional hyperbole. However, those who know it well can generally explain it back in simple terms. One of my favorite economists is Alfred Marshall for this reason. Though most of the Economics community during his time was obsessed with mathematics, he held that it should only be a part of it. His full quote:

"(1) Use mathematics as shorthand language, rather than as an engine of inquiry. (2) Keep to them till you have done. (3) Translate into English. (4) Then illustrate by examples that are important in real life. (5) Burn the mathematics. (6) If you can't succeed in 4, burn 3. This I do often."

Now this quote can be interpreted in our field in many ways beyond just teaching. But, given that I spent a good portion of my college years seeking to explain advanced mathematics to hungover college students trying to cram for a test, whether or not they understood it was often a test of whether or not I understood it. And I say often instead of always because sometimes it was absolutely just them :D

However, while teaching it and giving back what you've learned is great, we're talking about your own learning. Being able to output it in real terms requires a very deep understanding of the topic. Just like you won't be able to build something from nothing initially, you won't be able to teach something if you haven't actually tried to teach it. But teaching has this curious effect of making you pay far more attention to what you're doing, what you say, and WHY you're doing something because, otherwise, your already large imposter syndrome fears might kick in and eat you alive. Obviously that's kind of a joke, but it does give a far greater focus when you know other people will be using what you're giving them.

In a Nutshell:

1. Decide on a Goal or Project
2. Read Until You Understand "How to Think" About It
3. Read For Awareness
4. Build for Learning
5. Repeat, Lightly Memorize
6. Teach It

But is there any other way?

Well of course...and that's what good teachers are for! Though nothing can replace the time you take to sit down and build something or teach it yourself, a great teacher can accelerate all areas of the process. They can give you the right goals, solid compasses, awareness of important topics, and a project that covers all the bases. They can save you who knows how many hours of your life that might otherwise get thrown into re-reading the same document 10 times in a row because apparently the person who wrote it is either barely awake, borderline sadistic, or completely disinterested and trying to get things done...

...but unfortunately, not everyone takes the jump towards that 6th step even if they are qualified. And furthermore, even if they are able to step into that next area, communication, instruction, and pedagogy are disciplines in and of themselves.

Learning is a Skill

Learning is a skill in and of itself, and in my opinion, the most important skill of anyone who works in technology. Unless you're new to the scene, you know how quickly knowledge can depreciate in technology. And even though it'd be great if the best tool for the job always won, performance and utility are only a fraction of what determines whether or not a technology, and those skilled in it, will remain relevant. Network effects. Backing capital. Chance.

However, often we're so honed in on the skill we're learning that we don't take the time to focus in on the process of learning itself. A phenomenon that's a great disservice to our own progression. Yes, repetition is key, and so the more you do it, the better you SHOULD get...but deliberately zeroing in on what works for you or doesn't is not a given. If that were the case, then nearly all middle age and older adults could be expert drivers in the Indy 500. I mean, they've been doing it for years right??? How can you go 20+ years and still not check your turn signal...

But regardless of what skills come into fashion or go the way of punch cards, and regardless of however many potential learning paths lie before you, remember that improving your ability to acquire more capabilities is the one thing you can depend upon.

Thanks for reading! I hope you enjoyed the post. If you'd like to read more from me, be sure to sign up for my mailing list:

My Tech Guides and Thoughts Mailing List