Let's face it, your code is going to have errors, even code written by a kick-ass developer such as yourself. When bad things happen, it's nice to know that Honeybadger has your back.

Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring, and chron monitoring into a single, easy to use platform, all for way less than you're probably paying now.

Honeybadger monitors and sends error alerts in real-time with all the context needed to see what's causing the error and where it's hiding in your code so you can quickly fix it and get on with your day.

The included uptime and chron monitoring also let you know when your external services are having issues or your background jobs go AWOL or silently fail.

Go to Honeybadger.io and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Why is this important? Self-funding means they only answer to you, the developer, rather than a venture capital overlord.

Greater Than Code listeners get 30% off for 6 months. Simply mention Greater Than Code when signing up and they'll apply the discount to your account; no credit card required.

JACOB: Hello, and welcome to Episode 206 of Greater Than Code. My name is Jacob Stoebel. And I'm here with Jamey Hampton.

JAMEY: Thanks, Jacob. And I'm here with Rein Henrichs. 

REIN: Thanks, Jamey. And I'm here with my friend, Jerome. 

JEROME: Hey, everyone. I'm here with Brian P. Hogan, a software developer, teacher, author, editor, and musician living in Eau Claire, Wisconsin. He develops web applications like Codecaster using HTML5, Elixir, JavaScript and Ruby. He also coaches and mentors aspiring developers. He's also an author of several books, including Small, Sharp Software Tools, tmux 2 - Productive Mouse-Free Development, and Exercises For Programmers. He is always looking for interesting opportunities to help people succeed.

So Brian, tell us, what is your superpower and how did you get it? 

BRIAN: I would say that my superpower is being able to teach people stuff. I got it from my parents. My dad was a long-time teacher. He taught blind kids in the Chicago area for a long time. He taught blind kids in the Eau Claire area when I was growing up. And my mom became a special education and Early Childhood Development teacher. It was always kind of something that ran in our family. And from the earliest days, I can remember learning how to do something and then teaching other people how to do it. And that I think has become something that -- despite moving into software development, every once in a while, I always find my way back to teaching in some way, shape, or form.

REIN: So I'm going to start you off with a softball question which is, how does teaching work?

JAMEY: Is that a softball question? [Chuckles]

BRIAN: [Chuckles] I don't know if it's a softball question or not. I mean, how does it work? There's ways that people think it works, I tell you stuff and you do it. And that's not really how it actually works. If we could talk about how to be effective at it, what it really comes down to is guiding people. It's figuring out what the outcomes should be and guiding people towards those outcomes. Maybe that might mean some assessments, maybe that means finding and curating the best material that'll help them learn, maybe sometimes that means creating your own material. But really, it is guiding someone to be successful. You want to learn how to do a skill. I don't care if it's baking a cake or building a web application, how you learn that is important. And to be a teacher it's really important to understand how people learn how people are motivated and all that. And so, in order to make teaching work, you kind of have to think about how you're going to be their guide. And I think the coolest thing I ever heard was when I took a step away from software development for a while and I became a teacher in higher ed. I had a teaching mentor and he told me flat out, he said, "Your job is not to be the guy in front of the class pontificating and professing to your students. Your job is to be there with them." And he said, "You are the guide on the side, not the sage on the stage." And that since then has stuck with me when it comes to what it means to teach people. 

REIN: I really like that. It sounds like what you're saying is that teachers have to be able to learn about their students, for example.

BRIAN: It's so easy for teachers to look for themselves in their students. For example, you might have someone who's really good at math, and they'll sort of have a difficult time understanding why some of their students aren't good at math because they don't understand how that could possibly be. And I think that sometimes it's the same when we teach people to code,  when we talk about code, when we talk about data structures and algorithms. It's things that we really understand, but we have to understand that the people who might be learning from us come from a very diverse background and all have different motivations. Some people are looking to better their lives through a better paycheck. I mean, let's be honest, software development pays really well. And sometimes it's a way to lift people out of poverty, and I've seen that. One of the best students I ever had lived in his car for a year while he learned to code, and now he's doing very well for himself. 

You have to be able to understand that not everybody learns the way that you do and not everybody is excited about the things that you're excited about. And so learning what you can about the people who you're going to be teaching, I think is really important. It's just like if you're going to onboard a new employee, you want to learn about them, and you want them to learn about you, and you want to create that relationship. If you think about the best teachers that you've ever had in your life, they're the ones that you had some kind of a relationship with. You had some kind of connection because they took some time to get to know you. 

JACOB: In a previous career, I also worked in higher ed for a teacher education program. So basically, it was a college that was teaching college students how to be K-12 teachers. And one thing I really sort of absorbed from just interacting with the faculty there was how we really don't have an appreciation for teaching has methodologies that are -- you don't just know them. And you can know the content like how to write a web application but knowing how to teach that to someone else isn't the same thing. 

BRIAN: Absolutely. I have spent a lot of time learning about that. In order to teach what I taught here in Wisconsin, there was a collection of courses that I had to take about how to be a teacher because I taught at a place where it was like, okay, you know your subject matter. Now we're going to teach you to be a teacher. So I had to take these courses like educational psychology and diversity. And one class that really stuck with me is these brain-based teaching methods where we learned all different manners to connect with people with different learning preferences and how to embrace the Multiple Intelligence theory things like that so we can make better connections with students and help them be successful. But there is so much to it. 

There's so much more to teaching than putting up a landing page and a bunch of videos and saying, "Take my course." There's so much more to it than that. And I think it's great when people create learning content, but I think it's even more effective when people think about the processes and the outcomes they want for people to have. What are you looking for your students to get out of this material you're putting together? What are the outcomes? I like to look at it as what should they be able to do that they couldn't do before? If you can enumerate those things and then if you can work backwards from that and align all of your content to that, two things happen, number one, your learner has so much more success. And they're more engaged because they're doing things that are directly related to the outcomes that you've told them that they're going to have. But more importantly, it keeps you, the teacher, on notice that hey, maybe this really cool thing that you think needs to be in this course it's just something you like, and it's not something that's really directly relatable to the outcomes that you're looking for. And so it causes you to pair things down and creates more room for you to go deeper. 

JEROME: Absolutely. We've talked about this type of subject on several occasions on the sidebar because we both come in with a teaching background. So one of the things that you just said that I really liked was about the idea of how video courses -- anybody can do a video course. But it takes being able to really drill down and figure out your outcomes. And it's one of the reasons why it took me so long. It took me six years before I signed a deal with anyone mainstream to do a video course of anything because the craft of teaching varies person to person because every student is different. I have some students that are straight wizards when it comes to CSS and then there are others it looks like Egyptian hieroglyphs. So let's talk about that personal connection and getting that feel. How do you gauge that with a person quickly so that way you can have maximum impact on their educational journey? I think that's a great conversation piece to have. 

BRIAN: It takes a while. It's not something that you can do if you just deliver content like a drip campaign or a course in a box. It's much harder to do that. You end up really deciding who your learners are going to be. If you're going to put a course in a box together or a curriculum that you're just going to sell on something like Thinkific or Teachable, then you're kind of already defining what your learner's persona is going to be, someone who watches videos and maybe they code along with it. But if you're in class or a workshop setting or you have a cohort where you can develop relationships, you can learn an awful lot about that through different activities. 

One of my favorite things to do is as a thing called an exit ticket. At the end of a session or at the end of a course, I'll use an app that students can just enter a six-digit code to enter my classroom. And then I'll present them with some questions like what did you learn today? Some kind of reflective writing exercise or whatever. But I can always add a question in there that will let me learn more about them at the end of the session. And I can collect those. And over time, you kind of get to learn people through that. You get to learn through the questions that they ask, learn through the conversations. It takes time. It's relationship building. It's no different than working with a team at any kind of software development job. Building those relationships takes time. There's no shortcuts to it. But you can recognize patterns too. You can recognize, okay, this person believes they learn this way. That's a whole other discussion. 

I think one thing that's happened in the last 20 years is that we've sort of convinced people that learning styles are a real thing. And we've convinced people that they learn in certain ways. And I will have people say, "Well, I can only learn from video." And honestly, if we dissect that, I bet you, that's not true. I'll bet you if there's no video available and you have to learn something, you can learn it. I will be willing to bet you. And I think that that sometimes gets in people's way. So I always try to reframe it as learning preferences. You have a preference for video. Don't let anybody con you into thinking that you can only learn one way because you have enough roadblocks in your way as a learner when you're trying to learn something new. You don't need to add more in your way. So getting to know people and understanding how they learn and being able to provide methods for that I think is really important. 

I like to be able to develop courses whenever possible that do provide written materials, as well as video content, as well as exercises and activity because there are a lot -- It's very easy to buy a video course. It's very easy to buy a book. It's a little harder to learn from that if you don't do the exercises. And this is where we make that transition from passive learning, watching a video, listening to a podcast, to more active learning, building something, doing something, creating something. And if you ask any teacher, that's where the learning happens. You don't learn from watching videos. You learn from doing some kind of active things. Getting to understand the students is part of that but getting the students to understand how learning happens is another part of that,  getting them to understand that "Yeah, you're going to have to pick it up and here are some exercises to do. This will help you get better." I can watch how to hang drywall on YouTube all day long, but if I haven't done it, I'm not going to be very good at it. 

So I think that's where the conversation starts, making those connections with the student, making those connections in a bi-directional manner. Here's how I understand that you learn things. Here's how you might consider how you learn things. 

JAMEY: I wanted to ask a question about what you were talking about with building relationships because sometimes it can be tough to build relationships. You described it as being similar to being on a team. And I think also on a team, it can sometimes be tough to build relationships with people that you don't naturally vibe with. And on a team, both people in that relationship have the responsibility to try and come together and bridge that gap. But in a teacher-student relationship, I feel like it pretty much falls on the teacher to figure out how to bridge that gap. And I'm wondering what your thoughts are on that and how you do that as a teacher. 

BRIAN: That's fair. But I think that there's a bit of a difference. An awful lot of what people understand about teachers and teaching comes from their K-12 experience - I had math teachers, I had K-12 teachers, things like that. Teaching adults is a much different story. The kids have to be there because they're required by the law to be there or they think of school as this is the prison system. I have to be here. Listening to my 12-year-old talk about it it's like, "Argh, another day of school." But if you've got adults, you've got adult learners that are motivated. It's easier to make those connections because there is a common goal. I as the teacher want them to be successful in learning this material. They, as the learner, want to be successful in the material because there's a paycheck on the other end of that. 

And so what it really comes down to is tapping into that motivation and identifying what is the motivation? Why are you here? What are you looking to do? Do you want to make video games? Do you want to make mobile applications? Do you want to make websites? Understanding that is the starting point for me. That's always a starting point for me. Why are you here? What are you hoping to learn? What do you want to be able to do when you're done? And then we could have those conversations, and we can build those relationships. 

And I have gotten to the point where I had a student who was really excited about space. It was her hobby. She would watch the stars things like that. And there's actually this example in my Exercises for Programmers book. I found that NASA has the Open Notify API where you can see who's in space right now. You can just make a query to an API, and it'll tell you the names of people who are in space right now and what craft they're on. And you just pull this down, it's a public API, and you use it. And I showed it to her. I said, "Use this. Make a React application or make a JavaScript application that pulls this data down." And it's just understanding that this is a thing that there's these things out there that you can tap into. I had another student who had a kinesiology background. He was a physical therapist. "Your assignment should really be to try to make some kind of a workout tracking application." 

Tapping into those things understanding what people are, what their background is, and then tapping into the motivation really helps. It's a hack, a little bit, to speed that process and relationship building. What's that common goal? What is the common goal? And I think it's the same thing at a team too. What is our common goal? How do we tap into that? 

JEROME: It's very funny what you said because that's what I do. I know hey, here I am as a veteran who [inaudible] and he's writing down software pushing pixels doing fun things. Let me teach you how to do that. And one of the exercises I do is on the one on ones, I'm trying to figure out what are the things that you like? Like, if you like making beer at home  I think there was a phase during COVID called the lockalypse as I like to call it. Everyone has been making bread or something. So I've been doing that. We have a project going out with where we share the recipes where one of the veterans was like, "I'm just tired of reading the story of each recipe before I get to the recipe on websites. So I'm going to make a plug-in for Chrome where it will just skip straight to the recipes because I'm tired of this." Being able to find that thing that's like that button to push and pressing on it, when it comes to learning, I feel it is the greatest secret. 

People are always trying to get people to learn code through these various exercises that are really cookie cutter. How many JavaScript calculators have we've seen out there in the industry? There are too many. But when you build something about you, you're now the product. What are the things that matter to you? If there is a 3:00 a.m. emergency or you've got to work on this thing at 3:00 a.m., what is that thing that you would be okay with working on until 3:00 a.m.? And that's where I've seen the most success at is where people are working on things that are solely totally around them and has nothing to do with a project. Or like you said, you tap into that thing they're passionate about whether it's picking beer, tired of reading all the backstories of how Carrie Anne got this recipe from her grandmother's grimoire like she was a wizard or some shit. It's always very interesting to find that button and then tap into it. 

JAMEY: And I think it can be really frustrating when you're trying to learn something if it's not clear how it's going to be actually useful because most people want to learn something because they're actually going to use it for some reason. 

BRIAN: Yeah. That is kind of where the Exercises for Programmers book that I wrote came from because it was the stuff that we did in my classes. In my introduction to programming class, they do the first four exercises from that book. Every day we do one or two. And I try to keep them as real-world as possible for that reason. We weren't just going to do an if statement just to do an if statement. We weren't going to do a loop just to do a loop. It was going to have a story behind it. It was going to have a reason that we're doing this. It was going to have some requirements behind it. 

One of the first ones my students got exposed to was the idea of a paint calculator for calculating the number of gallons paint you need to paint the ceiling, the idea that you have to buy the paint in whole gallons, so you can do the math. Now you have to think about, well, okay, but I have to round up now because I'm going to need more paint because I can only buy on a gallon basis. And it was just to get them thinking like, okay, here's a more real-world scenario. It might not be something that they're exactly interested in, but at least there's an understanding of why we have to do this, why we think about whole numbers versus decimal numbers, why it's important to start getting those kinds of things going. Because there's so much to let's learn data structures without understanding why we learn data structures or even worse, you have to learn design patterns. But why do we have design patterns? What are they for? What do we apply them to? 

So I've always thought it's better if we can arrive at design patterns as opposed to teaching design patterns. Here's the thing, let's build it. Now, let's look at it. Is there a better way to do this? Is there a way to abstract this away? Oh, look. We have now created an adapter as a result of doing this as opposed to teaching it the other way. Let's look at the adapter pattern. It's okay to imagine someone sitting in front of you asking "Why should I care about this? Why should I care?" I think that's actually something that teachers should embrace. Be prepared for the sarcastic "This is a waste of time. Why should I care about this? I want to write the next Call of Duty. What am I learning this for?" Because those are real questions that I got. I had students that got into the software development program because they wanted to make games, that was their eventual end-goal. And you have to meet them halfway. You have to kind of explain, "The reason we're doing this is because this is how you're going to model the attributes of your character at an RPG, for example. It's making those connections right back to that motivation. 

REIN: So Russell Ackoff has this great lecture on YouTube that's basically about why the education system sucks so much. And one of the points he makes is that the only thing that is necessary for learning is motivation because you can get everything else yourself if you need to. And the example he uses is how did you learn your first language? Were you taught? No, you learned it yourself. Why? Because you needed to understand the world around you. You had motivation. You had a very powerful motivation.  

BRIAN: Yeah. Teachers talk about that a lot. It's one of the very first things you talk about when you're learning to be a teacher is understanding that motivation. And unfortunately, it gets lost. And if you trace back modern U.S. education, you'll eventually find that it traces back to the Carnegie model of education, which is, let's prepare people to go to work in factories. Learn these things, stand in line, the bell has rung, everyone stand up, go into this one place, go to the next station, follow the sounds, follow the bells. Learn the things, don't ask questions. It's kind of all rooted in that. I would have been a lot better math student when I was a kid if someone could have actually explained to me why I'm graphing equations. I spent a lot of time in algebra graphing equations on a graphing calculator. But nobody wants to explain to me why I would ever need to do that. I took a physics class in high school and all of a sudden, algebra made sense to me because we were doing Force = Mass x Acceleration and all these other formulas. And we're using algebra to rearrange the formula so we could solve for the missing values. And that was helpful. But that's, again, the active learning piece of it. It's not just doing things by rote. It's understanding the reasons why we have to do these things. 

JACOB: I think that's really cool because I definitely struggled the first few years when I was learning in this career. I was trying to figure out okay, well, now I've mastered the rudimentary concepts of Python. And then I was like, "Well, now what?" And I wish it was easier to sort of get a jumpstart by giving me some kind of larger project or problem to solve. Because I think when you're trying to learn the technique whether that is the code, design patterns, and the structures, et cetera, you can't very easily also make up a problem that is designed to help you learn the design pattern necessary to solve that problem if that makes any sense. I don't know how to crack that problem. If there was a list somewhere for people learning to code that they didn't tell you about the design patterns but they gave you a problem and then said, "Hey, you might have to use the adapter pattern. Look it up." I just feel like that would be so helpful. 

JEROME: Yeah, I agree. I can't remember the name of the site, but there's a repository of database signs that's kind of like that. I need to build an online store. Here's the database schema for it, and it's very good for inspiration. And I think the same thing holds true for those kinds of other applications. I think something like that for design patterns would be good. But also what about dissections of applications? Here's an application. This is how this application works. How does this application talk to multiple databases while it uses the adapter pattern? Now let's take a look at the Ruby on Rails framework. How does it talk to those adapters? Every database has an adapter and this is how it works. And okay, now let's look at Ecto, and the Elixir, and the Phoenix side of things. How does that work? That's using a repository pattern. I think there's a lot of work that we could do as a community to create those kinds of resources, looking at existing open-source frameworks and pulling out, and writing about or explaining about the different patterns we find in there. The Gang of Four book that all the colleges use to teach design patterns really is, here are patterns we've seen, not necessarily patterns you should use, these are the patterns we've seen. And I think a modern retelling of that could be kind of interesting 

JACOB: That's sort of also like teaching how to read code. I've never found any resources formal or not about here's how to go about reading code. 

BRIAN: That's very true. I didn't have a lot of that in the classes that I taught. But I remember the students had the most laughter and the most fun in the classroom that I ever saw when I gave them a completely goofed up website. I gave them the code for it and I gave them the W3C Validator. And I said, "Follow the Validator and see if you can fix this code." This is after they hit about seven weeks or so of HTML and CSS, and they could build things themselves. And I just gave them the code and just let them work individually and in groups, however, they wanted to work. And trying to work it backwards and those kinds of exercises I think are great. And I don't think we do enough of them. I don't think there's nearly enough here's a broken React application; let's figure out how to fix it or how to debug it. Or what are all the debugging tools like? There's all these great debugging tools, but you reach for them when you have a problem and you're trying to get stuff done. 

And there's been so many people who have talked about this. So I'm not even going to cite anybody because there's been so many people who have talked about the fact that in the software industry we're practicing in production. If you're a piano player, you spend eight hours a day playing the piano so that when it comes time for you to give your concert, you're doing awesome. People don't pay to watch you rehearse. They pay to watch you perform. But in software, we're always kind of under the gun to figure out how to ship this product. And as a result, we do suboptimal things and then someone else has to come along and fix them. And unfortunately, sometimes that someone else is us. But if there's more opportunities that we can create for people to practice in safe environments where they can get feedback, I think we can do a lot of good that way. And that's kind of where I'm trying to focus. 

When I'm coaching people to put together courses, I'm asking people "When you're going to write a chapter for a book, or when you're going to create this module for your course, what are the outcomes? Now write down a series of exercises that someone should be able to do by the time they have finished your material. Okay, now that you got those exercises, now work backwards from those exercises and ensure that you cover all the stuff in your module or chapter that someone needs to be able to successfully complete those exercises." And I think that if you do it that way, if you work backwards, if you work from the goal and then you have the assessment or the exercises -- And then once you have those laid out, then you create the material that lets people be successful. You end up with this really, really tight content that's really great for learners. 

And the other side of that is you start to notice when other people don't do that. We've all had a class in college or whatever when you get done with the test and you look at your friend and you go "I don't think he ever covered that in class." And it's often because there's no alignment. There's just I'm going to say a bunch of stuff for four weeks, and I'm going to give you a comprehensive test on it. But if we work backwards, if we come up with the outcomes, come up with the goals, and then work backwards with some exercises that let people practice and demonstrate performance towards those goals, and then we create the content that drives them to those goals, I think you have a lot more success with your learners. And I think the learners appreciate it more because everything they're doing is in service to doing those outcomes. And so debugging could be one of those.

JACOB: I'm learning how to read the code when there's no docs, which you shouldn't have to do. There should be docs, but it's sort of more of a survival skill.

BRIAN: Well, and it's not just that. It's the docs are wrong.

JACOB: Right. Yeah.

BRIAN: I just encountered that this week following the docs. And I sent a message and the response was "Oh, you're actually not using the right name. It's actually this." And my response was "Well, can I get a list of the things I should be using, please?" "Yeah, we'll get those over to you." So the docs that we're following and we're banging our heads against the wall -- I spend a lot of time working on docs, and I can tell you that I would rather have no docs than wrong docs every single time. I'd rather have no docs than wrong docs. 

Explore Domain-Driven Design is offering hands-on and highly interactive workshops this year. Workshops will take place over the course of the last two weeks in October and the first three weeks in November. 

Instructors include industry leaders such as Scott Wlaschin, Kacper Gunia, Marijn Huizendveld, Jessica Kerr, Kent Beck, Alberto Brandolini, and Paul Rayner. 

Why should you attend? No travel! No flight delays, passport control, or security checks. Worried about losing your luggage? Forget about it! 

Challenge your thinking in an open, sharing, and collaborative environment while accessing the workshops from the comfort of your own home or office. Take breaks as needed. These are strange times we are living in.

Use the time you would be traveling to report to colleagues on key lessons and takeaways. Help them to expand the skills you’ve learned from these innovative, remote sessions, and then incorporate them into your organization.

Talk to your boss and tell them how you would benefit from attending online workshops from Explore DDD. Relay the cost savings you will benefit from by not traveling this year. Visit http://exploreddd.com/workshops/ and register today. Use the Code EDDDGTC to get 10% off the price of any of the workshop tickets!

REIN: So a thing that I've been noticing as we've been talking is some of the language we've been using about learning it's been things like bridge a gap or make a connection. The language has been about constructing. And I think it's good that Folk Theories of learning are largely constructive because that's also the best scientific theories that we have of learning is that learning is not something that's transferred somehow from one brain to another. It's something that's constructed. 

BRIAN: Absolutely. If you think about all the different ways that you acquire any skill, you had mentioned language and your first language. And programming is a skill that you can learn just like baking, hanging drywall, woodworking. They're all skills that you can learn. But you must do them. And when you're teaching, you have to empower people to be able to do. You need more of that. I have been incredibly interested lately in interactive tutorials, for example, interactive learning not just read this text, but let's combine texts and interactivity together. And how can you get immediate feedback on the code that you're typing? When you type a command, can we run something that ensures that the command that you entered was the right command and that it generated the right files or whatever? You can get that immediate feedback. 

One thing that I firmly believe about learning is that learning happens through feedback and practice. You can watch the videos, you can follow along the videos, and you can build your own things. That's great. But who is telling you that you're doing it right? After you follow the video and you've built your own React application, your own Rails application, after that, who do you have to go to who can read that code and provide feedback on are you doing it appropriately? Who do you have that's able to do that? That is the part of education that is insanely hard to scale. The content delivery part, that scales pretty well but providing feedback on the assessments or the exercises that is very difficult to scale in a meaningful way, but that's where the bulk of the learning happens. It's sort of like you write a 30-page research paper in college and all you get on it is a letter grade. You don't get any written feedback on it. That is so demotivating to you. You don't know why you got the grade you got. You don't know why you got the outcome you got. When you get something back with meaningful feedback on it that you can then apply forward, I think that's where learning happens. So I'm very interested in situations where we can provide that at scale maybe it's volunteer mentoring, maybe it's we can do some things with software to provide feedback. In command-line applications, we can run a command line with the right flags and it will generate the right file. And then we can run an automated test in the background that says, "Oh, yeah. That file was created with the right attributes et cetera." Those kinds of things that let people practice and get that feedback, then that's where the learning really happens.

REIN: So the feedback mechanism that you're describing is sort of synchronous like the traditional sort of Shannon Communication Model where you do a thing and then you get a response and then you do a thing and you get a response. One thing that's really interesting about being a computer programmer in the real world is that our environments that we operate in are becoming much more asynchronous. So even our editors now they compile asynchronously, they syntax check asynchronously, they lint asynchronously maybe they've run your tests asynchronously. And so a lot of the feedback you're getting is joint. It's a bunch of cues just all happening at once. It's not something waiting around for you to finish. How does learning and teaching account for that? 

BRIAN: I think that you develop your learning materials. Teaching isn't necessarily real world. And why I say this is sometimes we'll get feedback on materials we create from people in the community. And they'll say, "Well, that's not the way you should do it. You should do it this way." And the part that we're missing is yes, but the way that we did it is easier to explain for someone who has no context of what they're supposed to be doing. There's a different way that you would write code in an education environment versus the way you would write code for someone who's got a couple of years on the job. The part that is hard to bridge, though, is that part where we need to transition learners from here are the safety nets, here are the places you can play, here are the places that you can learn safely. They just drop them off at their first job into the deep end of a pool. And now they're bombarded with error logs and asynchronous messages and all the things that you described. So I think there are opportunities for us to do that better. 

REIN: Practicing and production is a great way to experience joint activity because it really is a whole lot of stuff all happening at once. And you can't make any of it stop. None of it is going to wait for you. 

JAMEY: Huge mood.

BRIAN: Yeah. [Laughs]

REIN: I was thinking back to when we were starting our conversation talking about how we have to build relationships so that we can sort of make bridges and construct knowledge. There is a model of learning that comes from Gordon Pask, and it's called Conversation Theory. And the basis of this model is that every learning is a form of conversation. Even when you read a book, you have to have a conversation with yourself to learn from the book. And one of the things that has to happen for this conversation to work is that you have to establish a common ground. You have to connect on some sort of foundation that you can then construct from. 

BRIAN: And that was kind of what Jerome and I were talking about when it comes to finding that common motivation with a student. That's where some conversations can start from. If you're transitioning from being an engineer into a leadership role, you've got a motivation to do that. So if you're reading a book on how to do that, there's your common motivation right there to have those discussions, and I think that's part of it. That theory about how all the learning interactions really are conversations is a very important theory for people to keep in mind. When it comes to adult learners, I always recommend that teachers do share this information, share these learning theories, share things like Bloom's Taxonomy. Share things like the performance-based learning model. Because, again, it's me sharing as a teacher or me sharing my motivation with you and helping you understand the different ways that people learn that also creates areas for discussion. Here's why we're doing all these exercises. This is why because it's going to give you more practice. So when you see similar exercises, you'll be able to handle those just as well. So I never think it's a bad idea to keep teaching as a black box. I like to be transparent with the teaching methods that I use. 

REIN: I think this also helps me when I am writing documentation or when I'm doing something where I know I won't be able to have a personal connection with someone, to try to remember that my goal is to allow that conversation to happen. So I'm not just trying to impart a bunch of facts. I'm trying to create a context in which they can have that conversation in their own heads and engage with the material in that sort of way.

BRIAN: Exactly. Putting yourself in the reader's shoes is what I find to be the most effective way. What questions will they be asking at this point? What questions will they have? Trying to anticipate based on your experience the kinds of things that will come up and not necessarily answering every one of them because if you do that, you come across pretty wishy-washy. But do think about why are they here? Why are they reading this thing? They've come to this piece of documentation because they're staring at a blinking terminal with an error message in it or they have received a popup dialog from their application, and they don't know how to move forward. Why are they here? What are they trying to accomplish? Again, it goes back to that motivation because a lot of the times what we tend to forget, teachers and software developers and support people, we all tend to forget that when it comes to adult learners, they have so many other things on their minds, especially now. What was that thump? Was that my kid? I have to work tonight because I have to work that second shift. I had students who worked two jobs and went to school. I can tell you that the homework for my class wasn't the top thing on their mind, keeping the lights and the heat on in the winter was on top of their mind. And so, sometimes the motivation isn't the motivation that you think it is sometimes it's different. So trying to understand what people are trying to do and getting them their solution as quickly as possible is a great way to think about approaching a lot of the situations. 

REIN: I think that one of the biggest challenges with writing a book or a video course or documentation is that the teacher has so few opportunities to learn at all about the people they're teaching. 

BRIAN: Yeah. When you're doing those kinds of things, you have to decide who your reader is. And the advice that I was given as a book author, and the advice that I give as a book editor to my authors is decide who your audience is, decide that scope, and then tell the reader what that scope is. If this is for absolute beginners, tell people that it's for beginners. You have to make a choice and you will not have a very good product if you try to have a book or a video course or any kind of thing that's completely self-paced if you try to address too many audiences at once. I'm a bit hard line on it. And I will say one audience. Your audience is this. This is for this audience only because if you want to write for a different audience, create a different course, book, or product for that other audience. Segment it so that you don't confuse things. You don't have just to run around saying, "Well, if you're this, then this, if you're that then that." It just keeps it cleaner and simpler and sets the proper expectations because that is the other side of motivation. It is setting expectations. In this course, book, session, you will learn these things, you will do these things, and at the end of it, you will have done these things. And another one from my teaching mentor -- he was in the army. He loved to repeat the phrase "Tell them what you're going to tell them, tell them, and then tell them what you told them." He loved to say that all the time. But there's a lot of truth to that. When busy people have got a lot of things on their mind and they got to get something done, keep it laser-focused, keep it on track and keep that motivation there and set those expectations. 

JAMEY: We have been talking a lot about teaching. And one thing that you've brought up a couple of times is mentoring. And I was wondering if we could talk about -- I think teaching is something you do when you're mentoring. But what is the difference between these two things? Where do they overlap? Where do they not, in your opinion?

BRIAN: Well, in my opinion, a mentoring relationship is a mutually exclusive one. It's not just I'm going to tell you things, and you're going to do them. It's we're going to learn together. We're going to learn these new things together, and it's a long game. It's a long play. When I'm going to mentor somebody, it's a long-term investment for me. Because as a result of the people that I've met, I now have a network of people who know a whole bunch of stuff that I don't know because they've grown in their careers and gone off into different directions. And so now I can say, "I'm not really great at React, but I know who is. And it's a person that I mentored for a long time. And they're always happy to help me out." But I think the difference is that mentoring is a much closer and deeper relationship than just teaching. And sometimes you don't even know you're somebody's mentor. You find out someone refers to you that way. It just sort of happens, but it is that deeper and closer relationship. It's more of a professional relationship. We're colleagues, maybe one person has more experience in a certain area. But I think that's the bigger difference. It's more one-to-one, and it's more personal. And it's definitely mutually beneficial.

JAMEY: I assume that teaching is also mutually beneficial in many circumstances too but in a different way.

BRIAN: It is. It can be. If you're doing it right, you're going to get a lot of feedback as a teacher on what worked and what didn't not just from your own assessment of the situation "Ooh, that lesson did not go well. I need to do that differently next time." But you're also going to get it if you're open to it. Content creators and teachers and whatnot, a lot of people are not terribly open to feedback until it's too late. For example, I've heard a lot of people say, "I'm going to self-publish. I don't want to go through a publishing process. I'm just going to self-publish." And they go through the self-publishing process and then they get feedback that's not really great feedback that makes them feel good about the work that they did. That's unfortunate because if you're open to feedback earlier, you can produce something that might be a better product. I think that's true with teaching too. If you give a lecture, you do an exercise, and you don't collect any feedback from people about how that went, you're just going to do it the same way the next time. And you're not going to do it any better. And it's probably going to go over just as poorly. So from the teaching perspective, I got better at every class I taught. I got better because I kept all the notes that I received from -- I would do that. How did this lesson go? What were your thoughts in this lesson? And I would collect those, and I would keep them with my lesson plans. So when I taught the class the next semester, I could prep by looking at the feedback I got the last time on it and go, "Okay, these are the things that I should adjust. These are the things that I should do differently." That's where the learning happens. For me, it's being open to feedback and adjusting accordingly. 

REIN: I think we've highlighted a sort of misconception about teaching here, which is that in sort of traditional teaching, one person is the teacher and another person is the learner. But actually, teaching and learning are activities, they're not roles. And what you're saying is that in order to be a teacher, you have to be learning. And you're learning from your students, which means your students are teaching you. And so you're talking about getting feedback at the end of the class, learning from that and becoming a better teacher. Maybe the big difference between teaching and mentorship isn't that they're categorically different. It's that in mentoring, the feedback cycles are very short, continuous. When I'm one-on-one mentoring someone, I'm learning on a second-by-second basis. 

BRIAN: Yeah, absolutely. You're getting exposed to problems that you wouldn't be exposed to normally. There's been so many times when someone's been asking me to work with them on something, and I have never heard of this problem domain before. This is really interesting to me. Let's figure it out together. And that's what I mean. It's a professional relationship. I might have more experience in one area, but this is still a new adventure that we're striking out on together. But they are. Teaching is an activity, learning is an activity, and you can still see lots of people acting as that sage on the stage - They're just reading the notes out, going through the motions, having a monologue. And people tune out. Or you can even get in there and get in the trenches with the students, give them an exercise, observe the exercise, sit down next to each person as they're going through it, have conversations with them, and they'll love you for it. 

JACOB: It just drives me crazy. I think I said this last week on this podcast, but it drives me crazy. How many are using air quotes -- that are really nothing more than type this code and you should get these results. And I am just so frustrated when I see that because that's only a little bit better than documentation. I never learned much of anything from stuff like that. 

BRIAN: What are you looking for that goes beyond that? What are the things when you see it, they go, "Ah, that's great." 

JACOB: What would I use this technology for? What problem would I solve with it? How would I integrate it with other technologies, et cetera? What's an example of a project that I could build that sort of forces me to apply the knowledge rather than just repeat it?

BRIAN: Exactly. You need, as an adult learner with a million things on your plate, you need to understand the why. Why am I doing this? Why should I care? How does this fit into the greater thing? What will I be able to do that I couldn't do before? You need that. We talk about this at my day job a lot. There's kind of two types of technical writing that kind of comes across the wire - The first is look at what I did and the other one is look at what you can do. And they're very similar, but it takes a little bit more work and a little bit more effort to transform look what I just did into look what you can do. But an awful lot of tutorial content really is look what I did. I built this and I took some notes and I wrote it. And there's nothing wrong with that. In fact, I encourage people to do that because I think that's a part of learning. You just figure something out? Write about it. I encourage everyone to do that. But if you're looking to create learning material going that step beyond now, and changing the focus to being reader-focused, to being learner-focused and saying, "Here's what you'll be able to do. Here's why you should do it. Here's why you should care." It's more work, but it's beneficial to someone who comes along to read it. 

REIN: So this is the part of the show where we reflect on the show, the one that just happened.

JACOB: Yeah. I'm still harping on this - There's not nearly enough content out there that's in the category of, here's a challenge for you go solve this and by solving it, you'll learn about React or Rails or whatever. I'm just thinking about this a lot. I think it would be really neat if some really smart product people or people that sort of know a particular domain could contribute to some kind of a repository or something that's just a list of projects, and it's literally here's some problem statements we need solved and solved with whatever technology you want. But we know that you'll learn something great out of it. Because I think the problem of trying to learn a new technology is you don't know how to lay out your own challenge or exercise when you're trying to learn the basics as well. You have to know -- I'll just leave it at that. I think it would be really neat if there could be more of a focus on -- or more resources out there for someone who needs an opportunity to apply what they've learned so they can cement it. I'll just say that.  

BRIAN: That was the goal behind my Exercises for Programmers book. It really is aimed at the very beginning of learning a new language. So you can use it to learn Go or learn Elixir. But it doesn't go as deep as I think what you're saying. I think there are lots of opportunities to go even farther beyond that to more advanced topics too. But there isn't a lot of stuff like that out there. 

JACOB: Yes, exactly. I've been trying to learn more about AWS, and there's just nothing like that. I would love it if there was, here's an example of a project you should build. And you're going to have to combine several different services to do it. But you're going to have to make some informed decisions about what to use and how to use it. 

JAMEY: I'm reflecting on the story that Brian told about his student who loves space and doing this space astronaut project because I think the idea of "Well, just code something that is exciting and interesting to you." When you say it like that, it feels very obvious, but I don't think it's necessarily obvious. I think it's very powerful. I kind of consider myself the kind of person who doesn't really do a ton of extracurricular coding outside of my job and stuff. And I tell that to people. But then when I think about some things that I have worked on, like I made a social Slack that my friends are in because I thought it would be funny and I put jokes in it. And then when I was unemployed, I was worried I haven't written code in a while. Maybe I should do something to practice. And then I didn't for a while. And then I ended up making this little app that you could -- I was mad because I was playing Animal Crossing, and I wanted something to tell me all of the bugs and fish that were available in my time zone at that exact moment. And there wasn't a tool to do that, so I built a tool to do that. And then I used it for Animal Crossing. 

And I was like, "Oh, I didn't write any code." And I'm like, "Well, actually I did write code." It's just that it's being categorized in my brain not as oh, I was doing homework. It was categorized in my brain as oh yeah. I really put this together, and I have the skills to do that." But even then, I hadn't really thought about it in the same kind of really conscious way that we were talking about it with this story about this student who loves space. And so, I think that idea of being aware of that very consciously and trying to find things both for yourself and for other people that will get them excited in that way is extremely powerful. 

REIN: So I was thinking about a story that ACKOFF told from that lecture. And it's about -- there was a group of 13 students from so-called developing countries in South America, and they really wanted to be a part of a sort of civic development program. They were really motivated to go back to their countries and try to improve things there and so on. But there was no such program at the university. So they went to ACKOFF and they asked "Can we build a program like this?" And ACKOFF said, "Yes, and you're going to teach it." And so they said, "We don't know how to do that. How do we do that?" And ACKOFF said, "Well, you're going to develop a curriculum, and we're going to help you do that. And then you're going to give the lectures, and we're going to help you do that. And then you're going to give the exercises and the exams, and we're going to help you do that. And you're going to give the courses." And so they did. And the people who took the course were a lot of the professors at the university. And every single one of those 13 people, when they left the university, went back to their countries and they got positions in the ministries or secretaries of the interior or whatever sort of position that country had. And they all became leaders of their countries and helping those countries develop. And I just keep thinking about that. And it reminds me that often the best way to learn something is to teach it. And often the best thing for a teacher to do is get out of the way and find ways to support the learners.

BRIAN: And I'm thinking about all the things that you all have brought up during this show, all the really interesting questions. But I spent the last few minutes thinking harder about Jacob's concern about the need for these more complex types of problems to learn things like AWS and learn infrastructure. And I'm thinking that that's going to go on my to-do list and see if there's something I can do about that because it's the second time in the last two months that somebody has brought that up to me. I think that there's an opportunity there. So that's what I'm thinking about, is how do we create more opportunities for people to practice, especially in a community-oriented fashion? Because there are sites like LeetCode and other places, and they'll throw these challenge problems at you. But they're fairly academic fairly, I don't know, uninteresting. It feels too much like a job interview than a learning exercise. So maybe there's a way we can do that better. 

JACOB: I would buy that book, even if it was just a list of problems with no solution at all. [Chuckles]

BRIAN: That's what the Exercises for Programmers book is. But I think bigger than that, I think community. I think that you hit the nail right on the head that some kind of community initiative where we can really get people who have the experience to come up with these semi-realistic problems. I'm going to put them together because I think that works better than algorithmic brainteasers do. 

REIN: Well, those are the things. Those are all the things we had to do to have a successful podcast. 

JAMEY: Check off the steps. 

JACOB: [Chuckles] We did a podcast.

REIN: Thanks, Brian. 

JACOB: Yeah, thank you. 

BRIAN: Thank you all for having me. This was really fun.

JAMEY: Yeah, it was really great to have you on.