At first, it seems like a great programmer should have all the skills to become a great teacher.

After all, coding has many of the same traits as teaching. Underneath all the fancy syntax, code is just a concrete set of instructions that tells a framework how to do something. Even if one microscopic detail is left out, we’ll know soon enough. The compiler will yell at us.

Programs require us to code in a specific order too. We can’t implement a concept before it has been defined yet, just like we couldn’t teach someone how to multiply before they already understood how to add.

On the other hand, the act of coding isn’t like teaching at all. In fact, it promotes bad habits that are entirely counterproductive to the art of teaching.

First, rarely do we code linearly. We don’t start typing from the top of the page and work our way down to the end. We’re incessantly jumping around our code, implementing functionality in an order that might not be obvious to the observer. It’s especially true when we’re finessing the smallest of details—a variable name change here or an erroneous data type there. If our coding process were anything like our teaching process, our lessons would be filled with stutters, misunderstandings, and take backs.

Second, coding lets us worry about the details of our stream of thought later. For instance, when I’m in the middle of, say, redefining the input parameters for a shared method, I make the change on the method’s signature and then recompile. I know my code is not going to compile successfully. I expect a series of errors to pop up, each one complaining about a mismatched parameter type everywhere I’m calling that method. But I do this because it’s a much faster way to see where I need to change everything else than scanning through code or doing a search on where the method is referenced.

Oftentimes, we compile our code not because we think our work is done but because we want to find out what we may have missed. A compiler is a lazy programmer’s best friend. Ditto for unit tests, code hinting, and autocompletion.

All these niceties are essential for productive programming. They give us softly padded walls to bounce our code off of. They let us focus on the big concepts first and not worry too much about perfection in our code-speak. A good programming platform is simultaneously wiping our chin, correcting our grammar, and telling us what we really mean while we spew out semi-coherent lines of instruction. The faster and more efficient we are at coding, the more we rely on these tools to steer us in the right direction.

Teaching a newbie is entirely different. Every missed detail is a lost detail. We can’t start our sentences expecting our student to finish them, at least not early on. And unlike a compiler, which invariably will forget our missteps once we correct them, people don’t have as much luck separating the wrong details from the right. It may take us a dozen compiles before we finally get our code just right. But imagine the deer-in-headlights look on your students’ faces if we were to correct ourselves that many times before our teaching lessons made complete sense.

The quirky ways we program efficiently run counter to the lockstep nature of teaching. You can’t throw a bunch of concepts at someone, leave out a few of the details, and expect your human counterpart to know exactly what you meant. Instead of a list of errors and warnings, you’ll be getting a blank stare.

A really good programmer doesn’t automatically make a competent teacher.