Learning on the Job

I had been a college student for almost three years before I realized: I never really learned how to study. Sure, I knew, and occasionally even followed, all the commonly-given advice: Take notes. Highlight the main points in the reading. Write study guides. But I didn’t know if these rituals were actually helping me learn, or if they were the equivalent of garlic hung to ward off the specter of vengeful TAs. With mid-terms approaching, my procrastination method of choice became looking for and reading accessible books written or approved by cognitive scientists on the science of learning.

While I learned a bunch of minor useful tricks (vary where you study; use mnemonic devices), the main, recurring theme across all the material was that a technique’s usefulness tends to be directly proportional to how much effort it takes. Effort burns things into your brain. Highlighting? Pointless. Summarizing? Pretty effective. Testing (such as with flashcards)? The most useful method there is.

Since we’re usually on the lookout for ways to make learning less effortful, that might seem a bit disappointing. But “effort” here doesn’t necessarily mean work. Using flashcards isn’t that much harder than re-reading a chapter, but it’s much more effective, because it takes your brain more effort to try to recall something than simply to expose itself to it.

My reading proved to be more than worth the time (and library late fees) it cost me. But I didn’t think it would be applicable to my upcoming software engineering internship at Postlight. In fact, as my internship start date approached, I was growing more and more nervous. I felt vastly under-qualified and unprepared. After all, I had no clue what a CSS preprocessor was supposed to do, only the dimmest idea what “state management” meant, and I still don’t really understand what it means to go serverless.

But my very first day, just a few months ago, I tagged along with my manager, Gina Trapani, as she met with Jeremy Mack for a check-in. Though she was primarily a backend developer, she’d been learning React on the side, and these periodic check-ins were meant to add a little incentive to keep working on it as other projects came up. I couldn’t have gotten a clearer signal that you weren’t expected to know everything, and that learning is part of your job — no matter how senior you are. And as my internship ends, I’ve found that I’ve learned as much in the past three months as in a year at college.

The learning you do on the job doesn’t take quite the same form that it does when you’re working through a formal curriculum. Still, lessons from my reading kept cropping up in unexpected ways during my internship. Here are three contexts I found learning most often takes place on the job, and how to make the most of them.

Trial By Fire

Most often, you learn because you have to: your team is using some technology you’re unfamiliar with, you’re given a task you’re unsure how to do, you’re trying to fix a particularly stubborn bug. Through the repeated process of getting unstuck — reading documentation and tutorials, asking co-workers for help—you’ll learn.

But with the problem at hand in the back of your mind, it’s easy to find yourself skimming for what you need instead of taking the time to truly understand the concepts you’re being exposed to. In the worst case, you’ll just copy and paste your way into solving the problem. You’ll finish the task more quickly, but your work will be shoddy and the next time you face a similar problem, you’ll have to go through the whole process again. But if you take the time to deeply understand the problem’s domain the first time, you’ll reap the benefits later on.

So push back against the urge to move on, and slow down — even if it’s just by typing code out instead of copying it. When I’m reading something I suspect will be useful later on, I like to use a strategy adapted from one in this book intended for dense, academic reading: write a short summary in explain-it-like-I’m-five English of every paragraph of documentation or few lines of example code or so. Trying to phrase things in the simplest possible terms will often uncover the gaps in your knowledge: gaps you can then fill.

Learning via Osmosis

At other times, you’ll learn just by, well, being an engineer: through code review, following along in forums and bug reports, talking to people about their work, reading the articles your co-workers post on Slack. But while you’ll learn in spite of yourself when faced with a problem that demands it, you can find yourself going through the motions of learning without learning: to “read” an article only to realize you haven’t actually retained anything, or to implement a co-worker’s suggestion without understanding the motive underlying the change.

Once again, to truly take advantage of the learning opportunities you’re presented with, you’ve got to put in a bit more effort. Instead of just reading the article, take the time to read (and participate in) the discussion surrounding it. Ask your co-worker to clarify the suggestion she made in code review. Think critically about the code you’re exposed to: how does it work? Is it well-designed? Would you have written it differently, and how is the code better or worse than how you’d have written it?

Deep, Directed Learning

Reading a book, taking a course — it’s what we usually think of when we think of “learning”, and sometimes there’s really just no substitute for it. But without a teacher to compel you to do the reading, it’s all too easy to decide that you’ve got higher priorities.

Start by making a concrete commitment. Instead of a vague desire “to improve”, decide that you’re going to learn about design patterns, or category theory. There’s a learning group at Postlight where we give bi-weekly updates on our long-term learning plans: telling other people you’re working on, say, learning Latin makes it more concrete, and wanting to avoid the embarrassment of being absent at the next meeting keeps you accountable.

Once you’ve made a decision about what, exactly, you’re seeking to improve, it’s important to de-escalate the size of the task in your mind. To paraphrase Kevin Nguyen on reading: if you’re only going to try learning something new if you’ve got a weekend to spend in a cafe drinking cold-brew coffee you’re only going to learn something new when you spend a weekend in a cafe drinking cold-brew coffee. So let yourself learn in smaller increments and don’t give yourself too much grief about it. In fact, it turns out it’s often better to space out your learning: giving yourself time to forget what you’ve learned between study sessions makes those sessions more effective.

I like to take books chapter-by-chapter and courses section-by-section. It’s easier to make time for fifteen pages about the JavaScript prototype chain than 400 pages about everything JavaScript. And I never, ever let myself feel guilt for deciding that a resource just isn’t providing enough value to be worth continuing: maybe the material is too high or low level for my particular skill level, or maybe I don’t find the creator to be a very good teacher. The nice thing about not being in school, after all, is that you can choose your own reading, and it’s worth taking the time to find and stick to the resources that truly provide the most value for you.

It’s also useful to pair your learning with the work you’re already doing: if you’re a front-end engineer, read a book on more effectively using JavaScript, and try to put it into practice. Forcing yourself to recall and apply what you’ve learned is the single most effective learning tool there is. Plus, you’ll be more incentivized to spend time learning if you know that what you learn will be immediately applicable.