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:unit that’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…)