Go Time – Episode #149

There's a lot to learn about teaching Go

Mat, Jon, Johnny, & Mark

All Episodes

In this episode we dive into teaching Go, asking questions like, “What techniques work well for teaching programming?”, “What role does community play in education?”, and “What are the best ways to improve at Go as a beginner/intermediate/senior dev?”



LinodeOur cloud of choice and the home of Changelog.com. Get started on Linode today with a $100 in free credit. You can find all the details at linode.com/changelog

Pixie – Pixie gives you a magical API to get instant debug data. The best part is this doesn’t involve changing code, there are no manual UIs, and this all lives inside Kubernetes. Pixie lives inside of your platform, harvests all the data that you need, and exposes a bunch of interfaces that you can ping to get the data you need. It’s a programmable edge intelligence platform which captures metrics, traces, logs and events, without any code changes.

Datadog – Do you have an app in production that is slower than you like? Of course you do…is the performance all over the place…sometimes fast, sometimes slow? Do you know why? Well, with Datadog you will. Troubleshoot your app’s performance with end-to-end tracing and in one click correlate those Go traces with related logs and metrics. Use detailed flame graphs to identify bottlenecks and latency in your apps. Start your free trial, install the agent, create a dashboard, and get a free t-shirt! Head to datadog.com/gotime to get started.


📝 Edit Transcript


Play the audio to listen along while you enjoy the transcript. 🎧

Hello, and welcome to GoTime. Today we’re talking about teaching. We’re gonna be exploring this subject with some great and experienced teachers, including Jon Calhoun. Hello, Jon.

Hey, Mat.

How’s it going?

Pretty good, how about you?

Not bad, thanks. We’ve also got Johnny Boursiquot. Hello, Johnny.

Hello! It’s good to be back.

It’s always good to have you here, Johnny.

Thank you.

And also, you know, Mark Bates is here… Hello, Mark.

Hello, Matthew.

How are you, mate?

Yeah, I’m doing alright. How are you doing?

Yeah, not bad, not bad. I’m excited about this episode, because I feel like there’s a lot to this subject.

I think what you’re looking for is there’s a lot to learn about teaching.

There we go… Beautifully put. Thank you very much.

Thank you. I think I stole if off a Bazooka Joe gum wrapper… [laughter]

That is a reference I get.

I haven’t had one of those in forever.

I know. Are they still around?

Halloween coming around, I’m like “I need to go somewhere and find some Bazooka Joe.”

They are still around. My kids had some recently, and they haven’t gotten any softer. [laughter] I’ll tell you that much…

Okay, so maybe we could start off by a little bit of an intro, because I don’t know that our listeners really know how much experience you all have in teaching… So how did you get into teaching and what sort of teaching do you each do? Bates, we’ll start with you, mate.

Yeah, I have a feeling that the three of us do very different styles of teaching, which is gonna be fun obviously to talk about today. For me, I first started getting into it with writing books, about ten years or so ago… And then about three or four years ago I met Cory, and Brian Ketelsen… And we were talking about training and thinking about doing something together, and we started Gopher Guides.

[04:22] For me, my experience with training has been a lot of in-person, in a classroom, three days, four days, teaching. Not a traditional teaching style, but the in-classroom teaching. And then even last year we started to do a lot of virtual training, so of course, this year now we’re doing nothing but virtual trainings…

So that’s my experience - it comes from doing workshops and in-person teaching, virtual teaching, with the big groups and dynamics, and somewhat to the book stuff early on that led me into it.

Yeah. And Johnny, you do classroom-based teaching sometimes too, don’t you?

Yeah, my journey is an interesting one. A lot of the teaching I was exposed to came from being part of workshops that were aimed at teaching programming to beginners, right? So think RailsBridge, and GoBridge, and these kind of things… So basically at first I’d go and I’d participate as a TA, and help students and whatnot. Then eventually you start picking up enough of how people learn, the different styles of learning… There are folks who can just hear something, and internalize it, and know what to do. There are folks who hear it, but it doesn’t really stick until they actually try something and do it… You see all these kinds of very different learning styles: auditory learners, visual learners, all these kinds of things… And that’s when it dawned on me that “Hey, I seem to have the ability to tailor things for the different learners.”

So I wasn’t trying to learn how to teach, I just wanted to help… But okay, you’re able to convey certain information differently to different folks in the audience, so that everybody walks out satisfied with their journey, with their learning process. And the biggest thing is knowing how to leave enough of a spark there, so that when they leave the workshop, they can continue the learning on their own.

So it became this thing that I eventually also started doing professionally, not just as a hobby or a way of giving back. It became a professional kind of thing. I do other things now in that realm, but it just so happens that it wasn’t something I really wanted to get into.

That’s interesting you talk about the different people learning in different ways, because – I mean, how do you do that? How can you create a course or something that is tailored to these different–

Could I just say, before we get into the one-size-fits-all metaphor and the deep topics - can we hear from Jon, see how Jon got into learning?

I know, right? Jon.

Mat doesn’t wanna hear from me. It’s okay.

Mat’s like “Forget Jon.” [laughter]

I was gonna get to that in a minute.

I have faith in Mat.

Well, Jon, you don’t do classroom-based teaching as much, do you? You have video courses. So that is quite different.

Yeah, mine was – when I started learning Go, I realized that there weren’t any resources like… Like, Rails tutorials is how I learned Ruby on Rails, and I really liked that project-based book, or video course, or whatever; it ends up being both if you want, but… I really liked that approach, and when I was learning Go, they didn’t have it, so I basically just started taking notes with my journey, and I got to a point where I was like “I should probably turn this into something and share it with people and try to create something similar.”

And then it just happened to be that the startup I was working at was in some rough times, and it made more sense for me to just branch out and see how that went. So at first, I started doing consulting and teaching, with the two sort of augmenting each other, but it didn’t take very long until I’ve actually found a place where I was living off of just the teaching income, so that’s what I kind of focused on.

[08:14] It’s been a lot more fun; it’s really rewarding to see people get stuff and to take a different approach. It’s kind of interesting to me, because I see the benefit in having all these different styles put together, and I really feel like - and I’m hoping as a result of Covid we start to see all of these sort of get merged together, and find ways to find the best of both worlds… Because up until now, I just don’t feel like that’s happened. But we can go into the one-size-fits-all discussion first, that’s completely fine. Or, Mat, do you wanna talk about your teaching experience?

See, Mat’s making that face like he doesn’t think he’s a teacher, but we all know he is.

Even better, he just farted. Go on. [laughter] It’s a very similar face with that.

I’m gonna have to ban you for that, I’m afraid, mate… Well, yeah, I’ve done it at conferences and stuff. Sometimes at conferences you get asked to do a workshop or something, but I haven’t done that very often. One thing I’ll say is it’s absolutely exhausting… And that shocked me, of how draining it actually is to do teaching. Did you find the same thing?

It’s exhausting.

Yeah, absolutely.

It’s funny, because like both Jon and Johnny, I used to do the TA, and then the RailsBridge… In fact, Johnny, I think you and I might have even taught a couple together over the years [unintelligible 00:09:36.19]

Yeah, I’m sure…

And I did obviously the video stuff, which I still do, and I had Metacast, which was those kind of bite-size snippets for a long time… So there’s a lot of different ways you can learn, but overall, regardless of how you’re doing it, it’s still very daunting and still challenging. And when you’ve got a classroom full of people… I know for me if I’m at a corporate client for 3-4 days and I’m standing there for eight hours a day, training and being energetic and motivating and accessible, and all those things you need to be to be a good teacher, it’s exhausting. I go back to the hotel room and I lay on the bed and I pass out. That’s it, that’s my night. My night is I go back to the hotel room, order room service and I just watch TV until I fall asleep, because I’m so drained from that day.

Yeah. Why does this sound like an alibi? [laughter]

It very well could be. No, here’s one thing I’ll add on top of that - the funny thing is most folks think that to be a teacher you kind of have to be naturally outgoing, have the personality that brings out people from their self-contained personality types, and that kind of thing… But it’s really not. I know for me - I wouldn’t say I’m an extrovert… I have little spikes; so when I’m teaching, I have to literally – almost like flipping a switch in my mind, that says “Okay, now you need to be someone else.”

You need to be energetic, and motivating, and exciting.

Exactly. Literally, you have to flip that switch that says “Okay, now it’s no longer about you. You’d normally like to be introverted, and have your own space, and have quiet, and all these things… But this is not what you’re about to do now.” So you literally have to change and become someone else in order to do that.

Obviously, the more time you spend doing it, the more experienced you are, the more naturally that comes… But it is not an easy thing at all to put yourself in the right mindset to do it.

It’s not, and I have the exact same problem. I’m famously what I call an extroverted introvert, where I’m almost always introverted, but I have spikes, like Johnny said, when I’m doing something like this, or I’m teaching, or I’m at a conference. You see me at a much higher level of activity; I’m much more outgoing and energetic than when you see me offline, when I’m just kind of quiet, sitting in the room and just relaxing. But you do have to put yourself in that mindset, and that’s the daunting and exhausting part, at least for me anyway.

Is it like a persona then? Do you feel like you have a different persona when you – do you feel like you become someone else to do it?

[12:18] A little bit… I don’t know, I think we all have personas when we hit the stage… And whether that stage is a classroom, or in front of a thousand people, or at GopherCon, or something. When we’re in front of an audience, we all have a persona, whether you admit to having a persona or not. We’re all just a little bit different, and we all tweak ourselves slightly different just to be up on that stage… And that goes for just speakers, too; we’re also educators. We shouldn’t discount those who give 30-minute talks, 45-minute talks at conferences. They’re also educators, and we could talk about what it means to be that sort of an educator at some point too, which would be kind of fun.

In some regards I’m also curious to hear from Jon about this, because I’ve been fortunate enough to have done the face-to-face, I have done the online, and I think the worst possible combination of all these things is when you have to do virtual training, where there are no faces, there’s no cameras. You can’t see, you can’t tell that somebody’s getting something or not the way you can in a live classroom. These are the absolute worst for me. And I power through them, but they are my least favorite, when there’s no cameras and you can’t see anybody. You’re just a voice on the other end.

But it’s a slightly different thing perhaps with Jon. Maybe you’re doing a screencast, and you’re putting together a video… I’ve done those; you can give yourself a bit more – you can forgive yourself a little more, because you know that if you have a bad take, you can record it again… And I know you’ve done this with Metacasts as well.

So I’m curious, Jon, do you feel like you have to become someone else, a different personality when you’re doing the screencasts and the recordings?

It’s definitely there some. I remember one piece of feedback… I don’t even think it was that long ago, but somebody basically made the comment that my writing felt way more energetic than this one video that they watched… And it was like the very first video I’d released for one of the older courses. And those older ones - I really did not quite get that transition; I didn’t know how to do it. Even now it’s something I struggle with, because I’m not interacting with people as much, so a lot of it feels – I feel like I’m a random person on YouTube that’s crazy high-energy. And I know I’m nowhere near that level, but it just feels so weird to me, because I’m like “That’s not me at all.” So it’s kind of challenging.

And you’re definitely right that it is hard, because you don’t get that immediate feedback… So I can’t go do a workshop and then come back and be like “Okay, that worked. That was the right energy level.” It’s literally just release some videos and hope that it’s right. And I do occasionally get that feedback, but it’s probably not as immediate. Maybe people are more forgiving, because it’s a recorded thing and they just kind of realize that’s the way it works, I don’t really know. Maybe that’s why I’ve got the really bright colors in the background, that’ll brighten me up and make me seem energetic…

Yeah, I think a lot of people just don’t know how hard it is to do video, like Jon does… I used to do it with Metacast. There’s a lot that goes into that… You know, that idea of a) just having to come up with fresh content constantly is very difficult. But then that energy level, and that “How do I get this concept across to nobody?” It’s not even like a virtual training, where at least you know there are people on the other end to hear your words. You’re recording and you don’t have that, and you really have to pretend, like “What is this audience that I’m talking to? Who are these people? What do they wanna hear? What are they reacting to in this video?” It’s really hard. That’s why I stopped doing it… [laughter]

[15:52] I think people also forget for every ten minutes you see, there was probably like three hours of all sorts of other stuff, including bad takes… I’ve literally sat there one morning and spent three hours trying to record the same 15-minute video… And I’m just like “This isn’t happening. I don’t know why, it’s just not happening today.” And it’s so frustrating.

Meanwhile, you’ve got people like “When is that gonna be out?” and you’re like “I’d love to give it to you, but it’s not there.”

It’s frustrating when you’re doing a really, really good take too, and something doesn’t work. Like there’s a bug… And if I refresh, nothing happens; everything’s broken. Okay…! Hit stop, let me back up… What the hell just happened…? And then you’ve gotta get everything back in the same place in terms of your screen… Because you know, if I move to the browser, I have to get back to my editor, make sure the cursors are in the right place and everything lines up again… It’s a real struggle when you hit those things. At least live you can make a joke about it and move on…

Keep it moving, yeah.

Yeah. There’s that, too. I’m curious, has everybody else done virtual conference talks this year?

Yeah, I haven’t given one, but…

Jon, you haven’t. But Johnny, you have, right?

It’s been interesting… You know, we’re all having to do these virtual talks… And Johnny, you were talking about the energy. I’ve had a couple conferences this year request that we pre-record our talks, as opposed to giving them live… Because you know, it’s a virtual world, they can do whatever the hell they want. And I’ll tell you, I hated it. I did it once, and I really, really hated prerecording my talk.


The energy. I’m standing there in an empty room, talking to nobody, and I can hit record as many times as I need to. There’s no spontaneity there, there’s no energy, there’s no nervous energy that kicks you up a bit… So even knowing that people are virtually listening on the other side, even if I can’t see their faces, that nervous energy of just knowing that my words are being heard, and my face is being seen, I have to kind of be on my game. Yeah, that’s one of the biggest problems I’ve been finding with the virtual, is that energy.

And then what Johnny said, the feeding back. I scan the crowd; you’ve gotta scan when you’re teaching. If you’re not constantly scanning your audience and looking for people in trouble, then that’s – you’re not doing it right. You’re not doing your job right.

Right. One of the worst things is – normally, in regular conversations, there’s opportunities for impromptu jokes, and a little banter, that kind of thing… And I find that these things work their way into my teaching as well. Something will happen, it’s unscripted and it’s natural, it feels authentic, there’ll be opportunities for a joke, or something like that… You can kind of play with these things.

If you’re inexperienced, these things feel like “Oh my God, something bad just happened.” But the experienced speakers, they actually turn these around and use them to their advantage. That sort of skill – you can’t use any of that skill or any of these moments when you’re doing a prerecorded thing. Imagine having a joke on a prerecorded talk - how weird is that? So you have to imagine in your head–

I’ve done it. [laughter]

Did you add a laugh track as well?

No, but here’s how sad I am - I paused for the laugh.

Mm-hm… Yup.

I just took a breath, let the laugh happen, and then you continue.

Yeah, you can pause for laughter…

Yeah, but it shouldn’t be like two minutes, Mark. You’re not getting a standing ovation after every joke.

That’s true. Admittedly, the last conference talk, I did. I did wait for the standing ovation, and I did keep telling people to calm down, and just relax… It was mayhem.

[19:57] Oh, that’s great.

But like Johnny said, those jokes – I’ll tell you, one of the biggest things for us at Gopher Guides… Like, when we’re doing the in-person stuff we don’t have this opportunity with the virtual nearly as much, because of what Jon said, and Johnny (and everybody’s kind of saying that), that lack of interaction. When we’re in classrooms, or we’re at companies and we’ve got 20-30 people in a room or whatever it is, you’re talking, you’re having lunch, you’re learning about them as people, as individuals, as a company… And there’s a lot of stuff you – I like to take some of those in-jokes from them, and incorporate it back in; like some of what they’re working on.

If I’m trying to come up with an off-the-cuff kind of an example to describe something, if somebody had a question or whatever, I try to use their experiences. If it’s Uber, which we’ve done a ton of training for…

Other car shares are available… Sorry, carry on. [laughter]

Yes… But you know, I’ll use self-driving cars a lot as examples, because that’s the group I was doing a lot of training for… And using those examples – because they understand them, and they can relate to those things.

But the other big thing that you don’t get virtually for us was the in-class demos. I love doing live demos in class, and Johnny, I’m sure you have the exact same thing, right?

Someone asks that question, and you’re like “Oh, let me just open up Vim. Let’s code it, let’s see what happens.” And what’s interesting that we’ve found is that every single class we’ve done over the last 3+ years, we’ve taken some of what we’ve done in class as demos or discussions, and it’s been incorporated back into the training material, usually that night or the following week.

But you need that face-to-face, you need those questions, that spontaneity of someone just raising their hand - not even raising their hand, just shouting it out - that you don’t get over virtual. It’s just been tough.

So we’ve talked a little bit about what’s bad about the virtual… Have there been any positives to it?

No travel…

No travel is huge.

And maybe it’s a little bit different, depending on what you’re doing… But I know from my end, one of the things I really like about doing videos, despite that there are definitely some drawbacks - it’s the fact that you have this massive reach, in comparison…

[23:52] So rather than spending six months traveling, I can spend six months like “How do I really refine this challenging topic and make a much more involved project?” And then the second part for me has always been that the amount – like you said, it’s exhausting to teach in-person workshops, so realistically, you couldn’t go someplace and teach for a month. That would just kill you.

It’d be too much, yeah. I mean, teachers do it every day. Let’s not discount what – all of our teachers - and God help them - they’re all doing virtual right now. So kudos to every teacher in the world right now who’s having to deal with all this… But yeah, go on. I couldn’t do it for a month, let’s put it that way. [laughs]

But basically, you can make bigger projects and teach them in the online venue, because you kind of know that people have that chance to take breaks themselves when they need them, you don’t have to produce it all at once… Are there other advantages you’ve noticed to doing the virtual stuff?

I’ve found that instead of doing big 8-hour days when we’re doing in-person, we’ve scaled it back so we do more days at less hours… Because as we’ve all come to learn this year, some more than others, sitting in front of Zoom for eight hours a day is a real drag, and it’s really energy-sapping, and it could be so hard on you.

So we’ve kind of moved into these four-hour blocks, with nice breaks… And people need that. They can’t sit in front of a computer. But we’ve found that’s working very well; people are engaged for that time, and they’re active, and then they have the rest of their day to do their regular work, and stuff like that. So for us, the virtual has actually been quite nice. Our platform was kind of built for it anyway…

But what I miss personally, like I said, is that interaction, that face-to-face, that one-on-one… Which is odd, because I hate people. [laughter]

I tried to simulate that with a Slack community, but it’s still – I know it’s not the same, but it’s one of those things where you do get the feedback from people, like “Oh, I’m on this video, and this is the challenging thing I’ve ran into”, and you can incorporate that into future lessons, or you can give examples there… So there are ways.

I imagine with corporate training that’s trickier, in the sense that you can’t bring up a Slack and be like “This is your corporate Slack for just this thing.” Maybe you can make a channel, but even then that’s kind of hard.

Yeah, you usually have to use it. Usually they have Slack, we’ve found, or stuff like that, as a back-channel…

Sorry, I need to just say that other annoying apps are also available.

That’s true.

Not just Slack.

Not just Slack.

Not just Slack… You know, Zoom. We’ve also sometimes just used the chat in Zoom, or whatever platform we’re using, too. When you’re doing the live training, that kind of offline community isn’t as important… Certainly when you’re in the room. But virtually, you definitely need a way for people to funnel… And Zoom’s got the webinar features, with the raising your hands, and asking questions, and polling… So there’s some decent stuff built-in for reaching, and that can be quite helpful there. But like I said, having an interaction is really hard over Zoom.

Is there anything specific about teaching Go? Because I know, Bates, you did Ruby training, and things. Does Go’s minimalist design make teaching easier? Is it easier because Go has this smaller API, generally, in the language?

Go is simple, that’s what’s so nice about. I think that’s why we all like Go. I often joke in class that Go is kind of a WYSIWYG language… What you see is what you get. You look at a Go file and there’s no magic there; the imports are at the top, there’s all your stuff… There’s not a lot going on. There’s not that crazy meta-programming that you get with dynamic languages.

[27:53] When I was doing Ruby - and Johnny definitely can attest to this - you’re trying to mentor junior developers at work, and stuff like that… And there’s a million ways to do anything, and none of them are necessarily easy or make total sense. But a language like Go, where it’s very clean, and easy to read, and it’s optimized for reading - I think that makes it a lot easier to teach. I think the fundamentals are so much easier to teach in Go than a lot of other languages, to be perfectly honest. That’s my opinion.

Johnny, I think you said you taught Ruby stuff, too. I could be wrong though…

Did either of you run into cases where you’re teaching and somebody’s like “That goes against our style guide, how we do these things”?

All the time.

Oh, boy, I’ve got stories for you.

All the time.

And here’s the thing. Currently, I do trainings on platforms like [unintelligible 00:28:47.28] but also I do the private corporate stuff… And the private, corporate stuff, I tell you, it’s the one that has folks coming to it with the strongest held views and beliefs about style guide, and approaches, and this and that… So I feel like I spend about a third of the class - if I look at the amount of time I spend sort of saying “Well, this is like C, but different in that way. This is like C++, but different in THAT way. This is like Java, but different in that way. Don’t name your interfaces with an i in front, because we don’t do that.” All these kinds of things… I’m basically spending my time getting them to leave the baggage at the door, so that they can appreciate Go for what Go is, rather than saying “Well, I have this way of doing OO in my head. How do I do that in Go?” No. You don’t just overlay that knowledge on top of Go… Which is why I think as a teacher you have to know how to relate things that folks coming from other languages and other technologies might already know… Because they’re gonna come in the door with that knowledge. You have to somehow reframe it.

At the same time, as a learner - and I can’t say this often enough - you have to leave that baggage about all other languages that you know and love at the door when you come to learn Go. You have to really learn Go for what it is, and then have your preferences and your judgment, and “Oh, it’s better at this/worst at that”, or whatever it is. Leave that stuff at the door.

Yeah, that’s a really tricky thing to balance… Because I know exactly what you’re saying; I’ll often say “This is kind of akin to this in Java”, or Ruby, or whatever I can try to make some comparisons, hopefully to languages they know in the room… And that hopefully I also know, that I can use to relate… [laughs] But at the same point, a thing I always tell people is don’t code Go like Ruby, don’t code Go like Java… And also, don’t code Ruby like Go, don’t code Java like C. These things carry across all languages, but you do have to keep reiterating that in class.

A lot of people come at you and say “I would do this in C# like this”, and it’s like “Well, that’s C#. We don’t do that in Go. That’s not a thing in Go.” “But how do I do it?” You don’t. You don’t need to do it in Go; it’s not a concept in Go. “Yeah, but I need to do it in C.” But you don’t need to do it in Go! It’s like, how do you get people sometimes past those things, like “I know how to do it in this language”? It’s hard.

You’re not swapping syntax. This is not just a syntax swap, right? It’s a different way of thinking, it’s not a syntax swap.

Yeah, exactly. I once saw somebody code – and this still blows my mind a little bit, because I would never contemplate doing it… But I saw it and it just blew my mind that somebody did this. They wrote a try-catch mechanism in Go. [laughter]

With panics.

Yeah, with panics, and…


[32:01] …recovers, and stuff like that… And it was both remarkably beautiful and terrible at the same time. [laughter] It was in a package called Structs, which was even better… [laughter]

Because that’s where you put exception handling, clearly… [laughter]

That’s where you put exception handling! And so it’s a clear case of somebody saying “I need this. This is how I know how to code. I only know how to code with try-catch and finally”, and that’s what they built. They built a system that allowed them to do try-catch and finally, because that’s how they know how to code… And the idea of error handling in Go just made no sense to them.

Yeah. Breaking people of previous habits is really hard…

It’s hard, it’s hard.

One of the things I’ve found there is that when people ask “This is how I do it in C”, sometimes it’s more about trying to figure out what’s the underlying problem that you’re trying to solve, so we can look at what is the correct approach to take in this other mindset… And that can be very hard, because sometimes people come at you with just “No, I just wanna do the same thing.” And other times they’re like “No, I’m actually trying to solve a problem”, but they don’t ask that question. They ask “How do I do this other thing?” and you’re like “Well, let’s take a step back.”

I know that can be challenging, because we see this on the Gophers Slack all the time, where beginners ask that and you try to say “Well, what problem are you solving?” and they don’t know why you’re asking that. And then when they finally get it it’s awesome, but up until then you almost sound like that jerk who’s just like “No, I won’t answer that question. You need to give me a different question.”

You’ve gotta pull it out of them sometimes. You’ve gotta pull up that problem, definitely. And there’s some people who just want that answer… And it’s funny, there’s always those people - and they’re the people hung up on that syntax; they’re the people hung up on their way of knowing… But when you keep telling them that’s not a thing you do in Go, that’s not an issue in Go…

I’ll often say “I’ve been programming Go for seven years now, and I’ve never had to do that. That has never come up”, whatever the thing is. And they’re like “But how would you do it?” I’m like, “I don’t know, it’s never come up. This is truly a non-issue.” [laughter] But you’ve gotta try to answer that as best you can, though it’s not always easy.

Yeah. So if we could turn that then into a piece of advice for someone that’s gonna learn Go, and maybe they do come from a different language, I guess that advice is that you have to be open-minded… And you’re never gonna do away with everything you’ve learned, especially because people invest years and get really good.

I used to do C#… I’ve built some amazing, abstract class hierarchies and all sorts of things with abstract classes, with generics… In C# with the generics you can put constraints on the types that you’re allowed… They can be interfaces, or they can be base classes, and things… And I felt like I’d become really good at that. So in a way, we’re asking people to sort of – you say “Leave the baggage”, but that baggage is valuable to them. They’ve invested a lot in that, haven’t they?

Context though… I mean, you have to have context. Certain skills are gonna be more valuable in certain contexts than in others… Again, going back to what kinds of problems are you solving, and what problem domain are you working in… Is this tool better suited for this kind of problem? All these virtues that we as software engineers aspire to - did I use the right tool for the job? Craftspersonship, and stuff like that. We aspire to all these things, except when it comes to our fair programming language. We feel the need to defend, “Well, Java does things the right way. I like the way it does things. Why can’t I do the same as in Java?” Well, this is not Gava, this is not Guby, this is not Gython… This is Go. So learn that tool.

[35:58] But I will admit, I’m gonna get off the soapbox for a little bit… I will admit that it’s not unrealistic to say that the language you’ve been trained to use or learned to use for years and years and years has shaped the way to think about problems.


It’s not realistic to say. So naturally, you’re presented with a problem. You want to solve the problem, but the tools you have, the facilities you have in your mind are still contextualized for the previous language you were using. So the people who jump from language to language to language - I’m sure we’ve all done this, because we all work in multiple languages these days… You’ll swap your editor, and you’ll start to type Go inside of your TypeScript, or your JavaScript, and then you’re like “What am I doing?” Or you’ll switch to VS Code where you have your Go code and start typing TypeScript. You’re kind of jumping around.

But I think those who have to work in these multiple environments, multiple languages, are in a much better position and have the ability to change their thinking at will… To say “Okay, for this particular problem, this language solves it this way.” Whereby if the only thing you’ll ever – sort of the one hammer you have, it’s Java, or it’s C#, or it’s C++ or whatever it is, you’re gonna try to hammer every nail with it, right? So again, one of those things where we basically tell ourselves in the software engineering community “Hey, use the right tool for the job.” Well, if we’re gonna say that, let’s apply it across the board.

It’s funny on this, because I do write JavaScript and TypeScript as part of my day job at the moment, and I actually do feel like I’ve taken lessons from Go, and I do apply them actually… Because it’s simpler. Because Go is simpler, I feel like you can almost do it that way. For example, there’s loads of language features in JavaScript and TypeScript that I just don’t use, and I’ll just write very simple, little functions… It has actually changed the way I write JavaScript, too.

You could be seen as being not proficient enough though… Again, it’s one of those things where somebody who’s an expert JavaScript developer, or they really know TypeScript inside and out… And they see your code, they think “Oh, you’re just a novice. You’re not using these super-duper elegant mechanisms, this special, esoteric knowledge about the language that I happen to know because I have dozens of years of experience in that thing.” They’re gonna see you as a novice… Whereby you’re trying to keep things simple. But they see it as a lack of knowledge.

That’s interesting, yeah… I even do it in Go, because I don’t really use channels very often these days in Go, for example…

Neither do I. I very rarely have ever used channels, to be perfectly honest… As a matter of fact, one of the things when we teach channels - we have a slide at the beginning, and there’s a couple quotes; Mat, one of them is from you…

Oh, dear…

…which was…

Cut out Bates.

I can’t remember what your quote was, but it was about not using channels. I can’t remember what it is now. But Cory said “I find that once I – you know, I’ll start using channels, and about at the end I ended up refactoring them out anyway.”


That’s part of the learning experience though… Sometimes overusing mechanisms when you first start learning a language.

Yeah… What concepts in Go are in your experience then particularly troublesome for people? You mentioned errors earlier…

Interfaces, I’ve found, have been one of the biggest struggles in class. People really struggle with how interfaces work in Go. Everything else – we can talk about channels and people would get it; I can talk about goroutines and people would get it… All this sort of stuff. But when I start talking about interfaces, people are like “Wait a minute… I don’t get it.”

Right… Is that because they have already this previous knowledge, and they know how interfaces work?

[40:08] Yeah, where’s the implements IPersonal or something, right?

I think people are just so used to that–

[unintelligible 00:40:13.11]

Right… [laughter]

Interfaces are definitely weird, in the sense that you’re expecting them to follow a certain paradigm that usually comes from like a Java, or something like that, where you return the interface… It’s not the same as Go, where it’s like, when you write the implementation you don’t mention the interface at all. And they’re like “How is this related? You didn’t even mention the thing.”

How are you connecting those dots? Yeah, if it’s not in the code, how do you know? It’s magic. I don’t like magic.

And it is confusing.

It is. Well, I always say it’s implicit versus explicit. We don’t have to say “foo implements bar”, it just does. And then people are always like “But how do you know it does?” I’m like, “It just does.” They’re like, “But how do I know that my thing implements it?” It’s like, well, you look at the function definition you’re trying to call, and it says “I need an ioWriter.” You look at the doc for an io.Writer, and “Hey, my thing happens to implement that. Fantastic.” But people don’t get those two things.

And the big question I get a lot, too - as I’m sure you guys - is “Well, how do I know if I’m not implementing some other interface?”


Well, who cares?! Who cares if you are?

Right, yes.

It could be, it doesn’t really matter.

Yeah, that’s true. I remember that exact thought, like “What happens if by accident I happen to just match the method on signature for something else, and then it gets abused, or it gets used in the wrong way?” But it just doesn’t happen. And because of the simplicity… For example, you can’t have overloaded methods. In some languages you can have the same method name, but with different arguments. And Go doesn’t let you do that. So yeah, it feels at the beginning like that’s constraining you, and it feels like “Well, they need to add that feature.” But actually, it pays dividends when it comes to maintainability, readability and clarity, doesn’t it?

But those are abstract concepts you’re talking about here. These are things that are subjective. Readability - what you find readable may be not so readable for me. So it’s hard to get someone who’s very used to seeing a certain style of code and attribute their own idioms for what readable code in that other technology that they know and love is… Basically applying that and saying “Well, that’s what readable code is supposed to look like.” It’s very hard to carry all that stuff over to Go. It’s almost like you have to relearn “Okay, what does readable– at its core, what is readability all about?” You have to get to that underlying level.

I’ll tell you, in a class of eight hours, you’re not gonna have time to talk about the theory of the readability, what’s readable, what’s not - you don’t have time for that. You’re trying to cram as much information in people’s heads as possible, in as efficient a manner as possible, so that they can retain all of that knowledge you’re dumping on them in such a short amount of time. You don’t have time to dive into the theory, you have to get to the practical. But the thing is, without the theory to understand how to approach the language, then it becomes hard to say “Well, trust me - I’ve been doing Go for a long time. You’re not gonna run into this particular problem you keep telling me about right now.”

Changing topics – Mat, sorry; allow me to take over hosting here for a second…

Please do, mate… Please do.

A lot of people have been asking, what would we recommend for people who want to learn how to write Go? What ways of teaching, or what ways of self-learning I think is really the question that we’ve been getting on Twitter and Slack. “How do I best self-learn Go?” And I’m curious to hear – because again, I think we’ve all taught Go in very different ways… Some of us in multiple ways, whether it be books, blogs, videos, workshops, in-person, virtual, podcasts, conference talks… There’s a lot of ways we have taught Go, but I’m curious to hear how everybody on the panel here would – people would suggest to people who are learning Go, what are some great ways for approaching it.

I can say the number one piece of advice I have for people is to not just follow along… Whether you’re in a workshop, or you’re doing a course, or whatever else, if you just follow along with the material there and that’s it, it doesn’t stick. But if you take the material there and you try to slightly change it… Let’s say Johnny’s teaching something and he’s like “This is how we create a channel, and we send some values through it”, and they try to maybe create a buffered channel, or they create a channel of a different type, or they mess around with it a little bit and experiment and try to get a feel for what these different things do - those people tend to have a much better understanding of how it works… And sometimes you’ll write code that just doesn’t work, and you don’t quite get it, and then all of a sudden you have a question to ask. You can say “Why doesn’t this work? I apparently didn’t understand it as well as I thought.”

And even for courses, it’s really hard, because some people just wanna follow along with the tutorial, or a course, or whatever, and at the end they’ve built a thing. But really, the value doesn’t come from building a thing, it comes from “Okay, can I use this tutorial to build something sort of similar, but not the same. Far enough away that I’m gonna learn some stuff along the way.” And those people tend to be the ones who get the most value out of reading tutorials, or courses, or workshops, or whatever else. So that’s the biggest piece of advice I’d give to people - you need to be doing more than just following along.

Yeah. And to add to that, don’t copy and paste the code from the browser into your editor.

No. Type it in. Type, it, in.

Hand-type it. Hand-type that code. It’s muscle memory, and you will learn the code so much easier. If you just copy-paste it, you’re not learning anything; you’re just moving on. Spend the time, hand-type it. It’s painful, but it’s awful. But no, those are really good points.

The hand-typing is one of the things I loved about physical books - there was no copy-paste. It’s like, “Good luck, buddy.”

[laughs] Forcing you to do it… Yeah, there’s truth to that. But interestingly enough, the other day I ran a quick Twitter poll, obviously limited to my audience and my reach and whatnot… But of the folks who follow me, pretty much mostly, 90% of them are technologists, and engineers in some way… I wanted to find out how they learned technical content. And the options I had on there were like video, blogs, documentation or something like that… But basically not the kind of content, but the medium; what medium do they use to learn.

[48:07] I was expecting video to be the runaway winner. It actually ended up being a nice distribution across all the different mediums, including reading (the long way), watching videos, reading tutorials and how-to’s, and having a live training, that kind of thing… Again, reinforcing the idea that different people learn in different ways. But in the comments, what I was getting - there was like an underlying thread there.

What I was getting was that many folks need a combination of mediums to reinforce their learning. And I saw myself in that group, because literally, if I’m trying to learn a topic, I will get the video on Udemy, I will buy the book on Amazon, I will find a live training workshop to attend… Basically, I’m approaching it in almost like a 360 style, because I’m gonna get something from one of these instructors or teachers that I’m not gonna get from the other one. So I’ll try to get myself like a complete 360 degree sort of knowledge even before I jump in to start actually writing code.

I’m not sure what you call these kinds of learners, but I spend a lot of time gathering knowledge before I start to apply anything… And again, that might be slightly different from the typical recommendation to “Hey, learn it, apply it, type it” and whatnot… Some learners, like myself - we like to gather a lot of knowledge before we start applying it… But it’s a different mechanism of knowledge acquisition.

Yeah. See, I’m the opposite of that, because what I’ll do is I’ll start to build something. And I use that almost to guide my learning.

That’s what I do.

Yeah. Also, Mat, you mentioned Amazon - I should just say, other tax-dodging megastores are also available.

Right. [laughs]

I am a bit more like Mat. I like to start with a practical problem. I struggle reading thick textbooks… That’s just never been my forte. When I first started programming, that’s all we had. In the mid’ or late ‘90s there wasn’t a lot of online video courses and tutorials. You got a book at the store and you hoped that it was up to date. But I like the practical approach. I need to have a problem that needs some solving. Then I start working with it and investigating it.

Often, if I have a big project I’m working on for a client or something, often there’s a piece of it - “Oh, I’ve never done this before.” Or maybe there’s a new API I need to work with, or a library that I’m gonna have to work with… So I’ll just open up a simple, main, basic project, and I’ll start just a rudimentary playing with it in there; I’ll pull up docs, and I’ll watch some videos, and I’ll read some blog posts… Until I get something that is actually working, and that’s simplistic, almost linear, serialized programming top to bottom, just to get it work. That’s how I learn. I need to physically be in the problem to get the education out of it.

There’s an interesting dynamic going here I’m wondering if teachers feel the need, or if some teachers feel the need to get enough of a complete, broad set of knowledge, but then they advise their students to not learn in that way. They advise their learners to actually get the hands on, rather than try to acquire all the knowledge first… Because that’s part of my reasoning. That’s why I try to acquire as much knowledge as possible… Because only then do I feel comfortable telling somebody “This is what you should learn and how you should learn it.” Because I feel the need to know enough about a topic. I feel the need to develop expertise on a topic before I can then pretend to be a teacher for that thing.

[52:00] Oh, if we’re talking about teaching, versus learning - absolutely. I’m not gonna go and teach anybody how to write MUMPS. I’ve never written MUMPS in my life, and I’m not gonna pretend to sit there and teach people how to write MUMPS code. But learning I think is a very different process, at least for me anyway. For me, learning is that hands-on “I’ve got to be practical. I can’t get it into my head any other way.”

I don’t wanna self-promote, but I do have a book still available… You can get it on Amazon and other tax-dodging superstores. [laughter]

I just wanna let people know there are other books available. [laughter]

Not just Mat’s.

There are other non-Mat-Ryer books available on Amazon.

There are. Actually, there’s loads. Most of them aren’t written by me. But my book is a blueprints book, so it is about building real things. So the way I learn is kind of the way I teach… And I also extend that to trying not to over-teach or trying not to include everything. I try and pick the important bits, enough for people to be useful, so they can do something, and then start that reward process that you get when you code something and it works. That to me is what then inspires the next bit of learning, and it’s kind of that tight feedback loop. So the sooner you can build something real - for me, that’s a very exciting thing. It may not be the case for everybody, but yeah.

I think the criticism in some cases might be “You didn’t tell the whole story there. You’ve only touched the surface, or something…” And there’s loads of other things that people could know about this particular thing. And I try and focus on what’s pragmatic, what’s practical, and what can be useful, because really, that’s what we need to start with. And then it guides your learning, right? If you need something more, you know, because you’re blocked.

Yeah. You also have to be sure you don’t over-stimulate, too. You don’t wanna throw too much information at people at any given time, because even if it’s practical and incredibly relevant information, it’s gotta be handed out in small doses, so that people get it.

One of the big things we focused on at GopherCons in our content is when you see a slide, that slide’s about one topic. One thing. And it could just be a very simple thing - one way of variable declaration, and that’s all we talk about on that one slide. And the code example – maybe it’s a bigger code example, because we need more code, but we only show the 3-4 relevant lines to students, because we only want you to focus on those 3-4 lines that are important to this slide, for the topic we’re talking about.

I’ve found if you show somebody a huge, complex code example, you know what they’re gonna do? They’re gonna spend the whole time just staring and trying to figure out the huge code example; they’re not gonna follow what you’re saying. If you show them 3-4 lines and you just move through those slides, you’re giving them the whole picture just a little bit at a time. And then they’ll all catch up by the time you get to the exercise. Now it’s like “Okay, take all of those little bits and you can build something a little bigger.”

But it’s hard, you can’t overload people either… And I see it all the time; that’s one of the worst things you can do as a teacher.

Another thing that happens sometimes - if you’ve just made up an example, just because it doesn’t matter, I’ve done it where my example is not a good example, and that becomes then the focus… And that obviously gets in the way then. So that’s a fail on my part. And usually, breaking it down and only showing the relevant bits is a good way to avoid that sort of noise that otherwise can get in the way.

[55:57] It is. It’s also really hard – you just touched on something very important, Mat, which is writing examples. It’s probably the hardest thing you have to do as a programming teacher. Because we keep talking about Go, but we’re just talking about programming languages. All this applies to every other programming language on the planet, right? And honestly, learning anything, or teaching anything in general… But yeah, it’s – I’ve lost my train of thought… [laughs]

Well, writing examples is hard. You use the Beatles a lot, don’t you?

I do use the Beatles a lot, just because I’m a big Beatles fan. Well, they offer just enough variety, and those forenames - they’re not hard names, they’re not long names; they play instruments… It’s just little bit that you can use, and they’re good enough to give you more than 2 or 3. Because 2 or 3 things in an example is usually too small. But anything more than 5 or 6 is way too big; it’s just too complex. So 3 or 4 is usually a good example… But finding small, tight, concrete examples of the thing that you wanna show that’s also kind of real worldy too, because the smaller and tighter you try to get an example, often the less practical that example becomes. It becomes a toy, and I’ll tell you, we’ve spent so much time, Cory and I, sitting in Zooms together, talking about examples, going “This one just doesn’t work in class. It’s too small/It’s too complex/It’s not showing the problem tight enough…” And it’s hard. The words - that stuff’s the easy part. It’s those descriptions - that’s what people see. And the developers wanna see code; if you show them code, it’s gotta be good code, that illustrates it exactly, and that’s really hard.

I think this is one of the reasons why so many people struggle with structure… Aside from the fact that there’s not a one single solution, when you try to show examples it’s really hard to show an example that’s small enough to actually take in at once, while also appreciating the benefits of like “This is why we structured it this way, and this is why it works.” Because you almost need a large codebase for that to make sense, especially when you get into the more complex structures… Like you’re using domain-driven design; really, if you’re building a Hello World app, domain-driven design is just complete overkill and it’s not helping you.

So it’s like “How do we give an example that illustrates these points and is complex enough to feel the pains that this might solve, while also being simple enough that you can actually take it in in a short period of time.

My trick to that is to offer layered examples, as we get through the curriculum. Reintroducing and saying “Hey, remember in the last module we talked about this. Now we’re gonna add an additional layer of complexity to that.” So it’s building up that mental model and introducing more complicated things. But basically, you have the same one or two set of exercises that are getting incrementally more complex. That way, it’s not a completely new problem you have to solve with each new example of code I’m showing you, or with each new module; it’s just a continuation… Which is why I really enjoy projects that take that approach, to say “Hey, we’re gonna build a Kubernetes cluster together.” And we start from the ground up and we keep adding layers. But by the end, you know you’re gonna get a fully working Kubernetes cluster or something out of it. But we’re introducing the topics and adding the necessary bits as we go. But you have something you’re working towards.

That’s great, yeah. Would you have any advice for people that want to get into training? And I’m also gonna ask a cheeky question…


[whispering] Is it good money? Is it good money? [laughter]

It’s a good job if you can get it. Here’s the thing - we’ve really just been talking a lot about the actual presentation of the material… And just at the end there we were starting to touch a little bit on code examples, and stuff like that… But what I think people really don’t understand is that when you go to teach something, if you wanna teach three days, you have to have three days of content. And three days of content doesn’t grow on trees. [laughter] It takes you a lot longer than three days to write three days’ worth of content. It takes months.

[01:00:24.00] So if you tomorrow say “I’m just gonna go and start teaching”, well good luck to you, because you’re not gonna get very far unless you’re really ready to sit down and spend hours and hours and hours fretting over your content.

You could just buy Jon’s course and play it on an iPod in your ear… [laughter]

That would be pretty interesting…

You could, yeah. That would be the same. You’d have to have the same tone…

I think it’d be hard, because my stuff isn’t designed for in-the-classroom really… But maybe. But Johnny mentioned this earlier, where as educators we like to learn everything; like, really understand all of it, and then we sort of figure out “Okay, this is how I’d recommend learning it, now that I’ve actually spent a large amount of time learning this all.” And I think that’s where a lot of the value in these trainings and workshops and all this stuff comes from, is not just in the content, it’s the fact that I’ve spent hundreds of hours figuring out the best way for you to spend 40 hours and learn the most amount of content.

And a lot of people are like “Why does it cost so much?” It’s like, look, you can do this on your own, but given that you as a developer you probably make at least $25/hour, probably much more than that, it’s really cheap in comparison to how much time you’re gonna waste.

Right. And this is where we slightly deviated, so talking about the business value. I don’t know if I sound like a suit but really, this is where you have to look at “Okay, what am I paying, but what am I getting in return here?” You’re not just getting basically 50 bucks, 100 bucks, 300 bucks, $1,000 worth of content. What you’re getting is – and let’s be honest, anything that I teach in my classroom, and I’ll go as far as to say anything that all of us on the panel here teach, you can google around for it if you want. There’s nothing that we’re teaching that is proprietary, or magical, there’s nothing you’re gonna learn in our classrooms that with sufficient time and persistence you’re not gonna find out there and teach yourself.

Well, how do you think we learned it all?

Exactly, how do you think we’ve found it?! The value is in having somebody who’s spent the time distilling all of that stuff down to the key nuggets to help you pick it up in 40 hours, rather than 400 hours. So what is your time worth? We find joy and satisfaction - and hopefully monetary gain - from doing this work, because we enjoy doing it… But really, at the end of the day, what is your time worth to you? Do you wanna spend $200 googling around until you learn and master something?

Or your team’s time.

Right, yeah.

When you’re talking 40 people, that’s a lot of time.

That’s a lot of money. That’s a lot of time and money.

Yeah, absolutely.

To even back Johnny’s point, I’ve talked to people who make courses where literally everything taught in the course is available for free on their blog. It’s just all put together in one big project, in a really nice order… And they’re like “Look, people pay just for that. It doesn’t matter that it’s all there free.” They’ll read one little bit free, as a blog article, and be like “I want the whole course. I don’t wanna go searching for the rest of this.”

Well, that’s kind of the Michael Hartl Rails tutorial model, where he gives away the – or used to; I don’t think he does it anymore. He used to give away the entire Rails tutorial book online for free, as HTML. You can read the HTML version. Or you can spend hundreds on the videos, and the PDFs, and ePUBs… And he does great with it. I can’t tell you how many people I’ve seen go up to him and thank him 100 times over for his courses, and stuff. He will be out at a conference, or hanging out, and people just come up to him and thank him all the time.

But he didn’t get there by accident either. Again, he puts a lot of effort and time into all of that. So if you’re thinking about getting into teaching, consider all that we’ve just said about that time, and that effort.

[01:04:08.12] I would just say start small.

And start small, yeah.

Start small and see if you like it. Because it’s good to have more teachers.

One of the things I always recommend – when I used to run development teams, I used to force brown bag lunches every two weeks, and force all of the engineers, one at a time, to do a presentation during a brown bag lunch. And it could be on the library, a plugin, something that they’re working on at work, it doesn’t really matter. It’s a safe, small environment, with half a dozen of us in the room, or whatever… But it gives everybody a chance to stand up and start to learn a little bit of how to teach and how to mentor. Because at the end of the day, as we grow in our careers, whether we make our livings as educators or we’re working in dev shops as senior developers or directors, or VPs, or whatever - as you move up through your career, mentoring and teaching is a big part of your job. And as you move up, that’s why you get paid so much. You get paid to mentor the people below you, and you’ve gotta start learning how to do that now.

So if you are thinking of that, or you’re just looking at your future prospects, I think you need to start – try doing some of those things in-line, at your company; a brown bag, teach some stuff. Have other people teach some stuff. I think you’ll do great.

Yeah. Well, it’s that time again… Bates, hold this space guitar, mate. Jon, get on the drums. Johnny, piano… It’s time for Unpopular Opinions!

Do we have any unpopular opinions about teaching? [laughter] Mark’s really confused by that… But they’re gonna put the music in, aren’t they?

Has Mark been off the show that long?

[unintelligible 01:06:04.26]

I don’t wanna offend anybody, but I guess without a better way of putting it, I think the smartest people often make the worst teachers.

Hm… Thank you. [laughter] Bates is brilliant, by the way.

I’m trying to decide which way I should be offended.

I know, right? [laughter]

Either I’m a great teacher and I’m really stupid, or I’m a terrible teacher and I’m really smart. So I’m trying to figure out where I sit in there.

Tell us what you mean though, Jon. That’s interesting.

So what I mean by this is - in my opinion, the smartest people tend to be people who get things very quickly. They don’t struggle with them, so they don’t really start to relate with how the average person is going to learn the material. So as a result, the smartest people are the people who can’t produce a learning path that is going to appeal to the average person, and they’re just gonna try to go too quickly.

The best examples I can give is I had a friend in college who had – it was like a Calc 2 class, or something, and every time somebody would ask a question, they had this genius math teacher who would just be like “Oh yeah, it’s real simple” and he’d just throw something up on the chalkboard real quick… And the whole class would sit there like “We don’t know what you just said. We do not understand anything you wrote on the board.”

I think part of it was because it all just made sense to him and it all clicked, so he didn’t quite understand where they were struggling. He didn’t have the empathy to really relate to him.

Maybe he just needs to be a bit smarter. [laughter]

So what I mean by that - smart people can become good teachers, but I think naturally if they take what they learned in the way they learned it, it’s not going to do well. Another way to phrase this is I feel like you have to be dumb enough to struggle with the material, so you understand how the average person is going to struggle… But you have to be smart enough to figure out how to teach the stuff that you struggled with. And I just feel like the smartest people don’t necessarily have that struggle.

I think you’ve managed to find an unpopular opinion.

[laughs] I think it’s a–

I mean, I’m calling myself dumb as well, so…

[01:08:10.22] It’s an interesting opinion. I don’t know if I fully agree with it, but I can kind of see what you’re saying. I think there are definitely a class of really smart people who struggle with interpersonal skills and who struggle connecting with people and primarily live in their heads… And they definitely make terrible teachers, because they’re not willing to slow their brains down, or don’t know how to slow their brains down. But again, I don’t think it has anything to do really with smart, but more in terms of the personality and those interpersonal skills. Because if you’re really smart and you have interpersonal skills, you can make those cognitive leads, and you can say “Hey, how am I gonna get this person from A to B?” And I think you have to be smart to do that sort of stuff… But you have to have the personal skills. I think that’s the difference.

Smart is really not the right word, but I don’t know the correct word for it. It’s almost like the people who just innately get things are not necessarily the best teachers. And I realize it’s a generalization and there are exceptions; I don’t expect that to be true of everybody.

Jon, I think I’m gonna connect the dots for you.

And I don’t know if it’s an unpopular opinion or not, but… Those who are smart and know it, and bring that to the teaching with them - I think those make the poor teachers. In teaching, in training other people, your ego does not belong there… Because it’s not about you. You are trying to convey information, you’re trying to relay information, you’re trying to teach another person how to fish, to paraphrase the old proverb. So it has nothing to do with you; you’re just a conduit for information.

So if you go on stage, whether you’re giving a conference talk, or whether you’re on a podcast of professional teachers as a panelist, or something…

Insulting them all… [laughter]

Or you’re Mat.

Or you’re Mat, yeah… Or you do this professionally or not, on occasion, whatever it may be - your ego should not be part of that equation. It’s about how you convey information to people in different ways, meeting them halfway, meeting them where they’re at, and sort of conveying that information. You’re nothing but a conduit. Leave your ego out of it.

Can I add to that and say not only you’re a conduit for teaching information, you’re a two-way conduit, because you should be learning while you’re teaching. And if you’re not learning while you’re teaching, you’re not gonna be a good teacher… Because you need to learn your audience, you need to learn who they are, you need to learn how to talk to them, learn how to work with them… But also - I think I said this earlier - I’m not afraid in class when I get asked a question to say “Honestly, I have no idea. I’ve never thought of that before. I’ve never seen that before. That would never cross my mind…” And I’m okay saying that, because then the next thing I say is “You know what - let’s open up Vim. Let’s see what happens.”


“Let’s learn together.” And great, now I know. And I have learned something from that class that I didn’t know before I went through it. Like I said, Cory and I try to make an effort of putting that right back into the material, so we have it for the next time. So it’s like “Yeah, someone asked a great question, we didn’t have an answer, we didn’t have a slide… We’re gonna learn that answer, we’re gonna learn how to present that, and we’re gonna give it back to the next class that comes along.” And if you’re not willing to do that, you’re gonna be a pretty *blip* teacher.

I’ve struggled with how to convey that opinion just because–

What, with me swearing?

Because I completely agree with you guys not this swearing…[laughter] It’s a struggle to convey that opinion, because it’s almost like I’m saying somebody who learns how to present material and has the smarts to understand their audience and relate with them and figure out the best way to teach them isn’t smart, and that’s not what I mean… I think it’s more like Johnny said, there are some people who are – it’s almost like they’re just so focused on their own intelligence and showing people how intelligent they are…

Yeah, they live up here… They all live up here.

Yeah. They have to be able to step down and relate to the audience. And I think, in my experience - at least with university, and stuff - the teachers who tended to be like that were the ones who were there strictly for research, and they were forced to teach a class, and it showed. They were not teachers, they were very smart people who did not wanna be teachers.

They wrote some *blip* thing on the whiteboard and expected you to know it, and that was it. Yeah, I’m with you…

That’s your second strike, Bates… [laughter]

Oh, no way! I’m banned!

So do you have any funny stories? Because I did teach the Gopher Guides–

Okay, two guys walk into a bar…

No, no, hang on… [laughter] I taught the Gopher Guides material in London, Bates, if you remember…

Yeah. Years ago.

And at the end of the three days, this young man came up to me and said “I think I’m your cousin”, and I’d never met him before… And it turns out he was my cousin.

And he learned that as a result of you teaching the Gopher Guides material?

Yeah, I was teaching a class at a company…

…and I’ve found a cousin. So you can get extra cousins if you do teaching. That’s one of the perks. [laughter]

It probably could have been worse. He could have maybe introduced himself as your son. [laughter] “I think you’re my dad… Because of this channels example!” I’m not quite sure how a buffered channel would get you to that conclusion, but… [laughter]

He got into the unsafe package.


Just in time, and to save Mark’s career, we are gonna end here. So thank you so much to all our–

I think it’s too late to save my career… [laughter]

Thank you so much for listening, everyone… We’ll see you next time.


Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00