Outside-Work Programming Projects

About this Episode

In this episode of the Acima Development Podcast, Mike kicks things off with a cycling story that serves as an analogy for problem-solving in software engineering. Planning a long ride to Illinois’s highest natural point, he had to carefully map his route with handwritten directions before realizing he could quickly write a small program to calculate distances. The story highlights how coding, even outside of professional contexts, provides practical tools for organizing complexity and solving problems efficiently. This segues into the episode’s theme: the value of side projects as creative outlets that both challenge and refresh developers beyond their day jobs.

Dave picks up the discussion by sharing his own side projects, ranging from building automated tools for games like Minecraft to recursive Sudoku solvers. He describes his habit of scripting repetitive tasks at work and how tinkering with small, often quirky coding challenges keeps his skills sharp. Will chimes in with his perspective on solving Sudokus using deduction instead of brute force, sparking a lively debate about problem-solving strategies and approaches to recursion. They also discuss playful experiments like writing adventure games in SQL or porting Doom into Postgres—projects that might not have practical business value but showcase curiosity, resilience, and creative problem-solving, traits they argue are vital in startup or complex development environments.

Later, the conversation broadens beyond coding to explore balance, curiosity, and learning from outside experiences. Will reflects on being new in a role and choosing not to code outside of work, instead focusing on absorbing context, leadership, and finding inspiration in non-technical pursuits—whether it’s parenting, reading fiction, or woodworking. Dave shares his experience building cigar box guitars, while Mike recalls colleagues whose hobbies, from rose gardening to counseling, enriched their professional lives. They conclude that having creative or restorative pursuits outside of work—whether technical side projects or entirely different hobbies—ultimately strengthens problem-solving skills, resilience, and perspective in software engineering.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. Dave and I are going to do kind of a joint hosting thing today.

DAVE: Hello.

MIKE: We've got Dave Brady here, and we've got Kyle, and we've got Will Archer. Actually [chuckles], we've got the Archers [laughs].

WILL: No relation.

MIKE: [inaudible 00:00:37] relation [chuckles], Kyle and Will. But the four of us are here today, and I'm going to start with a story.

As Dave and I were talking, we were kind of debating on the pre-call who was going to host today. And we're both going to do this, but I've got the story. I've got the story. So, that's [laughs] why I [inaudible 00:00:57]. I have mentioned before that I've done a lot of cycling. I won't go too deep into it. I've done a lot with my kids, which has actually helped strengthen me. And, occasionally, I've gone out solo and had these great, long rides.

I went on a long ride a couple of weekends ago. And the ride itself is not where I'm going here. But ahead of the ride, I needed to find out the route. I was planning a new way I'd never been before. I went to the highest point in Illinois [laughter].

DAVE: 12 feet above sea level?

WILL: 13, baby. 13.

DAVE: 13?

MIKE: Okay. So, I misspoke. I went to the highest natural point in Illinois. The highest point in Illinois is not actually a natural point. It's the top of a high-rise in Chicago.

WILL: Is it a tower?

DAVE: Like the Sears or whatever, yeah.

MIKE: Yeah. It’s now called the Willis Tower.

DAVE: Is it still --

MIKE: It's called the Willis Tower.

DAVE: Willis Tower. Is it still the tallest?

MIKE: It is. But there is a...the highest natural point in Illinois is called Charles Mound. It's 1,235 feet, which my house is about 800 feet, so it's not that much higher. Except it's a ways away, so it's more about the distance.

Okay, I'm going to detour slightly. It actually is relevant here. It's in a part of the Midwest known as the Driftless Area. That's sometimes just called driftless. They could put different words after driftless, but driftless is the key word. It was unglaciated during the last ice age. So, unlike what you'd normally think about as the Great Plains, which are made by glaciers scouring everything flat, it is not scoured flat, and it is actually extremely hilly, not mountains, but exceptionally hilly [laughs].

And this high point is actually just, like, a half mile from the Wisconsin state line. Wisconsin has this as well, this very hilly area. And there's rivers that cut deep canyons in between high hills on both sides, hundreds of feet high.

And to get there [chuckles], I had to wind away through back roads through this hilly area, which means that there were a lot of turns. And if you ever tried using Google Maps, it only lets you get to, like, 10 steps along the way, and then it just bails. Like, nope, that's all you can do. And so [chuckles], that wasn't going to work. I actually did it in sections, and I carefully wrote down the turns and the distances between each one of them in a document. And I built this all out in just a text document because I'm a software engineer. That's what I do; I write it out in a text document.

And [chuckles] I got through it. And there was one point there was an alternate. I wasn't sure if I was going to be able to go [inaudible 03:39] because it was just, like, a farm road, literally through a farm. But there were no signs posted, and Google said to go that way, and it was actually in Google Maps with Street View. I'm like, okay, well, I'm going to do it, and I did. It was beautiful, by the way [laughs], and it was fine. Nobody yelled at me. I wasn't sure [inaudible 03:55] way.

So, you know, it was a text file, but there was some weird stuff in it. I got through it and said, okay, so how many miles is this? And [chuckles] what am I going to do? Hey, I will just write some code, so I did. I pulled up a console, and I had my answer in, like, three or four minutes. I had to do a little bit of cleaning to sanitize some of it, remove some of the stuff, and put it all together.

And it reminded me just how useful code can be. It allows you to do amazing things to solve problems. This was something far afield of normal software engineering work, and it still ended up [inaudible 04:33]. I'm going to use code as a tool here, and it allowed me to solve the problem quickly. If I had tried to add that up by hand on a calculator, I don't want to think about that. Maybe I could use a spreadsheet, right [chuckles]? But then I would have to deal with all the edge cases in there because there's the alternate routes that would have been a pain. Pulled it off quickly just by writing some code. It's an amazing tool that helps us in many things.

And today, we're going to be talking about our side projects. Normally, we talk about our day job, but we thought today we'd dig a little bit into the things we've been working on outside of work and how that's going. And it gives kind of some context to our day-to-day because these side projects tend to be weird [chuckles]. They’re the miles that you get to a high point. They just are way different than your normal work, which makes them fun. It breaks up the monotony. There's my story. And I've got a couple of other things I've worked on recently that I may bring up, but I'm going to start with that. Dave, over to you.

DAVE: Well, I don't want to follow up story time with Uncle Mike with story time with Uncle Dave, but here we are.

MIKE: [laughs]

DAVE: So, I'm constantly writing stuff. My career hack for people is, if you have the time, which most people you got to decide. We all get 24 hours a day. But I no-lifed programming for most of my 20s and 30s. I would go to work. I would work all day. I would go home. I would keep writing code. And insert story about mental health here. Work-life balance was something for other people to do.

And what I found is that there's not a problem...there's not an interesting question that I can come up with that I usually can't immediately think, I wonder if I could solve that with a computer? Off the top of my head, without going into full-on stories, although I might tell the clicker story because we can talk about AI for research as part of writing custom stuff.

But in the last 30 days, I have worked on a planner sheet thing that literally people listening at home won't be able to see this. But if you've ever looked like a Franklin-type, you know, day planners, that kind of thing. So, I figured out how to make a program, draw it out, fill in all the dates and times, and send it off to the printer. I built an auto clicker for Minecraft because I was AFKing and needed resources.

The other weird one, and this is harder than it sounds, or no, this is exactly as interesting as it sounds, is trying to calculate the cost of a recipe in Minecraft. If you want to build sticks, right, you need two boards to build four sticks. But to get two boards, you need one log, and that makes four, and there's, like, surplus numbers. And if you want to build, like, some of these late game, really complicated things, you can have these build palettes that are, you know, with thousands of blocks that you have to know what you need.

And normally, we just stand next to the crafting table, next to your inventory, and just pull what you need and build the next piece. And you just keep, do I have what I need? And on the other times, sometimes I'm like, no, I want to know how many, you know, how many chest full of, you know, cracked bricks do I need to have ready to go before I start this?

And being able to say, “I want three of these, but it's made up of this many of that,” you can see very quickly, like, this nested hash of, like, the dependencies to make this item requires these things. And they require this, and they require this. And it's just algebra, but it's tedious, and that's what computers are great at. Computers love tedium.

And there's half a dozen other things that I've written. Some of them are work-related. Like, I will...if I do a thing in git more than three times in a day, I'll start thinking about, do I want to just wrap a script around this, or do I want to keep this memorized? So, I'm constantly tinkering with things. Games as well.

I think you were saying...you said Sudoku puzzle. Did you mean programming is like a Sudoku, or do you mean writing programs to solve Sudokus? Because that was a very fun thing that I did about 15 years ago. James Edward Gray used to do, oh, it was to sit down and write some code in an hour. I'm blanking on it, Ruby [inaudible 08:46]? I'm blanking on the name.

But he would do this thing every month, where it's like, here's a programming challenge. It should take you about an hour. And son of a gun, he said, “Write a program to solve a Sudoku. It should take you about an hour.” And I'm like, what? That's nutso. And now I might be able to, but back then, it took me, like, two days to write the thing. And--

MIKE: So --

DAVE: Yeah. Sorry, go ahead.

MIKE: Sudoku comes in multiple flavors. The simple case, I did this probably more years ago than that. Simple case is easy, but there are some of them that require backtracking, where it's not fully specified. So, you have to start branching, and it gets a lot more complex.

DAVE: I have written a recursive solving solution that I now have a repo on GitHub just called Game Players, not Game Playing, but Game Players. And it's programmed to play other people's programs. And the pattern emerged very, very quickly of, here is the board. Here's the thing in it. What are the legal moves? Can I make one? What state does the board go into? Now recurse, and keep going until we...if you can exhaust all the moves out of the board, then great.

WILL: I see, like, I don't know whether I buy that sort of you need to backtrack problem. How I always solved Sudokus, in my general case, was always a little bit of a dynamic programming approach in that I would say, all right, here is the...so, I would create a board, create the blank board.

And then I would say, okay, so, for every cell, I've got a set from 0 to 10 that could be here, and then I would just sort of start adding things in. And then that would populate the board, and then I would eliminate the set. I'd be like, okay, nobody else can be a 1 on this row. Nobody else can be a thing. And then I would just finish that, populate that whole thing. And then I would go through the things until I found a...what do you call it? Something that there would only be one thing, and I’m going to put that in. I wouldn't even need to backtrack because like --

DAVE: What do you do if you put a 1 in the top-left corner, and then build out the rest of the board and find out that the 1 isn't correct there, and you have to go back and start over with a 2?

WILL: But that's not possible. I would never put...so, it's always a matter of...it's always a matter of you never make an illegal move.

DAVE: Oh, okay. You're writing a thing that actually does the deduction. Yeah.

WILL: Yeah.

DAVE: Mine was just a brute-force solver, just throwing numbers at it until something drops out.

WILL: That's probably faster to write, you know.

DAVE: The deduction would probably be a lot more fun to write though because then you'd get to understand what are the rules to it. What are the second-order implications?

WILL: So, you just muscled it through, huh?

DAVE: Yeah. And once you start seeing every problem looks like recursion, then everything is a smashed thumb. That's a terribly mangled metaphor, but yeah. When the only tool you have is a hammer, you're going to smash your thumb a lot. And so, yeah, I will approach things in terms of can I make a board out of it? Can I determine what the legal moves are? And does the legal moves reduce the solution set? If those three things are true, that is the definition for recursion will work here.

And in late game, I started reaching for recursion first because I had the board set up. I knew all I have to do is fill in this method, and give this a loader and a saver, and I'm good to go. And down the road you go, and it's crazy, so...

WILL: Interesting.

DAVE: But yeah, deducing is also a good one to do as well.

WILL: It seems more efficient. I don't know. I'm not an animal, just, like, hit it with a rock until it stops moving. All right. That's...okay. I went to school for this. I'm not going to like -- [laughs].

DAVE: I dropped out of school for this.

WILL: Yeah, well [laughs]. Interesting. Interesting. Sorry, I guess it's, like, you know what I mean? With, like, grad school, I spent my time working on sort of deductive decision trees for other things. So, that's just sort of, like, a...oh, well, that’s obviously what you would do [laughter], you know? Anyway, so yeah, regardless.

MIKE: Well, there's some sort of tree in that Sudoku solving at work. We're just talking about interesting stuff here, right? But there's...where it's not fully specified, right? Where there is..it's I am ambiguous which branch you have to take. Well, there's going to be some sort of tree structure, whether you're doing dynamic programming. There's different ways of representing that in terms of data structure. But conceptually, there has to be branching of some sort.

WILL: I don't think I’ve ran into that problem. I don't think I’ve ran into a situation where, if I had examined all possible scenarios, there was one where there were two legal moves.

MIKE: Yeah. The worst Sudoku puzzles have that. And that's where it gets...and, suddenly, it's way harder. It's not that hard to write a solver for a puzzle that's a beginner puzzle. But then they start to have those where there's multiple legal moves, and one of them is going to be a dead end.

WILL: Interesting. Interesting. I have to think about that a little bit. I have to think about that a little bit more than I have.

DAVE: Arguably, it's the same solver if you combine the two steps, where the first step is, is there a move that I know I can do? Because why would I guess if I can deduce what the correct move is? And then if you run out of...if you don't have a deducible move, then it's time to start guessing and putting...yeah.

WILL: Oh, that’s fair.

MIKE: Then you get your tree, right? You're going to have to branch down some direction, and sometimes it's going to be a dead end. And dynamic programming can address that, right, if you structure it right because you end up just taking the path that works, but you're kind of going down every one. I'd have to think about exactly how to set that up.

WILL: Well, I mean, basically, you represent the Sudoku as, like, a three-dimensional array, I guess I'd say, right? Like a two by two, you know, by three in that, like, okay, so I'm going to say, oh yeah, I'm going to...Each cell has a set, right, of possible legal moves, right? And so, you iterate down until that set comes to a fixed point, right?

And then if you have a situation where it's like, okay, well, the best I can do is this one has a set of three moves that I could do, right? Then you iterate, and you say, okay, I'm going to say it's one. I'm going to put a one in there, and then I'm going to go through. And then you continue to iterate, iterate, iterate, until you get to a situation where one of those cells has a null set, right, where there's no legal moves.

Like, that's where you know, like, oh, I screwed up. This is not solvable, right? And then you backtrack, you know, until you get to that iterative point. It's like, okay, well, I'll try and put a two in, and then you'll go through. And then like, you know, oh, null set. I failed. And you'll go back, and you'll say, okay, I'm going to try and put a three in. And it will either work, or you'll get a null set, and then the Sudoku puzzle in itself is --

MIKE: Is invalid, right [chuckles].

WILL: Is invalid, right?

MIKE: And interestingly, you're talking about two broad approaches. So, Dave, you’re like, oh, I'm going to do recursion, and you're going to come up with an iterative approach. Two pathways that diverge but end up in the same solution.

DAVE: Awesome. Years and years ago, I was goofing around with somebody, and I'm like, “I need to drop this table.” And I wrote drop table, and I hit Enter. And somebody responded with, “You dropped the table. There is a table here,” like the old Zork commands, like the old text adventures where you pick up the sword and take the lantern and go explore the cave.

And we giggled about this, and I joked, and I said, “You know, PSQL or PL/SQL is Turing-complete. You should be able to write an adventure game in pure SQL.” And everyone was like, “No, it can't be done.” I'm like...So, I wrote one to win a bet, and it was just fun, and stupid, and silly. And I lost the source code. It was like 2006. I lost the source code to it, and I've tried to recreate it a couple of times, and I just haven't gone off it.

And I was thinking about it a week ago, and somebody said, “You know, there was a guy that ported Doom to Postgres, right?” And I'm like, “No.” And it's for real. Somebody figured out how to get it...It's text. The graphics are terrible. It's ASCII art. But, apparently, it's even got a decent frame rate, and it's a first-person shooter in Postgres in PSQL.

MIKE: Wow [laughs]. I'm not quite sure what to say about that. We're talking about solving problems that don't necessarily need to be solved.

DAVE: And solving them in interesting ways, which then makes it so when I'm hiring somebody, I will ask them, “What are your hobbies and your interests?” And if I get somebody who's weird like this, if I'm at a...I've never hired from an enterprise position where I need somebody who's stable and just a metronome; you’re going to clock in at 8, clock out at 5, get 1,000 lines of code, da-da-da. That's not a good person for that.

But if you've got dragons and you're in startup mentality and you need weird solutions because you have weird problems, I love finding that person. Not because they know how to write Doom in Postgres, but because they know how to look at a tool and go, I wonder if I could turn that around backwards and use it this way and find a completely new way to use it?

MIKE: It speaks to curiosity and play, which are characteristics of somebody who can solve problems.

DAVE: Also, resilience, interestingly.

MIKE: Interesting.

WILL: I like that, right? I like that. And I like to play, and I like projects which reflect sort of, like, tinkerers. But I'm curious if you guys have a perspective on, like, most of my job is just reading other people's stuff and figuring out what the hell you people do. What do you people do?

DAVE: Code forensics.

WILL: There's very little Greenfield stuff. And so, what are good projects that demonstrate...like, honestly, the pivotal requirements around enterprise software development, where you're just sort of, like, groveling through the context, legacy codebases decisions that go years from people who've gone. And they've left their footprints in the fossilized clay, and you have to backtrack through what happened. Which is just a lot of reading code and a lot of patience and grinding through things, right?

I mean, because, on one hand, like, yeah, that's the job. But on the other hand, if you're doing this in your free time, you're a psycho, you know what I mean? Like, what? Was it cold outside so you couldn't catch any small animals to torture and kill them, like, you know what I mean?

[laughter]

DAVE: I can neither confirm nor deny, but if you want to look in my freezer, you're going to need a search warrant.

[laughter]

MIKE: There's a thing online where people will post a picture, and people will try to figure out where it was taken from.

DAVE: Like GeoGuessr?

WILL: Those guys are also psychos or, like, undiagnosed autists.

MIKE: Well, it's relevant here. I heard about...I don’t remember the exact story. This is a few years ago. There was somebody who was lost in the mountains. And his phone was dying, and he managed to post a photo from his location. And his phone died. And whoever got the photo reached out to people online and said, “You know, my loved one's lost in the mountains. What do I do?” And this community of people who locate where these pictures are taken from, found it, and figured out exactly where this person had gotten lost, and that's where they sent the search party.

DAVE: That’s fantastic.

WILL: Wow. Did they find him?

MIKE: They did. They found him. And I believe it was a him, and he lived because of these people.

WILL: It’s always a him [laughter].

MIKE: Off trail, he'd, like, gone down a cliff or something, so he was not where he should have been. But they found him anyway because this photo got posted. But that, you know, talking about that skill, I feel like that specific skill is the one that ends up becoming the most useful for senior engineers who are in the code. What is going on here? Where am I? What is the context, and how do I get here? What's here around me? And, you know, it's in the code. It's not out in the world. But it's that kind of thinking.

DAVE: 100%. 100%. I call it code forensics, where you start reading, and it's text on a page or on a screen in a fixed font, but you can still read other people's handwriting. You can absolutely tell, oh, this was written by that person who likes this particular pattern and likes to name their variables this way. And that means that when they go to solve this thing, they're not going to use this pattern. They're going to use this one. So, I'm not even going to look in this other sort of...or I'll look in the other place, but not first.

I play a lot of Chesterton's Fence with myself mentally. It's like Chesterton Fence, you find a fence in the woods, and it's in your way. Should you get rid of it without knowing who put it there and why? That's the thing. Some people very quickly are like, no, I'm efficient. We need to get this out of the way and get moving. And other people are like, somebody had a reason to put this here, and they went to great effort to do it. Let's find out why.

So, when I see something in code that doesn't make sense, I don't immediately assume that it didn't make sense to the person who wrote it. I start stepping back and going, okay, if you wrote this on purpose, what situation would you be in? And you end up spending a lot of time, like, playing with, like, git blame, looking up old PRs, and trying to see, okay, what problem were you trying to solve?

And I like it when I find some new thing in the code that's like, oh, do I have to follow this pattern? And then I'll git-blame it, and I'll find out that it was, you know, written by a developer in Poland in 2017 and hasn't been touched since. And I'm like, okay, either this code is rock solid or abandoned. And I've never seen this module come up in our Rollbar log. So, I'm pretty sure it's abandoned, but it might not have been. It might have been written two weeks ago by one of our contractors. And so, that greatly affects whether I will make the code match my style or whether I'll make my style match the code.

MIKE: So, we’ve dug a little bit on that playfulness and the skills required to deal with the kind of software, which are not, like you say, Will, they're not that greenfield kind of development very often, you know, it's new on day one and never new again [laughs]. And even after that, you're building within some framework, some context that you have to be aware of.

WILL: I mean, I enjoy... So, I was thinking about this a little bit, right, as you guys were talking about it, like things you’re working on right now. Like, so, I'll be honest, right, like, right now, I am, like, three or four months into, like, a new role, you know, with a new codebase, new tech stack, like, new everything, right? And I'm not coding nothing outside of work. Nothing. Nothing.

And I shouldn't be coding nothing, and, like, you know what I mean? And you shouldn't feel bad about coding nothing because, like, I'm drinking from a firehose right now. I'm, like, running. I'm still, you know what I mean? I can get things done, right? I'm clearing tickets. I'm getting things done. Like, there's all kinds of technology. Like, I'm in meetings, like, all the time.

And I encourage everybody to do this; I'm just, like, writing, like, little notes to myself, like, what is this? You know, like, and it's documented. You can ask people and read about it and just get things going, right? Not that hard, but I'm constantly just, like...And when I get done, you know what I mean, the [inaudible 25:09] free time that I have where I have, like, the ability to, you know, work on stuff, like, I'm not working on code.

And so, these projects you need to be working on don't have to be, you know, [inaudible 25:20] related because, like, I get a lot of inspiration anymore these days about, like, sort of what I'm doing professionally from things outside of work, you know? Because I’m pretty technically solid, you know?

I know my work, and I need to, you know, how does this API work? How does this library work? How does this, you know, third-party service, like, interface with our third-party service? Like, I have things to do. But, like, you could derive a lot of engineering work, and especially when you start getting into, like, interpersonal work and leadership work, and dealing with people. You can learn a lot about management from having kids.

MIKE: Amen.

WILL: You can learn a lot of stuff from reading fiction. Learn another language. Make something with your hands. Make something with your hands that does something, right? Like, just carve it out of wood, chop up wood. Build a deck, you know. There's so many things in life.

And get a good night's sleep, if you find yourself at work, where it’s just like, man, I’m just frazzled all the time, and I feel stupid. If you would like another 3, 20 IQ key points, just 3, get 8 hours of sleep, dum-dum. Yeah, it's just like, oh, today would be a lot cooler if I was 10% smarter, 8 hours of sleep, dummy, you know? Like, don't feel like, I suppose, like, you know, like, we can't all be Dave Bradys who are just, you know, programming freaks all the time. Like, you've got a life, and, like, you should live it, and coming in with a mindset, you know, because there's seasons, right?

Because you'll also find a season where you know everything, and you know everybody, like, every burial ground, every, like, you know, poorly covered, shallow grave, and/or mass grave, you know, in the company, and you know where things are. And you find yourself in a rut and rot, and everything's just boring. I’m just doing the same thing over and over and over again. Well, then it's time to start tinkering. Then it's time to start investing in things.

But like, you know, when you're drinking from the firehose, which we will spend at least half of our time just completely drowning...and do something else. Read a book where there is not a robot to be found anywhere.

MIKE: [laughs]

WILL: Not a [inaudible 27:47] robot. Not a one. You know? Like, write poetry or go geocaching. Do something else. It feels like you're not progressing, but you absolutely are. Doom scrolling on social media probably I'm not going to count that one.

DAVE: Not as good, not as good.

WILL: But you could watch a Ted Talk, you know. Anyway.

DAVE: Learn music would be the other thing. I messed up my elbow, and I could no longer fret. I'd been taking guitar lessons, and I could no longer fret a sixth string. And somebody said, “Why don't you play a cigar box guitar?” And I'm like, that's weird. And to shorten a very, very long story, somebody said, “They're even more fun to build than they are to play.” And I'm like, that's not [chuckles] even remotely possible. And then I ended up building...this is number five. I've built one and a half more since then. So, I'm working on seven right now. And they're ridiculously fun to play.

MIKE: My first boss I had as a full-time software engineer, had a rose garden at home. And I still think that was relevant. And I don't always talk to everybody and know all they do. But a recent person I've worked with does counseling with people who are getting married on the side, right? And does software during the day and this very different thing at night.

I'm building on what you said there, Will and Dave, that it really does matter. Having that other thing improves your ability to do your primary thing because it gives you new ideas.

DAVE: Drastically. Absolutely.

MIKE: I led by talking about that bike ride. I was thinking about this directly relates to software because...very indirectly relates to software. But figuring out how to make that work if you're going to go a long distance is actually challenging. Getting enough sugar that you don't run out of sugar and then have a, not a fall-off-your-bike crash, but a physiological crash where you just can't move anymore [chuckles] is a real problem. And if you don't deal with that, you're not going to be able to do it.

Figuring out your logistics, you know, you need water. And there's challenges in those things that you have to work out. And you have to be very detailed and meticulous about it. And developing those skills pays dividends in the daily job, for sure.

Honestly, my life is, I have not done a lot of coding projects outside of work recently for some of the same reasons. Probably one of the larger ones I did is I redid the...I made an alternate intro music for the podcast using the project we talked about, like, two years ago. It's called Sonic Pi, where you use Ruby to write music. And that's the intro and outro music that we're using sometimes. Based on the original one we had, just mixing it up a little bit. And we said we'd do that, and we did.

It really didn't have anything to do with the job at all [laughs]. It let me try something different, look at things from a different perspective.

DAVE: This is very cool. I'm looking at the Sonic Pi website right now. So, you guys finish the episode. I'm going to go look at some music code.

MIKE: Until next time on the Acima Development Podcast.