Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode 10 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time and with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the pain which async awaits brings to C-sharp code.

[00:00:17] Dave Adsit: I'm Dave Adsit, a CTO, and I have been thinking about the ubiquitous language of a socio-technical system.

[00:00:25] Allan Stewart: Today, we are without our regular co-host, Matt Baker, but we're going to cover the episode topic, team folklore. So Dave, what does folklore or storytelling have to do with software teams?

[00:00:40] Dave Adsit: So much. The first thing that comes to mind for me is that when we talk about software craftsmanship, we often talk about the importance of writing code that communicates with others. Other people, not just the computer. Computers can understand terribly written code where all of the variable names are some version of X and an integer. People are less good at understanding that kind of thing. So when we're working on our craft as software developers, we try to use naming, etc., that allows us to communicate effectively with others and with ourselves. And I think that that is a great start, but insufficient. Necessary, but insufficient, if you will. There are a lot of other ways that we communicate with our team. Team folklore for me encompasses a lot of different aspects. I mentioned socio-technical systems in my intro. In other words, systems that involve technology and people working together to accomplish a purpose. I think of a lot of different aspects when it comes to team folklore. The team dogma, the best practices, the inertia, all of the things that lead to where we are today and influence the decisions that we make from this point looking forward.

[00:02:10] Allan Stewart: Yeah. Going back to the manifesto, it talks about partnerships and professionals. And a lot of that has to do with how the people on the team interact, right? Do you have alignments? Yeah. Do you have alignment in the way that you do things, your culture? And storytelling is kind of the basic human mode of communication. It's always some kind of story that we communicate. Those are the things that we understand best. We can memorize facts and figures and rote memorization of certain things. But when we communicate with each other, it's almost always in some form of story. And so figuring out what our team story is becomes really important. It has a lot to do with our history. Right. And how we get to where we're at. So the history of a team then helps you understand a lot about the team and the dynamics and a lot about the code. Why did people make the decisions that they made? Why is the code in the shape that it made? Why do we have this particular architecture or are we trying to change it? If you don't have an understanding of that history, it can be really difficult. It's one of the reasons why it's hard to be a new developer on a team. But it's also... One of the reasons why you can make a really big mess very quickly. Even a really good developer with solid practices can make a big mess in a code base if they are working against the stream of the decisions and they're misaligned with the rest of their team.

[00:03:38] Dave Adsit: That's 100% true. I think that it's important for us to tell the stories to the new members of the team, partially to refresh them in our own minds. There's a lot that changes over time. And I'm reminded of many... I'm reminded of many systems that I've worked in where there was the old architecture and the new architecture. And if you came into the code base without somebody to help you and guide you, you would see evidence of the old architecture and evidence of the new architecture. But you might not have any idea which direction you were moving toward. And it would become very easy to undo the careful hard work of the team and move back towards the old bad way. Fortunately, we know that the old way is always bad. Context-free.

[00:04:28] Allan Stewart: So one way that we can learn about the history is through this storytelling concept. We can have an oral history where people tell you, right? So the members of your new team, they tell you about what's going on. And you get a lot of those conversations like, oh, yeah, that part of the code, it's special. Or there's reason for this or that or the other. Right. Right. Right. And so the way that we deal with storytelling is by writing it down. In software, we usually talk about that in terms of documentation. And documentation is kind of a double-edged sword. Because if you don't have any, then it feels very difficult to get up to speed. But can you find the documentation? If you spend time writing some, will anybody read it? Is it worse than comments for getting out of date and telling you a lie? Those are some of the things that I've often wondered about. Living documentation. That's something I've been thinking about a lot more recently. And just kind of wondering, does living documentation work? And if so, what are the things that make it work? Somebody has to be pretty dedicated to keeping it up to date. But you also have to have people reading it. As opposed to documentation that is more in the form of snapshots. And say, at this point of time, we believe this. Maybe if you have source control or some other mechanism, maybe it's a wiki or something else. It's, oh, at this time. That's what we believed. And you can go through the history of it. But there's still the potential for a gap. This page was written two years ago. Is it still correct?

[00:06:02] Dave Adsit: Or is it out of date? So when you talk about living documentation, I think that there's an opportunity to take it one step further from being words on a page to being the oral history of the team. Often told by the team shaman. Somebody who's been around for a while and knows, how the code evolved, or at least can tell you a good story about how the code evolved. May or may not represent the whole truth, but it could be enough to give you the feeling of why. On previous teams that I've been on, we've done this exercise where we get together once a quarter or so. Some regular, but not often cadence. And we draw the system on the whiteboard where everybody writes down all the pieces of the code. And people talk about those parts of the system. Or they talk about the drawing. It's kind of a way to share the oral history and to share kind of the direction that you're taking the system currently. And maybe remind people of some of the parts that are dark and twisty that they haven't visited in a while.

[00:07:16] Allan Stewart: I like that. It's almost like you can't really have living documentation in a written. Form. You almost have to have actual living people to create living documentation. But however you get it, I feel like it's really important to understand those things because without that context, like we were saying before, it's really easy to go against the stream. But also sometimes it just, there's a tendency in software development for us to come into a project that we didn't work in and be like, well, obviously it's bad. This is unfamiliar or scary, or I wouldn't. Have done it this way. And therefore it must be bad. We don't have the context. And without that context, you don't know why some of the decisions were made the way that they are. And so it's like, yeah, maybe you wouldn't have done it that way. Just context free. You look at it and say, no, I don't like code to be written this way. But when you go back in time and observe the team and understand what it was like, and that could be anything from like the available code languages. Maybe there's a change in like a framework or something that happened at some time. Maybe it was a people issue around like the level of understanding of the developers that came before. Maybe it was a difference in belief, right? Like they have different set of practices that were being employed and that doesn't make it bad code. It doesn't mean that they were wrong. Even if it's wrong now for the new context, that doesn't mean that it was wrong then. And. Keeping up. This history, right? Understanding the hows and whys of what happened before. Give us that opportunity to say, oh, I get why they did that. Maybe I have to change it. But I understand why it happened in the first place.

[00:09:06] Dave Adsit: One of the things that you made me think of there is that a system or the architecture for a system is unlikely to survive an order of magnitude change in scale. Like if you have a system that's built for a thousand concurrent users. By the time you have 10,000 concurrent users, you've probably had to make some pretty drastic changes. And it's easy when you're at the point of 10,000 users and struggling against something that was written for 1000 users to say the people back then didn't know what they were doing. And why did they even do this this way? This is so bad and so dumb. And if you have somebody who was around for the whole transition, that person can remind you why it was done. I've worked on a system that iterated through three different data storage technologies. Maybe four. At each point, it was easy to point backward and say, why was it done this way? And I'll tell you, there was always a good reason why it was done the way it was done when it was done. Sure, it doesn't meet the new context. But that doesn't mean that the people that came before were bad or wrong. In fact, if they had tried to do it. The way you're doing it now, the whole system probably would have failed and you might be out of a job. You know, at the extreme using a file system database versus a seven node Cassandra cluster. The team that was building the system with a file system database didn't have the time, the money or the people to even manage a seven node Cassandra cluster, let alone, you know, re architect the system to interact that way.

[00:10:51] Allan Stewart: Yeah, I think you see this a lot with startup culture, right? Where there's, you know, a lot of scrappiness and you're building up the concept of your company. But it can also happen in smaller concepts too, right? Like even in an established company, if you're starting in on a project, that project had a Genesis at some point. And when it started, that's when we know the least about what it is that we're supposed to do or what we're going to need. It's easy to look back in time and see what happened. Assuming that there's some record. Right. Oral or written that we can go back to, to reconstruct events. But for the future, we have no idea. And so we just make our best guess and try to move forward. And as we do that, we learn and we learn and we learn. And then we realize, oh, we shouldn't have done this this way. Oops. I made a mistake. Sometimes, sometimes they are just, I feel that way about some of the decisions that I've made. Looking back is like some things I feel fine about. I have no regret because I think. That's what it was like at the time. And it's fine. But occasionally there are also ones where I feel like, you know, that was probably a mistake. I shouldn't have done it that way. But either way, you have to kind of take what you've got in the present and move forward. You can't go back and change the past. You can't go back and recover the sunk costs. All you can do is move forward and say, what should we be doing now?

[00:12:15] Dave Adsit: Well, that reminds me of the retrospectives prime directive, which is regardless of what we discover. We must understand and truly believe that everyone did the best job he or she could. Given what was known at the time, his or her skills and abilities. The resources available and the situation at hand. And I truly believe that you can't second guess the past because you can't change it. You could stress about it, but that doesn't get you anywhere. All you can really do is move forward from the context that you are in now. To what you were saying earlier. There's a lot of times when if someone had tried to do it the way that you're doing it now, they would have failed. The reason that your startup is struggling against its code and refactoring its code aggressively and rewriting huge sections and changing the architecture drastically is because you have been successful. You could have had the same code base all the way from startup to failure. It just might have been a shorter pathway than you'd hoped.

[00:13:16] Allan Stewart: And it goes either way, right? Like you were saying before. You could have code base from the future and fail. Or you just keep the original code base all the way through without changing it. Without adjusting to the needs of the business as it changes. Speaking of adjusting to changes. One of the things I think really shows up a lot in team culture. In the folklore and the stories we tell. Are ideas around dogma and best practices. In fact, so much so that I've come to almost think of the two as interchangeable. We say best practices in the industry. But so often the context of a practice falls by the wayside. And we just think about the practice itself. Same thing happens with design patterns. We'll trot out the singleton whipping boy as an example. When should you use a singleton? When a lot of people were first learning about patterns and the Gang of Four book was getting big and things like that. Singleton was getting used in a lot of places. Because people were forgetting that part. Where you have to understand should you be using it. And the same goes for a lot of other practices that exist now. Around how you should do things. Like how you should write code. And whether you should have no comments. Or completely comment it all the time. And how you should break down your code. And whether you have regions in your code. Or all these other things that spring up as you write code. And your team will usually form an opinion around it. This is how we do it. And this is good. Because this is how we do it. If you're not careful, it can get very dogmatic in the negative way. Defined in the dictionary where you've got a point of view or tenet put forth as authoritative but without adequate ground. You didn't have the reasoning behind it. But you're just believing it.

[00:15:04] Dave Adsit: I think that we all develop our own dogmas over time. And they are typically a reaction to a time when we used a thing and it went very badly. I have seen that many times. I've observed that in myself. And I've tried to think what practices would I consider to be best always? Like if you took the context away, in a context-free way, are there any true best practices? Because every best practice that I've ever experienced has been in a context. In fact, part of the definition of a pattern is the context of applicability. Singleton is great if in fact you are trying to manage a resource which is singular. Most of the time, that's not the case. And most of the time, I've seen people implement Singleton for two reasons. First of all, because it's the one they can remember. The King of Four book was pretty complex for a lot of people the first time through. And Singleton is the one you can remember. So if somebody asks you about patterns, you throw that one out. And second, because early on, you had to do some pretty complex and tricky things to ensure that you actually only got one instance of that object or class or whatever. And a lot of that is no longer the case. Modern programming languages have simplified a lot of those things dramatically. But back in the day, if you could master figuring out a way to ensure that you only had one instance, period, no matter how many threads there were, and how tightly they were interacting, that was kind of an accomplishment. I think that's part of why people just go to that one. But man, there is a tight context where that's applicable. Most of the time, it's just not. So I've only come up with one truly context-free best practice that I would always recommend. And I'm curious if you have any that you would always recommend. Always context-free.

[00:17:13] Allan Stewart: Well, as I've been thinking about this in preparation for recording, the only one that I came up with was use source control. I have never been sad that I used source control. And especially now, you know, a lot of people are using Git with GitHub and kind of the direction that the industry has gone. There are a few others out there, but Git is really easy to start up a new repository because of the distributed nature of it. And, you know, there are some others similar like Mercurial or whatever. But being able to just say, I want a new repository now, I might never send it up to GitHub. I might never save it to, you know, Bitbucket or Azure or wherever else you tend to put your code. But just on my machine, for this little project, just like I'm playing with some code, I'm trying out an idea. It's really easy to get into that state where you say, no, I don't need source control. I'm just going to go and make some changes. And then you get to a point where you're like, well, it was working a minute ago. I need to figure out what I changed and why it doesn't work anymore. And so for me, that's one. That's one that I'd just say context-free. It's like, I don't know what you're doing or why, but use source control.

[00:18:23] Dave Adsit: That's the only one I've come up with as well. Every other thing that I've thought of, there's some context of applicability and some context of non-applicability. But man, source control, especially modern source control, is certainly there. It used to be the joke. Source safe ate my code, right? The dog ate my homework. Source safe ate my code. And in that era, I might not have even recommended source control as an always thing because you might end up wasting more time fighting source control than solving your problem. In the era where we always were using centralized servers to manage our source code, I don't know. I wouldn't have been as convinced. But now that we have distributed version control systems, especially Git, but I hear good things about Mercurial occasionally when people remember it exists. I just can't imagine a scenario where I would not get in it and commit my initial project and then at some point along the way do some commits just so that I can roll back when I make that dumb mistake that breaks it and I don't understand why.

[00:19:30] Allan Stewart: And it makes me think that one of the things for me that has really changed how I think about best practices and practices in general. And that helps me get away from being dogmatic about things is to focus on principles rather than practices. And maybe that's the same way with source control. There's an underlying principle. There's nothing special about Git. Like it doesn't have to be the one that we're using. It happens to be really easy to use and a lot of people are using it. It's popular. But there's a concept behind there. Why do you use Git? Oh, well, because I want to be able to roll back the change that I made when I made it. Or I want to be able to see the evolution of a project over time. Or I think this direction is a better direction, but I want to be able to go and refer back to this old code later if I want to. Or maybe the principle is I want to have a backup of this code. If you just Git init and then commit your first version, you have one layer of backup. It's not a very good layer of backup because it's just sitting right next to the other bits on your same drive. But it's pretty easy. It's pretty easy to push that to one of these places like GitHub. And then all of a sudden now you have a backup. You're covering these principles. It just so happens that Git is a good practice for doing that. But I don't think that it's inherent to Git. Another system could come along that everybody decides is better and the industry moves towards it. And after a while we would forget about Git. But we would still be using whatever the new thing is for the same reason. Or maybe the whole industry shifts. Because those principles are being managed in a different way. Somebody develops a new distributed file system that has version control built into it. And now nobody bothers. You're just all working on the same shared code. Something like that could happen. And it's not this command line tool anymore. But the principles and the concepts of why you were doing this thing in the first place are preserved.

[00:21:31] Dave Adsit: I think it's interesting that the only context-free best practice that we have is Git. And the only context-free best practice that the two of us could come up with is the one that tells the history of the code. I think that that ties back to the idea of as people we need a story. We need to know how did we get where we are? Why did we get where we are? Who can I get blamed for this code? Oh, it was me. I'm sorry. I'm sorry, current me. Past me was dumb and didn't know all the things that current me knows. We'll fix it today. And sorry, future me. When you know better than we both knew, you're going to still be stuck with the code we wrote forever because it's in the repo. The story is really the thing that I keep coming back to for the socio-technical system. It's the people and the technology working together to accomplish some purpose. If you don't have that way of tying it all together, a lot of what we do just feels like random wizardry. I've got some arcane data. I've got some text over here. I've got some events firing over there. I don't know. Someone please tell me the story of how this object and that class and that data store and the third-party API all integrate together to create something useful or interesting.

[00:22:55] Allan Stewart: I like that. And it goes bidirectionally. We often talk about the history because it's important. Having a record of what came before. That's something that we can look back on. And state potentially factually, sometimes conjecture, sometimes just guesswork about what happened before. But the future is also a place where we have these stories and where stories matter. Because we're not very good at knowing what's coming. But it's important for us to have the stories that tell us, well, where are we trying to go? Without those stories, it's really hard to change. We might not understand, like, the point. Well, why are we trying to change? And then somebody comes along and reminds us. Because we used to do this thing and we got a bad result. Or it was fine up until this scale and it was no longer tractable. Or something like that that helps us understand. It's like, okay, now I get why we're moving in this particular direction. Because if you don't have that, if you don't have that shaman kind of leading the way or maybe everybody takes turns being the one who's contributing part of the story, then it's easy to go off down other branches. You end up pulling in opposing directions. And you don't make a lot of progress that way.

[00:24:12] Dave Adsit: You know, when you start talking about the past, the present, and the future, it reminds me of one of the risk mitigation strategies that I really like to or exercises that I like to do with a team. If we're going to do something big, I like to sometimes do a premortem where you say, okay, I'm going to do this. And then you say, okay, everybody, put yourself in the mindset where it's 18 months, 24 months in the future. And we have failed. The whole project just, it was terrible. It didn't work out. It's embarrassing when we see each other in the hallway. Nobody wants to talk about it. Now what happened? And you work from that future point of failure backwards to the present. Identifying huge risks. Oh, and then you get all the way down to the point where you identify something that you can take action on and address, ideally in a blame-free way. It gives you something to work on based on a failure that did happen. And the premortem is like that, except that it's for a failure that hasn't happened yet, but potentially could happen if we don't take steps to avoid it.

[00:25:57] Allan Stewart: It strikes me as interesting that we learn so much from failures. When we experiment, when the odds are kind of 50-50 that we might succeed or we might fail, then we learn a lot regardless of whether we succeed or fail. But a lot of the time in coding teams, in business, you learn so much from the failures rather than you do the successes. If something worked, great. You just move on. You don't really learn. And that works both for your postmortem, but also for the premortem. Having the discussion of what went right. It's like, oh, well, you know, everything. We made a bunch of money. All of our customers loved us. And you don't learn very much from that. It's hard to kind of get at the whys. Why did they love us? Why did the stock market suddenly shift? And why did the things change the way they did? Those are really hard things to guess. The things that are easier to guess are kind of founded in the dangers that you can foresee.

[00:26:53] Dave Adsit: I think we have the opportunity to learn when we fail, but there's no obligation. In other words, we are perfectly capable of making the same mistakes over and over and over and over and over. But you're right. If you are doing something that's risky, it's on the edge of your capability and you have like a 50-50 chance. If you succeed, you learn something. If you fail, you learn something. Or if you put out an experiment and you think, I'm pretty sure this is going to work, but it could fail. You might learn which direction to take your product. I've also. Been on teams and even been the person who said, despite all the evidence that this is not working, we're going to keep going in the direction that I want. And eventually it'll all work out for the best. Or it won't. And you'll all leave me to my miserable devices with this code. That's obviously not meeting its needs.

[00:27:50] Allan Stewart: That just reminds me that there's a lot of inertia with a team, right? There's inertia in code because you spend this energy and time writing the code and getting it compiling. Right. And you're working in a particular way. Every line of code you lay down has some inertia to it. And it's like, oh, now I don't want to change it because that represents a working feature or that represents, you know, a bug fix that we made. So that can sometimes make it difficult to change things, to evolve and grow in, in a new direction. So that's really another place where this team storytelling becomes so important. We need to tell ourselves and remind ourselves and keep reminding ourselves. Why are we. Going in this new direction? Why are we changing things? There's some benefit that we are hoping to achieve because otherwise we just do things the way that we've always done it. There's inertia in code, but then there's also inertia in these other things. The way we do things, the practices and the beliefs that we have. Those can have quite a bit of inertia to them and it can make it hard for things to change. People are kind of naturally resistant to changing the way things are done. And so if you don't have that solid story, if you don't have it. Repeated so that people understand and know, Hey, we're trying to change how things work. Then it's hard to achieve that change, but it's necessary.

[00:29:10] Dave Adsit: Yeah. So one of the things that I have heard repeatedly, maybe even enough times for it to sink in is that you have to keep saying the thing until you are tired of hearing it yourself. And that's when people are finally starting to hear it from you. So if you're trying to seek alignment around a system architecture, you have to keep repeating. It so that people engage or people understand, because if it's just in one person's head, it can't be executed on by the whole team. So going back to the idea of the team shaman, the team shaman is a person who tells the stories, right? But that can't be the only person who thinks about the stories or thinks about the system. The shaman isn't the decider for the team. It's the person who reminds them of where they came from.

[00:29:57] Allan Stewart: It makes me think about fish stories and how sometimes. Sometimes. Things change over time and the details can grow when we're creating fabrications, then maybe that's not so good. But there is a tendency for us to start with basic stories, you know, really simple stories that, you know, have a clear defined moral or plot as it were. Especially in business or when working on a software project, we say, oh, well, we're doing this because there's this big goal. And so you have kind of the basis of your story. But then you go in and you flesh out a little bit more. You do some world building and explain more of the details. And as you go, the picture becomes more and more clear. And it goes from being just this one idea that somebody had that was mostly in their head. And they could tell the story in short form that didn't have a lot of details. And it was hard to catch the vision of. And over time it becomes a richer novel.

[00:30:57] Dave Adsit: That's kind of the story of. The Hobbit by Tolkien, isn't it? I know that you know this better than I do. But wasn't it just the story he told his kids that through repetition became a full.

[00:31:12] Allan Stewart: There's certainly a lot of a lot of that that was involved in there. Sure. And there's a lot of stories that he had about things which ultimately became the first age that influenced all of the story. But, you know, he had constantly changed it and told it. But because you have that consistency.

[00:31:30] Dave Adsit: Yeah.

[00:31:30] Allan Stewart: It can be hard for even one person to have that level of consistency. But if you can get that level of consistency across your team, then you can start having a deep understanding of what it is that you're doing. And then more people are understanding. And when you hire somebody new onto your team, you can convey that more richly.

[00:31:49] Dave Adsit: You said something there. You said that the stories started to influence the later stories. and I think that's the key to the whole thing. The stories that we tell about where we came from and where we're trying to go influence all of the things we do in the code now. I might find some code and if my story is the old developers were trying to sabotage the company and that's why they wrote such terrible code, when I encounter it, I might immediately hate it. But if the story that I am told is the old developers were novice but trying hard, now when I encounter that code, I am likely to be a lot more generous in my interpretation. I might say, oh, well, obviously they just didn't know that the singleton pattern was a thing. That's why they didn't use it in this most obvious of places for a singleton. I'll just put in a singleton here and then if they ever see this code in the future, they will have the opportunity So those stories influence us greatly and they change the way that we interact as a team and how we move forward as a team.

[00:33:04] Allan Stewart: Carry the story analogy forward. In a lot of stories, the unexpected happens and I feel like that impacts us quite a bit in software development projects because the industry is constantly changing. The environment and the context of your business is changing and meanwhile, over at Google Microsoft or Facebook or wherever your favorite framework or code language is being developed, they're making changes and now there's a new version. Oh, now the old thing is end of life. Now this server OS is not available anymore. Things are happening to you that you have to react to. So having those stories within your team that are representative of your culture and your practices and your alignment help you to have that continuity as you change. You can overcome some of that resistance, which is especially important as things evolve. As the world changes, we no longer think about talking to the team that requisitioned servers and is going to put one into our server farm in our colo. Those things don't happen as often anymore because as an industry, computation has evolved. The ability to run code on a server or a hosted platform has evolved. So you don't need to have your own hardware anymore. And you can rent hardware from one of these cloud providers. In that process, things changed. The way that we think about maintaining a server changed. We don't think about servers as pets anymore. But there was a time where that's what you had. You had a machine and so you had to take care of it. And so there were practices that made sense in that context. And as the context shifts, then you have to co-evolve your process. And you have to co-evolve your processes with it, as they say in the Wardley mapping space. That causes this change in your story and how you behave. And you need that your shaman to help you understand what are you doing and why. What is that context so that you can make the changes that are necessary? Or maybe like you said before, maybe it's more of like an architectural change. Our system used to be this way and we want it to be this other way for a reason. You need those stories that carry you through so that you can actually make good on the system.

[00:35:43] Dave Adsit: the last place that I worked, we had a team that was regularly complaining that they couldn't spin up VMs fast enough to be part of their CICD pipeline because sometimes it would take five minutes to provision a new Windows machine. And that was unacceptably slow. And I think this is progress, but if we don't know the stories of why we are going this direction, then we miss, we actually, we miss out on something kind of magical. Going from a six to 12 week requisition cycle to get a server so that you could hopefully address a load problem to now I can have auto provision servers in 30 seconds or less. It allows you to behave in a significantly different way. It's better here in the future.

[00:36:39] Allan Stewart: I love it. I like that. I think it's important for teams to be telling the stories of their accomplishments and to build up that morale because it's really easy to just be on the treadmill of constant change. Yep. We're making a change. You know, I get up, I go to work and we're doing things because we're doing things. And there's always something more to do. There's always more technical debt. There's always the new product feature. There's always something that is going on. And if you don't stop periodically and say, Hey, you know what? We accomplished something major. Or remember back and say, Hey, do you remember that pain that we used to feel all the time and how it's gone now? Isn't that great? If you don't do that, then you lose morale and you lose sight of like, what was the whole point of the work that you were doing?

[00:37:26] Dave Adsit: I think it's so important to hold regular team retrospectives and look back, really look back and see where you've come as a group. What have you accomplished? Hopefully you'll come up with some things that are pretty satisfying that you feel pretty good about. If you're struggling, then that's an opportunity to say, what are the stories we want to tell about this team in the future? So earlier, Allan and I talked about how we struggle to identify context-free best practices. But throughout the episode, we have mentioned some of our favorite practices when it comes to storytelling. Those include things like, a retrospective or the architectural decision records, the ADRs or pre-mortems and post-mortems. And one of my personal favorites is the draw the system exercise. Hopefully something that you heard here will help you to capture the stories and the history of how you got where you are and where you're hoping to go with your team. And if you have some good ideas sure, the history of a team, some thoughts on storytelling in a socio-technical system, please don't hesitate to share them with us. And with those practices, remember the principles

[00:38:51] Allan Stewart: behind why you're doing it. But whatever those practices are, it comes back to this idea of the folklore of your team. These stories might not always be completely accurate or complete, but they remind us where we came from and where we're going. So with that, we'll go ahead and wrap up this episode by recommending that you join a community of professionals by attending a Software Crafters group or meetup near you. In Utah, the Utah SC group at utasc.org meets the first Wednesday of each month in Draper, Utah. Maybe we will discuss some stories with you there.