Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect. And lately, I've been thinking about the importance of using the concept of a ledger for financial software so that you don't accidentally erase or change history.

[00:00:34] Dave Adsit: I'm Dave Adsit, a VP of engineering. And recently, I've been thinking a lot about cost of delay, economic calculation, homo economicus, and utilitarian philosophy.

[00:00:44] Allan Stewart: Our topic for this episode is prioritizing learning. And for this topic, we have a special guest. Steven Diamante, who we met through the Utah Software Craftsmanship online community, although he actually lives out east. So, Steven, why don't you introduce yourself a little bit?

[00:01:03] Steven Diamante: Yeah. Hey, everyone. I'm Steven, and I'm in Raleigh, North Carolina, working remote since the pandemic. And so I got my start in software on Extreme Programming Team. I was actually a few days just living in Chicago, and I applied to the first programmer job that I saw after attending a meetup downtown Chicago. And it said XP programmer and said Java. And I said, "I know that." I don't know what XP is. And that's how I started my software career. And since then, I've loved the just mentoring, being mentored, mentoring others. And that naturally led me to the craftsmanship community and technical coaching. And so over the past few years, I've been doing technical coaching and running learning hours. So I'd like to talk to you all about that today.

[00:02:05] Allan Stewart: That's excellent. Thanks for being on. So with this topic, to kick off the discussion of learning, one of the first things that we were thinking about is the difference between practicing and performance. And there was something that you said in an online chat that I thought was interesting, that devs are almost always in performance mode and rarely get time to actually practice.

[00:02:29] Steven Diamante: Yep. Yeah, I mean, if you think about other careers, like, my friend's a naval pilot, and he went through so much training where he has to practice all the time before he actually does it for real. I'm a big football fan. If you think about how many coaches they have on the field and the amount of practice they do, and they only play one game a week, right? But for software developers, we're always just pushing, pushing, working on something. We're never, like, maybe, like, outside of work, but a lot of companies don't give enough time for developers to learn and take some time and get out of that performance mode and actually be able to own our craft. And especially learn some of these harder to learn skills like test-driven development, refactoring. Those are things that are better learned by, like, taught by the people that actually are proficient in it. It's kind of hard to take a tutorial of TDD and then say, "all right, I got it."

[00:03:42] Allan Stewart: Yeah. Yeah, really it is.

[00:03:44] Steven Diamante: Yeah. And another analogy, I'm a guitar player and I've probably been playing for about 20 years and I probably haven't improved that much in guitar in the last 10 years. And that's because I don't really take the time to deliberately practice. And so one thing that we don't get in performance mode, yeah, we learn on the job by doing things, but if we don't actually, like, focus on a particular skill and do those kinds of things in deliberate practice, this where you're slightly challenging yourself and getting feedback and all that, you're not really going to learn that fast. And there's also developers out there that they could probably say the same thing. They've been at this profession for 10 years, but they've been doing the same job for 10 years, right? And maybe haven't grown at all, right?

[00:04:39] Allan Stewart: Yeah. So that phenomenon that I've heard described as a one year of experience 10 times versus 10 years of experience.

[00:04:46] Dave Adsit: Right. Exactly. Well, and this comes back to Gladwell's discussion around the 10,000 hours of practice. It takes 10,000 hours to master something new, which that number is kind of, we like it because it's a nice round number. And also it's very large, but the key thing there is is the deliberate practice, right? It's not just doing the same thing over and over and over. The thing that's easy for you, it's, it's reaching a little bit and practicing something that's a little bit harder and then coming back and practicing things that you're good at. And then trying something that's a little harder again and going through those cycles that allow us to stretch and grow and improve overall. I think I've seen that a bunch of times in my career, or times when I'm pushing hard to learn versus times when I'm not. And I've seen it on members of my team. You know, people who have on paper tons of experience, but then when you actually get in and work with them, they are delivering software much like somebody with a fraction of their experience would.

[00:05:51] Allan Stewart: Yeah, I think for me, I've seen a progression because I got into software because I just thought it was fun. I liked programming. It was something that I did kind of almost as a hobby. Took some, I was lucky to have some good classes in high school. And so I just kept, just kept doing it because it seemed like there was good money in it. But then once I started working, then I, I went into that performance mode and it wasn't until I read Uncle Bob's Clean Coder before I really thought about this in a different way about kind of that, the professionalism of practicing your craft. And I think he made an interesting point in that book about, yeah, you might not get time on the job. And so you might have to, if this is important to you, you might have to prioritize it in your own time. But I kind of agree with you, Steven. I think companies would do well to make on-the-job learning time available available because, you know, they're going to get a good return on that investment.

[00:06:57] Steven Diamante: Yeah. And there's also the idea of slack, right? You know, companies that bake slack time into their week, into their month, having some access capacity where, you know, we can be creative on our downtime, kind of take more breaks and kind of let things sink in or just prioritize learning. And you see that kind of feedback into itself, like the more time, like, you know, if we only commit like 70% and we have this time that we can feed into learning, then we get more output, put, which gives us more slack that, you know, kind of compounds. But that's not the mentality these days. It's really grind, grind, grind, sprint, sprint, sprint. And I hate to see it.

[00:07:53] Allan Stewart: Yeah. So in the case of somebody who's wanting to learn and they're kind of just themselves, right? The solo learning space. What suggestions do each of you have for people taking control of

[00:08:09] Dave Adsit: their own career? So one of the things that I tell people is to figure out something that you're actually interested in. Just like you said, Allan, you were passionate about programming because it was fun. And I tell people, find something that you are interested in doing well so that you can, I mean, we talk about T-shape, we talk about paint trip as different shapes that people can can be when it comes to their skill profile. I encourage people to find something that they're very excited about. You really like front-end development. You really like making delightful user experiences and user interfaces. Learn everything you can about React or whatever the toolkit is that you use, right? If you are really passionate about distributed systems and you want to be the network guy and the database guy and work on the backend stuff, get very, very familiar with, spend a lot of time learning those tools. And there's just a lot of techniques you can use. I used to, one of the interview questions I ask everybody is what is the most recent work-related book that you've read? And it is absolutely shocking to me how many people answer something that I read in college. "I don't really read books. It's been a while since I read a book. The last book I read was probably, I don't know, the book that my professor assigned in this one class." That blows me away because I'm a book person. I have tons of books. I'm reading constantly. Most of the people I talk to talk about the projects they're doing. And so that's actually, I think that's actually a very valid way to do it. Building home-based projects, something that you're interested in, something for a family, something for friends, something like you want to automate your networking or your sprinklers or whatever you can, a lot of people do projects. So those are two of the, two of the top ways that I see people learn in our industry through, you know, my experiences through reading what others have written and through hands-on experience doing projects outside of work.

[00:10:14] Steven Diamante: Yeah. I'll definitely echo what you said about, you know, learn something that you enjoy. It's a a lot easier to learn and you'll be motivated to do that if you enjoy it. So definitely that. And with the projects, yeah, I mean, at least with juniors, I think they get stuck in, like, tutorial, just tutorials watching that. But, like, you have to actually, like, have some kind of project that you're building and, like, hitting those roadblocks and actually learning from them. And, um, yeah, definitely reading as well, uh, what I would say, um, is probably in the last, what, 50 years, really nothing's changed about programming. Just the, just the different technology that's available. And so I always tell people to focus on those things, focus on the things that haven't changed in a long time and probably aren't going to change, uh, like, what does good design look like? Like, how do I refactor this messy code into something cleaner and maintainable? How do I make my code more testable? How do I write good unit tests? How do I do test-driven development? And yeah, and those things are hard to learn alone, but they're definitely possible. And when I think about those things, I think of it almost like exercise. Like we all know we should exercise. Like it's good for us. It's, it's something that we know we should do. Like we go to the doctor and, you know, uh, diet and exercise. Right. And, and that's what I think about craftsmanship is it's, it's, it's, it's a steep learning curve, but it's, it's so valuable to, to dive into those topics because they're with you your whole career. If I learn the latest framework or hot new AI library, it's only going to be around for a little bit. But if I learn how to refactor better, that's going to stick with me.

[00:12:26] Allan Stewart: Yeah, I like that. Another tip that I would give to people is even if it's not something you're as interested in, but you keep hearing it at work, it might be a good thing to start looking at. That's how I ended up learning test-driven development. And that's how I got involved with DevOps and learning about what is going on with that community is just because I heard about it at work. It sounded interesting and nobody else was doing it. And so I figured, well, why not me? And so, so yeah, it's definitely harder to pull yourself up by the bootstraps, but, but it can be done. And I feel like there are more resources now, especially online, than, than there ever were before. Or one tip I would give, if you are doing a tutorial, tutorials are great, but, like, explore the edges of it. So they show you how to create a button that does this and it saves it in the database or whatever it is. It's like, "Okay, great. Now pause the video or whatever and do it yourself and now do some variations of it, right?" It's like, now the button's a different color and now it saves two entries into the database database or whatever it is that helps you expand what you were doing. But ultimately, I think that solo learning, it is hard because it requires you to kind of take the impetus for yourself and say, "this is something that I am going to do and it matters to me." And so whenever possible, I do prefer group learning sessions because it kind of gives you motivation, right? Right. It's, if, if learning is like going to the gym, well, you need that gym buddy to come and help you learn. So maybe real quick, Steven, you could give us kind of an outline of the learning hours, stuff that you do with your teams.

[00:14:17] Steven Diamante: Yeah, sure. Yeah. So learning hours are for teams. I mean, not just software teams that can really, it's just a structure, basically. So there's a 4C model that comes from Sharon Bowman's Training from the Back of the Room!. And so the 4Cs are connect and concept, concrete and conclusion. So the first part of the learning hour, I usually talk about the learning goals. So that's usually two to three kind of focuses of the hour. Sometimes learning hour is more than an hour. But yeah, so connect is an activity where, you know, all people have different experiences, they come into the session knowing different stuff, so we want to make connections on what you know and what concept we're going to learn today. So sometimes it's tangentially related, sometimes Sometimes it is kind of what the topic's about. Some examples of these could be like, I like true false. There'll be like 10 true false questions, maybe like misconceptions about refactoring, right? And, like, a lot of these learning hours are, like, refactoring, TDD. It's kind of harder things to learn that I was talking about. Sure. Yeah, so that's the connect. And it's usually maybe 10 minutes, no more than that.

[00:15:50] Allan Stewart: And that just kind of gets people engaged in the topic.

[00:15:54] Steven Diamante: Yeah.

[00:15:54] Allan Stewart: They're not starting cold.

[00:15:56] Steven Diamante: Yeah. And sometimes that's breaking out into pairs, you know, leveraging breakout rooms. I do these basically only remote. So, you know, like corners of the room, you know, if you're like all together. Yeah. Or just as a group and just talking about, just kind of talking about, you know, it could be, like, fill, I do, like, fill in the blanks. Sometimes there's, like, web hunts. "All right. Everybody get into pairs. We're going to learn about code smells and everybody, like, research two or three code smells and then come back and tell the group about it." Like that's one example, um, right? So after connect is concept, so all learning hours are very, like, fine-grained micro skills, so we're not going to have a learning hour about TDD, like, maybe, like, an intro to TDD, you know, but, like, we want to, like, dive deeper than that. Like, all right, not just TD, we're doing a learning hour on fake it till you make it, like, just, we're just gonna do, like, extreme dream, fake it till you make it or something and just do that. Or we're doing refactoring, but we're not just doing refactoring. We're doing "Naming as a Process." We're only going to be improving names, things like that. So it's really micro skills that we focus on. And so in that concept, that's when the facilitator, the technical coach, whoever's leading it, will take maybe 10 to 15 minutes, maybe they have slides. I don't, I don't usually do slides. I normally set up a mirror board, I kind of have some bullet points, and I just generally talk about the concept. This is what it is, maybe this is my experience with it, and, um, and also definitely always asking questions, like, I don't want to be lecturing to people, so it's always very interactive. I try to make it as interactive as possible. Like, let's talk about this stuff and let's, let's learn from each other. And after the, uh, after the concept, that's when the most important part, concrete, that's when we put that concept into practice. We may do that through a, usually through a coding kata. So we will either break into pairs or as a group, I do ensemble programming and, and rotate everybody everybody around and everybody gets a chance to, uh, to interact with that new micro skill that we learned. Right. Hands-on. Yep. Hands-on activity and try to get that, like, 30 to 40 minutes of, of the session. And, um, and then always at the end leaving time for the last C, which is conclusion. And that's just the mini retro. Uh, maybe it's like one big question, you know, what's your, What's your takeaway for the session? And maybe, you know, how did that feel? You know, what is this going to change for you going forward? Because what we really want to do these learning hours, we want to learn some new skills. We want to practice them. But ultimately, we want to take those new skills and apply them to our context. We want to go to work tomorrow and start writing the test first. We want to start improving the maintainability of our code, things like that. So, like, how can we do that? And all of this 4C and all the way Learning Hours is designed, it's all about learning. Like, I don't want to just talk to you about it. My goal is for you to walk out learning something. So it's all designed about how the brain works and how we can absorb the material and apply it. And the best way to learn is by doing the thing. And next best is to teach the thing. So if I can get the people in the room starting to teach each other, that's even better. And that's why we work together on these things.

[00:20:13] Allan Stewart: I like that. I think that is more intentionally structured of a learning meeting than I have often done. Sometimes I've been responsible for teams learning. And honestly, sometimes I've just done different code katas, not with as much intention. It's just like, "hey, let's spend some time practicing." I think that that was valuable still. But there's definitely things you can do to improve that learning outcome. And I think it also depends on what you're trying to accomplish as far as the purpose of the group learning. Right. So I think there are cases where you do want to have it be a little bit more top down. Where there's somebody, I don't know if it's a manager or a tech lead or somebody who is picking these topics and kind of driving it forward. But I've also seen some really good experiences with peer to peer trainings. I'm thinking Dave and I worked together a company where we had a training, which we tongue-intrigued named "Expert Beginners." Nice. So maybe you can tell us a little bit about that, Dave. Remind me, why did we call it "Expert Beginners"?

[00:21:25] Dave Adsit: We were talking a lot about skill acquisition models. And one of the things that came up is that there are different levels of skill acquisition, right? You've got your beginner skill, you've got your kind of breakout and competent and proficient, and then you've got your experts or your, like, your mastery levels. And we refer to it as "expert beginners," partially because, you know, we're all at a different point in our journey, our learning path and our career development path, but also kind of to make it okay to bring something that you have not fully mastered and share it with a group. You know, one of the things that we did, the way we ran that follows a similar pattern to some of the other things that we've done. We had a very common practice of starting the meeting with lightning talks, which are zero to five minutes on any topic you think will be interesting to the group. And we used a timer and we would clap you off the stage like it was the Oscars if you tried to go over your five minute time limit. It. And we would do, depending on different things that were going on, we do one to three of those per week or zero to three, really. Nobody showed up ready to present anything. We just would skip it. And then we would do something else that was peer to peer. And we, I think we tried to follow some of the concepts of, like, let's do a, let's do a workshop. Let's do some training. I just, I don't think we had the level, same level of rigor about the topic because it was whoever ever brought it could present. But yeah, that was something that we did when we worked together, Allan. It's actually something that I continue to on my teams today. I have basically an open hour once a week that is for all of engineering to come and do peer-to-peer training. And we do it that same style of zero to two lightning talks and then something. And we have a preference for do something hands-on, but it's definitely not a hard rule because it feels like it takes a lot more effort to put together a hands-on training than it does a slide deck type of training.

[00:23:38] Allan Stewart: One of the things that I really liked about the expert beginner expert beginners also was that, even though it wasn't as effective and all the time, one side effect that I noticed is that people's presentation skills improved. And so I think depending on what you're wanting to learn, what you're wanting to accomplish, there can be a variety of ways to kick something off and have something that is useful and meaningful.

[00:24:07] Dave Adsit: One of the things that I've experienced with working with different groups is that some groups are composed of people who are very active and and proactive in terms of their own career and their own learning and development. And they will gravitate towards things like this and take advantage of the opportunity to put together trainings. And, and some people have learned the lesson that "if I want to learn something, I should teach it, right?" And that is where you're going to learn the hardest and the fastest is when you know you're going to be presenting that to, to your peers. And so I've seen that as a way that certain teams behave. You know, kind of the culture of the team is, we're all always learning and we're sharing with each other what we learn. And that's fantastic. And I've seen other teams where the culture is a lot less developed in terms of peer-to-peer training. And you kind of have to pull it. It becomes a struggle to fill the sessions and have something to share on a weekly basis. And in those cases, I found myself as a leader or a manager on the team, filling in a lot more than I prefer in the peer to peer training.

[00:25:23] Steven Diamante: Yeah, I definitely related to that teaching. Teaching leads to learning. My second year of being a software developer, I led my first TDD workshop. And I don't think I really understood. I mean, I started my career doing TDD. But looking back on that workshop, like, I didn't really understand. I was like level one, like, TDD, like, I, I, I, I grasped the basic concepts, but, like, starting to teach people, like, because from there I went on to teach more people and, and mentoring people, and, and I was, you know, when you need to prepare the presentation and and people start asking you different questions, like, somebody asked me, "so how do I approach TDD on legacy code?" And I was like, "ah, I had no idea." So I had to go back and figure all that out. And then I picked up Working Effectively with Legacy Code and got into all of that stuff too. And so, yeah, it puts you in a position to learn the other things that you need to learn. So it's been fantastic for my career and for my life in general, for sure.

[00:26:43] Allan Stewart: One thing that I have noticed that applies both with giving presentations generally, but also with training, is that if you can put yourself in the mindset of, "I am sharing what I know, and I am not the expert of it. I don't know everything, and I'm not pretending that I know everything." That helps a lot because it kind of, it gives you, you give yourself permission to say, "I don't know," or to ask somebody else or to say, "hey, you know, it's fine. Let's figure this out together." Other, or maybe I'm going to have to go and think about that and come back later. Because otherwise you can get into kind of a paralysis where you're just like, "oh, I might not know the answer because I, you know, I recognize that I am just level one. And so I'm not going to do anything." And then, and then you don't see any progress. You don't see any improvement. You have to take that step to say, "I'm going to go out and try it and hope that I'll get get better as we do more and more of it."

[00:27:47] Steven Diamante: And I actually ended up coming back to that same group. It was a Java community of practice at my work, and it was outside of our XP bubble that we had. So they're all doing things the traditional way, I guess. So after I said, "okay, legacy code, how do we apply TDD to legacy code?" Because that's their context, right? They don't know how are they able to apply it there? And so I took that as a challenge and I came back to them three months later and I delivered a talk about how to apply TDD to legacy code. And still, I had no idea what I was talking about, but I learned so much from it. And they also, I mean, I knew more than them, right? And that's all you need to do. You just need to know a little bit more and just be a little bit ahead head. And I like that, Allan, about, you know, "I'm not the expert. I'm just, I'm just here teaching you some stuff that I, I know, or I'm sharing my experience."

[00:28:52] Allan Stewart: Yeah. Well, and I've even found in some cases, things that I do know a lot about, somebody who knows less about it is sharing and presenting. I still learn something from it, or I, or I get a new lens into how I can look at this topic that I haven't encountered before. So I think you don't, you don't have to even know more than the people you're presenting to.

[00:29:14] Steven Diamante: Very true. Yeah. Cause I mean, that happens a lot with learning hours. Um, and, and yeah, so, so the learning hours that I've delivered, I've always been like the most senior person on the team. And so I've kind of been that one to organize them, but, but I always leave it open. Like, uh, you know, "if anybody has a topic, please, please come and give me a week off," you know? Like, cause I was doing them every week, maybe an hour or two every week.

[00:29:45] Dave Adsit: Yeah, I've definitely done that as well when I've been in various leadership positions where I feel like, in order to skill the team up quickly, I need to present on a lot of topics that they may not be familiar with yet. And it can become overwhelming if you're the only one presenting week after week after week. On the other hand, you do build up quite a nice library of training topics and presentations that you can pull out at the moment's notice and present on because you've already done it and maybe practiced it two or three times. So yeah, it's developing a skill in a different direction, I guess, versus the skill of writing code. You get the skill of teaching others how to improve code or write better code.

[00:30:29] Allan Stewart: So we've mentioned a couple things already when it comes to, like, how do you make these sessions work well? How do you improve learning outcomes so that it's not just everybody coming to the meeting and nobody really says anything and nobody wants to participate. And then it just kind of ended up being a waste. So we talked about hands-on. We talked about kind of the 4C model from Training from the Back of the Room!, right? The connect, concept, concrete, conclusion. You had also mentioned something in a Slack message, I think, Steven, about six trumps. Could you tell us about that?

[00:31:08] Steven Diamante: Yeah, so this is also from Sharon Bowman. It's kind of a, not a book, more of an article, "Six Trumps Using Brain Science to Make Learning Stick." So, and a little background about learning hours. So Emily Bache, she's a technical coach and she wrote a book. First, she wrote a book, Coding Dojo, Coding Dojo Handbook. And she's from an XP background, and that's how she was learning with people and training people. And eventually she met Llewellyn Falco and started coaching with him. And he kind of did this learning hours kind of thing, just didn't have a name on it and, you know, kind of did it. And so she took that and kind of bundled up and slapped a name on it called Samman Coaching. And so And so there's a book, her second book, Technical Coaching with the Samman Method. And so in that book, like, that's where I learned more about the Training from the Back of the Room! concepts because she has a lot of those. And in there, she talks about the six trumps and they are movement trumps sitting. I don't get to do this one too much because we're remote. And I mean, I have a stand up desk so, like, I don't have people, like, walk around the room, but, you know, in, and Emily doesn't talk about this too much either, but, I mean, if you think about it, like, the way the brain works, um, when we exercise, we actually remember things better. Um, there's, there's, uh, the connections in our brain that are formed when we exercise. And there's a lot of brain science behind that. So to get people moving around and talking with each other, and that's kind of things. So it's just that we should kind of prioritize movement and not just have people sitting all the time. So just having people get up every 10 minutes or so, that's the advice. Talking trumps listening. So definitely try to do this. I don't want to be the one talking the whole time. I want other people to talk to each other and have people make connections, learn from each other. And so it's not a lecture. And Training from the Back of the Room! is like all about, it's a lot of focus on corporate training. So they're like, you know, instead of having a trainer come in and just dictate to people, like, have, you know, ask them some questions, start getting them to talk to each other. So, uh, talking trumps listening, we have image trumps words. And I mean, we've probably heard that on, like, you know, PowerPoint presentations, we don't want a bunch of words there. And, um, and you know, with images, you know, um, yeah, you just, it, something about, like, uh, an image just sticks with you more than just the words. And so it's all about, like, a lot of this is, like, so that the training sticks, so that the learning sticks, right? Uh, writing trumps reading. So a lot of the times when we do the retro, um, instead of me writing down every thing everyone's saying, like, they need to be the one writing it. Uh, unfortunately, because I'm doing remote, they're typing it. It would be better if they would write it on paper, because that's even better for remembering the stuff. Something thing about the tactile movement, um, it, it enforces the learning even more. But, um, it is just better to interact with the material, actually, like, write something down. Uh, shorter trumps longer. So all of those, um, different sections, like the four C's, um, they're pretty short and they have, uh, like, we don't want, yeah, besides maybe the concrete, which is the most important part, we don't want any of of them kind of going on for too long and boring people. And, uh, different trump same, and this is just about, uh, kind of, I don't know, kind of like shocking material to, like, make it stick. You, like, I read this one book about learning, and they were, uh, explaining, um, about the, about the different connections in your brain using, like, an alien that, you know, just this kind of, like, if you can put some kind of weird cartoonish thing and something odd, is those kind of images kind of stick. So that's what that's all about. I don't use them all, and I can't really use them all. The big ones are talking trumps listening, um, writing trumps reading, and shorter trumps saying name, shorter trumps longer. So those are the ones I try to focus on in my learning sessions.

[00:36:20] Dave Adsit: Yeah, I can definitely relate to those concepts and some of the training that we've run in the past and things that we've done to enhance people's learning. I think it really is a bummer that we are all working remote these days and don't really get the opportunity to use the movement one. I found that to be a very powerful way to get people engaged and keep them engaged in a training, is say, "okay, we're going to talk about personality types. Everybody who's an E on this side of the room, everybody who's an I on that side of the room." Okay. We're going to talk about one of the ones that we've done a few times to great effect. And people still talk about, even though the last time we did it was easily a decade ago, is the duck passing exercise where you you have rubber ducks and you give people rules on how the rubber ducks have to move through the room. All the rubber ducks with a top hat have to be touched by everybody in the room in order from tallest to shortest. And everybody, every rubber duck that is holding something has to be passed through the room and touched by everybody from according to birthday, your your birthday on the calendar year? Is it, you know, are you a January birthday or a December birthday? And they have to go in order that way. And that I've definitely felt that those types of exercises stick with people a lot longer than the ones where you're like, "here's some paper, sit at a desk, I'll read it to you and you just listen." So I really, these concepts really really resonate with me for improving the training that we're doing.

[00:38:00] Allan Stewart: Another way of improving learning outcomes that I personally enjoy is simulation. So anything that we can do to make things a little bit more like, like real work, right? I think one of the things that will happen sometimes is that we get into a training and we don't understand how to apply the concept back into work. And I think, Steven, And you had some interesting comments about that as far as, like, not going too broad, but, like, being very specific in the concepts that you're teaching in your learning hours. But I've also found that we've done some exercises in the past where, like, we would role play out a system. And that can be very interesting way, especially when we start talking about distributed systems and we're talking about APIs and message passing. Those, those can be very abstract concepts, but so then we, we plugged something into it, so it's like, "okay, well, API means that you have to go and talk with another person, so somebody's going to represent the customer and somebody's going to represent the, um, the user interface and somebody else is going to be the API." But when we're, when when we do message passing, well, we're going to actually literally write something down on a post and pass it to somebody else. And, and we've even done a couple of these in a, in a digital way, right? So instead of a, instead of a post, it was a Slack message because we're all remote. But it's still, I feel like it helped, helped people understand the system. Or another one that I think about a lot is we'd done some exercises around messaging systems and, like, you're actually using the messaging system, right? It's like you're interacting with code, but it's not in our actual production environment. It's just something that somebody's got set up, right? I think back in the day, we had a Rabbit server running on somebody's laptop, and we all interacted with RabbitMQ and passed messages back and forth. And again, it's helping learn, it is hands-on, but you're working in somewhere in between complete toy project or, like, code kata that you start from scratch, but you're also not in your production environment where you have not, it's not about, like, the, the, the risk of working in production, but it's just the, the overwhelming size of all the restrictions that are in production. So that's, that's another way that I've found can make things engaging and, and applicable, so that that people retain it a little bit better.

[00:40:40] Steven Diamante: Yeah, I mean, that role playing, that's definitely different. That's different trump saying right there. I mean, that kind of activity will definitely make that learning stick.

[00:40:50] Dave Adsit: Yeah, I think that some of those exercises that we've done have really stuck with me for a long time as well. And there are some ways that you can take some very complex topics and simplify them down to a point where people can actually engage with them in a one to two hour long training workshop.

[00:41:07] Allan Stewart: shop. So a question I have here then is, I mean, these are good stories, good memories. I like the idea of it, but why? It also sounds like a lot of work, right? And having come from doing this at various companies, I know that it can be a lot of work. So why bother? Like, what benefits benefits have, do we see from investing this time into the learning?

[00:41:35] Dave Adsit: Well, I'm just going to pull out a famous business quote that may or may not have really happened where the, the CFO says to the CEO, "Hey, if we spend all this money on training, what if these people leave?" The CEO turns back and says, "What if we spend all the, what if we don't spend any money on training and they all stay?" Right. Like, Like, I think we owe it to ourselves and each other to constantly be uplifting the quality of the skills, our skills, our ability to deliver, our ability to understand and reason about and solve problems. We owe it to ourselves to get better at that. And we owe it to each other to be better teammates with regard to that. And so for me, this is something that I find essential from my role in leadership. I always implement some form of peer-to-peer training and also leadership-led training with all of my teams. And it's because of that, the fact that there's always something more we could all know and to be better at the jobs. And I want my engineers to be fulfilled in their job. You know, we talk about motivation, autonomy, mastery, purpose. Mastery is definitely one of of the things that motivates people to stay with a job and to stay with a company and team, right? And so from a leadership perspective, selfishly, I want my team members to stay, but I also want them to get better because I want them to master their craft and deliver a higher quality in a sooner timeframe over and over and over and over. And so these are things that I find to be essential for any team that I'm leading. But I've also worked on teams where this was not prioritized, in which case you have to do it yourself.

[00:43:27] Steven Diamante: Yeah, so when I first learned about Learning Hours, then I got an opportunity to actually put it into action. So I joined a new team that they were all consultants consultants and we are expected to work in an XP like way, using test driven development and pair programming. None of the consultants were very experienced with either of those. And so the technical lead was concerned and they brought me in to teach them. And so I started started learning hours with them. And within six months of doing that, they went from, I mean, they eventually ended up being one of the highest performing teams in that part of the company. And we were deploying once a week, at least, and it's just a constant rhythm. And so why do I do this is to build high performing teams because I want to be on those teams. And if I don't have those, if we're not high performing now, I know ways we can get there and let's try to get there together. And yeah, just like Dave said, I mean, our profession is all about learning. We need, we constantly need to be growing. And also it does feel very good to have that pursuit towards mastery.

[00:45:05] Allan Stewart: And in this industry, stagnation happens so quickly. It is very hard to rest on your laurels and say, "hey, I figured it out. I know how to do this thing. Don't worry, everybody. I know how to write XSLT transforms."

[00:45:21] Dave Adsit: "Don't worry, guys. I am VB6 certified. We're all good." Exactly.

[00:45:28] Allan Stewart: Exactly. So, so yeah, I, I, I'm totally agree with, with both of you. And I really liked that quote. I'd forgotten that one, Dave, the, you know, what, what if they stay, right? Like, we want, we want people who are going to engage and not just be there for the paycheck, ideally. So these are, these are big benefits. And I think there are, there are lots of evidences of why it is useful, right? It's like, Dave, as a leader in your companies, you've continually done these things, right? Um, various corporate training programs exist for a reason, right? We want to have skilled professionals working. So if you need to get started, I think that step one is just saying, "hey, I'm gonna do something about it." And, and I think that this can apply to everyone. There have definitely been phases in my career where, even knowing how important it is to continuously learn, I'll just be so busy, right? Something will happen in my personal life or we have this big project that just needs to get done, and I just keep working on it and keep churning on it and don't really, the learning just kind of falls off, right? It wasn't intentional, it's just, it dropped off. And so I think that that first step is decide, "hey, this is important. Let's do something about it." So we mentioned some things to do for solo learning, right? Code katas. There's plenty of code katas that you can find out on the internet. You can practice test-driven development. I like architecture katas. I like software architecture a lot. I think that that's a a really interesting one that I hadn't been exposed to for a long time until I heard about them. I think Neal Ford was doing them in a conference setting. And that was really interesting. The, you know, the pet project that you've got, or, or you could do, like, Dave, you've told us before about your mentor who took your mouse away. So you'd learn keyboard shortcuts. Yeah, those fun times. So, so there's definitely some, some ideas for things you can try. But if you wanted to get something going in a group, what does, what suggestions do you have? How do you get, how do you get this beyond just yourself and say, okay, I've decided this and I'm motivated, I'm learning something, how can you bring that to other people and get them to engage and participate? Um, yeah, so

[00:47:58] Steven Diamante: uh, in, in regards to learning hours, because that's just what I'm going to focus on, is, there is someone online coaching society, um, started by Emily Bache, I talked about before. Um, she has a bunch of free resources, and this is what I used when I started these. Um, I don't always use them as, I, as I've been going along, I start to kind of create my own as I kind of, like, understand the style. Um, but yeah, um, They have learning hours sort of by topic. There's small steps, test design, refactoring, BDD, legacy code, working in an ensemble. Even DevOps is up here, code reading. So there's all kinds of things that you can dive into these. A bunch of katas listed on this site, too. And it kind of guides you through it all. Um, in addition, uh, Emily started a YouTube channel, and she does guided learning hours so what those are is she'll, she'll basically, you do it with your team, and then you just pause the video, do an activity, come back, and then she'll explain it to you, right? So it's like you have a technical coach in the room with you, and I've ran those with my team as well, and And I think they're really great. Definitely awesome to just kind of get started with that kind of stuff.

[00:49:28] Allan Stewart: Nice. Yeah, it's definitely nice to have something like that, too. If you're not prepared for some reason or, like, you're feeling overwhelmed, you could say, "hey, well, you know what? Somebody else has done some of this work and we can, we can just put up the video and get some, get something meaningful out of it."

[00:49:47] Steven Diamante: Yeah. Yeah, another thing I do when I'm in that situation, like, it's like, "ah, I just don't really feel like doing it this week." So I just, I put on a conference talk. Like, it just, we've watched "Bug Zero" by Arlo Belshee. We've done, one of my favorites is "Practical Refactoring." Woody Zuill, Llewellyn Falco. That's an amazing talk. And that's two hours of them live coding. And so what I do is, like, we used to do two hour learning hours, so we would watch, like, half of it and then we'd spend the other half, like, doing all the refactoring they just did and, like, catch up to where they got. And then I'll do, like, another session, we'll watch the second half, do the same thing. So we watch them do it, and then we do it. Could definitely flip that as well, but yeah, yeah

[00:50:43] Dave Adsit: Yeah. So one of the things they say in community building, one of the things that they often do is bring food. People like food. If you're truly trying to motivate people, nothing but motivates people quite like free food for some reason. But keep in mind that once you do that, you're stuck with it forever. So for some of the public communities that I've participated in, and some of them have had sponsors that order pizza or Chinese food or something. And other groups have intentionally stayed away from it and said the learning should be motivating on its own. And you definitely get a different number and caliber of developer at those groups. Not everybody is intrinsically motivated to learn all the time. And a little bit of extrinsic motivation can go a long way. And, but then you also have some people who are very much intrinsically motivated to learn. And those people become the core of whatever training and development community you have, whether it's inside your company, outside your company, or wherever. One of the things that I've used in leadership is, I can say, I will say, "hey, we're going to have this. It's optional. You don't have to come. You can participate if you want. You can present if you want, whatever." Ever. But then if we aren't going to have people participate, then we probably lose it. And that will be a motivation. It's not my favorite. I don't love to use the stick as a motivating technique at work, but sometimes it works. And then once you get into the habit, things start to flow a little bit better. I also, for my leadership led trainings, I do not treat them is optional. They happen during our weekly engineering all hands. And so they're considered a mandatory meeting for all of the engineers. And so that's an opportunity where we may have a shorter period to work through a topic, but we try to introduce things there that we want people to go and learn deeper on their own or with their teams.

[00:52:50] Allan Stewart: Yeah. There've been a couple of cases where I've seen that when there isn't leadership support. Like, oftentimes you can get leadership support because training is important to leaders. But when there hasn't been even just sort of, like, a brown bag lunch, or I guess in the era of Zoom and remote, it's like, "hey, let's, you know, pick some off hours where we normally wouldn't be on. We would normally be at lunch and we're just going to do something, right?" Right. Like, everybody going to bring their food to their desk, and they can turn their camera off while they're shoving food in their mouth if they need to or whatever. But just kind of making that time often works if it's not, not too onerous. And I've seen that once the effects start to play out, it'll oftentimes turn into something where it gets adopted by leaders to say, "hey, we see what you're doing and it is good. Let's make it part of the workday and not just this extracurricular thing that's going on."

[00:53:55] Steven Diamante: Yeah, I was lucky enough to be on teams that allowed me to bring these learning hours um, and to do them during the workday, um, and to always put them on the schedule, and, um, yeah, sometimes we cancel them. Um, there, there were some delivery priorities that come up and I always made them optional. I said, "you do not need to come to this, but if you want to learn, this is where learning is happening." So people enjoyed them so much that they wanted to show up. So I never wanted to force anybody to show up, though.

[00:54:32] Allan Stewart: Yeah, it can be difficult. I feel like it's not super common, but there are definitely times where I've encountered people who just don't seem to want to learn. That it's not engaging to them or they've got something else going on in their life that is just kind of preventing them from really engaging or participating. So I don't know. Any thoughts about how you engage those people?

[00:54:56] Dave Adsit: Yeah, it's a good question. I am reminded of Kim Scott's book, Radical Candor, where she talks about how we have different phases of our career, where sometimes we are the superstars and sometimes we're the rock stars. And I feel like those two are almost synonymous. So I always get this confused, but one of them is constantly striving for the next promotion, the next thing. And the other is maybe busy enough with other parts of their life that they are content to come in and deliver at a high level and then not push for that next big thing. Sometimes that's okay. I will say that what I want to build is a culture of learning on my teams. And a lot of that goes back to how you're hiring and who you're hiring for. It's part of the reason why I'll always ask somebody what they do to stay current with the industry. What's the most recent job-related or work-related book you've read? What's a conference you've gone to? I'll ask people questions about their learning and their learning style and what they're doing as part of an interview process. Because I feel like, you know, there are different people who have different aspirations. And I want to put together groups of people who are striving to learn and improve and will make this a priority for themselves and the rest of the department. So I think some of it starts with accepting that we are all going to be different. And then focusing on how opinionated you want your engineering culture to be or the group of people that you spend time with or whatever.

[00:56:37] Steven Diamante: Yeah, I mean, yeah, so all I can control is creating a learning environment. Um, and that's fun. I always try to bring fun to the teams, and, like, we all got into programming because it's fun, so I try to inject that fun back into the team. And, um, but I can't control, I can't control other people and so if they, if they want to show up, they're going to show up. But if they're in the stage of their career or they just aren't prioritizing this, I don't think it's my place to really try that hard to convince them. So whoever shows up is the right people. That's, yep, that's right. Well,

[00:57:24] Dave Adsit: And one thing to be said is that feeling like you're falling behind your peers is a good

[00:57:28] Steven Diamante: good motivator to go do something about it. Yeah, yeah. So, so, uh, the first team that I did this on there were two senior developers on there. Um, and, and they were often pulled away to other meetings, sometimes they couldn't make it, but then, then they basically just stopped showing up completely, and so those two seniors I saw, I saw all the other developers kind of just, like, laugh them like, they, they started, like, refactoring, and I just, I was comparing, like, full requests. Like, I just saw a clear difference on how much, um, the other developers had learned over that period of time compared to the seniors that weren't going to these learning sessions. And, um, yeah, so they, they they were not motivated by any of that, and I didn't call it out or anything, but it's just something I noticed.

[00:58:25] Allan Stewart: Nice. Well, that takes us back to one of the ideas we kind of opened with, and maybe this is a good way to wrap up, is to say that if you're always in performance mode, it's very hard to improve. Making some time, even if it's just a little bit of time to practice, to do something different, to do something fun that kind of re-energizes you, helps you learn, just makes you want to be doing the work that you're doing again. It's so beneficial, and it's something that I think everybody can, can benefit from. I've been

[00:59:03] Steven Diamante: reading Training from the Back of the Room! I had never read it before. I only read it in the context of someone coaching. And so there's one quote from there is that, "do you want them to hear it or learn it?" So I think when we're designing our learning sessions, like, what are you optimizing for? Right. And just, and just to think about that, like, do you, do you want to stand up there and just tell everybody what you know, or do you actually want them to come away with some knowledge and put that knowledge in and apply it?