posts about mistakes rss

Don't lecture when teaching software engineering

Have you ever attended a learning session or brown-bag run by another engineer at your org and realized afterwards that you didn't actually learn anything during it? Or maybe you've given a presentation like that? After your session, you saw people making the same mistakes that they'd been making before the session. It's a bad feeling.

Most engineers don't know how to put together a good learning session, but teaching is a learnable skill! And if you learn the basics of what goes into a good learning session, any presentation or learning session you run will be a ton more effective.

The short version:

  1. Figure out what skills you actually want to impart
  2. Figure out why people should care. If you can't figure out a good hook, maybe it's a bad topic.
  3. Give people chances to practice.

Why are lectures about cool topics ineffective?

For learning sessions and brownbags, many engineers start with a "cool topic" that they want to tell people about. They spend a lot of time figuring out all of the snazzy things about their topic and then deliver that content in a lecture. There are a few reasons starting a presentation from a “cool topic” doesn’t necessarily lead to an effective session:

  1. Lectures are an ineffective learning format because they don't encourage practice. But… when you have a cool topic, the instinct is to give a lecture about it.
  2. Your audience might not find the same things interesting that you do, and this is particularly true when folks want to share exciting work that they've done—there’s often some ego wrapped up in it. Would you recommend that someone else present on the topic that you’re excited about because you think the topic is that important? That’s a good sign that it’s valuable.
  3. We’re not trained presenters—making lectures engaging is a skill that most engineers haven't practiced.

It makes sense that that's how people approach these presentations! Most examples you see are exactly this: videos on youtube, conference lectures, and even blog-posts like this one. Lectures are the simplest format when the audience gets large or when content needs to be delivered asynchronously.

That's not to say that there aren't great lectures out there! But when we deliver content within a company, we don't need to restrain ourselves to a lecture. We can have people share their screen to click buttons and write code. We can ask questions as we go to check to make sure people understand what's going on. We can go through practice problems. We can have a discussion. Lecturing is a tool, but it's not the only one available.

Why should people care?

The other key part of delivering content within a company is figuring out why people should care. Something being "cool" isn't always a good reason. For learning sessions that I run, I try to figure out the skills that I want engineers to take away from the learning session and why they should care about those skills or techniques. "You should come to this presentation because you'll learn $USEFUL_THING" not only makes your audience more interested in learning $USEFUL_THING, it also helps you make sure you're focusing your session on the most important parts.

When teachers talk about lesson plans, they'll talk about the "hook": Why should people care about this session? How is it going to make their work better? Without that hook, why should someone pay attention to this session and actively try to learn?

A few examples:

You can punch these up even more—"We didn't always run this session on DataDog, and people wasted so much time. I remember one time where a team had spent a week trying to debug something, and it took ~5 minutes of pairing and exploring the logs and adding a notebook to figure out what was going on. Want to save your future-self a week of frustration? Listen on."

But if you don't hook people, your session will just be background noise. And if you can't figure out a good hook for why someone should care about your session, maybe it's not a good topic for a session!

Engineers Will Be Able To ${DO_THING} (EWBAT)

Teachers start their lesson plans with a list of SWBATs (Students will be able tos)—the list of skills that they want students to gain over the course of the lesson. Starting your planning with the concrete skills that you want people to master will inform how you present the material & what practice you want engineers to

If you can't come up with a list of skills that you want engineers to take away from the session, you might reconsider your goal. Are you actually trying to help engineers at your company learn a thing?

A few examples of EWBATs:

Many teachers recommend sharing the learning goals with your audience! It's a good way to keep yourself accountable and on track.

I do / we do / you do: Practice is essential

Have you ever watched a lecture, tried to do the thing, and then realized you had no idea what was going on? An hour-long lecture is an awful way to learn how to do something—learning comes when you do the skill.

When you teach something, you want to gradually "release responsibility" to the learner. If you can get the learner to do the thing, they'll be more likely to retain the skill you're trying to teach. If the skill you're teaching involves running commands—get people to run commands! Or try to write some code! Coming up with practice problems is more work than just lecturing about a topic, but it's much more effective.

Sometimes a long lecture is unavoidable, but as much as possible, it’s best to avoid solely lecturing. At the very least, pause regularly and ask questions:

Questions like these not only exercise people's memories and solidifies their knowledge, they're also useful “Checks for Understanding” for you—perhaps you didn't explain things as clearly as you thought you had!

Checking your understanding

This blog-post is like a lecture—I'm not able to ask you questions to see whether I'm explaining things clearly, and we're not able to practice any of this together. It's a bummer! Beause of the medium, I have doubts about how much you'll be able to take away from this.

But here are the important bits:

  1. What skills are you trying to share? Write down a list!
  2. What's your hook? Why should someone care? (If you can't come up with a good hook, maybe it's not actually a good topic!)
  3. Are you giving people opportunities to practice the skills during your session?

If you hit those basics, the learning sessions that you run at your organization will be far better than if you were to set up a PowerPoint and talk for an hour. Good luck!