Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode four of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time and with the right tools. My name is Allan Stewart. I'm a software architect, and lately I've been thinking about the competing concerns of data aggregation and access control.

[00:00:17] Dave Adsit: I'm Dave Adsit. I am a CTO, and this week I've been thinking a lot about scaling teams and KPIs. Nice.

[00:00:28] Matt Baker: I'm Matt Baker, software architect. Lately, I've been implementing the Kafka Wire protocol.

[00:00:37] Allan Stewart: For our episode today, we're going to be talking about effective teams. To kick things off, Dave, Matt, what does it mean for a team to be effective?

[00:00:49] Dave Adsit: So, man, that question goes deep. Cuts deep. Yeah. It, uh... An effective team actually gets something done that is useful.

[00:01:04] Matt Baker: I would add to that they consistently get something done that is useful, day over day and week over week.

[00:01:11] Allan Stewart: Yeah, I went and looked up a definition for effective, and in the dictionary it said, something's effective if it is adequate to accomplish a purpose, producing the intended or expected result. And I think about that in terms of, you know, value to expense. If a team is, you know, they deliver something and it works, but it was super expensive, like 10 times more expensive than maybe it ought to have been, then no, that wasn't very effective. Or if they take a really long time to do something that might be ineffective, just depending on are they delivering value back to the business? Which gets back to some of the key tenets of the software craftsmanship manifesto that we often talk about, you know, delivering value. And making sure that we're doing what the customer or employer needs us to do.

[00:02:02] Matt Baker: I like that the definition starts with adequate to accomplish, and it's interesting for me right now to contrast that with like, amazing best tool ever. So adequate to accomplish to me sounds like, like, be a fan of good enough. If it, whatever causes you to expend the least amount of effort might be the right choice here. I don't know. I'm not quite sure what I'm trying to say, but I'm attracted to those, this idea that it's like, Hey, it's just going to work. It's going to work.

[00:02:28] Dave Adsit: And I think I'm drawn to something along those lines as well, which is the idea that it's not about being busy. It's about getting things done. It's adequate to purpose. So get something done, deliver it, then do the next thing, then do the next thing. And so to me, effective teams are teams that are delivering at a regular cadence. You said it at the beginning, Matt. They're delivering. They're delivering today, tomorrow, next week, the week after, et cetera. Right. A team can be very busy and very ineffective, or they can be very effective and appear to be less busy. Yeah.

[00:03:10] Allan Stewart: That consistency is an important aspect of being effective. And I'm reminded of the phrase, don't let perfect be the enemy of good or good enough. An effective team is going to make sure that they do good enough. Right. They don't want to be. Sloppy. They don't want the quality of the product to suffer, but they also aren't going to be perpetually gold plating or, or navel gazing at their code and trying to figure out what it is that they are delivering, but they understand we need to be on that treadmill of delivering value all the time.

[00:03:44] Dave Adsit: For my teams, I like to think we all get paid on a regular cadence and I expect to see value on a regular cadence back in the deep dark recesses of my past. I worked on a project. I worked on a project that had an annual release cycle. I never saw it released before I left the team. I missed the cycle. And then I left 11 months later because I had a job where I actually had the hope of getting something done and delivering some value to someone.

[00:04:11] Matt Baker: How did it turn out?

[00:04:12] Dave Adsit: The team that I left or the team that I went to?

[00:04:14] Matt Baker: The team that you went to.

[00:04:16] Dave Adsit: Oh, very well. Oh, good. We delivered a lot of things. It probably wasn't the most effective team I've ever been on because some of the things that we delivered were bugs. Yeah. Yeah. Defects and outages and changing code directly on production servers. But, you know, we were learning or at least I was.

[00:04:35] Matt Baker: Yeah. One thing that sticks out to me on the annual month cycle, I too have lived in that world and we were shipping on CDs at the time too. We would release once or twice a year depending on how much work we actually got done. But something that stuck out to me, those release cycles introduce work. That wouldn't be. There otherwise. And you can get rid of that additional work by shortening those release cycles. And I don't know if that's necessarily true now that I'm thinking about it in the CD world. But I know now that like the overhead necessary to wait a year to ship some software would be hard to justify for me instead of just shipping consistently.

[00:05:15] Allan Stewart: So what are some of the things that we've seen effective teams do? If these effective teams are going out, they're delivering value consistently. They're doing good quality code. They're. Understanding the needs of the customer. What are, what are the things that make them effective as far as practices or habits or just the day to day coding process?

[00:05:36] Dave Adsit: Well, so for, for groups of people, one of the things that I think is essential is having some kind of vision or goal or alignment that you're working towards. If you're just wandering around being busy, you're not going to be very effective, but if everybody knows what it is you're trying to do. Yeah. Yeah. collection of them. Have something that everyone knows about. Yeah, I like that. The vision aspect

[00:06:31] Allan Stewart: makes me think about some teams that I've seen where they weren't really delivering the value that the business needed. If you don't understand your purpose and how you fit in with the business, then it's really easy to kind of invent your own purpose. Sometimes teams will become less effective through creating their own identity around the thing that it is that they do. So rather than what the company needs, it's like, oh, well, we are team X and we do X. And so we deliver X. And they might be really good at continuous delivery or at least frequent delivery. They're getting code and features out the door and they're improving their spot, but it's a local optima. There's the problem in computer science of sometimes it's called hill climbing, where if you're on a hill, you know that you can go up, you can keep improving. You go up, up, up and get to the top. But then how do you know if you're on the highest hill? You know, you can go up, up, up and get to the top. But then how do you know if you're on the highest hill? Or you're just on the top of a little hill and behind you is the big old mountain that you wanted to be on, but you can't see it.

[00:07:32] Dave Adsit: Yeah, I've seen teams fall for that trap. We do X, we will maximize X. Well, but a little bit of X is good. And a lot of X is expensive. And we would have been satisfied with a little bit of X.

[00:07:46] Matt Baker: Sometimes I wonder what influence the organization has on this. I think it's true that there's some teams that don't actively seek feedback. That's, I think, a critical thing here. If they're not constantly asserting that they're serving their customer, then, you know, all it takes is a change in their customer that they don't detect and now they're drifting. And I think that depending on how well you're connected to that feedback, that can have an impact on it. So there's, it's interesting for me to think about teams I've been on that have done this. I've done this myself. Absolutely. I've gotten, I've fallen into this trap. And then there's also external factors to the team that can cause this like turning inward to occur. Where the team just stops listening to feedback externally.

[00:08:57] Allan Stewart: Where the team just stops listening to feedback externally.

[00:09:26] Dave Adsit: Where the team just stops listening to feedback externally. Where the team just stops listening to feedback externally.

[00:10:38] Matt Baker: Where the team just stops listening to feedback externally.

[00:10:54] Dave Adsit: I think that iteration is one of the things that defines an effective team. I've read that, you know, in experiments where they have people try to do the best version of X versus do them a whole bunch of them. Like there's one, one example of like clay pots, pottery class in a college where you get one point per pot you complete, you get 300 points if you make the best pot. And then they randomize who gets which assignment. And the people who make 300 pots always make the best. One of the people who makes the 300 pots. Because practice, it brings improvement. Right? And so working in small steps, iterating, I think is something that is essential for an effective team. For a couple reasons. First, it allows you to get yourself unstuck. You don't have to spend months or eons designing the perfect solution. Because you accept up front, I'm going to deliver a solution. And then I'm going to deliver a better solution. And then I'm going to deliver. And I'll probably do that five or six times. So it's okay that the first one is not going to be great. Because I know that going in. It's my draft. The first one I put out there is my draft. And then it's going to just keep getting better. You know, one of the things that happens to us, though, is that we start to get too hung up in our work. I have a workshop that I have done a few times where I make everyone in the room say, I am not my code. Until I hear like 95% of them say it. And. It's really hard for the first two or three people to say it. But pretty soon everybody's like, yeah, I'm not my code. I'm better than that. I have intrinsic value whether or not my code has bugs or not. But I think that there's some value in creating like a collaborative space where we have like shared responsibility. Because then it's okay if the code isn't perfect. And the design isn't perfect. And the delivery isn't perfect. What do you guys think?

[00:12:51] Allan Stewart: Oh, yeah. Yeah. Again, it's the perfect. Being the enemy of the good. Right. It's like, it's okay for it to not be the best thing ever. When you're starting out. As long as you can keep iterating and practicing and progressing. It reminds me a lot of this idea of are you doing project work versus product work? And it depends on what your company objective is. Again, going back to that vision. Because there are some places where there are project shops. And, you know, doing really high quality and iteration. Thing, may not be, what actually brings in money for the company, they might be, ready, and, willing, to, you, know, trot, out, their, sales, people, with, their, Cheshire, cat, smile, to, say, that's, called, a, change, request, and, it's, going, to, cost, you, so, in, those, cases, you, know, it's, something, else, but, the, product, mindset, the, product, mindset, gets, you, away, from, that, just, like, menial, task, point, of, view, or, it's, like, okay, here, is, the, thing, just, get, it, done, but,, there, is, a, lot, of, work, that, sees, or, sees, or, sees, or, sees, or, sees, or, sees, or, sees, or, sees, or, sees, or, sees, or get it to working as soon as you can. And instead, we're thinking about it in terms of let's iterate and progressively deliver value and improve it a little bit at a time, a little bit at a time, both the code, but also the team. You're improving those things as you go, because you've got the long-term strategy of this is a thing that we're going to keep around and we're going to support and sustain, not just build it once and done. Yeah. Something you said about salespeople going

[00:14:22] Matt Baker: out and doing the change request maneuver. I think you're right. And I think that sometimes this has been a hard pill for me to swallow in my career that, ah, crap, we're no longer in the business of producing the best product. We're in the business of knocking down these deals. And I know I found myself there before in my career. Companies grow and change. And that's a hard one to reconcile with, but I think it's right. And I think it comes back to what we said at the beginning, talking about the importance of doing the right thing. At the right time with the right tools, like a thing that's on the table for consideration is the robustness and the longevity of your code and your design. I don't like that all the time,

[00:15:06] Allan Stewart: but it's true. Yeah. And knowing where you fit in with the kind of work that you're doing, right? I tend to do a lot of web development and backend APIs and databases and web 2.0 kind of stuff, but not everybody's.

[00:15:52] Matt Baker: got the job done and we made the company the money. I just, it was not pretty all the time.

[00:15:58] Allan Stewart: Yeah. One of the other practices that I find really helps teams be effective is to collaborate. And there's a number of different forms of collaboration. And over time, I'm finding that more collaboration is better. Pull requests were a lot better than before I did pull requests and had a good way of doing code reviews, but pair programming was better than that. Mob programming has been kind of my go-to for the last few years of let's get together because when we collaborate, we get a bunch of people thinking about the problem. Very few of these problems are let's just slam this out as quick as we can. Who's the fastest typer? And can everybody be typing in parallel? That's very rarely the thing that is needed in a lot of software. development. But rather what's needed is people helping each other and collaborating to understand what it is that we need to do. And can we write code that is clear enough that the other members of the team also understand it, that we can make that progress. There've been so many times in my career when I have found myself writing code and getting to the point where it's like, okay, now it's finally working. This is it. This is perfect. This is great. And then as soon as I show it to somebody else, they're like, oh, well, but. It doesn't do the thing that we needed because, you know, somewhere along the way I lost track of it. Even if I understood it pretty well going into it, it's like, oh, did you remember X or Y or Z? Because that changes what it is that you need to do.

[00:17:32] Dave Adsit: When we talk about collaboration, you and I met, oh, half dozen years ago, maybe a little bit more Allan. And when we first worked together, one of the things that you would often hear me say, whether you remember or not, is that pair programming is the best way I know to improve your team. And test driven development is the best way I know to improve your code base. Since then I've learned there may in fact be even some better ways. And I may have been taught them by you in the, those early days when we were first working together. You know what I'm talking about? When your team decided to abscond with two 80 inch, 4k TVs and hook up your computer to them and form the very first mobbing station in our company. I do know about that.

[00:18:23] Matt Baker: You know, I just, as we go into this conversation, just for context, I want to say I worked on this team and that was easily the most productive team I've ever worked on. When, when I worked, I worked on the team with Allan and so Allan, please talk more about it, but I want to say that because

[00:18:39] Dave Adsit: it's a, it was a great team. Would, would you say it was effective?

[00:18:43] Matt Baker: Absolutely.

[00:18:43] Allan Stewart: Oh, it was definitely effective. I don't know that I can claim credit for everything that you said there, because a lot of that was still new to me at the time as well, but we discovered some things together and it was great.

[00:18:55] Dave Adsit: Well, and I was certainly skeptical. I was like pairing that's enough. We have a cheese collaboration. We don't need to do more than pairing and yet maybe we do. Yeah.

[00:19:06] Matt Baker: I don't always write code with other people. You know, sometimes I, or oftentimes I code by myself, but I do feel that I. Consistently write the best code when I collaborate with other people.

[00:19:18] Dave Adsit: There's just too much. I think that one of you said, said it right. When you said that it typing is not the bottleneck. That's something that's stuck in my head since I heard JB Rainsberger say it years ago, typing is not the bottleneck in delivering high quality software typing faster does not make you more effective. Like if typing is the bottleneck, you are not a very good typist. And that's okay because ideally you're collaborating with somebody who might be a little Yeah. I used to tell people when they were hesitant to pair program, I was like, every member of the team knows something that you don't. It might be a shortcut key. It might be like the way they do command line. It might be just like they learned one simple little trick to do something that you is kind of repetitive and you've just kind of gotten used to. Everybody on the team knows something. And some of them, what they know is that we can be more focused and more effective. And I just, it doesn't typically work. There may be contexts in which it does. And I could probably name a few if I were pressed, but like getting a good front-end developer and a good back-end developer to sit down and write some code together to build a feature, so powerful, so effective.

[00:20:58] Allan Stewart: It really is. Yeah, there's a lot that we could go into as far as collaboration and the many benefits of it. But I think the main thing that I would want to say at this juncture is echoing what Matt said about the effectiveness of it. At the surface, it really can look not productive. You know, that team with the big 80-inch TVs, it could be easy to go in there and just look at what they're doing. And on the surface, it's, well, they're all just staring at the TV and one person is typing. That doesn't seem very effective at all. What if two people were typing? Wouldn't that be better? What if all the... All the people were typing? But the problem is that then you don't get that collaboration and sharing, but you introduce other problems instead. It's like, oh, well, I wanted to do it like this and you wanted to do it like that. And if we're both coding independently, then we're going to see both of those things appear in the code and we'll have to reconcile it at some point. We're both going to change the same file at some point and then we'll have a merge conflict. We're both going to do something that makes it harder for us to integrate. And then suddenly we're finding ourselves being less effective, but more busy. It looks bad to see all the people just sitting there looking around at the TV screen. But once you stop and see, well, what is it that actually is happening there? And the communication, the speed with which they find little bugs and it's all of these like pitfalls that they're not falling in that brings you that effectiveness and speed.

[00:22:33] Dave Adsit: It's really hard to see the thing that didn't, It's hard to see the bug that wasn't shipped to production.

[00:22:40] Matt Baker: I wonder if, and I'm way out on a limb here. I don't have anything to back this up, but I wonder if there's some correlation between team splitting, like on the backend front end and the size of the code base. And I'm thinking about this in the context of like all code is a liability. So, you know, you're incentivized to keep that code base small. And I wonder if splitting into backend and front end makes for bigger code bases for any number of reasons, including, Allan, what you mentioned, you know, different design constructs. I have to imagine that two design patterns shoved into a code base make it bigger than if it were just one. I'm speaking very generally, but like in that sense, it makes sense to me right now.

[00:23:21] Dave Adsit: Well, I think that, I think that you're onto something there. If you don't know how someone's going to use your code, like if you're writing the API or the backend and you don't know how the front end is going to consume it, you have to write more generic or more optionality or, just more features in the hopes that you will meet the need because you're not, like we talk about going out and collaborating with our customers and our users and finding out what they need. But sometimes we don't want to do that with the people in our own group, right? I could write six extra APIs or I could go talk to that front end guy. Guess what I'm doing? Seven extra API calls, just in case. Talking with people is the worst. People, man.

[00:24:05] Matt Baker: One thing, I think about mobbing that sticks out to me. I've been thinking about this a lot lately, like practices that are hard to swallow. And I think that if I were, I can sympathize with a leader who might see mob programming and think, wait a minute, I'm not okay with that. I would see five engineers at one computer and I would think, well, that's one fifth of the output, absolutely not. And it's kind of one of those situations where maybe the real answer is, hey, just go try it. Like just go experience it for a little while because it's not going to be what you think. I'm pretty confident in saying that.

[00:24:38] Dave Adsit: Well, yeah, I think that you're right that go try it and see, especially go try it and see if you have someone who's got enough experience to help guide away from some of the pitfalls that you fall into when you're doing early collaboration. But I think one of the other things that we, as an industry suffer from, and I don't really want to go too far down this tangent, but we have a real lack of understanding and professionalism around our industry, right? Preach Dave, preach. I want to hear it. I think anybody who is a manager, director, VP, C, whatever, if you are responsible for guiding a team of software engineers and you don't understand the fundamentals of system design and delivery and how to make that effective, you are going to fail. Go read, I mean, at the very least, go read your gold rack, go read theory of constraints, go learn about flow, go learn about systems. Go learn about how we can create an effective system of delivery. Because if you're not doing that, you are holding back the capacity of your software development team. It is not easy to be a software engineering leader. You don't just get to be a leader or a manager or whatever you call it in your organization, because you're the guy who's been there the longest and you're the best coder. if I'm going in for surgery, I want the best surgeon who's doing surgery on a regular basis. I don't want the surgeon who became a hospital administrator and just has some free time. So he's going to come swing by and pull out my appendix for me.

[00:26:19] Matt Baker: I agree. In fact, I was just talking about this online today, coincidentally. Right now I'm wondering, the more you don't know about software engineering, the more you need to be willing to rely on the wisdom of the people on your team. I'm not ready to say, to say personally that you have to have been an engineer to be a great engineering leader, but it certainly helps. And I think the more that you're out of your depth, technically, the more you need to just be willing to say, well, I trust, I trust what my team says, you know, come hell or high water, I guess. And I, I don't know another way to navigate it because it's, it's pretty hard to be on one of those teams where, you know, that you've spent a career doing, and I, this isn't, I think this is just an objective statement to say, you know, you've spent a career doing something and you know, the person leading you hasn't. And when you start to watch them walk into things that you've walked into a number of times, or you feel like you, you recognize that can be a hard spot. If you can't like bend their ear to, to listen to you for a minute, it can be frustrating and just kind of like a demotivating at times.

[00:27:25] Dave Adsit: Yeah. 100%, 100%, which is part of why I think it's important. For us to have a collection of practices that have been validated and vetted in the industry across a lot of contexts, which isn't to say that anything becomes context-free, right? There are, there are times when any one of our practices is the wrong thing to do, no matter how good it is in most situations, it might not be the right thing right now for this

[00:27:53] Matt Baker: problem. I want to say that like five times in a row. Can we just edit that?

[00:28:02] Dave Adsit: But we do have a bunch of basic practices that we have developed as a, as a, an industry. Like, I think they all come back to earlier concepts to Larry wall, the Python guy. Is that right? He said that one of the three virtues of the programmer are laziness, hubris, and the third one. I always get hung up on laziness, right? Like remembering three things is hard. But being lazy, it was Pearl, not Python. Oh, right. Executable line noise.

[00:28:38] Matt Baker: So I had a duck, duck, doe it actually.

[00:28:43] Dave Adsit: So you want your computer to do stuff that's dumb and pointless and repetitive. Like don't waste your brain thinking about the deploy script. Use your brain to think about solving the business problem, find the user and solve their problem. The rest of it is just like an exercise for the user, right? It's like an exercise for the reader. You want to give that person, you want to focus on that problem for that person and remembering the manual steps to execute, to do your testing or to do your deploy. That's nonsense. Make a computer do it. Don't let the computer be lazy. You be lazy.

[00:29:25] Allan Stewart: Yeah. Automation is definitely one of those important practices. And to your statement earlier, I think it's one of those ones that has been well tested in many different contexts where we say, look, if you want to be an effective team, you need to automate some stuff. And if you're going to start automating the first place I would point anybody at is testing, get some automated tests because you're going to need it. You need to know that your code is doing the right thing. And as your system grows, it gets so painful to make sure that everything still works. You haven't broken something along the way because you were making another change for

[00:30:03] Matt Baker: another reason. Yeah. I would be impressed to meet a team that is not testing. I know some teams are still not automated testing, but if there was a saying I heard in, I think it was like 2018, I saw on Twitter, it's 2018. There's no longer an excuse to not do TDD. And if testing is a prerequisite to TDD, then boy, what a shame. We're a little late if we haven't adopted testing yet.

[00:30:33] Allan Stewart: For sure. And there's other things to automate as well, right? Your continuous integration, which oftentimes is going to be running those tests and your deployment scripts. We've talked about this in prior episodes, but you don't want to get to the point where it's time to deploy to production. Did you remember that one important step? Oh, whoops.

[00:30:56] Matt Baker: I know. Should we share some like war scars? I've deleted a whole customer's database trying to deploy live on the server, ran a bad SQL query.

[00:31:10] Dave Adsit: One of the guys that I worked with could not figure out which database the web server was connecting to. And so he just did a print line and he printed it right to the screen, the database connection string, that is. It would read it out of settings and print it to the screen on a web server. And it ran that way for about four hours.

[00:31:30] Matt Baker: While he was debugging.

[00:31:31] Dave Adsit: Well, because he had figured out what database it was, but then he had to go solve that problem. He forgot to go back and edit the web server in the production environment and remove it. A lot of things go bad when we're doing deploys. One of the things that I think is interesting is we talk a lot about continuous integration. And that meant a lot more to me when I was working on teams that were pairing or working on branches, because you had to integrate your code regularly. Right. Right. And often, as we would say. Yeah. And now I wonder, what has continuous integration come to mean for us?

[00:32:06] Allan Stewart: Oh, yeah.

[00:32:07] Dave Adsit: Because if a team is mobbing, what are they integrating with?

[00:32:10] Allan Stewart: Well, and I think that that's one of the key concepts there is that we go back to the idea of, well, what is continuous integration in the first place? It's not about having, you know, a Jenkins or a Bamboo or Azure DevOps or Azure Pipelines or whatever it is that you're using to build and deploy. Those are CI tools. They're things that help you to do continuous integration. But continuous integration itself is just, did you integrate that code? Are there branches of code out there, whether they're, you know, named Git branches, or it's just that thing that somebody's starting to type over in the corner that's different from what you're doing on your machine? And so, yeah, if you're mob programming and everybody's working on the same machine, then you are continuously integrating.

[00:32:59] Dave Adsit: So, would you say that if you were pair programming or using branches or pull requests or whatever, you're really doing continual integration? Every once in a while, hopefully often, you integrate. But if you want to really be continuously integrated, you are going to be mob programming?

[00:33:18] Allan Stewart: Maybe. I mean, that's one of those things like, when does stream processing become batch processing? Right? It's like, oh, well, or vice versa. It's like, well, how often are you going to do it? And then that gives you an answer. There are a lot of cases where pair programming is plenty sufficient, but then there's other cases where it's not because you don't integrate often enough based on the types of changes that are happening to your code base. And you can see the artifacts of that with things like merge conflicts. That's a good indication that probably you didn't integrate continuously enough to avoid a problem. Batch was too large.

[00:33:57] Matt Baker: Yeah. I wonder too, if there's a, if you would notice a size of the merge conflict, maybe correlated to the degree of the delta, you know, like the bigger it gets, the bigger your merge commits gets, maybe that's an indicator, hey, your lack of integration is really starting to impact us.

[00:34:16] Allan Stewart: Regarding automated testing, Matt, you talked about TDD, test-driven development. And one of the things that I think is a really effective practice for teams is TDD, because not because more and more I find that that's more like a byproduct of something more important, which has to do with fast feedback. While you're writing the code, you make some changes and you're getting fast feedback. You say, okay, great. I made this change and it worked. I made this change and all the tests fail and I make this change and they pass or no, they're really now even more failing pull the cord and, and start over on, on that work. But then there's also that design aspect, when you write with tests in mind, then it changes how you write your code to the point where when I was first learning how to unit test, there were so many bits of code that just seemed impossible. How did people even unit tests? Like this is ridiculous because there's these huge setups for classes or it's integrated right into the UI and there's not a hook. There's not a way to get into testing what it is I want to test. And then I learned that there's other ways to design classes that make it easier to test. And if you start with testing first, that changes the way that you do your design. And it oftentimes leads you into some really beneficial practices. You accidentally run into concepts around polymorphism and like hexagonal architectures and things like that, where even if you didn't know about that concept, you're brushing into it because the tests are pushing you in that direction. When I was first learning testing, there were

[00:35:58] Dave Adsit: And there were often conversations that would go along the lines of, oh, yeah, well, how do you test drive a class like this? And the response is, you don't get a class like that when you test drive

[00:36:10] Matt Baker: your code. Probably for the best. I think it's a ton of fun to take a legacy code base or, well, let's accept for a minute that legacy code is code without tests. I think it's fun take a legacy code base of like a sufficient size and try and test a class because it starts to become such a critique of the design. And it shows you all the ways in which you're coupled and your compadre there saying, how would you test this class? It's really kind of an indictment of his own design if we're being real. Because it's all coupled up. It was me saying it too. So we're clear. Sure. Sure. But I think it's such a great way to just sit down and what a great way to start testing or even start doing TDD. Can we just test this one function? In this whole release that we're about to do, these 20 sprints, can I test one function and just try that? Maybe that's a good intro into it. I don't know. But it's so revealing. Allan, I know you talk about it more as design than development. I totally agree with you because I think it just starts to reflect back to you your design and the tightest of feedback loops.

[00:37:25] Dave Adsit: Yeah. Well, and that was one of the things you said earlier, Allan, is like you would work on code and sometimes you'd lose the thread and you'd end up implementing something that didn't actually matter or wasn't actually what was needed anyway. It's really hard to do that when you start with TDD because you've written down, here's my unit test and it describes my functionality. This is what I needed to do. Oh, well, I'll just make it do that. And it gets like so easy. You're like, this is easy. Anyone could do it. And then you realize after a couple of weeks or a few iterations or whatever, you It's a pretty substantial and complex system or component in a system or whatever. At no point where you're like, that was so amazingly hard. I can't believe that I figured out how to do it with my convoluted multi-inheritance design.

[00:38:15] Allan Stewart: Yeah. And sometimes it's even simpler than losing the thread of what you were trying to do. Sometimes it's just, oh, I plus plus, not I minus minus. And in the olden days of my career, I would write up a whole thing. Okay. I've been coding for a few hours now. I'm going to run it and see if it works. 45 minutes ago, I did I minus minus that should have been I plus plus or I minus equals two or something. It's just like, oh yeah. And those bugs, when you're running it from end to end from the user experience or something like that, super hard to figure out why is this not working? Yeah, man. But when you're doing it in a unit test, as part of a TDD flow, it's like, oh, derp. I could see right away, that's not going to work.

[00:39:06] Dave Adsit: Let's see. I introduced the failure in the last 45 seconds. What was I doing 45 seconds ago?

[00:39:13] Matt Baker: It's a lot easier to remember than 45 minutes ago. I can tell you that. Get reset hard. Doesn't matter. Just reset. I don't know. Get reset hard.

[00:39:21] Dave Adsit: Yeah. I think you're right, Matt. Get reset hard more often.

[00:39:24] Allan Stewart: Absolutely. Especially when your boss came over and, oh. Hey, can you answer that email? And you got distracted by something else.

[00:39:31] Matt Baker: Maybe, you know what we should do? We should always get reset hard when that happens. And we should send like a wasted inventory statement to our bosses.

[00:39:43] Dave Adsit: Hey, let's not. Hey, one of us is a boss. And I don't, I don't actually, I think all of us have reports at this point. I meant what I said.

[00:39:54] Matt Baker: No, I was fair. I was writing some code. I was writing some code this morning for an advent of code. That's good. It's kicked up, you know, this year. And I was, I was doing day one. I'm way behind, but it was a, you, you got an input, a list of numbers and you had to find which two numbers equaled some particular thing or some to a particular number, and then you had to multiply them. So the naive way that I chose was, you know, a loop with a nested loop, just two, four statements looking for which, which two numbers equaled what I was, what I was after. And for 20 minutes I sat there like debugging the thing, wondering why it wasn't work working. And eventually it dawned on me that I was, I was concatenating strings instead of doing addition. But all of this, all of this, the list I was working with, like the first test input I had essentially was like 300 numbers. Like I, I, I was not thinking at all. And then all of a sudden it dawned on me, like, what are you doing? Like what you should be doing is testing. I'm testing two inputs and seeing how it goes. And, and then as soon as I narrowed in, I thought, oh yeah, I'm just concatenating strings instead of adding. And it was clear as day, but it was the smallest of functions. And I thought I was so cocky. I thought I had it and I started writing it. And then I, I, by the end I'm like, I don't think I can even call myself a programmer anymore.

[00:41:18] Dave Adsit: And I think that you have to have that experience on a regular basis to continue calling yourself a programmer where you've made the most obvious of mistakes and And the computer has done exactly what you said and not even within the same zip code of what you wanted.

[00:41:35] Allan Stewart: I was thinking about what you were just saying, Matt, about get reset hard and here's the inventory cost. But maybe it's actually the reverse. It's like, here's the savings that you get by me not trying to code through the interruption and carry a design inventory. And by this, I mean to segue into methodologies. Because we've touched on a few methodologies already or we've hinted at some things. I mean, a lot of the du jour methodologies are around scrum and a scrum flavor of agile. But more and more over the past few years, I've been learning about lean software development and really enjoying the things there. Eliminating waste is one of those things. Eliminating this inventory. That's another thing that comes in with lean practices that I think can really help make a team effective.

[00:42:33] Matt Baker: It's such a big topic for me and all of us. I know. So hard to unpack that I don't even know where to enter. But I want to talk. The first thing that sticks out for me is WIP limits and lean. Similar to what Dave said about a few fundamental practices that can improve a team. I believe that merely observing your WIP on a team can cause an improvement. Yeah. And I think that comes right out of lean. The way lean models in my mind is that there's this Mecca where you're focused on one thing at a time all the time. Don't always get there. Try your best. But in pursuit of that, I've seen teams really improve. But if you compare it all the way back and just say once a day or once a week, can we just write down how many items we're working on right now and just do that for a month? And then you can start having conversations like, is it right that we're working on 20? 30? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number? Is that a good number?

[00:43:54] Dave Adsit: Is that a good number? overall theme of effective teams, a team that has delivered even 50% of their imagined work all the way done. You've got 10 things to do and you've done five of them to completion. That is more valuable, more efficacious than if you have delivered 80% of, or 100% of them, 80% of the way done, right? Like what have you gotten done if you're only 80% on a whole bunch of tasks? Nothing, right? You have to be done. And that means to me, delivered to the customer or at the very least deployed and being tested in the production environment behind some kind of advanced feature flagging in order for you to actually be getting any value from the work that you've been doing. If you want to be effective, you get it done. It might be one thing, but if you only get one thing done, that is more effective than getting a hundred things. Partially done or a thousand things started.

[00:44:59] Matt Baker: Well, I think because if you, if you're willing to kind of be blunt about it is because in the latter case, you didn't do anything when, when it's the case that half done is the same as not started at all. You didn't do anything. And so regardless of how busy you felt, you know, you spinning out those 10 threads, it, in practice to me, I agree with you, David, all this seems more valuable to just pick one, do it. Even if you don't know which one is the right one. Like just flip a coin and go. And as long as it's like a bite-sized increment of work, you're going to be okay. But I think the key for me anyway, to what you're saying, Dave is one thing at a time.

[00:45:36] Dave Adsit: And all the way to completion to me, that is the measure of an effective team, a team that is getting work finished. And so there's a lot of strategies for doing that. And I really like some of the ones you're talking about, Matt. I love measuring and limiting whip. I love focusing. I love focusing on flow and the lead time to completion. You know, your average lead times for things. I love pushing those things smaller to smaller and smaller and smaller batches coming out more and more and more rapidly because it gives you so many other advantages around like feedback and steering, et cetera. But as you were saying, like, if you haven't delivered anything, there's no value. You haven't learned. You haven't given customers what they needed. No value has been created by having a collection of half done work.

[00:46:30] Allan Stewart: Yeah, I totally agree. It reminds me of there's a scene from Malcolm in the middle. It's been turned into a gif where he's trying to do something like change a light bulb. And so he goes into the pantry to find light bulbs and the cupboards all falling apart because the cupboard is broken. It's like, oh, well, I need a screwdriver to fix the cupboard. And so he goes to look for the screwdriver and then it leads him off to something else. And now I'm like, okay. He's in the garage doing something. And the wife comes up and says, you know, I thought you were changing the light bulb. He's like, what do you think I'm doing? Like, yeah, no, you're not. You're not changing the light bulb. Anybody can see that. Someone has to shave the ax. Getting those iterations down, I think is really important. And I wanted to say that I'm no big fan of scrum and I have some problems with agile to the point that you were making Matt, where it's not always clear what people are talking about. Some people are talking about agile as well. If you pay the consultant money, then they will sprinkle the agile fairy dust on you. And then you, you will be knighted as agile. There's some of that stuff that I really don't like. And yet scrum still has the beginnings of some of these things. It's like, if you're not doing, if you don't have a good process, then scrum is like your first iteration into lean. The problem is that people get stuck on scrum. They get stuck on certain ceremonies of like, well, we have to do stand up this way. Everybody has to. Stand up and they have to say, this is what I did yesterday. And this is what I'm doing today. And I have these blockers and they miss the forest for the trees of what it was that they were trying to do. Right. Whether those are practices like retrospectives or, or improving their cadence of continuous delivery. I mean, that's really nothing more than saying we're going to choose fewer planning poker points for it or every iteration. Oh, and by the way, this iteration is only going to last as long as it takes to do this thing.

[00:48:23] Dave Adsit: I think that it's an example of delivering in increments. Right. You know, I worked on a team, like I said before, we did rational unified process with annual releases. And we were like, well, that was the wrong answer. We, that is a thing. And it's the wrong answer for us. Swung the pendulum the other way and to absolute anarchy and chaos with no defined releases, no process, nothing. And then coming back, like that was another iteration of trying. Trying things and trying process. And then I went to another job and we were doing one week time boxes and we were delivering whatever was done. I was like, well, but we won't have the big thing that people want. Right. And to me, that was kind of my introduction into XP, which later became more like scrum for me and different jobs. But there's a lot of things that happen that they're increments and they're improvements. And as long as we're still. Learning, we'll eventually get to a place where things are working well enough for what our team needs to do. Right. And that's why you have to, we have to be kind of stepping back and getting a little bit meta from time to time and looking at what's working, what's not, and replacing the things that are not working with experiments of things that might work better. And I don't expect that every team ends up doing lean software development with multiple daily releases in the same code. So there's a lot of things that we can do. There's a lot of ways that people can get to a good enough state to deliver effectively, but you have to be thinking about it and retrospecting and improving your practice. And maybe the best thing for you to do is to focus on like getting better at your toolkit rather than getting better at your process, because maybe everyone on your team is just a little too novice. Yeah. And maybe you've got a bunch of good people and you need to be focusing on like. Really hitting the gas and getting that process out of the way so that they can just deliver constantly.

[00:50:29] Matt Baker: Yeah. I, I can't underscore this enough for myself. I think that this ingredient makes or breaks projects and teams, this ability to introspect and to hold retrospectives and to like really honestly assess the constraints that you are confronted with and work within them and constantly look back and see, you know, what's going on. How can I improve this? How can I improve that? And I've taken this to the extreme before I went out and saw Linda rising, give a talk on continuous retrospectives in 2000 something. And I went back to the team that I was on and it was just such a fantastic team that I, you know, I proposed it and they said, yeah, let's try it. And they were all willing to do it. And so we, we did this thing called continual retrospectives where we wrote a little Slack bot. And every time you had a thought about something. Something that could be improved or something that just wasn't working. Right. You would write it to that Slack bot. And then on the screen on this massive TV we had in the team area, we essentially had a team Twitter feed and each post had a smiley face or a frowny face next to it, depending on like what sentiment was trying to be expressed. And you walked past that all the time. And organically things would start coming where people are like, you know, I hear you, Matt. And I had a similar experience. I think we can fix it over here. Like, and those things have started happening. Yeah. Yeah. It was awesome. And the thing I loved about it, like if you're willing to take retrospectives and say they're turned up till 11 is that it was just happening all the time. Constantly. It was a part of the process. And I would do that on any team if I could convince them.

[00:52:06] Allan Stewart: So then we've covered a number of things that we've seen teams do that make them effective. Right. Uh, covered things around having a clear vision, collaborating together, automating, uh, using TDD for design. There's methodologies and introspection, but what conditions are required for these to work? I think Dave, you said earlier that all of these come with a context. It's sort of the caveat that it doesn't work a hundred percent for everybody in every situation all the time. So what is required for these to work or conversely under what conditions do they not work?

[00:52:49] Dave Adsit: So when I think about that question, what are the things that comes to mind is like, okay, there's a lot of things that we need to work on. our customers three, four times a day. Let's go do this. I think that that team would have a very hard time executing at that particular speed. So one of the contexts for me is the knowledge of the members of the team. You can't apply some techniques until you've mastered others first. So if you're on a team that's operating in chaos and you want to become more effective, you would do well to grab a book on XP installed or even your friendly neighborhood scrum master and say, help us bring some order to the chaos. And you might move beyond that. You might be working in a team that's so big, you've outgrown any known process, any known effective process for delivering software. And so you have to start coming up with different ways of structuring the work and the team and all of it. Yeah. Yeah. Team dynamics is a,

[00:54:17] Allan Stewart: Huge thing, right? Understanding like where you are as a team. And I think that that can manifest itself in a lot of ways. Like, are you remote or are you co-located or are you partially co-located? Those can make huge differences in how you work and which ways of working are effective. Are you synchronous or asynchronous? Or do you work for a company or is this like an open source project that you happen to be working on? Because those different environments, change the nature of the work that you're doing. And it can oftentimes change which of these practices are effective. So like, I believe in collaboration. I really prefer mob programming as my kind of go-to way of delivering production code. But if I'm working on some open source project that is done all asynchronously with pull requests as, as the mechanism to get things submitted into the, into the code base, then that pull request might be a good way to get things thing to collaboration that I can get and the feedback loops are going to be long. And, you know, the reviews might be harsh at times, but in that space, that might be the most collaboration

[00:55:28] Dave Adsit: that is really possible to achieve. One of the things that I'm thinking about to get very specific, if I am sitting down to do a Kata or a little project, that's just going to run on my pipeline or a continuous delivery pipeline. I'm not going to go to that amount of effort for something that I'm the only person who's going to use it. And I'm only going to use it a few times. And then I'm going to throw it away. I will use TDD and I will initialize a get repo because I don't want to burst your, your I don't want to change your impressions of me, but I'm not necessarily going to do perfect code every time. I, I have been known, I have been known to occasionally code poorly and get reset hard and.net test. Those are my go-tos for figuring out where I've screwed up.

[00:56:28] Allan Stewart: I don't know. It sounds like he's human, Matt. We're going to have to find a new co-host. I was going to say occasionally. I'm just kidding.

[00:56:38] Dave Adsit: You guys know me and my code too well. You have worked on too many of my abandoned projects.

[00:56:45] Matt Baker: Okay. It's okay. I, I, I too am ashamed of all the code I've written.

[00:56:50] Dave Adsit: Oh, good. Well, that's a relief.

[00:56:53] Allan Stewart: I think we've all worked together enough to realize that one of the things that will come out of our collaboration a lot is, oh yeah, you're right.

[00:57:03] Dave Adsit: Oh yeah. No doubt. You are right. So yeah, like I, I have a hard time imagining a scenario where I wouldn't grab TDD as a tool. I can see people who wouldn't. I was one of those people who didn't. First time I was introduced to TDD, I was like, aren't you just writing twice as much code to get the same value out? And I didn't get it. And it was years until somebody explained it to me in a way that I did understand. So that goes back again to lack of knowledge, lack of understanding. You know, sometimes I might not use TDD if I'm just replicating an existing algorithm. This is the algorithm. I'm going to do it this way. The test won't be just driving the design. I'll put in place a few, call them acceptance tests to make sure that I implemented the algorithm properly. Hopefully there were examples that I could use. Maybe that's a thing where if you're not letting the test drive the design, maybe you're not doing TDD. Maybe you're just writing good unit tests.

[00:58:04] Allan Stewart: Another area of team dynamics that I think about, what kind of a team are you? Or are you even really a team, right? So if we're talking about effective teams and what You've got to understand how does the team work together or do they work together? I like to think about it in terms of types of sports teams. Are you playing soccer or are you bowling? Because there are bowling teams and they do not look like soccer teams. Soccer teams, they're continuously working together. They're passing the ball back and forth. They're relying on each other to do particular specialties, but they're all on the field at the same time. The bowling team, everybody does the same thing. Sequentially. And they're rooting for each other and they need each other, but it's a very different kind of environment as far as that collaboration goes. And a lot of the methodologies and tools that you use are going to depend on that team context. How is the team willing to work?

[00:59:05] Matt Baker: One of the things that comes to my mind immediately is maybe the more detached you are, the more documentation you need. If you're writing, an open source project, chances are, if it grows any legs, you're going to have to write a contribution guide, maybe a code of ethics around it or whatever. All this stuff that comes with a open source project that allows people to contribute as effectively as they can. And that stuff's not nearly as necessary when you're all working together every day. We don't have to document the way we write our get messages when the mob knows. And even if an individual doesn't know when they joined the mob, the mob will teach them. And they pick that up. Anyway, one thing that's sticking out to me right now is the degree of documentation changes as your team dynamic changes. Recently, I've been reading articles about

[00:59:55] Allan Stewart: Wardley maps. It talks about this idea of pioneers, settlers, and town planners being different phases of evolution of a product or concept. And they talk about this idea that pioneers are exploring unknown territory. And I think about that in terms of like startups. there's a lot of information there. If you're in the very early phases of a startup, then maybe continuous deployment is not the thing that you need at that minute. Maybe a lot of regression tests is not what you need at that minute. Maybe what you need to do is to prove out your core concept and throw a lot of spaghetti at the wall and to see what sticks. In which case, there might be some things that you drop. There might be some practices that don't make as much sense in that space. If you don't know what the design is, what it is that you're going to be, then it's going to be hard to figure out what those acceptance tests are up front. And you might still use TDD to explore and to help you create a design for the classes that you're making. But at a macro level, it's going to be a lot harder to know what your end goal is. And so in those spaces, the overhead of some of these other practices might be so much that you don't get around to delivering value and your company is sunk. Because you're not going to be in this pioneer space. I think a lot of product development in the industry right now is in this kind of settlers space, to use this Wardley mapping metaphor. And they're working in this product space where a lot of lean principles, TDD, CI, continuous delivery, they get talked about a lot because they're working, they're effective, and we're seeing the business benefit of doing those. But then you can move beyond product to more of a utility space or a consumption space where it's just taken for granted that these are the way that things work. So Amazon is a great example of bringing compute into a consumption or a utility space, where you can just say, I would like to buy this much compute, please. Just like you would tell your water company, I want this much water. I'm going to buy water. And you can do it. Where you couldn't do those things in the past.

[01:02:16] Dave Adsit: Or even just, I want as much water as I need until the end of the month and just bill me. Yeah, exactly. I want as much compute as I consume until the end of the month and just bill me for it. You couldn't do that in any of those other spaces.

[01:02:32] Allan Stewart: Right. And in this third area, the people are town planners. They're working in this commodity space where they're probably the least tolerant of failure, right? So in the product space, you're talking about continuous delivery and you hear stories about things like, oh yeah, we fixed, we created a bug as part of our deploy and we rolled forward or we rolled back and it fixed it. And we had a really quick mean time to recovery. But unfortunately, when you're in the utility space, people are much less accepting of that. Even if it's small things that are broken, because they're depending on it to be this really well understood problem. It just needs to work. And so I'm not sure, but I think that those are kind of some extremes where a lot of the things we talk about tend to be in this product space. But if you're a pioneer trying something that's never been done before, or if you're a town planner doing something that literally everyone has done before, but you're doing it as a utility, then maybe some of these practices change and you have to think differently about what makes an effective team at that point.

[01:03:44] Dave Adsit: One of the things that that makes me think of is in principles of product development flow, Don talks about how there are times when you have learned enough and you're delivering the thing and it's just working. And maybe you want to start doing bigger batch sizes to get a different kind of economy around your change sets. Because you're not looking for fast feedback. You're looking for And I think that's the thing. You're in that commodity space, right? You're no longer discovering in a product. I mean, when I first read that, the first probably a couple of times I read that, it was really hard for me to get my mind around because I've been working for so long on the boundary between pioneers and settlers, where you've discovered where there is an opportunity and you're just starting to settle that territory and build that first real product. looking at the town planners who are like, well, we can save 4% on our annual copper budget if we route the lines like this instead of that. I'm like, who cares? Just build more and grow the top line and don't worry about the bottom line. But there are people who are in a space where they have to be working on the bottom line. They have to be worrying about that meantime between failures instead of that meantime to recovery. It all goes back to the same problem. At the beginning, you cannot ignore your context. Understand your landscape, understand your context, and pick your practices, pick your tools in alignment with where you are. And so that becomes one of the responsibilities of a team that is trying to be effective, is that they have a big enough toolbox and understand enough of the options that they can pick the appropriate

[01:05:44] Allan Stewart: context they're working in. And luckily, there is a lot of overlap. There are some things like testing that just they hold true. If you're going to write code, you should test it because you are a human. You are going to make mistakes. And testing is a great way, TDD especially, is a great way to figure out very quickly that you made a mistake. Things like introspection, like Matt was talking about. I think that there's a way to introspect in every effective team. What you're working on might be different, right? So some teams might be reflecting on it, well, how can we do our continuous delivery better? And some other team is reflecting on, well, how can we reduce our spend in your hosting environment or something like that? Because they're moving more towards the commodity end, whereas the other one is more exploring the space. But they're both reflecting. They're both I think automation tends to be one that always makes sense. And so there's these different flavors of practices that all fit into these different categories of things that you're going to have to do to be effective. It's going to look different, especially at the surface level, for each one of these different teams. But the principles behind it tend to stay pretty steady. One last topic I wanted to cover here is effective architecture. So as an architect myself, I think about this a lot in terms of what makes teams effective. And when you have a good architecture, then it makes it easier for teams to be effective. That goes both ways for a team. The team has to work in some kind of space. If there are multiple teams, they're working together. And the architecture of that system can dramatically impact whether the team is effective or not. But then also the architecture of what the team is building can make a huge difference on whether they're effective or not. The other thing that architecture provides is options for the business so that a business can pivot as necessary. If your architecture is too brittle, then it's really hard for you to stay effective as a team. Because when requirements change, and they always do, when the business landscape shifts, it always does, when the unexpected suddenly happens, and now it's COVID time and everybody is working from home, and what even happened to the world, you want to have an architecture that helps you so that you can pivot. And some of the things that we talked about previously feed into that. How the team works, how they design their code, how they reflect on it definitely drives towards better code and better architectures. But I think that there's a really important aspect of understanding the system that you're in if you want it to be an effective team. Because you can hamstring them so quickly by changing the rules or making

[01:08:46] Matt Baker: Yeah. I agree. There's something you said, Allan, in there that really sticks out to me, responding to the changing needs of the business. When you do that as an architect, I believe that this is a really undervalued or maybe under-discussed skill. You need to be paying attention to the way the business pivots are affecting your system, because they're telling you where your points of volatility are. And that tells you maybe where at least you should decoupling strategies or some indirection strategies to absorb those kinds of changes. And I just don't know. I feel like things like that don't get talked about enough. We maybe talk about it more at the code level, but there's a systemic side to it too, where maybe you should change from a microservices architecture to a microkernel if A, B, and C are true. But there is something to be said for that examination of over time, what sort of trends are happening in business pivots? as they relate to the changes I'm required to make? And is it actually confirming for me that my system design is working? Or maybe it's telling me that one of my, you know, components of my system design is off because one of the things to change is super hard or whatever. I don't know. But this idea you put forward is really clicking with me right now.

[01:10:02] Allan Stewart: And it also teaches you the converse sometimes too, where, look, after all of these changes, this thing never changed. So let's not invest in making it super flexible.

[01:10:13] Matt Baker: Yes.

[01:10:14] Allan Stewart: Because that's not, that's apparently not an area where we're going to need flexibility.

[01:10:19] Matt Baker: I love that. You know, and I think that this all kind of maybe buttons back up to our original topic. An architecture that absorbs change gracefully tends to make it easier for teams to be effective. And there's lots of things that I think contribute to an effective team. The organization design, the design, the team, the personalities on the team. There's, we can go on and on. But one of the things high on that list, I believe is the system they're working within. Some of that's people, some of that's technical. And I don't know if we're even separating them in this case when we're talking about how architecture plays into it. But you can definitely take a great team, put them in a poor architecture, either technical or people and watch them atrophy. You know, I do believe that can happen.

[01:11:05] Allan Stewart: Yeah, I totally agree. Well, that brings us to the end of our topic. And our episode for today about effective teams. So we will go ahead and recommend that you join up with a community of professionals by attending a software crafters group or meetup near you. Many of them have gone virtual in 2020. And the Utah Software Craftsmanship Group at utahsc.org meets on the first Wednesday of each month. And currently their meetings are virtual. Maybe we will see you there.