Right Seat, Left Seat, Solo: A Better Way to Start

Tomasz Tunguz's latest blog post 'Learning To Code In A Whole New Way' reminded me of learning to code and brought to mind something from my time in the Air Force—a learning technique I'd like to share. I found this technique effective for onboarding new team members.

If you want to be a pilot in the Air Force, you don't read a book and then go fly a jet. You do have plenty of classroom sessions and books to read, but then you (1) Right Seat: fly as a copilot and watch the instructor; (2) Left Seat: fly as the pilot and have the instructor watch you; and finally (3) Solo: take the plane out on your own. 

I was shocked to see that most developers train other developers in a process something like teaching a child to swim by throwing him into the deep end of a pool and laughing while he drowns to death. This is not only cruel to the newbie developer, it is inefficient for the team.

If a new person asks a "dumb" question, they are immediately ridiculed and told to "go figure it out" on their own. After some time and only after they have a strong base level of understanding to ask targeted, challenging questions, do they get any real help.

This is ludicrous. 

The justification for this practice ranges from "If you teach a man to fish..." to "What I'm working on is too important to be distracted by their stupid questions..." to "That's how I was taught and I turned out all right..."—and on and on it goes. Maybe it's because both my parents were teachers; maybe it's because I started as a project manager and always keep an eye on getting projects done faster. But for whatever reason, this practice makes no sense to me.

You can only really be good at self-directed education after you have a basic foundation to build on. If you understand 2% of the application you are working on, it will take days to solve the simplest of problems; but if you understand 25% of the app, you can figure out pretty much anything on your own and don't need to bother other people very often. In the ramp-up period you'll ask really dumb questions.  But those questions are easy—anyone on the team can very quickly show you the answer, save hours of wasted time, help you to maintain positive emotional momentum, and build team cohesion.

What I've learned works for onboarding new employees, adapted from the Air Force's pilot training regimen is this.  I use an example of developers, but it works for many different disciplines:

1. Right Seat: New developer watches a senior developer as they work. The new developer is not only learning by observation but can also catch grammatical errors quickly. Two minds work better than one at such things.
2. Left Seat: Senior developer watches as new developer works. It is much harder to do the work than to watch it. Even though the new developer will start to feel like they can anticipate what is going to happen next when watching, once it is their turn they engage different parts of the brain and will get stuck. The senior developer is there to get them unstuck quickly. The emphasis is on helping them get to the answer quickly, not forcing them to figure it out on their own—there is a time and place for that.
3. Solo: New developer is on their own. If they get stuck or have questions they can ask for help like anyone else, but there shouldn't be as many by now because they have a base level of understanding necessary to figure out most things on their own.

If you cannot get this from your teammates, or if you are working on a project or startup by yourself—as Tomasz recommended, try using CodeMentor.