Eugene Meidinger is a Pluralsight author and teacher of technology, a man after my own heart. He's on the show today to talk about his ksqlDB course in Pluralsight, and really his approach to just teaching things and explaining things. It's really nice to talk to a fellow teacher and dig into how you do that. It's a super important thing, and I was glad to talk to Eugene about it. Before we kick that off, a reminder that Streaming Audio is brought to you by Confluent Developer, that's developer.confluent.io.
Speaking of teaching, there're all kinds of educational resources there, video courses, design patterns, step-by-step hands-on code-based tutorials. Everything you need to get started using Kafka, Confluent Cloud, ksqlDB, thinking about data mesh, data pipelines, whatever it is it's there. When you sign up for Confluent Cloud to do exercises there, use the PODCAST100 code that will get you another $100 of free Confluent Cloud usage. So developer.confluent.io, check it out. And now let's get to the show.
Hello and welcome to another episode of Streaming Audio. I am your host, Tim Berglund and I'm joined in the virtual studio today by Eugene Meidinger. Eugene is an instructor in various places, including I believe Pluralsight. Eugene, welcome to the show.
Hey, thanks for having me. Yeah, it's funny. So I make courses for Pluralsight and I do consulting and over time, more and more of my time's been focused on making those courses. And so it's been an interesting leap having to learn how to teach people this stuff, but also constantly be learning myself. Sometimes I'll have to pick up a technology in the period of two or three months and then train it to other people. So it's interesting for sure.
The dirty secret of the professional technology trainer.
Sometimes you just learned the thing.
So anyway, what we're going to talk about today is, is really how to teach things. It's just a fascinating topic to me. I mean, this episode is about you it's not about me, but just thinking about myself.
I've often said if you boiled away all the other stuff like manager, conference speaker, road warrior, DevRel thinker person, like whatever I am just boil all that stuff away, even just professionally you're left with teacher. And so that's just always close to my heart and I love talking to other people who do it and that you just talking about that transition, you're a consultant, but you find more and more of your time is given over to instructing. If you're a person who's good at teaching, depending upon the kind of consulting that you do, you're probably going to find that teaching crowding out the other stuff, because it's-
... just super valuable if you're good at it. And I wanted to talk to you, to somebody who's had some success about this, just about how you do it. I just want to explore, how do you explain things? How do you teach things? Let's start with what you've done. I know you've got a few courses out there and there's-
... not a problem on Streaming Audio to promote them or to talk about them.
Yeah. Well, I think I've got 10 courses out now and it started out with Power BI, which is a Microsoft reporting technology and that's what I do the consulting on. But at a certain point, the learning path was done and they needed other stuff. So I've had to start learning these things and I thought, well, I'll start digging into maybe data engineering. And so I've done three courses on streaming technologies and it's funny because they've all been different. So the first one was on Azure Event Hubs and then Spark Structured Streaming. And then, a few months ago KSQL and Kafka Streams. And that's how I got here on this podcast.
Yeah. So it's been a little bit all over the place, but more and more, like I said, having to learn how to take something and very quickly put in a format that other people can consume because it's a little bit easier when it's something that you work with every day. Something that you are already maybe speaking on or consulting on or what have you.
Yeah. And there's a difference... And again, this is-
... as the young people say, a mood in other words, relatable, I get this because there's folks who are build just say Kafka, KSQL, Kafka Streams [inaudible 00:04:46]. You're in the trenches every day-
... building an application, you're learning where the bodies are buried.
There's the way things are supposed to work. And then you try to build the thing you're trying to build and it has to fit to your application and there're bugs and the API was built with this use case in mind and you're now this and you get to know the technology intimately by virtue of building things with it.
And you can develop very deep expertise in narrow areas of the technology and that's gold, right? Those people who do that, that's most of the community that I work with. Like you need to be giving talks at meetups about that stuff and conferences because-
Right. The 500 level stuff is always amazing.
Because nobody else can get that information.
Yet there's this, I don't know, we think maybe half a million people a year, it could be a high number. Don't quote me on that. But it's a large number of developers at this point in history trying to get on board with Kafka, trying to learn event driven-architecture every year.
And they're not looking for the 500 level thing. They're looking for somebody who's gifted at giving them the 100 level thing because it's this big scary thing and you don't know what to do with it. So I know that life where-
... you're the one good at explaining things and you're here and that's the knowledge you have to get to people.
Yeah. And that brings up a really good point. You're talking about, well, how do you teach this stuff? One of the most important skills is just this aggressive sense of empathy. And not only that but going through the exercise of actually mapping out who your audience is. Like I know in programming... I'm not a programmer. I dabbled in college and afterward a little bit, but I know there's an idea of making these personas for who's using your application, that sort of thing. And I think it's valuable when you're making a course or you're making training content to not only have a persona in mind but also who isn't your target audience. I think people try to make content for everybody.
But for me, my background coming to Kafka and this event streaming stuff is coming from the life of a former DBA. And to me event architecture, just seems entirely backward. Like this whole immutable idea, like the whole point of a database is an immutable state. What are we doing here?
How does this even work? Yeah.
Yeah. Right, exactly. It just seems strange. And so it can be really helpful to have just this very, very strong sense of empathy, of like, okay, this isn't about me. What is my learner and where are they coming from? Because you talk about those people that know where the bodies are buried and it's really easy to forget how they got there. Or it's really easy to forget that some of these concepts are unintuitive. And so that was a challenge when I was making a course on KSQL, because so much of the content assumed that you already knew all the vernacular for a Kafka and for streaming. It was just this little layer on top that made life easier. And so if you're brand new, it's like, no you're coming out from the other side. You see it as, okay, this is a variant of SQL what's all this Rube Goldberg machine underneath.
Right. You're like, "Okay, I know databases have right ahead logs in them and that looks kind of familiar, but the rest of this, you're not helping me."
And we don't start this podcast with pull quotes if we did at the beginning of what you were just saying there with that aggressive sense of empathy, that would be the pull quote.
That's just, I think a beautiful thing to say and it's a thing that we need to keep in mind as we teach.
Yeah. Well, and I think another thing too is as part of that, trying to find... I try to use a lot of humor and stories and that sort of thing in my training. And I've noticed that with you too, that's something I-
Terrible idea. I never do it. I'm just-
Yeah, no, no, no.
... not a very funny person.
Sorry. Because anything we can do to make this content relatable. I'm trying to remember some of the... Oh, when I did this course, I was given a set of objectives and I had to explain what the heck is a processing topology and how do you explain that for Kafka Streams? And so for my course, I was like, well, how do we explain the idea of these routes and these stops and everything. And so I compared it to a highway and everybody getting onto a bus and how you have these blocking operations, we have to wait for everyone to get on the bus. And at a certain point, once we pass that grace period, we're leaving without your events, we're leaving without your people.
And if you can find these analogies, if you can find these relatable ways, it helps. And the best way to do that is if you can establish a pain. So there's a gentleman, I want to say his name is Dan Meyer. He had a blog that was like, Dan, I can't do the math. It was basically the derivative of Dan, like Dan over DY.
Kind of thing. Right.
D Dan over DT or something.
Yeah. And there's a quote from him that I love so much it's the best way to sell aspirin is to give somebody a headache. And so much of what I do is find a way to give people a headache. Why was Kafka invented in the first place? What was the headache? Why is KSQL a thing? What is the headache? And so, whenever I'm doing any kind of content, I want to establish in the first two minutes this pain point, preferably one that's just this relived pain that they've gone through. It's something very relatable. And then the rest of the course is actually explaining things. But you have to get that hook if you want to maintain people's attempts.
You're so right. The aspirin analogy is good. I'll extend it. I'll say maybe it's more like therapy where like if you have a headache you know you have a headache.
You're not literally giving anybody a headache. They've got the headache. They just don't know it. Like this thing is gnawing at them. The pain is there. They're just covering it. They're not [crosstalk 00:10:57].
Aware of it. And you do have to find that. This is really just the hero's journey applied to education.
You have to start with what hurts you? What are you anxious about? There are things, there are systems you're trying to build without a foundation of events or event-driven architecture. And it's getting hard in some ways and you're a little worried, aren't you? We all are. And by the way, something else you said coming at this from a DBA perspective, that gives you-
... empathy for the DBA and the person who doesn't have access to some of the categories that we take for granted. Just so you know, unless you are deep in functional programming and that is like, you wear the t-shirt.
And that's all your friends and closure is no longer cool enough for you. You're onto something else. You're one of those people. And one of those people are people who are dear friends of mine.
It's weird and scary to developers too. So it's not just a DBA thing.
Okay. That is good to know.
Or deeply counterintuitive. And you have to access that fear and anxiety that they have about a thing that they're trying to do to motivate them to get over this intellectually demanding hump of learning stuff.
So I totally feel you there. We may know Robin Moffitt.
I've seen him around on Twitter for sure.
Yeah. Once and future guest on this podcast and developer advocate, just absolutely star performer.
Confluent, super guy. He's also a DBA. He's not a developer. So he brings that perspective. And I see him addressing things through the lens of DBA empathy that I just wouldn't myself. So totally works.
Yeah. No, that makes a lot of sense.
Okay. So huge common ground here. You're talking about needing a hook, needing to find out what people are afraid of or worried about, and that motivates them to go in. And you don't really need to give them headaches, it's there. You just need to point out this thing hurts.
Well, I think sometimes you may have to get a little bit creative whenever they don't understand why the tool exists. Like that was something that was a challenge for me is like, why is Kafka a thing? Like I don't get it, but there can be adjacent problems that people have run into that they've dealt with that make it click. So one of the things is like this whole idea of decoupling reads and writes. When you think about a normal database it seems a little bit maybe unintuitive, but I don't know if you've ever had to work with SharePoint, but I've had to do SharePoint migrations before and SharePoint does not let you change what database server's pointing to. So literally what you have to do is you have to go onto the server and you have to basically modify DNS but just for SQL. There's something called SQL Config and you have to basically do a DNS repoint just for SQL.
Or if you've ever had to migrate a user application and the connection string is stored on the machine. So you have to go around each and everybody's machine and update it. And that's a pain that I think is very, very relatable. And so you can remind people of oh, migrations are a pain, and then it starts to make more sense why, okay, we might want this intermediary that maybe is adding a certain level of complexity, but allows us to do things much more smoothly that we couldn't do before.
There you go, to explain that decoupling and you start with that, remember when you did that SharePoint admin work when you were young and you needed the money and you don't talk about it. Well, I know it's there.
Right. As a way of relating and putting us all together in a common struggle to build things, and it's hard to build things. So you start there, when you are structuring a course you start with a hook, obviously.
Do you have a process for how you build the rest? Does it just depend on the material? Or how do you go through that?
That's a good question. I'm trying to think how to put this into words, but generally, you want a sense that it's building towards something. At least for me... You'll find a lot of authors everything's sort of personal and idiosyncratic. Like you'll talk to two different authors and one will say, "Oh, I script everything." The other will say, "No, don't script anything at all just free will it." But for me, when I make a course, I try to make it so that the first module is something that in theory you could just skip. It's all fundamentals. It's laying the groundwork. And if you already know this, then you can just skip over that because... There's a great book by, I think it's by Krug it's about user science. It says Rocket Science in the title. I'm sorry. Well, I'm sure we'll have this in the show notes. I'm butchering it but [crosstalk 00:16:13].
Ladies and gentlemen, look in the show notes, it's there.
Yeah. Right. Yeah, exactly. But one of the things that were interesting is there are these heat map studies of how people read the internet and they skim. They jump around. And so I try to make courses that support that.
Right. And so I try to make it so that usually my first module is something that's laying the groundwork and you can skip over it if you need to and that's perfectly fine. But I don't know if there's a huge amount of structure, a lot of it's just, okay, what are my objectives? And what are the things that you're going to need to be able to do first to build off of that. And that's generally the flow that I follow is, I try to have it that each module is covering one or two things that we're trying to get the viewer to be able to do. And so there'll be a mix of slides and demos because at least for me, I find that the way people consume content varies a lot and you want to be able to support that.
So I have a bad habit of sometimes if it's content that's not in my main wheelhouse, I'll have it up on a second monitor just playing in the background. And then if something pops up that gets my attention, then I'll shift my focus. Where if it's like all demos, if it's just pure demos, it's impossible to consume it like that. And so I try to have these points where I resummarize. Here's the core thing. If you walk out of here and you learned nothing else, here's a single slide with a full-color background that says like this sentence, this is what I want you to get.
And so for Kafka, it might be that the power of Kafka is decoupling. Decoupling both in network space between readers and writers, but also decoupling in time. Like you wrote something now and you can read it later. And so the structure tends to be pretty straightforward, but I try to have enough variety both in tone and content and all these things so that I can support a bunch of different modalities for how people consume that content. And that I understand that some people are going to be distracted while they consume it and to not take offense at that. To have a way to manage the person who they're reading Reddit and they have my course playing on the side and I still want them to learn something.
And that goes to repetition and how much statefulness you can assume on the part of the viewer like-
You're building in a module a five-minute explanation of something, you are building, there's stuff you say in the first minute, that's going to matter in the third minute. But to the extent that you can even decouple within the lesson and put in little breadcrumbs of repetition later on that helps the continuous partial attention learner, which is unfortunate. I think devastating-
... consequences for the human mind, et cetera, et cetera. Sorry. It's [inaudible 00:19:19]. It's how we live. You can't fix that problem. You could just try to serve your audience the best-
Right. No, I would love to be able to throw people into a Faraday cage with a downloaded copy of my courses but that's just not the-
... the world we live in, unfortunately.
Yeah. Tempus chamber at your local defense contractor. No electromagnetic radiation in or out.
That's not in fact the world we live in. I've got a question I just thought of that-
... we're not prepared for.
[crosstalk 00:19:54]. I'm ready for it. Hit me.
We'll get there in a minute. I don't want to go there yet. The role of demo, slides, talking head, voice only. You're talking about video instruction of technical content.
When should it be a screencast? When should it be slides? Should you see a person's face ever? What's your take on all that?
Yeah, no, that's interesting. So I think when it comes to the whole being able to see a person's face, I think if you're doing a soft skills course, it's a 100% necessary. If you don't have any demos whatsoever you really, really need to consider that because the problem is that it's really hard to keep people engaged. But in general, I have yet to step into the whole live video piece because there's just so much set up involved. Like I just bought this 4K webcam. I've got a ring light hiding in my closet here-
[crosstalk 00:21:03]. If you are-
... that I'm going to set up at some point.
... an audio version of the podcast, Eugene just showed a boxed ring light.
It was a box with a picture of a ring light on it.
Yes. It has not been unboxed. Thank you for clarifying for the listeners.
Video looks great by the way. You're very well lit right now. It looks like you're facing a window. No problem.
Yeah. And so I think that you have to be aware that there's an added overhead cost post on producing content and editing the content. But if you're doing something with soft skills, I think it's important. Regarding demos versus slides. I think that demos are important for two reasons. So one is to establish credibility. I know at least when I was consuming content. I would want to know that the code actually worked. I don't know, I've attended enough intro to cloud sessions that would list like the five Vs but wouldn't get into any of the meat of anything. And I may not have the trust in the author or the presenter that, okay, does this actually work?
And then the other thing we talked about, having this empathy and having these personas in mind, there are some people that they have a task they need to accomplish at work and they just need to know how to do it. And so I've been in that position. And so for me, that was always beneficial, was like, okay, I just want to skip to the demos. I just need to know how to do it. Good, I was going to say with the whole partial attention thing that you talked about, it can be really, really draining to have a two-hour course that's just all demos. And so I think you have to mix them in there. I've seen stuff like that, but sorry, go ahead.
Well, I think to me, the role... I love the idea of a mix, by the way. To me, the role of the demo is it gives... Well, let me say what it's not okay.
Most of the time in content like what you do on Pluralsight or what we do on Confluent Developer, well, on our courses on Confluent Developer there are intentional hands-on exercises where we give you stuff on the page.
You go make your account and Confluent Cloud and you can copy and paste this and you can do it. And the video is a screencast of somebody doing that. I suppose you're not doing any hands-on component, you're just watching the screencast somebody's actually doing that stuff and it worked because we used computers-
... to do it and it was a thing. And watching it you're not going to really learn how to do that.
And you could attempt to bring in learning styles. Well, I'm an auditory learner I learn by doing so I have to tell. Well, you're a person who is a human and so to actually learn it if it's code, you're going to have to do it. You're almost certainly not going to learn it by watching the screencast. But what I think demos do is they give a sense of possibility and comfort like, okay, I saw it happen. It was kind of in front of my eyes.
I don't remember what to type for everything and what all the ins and outs of the API or the cloud service or whatever it is, but it happened, and I saw it and I remembered some pieces. And I feel like if I had a cheat sheet I could go through that now because there were steps and I saw the steps and that's a thing that's real. So I think they're critical for that. And then if you want someone to actually do the thing, then that's lab or an exercise and their hands are on the keyboard. And it's not really going to land until their hands are on the keyboard.
Yeah. There's a really great instructional design book. There are actually two I can recommend. But one really to this is called Design For How People Learn by Julie Dirksen. And one of the things that are really was helpful for me is she compares a lot of memory and things to your closet and you have these boxes and you have to figure out where stuff goes. And the thing is whenever you're just doing a demo, there's so much information there but nobody's taking the time to tell you which box it goes into.
Like imagine you see a picture of a zebra, okay, is this supposed to go into the box for quadrupeds or things that look like horses or things that are black and white. Whereas so much of the teaching, especially with the slides is curating information, telling people this is the most important. This is helpful. This is entirely optional. And I don't think we do that as much when we're doing demos unless you're doing the really good ones where you have call-outs that come out on screen and reemphasize a point or help identify, okay, this is where your focus should be.
Yeah. I think that's an excellent point. You need to give them, I've always thought of it as a skeleton and early in the lesson-
[crosstalk 00:25:42] scaffolding right. We're laying-
I want to give you that.
... out this structure and then we're letting them hang these bits of information on it.
And that's one of the things I started to understand as I was coming along with my career about paying for training is I am oftentimes paying for that curation and that thoughtfulness, not the content because there's a lot of good stuff on YouTube but you have to like a filter through all the chaff to get there. And sometimes I'd just rather pay somebody 30 bucks or 50 bucks for a book or something that says, okay, here's what you really need to know. Here's the scaffolding that you can then hang on to.
So much rather do that. So final question, wild card. Not in the notes. Ladies and gentlemen, Eugene is not prepared for this. What does it mean to explain? Like what is an explanation do you think? You're a professional explainer so you know, but can you put that into words?
I can try. Yeah. That's a certainly difficult question. I would say that when we try to explain things, we are telling them here's the shape of this idea and then we're doing all this work to ground it in lived experience. Okay. Here's the shape of Kafka, it's like I said, a highway system with these bus stops or it's like in Azure Event Hubs. It's like a sushi conveyor belt and you can take the bits off and they keep going by whether you want to consume them or not. And then we have to find these ways to ground it in things that we already know, or things that we've lived or whatever. It's this curation process where we wipe away all the stuff they don't need and tell them, here's the gist of it. Here's the shape. And here's how we're going to ground into something that you actually care about so that it doesn't just float off into the ether.
My guest today has been Eugene Meidinger. Eugene, thanks for being part of Streaming Audio.
Thank you so much.
And there you have it. Thanks for listening to this episode. Now, some important details before you go. Streaming Audio is brought to you by Confluent Developer, that's developer.confluent.io, a website dedicated to helping you learn Kafka, Confluent, and everything in the broader event streaming ecosystem. We've got free video courses, a library of event-driven architecture design patterns, executable tutorials covering ksqlDB, Kafka streams, and core Kafka APIs. There's even an index of episodes of this podcast. So if you take a course on Confluent Developer, you'll have the chance to use Confluent Cloud. When you sign up, use the code, PODCAST100 to get an extra a hundred dollars of free Confluent Cloud usage.
Anyway, as always, I hope this podcast was helpful to you. If you want to discuss it or ask a question, you can always reach out to me at TL Berglund on Twitter. That's T-L B-E-R-G-L-U-N-D. Or you can leave a comment on the YouTube video if you're watching and not just listening or reach out in our community Slack or forum. Both are linked in the show notes. And while you're at it, please subscribe to our YouTube channel, and to this podcast, wherever fine podcasts are sold. And if you subscribe through Apple Podcast, be sure to leave us a review there. That helps other people discover us, which we think is a good thing. So thanks for your support, and we'll see you next time.
Many of us find ourselves in the position of equipping others to use Apache Kafka® after we’ve gained an understanding of what Kafka is used for. But how do you communicate and teach others event streaming concepts effectively? As a Pluralsight instructor and business intelligence consultant, Eugene Meidinger shares tips for creating consumable training materials for conveying event streaming concepts to developers and IT administrators, who are trying to get on board with Kafka and stream processing.
Eugene’s background as a database administrator (DBA) and immense knowledge of event streaming architecture and data processing shows as he reveals his learnings from years of working with Microsoft Power BI, Azure Event Hubs, data processing, and event streaming with ksqlDB and Kafka Streams.
Eugene mentions the importance of understanding your audience, their pain points, and their questions, such as why was Kafka invented? Why does ksqlDB matter? It also helps to use metaphors where appropriate. For example, when explaining what is processing typology for Kafka Streams, Eugene uses the analogy of a highway where people are getting on a bus as the blocking operations, after the grace period, the bus will leave even without passengers, meaning after the window session, the processor will continue even without events. He also likes to inject a sense of humor in his training and keeps empathy in mind.
Here is the structure that Eugene uses when building courses:
If there's something you want to know about Apache Kafka, Confluent or event streaming, please send us an email with your question and we'll hope to answer it on the next episode of Ask Confluent.Email Us