Last week, my code lead sat down with me for a quick update. “You’ve failed plenty of times so far,” he told me, “which is to be expected.” I wasn’t surprised to hear this. I could think of several times I’d felt lost in the weeds of my own code. Each time, I’d sought out the perspective and experience of a fellow developer to regain clarity. I could recall several other times that I’d discovered the perfect solution to a problem, only to break something else in the process.

What did surprise me was my lack of reaction to his feedback. I wasn’t devastated or disheartened. This information registered as a simple, non-judgmental statement — and an opportunity to learn more.

The power of a growth mindset

This sort of neutral response to failure may not come naturally for most people. In my case, it was hard-won and developed over time — and is still developing. The mindset I began to develop in coding school is alive and well in the greater coding community. It enables coders to work on dozens of problems a day, solve a few, get stumped by a few more, and start over the next day.

One of my first assignments in coding school was to read ’s article, “.” Popova explains how there are two ways to think about intelligence: either it’s set and can’t be changed, or it can be developed over time. The scary part is, whichever you believe will come to be true.

Those who believe in a fixed mindset tend to avoid challenges, give up easily, ignore feedback, and sidestep any opportunities to flex their intellectual muscles. On the other hand, someone who believes in a growth mindset “sees failure not as evidence of unintelligence but as a heartening springboard for growth and for stretching existing abilities.” Whichever school of thought we subscribe to, our relationship with failure and success often follows accordingly.

Getting the memo

It took me awhile to get used to this growth mindset idea.

Early on, Luke Segars  – my instructor at – looked over my shoulder several hours into a project and noticed I was still working on the navigation bar. I couldn’t bring myself to move forward until the search bar looked exactly how I wanted it. I also didn’t want to show him my work until I’d perfected it. “Yeah,” he told me, “you’re going to need to get over that.”

A few weeks later, we started the day off with a JavaScript word problem. The goal: teach the computer to track how long a fisherman lost at sea would survive with a few fish in the boat and an ominously low chance of catching more fish. I tried to solve the entire problem with a single function and found myself boiling over with frustration. Even worse, this was just one of a series of problems that I’d failed to solve.

But my anger led me to pay closer attention to the solution. Luke broke the problem down piece by piece, dividing the complex problem into smaller chunks of logic. After each of the smaller problems were solved, he put them back together into a simple, cohesive whole. Looking back, all of those problems from the past week that had seemed out of reach now seemed more manageable. He’d told us many times to break problems into smaller chunks, but it wasn’t until I was ready to yell at him that I finally heard what he was saying.

Growth is a process

These experiences (and many others) gave me the perspective needed to turn fear into curiosity when I run into a concept I don’t understand. Whether it’s resolving a merge conflict, building an HTML email with the paltry collection of CSS properties that are actually supported, or pushing myself to ask a coworker for help with finding a solution… in coding, there are practically infinite opportunities to stretch my abilities and cultivate curiosity.

Of course, this isn’t to say that nothing changed for me in the transition between coding school and a coding job. There are team dynamics to navigate, scheduling conflicts between important meetings to solve – and my course of study is no longer so tidy nor linear. There is plenty of room for failure here, too. I still ask too many questions, jog to a meeting that is further away than I expected, or break the code I am working on.

But as I’m walking briskly through the halls of �������� or glaring at the semicolon that just cost me half an hour of mental energy, I think about a quote my wife once left in a note on my desk:

“Try again. Fail again. Fail better.” -Samuel Beckett

I remind myself that getting lost in a problem I can’t (yet) solve is a part of the learning process. If I don’t learn to live in that ambiguous and sometimes frustrating space, I’ll miss the hard-won moments of revelation that brought me into this career in the first place. The more I can accept failure as an opportunity for growth, the more discoveries are open to me. Each failure is a portal, and I intend to keep stepping through.