Key and Hand, Tamara Lempicka, 1941

I don’t usually deal in absolutes, but I now know this one thing to be fundamentally true: no one becomes a good software engineer by themselves. But in an industry that has always prided itself on the myth of the superstar ninja, the lone wolf, the self-taught genius, it can seem like good developers are not born - they rise out of the ground, fully-formed and churning out PRs their wake.

In my career so far, I haven’t seen a single person who has been able to grow successfully as a competent developer without learning from others. And, I’m concerned that, as an industry, we don’t often actively talk about the fact that we need other people at work to help us learn things, and that we need room for this learning in our development and work planning processes.

In “Rise of the Expert Beginner”, an essay that I re-read every couple of years, Erik talks about how developers stop learning. His basic thesis, based on previous studies of skill acquisition, is that people start acquiring skills very quickly. But, at some point in the learning process, they get to a point where they stagnate because the skills that they learned as a beginner will carry them to being an expert.

Think about the difference between being able to write functions that print out to your terminal versus creating a class with methods that return text to pass to other methods that checks for sanitized inputs, and then passes it to a front-end. Now imagine that that class is a function that has to be packaged to work in the cloud. And, on top of that, imagine that the function has to be version-controlled in a repo where 5-6 people are regularly merging code, pass CI/CD, and is part of a system that returns the outputs of some machine learning model with latency constraints.

You can write print statements in any language pretty quickly (given that you get over the hump of installing it on your local machine). But it takes a very long time to understand how to get from print(“Hello World”) to “Here’s an app that is making machine learning predictions for you in real-time.”

So how do we get everyone on our teams to that place? How do we help others get out of the dark, frustrating place that is the local minima of suckiness that is the expert beginner, past the stars, and into the cloud? And, how can we help ourselves become better developers?

There are three things that I’ve noticed in my own career that developers need to become better:

  • the room to make mistakes
  • repeated exposure to best practices, and
  • understanding how to ask good questions, or learning how to learn

The room to make mistakes

This is the best recent description I’ve found of the phenomenon we now call psychological safety: