Crafting Code Podcast

[00:00:01] Allan Stewart: Welcome to the first episode of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. My name is Allan Stewart. I'm a software architect, and I have liked computers from an early age. And so I decided to get my CS degree, and I've been getting paid to write software for over 20 years now. But I've only been writing software professionally for about seven years, as I've learned more about the ways that are effective. That are actually professional for writing software.

[00:00:34] Dave Adsit: I'm Dave Adsit. I'm a CTO. I have loved playing with computers since I was in elementary school. My interest in computers range from games to code to systems and teams creating value. If you find me at a meetup or a conference, I will talk your ear off about the latest book I've been reading.

[00:00:53] Matt Baker: My name is Matt Baker. I am a software architect. In my younger years, I enjoyed playing the game Mortal Kombat. And compiling Linux kernels. At some point, someone started paying me for computering about 15 years ago. I never asked them to stop, and here we are.

[00:01:09] Allan Stewart: All right. So with my co-hosts today, we are going to tackle our episode topic of crafting software. So what does it mean to craft software?

[00:01:19] Matt Baker: You know, it's a great question, Allan. In preparation for a talk I was giving at one point, I started asking people, what does it mean to craft software well? And one of the answers. That Dave Adsit gave me. Crafting software means that you build the right thing at the right time using the right tool.

[00:01:36] Dave Adsit: Obviously, I'm very proud of that. Proud enough that we put it in the intro to our podcast. For me, crafting software has always been an aspiration. But like Allan, I spent a large part of my career not even knowing what it meant. I remember distinctly. Being a young hotshot programmer with five years of experience. And I knew I could write code to do just about anything. And I was on the cusp of figuring out what these object things actually are for anyway. And as soon as I knew, I was going to tell you. Unfortunately, I'd never heard of testing or TDD or any of the practices that I now find.

[00:02:35] Allan Stewart: One of the things that I like about the word craft is that it kind of gives it this artistic element. And anybody who's been writing software very long knows that there are so many ways that you can write software. There's lots of different ways that you can write code to get it to do something. And which one is good? Which one is bad? Sort of the aesthetic of. Of software is something that I think that this concept captures really well.

[00:03:04] Matt Baker: Yeah. This idea of, Allan, you touched on it with writing software professionally. There was a time you were writing software, but then you became a professional software writer. And Dave, I can't remember exactly what you said, but similar idea. There's this point where you realize there's got to be a better way to do this. And I don't know how you get to that point other than just doing it wrong for a little while. So I don't want to disparage anyone. Anyone who's new in their career is saying like, well, you just haven't figured it out yet. None of that. It's just after you screw up the same thing over and over again, when you see an antidote to that, like it really clicks. Like TDD for me clicked relatively quickly because I thought, holy crap, I can get feedback at line by line. As I'm writing code, I can be getting this. These green lights are going right. And I understand things are working. And that's just one instance of something where if you hadn't spent time with the. Pain that is the absence of something like TDD, you're really not ready to, to see how, how impactful these practices can be. And so you might just not paying the credit they deserve until you get burned a few times.

[00:04:13] Dave Adsit: One of the things that I was just thinking of is before you got here, Allan, we were talking about people in software development. And we were talking about how every individual who writes code. Code is unique. And they're not fungible. They're not replaceable. You cannot go to the seven 11 and buy a six pack of identical software development resources. Despite the fact that many of the managers I've worked with in the past have behaved as though that were true. Every person has a unique path and every person. Learns to craft software in a different way. When you get to the point where you've got 15 or 20 years of experience, you get really set in your ways. And if you sit and think. Moat. Well, at least for me personally, like I say, everybody's unique, right? Maybe other people have a better way of learning how to do software. But for me personally. I look at the practices that I think are important. And the processes that I think are important. And all of them come back to. Answering. A specific pain that I experienced for a long time. In a in a certain way. Like this was the first really good way that I found to know. That the code I contributed to the shared repo. Wasn't going to break everything for everyone and crash the company into a brick wall. That's assuming that I was working somewhere that you source control.

[00:05:56] Matt Baker: Yeah, it really speaks about this idea of. Context to me. Right. I'm you can't walk around and say that these practices work in every domain. But you know, in a given context, you start to learn what's going to work for you. So I wouldn't say that the act of crafting software is predicated on using TDD or using version control. Even these might be table stakes granted. But but I think there's this other point here. Have you been around for a while? You've seen the pain and you start to see the results of it. I had this little saying. I like to say, which is a problem has context. The solution is derivative of a problem. Therefore, a solution has context. So does TDD always work? No, but that's not really what we're talking about here. What we're talking about is do something for a while. Find where the pain is that and then enjoy the solution being applied to the pain. Right.

[00:06:43] Dave Adsit: I was just thinking about some of the early space shuttles and early rockets that we sent up into space. And I know that they unrolled all the loops in the software they wrote for them. And so now I have a policy on my team that you have to unroll all of your loops because I learned that. Wait. No, I don't think that's true.

[00:07:10] Matt Baker: Yeah. Context, right? You get one chance to shoot a rocket. Right. You get a bajillion chances to ship to prod. Yeah. There are different things.

[00:07:19] Dave Adsit: I don't want to be on or at all associated with a rocket that gets an out of memory error. Wow. It's in flight. I hate to say this to my users, but out of the millions of requests we get per day, if you get an exception on a dozen, I consider that a win.

[00:07:40] Allan Stewart: Yeah. So kind of related to that, I think it's interesting what you were saying, Matt, before is there's a lot of learning that you have to do. Like you have to experience some of the pain for you to appreciate the practices that are often associated with these ideas of flight. Does it make sense to me in my context right now? So now that we've talked a little bit about kind of in general, let's go for a more formal definition. Anybody who wants to know more about the idea of software craftsmanship could go to manifesto.softwarecraftsmanship.org and learn about some of the ideas that have really kind of been foundational to this movement within the industry. They talk about craftsmanship as a way to create professional software development. They talk about really leaning on kind of the agile manifesto and saying, hey, it's not just about making working software, but well-crafted software. It's not about just responding to change, but we're steadily adding value. It's not just about the individuals and their interactions, but building a community of professionals and not just customer collaboration. But also productive partnerships.

[00:09:24] Matt Baker: Yeah. And even in this manifesto, I see these learnings applied. So if you take the top one, not only working software, but also well-crafted software. Year one of writing software or being paid to write software, you're all about working software. You don't have a concept of well-crafted software because you don't understand what less well-crafted software produces. So it's just, I'm just going to write software and I'm going to get this fat paycheck for it. And it's great. But then you experience year three or four of like the congestion collapse that occurs when all the legacy code just takes over. And you start to ask questions like, well, is there a better way to do this? Totally. Everything was all coupled together in that company. I ended up having to quit because it was horrible. And there were these release trains and it was a big collaboration mess every time. Blah, blah, blah, blah, blah. Right. Like you can highlight all the things that occur when you're not focused on well-crafted software, but it takes some time. And I think in each one of those statements, you see like this application of wisdom, which is we did this thing first. It worked okay. But then we asked how we could do it better. And we got to this next stage. And I see that in the manifesto.

[00:10:32] Allan Stewart: Yeah. One of the things that I think about a lot now with code is that getting it working. That's just the beginning, right? When I was first writing software, I was like, okay, I got it working. I'm done. But now as I work with, you know, mentoring developers that are earlier on, they're learning. Getting it working is an important step. You have to be able to get to that point. And, and now it's more like very good. You have just begun. Well, you're not done. You just started.

[00:11:01] Dave Adsit: In some ways, I blame my education for that behavior because education is a little bit transactional and you can always like, it doesn't matter if you turn in your first draft because you're never going to have to look at that paper again. Like, so what if you started doing your research Sunday at noon and you finished writing? You're going to be writing the last word of the fifth paragraph midnight or 1230 and then turned it in the next day. Everybody else did the same thing and you were graded on a curve anyway. So the thing that that prepared you for was doing poor work quickly and never returning to it. And it turns out that for most of us, we have to live in whatever mess we made until we learn to clean it up. And so that to me is what well-crafted starts to talk to. You did it in a way that when they ask you to improve it, you can. And I remember having some discussions with a couple of people involved in writing this manifesto when it was fresh and new. And I wanted more of a definition for well-crafted. And it kind of boiled down to. Go do software for 20 years and then come back and you'll see what I'm saying. I can't explain it to you without you doing it for a period of time, which is a super unsatisfying answer when you're coming at it from the beginning.

[00:12:41] Allan Stewart: But there's something I like about it as well in that, that, you know, going back to that kind of aesthetic of code, but also that it's more than just code. code, right? Because it's easy to kind of get into that navel gazing space where you're just like, hey, we're going to gold plate the code or it's going to make it amazing all the time. And you lose sight of these other aspects that they talk about in this manifesto. The one I wanted to touch on next is the steadily adding value. I can write code all day that provides no value whatsoever. And I might enjoy it a lot. I have a really good time writing the solution to some other problem or perhaps the solution to no problem. And it works, right? It's working software. And I might even go in and make it really well crafted software. It's very elegant. It uses the best dependency injections. It has immaculate variable naming. And it's so perfectly useless

[00:13:43] Matt Baker: because it doesn't provide the value. Yeah. You know, it reminds me, I had this somewhat working theory that I'm kind of confident in that says every engineer at some point will attempt to write a CRM. Like someone will attempt to write the elegant solution to everything, right? And then you start to get into this idea. And I think you nailed it by saying, you know, steadily adding value. Well, to what? Like, and I also believe this ties back to the well-crafted software. You're doing this for a purpose. And the purpose is not terse code, right? The purpose is not elegantly expressed classes that model the real world. None of that's the purpose, unless for some reason that is. I don't know what you're up to. But typically, it's someone's paying me to solve a problem. I must solve their problem. And in my mind, well-crafted software means I've mitigated the risk, which typically with software means less is more. So the simplest solution that could possibly work feels like a good stand-in for, well-crafted software. Yeah.

[00:14:49] Allan Stewart: And it depends on what you value, right? So if you're working at a company, then business value should be your driver. Does this thing help the business make money? Does it help the customers of your business to do whatever that they want to do? And if it's not, then it's not related. But in another context, like if you're working on open source software, you might have a different context of what provides value. And maybe it's making something that is really easy for other people to contribute to and improve the whole. Or if you're doing a project on your own, then the value might be completely in learning something. And you say, oh, well, I don't know how to use this database. And so the entire value of this project is in teaching me something. And you write different code. The nature of how you craft code changes based on the kind of value that you're adding.

[00:15:43] Dave Adsit: So there are two things that kind of came to mind around steadily adding value. The first one is this idea of code inventory. I've heard a lot of people talk about the horrors of working in a waterfall environment. And when I quiz them on it, typically nobody's actually worked in a waterfall environment. They've worked in an environment where there was no process or what felt like a very slow process. But I worked at a company once for about, 18 months that did the rational unified process, which is the very definition of waterfall. We did two months of planning and then we did like eight months of coding and then two months of QA. And then we had the week long panic where we released a year of work into onto our customers, whether they wanted it or not. Whether it was ready or not, it was release time. And we did the release once a year. I worked at the company for one release. I'm not sure that any of the code that I wrote there was, I don't think I ever saw it go into production, but because I joined too late and I was working on a side thing and it was a whole weird thing. And to me, all of that is inventory, which has a huge cost and provides no value. And so I think that's a really important thing. is produced. The customers aren't getting anything new for what all the input they're putting in. And so those two things come into mind. Like what, how are we avoiding this inventory problem? And how are we creating this system that is giving people new things that produce value for them?

[00:18:07] Matt Baker: They answer questions and solve problems. Yeah. You know, this point, one among many is one of the reasons I love talking about this subject, because I guess what I want to continue with is a quick story from a dev intersection in like 2014 in Las Vegas. I think that was the year. I took a workshop from a guy named Yuval Lowy, I believe his name. And I also watched him speak and the workshop was interesting. It was great. But when he got up to give his speech, he asked everyone to raise their hand if they were, software architect, it was a talk about architects and everyone who raised their hand, he proceeded to like berate them for the next 10 minutes about not actually knowing what they were doing. And it was interesting, but I don't know how I feel about that. But something he said really stuck with me. He said that if you write code that turns out to be a bug that causes your company $10,000 in damage, let's say you should pull out your checkbook and write a check for $10,000 and give it to your company. It's a bit like hard line. I get it, but it does speak to this idea of a community of professionals. So Dave, what I heard you just say was, look, this waterfall strategy doesn't work. We've, we've adopted this strategy and it doesn't work. And I believe it takes a professional mindset to interrogate the way that you're working and ask, is this, is this the best way to achieve the outcomes, outcomes that I'm after?

[00:19:38] Dave Adsit: Oh, definitely. Definitely. And speaking to the concept of community and problems is that we, we don't intrinsically know the answers to these problems. It requires a lot of work. And the, one of the key things that helped me turn the corner from getting paid for writing software into being a professional software crafter was discovering a couple of local communities that I could join that had some answers to the problems I was facing, whether it was from the perspective of the process we're doing and we're having these challenges. And I don't, I don't know how to solve them, or I don't know how to get along with this person. And what can I do to work more effectively with that person to things like we keep shipping code and every time it's full of bugs and we don't know what to do. And we keep getting slower and slower and we do more and more QA and the manual QA script takes half the sprint. And we don't know, how to go any faster and get value to our customers, finding communities of other professionals or somebody who's been there before and can help you or where you've been there before and can help

[00:20:59] Allan Stewart: them. That totally resonates with me because for a lot of the time that I was learning how to write code, I was kind of just doing it on my own. I mean, I got a CS degree and so I learned a lot At university is very different than what you do day to day writing code in the industry for a business, for a startup, for some tech company. And so I had to do a lot of learning and I felt like I was doing so much of pulling myself up by my bootstraps. I would figure things out. I remember when I first learned how to do unit testing, I had no idea. All I knew is that I was working at a big enterprise company and they kept saying, you've got to write unit tests. It was coming down from the CTO. Everybody should be writing unit tests, but nobody in the department really knew what that meant or how to do it. Eventually one day I just decided I got to go and figure out how to do this. They keep talking about it. So it must be important. It must be doable. Somebody knows how to do it. And I had to learn. Who knew? Who knew? Who knew? But finally, you know, I figured it out and a lot of my career felt that way is that I was pulling myself up by my bootstraps. Trying to figure out what is it that I'm trying to do? How can I improve myself? And eventually I started learning about some books that were helpful. But it was when I found the local software crafters group that really opened my eyes because suddenly I was with a bunch of other kindred spirits. They were having the same kinds of problems. They were experiencing the same kinds of things that I was where they were saying, oh, yeah, I'm also trying to drag my team kicking and screaming into writing unit tests. Learning from them. Figuring out what problems they were solving, what problems they were having, what solutions might help me was just super invaluable.

[00:22:55] Matt Baker: Yeah, you know, you talk about dragging people kicking and screaming into writing unit tests, which is appropriate at times. That's the way that it feels. And I'm also thinking about you saying your CTO had said, you know, we must be writing unit tests. In my mind, what's happening there is there's this debate or this . . . . . . . . . . . . . . . . . . . . . . . . . . . And it's that latter camp that I find that community of professionals. You know, when I sit down to these conversations at the Utah software crafters meetup, it's great. It's great. You know, one of the more memorable ones that sticks out in my mind is how do you do TDD with property-based tests? You can't have that conversation if people aren't willing to talk about unit tests. You have to be kind of bought in and sold and have done that for a while. And then you can talk about this more advanced thing.

[00:24:11] Allan Stewart: Or even know what is property-based testing. Right? Like the whole experience. Right? It's like the domain becomes so much bigger.

[00:24:22] Dave Adsit: Well, and this kind of reminds me of one of the ways that knowledge advances. And it advances in a lot of ways. Right? One of the things we hear a lot about recently is that science is advancing as people are bringing ideas from multiple disciplines. Cross-discipline collaboration, whatever. But we also advance when we get. Very deep into. I don't want to say echo chamber, but it's kind of like an echo chamber where everybody around has a deep context around a thing. And keeps reaching further and further. And you're just digging down together to build out and discover and explore the limits of knowledge. If you know test-driven development. If you know unit testing. Would you use property? Testing on everything? When would you? When wouldn't you? Why? If I've never even heard of it, what would make me want to go explore it? And who kind of discovered this topic anyway? Who came up with the concept of doing this type of testing for the types of systems that I work in?

[00:25:36] Allan Stewart: And I think that's really important. That you have a constant influx of people that are coming into the community. Uh, and. Because as each person enters the community and changes the dynamics slightly, they're bringing something else to the table. They're bringing some additional experience or perspective.

[00:25:54] Matt Baker: Yeah. Dave commented on something about, you know, this is cross pollination of ideas that is advancing things. And I think there's not, I think, but rather that resonates with me, you know, and, and Allan, to your point, you can't have that if you're all existing in this echo chamber that Dave was talking about. So it does require this.

[00:26:41] Allan Stewart: is this idea of like master journeyman and apprentice is like these different levels. And I think that that in some ways models community, but in some ways it may, it maybe doesn't quite fit. You know, there was a, there was a book by Pete McBreen, software craftsmanship, the new imperative. That was one of the first books that really discussed this concept in general. And it kind of laid that down this, this pattern of going from apprentice to master, and also kind of this vision of like a medieval guild model of software development that really came into play with this book. But how does that relate to these communities of professionals? How does that relate to this idea of growing in the craft of software? I think that one of the

[00:27:26] Dave Adsit: important things is that we go through phases as we progress. And it's not to say that, you know, And you get your new rank. And now you're a senior software developer, level three. Like none of that ever really resonated with me well, because everybody is going back to earlier where I was talking about how everyone is unique. Everyone has a unique set of and collection of related and collaborating and self-reinforcing skills. So there isn't a way to really measure a software developer's total skill. But there is this concept of as a novice, I need someone to tell me what to do and to a large extent how to do it. And then as I start to master that one way of doing it, I can start to break away from those rules. I understand when they apply, and I start to understand when they don't apply, and I start to understand new things. And if you use some of the other models of skill acquisition, like Shu Ha Ri, you follow the rule, you break the rule, and then you become the rule. If you've ever worked with somebody who's been working in a domain for a very long period of time, they will sometimes say stuff that makes no sense. Like, why do we do X? Oh, well, we do X because it's the right thing to do. And I know it's the right thing to do because I've been doing X for this long. I don't even know what you're talking about, man. Like that's not even a reason. But it is a reason in that person's mind because they've had so much experience and maybe they've tried a hundred ways to accomplish that end. And it always comes back to doing it this way works and other ways don't. And they don't have time to tell you the hundred other ways that they've tried and why they think that this is the right way in this context.

[00:29:29] Matt Baker: Yeah. And sometimes I think we get stuck into this value judgment conversation when we talk about master journeyman. An apprentice and coming to what you're saying, you know, this is the answer because I've done it for 20 years and whatever. And I think that's true. And I think it's okay to acknowledge that you gain wisdom when you do a thing a lot. And it's not to say that if you're an apprentice or a journeyman that you're not as smart as the master. That is not what is being said. But what is being said is, look, when you do this thing enough, when you write software enough, you're going to pick up some tricks that are not because you're smart, not because you're versed, not because you have your IQ, but it's just because you've been doing it. So you pick up these things. So I think that these master journeyman and apprentice, at least in part, just capture the fact that this person's been doing it for a while. Now, I'm not trying to say that, you know, there isn't a difference between the engineer who's written software for 10 years and the engineer who's repeated one year 10 times. That exists and that's true. But, you know, what I'm trying to say is if you're open and you're trying to constantly progress, just engaging is going to take you far. And, you know, again, it's not that if you haven't done that engagement, you're not smarter than the person that had, but the master, the journeyman, they've just been around for a while and they've been trying to do some things. And sometimes their answer really is, you know, go write software for 20 years and then ask me again. I know that's a

[00:30:57] Dave Adsit: crappy answer, but sometimes that's reality. And I think part of that goes to the fact that we don't necessarily have the language to talk about it well. Makes me think of a couple of other related domains. For example, in chess, they say that a master or grandmaster has played a hundred times more chess than somebody at whatever the next tier down is. And if you go to Thinking Fast and Slow by Kahneman, they talk and Traversky? I can never remember his partner's name on that book, but they talk a lot. How we train our pattern matcher in our brain. And one of the things that we do by seeing things over and over and over and over and over is we basically train our brain to skip all the hard thinking part and go straight to an answer. And nobody wants that. And we actually talk about that in software development is like when we train AI, when we train machine learning algorithms, they just skip right to the answer. And then what? Like we want to know what the answer is. And then we want to know how did you get that answer? Well, what are you considering? Do we want you to consider those things? Is that a valid input? Like, I don't care what color the person's eyes are. Are they going to crash their car into that pole? Maybe they picked up on the wrong things. And that's a thing that is also worth considering is this is one that gets me a lot is sure I've been writing software for 20 years, but how do I know that I've trained my pattern matcher on good data as opposed to very biased data. How do I know that I'm not leading a team off a cliff at full speed? Because I'm pretty sure that that hill just curves down on the other side instead of dropping abruptly 500 feet. I haven't looked to the, but it's fun. It's, it is definitely fun. Like it's super fun right up into the last minute or second. Right. It's like,

[00:33:06] Allan Stewart: it's like a bankruptcy, right? You do it a little at a time and then all at once.

[00:33:10] Matt Baker: Exactly. Exactly. Well, and not to harp on, on this point, but you, you just said a few times, how do I know? And again, I think you're capturing this idea of professionalism where you know how to get it to work. How do you know that that's the best way to do it? Right. This, this, how do you know? I think if you're able to establish these feedback loops to start answering that question, then you're starting to become a professional, right? Because there's a myriad of ways to do it. And, and you're not asking, can I do it? But you're rather asking what's the best way to do it? How, how do I know that the solution is the best? And I think it's that line of questioning that's really just going to, it'll progress you in whatever craft you're doing.

[00:33:51] Allan Stewart: For sure. So if software crafts, craftsmanship or crafting code, if these, you know, are about these professional ideas, right? Well-crafted software value, adding value, communities of professionals, et cetera, then what is it not? How do we distinguish? I know Dave, you often talk about this idea of, well, how you define something in large part is what is it not?

[00:34:16] Dave Adsit: So what is not software crafting? I think you're right. I definitely do that. I say that often. Okay. You've told me what a thing is now teach me the other part of the pattern. So I know when I haven't found one and that's the harder part to learn. I think, one of the things that comes to mind for me is that crafting software is not about creating art. I go back to what is a craft? It's a thing that you make and sell for value. You're trying to create value for someone else in exchange for some kind of compensation. Art exists presumably for its own sake. Sometimes people create professional art, but I, I feel like in general, we have an idea as a society that they've, their art has lost something for it.

[00:35:08] Matt Baker: If they made it for money. Yeah. It's like art is expression versus art is product. Those,

[00:35:14] Dave Adsit: those are different things. I still sometimes play that song, sell out. Yeah. So as we established earlier, I do not have perfect pitch. I have, I think the exact opposite

[00:35:28] Matt Baker: of that, but, um, but how do we know Dave, we're only going to know if you sing and then,

[00:35:34] Dave Adsit: yeah. And it's going to be really hard. We're not ever going to get the not test for my singing ability. You just have to trust me. I've done it for 20 years and it's always terrible. What a crappy answer. So there's some amazing software art. I love it. I love software art. There are people who've created languages that you can't even use. There's one that I've dabbled in called Rockstar kind of playing on the idea that we could all be Rockstar developers and screw up all of the recruiters plans. If we just learned how to write one program in Rockstar, which

[00:36:17] Matt Baker: transpiles to JavaScript or something. So you're saying when they ask you if you're a Rockstar developer, you say yes, but it's not, yes, I'm like a 10 times multiplier unicorn developer, but yes, I actually just write in the Rockstar language. Yeah. I mean, I have one,

[00:36:34] Dave Adsit: one Rockstar program on GitHub and therefore I am a Rockstar developer.

[00:36:38] Matt Baker: More so than anyone else I know. Probably. I have more cred.

[00:36:43] Dave Adsit: Yeah, that tracks. That tracks. But there's, there's so much art that is software. There's this idea of a quine, which is software, which when executed generates its own source. And there's this, I don't know, some genius or group of genii who have somehow come up with, this Ouroboros quine that starts with a Ruby file and then goes through a hundred programming languages until the output is the same as the input. I don't know the types of things that blow me away. They're very, they're awesome in the truest sense. They create awe in the observer who is trained to understand, but they definitely are not valuable to my customers or probably anyone. Else's there's other really cool software art, like the international obfuscated C competition. If you want to see some code that is artistic, go look at some of that. My favorite was either the winner or the runner up for the 1989 contest. It's a really cool program that when executed generates the value E anyway, I would say, one of the things that software craftsmanship or craft of software is not is creating art.

[00:38:14] Allan Stewart: Yeah, I totally agree. And one of the other things that I think sometimes with the idea of software craftsmanship, especially the word craft or craftsmanship often evokes this sense of perfectionism getting back into that medieval guild mindset. It's like, well, we have to create the masterpiece. And that's how we'll know that we are master software developers. I remember this anecdote about a speaker who really just did not like this whole idea of crafting software at all, because he felt like everybody out there who was doing that was trying to create essentially Faberge eggs. You're doing it. You're gold plating the heck out of this thing, just because that is how you're going to make like this perfect art piece for its own sake. And that he felt like that, that wasn't valuable. That wasn't. Delivering value. And personally, I feel like he just misunderstood the space that really it is about delivering value. It is not perfectionism for its own sake, but it is delivering some kind of value.

[00:39:15] Matt Baker: Yeah, I think, you know, even this word we're using value, I'm going to, I'm going to change it out for a second and use the word quality, whether or not you delivered value is a judgment that someone's going to make, right? Sure. Typically, the customer that you're trying to serve. So, so much. Yeah. So maybe there is a world where the value is in the perfect if statement or like the flawless ternary operator, you know, like maybe that exists, but you should ask yourself if that's the domain that you're in. When I hear this, this anecdote about the Faberge egg, I think, well, I agree with it as long as the domain wasn't someone wanting a Faberge egg, you know? So sure. So, and I'm, I'm dragging this out to an absurd degree, but what I'm trying to say is that quality is subjective. And value is too. And value is subjective. Yeah. And so when you're, when you're writing code and coming back even to something you were saying earlier, one of the things you don't learn about when you're, when you're taught maybe traditional computer science is ascertaining your customer and what they need, you know, and that's just another skill of professionalism. And so when we talk about, I can't remember one of the things out of the manifesto, but anyway, I guess what I'll end with is this idea of art, this idea of, of overdoing things. This is, it's all subjective, I think. Yeah. So really what it comes down to is, you know, are you optimizing for, for your customer receiving value or not? Maybe that's something, maybe this is like an overgeneralization I'll regret later, but that's how I'm feeling right now.

[00:40:43] Allan Stewart: For sure. I read that a 93% of paint splatters are valid Pearl programs, but I don't think that any of them are very useful for my employer.

[00:40:55] Dave Adsit: I can attest to that fact. I've met them. So it goes back to this idea of your employer, right? Someone is paying you to create software. Someone is buying that software or the output or whatever the downstream value created by that software is being sold to someone. And if it's not being exchanged for currency of some kind, then we have no evidence that it provides value to anyone. Uh, one of the domains that I find fascinating and complex is economics. And that's one of the things they talk about over and over is the value, the amazing power of free giving it away for free. You don't know how much somebody actually values it. When people start paying for it, then you know, you've created something of value to someone. And so that's kind of one of my measuring sticks among many.

[00:41:55] Matt Baker: Yeah. I maybe I'll just pile on with one more, one more thought here. Um, if I were to walk into, let's take a car mechanic and taken, I don't know, I drive a Hyundai, let's say I drive it in and say, you know, I'd like the oil replaced and I'm waiting in the waiting room and the mechanic comes in and says, you should really gold plate your engine and replace it with a, uh, a race car engine that, that might be true for what he or she is optimizing for their mechanic. And they think like this car could be great if it had all these things. But again, I'm the one paying and really I just want the oil change. The, I don't want the gold plating. I don't want all these bells and whistles. I just want you to solve my problem, which in this case is an oil change. And I think that this gets lost. We, we talk a lot in software. I feel like an absolutes, good tool, bad, cool, good pattern, bad pattern, good solution, bad solution. And, uh, maybe the solution parts valid, but, um, I, I just think that there's so much context that we neglect, um, when we talk about delivering value. Yeah. Yeah. Uh, I'm not sure how I'm going to connect this back all the way. I'm maybe I'm on a tangent here a little bit, but the thing I would just say is, um, one of the things I've appreciated about this, this group, the software crafting group is that we do spend a, a, a not small amount of time talking about what does it mean to actually deliver value to your customer?

[00:43:22] Dave Adsit: Have you considered how much you could tow with your Hyundai if you replaced the engine with a V8 diesel?

[00:43:30] Matt Baker: I haven't because it's not my problem.

[00:43:33] Dave Adsit: Well, it's someone's problem, presumably. Oh, fair point. Matt, always focusing on your own needs.

[00:43:42] Allan Stewart: So if a crafting software is not about art, um, another thing that I think it really is not about is elitism. And it's a, it's a really interesting thing because one of the things that, that I feel like I get a lot of pride out of writing really well crafted software, or at least what I believe to be good software for me, crafting is really a type of elite work. It's like, Hey, you are doing your best work here. You're doing it the best in the context of you're not just making art, but you're delivering value. You're doing something that your customer needs, but it's not about elitism. It's not about saying, oh, there are only so many people who are capable of doing this and no more. Yeah. But rather I have found that the community is very much about like lifting each other up and, oh, let me show you this cool thing. Hey, let me tell you about this idea that will improve your whole system. I don't even work for the same company as you, but I want your company to succeed. I want you, your software developers to be elite in the best sense of the word.

[00:44:54] Dave Adsit: Yeah, I completely agree with that. For me, data data data data data data data data data data data data data data data data data data data

[00:45:23] Matt Baker: our ideas. If we come across as saying our idea is better than yours, then I don't blame people for feeling like we're elitist. But I also think there's a way to communicate that, hey, this is just an idea I have, and it seems to be gaining some traction. And it's hard to stay there. And I get it. We're not always going to be perfect. But the way we communicate our idea, I think does have an impact on the efficacy of our idea.

[00:45:48] Dave Adsit: Definitely. But Matt, have you considered the fact that sometimes I really just do have a better idea? I hadn't. Not in all the years we worked together. I mean, that does tell me something.

[00:46:02] Matt Baker: I mean, I've told you I have. Okay. But I really haven't.

[00:46:08] Dave Adsit: I'm just glad it's out in the open. I mean, that's the real thing. That for me, I'm getting value right now by finally hearing this.

[00:46:18] Allan Stewart: Yeah. So I agree with you, Matt. I think that in general, my observation of the movement and what makes most sense to me is that it is not a naturally elitist group, but we have to be careful. We have to be careful of how we're presenting ourselves and be mindful of what it looks like from the outside looking in, or even from the inside, what other people are thinking about just kind of the social dynamic of the group. Well, to wrap up our discussion, I just wanted to ask the question, why do we care about this

[00:46:55] Matt Baker: Well, I'll start. I've been thinking about this one a little bit. I do not believe that all methods of creating software are equal. I believe that certain approaches are better than others, and it depends on context and all of that, but it's not all equal. And since I believe that, and it makes me start to think about the people that I'm writing software for. So right now, it's an employer, and these people are giving me money and then giving them back whatever my employer is is oftentimes looking for ways to maybe give me more money or more benefits not me because i'm mad but just me because i'm an employee and they're always trying to do better and i think that we owe the same in return when we when we take money for some for some job in this case you know writing software and if all the methods are not created equal then i believe it's now it's upon us to figure out the best methods for for our particular situation so why is crafting software important for me because i believe it's the the best way to sort of honor the agreement that you've entered into with an employer or a customer or whatever they've given you money and they expect you to deliver on the agreement in the best way that you know how i completely concur with all of the things that

[00:48:11] Dave Adsit: you just said those all resonate very deeply with me i would like to add that my hope is that i can find someone like me who didn't know what he was doing or didn't know what she was doing and i can save them some of those many years that i spent wandering around thinking that i was the biggest fish not knowing i was in the smallest pond and thinking i was doing well by getting a rough draft ready and shipping it i feel i you know i feel like i need to give back something to the people who i can't pay back i can't go back and teach the handful of specific people who i won't name how to do tdd because they still know but i can help someone else maybe be exposed to concepts that they don't otherwise have an opportunity

[00:49:09] Allan Stewart: to learn about yeah yeah same with me just in the same way that i was talking about earlier where the craftsmanship group really like opened my eyes and helped me in a lot of ways my hope is that this podcast will reach out to some other people and i've worked with matt i've worked with dave for a number of years now and i just i really like the discussions we have i feel like we really get into this topic and have something to say that might be useful and interesting to other people so i think our collective hope to speak for everybody is that you'll enjoy this podcast and that it will help you understand a little bit more about this idea of crafting code and that you can take some things that you hear from from this podcast and apply it in a very useful way into your life into your work into your code so with that we're going to wrap up the first episode by recommending that you should also join a community of professionals by attending a software cross or group or meet up that is near to you and data data For anybody listening who is in the northern Utah area, the Utah SC group at utahsc.org meets the first Wednesday of each month in Draper, Utah, and we hope that we will see you there.