I graduated with my computer science degree just over a year ago. I had learned what I thought was a lot about backend, “heavyweight” C-based development, and I assumed I’d be using those skills on the job, while learning new things that were unique to the consulting trade. I had a few acquaintances who were web developers, and I’d come to think of web development as a lightweight version of what I’d learned in school. This turned out not to be the case.
When I started at Atomic, I found myself assigned to four different web projects over the course of a year. Learning web development in 2016 turned out to be incredibly overwhelming, especially for someone who had been taught to use the C++ STL and not much else. I couldn’t understand how the people around me could keep up with all of these libraries, tools, and frameworks.
Coupling this with the need to prove myself as a new developer in a new place made for a lot of anxiety. Opening up our project’s package.json file made me want to crawl under my desk and write vanilla C++11 for the rest of my life.
Surrounded by Wizards
A big source of my anxiety about development came from being surrounded by other people who had way more experience than I did. We’re talking orders of magnitude more time, more projects, more problems solved, and more clients helped. I’d sit behind them, feeling useless while I watched them work. It seemed like they had the answers for everything.
I started to perceive experienced developers as wizards. Sometimes, one of those wizards would give me a small task to complete on my own, without a pair. I’d struggle and bumble and be terrified that, any minute, they would come back and see that I had no idea what I was doing.
I’d google the problem, search fruitlessly, and after entirely too long, I’d throw up my hands. Dejected, I’d decide that only a wizard could solve this problem; I must not be able to do it because I’m too inexperienced, or maybe just too stupid. Once I finally swallowed my pride, I’d turn to my team lead and ask what to do. And they would…google it.
What? They weren’t just holding that knowledge inside their heads? It turned out that experienced developers didn’t know everything, after all. But why were they so much more successful at turning up answers to the problem? After many months of watching carefully and asking questions like, “How did you know to google that?” I realized that there was a fundamental difference in how I went about problem solving, versus how wizards did.
What Would a Wizard Do? (WWAWD)
When I ran into a problem, I’d google the error message, throw some console.logs around, and get lost in stack traces in hopes of uncovering a lead that would ultimately take me hours of searching to pin down.
But when wizard developers ran into problems, they would take a step back. They’d think critically about the whole system and hypothesize about potential problem areas. They’d have a idea of the solution they were seeking before they even thought about hitting google. They didn’t have all the answers, but they knew what they needed to learn to find the answers.
The difference was that wizard developers perceived problems as artifacts of error by rational humans in otherwise rational systems, whereas I perceived them as mysteries beyond my control.
Imagine yourself as a team lead wizard. Shake off the tiny goblin on your shoulder that starts panicking when the answer doesn’t turn up on your first visit to Stack Overflow. Internalize the idea that the problem is solvable, and that you have the ability, if not all the information, to solve it.
I’ve found that learning to identify and locate the information you need takes time, and that having relevant experience does help. But that’s why being surrounded by wizards is so great—I can pull on their experiences for guidance in my search, instead of just asking them for solutions.
What Kind of Thing Is It?
One of the most important qualities of a wizard developer is the ability to think critically about how the parts of a system work and where potential failure points are. This requires them to have an understanding of what each module in the system is, how it works, and what problem it solves.
I found this exceedingly difficult to do. I would get overwhelmed with the sheer quantity of named things in our codebase–all of the different libraries and tools and platforms and environments. When I jumped into new projects, conversations with my teammates would go something like this:
Wizard: So if you run
yarn test:unitthat’ll run our Jest tests.
Me: Okay, what’s Jest?
Wizard: It’s how we test React apps.
…A while later…
Me: (googling Jest problems) I’m getting errors here in the tests, but I can’t find anything about them online. What’s going on?
Wizard: Oh, that’s a problem with how you’re using Enzyme.
Me: Enzyme?
Wizard: It’s a testing utility for React.
Me: (I thought I was using Jest…)
I’d be left feeling confused and incompetent. Was Enzyme a tool inside of Jest? Was thing A a subset of thing B, or a plugin, or totally orthogonal? This would happen with external tools, modules of our own codebase, and even just business domain concepts. But the questions took up too much time and derailed important team-wide discussions. Later, I would beat myself up for not remembering the difference between Jest and Mocha and Enzyme and Nightmare and Phantom.
Eventually, I realized that the problem wasn’t my failure to remember library names. What made the difference in my high-level understanding of the system was how I asked my questions. I started asking what I actually needed to know:
What kind of thing is it?
- Jest: A test-running tool
- Enzyme: A package of utilities for writing tests for React apps
What is it similar to?
- Jest: Sort of like Mocha
- Enzyme: Sort of like Casper
What problem does it solve?
- Jest: Quickly running tests for TDD
- Enzyme: Manipulating React components within tests
Asking the questions that I was really trying to answer helped me find solutions to my problems, and it turned out that I remembered things better later. This technique got me on the right path, toward a fuller understanding of the systems in my projects. It also helped build my confidence that I could solve any problem by learning to ask the right questions.
Overcoming the Anxiety with a Mantra
Remember how I mentioned that feeling of wanting to crawl under my desk and hide? That feeling still came around when I looked at a new codebase for the first time, when I listened to gibberish-sounding technical discussions between wizard developers, when I had those moments of perspective that made me realize just how much I didn’t know. It was a huge, crushing feeling that I could never possibly understand all of this.
For the last few months, I’ve been keeping a mantra that helps me stay on track when I start to panic: “I don’t know everything, but I can learn anything.”
I’m a smart person. Just being unfamiliar with a tool or some esoteric noun.js doesn’t negate that.
All of those libraries and all of those tools were written and documented by wizards people. Those people want you to use their tools; they want you to understand, and there are resources like documentation and communities and open-source code there to help you with all of that.
All you need to do is be confident in your ability to dive in and learn new things. Having a simple mantra to fall back on reminds me to be fearless in my pursuit of understanding.