During my career, I’ve constantly heard about how learning new things has to be uncomfortable, how you have to just throw yourself into the deep end, etc. People will also try to equate learning things with how you have to “exercise hard” in order to build muscle and get stronger (which is another thing that isn’t true depending on the kind of strength you want to build). The obsession and expectation is that basically any kind of growth has to hurt.

I’m here to tell you that’s not only untrue, it’s actively harmful to make this the expectation.

Why is it harmful? Setting the expectation that learning has to be uncomfortable means that you are, at a minimum, going to cause people with various levels of anxiety to self-select out of this career. Speaking as someone who has anxiety (a fact which may surprise some people who know me), the anticipation that something is going to be difficult or painful can make it daunting, if not impossible, to start something.

This expectation that learning is going to be uncomfortable will also work against people with depression, PTSD, C-PTSD, etc for similar reasons. These groups contain a lot more people than you’d probably suspect, and that makes “stress is normal during learning” a very dangerous and harmful gatekeeping device.

So how do we fix it? We start to normalize, from a social standpoint, the reality that a lot of learning can be done gradually and in a low-stakes environment.

Yes, we’ve all been in situations where we’ve had to figure out the answer to a problem when production blew up and the stress was at a high level. Some of us have also had the dubious pleasure of learning tons of new technology on the fly because the requirements of our jobs changed rapidly. And I’ll be the first person to admit that you can learn a lot like that in a short period of time, but I’ll also be the first person to admit that learning like that is extremely scattershot and stressful.

Not to mention that most of the time, the things we learn come in as a trickle, not as a flood. They happen as the result of solving relatively mundane problems as we work or poking at a project idly on some random evening. In fact, they often happen so gradually that we don’t even realize they have happened until we look back and see how far we’ve come.

The best way I’ve found so far to take the stress and pressure off of learning new things is to try to foster a sense of kaizen (roughly translated – “continuous improvement”) in both myself and on my teams where learning is concerned. If it becomes part of your regular routine, it tends to become a lot less stressful.

Make it part of your regular workflow. Explicitly make it known that not all of your working hours are going to be spent hands-on-keyboard shipping features, but rather that some part of the day/week is going to be used to learn. If you don’t make it an explicit expectation on your teams, people will often sacrifice their time for learning in order to “catch up” or “make a good impression” and this will cause them not only to stagnate from a skills perspective, but to become even more insecure because they feel like there “aren’t enough hours in the day”.

I’ve seen a number of places where they said that they wanted people to continue learning, but their actions showed that they only valued being a feature factory. This is not a good place to be in. You have to not only say that you want your people to learn, you have to set the tone in your organization so that it’s socially normalized and acceptable to be able to answer “what are you doing?” with “Learning X”.

From an actual learning standpoint, I’ve found that one of the most effective ways to learn new things in a low stress way is to take it in stages. I’ll decide that I want to learn Thing X and then break it up into manageable chunks – “manageable” is the key word here. In fact, I’ll often try to figure out what the simplest thing that I can do next to learn the subject is. Being overly ambitious is a recipe for stress when things don’t work, and we’re trying to avoid that.

Let’s use the example of learning a new language.

First, I’ll want to learn the basic syntax, so I’ll probably watch a couple of videos or read a quick start tutorial.

After that, I’ll write a little code. Nothing too complex – hello world, a couple of functions to do simple math and work with strings, etc. Essentially just enough to figure out how to write “working” code, simple functions, and possibly basic output.

Next, I’ll learn to write a test in it. This may seem like a big jump (and if you aren’t well versed in TDD it may be – these are my steps. Yours may be different). Being able to write a test means that I can iterate on learning new things faster because I can write code snippets to learn different concepts without having to write an entire program around each of them.

After I’ve figured out the basics of a language and how to test, we’re on to the concept of Breakable Toys outlined in the book Apprenticeship Patterns. Breakable Toys are programs that literally don’t matter in the scheme of things. It doesn’t matter if you screw them up because nothing is depending on them, so don’t worry about making mistakes.

For these, I may use some code kata (which are available online) or start to work through exercises in the book Exercises For Programmers (which basically starts at “hello world” and works up to consuming and creating APIs).

I’d recommend putting your Breakable Toy into source control and commit frequently (make it a private repo if you’re nervous about people seeing your mistakes as you learn). This will allow you to get back to a known good state if you make a mistake while you’re working. I find that it’s a lot less intimidating to try things if I know that I can roll back broken changes.

After I get to this point, I’ll probably spend some time learning the finer points of the language – being able to program idiomatically in the language for example. I’ll also probably spend time learning about security issues and how to resolve/avoid them (this is something that’s in my wheelhouse as a general skill so I try to keep up). These are stretch goals for me, so don’t think that you have to get to this point to say that you can work in a language.

At this point, you’re literally creating functioning applications and have done so in a way where the consequences of making a mistake are essentially the frustration of figuring out what went wrong. It may be a slightly longer timeline to learn the language, but the stakes are much much lower. Congratulations, you have a new, useful tool in your toolkit. (Now, put it on your resume and in your notes for your end of year review)

The added bonus is that, by breaking it up like this, you can do it a few hours a week and make noticeable progress. In all honesty, when I follow the workflow I outlined, none of the steps tend to take more than a few hours with the exception of writing more complex programs later in the learning cycle (I wasn’t kidding about doing the next, simplest thing possible).

Also remember to celebrate the wins at every step. You are making forward progress every time your tests turn green. Every time you figure out why the thing you just tried didn’t work, you’ve grown as a developer. Take a moment to realize that and give yourself a pat on the back.

Pain doesn’t have to be a part of most learning. In fact, a lot of times, it’s better when it isn’t a part of the process. We need to accept and normalize this mindset for ourselves and others.