MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about frustration management. And you might think, well, what does that have to do with code? [laughs] And I'm going to say that it has almost everything to do with code. Software development is largely an exercise in frustration management. And that, I think, is genuinely fundamental to what we do as software developers. 


We solve problems, and we have to deal with our inner self, you know, with that inner voice as much as we are dealing with anything else because, you know, that's the tool that we have. We have our minds. And if we're not in control of our emotions and our minds, then we're not going to get much done. I feel like frustration management is genuinely central to being able to be effective as a software developer. 


I wanted to start with a story. As we were preparing for this, I wanted to share something that was genuinely frustrating for me. A number of years ago, I was tasked with working on a project. Specifically, there was communication. There was messaging not working between two systems. And the library we were using to message between the two systems had a few interesting attributes. [laughs]


First of all, it was designed to run in a separate thread, so it kind of ran in the background. It actually did not only run just one thread, but it ran a pool of threads, which meant that there were several different parallel threads of execution running, so it was concurrent. There were several things going on at the same time. 


Secondly, it was distributed because there was more than one system. There was more than one system that was involved that we were listening to. And you could actually have multiple different processes listening or multiple threads. So you had concurrency at both ends, and it was distributed.


And third, it was asynchronous. These messages were sent over a message queue. They arrived kind of when they arrived. So there was no guaranteed delivery time. So it was concurrent, distributed, and asynchronous. And if you've ever tried logging something that is across multiple systems, [laughs] that has multiple threads going at the same time, you may find that it's quite challenging. It is remarkably difficult to find out what is going on there. 


And, further, the system that I was testing had unit tests that didn't work. They were written for a different messaging system, and they just didn't work with the one we were using. So the tests I had didn't work. The messaging layer was sometimes a little unreliable. The code I was working crashed randomly, and I didn't know why. And all of the kind of standard tools for debugging or logging were somewhat ineffective because you couldn't really figure out what you were latching on to. 


Also, I didn't know it at the time, but the library that we were using had several critical bugs in it. [laughs] I thought that I was solving messaging, but I was actually solving a bunch of problems at once. And I came in excited. I was recently working at this company. And I wanted to kind of show that I knew what I was doing, spent a day working on this problem and got nowhere, and felt really deflated at the end of the day. Tomorrow will be better. 


And the next day, the same thing happened. [laughs] I spent all day working on it and got nowhere. And I thought, well, tomorrow I'll get this. And that happened for almost a month. Every day, I tried a new thing. And every day, I left defeated and had to come back and push on it some more. And what I did was I just tried lots of different things. Every day, I would try something new or maybe adding different logging. And, over time, it was imperceptible. It was imperceptible. But I started to see where the problems were. 


Eventually, I found one bug in our library and got that fixed from the library creator. A while later, I found a bug in our code, and the way it was using the library was causing multiple threads to be spawned, and that wasn't good. That got fixed and made it a little bit better. A little further, I found another bug in the library and solved it. I still hadn't solved the problem. The messaging still wasn't working. But by pushing at it, those incremental changes actually got me a little bit closer.


Finally, I decided to redo the way some of the unit tests were running, and I got through the unit tests and got those working, which allowed me to progress. After about a month, I finally got all of the problems solved. And it worked. That library went on to work, essentially without thinking about it for years because I'd taken the time. It was a very painful month. [laughs] That's probably the most challenging project I've ever worked on because it's just so inscrutable. But I got through it, and it was worth it in the end. 


I share that story because, hopefully, [laughs] it reveals some of what's going on, and it's just kind of some personal confession here. But yeah, sometimes things are hard. I talk to my kids when they're working on things. They get frustrated. And I tell them that there are three things that they should do. There's three specific skills that I teach them that they should use when they get frustrated because frustration happens. Helping them with school, helping with their schoolwork, they're going to get frustrated sometimes. 


So I tell them three things to do. These are things that I give to my children, but I think that they're very applicable to adults as well. And the three things I tell them that they can do, and I'll ask them, say, "You know, you're feeling frustrated. What can you do?" And then they'll pause for a second, and they'll give me ideas, and they'll choose one. 


First, they can stop and breathe deeply, close their eyes, and breathe deeply. You may refer to this as meditation. It is the process of stopping, calming down, just listening to your breathing. It may sound like a little thing, but it makes a dramatic difference. It makes a surprising amount of difference in your mental state. Separate yourself from the work and just focus on your breathing.


The second thing I suggest to them is exercise. Step away from here, [laughs] your work, and exercise for a minute or two. Some people go for a walk. My kids will often do jumping jacks or run up and down the stairs a few times. And getting blood to your brain has lots of evidence behind it, as giving you some added oxygen and probably glucose. It sends your brain the things that it needs to kind of freshen up and be more clear. 


And the third thing I tell them is go do something different. If you're really frustrated on something and you hit your head on the wall, go try something different. I find those things are very helpful. 


I've got a number of other ideas as well. I wanted to lead with these ideas, though, because I think that it's really helpful to have something to start with. So, what are your thoughts about this idea of frustration management? And did those suggestions resonate with you? Or do you have other ideas that really work for you?


MATT: I feel like stepping away is key because we face these frustrations every day and repeating the same thing over and over with the same result they call insanity, right? So I feel like stepping away is one of the most important things that someone can do. It helps you gain a little bit of clarity. And you never know when those aha moments are going to come. But I have found that stepping away, thinking about something else brings those aha moments, personally.


MIKE: But it's sometimes hard to step away, isn't it?


MATT: Oh, absolutely. Because you don't want to feel defeated.


KYLE: I've got several different levels of stepping away. I'll get up, and it's maybe just a change of scenery for a second. And you stare out the window. And it's got to be some type of movement for me, at least. Even doing that for a couple of minutes and then coming back will relieve some of the frustration and help me think better or going on a walk. 


Even changing a scenery, you know, in the sense of changing the environment where you're pairing with somebody that seems to help too. The other thing is just stepping away in the sense of working on something else for 30 minutes to an hour or so just to kind of do a mind dump and then go back and see if you can figure it out from there.


EDDY: I was just going to add to Matt's aha moment. Like, I live for those moments personally, and that's what makes, like, super, really fulfilling. [laughs] It's great when you can get unstuck. But talking about what Kyle just said, I think change of scenery is super key, whether that's, like, walking your dogs. Like, that's what I do sometimes. Like, I'll take a 15, walk my dogs, and I'll play with them, play catch. And then, when I come back to the computer, and I look at something, I'm like, well, duh, that was the problem. But it's really hard to see that, you know, when you're tunnel-visioned, so, like, getting a fresh view coming back really does help.


MATT: I think that's a great point. Another thing is a different perspective helps me often, if possible, right? If you can reach out to one of your peers and get a different set of eyes on a problem, I find that extremely helpful. But I love paired programming so much because then you don't face that tunnel vision that we sometimes have a tendency to get stuck in.


MIKE: So you mentioned pair programming. I came thinking about that as well. You said that another pair of eyes can sometimes help you be less frustrated?


MATT: Absolutely. As engineers, we sometimes get into habits and form patterns of how we solve our problems, and they don't always work. But having another person there to talk it through with and give a different perspective can be so enlightening.


MIKE: And sometimes people feel like if somebody else is looking at them, they're going to feel bad about themselves and feel more frustrated. So, why do you think, Matt, you said this other perspective is helpful? What do you think is so relevant about pairing that will make it better, even though there's some possibility of social stress there?


MATT: Absolutely, there's social stress. But I think that the more we practice it, the less that becomes a problem. At some level, I think we all have some insecurities and don't like to be judged. But if we can get beyond that feeling of judgment and get to a point of openness, the level that it can help you and the rate at which you will succeed becomes so much greater. But that is, as you say, that's another level of frustration that we have to overcome initially, I think. And sometimes that is hard.


DAVID: This is a kind of beautiful series of thoughts that are stringing together here for me that, as I was thinking about the podcast topic, I actually came to the call ready to say, "Oh, my secret technique is get therapy." And I laughed at myself. And then I thought, actually, that's kind of a serious idea. If anybody here has ever been to therapy, your therapist will do two things: They will either help you increase your capacity to deal with what you are doing, or they will teach you situational tactics to deal with the specific stresses you are facing right now. 


And what are we talking about here, right? Get up. Go take a walk. Get some exercise. Get some oxygen. Increase your capacity to handle what's in front of you. And then situational tactics, right? Find a way to disconnect yourself from the stress. Take a break. Walk away. Talk to someone else. Find some psychological safety. This is blowing my mind. It's fantastic.


MIKE: There's a recurring theme in lots of conversations we've had here in the podcast that a lot of success in software development is not necessarily about technical skills. A lot of it has to do with your team and their willingness to grant you the psychological safety you just mentioned. It's easy to think, well, yeah, I'm really good at coding. That's not necessarily [laughs] the defining characteristic that's going to lead to success. But rather, it's going to be that collaboration with your team, the ability to have psychological safety, and let people feel safe when they come to you with a question, and they're stuck because we all get stuck.


MATT: That's a really good point. I think one of the things over the course of my career that has leveled me up more than anything is working on my communication skills and learning how to listen and not talk over people. That's one of the things that I really work on and sometimes still struggle with. But just working on that problem with myself has helped communication immensely. 


And when you are able to communicate with your team, and your peers, business, and your customers, I think you level up really quickly. And, ultimately, I think that's all of our goal, right? Is just continue to level up in our career and our personal life and become better.


KYLE: I was thinking as we were talking through this that half the time when I'm pairing with somebody or reaching out to somebody, it's more of just a teaching experience, I guess, to some extent. And that's where I've found a lot of the success in pairing and figuring out a problem. And so that, like, reaching out to a team member that maybe has no idea about the topic, and part of the way through explaining that, I'll be like, "Oh, this is a solution, right?" 


And even so much as in, like, I'll be frustrated and go and try and explain it to my wife where she's not as technically savvy. So I have to put it in more layman's terms. And just the process of putting it in layman's terms, you either solve the problem, or it becomes more apparent to you what the issue might be.


MIKE: That process of explaining is amazing, isn't it? [laughs] It reveals all of the...maybe not all of them, but it has a tendency to reveal all the cracks in your thinking, all the gaps that you hadn't filled in, the dots you hadn't connected. It is a remarkable tool. And some people will keep a rubber duck or whatever other toy they choose on their desk to talk to if they don't have somebody to talk to, just so they can explain to somebody. That idea of explaining is so useful. 


What other things do you all try to deal with your frustration?


KYLE: I'll just throw out music therapy. I've got different levels of different genres of music that I will go through as my frustration builds. Sometimes that tends to help as well. 


DAVID: Ooh, riffing off of that, somebody taught me a technique in middle school that blew my mind, specifically how to use music therapy. Like, if you're in an awful mood and you're just like, well, I've got this library full of...this playlist full of, you know, thousands of songs, how do I fix my mood with music? And he told me the secret. He said, "Go find something in your playlist that matches your current mood and play that, and sync up to it. And then start moving towards music that represents the mood you want to be in."


And it was that idea of, like, find the music that matches you right now that was, like, the aha moment for me because, like, if you're furious, then, you know, some calm classical is...you're going to spit it out. You're just, like, get away from me with this. So I have a lot of playlists that start with, like, Rammstein and go towards Mormon Tabernacle Choir by the end of it. And it's a pretty eclectic playlist but profoundly useful.


MIKE: It's interesting that music is mentioned. It's another change of environment. The change of environment just keeps on coming up as well. [laughs] Change what's around you. And music is one very active way to change that environment, much like stepping outside would be. 


DAVID: The nice thing about Utah is we are about 20% relative humidity right now, which means we can walk out when it's 20 below, and you can be in a T-shirt. And you can make it pretty much to the end of the block and back before, you know, serious complications set in. A lot of my friends that are out in, like, you know, Illinois and, you know, Ohio where it's, you know, 90% humidity all the time, they're, like, "You stepped out onto your porch without a coat on? What's wrong with you?"


MIKE: We've talked about this change of environment and literally changing your surroundings or what you're listening to. One thing that I find very useful is more figuratively stepping back. When I've been figuratively banging my head against the code for a while, one thing that I find works tremendously for me is to take a figurative step back, maybe a literal one, you know, step back from the laptop. But, figuratively, to start, in my mind, looking at the bigger picture.


One thing I find is that when I'm very frustrated, it's usually because I'm running into something that doesn't make sense to me. And if something doesn't make sense, it's often because I'm missing the broader context. I'm looking at something too closely, so I don't see what external to that little piece I'm looking at might be relevant. I find that when I'm stuck when I'm in some sort of hole that I can't get out of, what I need to do is kind of step out of the hole, right? And look at the bigger picture. 


Well, maybe this doesn't make sense because I'm thinking about the problem wrong. And when I go and look at the surrounding code, look at the...re-evaluate, challenge my assumptions, it can make a tremendous difference. And maybe sometimes the change in the literal environment is conducive to that because you're looking at something different. 


When that's not an option, and even if it is an option, a lot of times, I find it very useful to take that alternative approach, think, well, this doesn't make sense, which means I'm probably thinking about it wrong. Because if it doesn't make sense, if I'm frustrated if I'm just hitting against it, I'm probably thinking about it in the wrong way. Taking a step back makes a big difference to me. Have you found in your personal work that that is an effective technique?


DAVID: When I remember to do it.


KYLE: That makes me...I had a manager a few companies back who introduced me to mind mapping. And I don't always start out with that, but when I do get stuck in a problem, I will start mind mapping. And how this relates is when I get so far down a path, I'll either take a step back and see, like, maybe I missed a path for a solution, or I just wasn't thinking that specific section through far enough. And I'll keep going back to see if there's a neural path that I maybe have missed. And that has helped previously. That'll get me out of the weeds a lot of the time, actually.


MIKE: What tool do you use to write out that mind map?


KYLE: Pen and paper, to be honest with you.


DAVID: Yes, I was waiting for you to say one of the 20 different mind-mapping tools that are out there. But every electronic mind mapping tool I've ever found demands that you start at a route, and you descend acyclically down from the route. And I was taught to mind map with pen and paper. And my mind maps are cyclical. I will draw a point, then another point, then a second point or a third point, and then I connect the third point back to the first. And now you've got a cycle. 


When I'm trying to think my way through a mind map, I will doodle the connections that I've drawn between, like, I will darken this connection because it's stronger. I will circle this node more and more and more and underline it because it's more important. And I just kind of let the pen wander over the mind map, adding nodes as I see fit for them. So, Kyle, I'm your kindred spirit on this. Technology has not been able to solve this problem. They've damaged the problem to make it tractable.


KYLE: Yeah, I haven't had good luck with a software-based mind map. The only one that I could say has provided me with better results, especially in a team-type mind mapping, is whiteboard just because, you know, kind of like you're doing adding the different colors and everything. I guess you could do that with colored pencils, but I've never done it that way.


MATT: There's something to be said about low-tech. You know, in this high-tech world that we live and work in, sometimes low-tech is the answer.


MIKE: So maybe changing your environment from the computer you're working [laughs] on to --


DAVID: It can be.


MIKE: Doing something very tactile follows right along the lines of what we've been talking about?


MATT: I think so.


DAVID: It's important to note that it's not just a matter of, like, sometimes the old ways are better where it's, like, well, no, the modern way is clearly better in every possible way. It's more, like, a case of anybody that used a cell phone around Y2K time period; your calls were much, much clearer than they are now. There's a reason for this. And that is because the cell system 20-25 years ago was analog, and you had infinite fidelity on the signal strength. 


Now, as you get farther and farther away from the tower, your signal starts to degrade and starts to fall apart and whatnot. And as the cell companies wanted to make more and more money, they cram more and more calls into the same amount of bandwidth, which means they have to compand, which means to degrade the signal of each individual call to make it fit in a thinner slice. And so the calls get more and more digital, and more digital, and more digital. 


And I remember especially, like, in the mid-noughties to late noughties, it was hard for me to use a cell phone because people sounded like rubber ducks. Everyone sounded...people would just quack over the phone. And it was because they had gotten too aggressive. They had cut everyone's bandwidth down way, way, way too far. And they had to back off and say, "Okay, we have to provide more bandwidth to get more calls. We can't just keep degrading signal quality to make this work."


That's the thing with a pen and paper. It's not that it's low-tech and that brute force is the better idea. It's that it's infinitely analog. You can do things like darken a line or change a color. I guess you can change color in a mind mapping tool. But being able to switch pen types, being able to change the tactile input that you get as you write something, being able to move two nodes the exact distance apart that you want them on the page in infinite increments of analog precision, rather than having to just put this node under this node on the tree and it always must be down one line and in two spaces, yeah, it's so much more freeing to have that much more power.


MATT: The nostalgia of the old analog phones that you had to strap to your belt. But the best phone I've ever owned in my entire life was an old Sony analog phone that was the size of a brick. [laughs]


DAVID: So I've kind of pulled us off into nostalgia a couple of times here. But circling back to the specifics of frustration management, I do like the idea of changing the environment. Internally, we can change our environment as well, I think, which is that if you're sitting at the machine and you're stuck...Mike, I've been in that problem where you've got, like, you talked about the messaging system at the start. You have no idea how the system works. You have no visibility into how the system works. You have no control over the functioning of the system. 


All you can do is sit outside the black box and just cast things onto the water and hope the output will eventually be different whenever that asynchronous stuff finally, finally comes in. And, like, all of these things kind of stack up to put you in...I don't want to say an abusive environment. [laughs] I don't want to use that word lightly. But it is kind of an environment where you're stuck. And you can get yourself into this kind of stuck thinking where it's like, oh, this is terrible. I'm trapped. I have no resources. I can't get my job done. 


Oh, in addition to the no observability, no debugability, no, you know, da, da, da, there's also no mercy if you don't get it fixed. So we're going to just keep ratcheting this up until you make it work. And you can feel shackled to the machine. And just, like, ah, how am I going to make this work? Sometimes being able to step back and go, all right, guys, it's just a computer. Let's breathe. There's only two ways this bit can go, either one or zero. How do we reduce this problem? 


Finding a way to step back and give yourself some control over your environment or just control over yourself can be immensely liberating. And it can open up to you a lot of tools that you had on your belt the entire time, but you kind of get blindered. You stop thinking that, oh, I can deal with this, and you suddenly...half your toolkit has vanished because you're not present to it anymore. 


I don't know; I feel like I'm babbling. Does this make sense? Where, like, you don't feel trapped and stuck on the machine? Suddenly, all the things that you could have done all along but didn't know suddenly you remember that they exist. I don't know if anybody else has had that experience, but it has for me. 


MATT: Yeah, freeform, right?


DAVID: Mm-hmm.


MATT: I, as a hobby, and in a past life early on out of high school, was an artist. And I'm kind of relating to that and the digital age where I feel so much more free using real paint or real pencils versus a tablet to create art. Yeah, there's so many things you can do with technology. But there's something about that freedom and the feeling it gives you doing it the old way. It just...it frees the mind, I think.


MIKE: You know, I might expand on that a little bit. The recent surge in generative models used for AI art [laughs] was triggered by some pretty interesting realizations. Previously, there was always an effort to kind of start with something and get to something. [laughs] You got to follow these sorts of rules, or you've got to match this thing. 


And they decided to try a new technique. What they did is they took an image and then they blurred it a little bit. And then they trained a model to deblur it. You know, add a little bit of noise to the image, some visual noise, and then train a model to deblur it and get back to the original. And then, you add a little bit more noise and see if your model can get back. And then you add a little bit more noise. And they do this, you know, with millions of images. They add a little bit more noise, and a little bit more noise, and a little bit more noise. And then you bring it back to the original.


Eventually, they just start with pure noise and some text [laughs] and say, "Bring me back to what this image is." And, in previous models, it had always sort of fallen flat. But this approach where you gave it a completely blank slate, right? Just start with noise and make this look like a duck in a captain's hat. And the AI looks at it, and, like, okay, well, I think I maybe kind of see a duck over there, right? [laughs] And it starts inventing. 


And, eventually, you get a photorealistic duck with a captain's hat. That approach of going back to perfect, you know, as you said, Matt, freeform, where just, you know, start from scratch. Starting with a blank slate ended up being far more effective than other techniques had been. It doesn't even just work for humans.


MATT: And I love that.


DAVID: The thing I love about the AI things is when they frame it in a style. So they'll do the make me a picture of a duck in a captain's hat, but do it in the style of a 1960s tobacco billboard. And it produces something that is terrifying. You're just like, oh my gosh, that totally could have been on the side of the road in 1964.


MIKE: [laughs]


MATT: I have spent so much time playing with those things. 


MIKE: [laughs]


MATT: All of these lead us back to those frustrations. And, as we talk about this, maybe that's one of the answers is find something that you find joy in to help with that frustration. The bottom line is letting it go and, I think, accepting it.


DAVID: Resignation to your fate. It's a little fatalist, isn't it? But, yeah, accepting what we have in front of us.


MIKE: And I think there's something very liberating in acknowledging reality as it is. And, in fact, I take that further. We've been talking about arts a bit. I'll talk about another art example. I'll talk about Shakespeare. Shakespeare is considered, I think, widely to be the greatest writer in the English language. And one thing that's interesting about Shakespeare is that he had, like, one hand tied behind his back. Because, generally, the form that he was expected to write in had some fairly rigid rules. It had to have a certain number of accented syllables per line. Typically, it was rhyming, right? 


So the language that he was constrained to use was a rather limited subset of the English language. And, with those constraints, he was able to create great art. And I would argue that, to a degree, the constraints themselves were what enabled him. A teacher mentioned this to me in high school, and it kind of blew my mind. 


Like, oh, that's an interesting point [chuckles] that once we are given constraints, then we filter down the world of possibilities. And then there's less that you have to deal with, and you can focus in on what you can do. And that's remarkably liberating because, within those constraints, you don't have to think about everything. You can think about what could fit, and it allows you to fill in blanks with something pretty great.


MATT: And it really helps us to keep things simple. Humans, by nature, overcomplicate problems. And those constraints can really help you just keep it simple. Don't overcomplicate it. Don't overthink it, and just tackle the task at hand. And, in software, that is really important. I try as hard as possible every time I take on a task to make it as simple as possible. If it needs to become more complex as we go along, that's great. But I always find the simpler, the better, and you usually end up producing better work that way.


DAVID: I love that. There's an interesting tension here that we're talking about, like, for creativity...and I heard this back in, like, my 20s, but it's been so true. If you want to increase your creativity, increase your constraints. If you want to write like Shakespeare, tie one of your hands behind your back, figuratively speaking, right? 


There's a fantastic video by Tom Scott about Why Shakespeare Could Not Have Been French. And I'm, like, that's pretty elitist. No, he's like, literally, the notion of an iamb, which is the thing you make iambic pentameter out of, doesn't exist in French. You literally cannot construct iambic pentameter in French. It doesn't work. There are other types of poetry in French that have meters that match the metrics of the French language, and French poets will follow those. 


But, yeah, if you want to increase your creativity, increase your constraints. If you don't believe me, try this exercise. First, name every animal that you can think of, and give yourself, like, 10 seconds to do it. And I find I get, like, five or six out there. And then circle back and say, okay, do the same thing, but do it in alphabetical order. 


And you're like, whoa, what? Somebody has said, "Oh, name all the animals you can think of," all right, fine. I'll start in the alphabet. But if you start with A, you can immediately come up with an animal that starts with A, and you get to 10 seconds, and you realize I just named 12 animals because I constrained myself. The constraint gave me structure. 


The reason I mention this as a tension is that when I'm debugging, I want to go the other way. I'm already constrained five different ways. I don't know how the system works. I can't observe it. I can't debug it, can't...I don't have unit tests or whatever. What can I do to increase my options and my choices? And sometimes we don't have very many. And that's a good time to just kind of sigh and accept without judgment and just say, "Well, I guess we're going to get pretty creative because we are pretty constrained."


MIKE: This idea, I think, is so powerful, and I'll add to it. Multiple of us are musicians here. For those who are musicians, I want you to think about this. If I want to sit down and make some music, invent some music, improvise, well, I just sit down and say, "I'm going to write some music," that's an intractable problem. What am I going to do? But if I sit down and come up with a riff, just if I'm going to play on the piano, I will [inaudible 31:46] my left hand. And I'll come up with some chord progression or play something sort of melodic that sounds interesting and then start repeating playing it as a riff.


So it's something that could be in a cycle that I can listen to. Well, now I'm wildly constrained versus what I was before. Now I've got something that I have to work with that I have to fit into. And, suddenly, I can play because now I can invent music that fits within those constraints, and I can make music. And if I remember that, if I ever want to sit down and write a song, you know, in a couple of minutes, I can be improvising and having some fun by starting by limiting that world down to those constraints. 


MATT: That's such a great example. I kind of do the same thing. If I am asked to just sit down and play something on a guitar, I would fumble. But if you said, "Hey, sit down. Play something. This is the mood I'm looking for," then I can say, "Okay, I can pick a key." And once you constrain it down to a key, it becomes really easy because there are constraints on how you're playing it.


DAVID: That's impressive. And various things can imply a lot more constraints, right? Like if you say, "Play me something moody," that's going to constrain things gently in a certain direction. But if I say 12-bar blues in G minor, you know the chord progression now. It's 12 bars, and you have to start on the one, and there's rules for how they come out. And so you've got your chord sequence now.


MATT: Yeah, if someone says, "Play something moody," I think, okay, A minor because that, to me, is the moodiest key. It makes it so much easier locking things down, having constraints, which, in software development, we have requirements, right? And if we don't have requirements for a problem, then it makes it really difficult to solve.


MIKE: I'm going to take this right back hard into software. We've been talking about constraints. Frustration, in the general sense, to be frustrated that word means to be stopped, to have your course blocked. And these constraints we mention are essentially that, right? They're frustrations. They're barriers. They're obstacles. And what we're saying is that those frustrations actually provide us a framework in which we can create beautiful things. And it's the existence of those frustrations that gives our work shape and even meaning.


KYLE: I was thinking about this as you guys were talking about music. I don't play, but my family had sent this YouTube video that was talking about how they did the music for the Dune movie. And, in that, we were all kind of shocked to see that the bagpipe that you end up hearing in some of the scenes they were saying that that wasn't actually done by a bagpipe. That was done by an electric guitar. They had just taken a different approach to generating those sounds. 


And I think that can be related to software in the sense that you can constrain yourself but don't let the constraint be of frustration in the sense of, like, that you tunnel. And what I mean by that is don't go so far into a tunnel that you're insisting on using a specific tool. Sometimes another tool will provide you with the same result, if not a better one. 


The example that I can think of right now is just on our team. The easiest tool for us to use, specifically our lead that designed the Acima script; he was very familiar with Ruby, and he was able to bust out the script in Ruby. But that didn't make it as easy to pass it around. And so, he took a different approach with another tool and used Golang. And that made it easy to distribute an executable to all of these systems. 


And so much now that, you know, Apple silicon or ARM64 is becoming a more popular option. We need something for those environments. And this has allowed us, because of that tool, to now generate that software, you know, with just one or two changes. Then we have an executable that will run on those. So it's cross-platform now. Just thinking about that, just while you're constrained, don't also tunnel because that can just add to your frustration.


MIKE: Oh, that's great.


DAVID: I think approaching your constraints as a challenge as opposed to a trap or something that just leaves you powerless...something that I keep hearing come back, and back, and back as we talk about this is the notion that sometimes we look at the challenges in life with fear. And other times, we look at them with wonder and excitement. And the only difference is the attitude that we bring to it. 


Looking at the inconsistencies, or the challenges, the difficulties that we face, when we see them with kind of, like, wonder, they become opportunities. They become interesting things to play with. They become flavors to taste rather than things to be pushed away and kept at a safe distance. And I think that mindset really, really makes it a lot more powerful, a lot more capable for us to kind of relax and just kind of play with what we have. And that helps us find the way out that we're looking for.


MIKE: I love that: flavors to taste. There's one other thing I wanted to bring up, and I think that it builds on that idea of joy you just brought up, Dave, which I think is phenomenal. I think the one other technique that we really haven't talked about is asking a question, what else could I try? And to your point about, you know, this is a world of discovery, if you're in a situation and you feel like, well, there's nothing I can do, well, then there's probably nothing you can do. [laughs] You've made a choice. 


But there usually is something, even if it's trivial, right? Well, I could breathe differently. [laughs] That is an experiment. That is play. If you look at the problem and say, "What else could I try? Is there maybe some way I could add some logging to this that is crazy but maybe does something, or is really simple and crude, but it would maybe get some information out of this?" Or maybe I usually use a debugger. Maybe I could just use some simple text logging. 


Or maybe I could add a request ID to all of my requests that I make so I can track what's going through. Or maybe I could log my thread ID so I can connect the thread with the outputs going on. There's usually something else we can do, and seeing the world as a big sandbox. What could I try next? Changes that perspective. It gives me an opportunity to keep trying.


DAVID: Amen. One of the best tools or ideas put into my quiver early, early on, was the notion that debugging doesn't stop when you run out of answers. It stops when you run out of questions. As long as you can sit back and say, "What else can I try? What else is there? Have we looked at this?" There's always more things to find out. So, yeah, when you run out of answers, it's time to loop back up a level, not to just give up.


MATT: I love that. 


MIKE: That, I think, is the perfect place to kind of land here. Yeah. Thanks for joining us and for all of your thoughts. And thank you to our listeners. I hope that you've gotten some value out of these tools you can use to work through the constraints that you have and even celebrate the constraints that you're working with. With that, see you next time.