Crafting Code Podcast
$ cd episodes/019-sustaining-communities
~/podcast/episodes/019-sustaining-communities $ ls -1a ~/podcast/episodes/019-sustaining-communities $ cat episode-summary.txtThere are many benefits to having communities of practice, so long as the community continues to exist. In this episode, special guests Jon Turner and Neil Sorensen discuss what they've learned over their many years attending and facilitating the Utah Software Craftsmanship group (http://utahsc.org/).
~/podcast/episodes/019-sustaining-communities $ cat references.txt- Clean Craftsmanship. Robert C. Martin.
- Out of the Tar Pit. Ben Moseley and Peter Marks.
- The Software Craftsman. Sandro Mancuso.
- Apprenticeship Patterns. Dave Hoover and Adewale Oshineye.
- Global Day of Coderetreat. Corey Haines.
- Mocks Aren't Stubs. Martin Fowler.
- Clean Architecture. Robert C. Martin.
$ cat transcript.txt
[00:00:17] Allan Stewart: Welcome to episode 19 of 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 wondering whether my immortal soul will perish if I cannot obtain some mithril.
[00:00:34] Dave Adsit: I'm Dave Adsit. I'm a technologist, and recently I've been thinking a lot about container-based software deploys.
[00:00:42] Matt Baker: Hey, I'm Matt, and lately I've been working on a system built with immutable data, and so I've been thinking a lot about that.
[00:00:50] Allan Stewart: For today's episode, we're going to be talking about sustaining communities. And we have two special guests, Neil Sorensen and John Turner.
[00:00:59] Dave Adsit: I've known John for a decade, since I first started going to the Utah SC meetup and the Utah.net meetup. If anyone asks me about John, I would tell you that he is an excellent teacher with a lifelong interest in robotics, teaching kids to code, presenting to aspiring developers, and always knows the latest about .NET language developments.
[00:01:23] Jon Turner: Thanks, Dave. I'm going to have to hire you to write my bio for conference submissions.
[00:01:29] Dave Adsit: Sounds great.
[00:01:31] Matt Baker: Neil is a practicing software engineer and conference speaker who usually hosts and is always organizing the Utah SC meetup.
[00:01:39] Neil Sorensen: Thank you, Matt. It's a pleasure to be able to join you. I've known Allan, Matt, and Dave for several years now, and they're all great people who I love to learn from.
[00:01:50] Allan Stewart: So when it comes to sustaining communities, Neil and John have been keeping up with each other, keeping the Utah SC group alive since somewhere around 2015. I'm curious, how did you first get involved with the Utah SC group in the first place? So for me, I first got involved with the
[00:02:08] Neil Sorensen: Utah SC group because a mentor of mine, Mike Clement, was involved in organizing the group for the first time. I attended the very first meeting in February of, I believe, 2010. May have been 2011, I don't remember exactly. But I found it to be a great way to practice skills and develop. I started as a very junior developer and have continued going for more years than I
[00:02:40] Jon Turner: want to admit now. So for me, I didn't start attending quite as early as Neil, but started attending a few years after that, 2013 or something around there, for similar reasons to find a group of like-minded individuals, not maybe like-minded is a wrong word, but who share some similar values in regards to the software development. So I attended for a couple of years. And then I don't remember if Neil mentioned it, the original founder, Mike, he moved away. He thought that there was value in the group. And so he was like, who can I ask to keep this group alive and keep providing value to the community? And so he asked us individually, right, Neil? I don't remember how that... I remember talking to him. I don't remember how that worked though.
[00:03:26] Neil Sorensen: I don't know that he ever actually asked me. In my case, it was more of, well, Mike is leaving and I have gained a bunch of value from this group. I want to continue gaining value. And I want to make a place where other people can get the value that I have gotten. So I'm going to keep running this as long as no one tells me no. No one ever told me no.
[00:03:49] Dave Adsit: I think mostly we told you, yes, thank you. Keep going. One more thing I don't have to worry about.
[00:03:57] Allan Stewart: So now that you've been running the group, helping keep it organized, keep it hosted, what motivates you to keep coming back? So Neil, you said that there were some things about the group that you found really valuable. Are you continuing to see that value? Are you seeing new things as you've been running the group rather than just attending the group? What keeps you coming back, especially when things have been hard? We're going to talk, I think, in a few minutes about COVID pandemic and how that kind of changed everything. But what keeps you coming back? Why are you still running the group and not just
[00:04:31] Neil Sorensen: letting it die off? So I think an important part of it is that we have intentionally structured the group so that it doesn't require hours and hours of work to keep it running. We have designed it so that with just a couple of hours a month, we're able to keep the organization up. John is kind enough to keep Meetup up to date. I usually forget to do that. But we host a couple updates throughout each month. And then because we have a volunteer coding exercise rather than doing speakers, it's much easier to organize every month than it would be if we had to get a speaker for a full hour like many other groups do.
[00:05:21] Jon Turner: that's one of the strengths. I mean, it's a trade-off, right? The format. But one of the strengths of the format is that it doesn't take a ton of time on our part. And so we're less likely to get burned out on doing it. Being like, oh, well, this is super awesome. Be super gung-ho about it. And then three years later, be like, I just can't. I just can't do that anymore. Like the fact that it's been structured that way, we've mostly kept it the same since Mike originally started it. The overall format is basically the same. So that helps a lot. For me, some of the other reasons that I keep doing it are usually when we talk about software craftsmanship or being a software crafter or that kind of thing. A lot of times we talk about technical things, TDD or pair mob programming or things like that. But there's also a community aspect to it. Some people have written on the topic have talked about this idea of community and mentorship one of the really valuable parts of this group. It's always the best when we get a new person who comes. It's their very first time. They've never been before. And I don't know that anyone has ever actually said exactly these words, but you can tell they say more or less these words. They say something to the effect of, oh, I'm so glad I found this group. I found my people. I found people who want the same kinds of things in software development that I want, but I haven't been able to find them. And now I found them. And we can help guide those people through some of that journey. We can say, oh, well, if they have a question about some topic, we can be like, oh, hey, have you read this book or read this blog post or watch this video or something? We can be a resource to help those people find a better, is better the wrong word? I don't know, a better way to do software development, a more sustainable way, a funner way to do software development. So being able to connect with people and help them in that journey is something that I get a lot of value out of.
[00:07:20] Matt Baker: I have one ad for that. There've been a few times at these particular meetups that I've been able, I've been connected to someone that at their company was working on something that I was working on at the place I was working at. And they might've been ahead of me a year or two down the line and what we were working on. And it was so invaluable to be able to sit and talk with them and talk to someone that has just walked where I'm about to go and be able to pick up some of their lessons. Just showing up to one of these groups where people, like you said, they're working on the same stuff and they have some common interests or some common opinions about how it should be, you know, how it should be dealt with. It's, it's real good to meet people
[00:08:00] Allan Stewart: that are doing similar things. And I've seen that firsthand, what you were talking about, Neil, how quickly the group can get put together. It's not entirely foreign for somebody to forget that they had the coding exercise and they didn't prepare something or at the last minute, they couldn't make it for some reason. Cause you know, life, life happens. And what that says to me is that a lot of the value that comes out of the group isn't from something that was pre-planned that was packaged up for you. And so here you can deliver it. And we could see that there's definitely value to those kinds of things, right? You can watch conference talks online. Somebody already recorded it, right? You can watch videos that teach you how to code or about coding adjacent principles. But when you're actually there in the discussions it's free form and it's about being hands-on rather than being talked to. And so a lot of what I have gotten out of the group has really depended on what I put into it.
[00:09:04] Neil Sorensen: Yeah. One of the things that I'm really happy with our group is that it is an opportunity to practice the skills that we say are important technical skills that make us better at developing software. TDD and pair programming or mob programming. These are skills that you have to develop, which means the first time you try them, you're going to be really bad at them. But not many companies give space for their developers to learn that on company time. And certainly very few value it enough to say, yep, you better learn that on company time. So by having this opportunity to practice your skills, you're definitely going to have an advantage. And I think that's an interesting thing to remember about TDD and how TDD has strived to do its thing and how TDD has strived to do its thing and how TDD has strived to do its thing and how TDD has strived to do its thing and how TDD has failed and then had the chance to work with people at this group for a few months. And it was like, oh, I get that now. I'm starting to see what this is all about and the value that it provides.
[00:10:39] Dave Adsit: For me, it's not just the hard technical skills that you get to learn and practice and develop through the group, but there are a bunch of other really important life skills, developer skills, craftsmanship skills that I feel like I've developed more deeply through participation, including presentation skills. With the format that we use, it's easy to get up and talk for one to five minutes, or at least it's substantially easier to get up and present for one to five to 60 minutes, which is typically the commitment at other meetups that I've participated in. One of the things that I find really valuable is practicing the skill of coaching or mentoring or teaching, as well as the skill of being a good novice, being a good beginner. The fact that we have community-driven coding exercises every month, that some months I'm up there presenting about the thing that I find interesting. And some months somebody is teaching me something I've never done before. And those are skills that I also find super valuable as my career goes on.
[00:12:01] Allan Stewart: I'd maybe add to that the social skills around getting to know other people, getting outside of your own company. Because even when I've worked at companies that have or you know, having brown bag meetings, or you're having other kinds of meetings where you're doing learning and sharing, getting insight from somebody who's not working at the same company as you can be very valuable. It's kind of like what Matt was alluding to before. And I know, Dave, some of the connections that you've made have come in valuable when you were recently flung into doing React development, of which you had no prior experience.
[00:12:43] Dave Adsit: It's definitely true. Yeah. It's also kind of a side note, or even a little bit selfish, it's been very helpful for vetting and developing a professional network. You know, if you want to hire somebody and you notice that somebody that you've been to the meetup with has worked with them before, suddenly you have a really good source of information about how this person works and whether or not they're going to be a good fit for your company. One of the other things that I've really valued about the group is that it provides stability as I have changed as a professional software developer. Over time, there's been periods when I felt like I have mastered certain basic topics and I want to move on, and I want to get deeper, and I want to understand something at a more foundational level. And the group has been talk to people who have also walked those paths. Neil talked about getting started with TDD. We do a lot of basic mentoring on how to get started with TDD because a lot of people, surprisingly, still aren't using it on a regular basis. Not even test first, not even unit testing, to be frank. And so if you do a lot of mentoring and a lot of, if you're going back to basics all the time, that doesn't give you much opportunity to go deeper, especially if that's what you're doing at your company. You're doing it at your regular day job. So getting together with people who have also been doing a practice like that for a while gives you an opportunity to explore the concept to a greater depth than you would otherwise. Are we going to do Detroit style? Are we going to do London style? Do we hate mocks this week? Do we love mocks this week? Are spies mocks? Do we care? What are we doing? How do we understand these concepts at a deeper level? How do we move forward? And so having a group where there are people that you can source information from and just have deep conversations with because they bend down the same paths has been really valuable to me throughout my career. There have been times when I thought, you know, we should start a second group that has like invite only just for the people who have done all these things. And then we can always have these deep conversations. And then I'm like, and then we would leave behind all the people who were not mentoring anymore. And then we will take the opportunity away from people who once would have been us. And so, you know, depending on where I'm at in my career, I have had all of these thoughts about how to improve the group through changing it. And it tends to evolve on its own. And I find that super valuable. So the answer to your question, Dave, is yes,
[00:15:33] Jon Turner: we love mocks. And no, we don't care enough to remember the difference between spies and mocks.
[00:15:38] Dave Adsit: Just call them all mocks. I don't care. Okay. That's good to know. I'm pretty much I'm pretty sure that the only time I've ever used spies is when testing JavaScript. But that it's possible that I've inadvertently used them in other cases as well. Are spies stubs?
[00:16:01] Matt Baker: What's the difference? Yeah, yeah. Spy, you can assert what behavior?
[00:16:07] Jon Turner: See, this is just the thing.
[00:16:09] Dave Adsit: See, this is the thing. I'm going to tell you what the definition, I'm going to tell you the And what the difference is. And all of the comments are going to tell you why I'm 100% wrong.
[00:16:21] Neil Sorensen: But should we talk about monads, Dave?
[00:16:25] Dave Adsit: Not, not today, Neil. I haven't, I don't have a blog post. So mocks just replace or have a different implementation of the same functionality, right? Often with a tool that generates it for you. So you don't have to do it all manually. Okay. So the other thing that I'm understanding is that spies use the real function under the hood, but let you watch the interactions. So you can make assertions on the interactions either way. But if you're using a spy, it still calls out to the underlying production or correct implementation versus just faking it all the way. Yeah. Okay. See, this would be a great
[00:17:11] Matt Baker: five minute lightning round or excuse me, lightning talk. Beginning of the meetup, which is another thing. That's a tradition. I really have always appreciated about the meetups, the five minute lightning rounds.
[00:17:22] Jon Turner: See my version of that lightning talk would be, Hey, do you want to know the difference between stubs and mocks? Look, Martin Fallow wrote a blog post on it. Go, go for it.
[00:17:32] Dave Adsit: See, John, you just introduced a whole different topic. I didn't say stuff. That's true. They're all test doubles. Let's just say. Let's just agree that all test doubles are good at the right time in the right place. And you should use them if you want your tests to be fast or at least easy to verify functionality. I don't know. See, they all do different things.
[00:18:04] Jon Turner: Except the term test double is too long. It had too many characters in it. So you just say mock, even though it's not right.
[00:18:10] Dave Adsit: Right.
[00:18:11] Matt Baker: The mock is the same thing as the stub.
[00:18:13] Jon Turner: That's fine. I think that's the conclusion we came to. Definitely.
[00:18:18] Dave Adsit: That is that. Yes. Mocks are spot. Mocks equals, equals, equals spies. That's right.
[00:18:26] Neil Sorensen: I am definitely going to have to watch.
[00:18:29] Dave Adsit: And you can call them all mocks because mock is like the brand name. It's like, you might have a box of facial tissues on your desk, but you're definitely going to tell people they're Kleenex.
[00:18:41] Matt Baker: Perfect. Glad we got that sorted out.
[00:18:45] Allan Stewart: And some of these things around the format have definitely stayed the same over the years. But then 2020 happened and the COVID-19 pandemic. So could you tell us a little bit about keeping the group alive through that pandemic? What are some of the things that changed? What improved by going remote? And what things do you miss about in-person meetings?
[00:19:07] Neil Sorensen: Like everybody else, when March of 2020 happened, I was like, well, we just have to do this for 2020. Maybe a month or two. We'll just be remote for a month or two, and then everything will be back to normal. So we didn't start trying to perfect an online meetup, but in a lot of ways, our meeting was online friendly already. It's a highly interactive meeting and Zoom gave us tools for that with breakout rooms, giving everybody the opportunity to talk. One of the challenges. One of the challenges with doing it in online format is that you lose all the side conversations that can happen when you're in-person. And I do really miss that. I miss the ability to just see somebody and be able to say, hey, good to see you and have a conversation without it dominating the whole group. That's a thing that I would love to get back. to have people from across the country join us. Mike Clement, who we talked about, has been able to come back to the group on several occasions that we otherwise wouldn't have been able to see him and talk with him. And we've been able to learn from people who would otherwise have been
[00:20:33] Jon Turner: inaccessible to us. It's really interesting because I think, like I agree with all the things that Neil said, some things in going remote has made it more attractive for some people and it's made it less attractive for other people. Ironically, before we went remote, we had a group of college students who would drive to where we held it in person every month. And it took them like an hour to drive, hour and a half, one way to drive there. And it was like, wow, that's awesome dedication. And so initially when we went remote, I was like, oh, that'll be way easier for those guys. But they haven't attended nearly as much since we've been... Remote. So there's that example, but then there's also the example that Neil said where we've had other people from across the country be able to join and stuff. So that's been interesting. Neil usually takes care of this part. So maybe he'll have more to say about this. But one thing that has been very nice not to have to deal with is figuring out physical location. We've always done... So like some groups, some meetups will get company sponsorship and stuff like that and have... Money for giveaways or food or other things like that. And so maybe you can get enough sponsorship like that to rent some kind of venue. We haven't ever done that. And so it's always been, well, what kinds of venues can we find that are... I think we've only ever done free venues. And a lot of times there have been companies who have some kind of program going or someone who works at a company that has space that they're willing to let us use. And so we've had a space, but it has been... It's been challenging sometimes. If Neil wants to tell stories, I'll let him tell stories. But... So like not having to deal with that has been really nice. Sometimes in the spaces that we've been in for the lightning talks that we talked about, it's hard. There's not a computer hookup or something like that. If you wanted to show something on a computer as part of a five-minute lightning talk, that was challenging. With Zoom, it's super easy. You just share your screen and just share whatever you have. So that... That part has been nice. I totally agree with Neil about the side conversations. That's a thing that I miss.
[00:22:48] Neil Sorensen: Speaking about location and changing location. So most of the time we have held the meetup at a company where a member of that company is attending and there have been several local companies. We'll go ahead and name drop exact where. Pluralsight and Health Equity. Health Equity. That was the name. Sorry. So exact where, Pluralsight, Health Equity. We're very generous in letting us use their space and letting us spend some time there for many months at a time often. When that stops being feasible for the company that is offering, it can get a little bit awkward. Sometimes we get that notification at the very short notice. I wish you would have told me that we can't meet there three weeks ago so that I could have had time to figure out what the meeting space would have been. But it was very generous of them to give us the space. We have intentionally never done food as our group. So we haven't had to worry about lining up sponsors for that. But it's been interesting as we've been moved around, and I don't think we've moved. More than 20 miles ever. But even just a couple of miles difference, we get very different groups as we move spaces. I don't know exactly why, but for some people, the move just means that this is too much. And that's reasonable. Different people have different priorities. And sometimes that extra 10 minutes really is something that is not feasible to commit. Moving online, which would seem to be the easiest thing to commit to, has had a similar drop off and change in who's coming as all the other moves that we've had. And so we're sorry to see people go. Hopefully they are continuing to develop their skills and grow as people and as software developers. But we're glad to have new people join us whenever they do. It reminds me of the concept
[00:25:09] Allan Stewart: that sometimes you value things more when you have to pay for it. And this has been a free group, so you're not paying for admittance to the group or to be able to attend. There's no membership dues or anything like that. But having to pay the time or even the gas money or the train ticket to get over there to the meeting, I think sometimes that added incentive to people to go. Whereas the virtual And it's virtual. And you could take it or leave it. And so if you're busy at all on the first Wednesday of the month when the meeting is held, then you just might not make it because you
[00:25:50] Jon Turner: haven't invested as much into going. People are so weird, aren't they? This is why I deal with computers instead of psychology. Just keep telling yourself that, John. I'm trying. I'm trying.
[00:26:04] Dave Adsit: One of the things that I miss most about the in-person meetups were the conversations they have afterwards when everybody went to a local restaurant for dinner. And they were always much less formal conversations and a different type of social interaction than you get during the meetup itself. On the other hand, I'm super glad that we can meet with some of the developers that I've met from other states. And we can have their insight from the workplaces that they're in. And
[00:26:37] Allan Stewart: I think that's a really important part of the meeting. And I think that's a really important part of the meeting. And
[00:27:10] Dave Adsit: That will simplify a lot of things.
[00:27:11] Neil Sorensen: Just get jersey numbers for all their shirts.
[00:27:16] Allan Stewart: But that assumes that I'm better at numbers than symbols.
[00:27:20] Neil Sorensen: No, no, no. I'm not saying remember the numbers. You give them a shirt, and their shirt has their number. So, as long as you can see them, then you know the right number to call.
[00:27:30] Dave Adsit: There you go. That does seem nice. So, one of the things that I've thought about... a lot as a participant in this meetup is the group education component that we have in it, where we have typically picked some kind of software engineering related material to read and discuss as a group or a video to watch and discuss as a group or something to that effect. And one of the things that tends to often be a challenge is deciding what thing we all want to learn together. How have you two chosen to tackle that challenge? Does poorly make a good
[00:28:14] Neil Sorensen: confession? That's what you'd get from me. The challenge of doing this learning as a group, which I do think is valuable, but the challenge is that the level of commitment that everyone has to prepare before coming to this meeting is different. And so there are some... people that are very dedicated about reading or watching or doing whatever preparation we ask, and there are other people who aren't. We don't want to exclude the people who don't dig deep into the material, which means that often we end up going for material that you can have good conversations about without having to go deep into research. conversation. So we will often choose not to read highly technical books, not because those aren't good, not because those skills aren't important, but because if we're going to have a conversation and it's going to revolve around whether a certain problem can reduce to the three color problem, then you have to have a shared background of understanding around a lot of technical things that the average software developer may not have a great understanding of just from having done their job. And so instead we tend to focus on books that incorporate some technical, but also a lot of relatively un-technical discussions. We are just finishing up reading Clean Craftsmanship by Uncle Bob, which is a great book, but doesn't really get into, well, how do you do TDD? Talks more about why do you do TDD and how do you help your organization grow?
[00:30:19] Allan Stewart: Another example of that was a little while back, the group read Out of the Tar Pit, which is a pretty widely known paper, and it goes into a lot of detail. It has been published in more like academic tone. And so it's not, it's not the same as just reading a blog by any means, but there was also enough generality in there that people could relate. There's a lot of jobs out there that have tar pit kinds of problems and people have experienced it at some level or another and being able to talk about kind of talk about the problem didn't always mean that you got into the reader reader thing. details of the conversation. You might not have a really deep discussion or debate about, well, what does this mean? And is this true? These few sentences or this assertion that was made in the paper, but you can have a good conversation nonetheless. And it kind of goes back to what we were talking about before, where a lot of the value comes from what people are bringing into it. If I can learn from somebody else's experience, how they perceived the tar pit at their company and what they did about it, oftentimes that's just as valuable as having a more academic discussion about specific differences between some of the assertions. Like a lot of aspects of the group,
[00:31:42] Jon Turner: it's finding a balance for the reading specifically. Like to Neil's point, we want to find something that is interesting to most people, that people who put more into it, or maybe who in the software development field can get something out of it, but people who just show up and for the first time at the meeting and have never read the book or heard of it or anything like they can still get something out of it, or people who are newer in their software development career can get out of it. Dave will like this because it comes from principles of product development flow. It's kind of like a U-shaped curve optimization where we're always trying to get to the best possible option, but it takes a lot of work to really get there. We try to go for a good enough option. And fortunately for the reading, there are a lot of good books that mostly fit into that kind of category. But it does mean that sometimes we don't read the Golang in-depth book or Postgres for wizards or whatever. There are some of those kinds of books that don't fit that criteria super well. And we never did read that book
[00:32:55] Allan Stewart: about XSLT in-depth that you had. Sitting on your shelf for all those years, Dave?
[00:33:00] Dave Adsit: Oh, I definitely read that book. I used it extensively when I was working in a project that was XML with XSLT transforms to generate everything from HTML to CSV. You've got to love that.
[00:33:20] Allan Stewart: Well, sure. You used it. We just never talked about it in the group.
[00:33:24] Dave Adsit: It turns out every time I brought it to the group, people were like, how old are you? What is an XML?
[00:33:32] Jon Turner: Fun factoid. I can't remember if it was the Battle.net website or Blizzard's main website used to be generated off of an XSLT transform.
[00:33:40] Dave Adsit: That was all the rage for a while. And then we decided that was insanity and we should just render HTML. And then we got React. I'll just leave you to draw your own conclusions there.
[00:33:53] Neil Sorensen: All you need to do is render JavaScript as HTML, and everything will be better, Dave. I agree.
[00:34:01] Matt Baker: Speaking about books or articles that you discussed at the meetup, both John and Neil, is there a memorable one that sticks out to you, either one you enjoyed reading the most or maybe the discussion was especially good for you?
[00:34:16] Neil Sorensen: So one of the ones that I have gotten the most out of was The Software Craftsman by Sandro Mancuso. and apologies if I got his last name wrong. I am not Spanish. That's one of those more general books, and it talks about the why of many of the practices that I appreciate, and getting to dig into those whys helped me articulate what I liked about it and has helped me improve the way I work
[00:34:48] Jon Turner: in order to emphasize those benefits. That one was good. I really appreciated that one because we're all friends here, right? I can share this. I love Robert Martin. He writes a lot of good stuff, but if you read one Robert Martin book, you've kind of read all of his books. I mean, it's worthwhile. Sometimes there's new stuff in each subsequent book, and clean architecture is kind of different than his other books, but a lot of them are very similar, and so it was really nice The name of the group is Utah Software Craftsmanship Group, right? So obviously, software craftsmanship is an important thing, and so to have another strong voice talking about that kind of thing, I found very helpful. I really like that book as well. For me, though, more than like, oh, well, this book was super good and generated a lot of good discussions. Sometimes you can have a great book and not have a great conversation about part of the book because of the people or the circumstances or something like that. So for me, it depends usually a lot more on the people that I'm having the conversation with and what we're talking about and everything. The types of conversations that are memorable for me are when either someone has like an aha moment of, oh, I had never thought of that before or something like that, or when we talk about some topic and someone is really, interested in it. They're like, oh, that sounds really interesting. Does anyone know more about that? Can anyone help me learn more about that? Those kinds of conversations get me excited.
[00:36:30] Allan Stewart: Having attended for a while, I've noticed that there are some times where we'll go back to the same books over and over, and I've been surprised at how much I've gotten out of those discussions as well, where it's easy to think, I already know what it's about. I already have ingested it, so to speak. But really, when I go back to it, I learned something new. And when the discussions come up, then somebody throws out something that I hadn't thought of before or puts it into a new light. And so I've really enjoyed some of those discussions where something I thought that I understood pretty well, all of a sudden I had my assumptions challenged and I had to go back and think, wait, what does this mean? Is this really what I thought mean, suddenly changed around me. Those have been very healthy for me.
[00:37:24] Dave Adsit: There's a concept that I've encountered at a lot of places where there's one developer who is more experienced, has been there longer, knows the system inside and out, whatever. And for a while, we've referred to that person as the guy, because that's the guy you have to talk to, to get any. thing done. And one of the things that I found super valuable when I first started attending the meetup is that everybody that was there had the capability of being the guy, but everybody was there to instead be open-minded and learn from others. It's really helpful to go from being the person who has all the answers, or is at least expected to make them up on the fly and sound convincing, to being somebody who can just expose your own ignorance so that you can grow as a
[00:38:26] Matt Baker: developer. Something I've always liked about the meetup is the emphasis on a hands-on exercise. And then occasionally I hosted meetings and I would run the exercise and either John or Neil would remind me, hey, we typically like a hands-on exercise. I've always appreciated that at each meeting. And I'm wondering, where that came from?
[00:38:48] Neil Sorensen: That was a reaction to some of the meetups that we were attending for other groups, where many of the participants, and this included us at the time, would, you'd come and there was food, was usually pizza. And so you'd get your couple slices of pizza and go sit in the back of the room. Someone would get up front and talk to you. And I would say, hey, you know, I'm not going to sit in the back of the room and talk about something for an hour. And everybody else would totally tune out and eat pizza in the back of the room and not do anything to learn. We did two things in order to try and change that dynamic. And the first is that we said we're never going to have food because if you're here for $2 worth of pizza, if that is your primary goal in coming to this event, you're not going to help the other people who are here in the way that we want you to. You're not going to participate the way we want you to. We're glad if you are willing to come and participate. If you're not willing to participate, then there are other meetups you can go to. And I hope you have a good time there. The other thing that we wanted to do is make sure that everybody had a chance to participate and actually had a chance to practice. We say that that's an important part of our job. And there's not many places that you can go and practice. And so that was an intentional choice when the group started. And we have kept it as an intentional choice through the, I'm just realizing more than a decade that it's been going on.
[00:40:41] Matt Baker: Yeah, well done. It makes it a different kind of meetup. And I don't think I've ever not had fun at those, the coding exercises. It's always a treat to code with someone, especially people you haven't coded with before.
[00:40:53] Jon Turner: I agree with what Neil said. That's not to say that there's no value in presentation style learnings, but it can turn into the situation that Neil described. One other reason why we tend to do hands-on coding exercises is because, you know, if you're going to do an hour-long presentation, you have to have an hour's worth of material. And that's one of the reasons why we Or possibly more, right? And you have to practice it and ideally practice it and prepare it and everything. Where with a hands-on exercise, it's really easy to say, here, here's a problem description. Go understand the problem and write code to solve the problem. Your preparation was, could be as little as five or 10 minutes. And your presentation can be as short as five or 10 minutes. So that is another added benefit of that type of activity. Is it, again, not always, but often, can, you know, have a low preparation cost, which goes back to the sustainability kind of thing that
[00:41:52] Allan Stewart: we talked about at the beginning. So I'm curious, having been in the group for so long, the decade plus that Neil just mentioned, maybe John's coming up on that still. What are some of the things that you've observed or learned as you've seen people come in and out of the group? I feel like there's only a few people who are regular attendees. Like even myself, I'm sad to say I haven't been as an attendee in the last year because of some changes in my home schedule. And so I haven't been able to come. But what are some of the things that you've observed or learned seeing these different people coming and leaving, sometimes coming back? One of the things that comes to mind
[00:42:33] Neil Sorensen: is from the book Apprenticeship Patterns by David Hoover and Adewale Oshinai. And again, I apologize if I get people's names wrong. I have never met them in, personally, trying to read names off of books. But they talk about the long road is one of the patterns. They talk about how over the course of a career, people will take different paths. And some people will stay in software for their whole career, and other people will go in different directions. And that's okay. That's one of the things that I have appreciated about running the group for a long time. and hoping to have something that they can come back to when life changes again, because life
[00:43:43] Jon Turner: always changes. Yeah. I used to take it more personally when people would attend the group for a while and then they would stop attending. Like, Oh no, what, what did we do? Did we, did we fail them? Did I offend them somehow? Or, you know, like starting a rival group and we're going to, you know, like get jackets and fight each other and what's going to happen. But yeah, I think over time I've gotten, I'm still human. So occasionally I still want to put on my leather jacket and snap my fingers, but usually not. I usually do try to think of, you know, what, what value have people gotten out of it, out of the group? Sometimes it's someone who just came out of a bootcamp and someone, some smart person somewhere said, Oh, you should go find a group to attend a local community group to attend. And they found ours. Uh, you know, and they're trying to get a few connections in the industry and try to get a job. And sometimes those people come two times and then they get a job and then they don't come back again. And, uh, you know, it's easy to be like that person could have continued to get value from this group, but like Neil said, maybe, maybe they got the value that they needed for right now. And maybe it can be a thing that they can come back to later. For me, it's been helpful to look at it from the perspective of not, are we the popular group? Are people coming because, because they think we're cool and they want to hang out with us, but really more what value can we provide to the people who do come for the amount of time that they come, whether that's a long time or whether that's just one or two times.
[00:45:17] Neil Sorensen: I will say that there have been some groups that have not explicitly been rival groups, but have targeted many of the same people and been like, well, we're the slightly North of you software craftsmanship group. It has been perhaps a little selfishly pleasing to me to watch those groups come and go. And most of them don't last very long.
[00:45:46] Jon Turner: See Neil's human too. We're all human here.
[00:45:49] Allan Stewart: Well, as we wrap up, I'd like to ask about what are some of everybody's favorite memories or things that have stood out in particular as you've attended the group? I know for myself, gone to memories, but are there any particular ones that just stick in your mind or that are just kind of on the tip of your tongue? Well, I've got a couple. The first one is
[00:46:14] Dave Adsit: just a little too obvious in that I was approached by another attendee who said, I like your answers to some of the questions that we've discussed. Would you like to come have a job at my company? And it turned into a job that I worked at for many years and enjoyed for most of those years. And I think is the time I decided to do a coding exercise on distributed systems. And I got to spend many hours prepping a message broker that could be shared by all of the people who were writing their own clients, et cetera, so that we could create this big distributed calculator that's entire purpose was to add and subtract numbers. But across multiple dev machines.
[00:47:06] Matt Baker: My favorite memory was from an early meeting I came to. And as a group of about 15, we wrote some Golan code using mob programming. And I think that was one of the first times I'd done it. And if you've never tried it in a 15 person group with like two minute turns with a strict driver navigator, it was fun. It's, it's nerve wracking coding like that, in front of so many people you never met. But I enjoyed it.
[00:47:40] Neil Sorensen: That was a good coding exercise. One of the things that sticks out in my mind that I have really appreciated is by going to the software craftbr craft br happens every year. And so I first attended because of this, which was a great opportunity to learn and practice a bunch of the skills. And then a couple of years later, I had the opportunity to host one. This was a great for me experience to show how I had grown from where I had been someone who would show up for the first time at this kind of an exercise to organizing and hosting and helping everybody else get the same kind of experience that I had had. That reminds me,
[00:48:36] Jon Turner: we need to go see when the next Global Day of Code Retreat is. It's sooner than I want to think about, but yeah. Yeah. I think it's November something. A thing that sticks out to me, I mean, there are lots of things that I could pick, but the one that I'm going to share now, it was one specific experience. It was with a person who had come a couple times, a little bit less experienced, in his career in software development. And he and I talked a few times and he was interested in learning more, which was great. And one time we ended up doing the coding exercise together. We were pairing. And sometimes I like to do the coding exercise by myself because at work, then I'm almost always pair programming or mob programming. And so sometimes for me, it's nice to take a break and do it solo. And so at the time, I was like, oh, okay. Yeah, sure. I won't do it solo this time. I'll do it with someone. And we were just going along, trying to figure out some things. And we're just chatting and talking and we'd come up with ideas and talk about them and go back and forth. And we'd write some tests. And at the time I was just like, oh, okay. That was fine. That was great. And at the end, he was like, oh, thank you so much for doing that. I finally understand what TDD actually means now. I was like, oh, I just thought we were coding. Yeah. Yeah. Yeah. noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I noticed him and I him him him
[00:50:19] Allan Stewart: There are a lot of coding exercises that I had a lot of fun working on. And they're usually just little problems. A lot of them could be code katas that we worked on together. But then some of them have been fun. John, you have the XOR tag that we've done on a few occasions that I think is just always fun to play around with and learn from. One time I sat down with a good friend of mine, and he wanted to write code in Rust, and I was completely unable to do anything useful. So that sticks out in my mind, but in a positive way like it's good to be exposed to things that I had never tried before. And I think the thing that I've missed the most is just getting food after and having those sort of after party conversations. But we'd like to thank you, John and Neil, for helping continue this group. I know that it's been impactful for the three of us hosts. So we thank you for keeping the group up and for coming on and recording with us, telling us a little bit about the insights that you've had and the things that you've learned by participating in this group over all these years.
[00:51:36] Jon Turner: Yeah, thanks for having us. I was telling people at work right before this. It's always entertaining to... It's always fun to listen to Allan and Dave and Matt just talk about stuff. So it's fun to get to be part of one of those conversations.
[00:51:50] Neil Sorensen: Yeah, I'm glad I could take the time and would love to come back some other time if you've got other things you'd like to talk with me about.
[00:51:57] Allan Stewart: Definitely. Well, the music for our podcast has been generously provided by Todd Fisher. And as always, we recommend that you join a community of professionals by attending a Software Crafters group or music. And if you'd like to join Neil and John at a meetup, the Utah SC group at utasc.org has a virtual meeting the first Wednesday of each month. Maybe we will see you there.
Copyright © 2026 - Crafting Code Podcast