Two Types of Learning

November 26, 2019

There’s only two types of learning. There’s right time, right place learning vs. commitment-based skill buildup.

There are some things that if we learn them too early or too late, they’ll feel irrelevant and fly straight in one ear and out the other. The easiest example of this is learning the individual syntax for an API. If you use the API when you need it, you’ll start to memorize the commands, but if you read every word of the documentation beforehand, it’s not going to stick with you.

It’s easy to say that having your entire learning plan revolve around right time, right place learning is enough. You will naturally pick up what’s important and you’ll be a very malleable engineer.

I disagree with this. In fact, I think it’s naive. Learning things just in time means there’s never enough time to build up new skills deeply and deliberately. If you only learn about your language of choice (or maybe more importantly, your second language) when you need it, it will take 10x as long to understand the inner workings of the language. By then, the language may be out of fashion and you’ve moved onto learning a new language using right time, right place learning.

Commitment-based skill buildup is better for larger things to learn — new languages, CS concepts, programming paradigms, next-level stuff like AI/ML. You just can’t learn that kind of stuff just in time.

It’s easy when you’re learning pre-professionally. College or a self-taught environment naturally encourage going deep, arguably too deep. The best just in time thing to learn is software engineering itself. Once you’re already an engineer, it’s a hard balance.

So, how do you draw the balance? And, in keeping with the theme of the blog and the newsletter these past few months, how do you balance it when you have a good learning environment at work?

I believe the best thing to do is to have a list of skills you want to learn, and to differentiate between the two. I don’t know the criteria for doing so yet, so let’s go through some examples from my list and see how we’ll decide.

I’ve been keeping a list called “Concepts to Learn” in my todo list app since I started my job. It currently has about 20 items that I’ve collected throughout the months.

Let’s go through a few.

React Hooks

Okay… This is something very practical. This is mostly syntax, but it’s also got some lower-level theory behind it that the React team has published across the docs and Dan’s blog. So, for this, I think the next time that I am using React Hooks — probably at work — I should stop for a minute and read the documentation and maybe watch the talk where the React team announces Hooks.

This definitely falls into just in time learning, so I shouldn’t prioritize focusing on it when I go home. I should be making time for this at work.

MVC

I’m not super familiar with MVC. We use it in some form at work, like lots of people do, but I never really understood it. I’ve read enough about it to have memorized what Model, View, and Controller are, but I feel like I need something deeper. I need to understand why we use MVC and what context it was created in.

This feels like a specific topic in the higher issue of learning about software architecture. That’s very much a reading-based activity, with lots of deep thinking and high abstractions. This is something that, to be truly understood, needs a lot of context around it. I believe this is a smaller part of the larger skilling up of my software architecture skills.

GraphQL

GraphQL is an interesting mix of theory and practice. I know the basics, but I don’t know advanced syntax, and I don’t really like it because I don’t understand it contextually.

Is this something that would be fixed by digging deeper into it when I have not been exposed to its complexities or is this something that I should build up on the side on my own?

I don’t know. I tried reading a book about it, but that felt wrong. It felt too shallow in either direction. I think there’s not a lot of theory or deep thinking about GraphQL. It’s just a way to handle APIs. I probably need more exposure to when we use it. That feels very practical, and I should wait until I’m exposed to it further at the job. So, this is just in time learning.

Testing

This is… one I’ve been avoiding. There’s two parts to testing, the theory and differentiation between unit testing, integration testing, and end-to-end testing, and then testing frameworks themselves. Testing is an even split of theory and practice.

But which comes first? I believe that it’s useless to know what to test if you’ve never even tested the wrong things first. I probably need to do this at the right time, right place (now), but a very practically-focused course. Further in, getting very good at testing definitely requires you to think more critically, and is probably more of a skilling up situation.

I won’t go through all 20 items on my list, I think these 4 are an interesting overview of examples. The commonalities between what should be learned just in time mostly have to do with the practice itself as it relates to specific skills and tasks at work, learning GraphQL, learning how to test, etc..

But, really skilling up requires a deeper commitment. You need to be good at the specifics of the implementation first, and that’s a lot easier when you have a context to use it in, then you commit to skilling up because you’re holding that context.

I use JavaScript almost every day. I can use it very well in practice. So, now is the time to commit to thinking deeply about it, learning about the internals like the event loop, and the V8 architecture, etc., etc.. That won’t be practical in my day-to-day, so I need to skill up on my own time and at my own pace.

But learning about the internals of Python are useless until I learn how to use Python practically. It’s inefficient to learn how to use Python practically until I have a context to use it in.

Basically, it’s all context.


If you liked this post, get updates about new posts by signing up to my infrequent newsletter.