Code with Jason
Code with Jason
252 - What is Good Code? with Jerad Gallinger
In this episode, I talk with Jared Gallinger about what makes good code. We agree that code must first work correctly, but real quality comes from being understandable and maintainable. We discuss how different code requires different quality standards - throwaway scripts can be messy while core systems need careful design. We explore how UI design limits code quality and why creating good software, like art, requires both discipline and comfort with necessary waste. A practical look at a concept developers discuss but rarely define clearly.
Life hasn't been the same since the pandemic. Instead of working at an office around people all day, like we used to, most of us now work remotely from home, in isolation and solitude. We sit and we stare at the cold blue light of our computer screens toiling away at our meaningless work, hour after hour, day after day, month after month, year after year. Sometimes you wonder how you made it this far without blowing your fucking brains out. If only there were something happening out there, something in the real world that you could be a part of, something fun, something exciting, something borderline, illegal, something that gives you a sense of belonging and companionship, something that helps you get back that zest for life that you have forgotten how to feel because you haven't felt it in so long. Well, ladies and gentlemen, hold on to your fucking asses. What I'm about to share with you is going to change your life. So listen up.
Speaker 1:I, jason Sweat, host of the Code with Jason podcast. I'm putting on a very special event. What makes this event special? Perhaps the most special thing about this event is its small size. It's a tiny conference, strictly limited to 100 attendees, including speakers. This means you'll have a chance to meet pretty much all the other attendees at the conference, including the speakers. The other special thing about this conference is that it's held in Las Vegas. This year it's going to be at the MGM Grand, and you'll be right in the middle of everything on the Las Vegas strip.
Speaker 1:You got bars, restaurants, guys dressed up like Michael Jackson. What other conference do you think you can go to, dear listener? Or you can waltz into a fancy restaurant wearing shorts and a t-shirt, order a quadruple cheeseburger and a strawberry daiquiri at 7 30 am and light up a cigarette right at your table. Well, good luck, because there isn't one Now. As if all that isn't enough, the last thing I want to share with you is the speakers. And remember, dear listener, at this conference, you won't just see the speakers up on the stage, you'll be in the same room with them, breathing the same air. Here's who's coming Irina Nazarova. Oh yeah, here's who's coming For Freedom Dumlao Prathmasiva, fido Von Zastrow, ellen Rydal, hoover and me. There you have it, dear listener, to get tickets to Sin City Ruby 2025, which takes place April 10th and 11th at the MGM Grand in Las Vegas. Go to sincityrubycom.
Speaker 1:Now on to the episode. Hey, today I'm here with Jared Gallinger. Jared, welcome, thanks, jason. So we met because we work at the same place I'm contracting there and you're an employee there and we had a really nice conversation one time that involved philosophy, because I think, if I remember right, you were a philosophy major, is that right?
Speaker 2:Yeah, that's right yeah.
Speaker 1:And then we met in person and we had a nice shouted conversation to try to hear each other over the very noisy band in the very echoey room. That was a terrible choice on the hotel's part.
Speaker 2:It was a really pro-choice on our part, our group of people to sit right next to the excellent jazz band but just playing noodling so beautifully right in our faces. Great social decision on our part.
Speaker 1:Exactly. But now we're both in nice, quiet environments and, yeah, I thought we could talk, as you and I discussed pre-show talk about what is good code, because this is. You know, we talk about good code and code quality and stuff like that a lot and we say like, oh, this code isn't very good because such and such, but rarely do we actually talk about what good code means, which seems like something we should talk about. And if you had asked me five, 10 years ago whatever, what does good code mean? I don't think I could have given like a coherent answer. I certainly wouldn't have an answer at the ready, off the top of my head.
Speaker 1:I certainly wouldn't have an answer at the ready off the top of my head, and I think probably most people don't, but I think most people should. So let's talk about that. And what is your take? Not to put you on the spot, but do you have an idea off the top of your head of what good code means?
Speaker 2:Yeah, so after you mentioned that this was a topic you're interested in talking about, I was thinking a bit about it and I don't know if this is the philosophy training coming out or if this is just how my brain tends to work, but it feels so. I'm just for context. I would describe myself as a pragmatist. You know, I'm very driven by making choices based on what is useful and useful in a particular context, right, you know. So you know, when you're asking me the question of what is good code, the first thing that pops into my head is, well, it's code that works. Now, that's a kind of a weaselly answer, right, what does it mean for code to work? And this is very much, you know, this is very much coming from the philosophy. It's like you start asking these. You know not just five whys, but like 37 whys all the way back. You know very much, like the child, just endlessly more and more questions to get to the heart of the matter, but can easily be never ending.
Speaker 2:But on products, you know, the first answer that pops into my head is well, it's code that accomplishes the goals that are set out to work for the customers, right, maybe that's all that it means to have good code.
Speaker 2:So, but then, thinking about what it's actually like to work in the context that I'm in, working at these software companies you're not working alone, right? So you know you have to think about what is good code in the context of being on a team, or if you're at a bigger company that's more than just a few developers. What's it like to write software in that context? What does good code mean in that context? And then, of course, what is good code like? Are we talking about statically at this point in time, just looking at what the code base is like as of, say, this commit, right, or is it? You know what is a good code base? Look like over time, right? So you know, I just go to all the different dimensions that we could be talking about, and there's a lot to dig into there well, I appreciate that because I I I do the same thing with code.
Speaker 1:Like more and more in recent years I've been digging into, like you know, like you said, like good code, it's code that works well. What does it mean for code to work? Um, stuff like that, which I think we could all benefit from doing a bit more of. Um, let's see. You said a couple things that I wanted to dig more into. Oh yeah, like the snapshot of the code base today and the changing over time and stuff like that. First, I want to share my uh definition of good code. For me, it's code that's easy to understand and work with. Because code has, like, two jobs one is to meet its functional requirements and the other is that it has to be worked with. And to me, I guess I put the functionality part as just like table stakes, like either it meets the functionality or it doesn't, and if it doesn't meet the intended functionality then it's just incorrect. That's not really a subjective thing, but on the and so and I think probably pretty much everybody agrees that like the code should work.
Speaker 2:Yeah, it's pretty intuitive, right yeah?
Speaker 1:Yeah, and so the only thing in question is like, what does it mean for the code to be high quality or whatever? And for me, again, it's code that's easy to understand and work with. So, before we get into anything else, do you have any any thoughts based on my definition?
Speaker 2:I mean I, I think I come to more or less the same place, the one. There are a couple of maybe little nuances that might be worth pointing out For me. I think that the aspect of so what did you say? It's code that's easy to understand and to work with.
Speaker 1:Exactly.
Speaker 2:Yeah, I think the understanding part is only because it needs to be worked with, right? I think that if you are writing something that is just a one-off like, if it is just for whatever reason, we could contrive an example of code that is just throwaway code, right? I don't know that it is actually important for that to be understandable outside of that moment. You don't know that it is actually important for that to be understandable outside of that moment. You don't necessarily need to think back on that and understand why you made this decision or what that means. Nobody else ever needs to read it. Maybe it's just like a script that you're literally writing once and you don't even save it. You're just like you know when I was a front end dev, especially, did this all the time Just like you know, write a little something in my editor, put it in the Chrome dev tools, run it once and then it's gone forever, right? Totally agree. Who cares if that's readable or understandable, right?
Speaker 2:But I think the grokability of code, especially by other people, only comes from the fact that they need to be able to work with it, right? The idea of especially in code in an organization, not just for yourself, needs to be something that somebody in five years can stumble across. Need to make a change, and you're no longer need to work there. You're no longer working there, and they still need to be able to pick it up and do something with it and make a change and understand something of the motivation of you. Know why you wrote it that way, know why you wrote it that way, right. So I feel like the, the understandability, is uh uh kind of a sub criteria and sub criterion of the. You know people need to work with it.
Speaker 1:Um, yeah, and I think that's actually a really important point. You made that like code only needs to be good if it's going to be worked with. Um. I think of code as being like there's like trunk code and leaf code. Um, like if it's a leaf, like nothing else depends on it, then who cares? Um, because like I'm not super happy with my analogy because maybe that's not exactly the significant thing, but like if it's a code that, if it's a piece of code that nothing else depends on and it doesn't get like looked at or worked with hardly ever, or like let's say, it's never going to get worked on again, like you can afford for it to be terrible and it doesn't even matter. And that's why I think, like um ai is great for writing tiny throwaway scripts that you're only going to use once, because who cares if those are the most inscrutable things in the world?
Speaker 1:Because as long as you can use them once for their intended purpose, and then you can just delete it. And then, if you need to do the same thing again, you can just inexpensively rewrite the same thing with AI and delete it again, and that's totally fine.
Speaker 1:It's cheaper to do that than it would be to take the time to make a high quality piece of code and then use the same code twice. But AI, I think, is terrible for writing really critical code that other stuff depends on, because that code does need to be understandable and AI is at least not yet very good at writing understandable code, but again I think like I really want to. I want to emphasize the significance of the fact that not all code calls for an equal level of quality.
Speaker 2:Yes, I would completely agree with that. I think you know, like look, for example, you know the difference between you know, let's say you're writing a library, right, and you have. You know, methods or classes that are public, and then you have methods or classes that are public, and then you have methods or classes that are private. They're only consumed by the public methods, right? Sure, maybe if it's an open source project, you care whether the code is understandable, because you want people to be able to contribute.
Speaker 2:But in terms of people who are just consuming the library, it doesn't matter whether a private method is well named, unless they are digging in because they're needing to debug it or something like that. Right, you know, it really only matters what have. You know what. What is most critical is the naming of the public methods, the public classes. You know the public interface, because those are the things that people are actually going to be directly working with and you can have to care much more about those than you do about naming anything private or you know, the, the inner workings, uh, of things, right, you know.
Speaker 2:So, yeah, I think there's kind of inherently a you know the inner workings of things, right, you know. So yeah, I think there's kind of inherently a kind of you know tiering of you know how much you need to care about the you know quote unquote quality of different aspects of the code, depending on how much they're going to be worked with. I think, that's absolutely true.
Speaker 1:Yeah, and I want to dwell on that for a minute too like talking about the APIs of pieces of code you know, everybody knows about, like there's the Stripe API and you can interact with Stripe using that, or there's the ActiveRecord API, yeah, but I feel like people talk less about the API of their own custom code.
Speaker 1:But I think about that a lot, like I feel like a large part of I'm articulating this for the first time but like a large part of the quality of a piece of code is determined by its public facing API. And I think of an application as like just a whole bunch of layers of APIs because, like, for example, in a Rails controller, you might interact with an object via its public API, of course. You might interact with an object via its public API, of course, but then you go inside of that object and it uses other objects through their public APIs and you just keep going and going until you reach the core and that's just the bottom of it. It doesn't depend on any other objects and it's like, if every layer is easy to understand and abstracts away the details appropriately and shows the big picture essentials appropriately, then the code's going to be easy to understand, I think I think that, or more more easy to understand, I suppose yeah, yeah because then you're not even like necessarily thinking about kind of bigger I think.
Speaker 2:I think that or more easy to understand I suppose, yeah, yeah, because then you're not even like necessarily thinking about kind of bigger picture stuff, like domain modeling or like. You know how closely does this match reality at some conceptual level? But you know, but like in terms of like the mechanics of the code and the developer being able to follow the path of logic, say when trying to debug something right. Path of logic, say when trying to debug something right. I think that, yeah, you know the public API of like, you know this individual, you know controller class, say in a Rails application, right, obviously there's a series of method calls. You know, if you look at the backtrace of like, you know when something blows up in your controller, you're getting hundreds and hundreds and hundreds of lines. You know of stuff that was called in the lifetime of that request and who knows what you might need to be looking at to debug something.
Speaker 2:So the quality of all that stuff does matter when you're actually consuming it and writing software against it. So I think that's where, when we were saying a minute ago that there are parts of code bases where it's. Maybe this is kind of a refining of the idea rather than a restatement, but there are parts of code bases where it is more critical to ensure that they're easier to understand. Or have you know again, using air quotes, you know higher quality code, um. But at the same time, as soon as somebody else is going to need to potentially be debugging your code and that could be you're writing a library, that could be you're working at a company that has a you know SaaS app, you know you're gonna, it's gonna need to be debugged at some point then the quality of all of it matters, right, because who knows where, when the stack is going to blow up.
Speaker 1:Yeah, and that brings up something really important. You don't, you don't know, um like you don't always know at the time that you write the code, how important that piece of code is 100 yeah, and so when, when you invest time in making a code, making a piece of code easy to understand, you're making a bet.
Speaker 1:You're making a bet that this time investment is going to yield a positive return because on average and that's the key thing is, on average, we're going to get a bigger payoff from these investments than what we spent in making the investments. And that's something that, like I, find people very often misunderstand. There's this, um, there's this like pathological obsession with efficiency and people want to never be wasteful. Um, but in being wasteful, you actually or in avoiding wastefulness, you actually end up being way more wasteful. Um, because if, if you look at it in this betting mindset, where I'm going to, I'm going to bet $1 a hundred times and I don't know to make the math easy 99 out of those 100 times I'm going to lose, but when I win that one time, I'm going to win $1,000. So I paid $100 to win $1,000. So, even though I've lost 99% of the bets, I came out on top still.
Speaker 1:I think that's the mindset people should have when they're making those investments, because the other way of looking at it is like, well, I don't ever want to take any risk, so I will never make investments in improving the understandability of the piece of code. Then you are guaranteed to win zero and so you never come out ahead that way. So people need to be comfortable with being wrong, because you're going to be wrong some percentage of the time, unavoidably. But as long as you're right a high enough percentage of the time and you're right in the right way, then your total average payoff is going to be positive.
Speaker 2:So in this analogy, I just want to make sure I'm understanding where you're going with this. So the bet, so placing the $1 bet, is what? So it's like spending time trying to improve the semantics of a piece of code, or trying to make a piece of code higher quality, and the payoff is, I mean, I suppose if you're working at a company you could literally be saving money and time fixing a bug is. Is that that what you're, what you're trying to get at?
Speaker 1:yeah, yeah, like to make it a little bit more concrete. Um, if I never do any refactoring and I just keep whatever my first draft is, um, those, those pieces of code, in their imperfections, are going to kind of compound and ossify. And then, a year later, now that these things are buried under the weight of a bunch of other additions, when somebody comes across a piece of code that's really hard to understand, it's going to cost them so much more to gain that understanding that they need in order to be able to work with that piece of code, to gain that understanding that they need in order to be able to work with that piece of code. And so it's. I don't know. You could look at it, I guess, either as like a positive return or just the avoidance of loss. I think, realistically it's like more of the avoidance of loss than a positive return.
Speaker 2:I mean somebody you know.
Speaker 2:You might say that they're equivalent, right either way, I suppose so yeah, yeah, um, yeah, I mean I suppose you know, coming from that pragmatic point of view, but I think also just kind of you know where I think we agree on kind of what we care about in terms of good code, which is, you know, it's usability and whether the thing works. I mean, you know, if you, if you write the code, and then nobody you know you write, let's say, you write, a class, you know there's one consumer of the class which you are the person to, you know make the change to that consumer, to you know, to use this new piece of code and then you know, doesn't break for a year and also nobody makes changes to it for a year, doesn't feel necessarily like a great use of time to go back to it and like refactor the hell out of it and change the names of everything, and you know it might not be. You know, especially when you're yeah, like if nobody's using it, then kind of, who cares if it's working right? Um, you know, and then it breaks a year later. Okay, well, maybe, well, maybe now's the right time. Now you've had a chance to look at it again, you're realizing that, oh, this, you know, this thing's more important than I thought Taking the time to do the refactoring, do the editing, might make sense at that point. Right, you know, we haven't talked about at all that, maybe is also important to some degree.
Speaker 2:Aesthetics is whether this is satisfying to you at some kind of like emotional level. Right, you know, it might be that there's. I think a lot of, especially professional developers would agree that enjoying reading code is part of, you know it, being good code, even if it's at some like satisfying intellectual level. Not necessarily that it's, like you know, poetic per se. But you know, I think there's some aspects of maybe the best code where there is an aesthetic aspect to it. Right, you know, I think you know the, you know terse but also easy to understand. You know, golfed, but not so much that it's, you know you know, impossible to know what's going on, right, yeah, efficiency is, you know, it's really important to people looking at it and realizing, oh, this is such efficient code and yet I can still understand it. You know, I think there's a lot of that as well. That's easy to gloss over, you.
Speaker 2:But from a purely business standpoint, right, because we're, you know we're both in the software business. You know, I think we, we've probably both coded for fun as well, but it's, you know, it's our livelihood, you know, and so we're working at places where you know if we're going to be spending time editing code, um, you know. Hopefully you're at a workplace that gives you some leeway to just do projects that are interesting to you, at least from time to time. But most of the time people really care about whether the time you're spending on making changes to this application is going to make the company money. That's important. That's why you're being paid. So I think the other non-aesthetic aspects have to come first. I'm not so sure.
Speaker 1:Unaesthetic aspects have to come first. But I mean, you know, I'm not so sure.
Speaker 2:Well, look, they probably have to come first to the person who's paying you.
Speaker 1:at the very least, I'm also not so sure Whether that's what gets you up in the morning is oh, that's interesting. Yeah, so I have some controversial opinions. In general, people underestimate, or I'll say they overestimate, between the split of like um parts of life that are rational and parts of life that are emotional. Um, they, they overestimate how much is rational? Um, like, almost everything we do is for emotional reasons we agree with that, completely agree, yeah, 100 yeah, it's like why do you buy like a nice car instead of a really crappy car?
Speaker 1:like a crappy car would still get you where you need to go? Um, but you buy a nice car instead of a crappy car? Uh, for what we could call emotional reasons or psychological reasons or whatever. Our brains are hardwired to want to have status and stuff like that, and so we buy a car that we think is appropriate for our status because we don't want to be perceived as low status if we can afford not to, and like saving for retirement, for example. Like you would think it's like more rational to like save more money than less money. Um, but like these are all like subjective, emotional decisions. It's like should I take job a and move and make more money, or should I take job b and not have to move and make a little less money? What's the right decision? Well, it's like there's no right decision. It's just what do you want?
Speaker 2:it's a hundred percent emotional yeah, I think, uh, people are very good at making decisions for purely emotional reasons and then finding justifications to explain why they're actually logical. I'm good at that, that's you know. That's that's I. I'm I'm, you know, trying to become more aware of how that's true in my life, and I've been, you know, become more aware of that over time. You know, I think I'm somebody who has thought of myself as like, extremely logical, you know, logic first and, like you know, trying trying to, you know, have rational explanations for things you know primarily, but having to realize over time in my life it's like just how emotionally driven I am. You know what I mean.
Speaker 1:Yeah.
Speaker 2:You know that being a software developer is. I mean, you know it's certainly a financial decision as well, but it's primarily an emotional decision. It's something that felt so much easier for me to do at an enjoyment of life level than you know anything else I had tried leading up to that.
Speaker 1:So yeah 100%.
Speaker 2:Yeah, I'm on board with that idea.
Speaker 1:Yeah, and back to how it applies to business Like, for example, why does any business exist? Like, people start businesses for emotional reasons, not logical reasons. Like I recently decided to take my I don't know if you know, jared, but I have this product I've been working on on the side for a long time called Saturn CI. It's a continuous immigration platform. I decided a few weeks ago to make a go at making it a real startup. Oh cool, that's great. I didn't make that decision for rational reasons. It's 100% emotional. And then, like, in designing the UI and stuff like that, if you're Googling it right now, you won't find anything.
Speaker 2:But actually you might.
Speaker 1:You caught me opening the new tab yeah um, um, and like designing the ui and how the product's gonna work and stuff like that. That's all emotional too. Like it needs to meet certain certain functional requirements of course it needs to be able to run a test suite and stuff like that but like how that all happens is 100, um, and then back to like should um, aesthetics and code and stuff like that. Um, like I think it's wise, from a cold, hard calculated business perspective to give your employees aesthetic enjoyment and um, like we could have everybody work in like a fluorescent lit, windowless basement all day, every day, and that would work, um, or we could have them work in, you know, I'm sure you've seen these like crazy github offices and stuff like that, where it's just like insanely nice. Shopify visited their office. It was, it was nuts, um, gorgeous, um.
Speaker 1:So that's like the physical environment, but then like the mental environment like you're in this mental environment all day, every day, and shouldn't you want your employees to live in a pleasant mental environment? Uh, doesn't it stand to reason that they might be more productive if they live in a pleasant mental environment than in an unpleasant one?
Speaker 2:yeah, absolutely, yeah, no, yeah, I think you're right. I think I don't think for any given decision that I would say it. When it comes to code, right, and you know code decisions made at a company, I don't think that it's true to say that every single decision is purely motivated by profit. Certainly not in a descriptive sense. It absolutely isn't. You know software developers make you know all kinds of irrational. You know decisions based off of purely personal preference. You know constantly, all the time, probably in every pr? Um, at least in the naming of things. You know what I mean.
Speaker 2:It's not based on profit, but like yeah, yeah, I think there, there absolutely needs to be space to be making aesthetic decisions, to be, you know, to be able to try new technologies just because they're fun, not because you know the, the company's, company's bottom line demands it, or whatever. I think having a work environment that as a knowledge worker, it's fun to play in as part of doing the job is absolutely, I think, critical for our mental health. But perhaps, to counter it slightly, to counter your framing of it slightly, I think that and maybe it like there are a lot of tech companies that treat their engineers as pretty ponies and might treat other parts of the company not particularly well. I feel fortunate to be at a company now that that's not the case, but I've definitely been at companies before where the developers were given all kinds of free reign and then other aspects of the company company be it sales or support or whatever they're just, you know not necessarily treated very well. Um, you know. So I think it just goes for everybody. I would say that this should apply to everybody in every work environment.
Speaker 2:But it is in the company's best interests, I think, to provide that type of environment where you can make aesthetic choices, where you can try new things, where you can make aesthetic choices, where you can try new things, where you can have an intellectually stimulating environment, because then you can hire better people, you can retain people who actually are both good at their jobs from a purely profit-motivated standpoint, but also enjoy working there. I think that's just a good business decision. I've been fortunate to work at some companies that recognize that Huntress where we're both working now, I think, recognizes that pretty well. Uh, at least that's been my experience, you know. But uh, you know, I've definitely seen places that take that more and less seriously and you want to work longer at the places that let you do stuff that's fun, you know.
Speaker 2:At the same time, there needs to be there need to be guardrails around that. Um, partly so you don't shoot yourself in the foot and make your own life more difficult. I've been at companies where somebody gets excited about some new programming language, say Elixir, which is for Rubyists who want to try something different, want to try something functional. They often reach for Elixir right, and so I've been at a Ruby shop. There were folks who wanted to try Elixir and they you know a new elixir app to build some new feature. Um, it was fun to try it, but now they have to maintain that other thing yeah, and that's that's expensive, that's that ends up being painful because it like isn't being updated on the regular.
Speaker 2:It's you know, so like I think there there are guardrails that have to be in there as well, right, well yeah, yeah.
Speaker 1:So I completely agree with everything you've said, um, um, except maybe a small part. Um, you know, I don't think art is mainly about and I'm not saying that, you're saying this but I don't think art is mainly about freedom and fun. It's a lot of art is about constraint and discipline. Yeah, um, like I don't know um. If you think of like. So, like modern art, post-modern art, it's garbage um, but like classical art, um, you know, like a michelangelo sculptor, if I'm getting getting that right, he was a sculptor.
Speaker 1:Among other things, yeah, yeah, like he would make human figures and you can't just go willy-nilly. It's not like a Jackson Pollock painting, where you're just flinging bits of paint at a canvas. There's great constraints and like maybe a better example is like architecture, um, like, we've all seen these crazy ass buildings like. Uh well, when I, when I was in toronto, you know they have some some architecture.
Speaker 1:we don't really have this so much in the us, where you know these buildings that are like twisted and stuff like that, which I think are kind of neat looking but, like, if you go to like europe, like the buildings in paris, for example, um, they're very elegant in a way that these modern glass and steel skyscrapers are not, and they can't just uh, go crazy experimental with these buildings. Um, because you know, there are buildings that are like experimental and it seems like the architect was just like having fun and those aren't like very, uh, artistically high quality buildings. It's the more restrained, traditional, reigned in buildings that are of higher artistic quality, I think.
Speaker 2:Well, I mean well, in your opinion anyway. I suppose. I mean the Jackson Pollock example is an interesting one. I mean I would say, and I've never done art history right, I mean, I think that's. I mean, perhaps he set himself the constraints to, hey, what you know, can I make interesting art by just putting the canvas on the ground and gripping in patterns? I mean, maybe that's a you know. But to the point, to the point about constraints, I do completely agree with that. I think that you know, operating under constraints is, you know, I would certainly see it as an important part of a creative process, right? I think you know it's like the whole blank page syndrome thing, right? It's like when you don't even know what your starting point is, it's really hard to get anything done. But if you have like a you know, if, if you, if you set yourself some constraints or or know where you're starting from, um, you know, things get a whole lot easier yeah, yeah.
Speaker 1:I think maybe the point I want to make is like, in order to create great art, you need to a skilled, disciplined adult.
Speaker 2:Hmm, I get tripped up on the have to part. I think it's probably generally true though. Yeah, I mean I would tend to agree.
Speaker 1:Yeah, because, again, it's not about indulging yourself. I mean, maybe it's about indulging yourself to a degree, but it's like. I mean maybe there's a distinction between yourself to a degree, but it's like.
Speaker 2:I mean, maybe there's a distinction between like a single piece and wow we are really going off in a different direction here, I love it. Work and a satisfying body of work, or a sustained ability to create, uh, you know, uh, high quality artistic output over time. You know what I mean, I think. I think it's. I think I don't see any particular reason why somebody couldn't just as a one-off, like accidentally, put themselves into a position where they make a painting and somebody else looks at them like hey, that's amazing, I love it. You know, whether they can consistently do that on a regular basis as part of a creative process is is a different question entirely, I think sorry I I just had an example.
Speaker 1:an example of a self-indulgent artist is yoko ono and her music sucks for precisely for that reason she's just like going crazy and it's experimental and completely like self-indulgent. It doesn't have discipline to it.
Speaker 2:Now, to be. To be fair, I don't know if I don't know if anybody would describe her primarily as a as a musician. I think maybe she's more a visual artist and a performance artist.
Speaker 1:Yeah, and I don't know anything about her visual or performance art. I'm just talking strictly about her music. So in the realm of music I find her music to be self-indulgent.
Speaker 2:What very little.
Speaker 1:I've heard of it, like there was this famous occasion where John Lennon and Chuck Berry were playing together and Yoko was on stage also and they were playing like some nice rock song together. Um, and then at one point, yoko just let out this horrible scream and just sustained it for like a really long time and it's like that's just self-indulgent, that's not high-quality art, anyway. Yeah, so I think indulgence can be part of the. Well, it's not art you'd want to pay money for, anyway. What's that?
Speaker 2:It's not art you'd want to pay money for anyway, or me for that matter, but yeah.
Speaker 1:Yeah. So I think you can be indulgent, but you have to then rein yourself back in and be like, okay, now that I've, now that I've let my sillies out, or whatever, let's get serious and maybe there's some um, some value that got created in that indulgent process. But we can't just give out the, the unfiltered, uh, indulgence. We have to refine it, refine it into something. And that brings me to another. I was talking about wastefulness. Creating great art requires waste, like I think it's maybe mostly waste, like music again.
Speaker 1:Like I think, think, speaking for myself personally, like the vast majority of songs I've written, like never got kept. Like for every thousand parts of a song I've tried to write, I've kept like one um, so it's mostly waste. But if I tried to be like efficient with songwriting and I'm like, all right, 100% of the parts I write I'm going to keep, I'm not going to be wasteful and be irresponsible Like that would be terrible. The music would be worthless.
Speaker 2:But good Lord, I'm sure even the most prolific musicians and you know music producers who are doing it as their job and are, you know, putting a new song on the radio every week. I mean they probably have five, ten more times that and stuff that they just threw away. I think they get faster, faster at iterating, probably.
Speaker 1:You know what I mean faster at churning stuff out, yeah, and to see what is good for every album that comes out, there are, like several recorded polished songs that the artists choose not to include on the album because they're not good enough. Um, I mean surely not in every case, but like a bazillion.
Speaker 1:There's so many examples of albums that have like b-sides they don't get released until some like rare compilation later or something like that oh yeah yeah, um, and so in software like, people are often pressured from within and from above to be efficient, and I think that is a false economy.
Speaker 2:Software is art, and in order to make good art, you need to be comfortable with being wasteful, because it's only by creating something bad that you can ultimately create something good yeah, yeah, I wonder what percentage of the lines of code you've ever written are still, you know, and I don't even mean like applications that are still around, but like are in the. You know the current version of the application. You know what I mean. It's probably all been. You know most of it has been deleted, either in the course of, like, the initial writing, right Like before you even submit the PR. You know you're writing all kinds of lines, deleting all those characters, replacing them something else, or just churned away, refactored away, I mean like, you know, like any any kind of, you know, organic or pseudo organic process. It's, it's, you know. Stuff gets created, stuff gets destroyed, you know yeah, yeah, people constant entropy, constant churn, you know that's just.
Speaker 2:That has to be seen as part of it absolutely I think people are too precious about code.
Speaker 1:Like imagine, like if every, if I was just like messing around on my guitar for a few hours and like it was recorded and encoded and saved in like a git repo or something like that. Um, like, maybe I'd be more inclined to like get attached to those notes and want to keep things. But since it's just like ephemeral sound that's in the air momentarily and then goes away, like we don't have that attachment. So maybe it's something to do with the fact that we commit the code to these files. We're like well, I took the time to to write this. It'd be a waste to like throw it out now. But I think code should be thought of more like sound waves in the air.
Speaker 2:Um, where it's, we should think of it as being cheap and we should delete it eagerly I mean just much cheaper to you know, delete your your initial first ideas that you made, you know, before you had a chance to think things through, than it is to keep it around and have it, you know, be buggy and hard to understand. And yeah, absolutely, I mean, I think you know. That's why people talk so much about prototyping as an exercise, with the distinction that a prototype is something that is made to be thrown away. Right, it's not something that's made to be shipped to production. It's intentionally made so that you are able to get those ideas out of your system, figure out what works, what doesn't, at like a very basic level, and then intend to trash it and in fact, force yourself to trash it, even if you like it, and start from scratch, but not intellectually start from scratch, just start from scratch in terms of the actual code that you're you're committing.
Speaker 1:Yeah.
Speaker 2:I think that's. That's. Yeah, I agree with that. There's another. I want to go back for a second Cause.
Speaker 2:We we had kind of two, two, kind of two or three key bits to this initial question of, like, what makes good code, and we talked a lot about kind of the, the second or the second and third parts about the. You know it's, it's easy to understand and easy to work with. What about the it works part? So you know how, how important is that to something being good code per se? And and the reason why I ask this is thinking about real in the world software.
Speaker 2:You know projects, uh, whether they be you know sas, sas application, or you know an app on, whether they be you know a SaaS application, or you know an app on somebody's phone or an open source library. Every one of them has bugs constantly. You know, might have, you know hundreds of bugs you know at any given time. Maybe you found them, maybe you haven't. You know, maybe it's you know alerting you in production. You know 10 times a day and you just haven't gotten around to it yet. When we're saying it's important for software to work in order for the code to be good, what are we saying there?
Speaker 1:Like how I said, it's like table stakes for it to work, like that part just is yeah, I mean I think yeah, yeah, where you know, but you know it's non-negotiable.
Speaker 2:But you know a part of you know I think yeah, not, yeah, exactly, you know, but it is a part of good software. Good code is code that works. I assume you know. I assume you wouldn't, you know, say that you know if a function, if you write a function and it's very aesthetically pleasing to look at, but it actually omits returning the value that's expected, maybe it is aesthetically pleasing but not good code, how do you think about that, either for an individual method or for an entire software project? How, what's, what's the relationship between good code and code that works?
Speaker 1:well, let me answer that in the most circuitous possible way, since we're here to open up uh philosophical cans of worms. What does it mean for a piece of software to work? Um, because, like you, okay, think about gas stations, like gas station pumps, the pump near my house that I always go to. Now, it works pretty well and I don't know if, like, things have just gotten better or I'm only getting this one sample now, but, like, like I've experienced so many infuriating uh gas pumps like their, their ui is so bad um you know you're a software developer when you're complaining about the ui of a gas pump.
Speaker 2:I completely I don't. I don't own a car, but I rent a car enough to have had experiences with with gas pump ui, and boy I could not. There's one step, one step. At this one gas station I go to in Canada where, in order to pump the gas, it first asks you if you have a loyalty card, but there's no ability to tap or to scan the loyalty card. It forces you to enter the 10 digits of your loyalty card number. Who the hell knows the 10 digits?
Speaker 1:of their loyalty card number.
Speaker 2:Now you're pulling that out and staring at it while you're pressing it on the pin pad. What do they actually expect from you there? So yeah, I completely agree.
Speaker 1:Yeah, and the reason I bring that up, even though it's probably not the best example. Another quick example is doors. Like a door is such a simple mechanism, but the usability of doors varies so greatly like there's some doors that look like pull doors but they're actually push doors and the other way around. Um, there are you know round knobs are like. I think it's actually illegal in the us for knobs to be round in public places, because if you don't have hands then you can't use them like if you have like a a stumpy arm or something.
Speaker 1:You can't open a door with a knob. You have to have like a lever, um, um, and so doors vary quite a bit and it's like does this door work? Um, well, uh, just just take this like push door that looks like a pull door example. It's like, yeah, the door works but, not all the way, because it, like uh, doesn't serve the purpose nearly as well as it could.
Speaker 2:Who does it work for and under what circumstances?
Speaker 1:Yeah, exactly.
Speaker 2:Could be the same, easily the same for software.
Speaker 1:And there's software with like, oh man, all right, so I'm building the CI product, largely because I hate and hate is like not a strong enough word GitHub, actions and CircleCI, because, like in CircleCI, for example, when a test fails, the first thing I want to know, of course, is what failed. But I have to like dig to find the failure. It's like CircleCI. Hey, you know that, out of all the steps in the workflow or whatever, you know that only one failed Um, and you know which, like worker or whatever failed. So like, why not just take me straight to the place that you already have all the information you need, uh, to know what I want to see. Why not show me that? But it doesn't. And so it's like does it work? It's like um, and so it's like does it work? It's like, does it meet its functional requirements? I guess it does, if that's how they designed it to work. But the design sucks. So do you include the design in the question of whether the software works or not?
Speaker 2:I mean yes. I want to say I mean design.
Speaker 2:Design is a few different meanings, I suppose, you know. I, I think a good application or a good product, yeah, 100, you know that, with a visual design, the product design, more generally, thinking about you, what you want the thing to even do and for whom, you know, I think those are all parts of a high quality application, I think you know. When it comes to the question of high quality code, right, I think, then, well, let's dig into it a little bit. Yeah, you know what do we mean by design in this case, right, you know, I think that the you know the software industry, at least our corner of it, you know, has I haven't worked at like really big kind of you know Fortune 500 companies. I worked at Shopify for a while, you know, but that's, you know, maintained a lot of kind of. You know it's a, you know it's a Ruby on rails shop, you know it's. It's, you know, founded by somebody very much in the open source community. So that has a. You know it puts a certain angle on things, you know so.
Speaker 2:But point being that, you know, my experience has been in places that aren't really in favor of a lot of upfront design.
Speaker 2:You know what I mean you know that kind of like traditional waterfall, you know process where you figure out the requirements and then you know hand them down the chain until you know software is plucked at the bottom, you know. So presumably we're not talking about heavy handed, upfront design. So I mean I don't know what does it mean for software to be well designed? I think it's a process over time of you know making guesses, making bets, like you were saying earlier, having them be confronted with reality and then trying to have a thing that is you know, more and more, you know, I would say, useful in the context of an actual working thing in the world and is, you know, maintaining those qualities of being understandable and easy to change yeah you know, and that that is a design activity that is, you know, never ending, that has aspects of upfront design, of you know conversations between you know a software developer and a product owner and a you know UX designer and whoever else to make initial decisions.
Speaker 2:You know, but clearly you're not just doing it once and then never touching it again.
Speaker 1:Yeah, so yeah, and again, so much of this stuff is emotional and subjective, um, so much more than people realize. Um, by the way, I I also want to say because, like code quality, product design quality, I came to the opinion recently that code quality can never exceed the quality of the UI, because the code has to be a reflection of the UI and if the UI is conceptually corrupt, then the code is going to be conceptually corrupt also.
Speaker 2:Conceptually corrupt UI. Yeah, okay, do you have an example?
Speaker 1:No, I wish I did, I don't necessarily mean a real world.
Speaker 2:like a contrived example is fine, I'm just trying to.
Speaker 1:Yeah, I don't know. Well, if somehow a door had to have code and it's a push door that looked like a pull door, the code would have to reflect how the door works, and so the code would be bad, like if if the product models the world in a way that doesn't make sense, then the code's gonna have to match.
Speaker 2:I mean, I think, yeah, that's that's that's interesting, it's what it's hard to think about in the abstract. So I mean I think that, so, like you know what, if you had some like really tidily written code oh, I'm sorry, I have an example, well-factored, yeah, yeah, please.
Speaker 1:In WordPress, everything is a post, so a post is a post. If you have an e-commerce system in WordPress, each one of your products is a post, like every pluginin, like every entity is a post. It's stupid, um and like because the product design is conceptually corrupt. You know, not everything is actually a post, um, the wordpress code has to be conceptually corrupt also. The WordPress code has to be conceptually corrupt also, and so does the code for every plugin ever written, pretty much.
Speaker 2:Okay, but hold on a second. Are you telling me that every single? You know every single? Okay, hold on. Now. My philosophy logic brain is trying to think about the order of these dependencies here. So WordPress code base has baked in some poor assumptions. Look, I haven't worked in WordPress in a long time. I certainly remember it being pretty messy to work with. That was a while ago. Don't add me WordPress people, but certainly not every um. But uh, you know, certainly not every website that's made in wordpress has like bad ui or is like hard to use, but I don't think, logically speaking, that that has to be the case from what you were saying.
Speaker 1:So no, I just don't worry about it. Wordpress itself, because the wordpress product was designed in such a way that never went back and reconciled the, the conceptual model of oh, I see what you mean yeah, um, they. They just. I mean this is maybe unfair to say, but they were just lazy and said even those of these things aren't posts. We already have this concept of a post and it kind of works, so let's just let everything from now on just be opposed.
Speaker 2:Yeah, yeah yeah, even after wordpress just kind of became a default for you know many non-blog uh use cases. Yeah, yeah, I see, I see what you mean. I mean, well, you know the wordpress example is a funny example because you know it is famously a blogging platform and I think the fact that it's turned into so many you know thousands and thousands of other things uh, you know, maybe doesn't take away from the fact that it's turned into so many you know thousands and thousands of other things. You know, maybe doesn't take away from the fact that primarily that is what it is written for and that's what the domain modeling is around, and anything else is just well, you're building on top of a blogging platform. So what do you expect? Used anything platform in the world?
Speaker 2:You know somebody could have taken that under consideration from a software architecture, system design. You know perspective earlier and you know, change the domain models to reflect the. You know it's an everything platform now, but I don't know if I necessarily agree with that. I mean, you know, maybe that's the whole constraints thing again. Right, it's like, hey, what is wordpress if not a blogging platform? And you know, if you want to do anything else with it, then you just have to, I'm not sure you're appreciating how deeply stupid this whole thing is.
Speaker 2:I I like I said I've, the last time I worked in wordpress was like literally at the beginning of my development career. So it's uh, it's been. It's been quite a while now yeah, it's like everything is a post and like the details come out and when you say everything, you mean like, when you say like a plugin is a post, like, literally it is an instance of the post.
Speaker 1:Like the entities of plugins, Like yeah, like there's a database table called posts.
Speaker 2:And if it's a customer, it's a post and if it's a customer, it's a post.
Speaker 1:If it's a product, it's a post.
Speaker 2:Wait, it's an entry in the posts table. Oh no, okay, no, no, no.
Speaker 1:Okay, yeah.
Speaker 2:Yikes. No, I did not appreciate that nuance. I don't like it.
Speaker 1:Yeah, yeah, yeah.
Speaker 1:And again, because they designed the WordPress product that way. Now all the code has to suffer. And I worked on a system before where it was like we had something that was like conceptualized kind of weird in the UI and like the code could never escape the UI because it had to serve the UI and like, in theory, maybe we could have like named things different and had like a mapping or something, but that would just be like even more confusing. So again, the code is subordinate to the UI and so like as a programmer, if you can't influence the UI, then it's just like left up to chance and you can't, no matter how good of a programmer you are, you, your quality of are not very good and, quite frankly, most UI designs in the world are not very good and I think that's a big part of the reason why most code in the world is not very good.
Speaker 2:Well, yeah, and also if you don't have a good working relationship with the UX design folks, you know in your organization or with your team, I think you know in a healthy, in a team that's functioning well, you know things aren't just designs, aren't just being handed off right, like you know there is a back and forth collaboration, you know where you know you're kind of respecting each other as you know the experts in you know the design domain or in the software domain and you respect each other as the experts in the design domain or in the software domain and you respect each other's opinions.
Speaker 2:But where there is kind of a healthy amount of pushback of saying it's like oh well, that's interesting kind of visual design you have there, that is gonna be a nightmare to do in whatever language we're using, whatever framework we're using, so can we change it to be, or even just a conceptual software design level. You know there are UIs that are more or less terrible to implement or that can lead to serious problems with, like maintaining them right, like that's absolutely true. So you know, having that kind of relationship where you can have those conversations and there is not just an expectation that a UX designer is handing off a design that you then need to implement.
Speaker 2:you know, is essential to having code that isn't trash.
Speaker 1:Programmers, unfortunately, are usually so undereducated in the area of design Like it would be great, I think, if programmers could have direct and I realize this happens sometimes if programmers could have direct contact with the end users and have the skills to be able to use that contact to create good designs use that contact to create good designs.
Speaker 2:Yeah, it's interesting because that's usually like part of the like UX designers or like product owners kind of domain there. You know, it's kind of considered standard now for, you know, folks in the design and kind of product kind of roles to be having those conversations with actual customers, to be having those conversations with actual customers, and very often the developers are kept out of those, either because the business has decided to not include them or, very often, because software developers just don't wanna have those conversations, which I think is sometimes, maybe very often, leads to kind of worse software choices because folks aren't thinking about what an actual user wants, because they have never talked to an actual user. You know it's interesting. I'm actually today is actually my first day changing teams from a external product focus team to an internal developer experience team, so I'm now going to be in the position where my users are primarily the developers within the company, which is, you know, both kind of amazing in the sense that not only will it be easy to seek them out, but they will be seeking me out constantly because we are on the same slack, but at the same time quite daunting because you go from being a software developer whose users are I mean because we work at a kind of a cybersecurity company.
Speaker 2:A lot of our users are more technical, but you know, typically your end user at a software company is not as technical as you are and therefore there's a mystique around your role as a software developer.
Speaker 2:They don't quite know what it is that you're doing, but it's something very powerful, very mystical, right. I'm now going to a situation in which no people know exactly what I'm doing and quite a lot of them are probably better at it than I am and so the expectations of the customer are going to be very high in very specific ways, related to code quality even. But to your point, I think you're right that software developers especially tend to be pretty isolated from the end users, and my experience has been that that can lead to bad software design choices or API design choices. Say, for example, a backend-focused engineer is creating a REST API to be consumed by a single page frontend application and that backend engineer has no idea how JavaScript works, how HTML works, what it is like to create a UI. They're going to make some weird choices in how to structure that API that can make it a lot more difficult to use.
Speaker 2:I've definitely had that experience before. Very painful for both ends yeah, yeah.
Speaker 1:And it's surprising that it's not like standard practice by now, but like the only way to know if a designer, a design, is good or not is by testing it. But most designs never get tested. I mean, they do get tested in the sense that they get put into production.
Speaker 2:And people complain or don't complain.
Speaker 1:Yeah, and usually people aren't going to complain because you know I don't go knock on the gas station door and be like, hey, your gas pump UI sucks. I'm not going to go track down the engineering company and call them.
Speaker 2:If your expectation is that a UI is going to suck and even if you complain nobody's going to do anything about it, then why bother complaining? Except if it just makes you feel better in the moment, I suppose Right.
Speaker 1:And so, yeah, it's really. Not only is it not expensive to do in terms of time and effort and stuff, but it pays itself back many times over, because most flaws in software are flaws of design. Um, like, if you can just like, doing the right things in software is so much more important than making it do more things and you can do the right thing crappily, like, doing the right thing crappily is so much better than doing the wrong thing. Well, most software just does the wrong thing crappily. But yeah, it would be really nice if more developers were versed in UI design and talk to a customer and design a feature and stuff like that in a way that would be appropriate.
Speaker 2:No, I totally agree with that. Thinking about how the end user actually uses the thing, actually asking an end user how do they use the thing, I think you know, is, even if you don't have direct access to the customers of your company, trying to put yourself into their shoes, trying to have that empathy, you know. Empathy for users I think is really important. But also, like you know, I talked about the importance of the relationship between a developer and a, you know, a designer that you're working with. I think that's true between developers and sales as well. I think that's true between developers and other people on the team.
Speaker 2:The sales one's an interesting one, because I've definitely had the problem before where the developers on the team I was on didn't know exactly how the sales folks were explaining the product to the end users. You know, maybe certain things you know were being oversold, not maliciously, not, you know, not intentionally, but just misunderstandings, right, and what that ended up with was users who you know were complaining that it didn't do X, y and Z, but that, from the developer's perspective, we never said it was going to, we were never asked to. So having those relationships, healthy relationships with all the stakeholders, I think it's important to making good decisions, because if you knew that sales was going to expect this and it was critical for them to be able to actually sell the product, then you'd be making different decisions about what you're prioritized when making it right.
Speaker 1:Yeah, yeah, yeah, it would be great if we all had more of a big picture perspective of the whole thing.
Speaker 2:And sometimes you can go and do that without having to get anybody's permission.
Speaker 1:Sadly, we do have to wrap up. We only scratched the surface of a lot of things that I would love to get deeper into, especially what you said about the snapshot of the code base and how it evolves over time and stuff like that. Because I think that's really significant, but we'll have to save that for another day. Um, but before we go, jared any anywhere that you want to send people online, anything you want to plug or anything like that.
Speaker 2:Uh, no, not really. I mean, you know, uh, jaredgallingerca I guess he has a wildly outdated website, uh, but yeah, I work at Huntress, which is an amazing cybersecurity company, so if you're in the market for EDR or other protection, go hit us up. But yeah, no, that's about it.
Speaker 1:Yeah, and, by the way, I've gotten more than zero people hired at Huntress, and so if you're looking for a job, or even if you just think you might want a job someday, talk to me and I can maybe put you in touch with the right people, because I'm always happy to do that just for karma. I believe that those things come back around. So, in general, anybody who's looking for a job or looking to hire people, I'm always happy to talk to those people. Anyway, jared, it's been a lot of fun. I really enjoyed this conversation and thanks for coming on the show.
Speaker 2:Yeah, likewise Thanks, Jason. Appreciate it.
Speaker 1:Thank you.