Early in my software engineering career, I had an internship at Microsoft. I was working on the Microsoft Office team. We were responsible for the internals of a distributed peer-to-peer network, and it was one of the most complex applications I’ve ever worked on. My team threw me into the deep end.

I had to work in a codebase that spanned millions of lines of code and use a programming language that I was completely unfamiliar with. Despite that, I was expected to help the dev team build a better product. I couldn’t have doubted myself any more than I did. It was scary.

But by the end of my 6-month internship, I had turned myself into a contributing member of a high-performing team. I had a lot of people to thank, but the most important one was my mentor, Ransom. He took me under his wing and accelerated my learning. Ransom seemed to know everything about the codebase. I’d always see other senior developers knocking on his door to ask for advice.  

To be honest, I was intimidated by Ransom. His time was so valuable. But he always took the time to make sure he put me on the right track and in a position to complete my assigned work. Throughout my internship, I learned more than one powerful lesson while working with him. I wrote about the most important one on Inc.com a little while back. He taught me so many things about how to help other people learn quickly.

But here’s the crazy part. I learned the most important lesson from him when he lied on stage at a huge Microsoft conference. I’ll rewind a little bit to give some context.

It was my first few weeks at Microsoft.

I was assigned a few basic tasks that would help me get familiar with the codebase, workflow, and product. The first responsibility that I had was to spruce up the automated test suite in a very narrow and specific aspect of the product. After a painstaking month of work, dozens of hours of talking things through with Ransom and other developers, and a number of code reviews that made me start over from scratch, I finally shipped a feature.

Ransom probably could have done it in only a few hours.

It was painful. But the process taught me more about programming and problem solving than any other experience I had gone through previously. Over time, I became more and more effective. By the end of my internship, I was shipping features and bug fixes very quickly.

I was developing a better eye for noticing problems too.

There was one bug that I remember in particular. There was a problem with the way our files were synced peer-to-peer. I knocked on Ransom’s door to tell him about it.

I explained the bug to Ransom and walked him through why it was happening. Our code had a sophisticated, thought-out organization. Unfortunately, this edge case didn’t fit inside the paradigm like everything else. Ransom and I decided that it made sense to solve the bugs in this edge case in a way different from the way from how the core of the system was designed.

A few weeks later Ransom was set to give a presentation to the entire Microsoft development team.

He was scheduled to talk about how our system was architected. He flew out to Redmond, and his presentation was video streamed for developers outside of Redmond. I tuned in to watch it.

I watched Ransom articulate exactly how our system worked. He broke down the organization of different structures in the application, walked through examples of how our engine could sync things across peer-to-peer networks (plus SharePoint and other endpoints too) and talked about how everything was set up.

He nailed it.

It was really cool to see my mentor representing my office on a stage in front of hundreds of people.  

After Ransom finished his presentation, he gave the audience time to ask questions.

After about 6-7 minutes, Ransom answered a question in a way that would permanently change the way I thought about teaching.

The question was in relation to the system that Ransom and I were discussing a few weeks earlier. The audience member described his interpretation of how he thought out system worked and asked Ransom if his interpretation was correct.

It was clear that he understood the core of how the system worked, but he overgeneralized it a bit and didn’t account for the edge cases that Ransom and I had discovered.

When audience asked the question, I closed my eyes and put myself in Ransom’s shoes. I imagined walking through the specifics of this pretty complex bug, some of the limitations of the architecture, the specific workaround, and talking about the specifics.  

But when the audience member said this:

“Is it fair to say, that’s how the system is built?”

Ransom’s response astonished me:

“You could say that…”

Ransom lied. Well, lied is probably too harsh a term. But he certainly oversimplified. He certainly didn’t forget the nuances of the problem – we had recently talked about it, and Ransom as one of the smartest devs I had known.

So why didn’t Ransom correct the audience member handle the situation the way I thought he would?

There are a lot of reasons why. They all go back to the core of why Ransom was such a great developer and such a great mentor of other developers.

1. Ransom was confident in his skills. When you’re an expert on a particular subject it can be tempting to correct people and tell them they’re wrong to prove your expertise. With any system that’s large and complex, any generalization is going to be an over-generalization. But telling people they’re wrong and correcting them based on minutiae is often less productive and far less helpful for the person you’re supposed to be helping. There are ways to teach complex topics without talking down to people.

2. He realized that the audience member who asked the question understood the core of what he was talking about. The guy understood how it worked in virtually all situations except a couple really exceptional cases. He was mostly correct and had a solid general understanding of how the architecture was built. In that moment, it wouldn’t have been helpful to correct him in front of the crowd and go into complex edge cases. Doing this would have confused the audience member – and likely the entire audience.

3. The answer was correct for the person asking it.  For people like me and Ransom, it was important to work in the weeds of the codebase and try to nail down all the edge cases. It’s part of our job. But for people who are just interacting with our codebase, as opposed to the people building it, sometimes the internal structure and edge cases are far less important. Ransom understood that you need to tailor your teaching to your specific audience. That’s something that only really good teachers understand how to do.

When I teach people to code, I now take on this philosophy.

Learning to code is hard. It’s common for beginners to ask questions that will lead to answers that only confuse you more. So when someone asks me a question like this:

“Is it true that [something] is always true?”

I typically answer it with something like:

“Yeah, that’s usually the case.”

I try not to answer it with something like:

“No, and here’s a handful of reasons why you’re wrong.”

Why? Because that’s what Ransom would do.

If you’re learning to code, you don’t need to understand every complex edge case for every single concept. You’ll go crazy if you try to do it. That’s why I won’t ever push students in that direction.

As you level up your coding skills, you’ll start to learn more about the intricacies of complex programs and systems. But you should remember that it’s important to slowly build up your core foundation first. Once you understand the broad strokes, you’ll be able to dive into the more complex nuances later on.

Students often articulate questions in a way that isn’t really what they meant.

Teachers need to be able to synthesize these questions and answer them in a way that is best for that individual student at that point in time.

That’s what I try to do. And it’s what we tell every single mentor in the full Firehose program to do as well.

Put yourself in their shoes of the student and ask yourself, what does this person wish they asked, even if they articulated their question a little differently? That philosophy gives students the best chance to grow and reach their potential without getting stuck along the way.