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, Stephen Diamante, who we met through the Utah Software Craftsmanship online community, although he actually lives out east. So Stephen, why don't you introduce yourself a little bit?

[00:01:03] Stephen Diamante: Yeah. Hey, everyone. I'm Stephen, and I'm in Raleigh, North Carolina, working remote since the pandemic. And so I got my start in software on Extreme Programming Team. It 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. I think 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:04] Allan Stewart: That's excellent. Thanks for being on. So with this topic, kind of 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 onto a lot of things on a daily basis. almost always in performance mode and rarely get time to actually practice.

[00:02:29] Stephen Diamante: Yep. Yeah. I mean, if you think about other careers, like, 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, they do, and they only play one game a week. Right. But for software developers, we're always just pushing, pushing, you know, 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, 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] Stephen Diamante: Yeah. And another analogy, I'm a guitar player and, um, I 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, um, you know, do those kinds of things in deliberate practice where you're slightly challenging yourself, 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. Right. Exactly.

[00:04:48] Dave Adsit: Well, and this comes back to the, to Gladwell's discussion around the 10,000 hours of practice. You know, 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 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, 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 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. Um, 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. Um, but then once I started working, then I, I went into that performance mode and it wasn't until I read, uh, uncle Bob's, uh, 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, uh, but I kind of agree with you, Steven, I think companies would do well to, to make on the job learning time available because, you know, they're going to get a good return on that investment.

[00:06:58] Stephen Diamante: Yeah. And, and there's also the idea of slack, right. Um, you know, companies that bake slack time into their, um, into their week, into their month, um, having some access capacity where, you know, we can be creative on our downtime, um, and I take more breaks and kind of, and I let things sink in or, or just prioritize learning. And, 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, this time that we can, uh, feed into learning, then we get more output, which gives us more slack that, you know, kind of compounds. Um, but that's not the mentality these days. It's, it's really grind, grind, grind, grind, sprint, sprint, sprint. And, uh, I, I hate to see it. Yeah.

[00:07:54] 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. Um, what suggestions do each of you have for people taking control of their own

[00:08:09] Dave Adsit: 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, 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 be when it comes to their skill profile. Um, I, 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 and, and, or whatever the toolkit is that you use, right? If you are, you know, really passionate about distributed systems and you want to be the, 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. Um, 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, it's 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, my professor assigned in this one class that, that blows me away because I'm a, I'm a book person. I have tons of books I'm reading constantly. Um, most of the people I talk to talk about the projects they're doing. And so that's actually what I think that's actually a very, very valid way to do it. Uh, 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] Stephen Diamante: Uh, yeah, I'll definitely echo what you said about, um, you know, learn something that you enjoy. It's a lot easier to learn and you'll be motivated to do that if, if you enjoy it. So definitely that. Um, and with the projects, um, 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, and like hitting those roadblocks and, and actually learning from them. And, 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? Uh, how do I refactor? This messy code into something cleaner and maintainable? Um, how do I make my code more testable? How do I write good unit tests? Um, how do I do test driven development? Um, and yeah, and those things are, are hard to learn alone, but, um, they're, they're definitely possible. And, um, and when I think about those things, I think of it almost like, 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, you diet, 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 your whole career. If I learned the, the latest framework or hot, new AI, library, it's, 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 if, 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. Uh, and that's how I got involved with, uh, dev ops and learning about what, what is going on with that community is just because I, 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, uh, 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. Um, one tip I would give if, if you are doing a tutorial, tutorials are great, but like explore the edges of it. So they, 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 is a different color and now it saves two entries into the database or whatever it is that helps you expand, um, what you were doing. But, um, ultimately I think that solo learning, it is hard because it really, really 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? It's, uh, if, if learning is like going to the gym, well, you need that gym buddy to come and help you learn. So, uh, maybe real quick, Steven, you could give us kind of an outline of the learning hours, stuff that you do with your team. Yeah,

[00:14:18] Stephen Diamante: sure. Um, yeah. So, uh, learning hours are, uh, for teams. I mean, not just software teams that can really, it's just a structure basically. So there's a four C model that comes from Sharon Bowman's, uh, training from the back of the room. And, um, so the four C's are connect and concept, concrete and conclusion. Um, so the first part of the learning hour, I, I, I usually talk about the learning goals. So that's usually two to three kind of focuses of the hour. Um, sometimes learning hour is more than an hour. Um, but, um, yeah, so connect is an activity where, uh, you know, all, 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 it is kind of what the topics about, um, some examples of these could be like, I like true false. There'll be like 10 true false questions, maybe like, uh, misconceptions about refactoring. Right. And, 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. Um, yeah, so that's the connect. Um, 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. Yeah.

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

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

[00:15:56] Stephen Diamante: Yeah. And sometimes that's breaking out into pairs, you know, uh, leveraging breakout rooms. I do these basically only remote. So I, you know, like I'm corners of the room. If you, you know, if you're, if you're like all together, um, just as a group, um, and just talking about just kind of talking about, um, you know, uh, it could be like, Phil, I do like fill in the blanks. Uh, 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, 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 TDD, we're doing a learning hour on fake it till you make it like just, we're just going to do like extreme fake it till you make it or something. And, and, 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, um, things like that. So it's really, uh, micro skills that we focus on. And so, so in that, uh, concept, uh, 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 then 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 together, 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 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? Um, and, and maybe, you know, you know, how did that feel? You know, what is this going to change for you going forward? Cause what we really want to do. He's learning hours. Uh, we, 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, we want to go to work tomorrow and start writing the test first. We want to start improving, uh, the maintainability of our code, things like that. So like, how can we do that? And all of this. Four C and all the way learning hours is designed. It's all about learning. Like I, I don't want to just talk to you about it. I want, 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. Yeah. 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, of a learning meeting than I have often done. Um, sometimes I've been responsible for teams, uh, learning and some, and honestly, sometimes I've just done different code. Um, not, not with as much intention as just like, Hey, let's, let's spend some time practicing. I think that that was valuable still. Um, but, but there's definitely things you can do to improve that learning outcome. And I, and I think it also depends on what you're trying to accomplish as far as the purpose of the group learning. Right. So like, 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. Um, but I've also seen some really good experiences with, uh, peer to peer trainings. Uh, I'm thinking, uh, Dave and I worked together at a company where we had a training, uh, which we tongue and treat named expert beginners. Nice. So, uh, maybe you can tell us a little bit about that. Dave, uh, remind me, why did we call it expert expert beginner? Uh,

[00:21:26] Dave Adsit: we were talking a lot about skill acquisition models. And one of the things that came up is that there's, you know, you, 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 referred 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, um, follows a similar pattern to some of the other things that we've done. We, we had a, uh, 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, um, 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, uh, let's do a workshop. Let's do some training. I just, I don't think we had the level, same level of rigor, uh, about the topic because it was whoever brought it could present. Um, but yeah, that, that was something that we, 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 strata, 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 beginning expert beginners also was that, uh, even though it wasn't as effective and all the time, uh, one side effect that I noticed is that people's presentation skills improved. Um, and so I think depending on what you're wanting to learn, what you're wanting to accomplish, there can be, um, a variety of ways to kick something off and have something that is useful and meaningful. Well,

[00:24:08] 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 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, uh, 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, 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, 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. Yeah.

[00:25:25] Stephen Diamante: Yeah. I definitely, I definitely related to that teaching, um, teaching leads to learning, um, like, uh, my second year, um, of being a software developer, I led my first TDD workshop. And I don't think I really understood. Like, I mean, like I started my career doing TDD, but like, look, 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. Um, 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? Like, and I was like, ah, I had no idea. Like, so I don't like go back and figure all that out. And like, and then I picked up working effectively, effectively 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, you give yourself permission to say, I don't know, or to ask somebody else or to say, hey, it's fine. Let's figure this out together. 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 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 better as we do more and more of it.

[00:27:47] Stephen 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. And they're all, you know, doing things the traditional way, I guess. So, you know, 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. Like, and still I had no idea what I was talking. 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. 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 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, knows less about it is sharing and presenting. I still learn something from it 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 have to even know more than the people you're presenting to.

[00:29:14] Stephen Diamante: Very true. Yeah. Because I mean, that happens a lot with learning hours. And yeah, 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, but I always leave it open. Like, you know, if anybody has a topic, please, please come and give me a week off, you know? Like, because 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. Right. Yeah. Yeah. Yeah. Becoming 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, you know,

[00:30:28] Allan Stewart: write better code. 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, Stephen, about six

[00:31:06] Stephen Diamante: trumps. Could you tell us about that? 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, 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 kind of did it. And so she took that and kind of bundled up and slapped a name on it called Salmon Coaching. And so there's a book, her second book, Technical Coaching with the Salmon Method. And so in that book, 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, when we exercise, we actually remember things better. There's a connection. And there's a lot of connections in our brain that are formed when we when we exercise. And there's a lot 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 you know, get up every 10 minutes or so. That's, 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, it's not a lecture. And training from the back of the room is like all about 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, start getting them to talk to each other. So 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, and, you know, with images, you know, yeah, you just it something about like, 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. sticks, right? Writing trumps reading. So a lot of the times when we do the retro, instead of me writing down everything everyone's saying, like they need to be the one writing it. 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 about the tactile movement, it enforces the learning even more, but it is just better to interact with the material. Actually, like write something down. Shorter trumps longer. So all of those different sections, like the four C's, they're pretty short and they have, like we don't want, you know, besides maybe the concrete, which is the most important part, we don't want any of them kind of going on for too long. And boring people. And different trumps, same. And this is just about kind of, I don't know, kind of like shocking material to like make it stick. Like I read this one book about learning and they were explaining about the different connections in your brain using like an alien. And that, you know, just this kind of like, if you can put some kind of weird, cartoonish thing and something odd, 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, writing trumps, reading and shorter trumps, same, shorter trumps longer. So those are the ones I try to focus on in my learning sessions. Yeah, I can definitely relate to those

[00:36:24] Dave Adsit: 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 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, you know, 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 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, Stephen, 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 can be very abstract concepts. But so then 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 is going to represent the customer and somebody is going to represent the user interface and somebody else is going to be the API. But when we do message passing, well, we're going to actually literally write something down on a post it and pass it to somebody else. And we've even done a couple of these in a digital way. Right. So instead of a post, it was a slack message because we're all remote. But it still, I feel like it helped people understand the system. Or another one that I think about a lot is we've done some exercises around messaging systems and you're actually using the messaging system. Right. It's like. It's like. It's like 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 back in the day we had a rabbit server running on somebody's laptop and we all interacted with rabbit MQ and pass messages back and forth. And and again, that's, you know, it's helping it's helping learn. It is hands on. But you're working in somewhere in between complete toy project. Or like. It's like a 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 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 people retain it a little bit better.

[00:40:40] Stephen Diamante: I mean, yeah. I mean, that role playing. That's definitely different. That's different Trump same right there. I mean, that kind of activity will definitely make that learning stick.

[00:40:50] Dave Adsit: Yeah, I think that those 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: 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 what 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 tells me. 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, I think we owe it to ourselves and each other to constantly be uplifting the quality of the skills, the arts, 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 so I want my engineers to be fulfilled in their job. You know, we talk about motivation, autonomy, mastery, purpose. Mastery is definitely one 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 sustainable way.

[00:43:42] Stephen Diamante: They were all 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 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 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. It 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 XLST transforms.

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

[00:45:27] Allan Stewart: Exactly. So, yeah, I totally agree with both of you. And I really like that quote. I'd forgotten that one, Dave. What if they stay? Right. Like we want people who are going to engage and not just be there for the paycheck, ideally. So these are big benefits. And I think 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. Various corporate training programs exist for a reason. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. 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 really interesting one that I hadn't been exposed to for a long time until I heard about them. I think Neil 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, trick cats. 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?

[00:47:57] Stephen Diamante: Yeah. So in, in regards to learning hours, cause that's just what I'm going to focus on is there's there is someone coaching society started by Emily Bache. I talked about before she has a bunch of free resources and this is what I use when I started these. 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. But yeah, 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 the site too. And then, and it kind of, it kind of guides you through it all. In addition, 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 I think they're really great. Definitely awesome to just kind of get started with that kind of

[00:49:28] Allan Stewart: stuff. Nice. Yeah. And 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

[00:49:45] Stephen Diamante: get some, get something meaningful out of it. Yeah. Another thing I do when I'm in that situation, like, it's like, ah, I just don't really, really feel like doing it this week. So I just, I put on a conference talk, like it just, um, we've watched, um, bug zero by Arlo we've, uh, done, uh, uh, one of my favorites is a practical refactoring, Woody Zool, Llellan Falco. That's an amazing talk. And that's two hours of them live coding. And so what I do is like, w w w 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 where we'll watch the second half, do the same thing. So we watched them do it and then we do it could definitely flip that as well. But yeah.

[00:50:43] Dave Adsit: Yeah. So one of the things, uh, they'd say, um, in community building, one of the things that they often do is bring food. People like food. If you're truly, truly trying to motivate people, nothing about motivates people quite like free food for some reason. Um, and then, but keep in you do that. You're kind of stuck with it forever. So for some of the public communities that I've participated in, some of them have had sponsors that, you know, 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. You know, 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. Um, one of the things that I've used, uh, 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. Um, 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. Um, I also, for my leadership led trainings, I do not treat them as 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, to work through a topic, but we try to introduce things there that we want the, 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, 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, um, 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. 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, um, just kind of making that time often works. Um, if it's not, uh, not too onerous and I've seen that once the effects start to play out, it'll often times turn into something where it, uh, gets adopted by leaders to say, Hey, we see what you're doing and it is good. Let's make it part of the work day and not just this extracurricular thing that's going on.

[00:53:55] Stephen 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 work day, um, and to always put them on the schedule. And, um, yeah, sometimes we canceled them. Um, there, there were some delivery priorities that come up. Um, 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, um, people, people enjoy them so much that they wanted to show up. So I never wanted to force anybody to go 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 they it's, 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, 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, Scott's book, um, radical candor, where she talks about how we have different phases of our, 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, uh, 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, you know, not push for that next big thing. Um, 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 what's the most recent job related or work related book you've You know, 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're going, 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

[00:56:37] Stephen Diamante: whatever. Yeah, I mean, yeah, so all I can control is creating a learning environment. And that's fun. I always try to bring fun to the teams. I'm like, we all got into programming because it's fun. So I try to inject that fun back into the team. And, 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 this 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.

[00:57:21] Dave Adsit: That's, yep, that's right. Well, and one thing to be said is that feeling like you're falling behind your peers is a good motivator to go do something about it.

[00:57:31] Stephen Diamante: Yeah. Yeah. So, so the first team that I did this on, there were two senior developers on there. 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, hearing like full requests, like I just saw a clear difference on how much the other developers had learned over that period of time compared to the seniors that weren't going to these learning sessions. And 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.

[00:59:02] Stephen Diamante: I've been reading training from the back of the room. I had never read it before. I only read it in the context of Salman coaching. And so there, 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.