Crafting Code Podcast

[00:00:15] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been considering how much I want to spend to replace my recently broken office chair.

[00:00:32] Dave Adsit: I'm Dave Adsit, an engineering leader, and recently I've been thinking about incremental progress and the power of consistency.

[00:00:39] Allan Stewart: Our topic for this episode is the art of code. We have previously mentioned that we don't think of our code as art, the code that we work on day to day, but we also talk about the idea of craftsmanship. So what is the difference between code as art and the art of code?

[00:01:00] Dave Adsit: Yeah, I've thought about this a lot as well. Over time, I've used to give a presentation around software craftsmanship in which I contrasted craftsmanship with engineering, like structural engineering, and on the other side against art in talking about the art of code. And so I've thought about code as art for a long time. We've talked about examples on this podcast. We've talked about quines, where you have code that when executed generates its own source, and the Ouroboros quine off of GitHub that generates its source in a new language 100 times in a row until it comes back and generates the original source again. We've talked about the International Obfuscated Sea Competition that they used to run. Are you right? Sea that doesn't look like it could be interpreted, but actually does something useful. We've talked about the Rockstar programming language. I even tried once to write a compiler to transpile C-sharp into Rockstar, and then I gave up because I don't know how to write a transpiler, and I didn't have the time to learn in the moment. So those are some examples of what I would consider art expressed through code. When it comes to what is art, I mean, that's a philosophical question. I suppose things that come to mind are something that's surprising or novel or self-expression for its own purpose, as opposed to to serve some other purpose.

[00:02:36] Allan Stewart: Yeah, I think about those things as well, especially when I think about things like modern art. It's almost like anything can be art. And when we're thinking about code as art, I feel like the value of the code is kind of weighted. Towards kind of what it is intrinsically, rather than what it's doing for you, or whether you can maintain it.

[00:03:01] Dave Adsit: Yeah.

[00:03:02] Allan Stewart: So like the equivalent of a picture, I guess, a work, you know, a statue or some other work of art. But when I think about the art of code, I feel like the value is weighted more toward outcomes. It's what the code does and how maintainable it is. And so like both of them have some of this essence of creativity and style. But the art of code is more, or at least the way I think about it is like, how do you use your judgment? The sense of taste that you have an aesthetic for creating high quality code, the style that you use, not just like coding styles, like or linting rules. Yeah. But more of a style around how you craft the code, for lack of a better term, the elegant solutions that you come up with that avoid surprises. But they're elegant because they fit the domain and they work really well. They are, you know, nice and performant, easy to maintain, rather than elegant because, you know, the braces were placed in such a way that it, you know, looks pleasing to the eye. You know, it's sort of an abstract vision rather than the actual what you see art vision.

[00:04:32] Dave Adsit: Yeah. One of the things that I think about as we talk through this is when I used to do a lot of database work, I would spend time formatting my SQL statements for readability. And that's completely unnecessary. The interpreter doesn't care. But when I worked on them, it made it easier for me to understand where I was. And I will say that is, of all the parts of the code base that people have different styles and different ways of writing code, that database layer is one where it seems every developer has come up with their own style, their own format that they use that they think is the most expressive and the cleanest and the easiest to interpret. Yeah. Yeah. So given that, one of the things that comes to mind for me is this quote. I think it's a famous quote. Maybe it's only famous in my own mind. By Paul Valerie, he said that he is a poet and he said, a poem is never finished, only abandoned. And so formatting the SQL was never actually finished. I just stopped when it was good enough and I could move on to something else. Right. When I was working on some of these systems, it was, they would be 50, 60% SQL statements. And if I spent all of my time, formatting them all exactly the way I wanted, I would probably not get much else done. So you don't finish art. You just abandon it when it's no longer providing you that value that it gave you when you were originally working on it.

[00:06:07] Allan Stewart: Yeah. The more I think about this, I consider like if code is art, then it's kind of the code that we're dealing with, but the art of code or the art of coding is almost more like a meta statement. It's like how, how you go. About right. It's the, uh, it's the difference between the paint on the page versus how you go about painting. What kinds of, you know, brushes and brush strokes and things you use.

[00:06:37] Dave Adsit: Yeah. I, I like that distinction. The art, the art of code is about creating code that you would be happy to put your name on, but is not in and of itself, the valuable thing. Like we we've said before. Many times, and this is borrowed from someone else as well, that code or functionality is an asset, but code is a liability. Right. And by treating the code with some level of respect by expressing our art ourselves artistically within the code, we create code that is less of a liability because it has other characteristics that are desirable, like maintainability, uh, changeability, et cetera.

[00:07:20] Allan Stewart: I also like this. Yeah. I think it's interesting to think about it in terms of the phrase that you are not your code. Yeah. Which I think we've said before as well. Many times. That we're separating the value of the person from the value of. The work product or the, the expression of what you have created. And I think that that's important partly because of this distinction, right? Where there's this separation of it's like, oh, it's, it's how I'm going about the work that matters. And, and partly the result, like the, the resulting effect that it has on the code. So like. The actual code is impacted by this, but when we, when we recognize that distinction, hopefully it also helps us recognize the distinction. It's like, oh, you as a coder are good because of how, you know, like the, the care and the quality that you put into the code, you know, like that, like you actually cared about the outcome. Yeah. You weren't just waiting for paycheck on Friday, right? Like you are actually engaged and, and that, that is what matters. Yeah. Yeah. Yeah. Like, if somebody comes along tomorrow and says, oh, hey, there's actually a change in requirements and we're going to delete all the code that you just wrote. It's fine. Yeah. You're not your code. And, and that, that expression can go away. It's, it's okay.

[00:08:36] Dave Adsit: When I was a very young coder, I used to have a zip disk, which tells you when this was, but I had a zip disk of all the code that I'd ever written because it was so precious to me. It was hard to write back then. And now I can write code now. Like even before. Yeah. LLMs made generating code trivial. I've written so much code that I couldn't even be bothered to care. If you, you say, Hey, we're going to drop this functionality. I'm like, thank goodness. I get to delete 10,000 lines out of this function or out of this application that we've been maintaining. And that will make it easier to continue maintaining and enhancing. Yeah. So, so, but why does it matter though? Why, when we talk about this, like, why does it matter that I have a style and execute in an artistic way? And I use my creativity to come up with elegance. Solutions. I think to understand why it matters, we should talk a little bit about what happens if you don't. Like, let's look at the counterpoint where we don't do any of that. And we just, whatever code, whatever the first draft is, we throw it out there all the time. What happens then?

[00:09:38] Allan Stewart: Yeah. With the current climate, we hear a lot more about slop these days and, and AI slop, but I've seen a lot of slop code well before LLMs. We came into the, into play. And when, when people don't care about the quality of the code, when they don't care about the art of coding, I've found that we get into various problems and it's not, it's not that the code doesn't compile. It does. It works, but it's, it's hard to work in, right? We, we didn't care about things like coupling. We didn't think, care about things like naming conventions. We didn't think about things like naming conventions or deleting something that is no longer used. And so you trip over it, you know, long after the, the feature has ceased to be utilized. And there's just like just some remnant of it in, in the code. So I feel like those are, those are just some of them. And a lot of times we, we bucket these under reasons to do clean code reasons why we want to have clean code. But if. More than anything, I think there's just like, there's just this, when you don't care, there's just a lot of stuff that you have to filter through. It's like debris, right? I've used sometimes the kitchen metaphor which I borrowed from Martin Fowler, where if you come into the kitchen and the kitchen is clean, then it's easy to prepare a meal. But if the kitchen is dirty, then you don't have the working surfaces. You didn't have the pot or the pan that you need. Like every, you know, you go to grab a spoon and there's no more spoons in the drawer because everything's dirty and it just makes everything more difficult and keeping things clean helps us to be able to move faster in a sustainable way.

[00:11:38] Dave Adsit: Well, and having worked in kitchens, I will say that cleaning is something you should be doing as you go. It's not something you can save up till the end. And if you try to do that, you're going to end up with a substantially higher, a higher amount of work doing cleanup. And so, but if you clean as you go, then you can continually maintain that, those working services and those tools in such a space, in such an order that you can keep making forward progress. So you mentioned that, you know, with LLMs, it's really easy to go from no code to some code or no code to a lot of code. And I think that one of the things that that comes to mind for me is that when we're building algorithms, we often talk about like the base case of the null case. Where we go from, we're handling zero, and then we go from zero to one, and then we go from one to many. And I think that what we've learned is that that zero to one is something that anybody can do with a $20 AI coding assistant. And what gets hard, the place where we need to apply engineering or where we need to have some artistic approach to our code, some kind of, you know, aesthetic approach to our code is going from one to many. You know, when we're first doing that, those initial prototypes, when we're doing those initials, like it kind of doesn't matter because the code will meet the need of the prototype. But when we start building for larger scale, for larger numbers, for, you know, more people working on the code or more people using the product of the code, it becomes more important for us to deliver code that is not slop. Yeah. That's, Yeah. That's, easy to, easy to understand, easy to enhance, easy to maintain, and meets all of those business requirements. And I think that that's one of the things that for me comes in when we talk about craftsmanship, craftsmanship is a craft is something that you sell. It is, you are selling your services, your knowledge, your experience, whatever. And craftsmen need to be thinking about the business implications of the things that they are doing, not just the aesthetic or artistic aspects of them. Right.

[00:13:51] Allan Stewart: And I think about it in terms of constraints a lot. So scale is one of those constraints that often comes up and bites us, but also just the number of features can be a big constraint because as things are coupled together, you very quickly go from having a lot of options to, oh, well now it's difficult because if I change this, it's going to affect some other thing in the system and now, nobody wants the other thing in the system to change or break. And so now we have to, you know, think about it more. We have to exercise that judgment to figure out, Hey, what is the right way to build something that's not just thrown together, but that, that can be modified. Yeah. When the time comes without, without the whole house of cards falling down, which oftentimes it feels like that, right? Like, or I've described it as kind of like a spider web in some kind of bases where if you touch any one part of the, of the web, it vibrates to every other part.

[00:14:58] Dave Adsit: Yeah. I think about growth a lot and inevitably any of those aspects of growth is going to cause us to slow down per unit of effort injected into the system. So if we have more people, then some of our effort gets eaten up in communication and collaboration. If, if we have more users than some of our effort gets eaten up in terms of like handling the coordination between servers as they scale. If we have more code, then there's more connection points, more coupling between the various aspects of the code. And if there's no coupling, then you can definitely go very fast, but it means that your code is not really cohesive either. Right. There's that concept of like balancing coupling and cohesion. Yeah. So our ideal, our ideal case is linear growth. As we add more code, more developers, more users, growth can be linear. Our realistic case is that it's going to always be sublinear velocity over time and velocity as you scale, the system tends to go down. And so what we are trying to do is create an environment where we are as close to a slope of one as possible. As we scale, the system, the systems that build and deliver this product. And so one of the, I think we have to have clean expressive code. If we want to stay as close to that linear growth as possible, you know, adding one developer adds one developer's worth of effort, as opposed to adding one developer adds 0.8 or 0.6 developers worth of effort and adding the next one is even less.

[00:16:42] Allan Stewart: Yeah. And so I think going back to this idea of art, right? The art of code, or the art of coding, I think it has a lot to do about a lot to do with these judgments of how should we construct it? How do we reduce the coupling? What makes it clean? Like there are some, there are some specific things that we can do that are, are perhaps more rote, right? Uh, adding tests, um, or refactoring, right? Like we can sit, we can say you should refactor and like, and that's the kind of thing that you could put, uh, in your employee handbook or something where you say thou shalt refactor all of thine code every day as, as it is written. And you can give it an instruction for Claude to say, absolutely LLM. You have to refactor your code. That's a step of the process. But, but how do you do that? How do you construct the test? How do you separate your, your files? How do you organize the system? What, what makes clean? Yeah. How do we decide what is clean and what is clean enough? And I think that that is kind of the artistic part, the aesthetic, the judgment part that we need to get to. So what are some of the characteristics that we want for the code bases that we work on?

[00:18:07] Dave Adsit: Well, I mean, Bob Martin, uncle Bob already wrote a book called clean code and we can just borrow a little bit from there. Some of the luminaries of the industry have shared, share their perspective and you know, we could start with Bjorn Strauss drop. I think is how you say it. Inventor of C plus plus he, he says, I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide the dependencies, minimal to ease maintenance error handling complete, according to an articulated strategy and performance close to optimal, but not to tempt people, but so as not to tempt people to make the code messy with unprincipled optimizations, clean code does one thing well, and that's a lot. There's a lot in there. And I really think a lot of it is valuable and a lot of it is expressed in the C plus plus language itself, right? Elegant and efficient optimal. So as not to tempt people to do unprincipled optimizations, that is definitely something that you need to remind yourself of. People have when they're writing C sharp or C plus plus, right? Clean code does one thing. Well, I like all of what he says in there. And I think about those things as I'm working on a code base. Yeah.

[00:19:28] Allan Stewart: And a couple of the words that really jump out to me are elegant. And tempt. Right. Cause some of the other things we can measure pretty easily. Efficient. Right? Like we, we can, we can put a test harness on it and find out how efficient. This could be. This could be. This could be. This could be. This could be. This could be. This could be. This could be. This could be. This could be. of UML and has written various books. He says that clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent. Again, kind of these things that highlight for me, like intent. What did you want to have happen? What were you trying to achieve? And now it's about communication. Again, not with the compiler, not with the computer. Communication with whoever's going to read this well-written prose. How do you decide whether it's well-written or not? Again, it's one of those qualitative judgments calls that you have to make. I don't know that I want my code to read like Shakespeare. I don't know that I need to be using rhyming couplets or iambic pentameter for my code. Because again, that starts to drift into code as art, I feel like. But there are perhaps some equivalencies that we can apply for the art of coding where we say, hey, these are some techniques that I can use to make it easier to express myself so that the code is simple and that other people might think that

[00:21:35] Dave Adsit: it is simple as well. Well, and that one leads directly into the next, that concept of simple. Michael Feathers, the author of Working Effectively with Legacy Codes said, clean code always looks like it was written by someone who cares. So simple, easy to understand. Someone who cares about this code, they've done things to the code to make it more habitable, I think is a word I like to use. The code base itself is habitable in a way that you can walk into it, live in it, understand it, know where to put things, know how to keep it clean and all of that. Yeah, I like that. And I think that's probably the case for most students in a high school setting is you wait and procrastinate until the last possible moment. You write one draft, you maybe read through it again and say, ah, good enough. Give it to the teacher. The teacher is used to it. You give it to the teacher. So they score it on a curve. But if you actually cared about using your writing to convey a concept and to deliver something, that rough draft becomes your first draft and you iterate on it a few times. You clean it up, you restate things, you move things around, you restructure arguments, you refine it. And then you turn in something that is a later draft that is better and more ready for prime time. And then you review and evaluation. I think the same happens with code.

[00:23:19] Allan Stewart: Yeah, I agree. We've discussed before the importance of naming and even just that, right? So like in your English paper, the words you use to convey something matter. Well, in code, how we name things matters. And it turns out to be really, really hard.

[00:23:37] Dave Adsit: Yep.

[00:23:38] Allan Stewart: The last quote that I, that I pulled from the clean code book is from Ward Cunningham, the inventor of Wiki. He says, And again, I think this is absolutely one of those design things. Like there's so many ways that you can write code. And if you're just looking for, does it work? There's an infinite possibilities, you know, infinite number of possibilities of how you could write that code. But if it's going to turn out to be pretty much what you expected, It narrows the field quite a bit. And it requires you to think about, you know, how have you broken up the code into different files, into different classes or modules or functions or routines so that when somebody's reading it and you got that name right, so that they didn't run into something unexpected, but they say, oh yeah, based on the name of this function, I think it's going to do this. Oh, and it does. That helps. So much with maintaining and extending code.

[00:24:47] Dave Adsit: It really does. So you and I are in agreement with all of the contributors to clean code and, you know, uncle Bob, that it is important that code be elegant and expressive and maintainable and all of that. And we also are in agreement that that means extra effort. That means not turning in your first draft, not turning in the slop you generated with your LLM, your LLM, not turning in whatever, the first thing that you threw at the wall. So if we're going to put in extra effort, now the question becomes, how do I know when I've put in enough extra effort and how do I know when I need to stop because it's becoming wasteful and it's too much, right? We know there's diminishing returns as we continue to refactor and refactor and refactor and refactor. When do we stop? How do we know

[00:25:39] Allan Stewart: when enough is enough? It's a hard question. And it takes me back to that word judgment, because at some point I feel like it is, it's a judgment call. I don't, I don't know that there is a definition for myself. One of the things that I have often done is just kind of for myself, gotten into a process where I make sure it's not the first draft that I'm turning in, that I at least I get things working. I go through some refactoring passes to make sure that it is looking good, that I'm, I'm feeling, comfortable feeling happy with the results. So the first step is to not stop when it's, when it appears to work the first time I worked through it a little bit more than that. But then beyond that, I don't know how much time I really want to spend. There's often pressure to get things delivered, to move on to the next task, to make progress, right? Ship our, ship our code and actually deliver that value. And so on, on the other side, what I do is, is follow that boy scout rule of leaving things cleaner than I found it. And if I always am in that habit of whenever I find something that is just annoying me, finding something that is problematic, then if I didn't, if I didn't go quite as far in my initial creation of, you know, it's like, oh, well, I turned in the third draft. It should have been, you know, the fourth or fifth revision. Well, I'll pick those up later as I go, because I haven't shelved this forever, but any, any code that I come across in the work that I'm doing is subject to be improved.

[00:27:20] Dave Adsit: Yeah, I definitely agree with that. And I would say, you know, there's a, an interesting question is, is refining and improving the code at odds with our other value, which is delivery. And we talk a lot about the importance of delivery and getting things done and getting things out into the hands of customers. And are these actually at odds? And I would say, no, not really. As long as we are continually iterating. One of the valuable things that we get, one of the valuable pieces of feedback we get is from actual use of our software. So if I ship the third iteration, you know, I wrote it, I refactored it, I wrote some more code, I refactored again, and then I shipped that out to customers. The experience of the customers, whether they engage with it, whether they use it, whether they, whatever, that is a thing that tells me whether or not I should continue working on and refining as part of the code, right? So should I, if I'm building a new feature in the same area of the code base, that's another opportunity to continue refining and refactoring and cleaning this up and making it elegant. And if nobody engages with the code and we never build another feature in this area, then that is a good sign that I don't need to be continually refining that code. You know, one of the things that happens to us particular, well, I was going to say, particularly when we're younger, but I'm not sure that that's actually true. I think it's true. it might happen to us throughout our careers is getting caught up in the, with the idea of gold plating the code that we're working on, which is to say, I've written code and I am refactoring it. I've refactored a couple of times. Now I'm unnecessarily gold plating this code, or I am continuing to work on it and refine it and refine it and refine it despite limited or no return on that. There's a few reasons that are psychological. I think sometimes it's easier to keep working on the same thing than it is to start something new where I'm going to have to start my new learning journey on like, what even is this new feature? I understand the feature that I've just built. So I'm going to keep refining it versus going on to the next feature, which I don't understand yet. And is maybe a little intimidating because maybe I'll have to learn something about a new tech or whatever. Uh, I've, I I've seen that happen to both myself and to developers. Who've worked with me, that tendency to get hung up and can, and work on the same thing forever, kind of like this sentence, but we do need to move on. We do need to ship it and move on to the next thing. You know, that's the value of the system is that we can keep enhancing it with new

[00:29:59] Allan Stewart: functionality. Perhaps asking yourself why is a good way to like kind of check yourself. So, so if you're ready to move on, and you ask yourself why, and you say, oh, well, because I'm feeling really rushed, there's pressure. Well, that might be an indication that you should maybe slow down and think about, Hey, well, what's going to happen? Is that code really done? Or are you just rushing through it? And you're, you didn't give it its due, but on the flip side, if like what you're saying is like, well, I just don't really feel like tackling a new hard problem. I was like, okay, well, that might be telling you something too. It's like, if there wasn't a why there wasn't like, oh, well, there's a reason. Like when, when this goes to production, we're going to have some performance issues, or I know that the next feature that we're going to build is going to require us to make some changes here, or, you know, there there's these other wise, but when the why is just, eh, I don't want to, then that might be a signal. It's like, oh, well, you're just, you're just gold plating though. Yeah.

[00:31:09] Dave Adsit: Yeah. Yeah. Yeah. It's helpful to have some heuristics or some structure around understanding when enough is enough, when you have something that is sufficient and when it can, can be considered done. Uh, one that I really like is the four rules of simple design and they are in hierarchy order. First rule is it passes all the tests, which of course requires that you have tests and sufficient tests, right? Number two is that it reveals intention and that speaks to good naming. is a sign that I need to go back and refactor all this code to use the same function, share an algorithm, share an object, whatever. I like to do aggressive refactoring as I go, of course. And when there is obvious duplication that shouldn't exist, I'm going to remove it immediately, even if I haven't reached that three copies of the same algorithm. Um, and the last one is that it should have the fewest elements that can reasonably, uh, pass all those other rules, right? It passes the test. It reveals intention. It has no duplication and it has the fewest reasonable elements. So there's no extra modules. There's no extra duplicate classes. There's no extra functions that there's no, definitely no dead code in the system, but also no unnecessarily, unnecessarily, unnecessary blow. You know, we've talked, we've talked in the past about patterns and pattern languages and like getting obsessed with patterns and trying to apply every pattern to every code base. Well, we don't need to do that. That creates an unnecessary number of elements in the code base, including patterns, but also all of the supporting structures of objects and functions, et cetera. We want to minimize the amount of code that we have. And that helps us have a simple design. It helps us have code that is clean and maintainable and easy to reason about.

[00:33:33] Allan Stewart: I like the idea of heuristics to help guide us with this. Um, another heuristic that I might add in, uh, kind of relating to patterns is like, are you following the patterns? Um, and maybe better said the conventions of the code base that you're, you're working in. Like if there are any higher level architectural things that you're working towards, like, uh, like we're, we're trying to surfing surfing surfing surfing surfing surfing that I look at it to see, hey, is this done? Is this sufficient? Yeah. Does it feel like it belongs with the rest of the code base? Because there's no one right answer, unfortunately, right? Just like there's no perfect architecture. There are many ways that the code could be written. There's many system designs that we could choose to use. And we just have to make the judgment call of what is useful right now? Because what we need right now might not be what we need later. In fact, it almost certainly is not. But trying to build what we need later can make it so difficult to build what we need now as to make it impossible to have progress.

[00:34:58] Dave Adsit: One of my heuristics is that for every order of magnitude increase in customers, you should effectively rewrite your code base. Which means that if you have 100 users, if you scaled your code appropriately for 100 users, and now you have 1,000, you will have to rewrite significant portions of your code to meet that 1,000, and then the 10,000, and then the 100,000, right? And if you are not doing that, then you are over-engineering for the scale that you're actually operating at. If you build a system that can support 100,000 concurrent users, and you have five, you are wasting resources in many ways. Server resources, developer resources, design resources, you're not acknowledging the current state. You've overdone it. And you need to scale back your designs to be more appropriate to the place that you're at right now. So along the lines of no perfect architecture, one of the things that is often talked about in the circles that we run in is the idea of a screaming architecture, or rather an architecture for a system, that reveals what the application is. If you're building an e-commerce system, you should look at it and say, this is an e-commerce system. I can tell by the structure of the modules and the components, as opposed to this is an MVC system. Right. Which is hard.

[00:36:29] Allan Stewart: It's something that I've thought about and tried to do in code bases I've worked at, and I'm not sure that I have been entirely successful at helping reveal it. One of the areas that I, do try to do a better job of it than not is, I'll often create like a domain section, like in C sharp, it's its own assembly. Namespace. Yeah. And a namespace to say, Hey, this is where all the business logic lives. And in there, I want it to be grouped so that you see the things that are important to our code base. But in other projects, it's easy to slip back into. It's like, oh, well, this is where the utilities are. And this is where the controllers are. And this is where the, all the message listeners are or whatever.

[00:37:18] Dave Adsit: Well, and it's, that's definitely the case. And I would say that that speaks to the fact that there is no perfect architecture. And it depends on the scale. If you have two people working on a single application, maybe, you know, you're doing a mono repo and your architecture is layered and everybody knows these are the controllers. These are the workflows. And these are the data access points or the, you know, the interfaces into other systems. And maybe that's okay because maybe at your scale, it's expressive. And when you have 10 times as many developers, you need a different architecture to support that scale. So why do it all? You know, if we could just, if we could just get away with throwing out slop and they would be fine. What, what do we even need it for?

[00:38:07] Allan Stewart: And we've talked about some of the problems with slop as far as, you know, like from a business point of view, it makes it harder to maintain. It makes it more expensive to run, et cetera. So like there, there's definitely a business case, but I think that there's also a case for how the art of code affects you as a person, right? As a human being who is approaching their job and that you want to be able to feel satisfied, right? You get that job satisfaction, uh, the feeling of having done good work. Um, I think it's also tapping into that intrinsic motivation for those of us who are here because we, we care about the art of code. We're not here just to collect a paycheck. Obviously that's important, but, um, that we have care for how things operate. Um, not, not just the product features. And, and personally, I find this because I've been at a lot of different companies and built a lot of different kinds of software, but I don't, I don't always care so much about what it is that I do. Uh, as far as like, what, what does our company do? So I, I do care. There are some things that I enjoy better than others. And, and that may be why I've ended up in various education companies or service companies that help people be able to, you know, do their job better. But ultimately what I care more about is, am I serving? My company? Well, in my area of expertise in writing code, rather than do I care so much about the specific thing that the company has is doing. Um, so there, there's, there's that aspect of it. There's also kind of the aspect of, do I care about how a thing is built? Right? So I think about like a precision watch. Can I have a passion for how that is created? And do I care about, care about that as much as I care about accurate timekeeping? Because accurate timekeeping can be done. I think you need a cesium, Adam. Yeah. Right. Like, or a quartz crystal maybe because you know, the, the Casio $10 plastic watch that you can buy. That's got Dora the Explorer on it is probably not considered a work of art, right? It's, it's cheap, but it's accurate. It's probably more accurate than a 300 year old clock. But that 300 year old clock might be a work of art in the care that was taken in creating it.

[00:40:52] Dave Adsit: Yeah. It makes me think of the product management concept of jobs to be done. You know, when we talk about jobs to be done, it's like, do you want a drill or do you want a quarter inch hole in your wall? And the job to be done, is drilling a hole is creating a hole for some other purpose. In fact, the job to be done might be hanging a picture versus drilling a hole or whatever. Right. And so sometimes you care about the outcome. And sometimes you care about the process. Like I have a shop full of tools. I have tons and tons of all kinds of tools. And I like to have tools. I like to have the capability to do. Whatever at any time. But also the reason to have them is because I want to hang a picture. Or put up a TV or whatever the thing happens to be. And so you think about like both the outcome, which is I have. A picture hanging on the wall. And the process of like, I drilled a hole in the wall to get that. And the tooling and the prospect, you know, the things that I did to make it happen and how I feel about my knowledge and skills and my ability to execute those with the tools I have. And so all of those things kind of play together into making me satisfied as a homeowner that I did this. Home improvement project myself.

[00:42:20] Allan Stewart: Yeah. There, there are various quotes that I found that talk about. You know how it's not what you do, but how you do it or the manner that you achieve it. And I think about it just kind of the concept of. Yeah. That pride in your work. Would you want to put your name on it? Would you want to sign it? When you want to move that painting? Are you going to be real mad about the condition of the drywall underneath? Or, you know, in, in code, do you want to be known as the person who wrote that code? You know, that code that I'm talking about, right? Either because it's amazingly great or horrifically terrible. Like. Yeah. One way or the other. You're, I'm not sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure

[00:43:26] Dave Adsit: I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure I'm sure now wasteful. And so that comes back to judgment and judgment requires experience. And we have to have both good and bad experiences to create good judgment. And we're going to get those whether we want to or not by doing the actual work, getting in there and working on systems, building projects, delivering things and figuring out, hey, this time I refactored this amount and it later wasn't, I found out it wasn't enough, or I refactored this amount. And later I found out that that was a big waste of time and I should have just shipped the earlier version. And so I, I feel like there's no substitute for experience and developing that judgment that we need to create the kind of code that we're actually proud of. That's elegant and matches the expectations that we have for the system we're working in.

[00:44:31] Allan Stewart: And so we've talked about in previous episodes, code as art, and, and now we're talking about the art of code. We've talked about the idea of craftsmanship. And I think the core concept that I want to leave our listeners with is that there is an aesthetic, there is an art that matters to the code that we're writing. Even if we're not trying to create an art, we're not trying to say, hey, this, this, this is going to be an amazing piece that's going to go in a museum of code that expresses the angst of my soul or anything like that. But that just the way that we go about creating our code, the, the judgment, the aesthetic, the creativity, and the style that we use to try to create elegant solutions that are maintainable, that matters. It has a real business impact and it has an impact on our own psyches. As developers and authors of that code.

[00:45:34] Dave Adsit: Yeah. I'm reminded of a quote from Adam Smith, who is the father of modern economics. He, he wrote a couple of books and one of them is the theory of moral sentiments. And in that book, he says, man naturally desires not only to be loved, but to be lovely or to be that thing, which is the natural and proper object of love. In other words, we want to think we did a good job and we want, other people to think we did a good job when they see our work product. We want them to appreciate us and we want them to appreciate us for the right reasons. And so the way I think about that is when I'm working on a code base, I don't want to be the reason why it suddenly got really hard to keep moving forward.