As Atomic continues to grow via our Accelerator program, our core value of Teach and Learn is putting some heavy emphasis on Teach. One of our first graduates from the program was feeling nervous about being a mentor to someone new. They asked me for advice and, thinking back on 10 years of working in software at Atomic and training new people, I came up with a list of big things to keep in mind when working with new developers.
1. Pair Programming Is a Must
The best way to help someone come up to speed in skills and methodologies is to work directly with them, side-by-side. Pair programming is the perfect chance to nudge people into good habits and explain along the way. The best way I’ve found to get someone proficient quickly is to make them drive.
A good pair of developers has one person working the keyboard (driving) and the other keeping their head out of the boat and steering the architecture of the code-base (navigating). The best way to learn navigation is by example, and having the new pair drive the keyboard has a couple of benefits.
First, they are actively involved, learning the basic driving skills they need to get code into their editor. This is the phase I like to call “Vim barking.” When I started as an intern eons ago, my mentor was a die-hard Vim guy. He spent weeks barking Vim commands in my ear until I internalized them and could “speak” Vim quickly. Coming out of college, I needed this: the ability to navigate files, search/replace, autocomplete, auto-format, jump to and run tests, etc.
The tool doesn’t have to be Vim, but whatever it is, spend time in the development process. Make the new pair drive. Show them how to be proficient, and be open to improving your own setup if they have ideas.
The second benefit of having the new pair drive is that it lets you, the more senior pair, steer the architecture. I’ve found that even hard-working, super-bright Accelerators usually don’t have great navigation skills (yet).
As you demonstrate good choice/patterns, opportunities arise for meaningful conversations about what you’re doing. Resist the urge to steal the keyboard and take over. (I’m often guilty of this, and I view it as a weakness in my teaching/communication skills.)
2. Take Time to Explain the Big Picture
When starting any new person, regardless of years of experience, I like to draw up some architecture diagrams on a white board. I conversationally doodle up how the big pieces of the app fit together, where pieces are hosted, how deployments work, what technologies are involved, etc.
Often, a simplified DB schema can be super-helpful for a new person. Of course, a lot of this is documented with the project, but I like discussing it as I draw it. The white board approach allows time for asking questions and clarifying pieces.
I err on the side of over-explaining, but I make sure the new person knows it’s okay to shut me down if they already know something. I do this to make sure they understand my train of thought and reasoning, even if they don’t feel confident enough to interrupt and say, “Wait, why are you doing _that_?” or, “Why not do it this way?”
Be careful with the Curse of Knowledge here. One thing I learned from my time teaching college students is that it’s very easy to assume they know more than they do.
Err on the side of teaching more, and let them stop you. Feel free to grab a white board and explain how that system test works or how mocking works. Spend the extra time to answer questions as they come up; don’t rush through the work just to claim the points for that story. You’re not just building software. You’re helping to build another maker.
3. Slowly Build Their Confidence
The goal of this process is to raise a developer that feels confident in their skills and can build quality software in a similar fashion to the rest of Atomic.
A great way to build confidence is to slowly introduce more responsibility. Stories and tasks don’t always require a pair; eventually, you can split the new Atom off onto their own sub-tasks. Once they’re finished, you can sync back up and review. As you work together, they can build bigger and bigger things on their own. This is a great way to verify that they’ve retained a lot of the patterns and practices that come from your pairing sessions.
There’s a reason the value mantra at Atomic is Teach and Learn. Just teaching at someone all day diminishes their confidence and doesn’t contribute to their sense of being respected and accepted.
Instead, field every question with empathy (remember how much you didn’t know in college). Listen to ideas and discuss them. Do not be dismissive.
As a mentor and senior pair, I often learn new tips or ideas and have great discussions about the way we do things here at Atomic. The goal, after all, is to make better Atoms and to continually grow as individuals and as a company.