I work with databases for a living.

I teach people, and I help them via consulting.

And as far as I can remember, I’ve never written something about how b-trees work.

And I don’t ever expect to. Ever.

For decades, I felt really guilty about that. I kept telling myself, “Man, I’m not really teaching people about databases because I don’t explain b-trees. My most popular free class, How to Think Like the Engine, completely glosses over the whole concept of b-tree navigation, and I act like all of the magic is just within the leaf pages themselves. It’s not, and … I should probably explain the rest of the magic.”

But the rest of that magic just isn’t that important.

When I teach How to Think Like the Engine, I see all kinds of lights go on in peoples’ eyes, and they say stuff like, “Now I get it. Now I understand why column order matters in an index, and I’m starting to get what columns are supposed to go first, and why my query is scanning an index instead of seeking on it, and why key lookups have to be done.” They immediately do a better job of designing indexes to support their queries. As they’re walking away, I feel like I need to add, “Oh, by the way, there’s this thing called a b-tree, and it’s how you actually find the page you want, and … I mean it’s probably important, but… yeah sure you should go, because I gotta scope how much I can teach you in the limited time we have together.” I felt really guilty about that.

I stopped feeling guilty when I watched Adam Savage answer the first question in this YouTube video:

He said:

Science communication is about getting the idea across, not all the facts. I know that sounds weird, but sometimes the facts can get in the way of the understanding.

He goes on to explain much more, and with every sentence that he uttered, I found myself yelling, “YEAH! YEAH EXACTLY! PREACH!”

Some of you out there wanna share what you’ve learned. You wanna write a tutorial or build a presentation, and you feel overwhelmed because you keep adding more and more onto the list of things you think it needs to include. You feel like you can’t explain topic A and topic E without covering B, C, and D in detail.

Your strategy is to:

• Come up with the concept you want to teach.
• Write your takeaway slide: the 4-6 bullet points that you want the audience to have learned during your time together.
• Write a bio of the perfect person to attend your session. How old are they? What do they do for a living? What do they know already? What terms have they never heard before?
• Write out the linear story you’re going to tell them, trying to keep it in a straight line as much as possible, without going off on tangents. You need to get them from what they know today, to knowing the 4-6 bullet point takeaways, taking them on as few detours as possible.

When you find yourself saying, “Oh but they really need to know C or else their project is screwed – but it would take too long!” – no problem, just add that to a resources slide that you’re going to cover at the end.

Your readers/attendees are not going to walk straight out of your session and go build a database server by hand! They’re just using your session as a starting point for their learning journey, and you’re going to be so excited and compelling that it’s going to motivate them to learn more. Your resources list at the end of the session is valuable, and the really motivated students are gonna devour that stuff on their own time.

Except for b-trees. People writing queries have no business learning that minutiae, and I’m tired of feeling guilty for avoiding that topic. And if you’re the kind of person who was kinda underwhelmed by how b-trees are mostly unrelated to the practical work of performance tuning, then check out my training classes.

Update one week later: okay, I finally taught you about B-trees. It was bothering me deeply.