Acima Development

Mike opens by framing “production incidents” with a vivid non-software story. As a teenager he smashed bathroom tile with a dead-blow hammer, drove his pinky knuckle into a jagged shard, and had to manage both the injury and the panic of his little brother who got sick from seeing it. He uses that as the metaphor for on-call life. Bad things happen, reactions vary, and what you do in the first moments matters, especially staying calm, reassuring others, and focusing on the most urgent next step. The group riffs on modern incident response, starting with humor about “just ask the LLM,” but landing on a real point. AI can be excellent at sifting noisy logs, even if you should not blindly trust it mid-emergency. Dave pivots to the idea that the best loyalty, from customers and coworkers, is earned when something goes wrong and support is excellent. He describes jumping into a long outage call ready to tear apart his own recent work with zero ego, because people remember who shows up with “two tow trucks” when everything’s on fire. Mike and Justin emphasize composure and delegation. If you are overwhelmed, hand off to someone with a cool head. Prioritize restoring service, “stop the bleeding,” before deep root-cause analysis. Invest ahead of time in rollback plans, feature flags, staged rollouts, and observability. From there, they broaden into practical triage and long-term resilience. Verify the issue, look at metrics and dashboards to identify symptoms like CPU, disk, network, traffic spikes, and database issues, and narrow the delta between last-known-good and broken. They discuss how constraints differ in mobile, including App Store review delays, crash loops, and reliance on the user’s device and network. They also cover security incidents, where you need monitoring to detect attacks, plus coordinated mitigation like blocking traffic and working with vendors. They stress the importance of having an incident quarterback, a playbook, and a contact list for after-hours escalation. The close focuses on what comes after the band-aid. Do postmortems and cleanup so temporary fixes do not become permanent donuts. Balance realistic risk planning with business needs. Emphasize strong observability and the ability to recover quickly, alongside prevention, echoing practices like Chaos Monkey and the idea that monitoring prevents historical events from re-happening. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. We've got a good crew here today, and I'm excited about this one. We've got Kyle Archer, Eddy Lopez. We've got Dave Brady. Hello, Justin Ellis, Thomas Wilcox. We've got Ramses Bateman, and Will Archer. So, I think we've all been here before multiple times [chuckles]. We've got a familiar crew to talk about an important topic that's always fresh because [chuckles] there's a constant need. I was racking my brain what story to tell for this, and I ended up going back to...I don't even remember exactly when it was, but it was somewhere in my late teens, early twenties, in that era. So, admission, that's quite a long time ago [laughs]. That's more than halfway back [laughs]. And I was helping out at my parents' house with some remodeling they were doing. They were tearing out the...they were redoing the bathroom. And so, they were tearing out...they had a wall that had some tile on it, and they were tearing out the tile. And they were going to put some new...I don't even remember. They shifted things around, but they were tearing out the tile. That's the important part. And I had my little brother with me nearby. He was too young to really help. He was, like, six. And, you know, he was just hanging out and chatting with me, and I was taking a...they call it a dead blow hammer. It's a hammer with sand in it, so when you hit, it just stops. So, it's a weighted hammer, but it has a soft landing, so it doesn't have a...it doesn't bounce back, right? It just kind of stops, rather than having a strong bounce. It's good for situations where you want to do that, right, where you don't...you really don't want it bouncing back and hitting you in the face. And I was breaking up the tile wall. Context, there I am with, like, a six-year-old breaking up a tile wall. And there was some wire mesh behind it, and I was gradually peeling back. As I broke it, I was peeling back this wire mesh that was embedded in some sort of mortar. And I was pulling out [inaudible 02:26] the cement behind the tile. And so, as I'm banging, I pull back a piece, you know, pull it back because I'm making some progress, and I swing in. And because that broken tile is now hanging out and mounted on that wire behind, with the, you know, the cement that's holding it together, when I swing with that hammer at full force, right after peeling, you know, an extra layer back, I sunk my knuckle of my pinky finger right into a piece of broken tile. And I go, oh, and I look down. And I look down into my knuckle, maybe five eighths of an inch, a couple of centimeters more than you should be looking down into a knuckle [laughs]. Oh [laughs], that moment, that's not good. And then the blood starts, right? A rather remarkable amount of blood, I'll say [laughs], was coming out of the finger. Remember, there's a six-year-old here in the room with me. And he yells, "Mom, dad, come help Mike. He's really hurt bad." And, of course, they're thinking the worst. I'm like, "No, no, no, no, no, it's okay [laughs]," yelling. But, you know, there's the moment of panic there. And so, I had some choices in that moment, right? What do I do? Luckily, I think I handled it pretty well. I comforted the people around me to let them know this isn't a disaster. I'm going to need to do something, but you don't need to, you know, call 911. Unfortunately...so, we got everything up, went to one of those urgent care places. They stitched me up. I could tell some other weird stories about it there. A few weeks later, I noticed a little white mark on my finger, and I started pulling, and it was a piece of the thread from the gauze that had somehow got stuck in my finger. And I pulled out, like, a foot [laughs] of this string out of my finger, and then it snapped down near the bottom, and some of it zipped back in. I've never seen it again, like, oooh [vocalization] [laughs]. And I still, when I touch my knuckle, I feel weird sensations all the way down the rest of my finger. It's a [inaudible 04:21] impact of that one. But my poor little brother [chuckles], he got sick from seeing it, and he was throwing up and just not okay. And I felt bad, and I had to comfort him, "This is really okay. I get some stitches, and it'll be fine [chuckles]. It will be fine." And [chuckles] I felt really bad because I was not really even thinking about it. I didn't realize that he was not okay. So, when I discovered before I left, like, 10 minutes later, he wasn't okay, you know, I gave him a hug, you know, tried to help him feel like things were okay, get a ride over to the urgent care facility. They stitched me up, and I'm fine. Today, we're going to talk about dealing with production incidents. And I bring up this example because it's outside of software, but it's a production incident, right? You've got the bad things happen, and what do you do? What do you do now? And I think that there's some aspects to that story we can riff on as well as others. But it helps set the stage for a lot of what happens when we have these production incidents and what we do in that moment because it matters a lot. And how some of the reactions, you know, there's a variety of reactions to this moment among the various parties in place that had some better, some worse, you know, impact. So, servers are down, you know, how do you keep cool? Things are on fire. And that's our topic today. And I've got definitely some thoughts on this. I've written down some notes, but, as usual, I don't want to...I've told the story, right? I've laid out the context. So, I am really hoping some of you all will have some initial thoughts to lead out with. EDDY: Sorry, is the answer not ask AI to see what's wrong with your server [inaudible 06:02]? MIKE: [laughs] DAVE: How do you think the server went down? EDDY: I was thinking, is that not the go-to answer now? I'm sorry, podcast over. Ask the LLM. [laughter]. WILL: Not not the answer. DAVE: The AI is going to say, "You are absolutely right to be upset that the server is down." JUSTIN: So, related to that --  WILL: I mean, I'm just saying that's not not the answer. Like, AI is great at reading a log. Like, it took me --  DAVE: Yeah, actually. WILL: Years, if not decades, to get, like, pretty decent at reading log vomit, you know what I mean, like, filtering through the chicken innards that [laughter], you know, a log will, like, throw up all over you and just be like, "Oh yeah, that's actually it." AI is actually super duper at that. I don't trust it, especially in an emergency but, like, do that. Sure. Yes. Do it. EDDY: I was literally pairing with someone, and we were looking at a Grafana log, right? And I'm like, "Oh, it's because of this." And they're like, "Where? Where is that?" And I'm like, "Oh, I read it somewhere here. Hold on, let me find it again." And, like, you get so good at ignoring all the clutter, you know, and just filtering everything. But, oh my God, dude, like, AI can sift through, like, raw JSON, like candy. DAVE: I have a thought to throw out. I have a bunch. I always do. But one of the things that...and this is not really a production thing, well, maybe it is: loyalty. The thing that makes somebody loyal, a customer, in particular, is you get this graph of, like, did they have a good time, or did they have a bad time? And then did they receive good support, or did they receive bad support? And the most vehement haters of any product are the people who had a bad time and got

The episode turns into a freewheeling, funny, very human conversation about how AI is showing up in developers’ day-to-day lives, especially for the “I can do it, I just hate it” work. Will talks about getting wildly inconsistent AI PR review comments, but still finding real value in using Claude to refactor boring-but-necessary code like splitting up bloated classes and shared components. Dave riffs on how Claude is starting to mirror his humor and writing voice, then connects it to a psychology idea from Marty Seligman: don’t force yourself to “get good” at tasks you’d still hate even if you mastered them, because that’s a fast track to misery. For Dave, AI is a relief valve: it can generate PR descriptions, test scripts, and documentation in minutes, turning a three-hour, soul-draining slog into something manageable, and giving him back energy for the work he actually enjoys. From there, the discussion shifts into “agentic” workflows and a geeky Dungeons & Dragons thought experiment: could you build an AI-powered rules engine that handles combat bookkeeping, tracks inventory and positions, and references a big PDF ruleset accurately? Dave and Will talk through using RAG (retrieval-augmented generation) to index the rulebook and something like MCP-style tooling to let the model read/write to real databases so it doesn’t lose track of facts (what room you’re in, what items you have, what the rules say about advantage/disadvantage). They also touch on how newer models can sustain longer, more coherent outputs (Dave gushes about Claude Opus improvements and even creative writing that lands emotionally), and they speculate that “divide the work into sub-agents” is how these systems stay on track as tasks get bigger. The back half gets darker and more real: what happens when you give AIs root-level access to email, calendars, and money? Will imagines an assistant that can handle adulting (getting flooring quotes, scheduling bids) and Dave goes further, describing the exhausting annual battle to secure life-saving medication coverage for his wife and wishing for an AI that can fight bureaucracy relentlessly. That leads into red teaming, prompt injection, and the uncomfortable truth that guardrails are often driven by liability, not human-centered ethics; Dave contrasts frustrating experiences with GPT-style “lawyer mode” refusals versus Claude’s more collaborative boundary-setting, and argues we’re heading toward rules for AI that resemble rules for people. They close on a practical optimism: AIs aren’t “good” on their own, but they’re powerful force multipliers for getting over psychological humps, clearing drudgery, and even helping people stop discounting their own progress by reflecting back evidence-based positives—an unexpectedly meaningful use case amid all the chaos. Transcript: DAVE: Hello, and welcome to the Acima Developer Podcast. I'm David Brady. And we have been having a fantastic time chatting about AI, and we forgot to hit record. So, we're going to start the show right now. Today on the panel I've got Kyle Archer. I've got Thomas Wilcox, and I've got Will Archer. And this is going to be a fantastic chat. So, what have we been talking about, guys? We've been talking about D&D, music, lyrics, poetry. What's going on in AI this week? WILL: Oh man, I'm getting better. I'm getting better and better. Like, I got an AI review comment on a PR of mine earlier this week, and it was good. And I also got one today, like, just now, seconds ago, and it was doggy doo-doo. So, you know, like, they're getting smarter. They're getting smarter. They saved my bacon. My prompts have been getting more ambitious, you know? Like, more and more ambitious, where I'm like, hey, it's just, like, it's amazing. Like, I love finding the things that I hate. They're not hard. I just hate them. And AI doesn't have feelings about scut work. You know, I'll tell you, like, one thing. This is an antipattern that I think myself and other people will fall into, like, very frequently, but wonderful [inaudible 01:37] for AI. It's like, when you've got, like, shared library components, you know what I mean, or, like, your class is starting to get big, it's not technically complicated to, like, start breaking that thing up and, like, pulling these things into shared libraries, pulling these into shared modules, you know what I mean, common class extensions, like, all that stuff. It's very, very easy to do. It's very simple and straightforward. But you're not doing it, and I'm not doing it, and none of us are doing it, but we ought to be, and we can. And Claude does a pretty decent job. I had to clean it up, but I'm not mad. It didn't do me dirty, like, it did not do me wrong. DAVE: I have started saving screenshots of things that make me laugh about the AI, and Claude is absolutely learning my sense of humor and my writing style. And so, I literally...I will start typing a comment, and then I'll take my hands off the keyboard. I'm looking at one right now that is literally, "Comment, dear future..." and then it wrote, "Dave, colon, I'm so sorry." And that was pretty much where I was going with that comment, which is...it made me howl. There's another one where it's like, "This class couldn't," and then it completed, "possibly be located in a worse location." Oh, something you just said, though, this is a huge, like, a cross-threaded jump. I'm going to be thinking about this for a few days: the stuff that you can do, but you don't want to, that you don't like it. Okay, ready for a real big cross-discipline skip? Marty Seligman, "Authentic Happiness," I think, is...He wrote a book about happiness. But one of the things that he talks about...he's a psychiatrist. He was literally president of the APA. And what he realized is that there are things in your job...we tell everyone, "If you're bad at something, get better at it," and he said, "That is a recipe for depression and misery." Ask yourself what things in your job, that if you were really good at them, you'd still hate it. Don't get good at those things. Get rid of them. Put them off on someone else. Find somebody who likes that work and trade it off because the more you do it, the more miserable you're going to be. You're not going to find meaning in it. It's going to be drudgery and scut work. And there's so much stuff that I have been shoveling off on Claude, using that as my rubric to say, I'm going to keep this. No, you go do that. And, oh, it's so good. I write very, very slowly. It is agonizing for me to write. You guys, you've met me. I like to talk, and I talk fast, and that means I talk sloppily because I'm thinking as I talk. I'm an extroverted thinker. I'm literally hearing myself talk for the first time, and I'm processing these ideas. Well, when I write, I can't do that, and so it slows me down. So, everyone on my team they're writing their Slack report every day. It takes them five minutes. It takes me half an hour. They write a pull request description, takes them 20 minutes, takes me 2 and a half to 3 hours to write. And I've got a review writing skill now in Claude that I just drop it on there, and it follows the Acima template. Here's the ticket, here's the summary, here's the description, here's the reason why, here's how to test. Go on main. It will actually write me the Rails runner script. You put the thing in, like, go into a console, and type this, type this, type this. Nah, screw that. Open up bash and type Rails runner, and then here is your script. And it's going to load your merchant. It's going to do this, da da da. And then it will show you, right here, here's your output. Boom, done. Jump back to the branch; do it again. Here's the different output. Off to the races you go. And it will generate a PR in, like, two minutes, what was taking me three hours, and something that takes me three hours that when I'm done, I don't feel happy. I just feel exhausted. I just feel relief that it's over. And so, having that off my plate, fantastic. WILL: [inaudible 05:35] say there, like, I love it. Like, I have found that another stupid AI trick is just writing documentation, writing reviews, that kind of stuff. Man, I hate it. I hate it so much. But what I've found, right, and this is, I don't know, maybe more psychology than AI, is, like, AI will get it wrong. Often it's not. It'll blow it all the time, all the time. But the fact that they tried and failed, it's like, oh, I've got this thing now. I can work with this thing, right? Like, I'm not going on, like, a blank page, you know? Like, it'll just sort of, like, blargh, vomit out whatever sequence of words it thinks are going to come next in the equation, and then I can work with that. I work from a position of strength. DAVE: Yeah, I put a tweet out this morning. How'd I put it? "Claude lets me be 5 of me, each doing 80% of my work. One of me is an idiot, but the other 4 of us are 3 more of me." The footnote is, "Mind you, some days it takes all four of us to hold that idiot down," right? It's like, we've all lost time to the AI. If you've got any work done with AI, you have lost work and lost time to AI learning how to run it, because when it rolls, it rolls the truck, right? It will crash. WILL: Right. Okay. And this is a great, like, I am far from an AI expert. I am constructively lazy, which is the highest and best version an engineer can have, you know. DAVE: Capital L, Larry Wall's lazy, mm-hmm. WILL: But I'm not an AI expert. Like, I just, you know, I will pick up the tool, and it'll be like, if I've got a handful of nails and somebody's like, "Hey, this is a Powernail," I'll be like, all right, bang, bang. So, I was pitching Dave on, like, a less code-oriented thing. DAVE: Yeah, talk about this for a second. WILL: Mike left, and he left Dave and I alone to our own devices. And so, this is what you get, Mike. DAVE: Dear listener, we are unsupervised. WILL: Unsupervised, unsupervised, a

This episode unfolds like a long, curious conversation among people who can’t help but see software everywhere—even when they’re not writing code. Mike opens with a story about large language models: how something as simple as guessing the next word, repeated trillions of times, leads to strange and powerful emergent behavior. Models start writing poetry, solving math problems, and following instructions—not because they were explicitly taught those skills, but because mastery in one domain spills into others. That becomes the episode’s core theme: real understanding, whether human or machine, comes from making connections across disciplines. From there, the panel moves into personal stories. Justin talks about electric vehicles and electric dirt bikes—machines made of frames, motors, batteries, and controllers that must “speak the same language” to work. Tuning power output or regenerative braking feels eerily similar to designing distributed systems or microservices: misaligned interfaces lead to failure, while deep understanding unlocks performance and joy. Kyle shares his experience retrofitting a sound system into a 1994 Ford Ranger, cutting metal and rerouting wiring to modernize old tech. Thomas brings in video games, describing how a decade-old console game breaks when ported to modern PCs because its logic was tied to frame rate—an unintentional lesson in legacy assumptions and technical debt. Each story circles back to the same realization: whether it’s hardware, games, or cars, the same systems thinking applies. By the end, the conversation becomes more reflective. Mike ties everything to teaching math, music, and writing, arguing that we often strip these disciplines of creativity by overemphasizing rules instead of problem-solving. Math, like programming, is a language for understanding the world; music and writing are languages for expression. The best software engineers, the group agrees, aren’t just chasing paychecks—they’re hooked on the joy of making, tinkering, and solving problems. The episode closes with a gentle challenge: don’t only optimize systems for work. Build something for yourself. Learn a new language, musical or technical. Touch hardware. Make noise. Those side paths, it turns out, are often what make us better at the thing we thought was our “main” craft. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. We're happy to have with us today Justin, who has not always been with us lately [chuckles] sometimes. JUSTIN: [laughs] MIKE: [inaudible 00:32]. He's not going to probably be here for the whole discussion, so I'm going to kind of pick on him a little bit at the beginning. But it's great to have him joining us. We've got a longstanding panelist, Kyle, and we've got Thomas who's been with us a couple of times now, right? THOMAS: Yeah, I think the last four times, so... MIKE: Cool. Cool. And, as usual, I'm going to...and there's actually even more relevance today. I'll [chuckles] come back to... I'm going to start by something a little outside of...well, this one's actually kind of in software, but not in writing software. So, large language models have been all the big thing in AI over the last few years, and it's just exploded. When I say exploded, they're expecting something like multiple trillions of dollars to be invested in data centers and AI generally over the next five years. That's just unthinkable sums of money. Unthinkable sums of money. By the way, we do have Will Archer joining us [chuckles], who is here a little late. So, unthinkable sums of money. It's a big deal. These large language models are a big deal, and they often display what's known as emergent behavior.  Now, let me give a little explanation. How they usually train these things is shockingly simple. They have a whole lot of weights that they use that can be moved around to make a guess. And they feed it some text, just a series of words, and they don't even recognize the words. They just know each one of them is a number. They, like, say, "Here's the series of numbers. Which one's next? Guess the next word." And, of course, it's going to be wrong. They'll nudge it a little bit. It's going to be a little closer, and they'll do it again. And they do that trillions of times [chuckles], like, just an unthinkable number of times. And it turns out, if you guess the next word enough times, weird things start to happen. First of all, you get really good at being able to say plausible natural language. I'll say English because we're speaking English, but they do other languages as well. But, you know, you can give it a starting word, and it'll come up with a sentence that follows that word that's very likely. And that sounds pretty boring, though, right? Guessing likely English that doesn't sound particularly useful, except that there's this emergent behavior, because it turns out that if you get really good at guessing words, you're also kind of good at other things. For example, it can generate poetry. You say, "Give me a poem." In fact, I saw one yesterday. "Give me a poem about fourth normal form [laughs] and emotional." Well, actually, how was it described? "Emotional lyrics about fourth normal form."  JUSTIN: [laughs] MIKE: And it obliged [laughs]. And this particular example I saw yesterday, it was done by our frequent participant, Dave Brady. He then sent it to an AI music generator and had it generate a prog metal song based on it. And [laughter] it was plausible and super cringy. But you can do that by just guessing the next word. You can do things like knowledge base querying because, guess what? If you know some stuff, right, asking, "Well, what's the answer to this?" Well, if you know the next word, it'll tell you the right answer. And then you get even into more perhaps amazing things like multi-step reasoning, like arithmetic. If you're guessing the next word, you're going to have to learn to handle some basic arithmetic problems, and it learns to do that. And even more, it can do things like instruction following or tool use like, "Go write me some software," or, "Go" as we talked about a few weeks ago, "act as my agent to go take some actions on my behalf." And because it's going to do plausible, you know, believable things next, it'll tend to go do that. So, there's overlap. Where I'm going with this is there is overlap between fields of expertise, between domains of expertise, and sometimes getting good at one thing can help you in other stuff. I've tried for years in this podcast to connect concepts [chuckles]. It's something I try to do. I think it's useful for discussion generally. I especially try to do that with abstract concepts, you know, things that are hard to think about, try to connect them to very grounded things, very tangible things outside of software development. I think there's often more overlap than we might think superficially between things. Part of what makes us good at thinking as humans is that we make connections. We make those connections between different domains of expertise. We reuse knowledge. We repurpose knowledge. We take it from one area to another. And finding surprising connections, it's delightful; it's enlightening. So, AI is starting to show some of those things, some of those emergent properties, but, frankly, it's not very good at it yet. I mean, you have models that have read basically the entire internet, and now they can usually answer your question about the weather right [laughter]. We need to get better at this. But we're going to use our human skills, and we're going to talk about software-adjacent things that we do. This is a chance to go a little outside our normal boundaries and explore where there might be some overlap in things that aren't specifically software. As I said, I would like to start with Justin and hear about some of the things you're doing outside of specifically the software world, and what you've learned from them, and maybe...well, exactly what have you learned from those? Because I'm guessing it's going to be applicable. JUSTIN: Yeah. So, a couple of things that I am doing right now that are software adjacent. I don't know if you guys know, but I am a big enthusiast for electric vehicles. I'm inside my, you know, GE Chevy Equinox right now, fully electric. I love driving this thing around. I also like to ride around my electric dirt bikes. And if you haven't been on an electric dirt bike yet, it is a lot of fun. Instant torque. You can ride it in the wilderness without, like, scaring animals or annoying neighbors, all of those things. And the thing about the electric dirt bike, it is a platform that you can customize to your heart's or to your wallet's content. I particularly like Talarias. There's other ones like Surrons, and, I mean, there's a whole slew of them now. But with my Talaria, I got one of the xXx ones. But you can customize this, the base of this thing. You basically have a frame, a motor, a battery, a controller, and then, you know, a slew of other things, including brakes and other things. And you can swap them out. The important thing, though, is that your controller has to be able to converse with your battery, with your throttle, with your brakes, because you have regenerative braking. And if you don't have a controller that can talk to these other things and that can, you know, interact with them right, you aren't going to go anywhere. And it certainly is not exactly software, but it is software. The controller has a kind of a base level of software that you can go in and update and tweak, such that you can tell it to draw more power from the battery. You can tell it to output more amps to the motor, and you can tweak things like those such that you can go faster. You can be more reckless, all of these things. But if you don't understand the language of this controller, you can mess it up. And back in my

Mike opens with a post-apocalyptic “choose your team” trope to frame today’s job market for junior developers: brutal competition, few openings, and the need to stand out with real, survival-level skills. He shares examples like his niece (strong student, no offers) and Acima’s internship receiving 300+ applicants, then asks the group what actually helps new grads stay relevant and get picked. Will’s core message is: breathe—computers aren’t going away, but the industry is cycling out of a long boom and juniors are getting hit hardest. He tells his own dot-com bust story (gas station job, selling plasma) to emphasize grit and staying in the game. His practical advice is to stop relying on being “in the stack of 300” and instead get known: show your work publicly, connect with people, join communities, and consistently post demos/blogs/tutorials for 3–6 months so hiring becomes about recognition and trust—not resume roulette. The group zooms in on communication as the multiplier: resumes should be clean and consistent (attention to detail), but networking and clear thinking matter more than keywords. Thomas and Eddy stress becoming more social, asking “dumb” questions, and building presentations around questions to invite engagement—especially remotely. For interviews, Mike and Will flag dishonesty and hand-wavy answers as major red flags; they prefer candidates who can explain their process, own gaps, and reason out loud (even if they need to look things up). They close by pointing to AI as a near-term opportunity: write and build around AI tooling and “vibe coding,” because established companies are hungry for people who can help integrate AI into messy legacy (“brownfield”) codebases—while noting the job crunch isn’t only AI, but also macro factors like post-COVID pullback, rates, and layoffs. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With us, we have Eddy, Thomas, Will Archer, Ramses, and Kyle.   I'm going to start by...in the pre-call, we were talking about this. I'm going to paint a picture of a post-apocalyptic wasteland, and you've probably heard this story before. So, you got your standard post-apocalyptic narrative. Everything's terrible. You're alone, and everybody's dangerous. And you get a chance to take a couple of people with you. And everybody else might not make it, right, or depending on who you pick, you're not going to make it, as you have to cross through the hazards ahead. So, who do you choose? Who do you choose to go with you? And, you know, this is a common theme. It's a trope [chuckles]. It's a trope. You got to choose the right person.   And who you're going to choose is probably somebody with a particular set of skills [chuckles], and those particular skills...yeah, and I think that's a direct quote from a movie, but I'm not going to go with those ones specifically. You're going to look for somebody who stands out. So, are you going to look for somebody who's exactly like everybody else? Or are you going to look at the person, like, I know that they are super aware of their surroundings, and when the zombies come in, they'll alert me before they make it here, right? I would definitely pick somebody like that in the zombie post-apocalyptic future.   Or maybe you pick the tough person, right? Or you pick the person with deep knowledge of the plants and animals around, you know, who can forage for food. You're going to want to assess somebody who has skills that can help you survive. And there are going to be a lot of people who are going to have average skills, and they're probably fine. But you're going to want that person who actually stands out.   So, trope time over. We are in a world today where it is hard...and this is not just in software. We have a situation throughout many industries, actually, but it's especially bad in software, where if you're a new graduate, junior developer, it is...we've talked about this before [inaudible 02:37] crisis.   WILL: Apocalytic.   MIKE: It's apocalyptic, exactly.   WILL: Apocalyptic.   MIKE: Exactly. It's apocalyptic. It is.   So, I've got a niece who graduated, I can't remember now whether it's one or two years ago, and was, I think, valedictorian at their high school and solid near top of their class, I think, in college, lots of extracurricular activities. Brilliant, personable, kind of everything you'd want, hasn't got a single job offer [chuckles].   Another example: last year, we had an internship. We tend to every summer. I believe we had over 300 applicants for that role, and we got to pick, right [chuckles], which was great, and we had some great folks. But, actually, we brought one person from the year before. So, 300 applicants for one job; that's some serious competition.   And if you are going to try to get a job in this market, it...well, first of all, I'm sorry. We've talked about this before [chuckles] a few times, you know. It's...I feel for you. It's...this is tough. But also, you're going to...we'd like to talk today about what you can do. So, you're the person in that situation. Now we're talking specifically to these people in that situation, but it applies to everybody, right? We're all permanently in a situation where if you don't stay fresh, you're at risk, you know.   We're going to talk today about how you can stay relevant. How can you stand out? How can you be that person who gets picked so you don't get left behind for the, you know, for the apocalypse to claim you? Well, I've got some thoughts. We'll pepper the discussion with them as we go. But, you know, I'm just going to straight up ask at the beginning, you know, what do you all think? Do you have anything specifically in mind you think that somebody should be doing who's in that situation that you've seen work, or that you think would work, or you think doesn't work [chuckles]? What do you got?   WILL: So, the first thing I'd say is, like, everybody calm down. Computers are not going away. They're not going away. Nobody's phone is going away. Nobody is, like, nobody's unplugging servers. They're not going dark. None of this is happening. And I think, like, you know, we as an industry have gotten used to boom times for so, so, so, so long that, like, you know, finding out how the other half lives is, you know, an existential crisis for us. But, like, that's not to understate, right? Like, it is really bad out there, especially for junior developers and new grads and stuff like that.   I mean, so, from my perspective, you know, Uncle Will's story time. I graduated in 2001, right, which was pretty much the depths of the dot bomb, you know, economic pullback. I graduated with a degree in computer engineering, not computer science, computer engineering, right? So, it was the hardware engineering and stuff like that. I graduated first in my class, not top 10%, like the, you know, the spring semester, not the spring semester, summer semester. Well, anyway, whenever I graduated, like, I was the number one graduate from that thing. But I was like, I graduated from a terrible university, not a terrible university. It was a pretty good, small engineering school, Wright State University, go Raiders, in Dayton, Ohio.   I, valuing my life and sanity, wanted to get the absolute hell out of Dayton as fast as I could, which is a decision I have not regretted a single time in my entire life. But, like, I moved to Austin where I didn't know anybody. I had no connections, could not get a job anywhere for anybody, you know. Like, I was working at a gas station to make ends meet, right, because I had to eat still. I was working at a gas station and selling my plasma, right?   You guys stay in the game, and it'll be all right. Like, the people who are good are still valued. The people who are good are still needed. The people who are good are still not as common on the ground as you might be led to believe. It's still pretty tough to do this work, and if you're actually in here...so, like, if you've got the knack for it and you have the grit and the drive to continue doing it, you're going to be fine. There's still a seat at the table for you.   If you're out there for the bag, you know, maybe not. You're not going to make it, you know. They, like...it happened in 2001. It's happening again in 2008. It's happened over, over, and over, you know. There was a massive hiring boom from COVID. And, you know, like, if you're just in it for the paycheck, this work is just going to chew you up. The businesses, the industry is just not going to...you're not going to be able to keep up because the money is just not enough. And there aren't, like, any variety of worker protections in the business. There's nothing. There's no licensure. There's, you know what I mean, it's just, like, a random, maybe high school dropout in Bangladesh can take your job tomorrow, and that's just what it is. That's the literal long and short of it, you know what I mean?   So, it's going to be okay, guys, but, like, yes, there's going to be a cull, and if you lost your fastball or, like, you're just in it for the bag, or you're not really committed to, like, the thing, then, like, sorry.   MIKE: And, honestly, if that's where you're headed, you wouldn't be satisfied anyway [laughs].   WILL: No, you...yeah, you'd get out after, you know what I mean? Like, you're going to get out now versus getting out in five years, where it's just like, I just can't...I can't do another code review [laughs].   MIKE: Yeah. But a lot of us who love it, there's a reward in building things the way we do that, if you've been hooked by it, it's hard to let go of. And if you've got that and you're willing to put in the work, I agree with Will, you'll get there. But it might be a slog. I did not have great times back in that early 2000s era either [laughs].   WILL: Yeah, right? Yeah, it was a thing. It was kind of...it was kind of ugly out there.  

Mike kicks off with stories from his career to argue that SQL is a “never-goes-away” superpower. He describes early jobs where everything was handcrafted queries and good database design was foundational, then later roles where rapid growth made inefficient queries and missing indexes painful fast. Even with modern ORMs making raw SQL feel like a “code smell” in app code, he still relies on SQL constantly for investigating patterns, diagnosing anomalies, and answering urgent business questions in real time. His core point: avoiding SQL is like avoiding algebra or relying entirely on GPS—you can get by, but you’ll be weaker when you need real problem-solving power. Will pushes back with a reality check from big enterprise environments: many engineers simply aren’t allowed to touch production databases for security and scale reasons. He explains how, in those worlds, “SQL skills” get replaced by working through service boundaries—mocking/spoofing microservice requests and relying on managed interfaces rather than direct queries. Mike agrees scale changes access, but argues the underlying concepts still matter: relational thinking, knowing what’s expensive, understanding how data is shaped and retrieved, and especially understanding concurrency and locking at the database layer. They trade war stories about bad concurrency patterns (like incrementing an integer in a table inside nested transactions) causing real production pain, and riff on why older systems leaned on sequential IDs vs UUIDs due to historical CPU and memory constraints. The conversation broadens into “fundamentals change how you think.” Dave argues that specific jobs (like DBA roles) may evolve or disappear, but the principles behind them are evergreen—much like learning Lisp/Clojure or watching SICP to internalize functional, transformation-based thinking. Mike ties this directly to SQL as a declarative language: you describe what you want, not how to do it, and that mindset carries into MapReduce, streams, comprehensions, and even modern AI prompting. Eddy and Thomas add practical perspectives: ORMs can hide SQL until you need verification, debugging, or analysis—then SQL becomes essential (especially in support/data roles). They end by stressing curiosity and communication as the real career accelerators, capped by Dave’s interview story about spotting a SQLite aggregation quirk: the takeaway isn’t “memorize tricks,” it’s “stay curious, keep learning, and you’ll keep moving up.” Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, we've got Dave, Eddy, Will Archer, and Thomas. I think we're all return [chuckles] panel participants here. I'm going to jump into, actually, kind of a series of stories here, talk a little bit about my career. My first full-time dev job, all of our database queries were handcrafted. We did use parameterized queries; that was supported. But this is in the time before you had Object Relational Mappers, you know, ORMs, they call them now, before they were widespread. I'm sure they existed. They probably existed for a long time. It was before anybody really used them. The leader of my team cared a lot about data, and we focused a lot on good database design as the foundation of our work. We always kind of started with the database and then modeled way up. It's a common way now, isn't always common. You can tell when people don't do it that way. He even discovered a bug in the PostgreSQL adapter for Java and submitted a patch to the project, so, you know, it was a thing. Those were both kind of new tech at the time, so [laughs] times have changed. At the time, I hadn't really done much with...okay, now here's a pause. You can call it SQL or sequel. I don't care. And I'll probably call it both in this conversation. It's a debate with no clear answer, and it really doesn't matter, so...[laughs] DAVE: It's a debate with no clear need, right? MIKE: Yeah. DAVE: Because if I say, "Sequel" and you say "SQL," I know what you meant. MIKE: Yep. So, I hadn't really done that in school, so it was this interesting new tool to learn. It's this language that's oriented around relational algebra instead of implementation details like loop counters or sorting algorithms, right? And different's fun, right? It's the cool thing. Wow, this is a different way to think. It was more than that, though. I got to...I enjoy...I started to, and I still enjoy thinking about problems in terms of a series of transformations on data. We could probably talk about that. I think it's a big deal. Sometime later, that company had been acquired. I ended up spending months just writing queries, like, all day, every day to drive reports, to make them efficient, to run quickly, so many queries. Probably wasn't the best way to do things, but it's what we did. I wrote a ton of queries back then. You know, at a later job, I've probably mentioned this before, our traffic grew 100x in a year, startup, right? And we were working with publishers. So [chuckles], we grew really fast, but it meant that anything inefficient became a bottleneck really quickly, like, weeks. Within weeks, a thing that worked great doesn't work anymore. And so, I added indexes to tables I don't know how many times. I added external indexes for full-text indexing, like twice. We did it once, and then that tool failed, so we did another one. Designed a new database schema for arbitrary web content, you know, wrote the queries around it. We even had a little micro language for publishers to use. I didn't originate that, but it was something we worked with to query their data into their pages. It was queries all the way down. It was just queries is all we did. Later, we built a data warehouse that powered, you know, analytics for our users, and, again, SQL [chuckles]. In recent years, those Object Relational Mappers, or ORMs, they've gotten really good for web development, right? I mean, it's the standard. And I'd say that using raw SQL in production code there's usually a smell nowadays. And I've been a lot less hands-on in the code for several years now, but I query the data warehouse all the time. Just in the last few weeks, a couple examples, I've pulled stats on historic traffic patterns and all sorts of configurations. I don't know how many times I've run the query, tweaked, to let us know what to expect for seasonal load as we went into holiday season, lots of shopping. I think it was last week with a group of people in a conference call. They're all watching me live coding, one of those make you sweat experiences. But, you know, I wrote this fairly complex query to show the average daily time between merchandise, like a customer choosing to get the merchandise and when it got shipped, and to show that a big vendor, that I'm not going to mention, was temporarily delayed. And so, this anomaly we saw in our system, because they had a big impact on us, was external and not a problem in our stuff. You know, live coding is always a little dicey, but it worked. And, fortunately, I had done this kind of thing before. This is all to say, knowing Sequel, SQL, call it either way, is as important to me today as it was at the start of my career. You know, way back then, like, wow, this is an important new tool I need to learn. And I'm still using it as much today as I was back then, and it just hasn't changed. It's still important. I haven't written Perl in decades, I don't think [laughs]. Anybody remembers Java applets? [laughs] DAVE: Yes. Wow. Yes. MIKE: I could talk for a long time, right? We could make a whole episode on dead or unpopular tech that was once a thing. But SQL, it hasn't gone away. Getting data out of a database is just this critical skill that never goes away. So, today we're going to talk about Sequel, or SQL, as kind of a superpower. You can get away with not knowing it now for a long time because you've got good ORMs. You've got visual query tools. You've got, like, the Business Intelligence Team they provide queries for you. But based on my own experience, I think that avoiding learning it it's like never learning algebra or never learning how to plan a route without GPS. Like, you can get by without it for quite a while, but you'll have so much power to solve problems you couldn't otherwise solve if you learn the amazing tool. WILL: You know, like, I love that, and I have, like, a similar...I have a similar arc. But as I was listening to it, I was thinking about, like, well, when's the last time? So, I mean, I'll just say, right, like, I think you have a unique and privileged position in that, like, you are allowed to run SQL. Most folks aren't allowed. You don't get to run SQL. And I thought about, like, what I had sort of replaced those SQL query skills with. And to be perfectly honest with you, like, you know what I mean, because I'm working for, like, big boys, like, you know, like, I went, you know, I worked with you guys at Acima, and Acima's not small. And then I went, you know, an order of magnitude bigger someplace else. And I went another order of magnitude bigger at someplace else. And, like, you don't run SQL. Like, I'm pretty, you know, I'm pretty up there. I'm a software architect II, you know, which is pretty, I mean, it sounds cool, right? There's a cool sound. It's got a cool sound to it, you know. They trust me with some stuff, but, like, I don't get in that database, never, never, ever. And, like, you know, and so, like, you know, you could do that, but I'm not allowed to do that. But I have all these tools, and I love SQL. And it would make my life a lot easier if I could do it some of the time. But I've kind of replaced SQL with microservice request spoofing, you know what I mean? Microservice request spoofing kung fu, in that, like, I can invent an entire data layer out of whole cloth and just be like, you're talking to them. And my application'

The episode opens with host David Brady introducing a panel to talk about recent advances in AI, kicking off with “story time” from Mike. Mike describes how massive investment has accelerated progress and uses a hotel analogy to explain the shift from traditional AI tools (you ask for a specific thing and it does exactly that) to agentic AI (you describe a goal like “I’m cold,” and the system takes multiple independent actions to solve it). The panel frames this as a major interface change: instead of issuing step-by-step commands, you collaborate with a tool that can plan, execute, and iterate—powerful, but also riskier if it takes the wrong initiative. They then ground the idea in practical software work. David describes using an AI agent to scan a large, messy, decade-old Rails codebase for dead or “zombie” code—surfacing unused files, routes, and even database tables with no activity since years ago—while also noting how the agent can misunderstand intent (e.g., trying to “fix” missing controllers instead of removing obsolete routes). Justin and Matt extend this into security and ops: combining logs (like Datadog/WAF), an OpenAPI spec, and code access—potentially via MCP (Model Context Protocol)—to identify unused APIs and shrink attack surface. A recurring theme is that agents excel at tedious grunt work (grep-style hunting, bash plumbing, awk/sed, git forensics), but they still require review, guardrails, and clear instructions. The conversation widens into “AI fluency” and human factors: prompt skill matters, “prompt engineer” is treated as a real craft, and vague requests can cause agents to take unhelpful liberties. They discuss personality differences among models—sycophancy and overly affirming behavior versus more nuanced ethical reasoning—and how that can affect users, sometimes dangerously. The panel debates whether software creation will move toward natural language: some argue English is too ambiguous for precise specs (hence lawyering), while others think we’ll keep needing discipline and precision even if interfaces get friendlier. They close by flagging major risks—unattended agents with broad permissions, security exposure, and IP leakage—and tease that AI security and governance deserves a full follow-up episode. Transcript: DAVID: Hello and welcome to the Acima Developer Podcast. I'm your host today, David Brady. And we have got a fun panel. And we're going to talk about advances in AI today. Today we've got…on the panel, we've got Kyle Archer; we've got Mike Challis; we've got Eddy, who's down in Mexico now. That's awesome. We've got an AI bot who I'm pretty sure is our coworker, Justin. You're elsewhere now, aren't you? JUSTIN: Yes. DAVID: Yeah, awesome. Well, I mean, it's terrible for us [laughter]. We've got Will Archer. We've got Van…well, you go by Thomas, don't you? Wilcox and Matt Hardy. And this is going to be a good, good show. We always start with story time with Uncle Mike, and I'm not going to break that trend. It's great because Mike did not say in the pre-call that he had a story ready. I'm just putting him on the spot. MIKE: Well, I've been grappling with how to think about or how to express the changes that have happened in AI over the last few months. And if you put, you know, like, hundreds of billions of dollars into something, it's going to tend to move, and that's happened. DAVID: Something will happen. MIKE: There have been amazing, amazing level of money, like, shocking levels of investment in AI. And I'm sure not all of it will pan out, and we'll probably touch on that a little bit, but some things already have. And there are new ways of doing things that didn't exist, like, a year ago, in, you know, any meaningful commercial format. And one of this is this agentic approach to AI. And I've been trying to think about how to express this. If you're like me, you've been to a hotel. And if you have kids and you go to put a bed on the…sorry, some covers on the fold-out bed out of the couch, and you're like, oh, wait, there is no blanket here. I'm not going to have my kids sleep on the springs. And so, you know, you call into the desk and say, "Hey, can we please have a blanket?" Or you walk down there and ask for a blanket. And they'll bring it to you, right? And they'll bring it to you. It's part of the service, and it's covered. But it's very much, I am going to ask you to do this, and you will do it for me. And that's how AI tools have been up until fairly recently. But there's been a change. Now they've got these agents, and so it's more like you call in and say, "I'm cold." And they say, "Okay," and a few minutes…well, maybe actually more like an hour later. It takes longer [laughs] [inaudible 02:43]. You know, they show up with, like, an electric blanket and a comforter. And they go over, and they raise the temperature in your room, and, like, “Oh, this is how you use the thermostat,” because it is taking actions independent of what you asked it to do. You express the parameters of what you'd like to have happen, and you're allowing the agent to take action on your behalf. Now, it could be you say, "I'm cold," and they send up, like, a therapist and say, "So, we hear that you're having some emotional distance. What can you do for me," right [chuckles]? Or they turn up your thermostat to 100 degrees, and maybe they say, “I’m a paramedic.” You know, there's risks here that you didn't have before, but there are also benefits. And, hopefully, you're going to have the foresight to be clear enough to try to express, I am cold because the temperature in my room is low, and I don't have a blanket. Can you help me out? And then you get some of the things that you need. You notice that there's some prompt engineering there, where you're trying to express your needs clearly, much like we've always done in programming, in software, where we have to be explicit because there's ambiguity in language. But you get different results than you got otherwise, and that's introduced a whole new set of things, this agentic AI. And I think that that's a lot of what we might end up talking about today. DAVID: I absolutely love that. We had a brief chat before about, like, the things that we are getting into. And my favorite take…I remember trolling YouTube or scrolling YouTube when the agentic thing first started hitting. Like, all the viral, you know, content generators out there were starting to talk about it. And they were talking about it back in GPT 1 or 2 era. And they were like, "You can do this with any LLM, and you do it like this." And the lady who was talking about this literally said, "I'm going to give you this task, but I want you to approach this from this stance." And then prompted it again and said, "I want you to take a skeptical stance to this person's argument. Okay, that's fine." But then she ran it again and said, "Back to you, first person. Address the concerns." And, obviously, if one or both of them hallucinate, it's just going to go off the rails even faster. But there's something about the way agents work that kind of keep themselves on task a little bit. And so, you end up with the ability to artificially expand the context or the thinking of the AI by just chunking it over time, right? I'm going to make you think on this part of the problem, then this part of the problem, then this part of the problem. And now, like you're saying, Mike, the agentic stuff, where you fire up Claude Code or Copilot, and you just say, "Go work on this," and it just keeps identifying tasks and working them and identifying tasks and working them. MIKE: So, what kind of tasks. DAVID: Right? So, actually, that's a good point. I just realized we talked about this in the pre-call. It's new to our listeners. One of the things that I'm working on right now is scanning for dead code in the codebase. So, we've got a very large codebase. It's very complicated, and it's a 10-year-old codebase. It's what programmers do. We create these things. And taking AI and sending it in there to go look for code, and it's literally coming back…It's coming back with files and saying, "I don't think anybody talks to this. There's a database table connected to it, and I don't think anybody's writing to it." And you go looking, and it's like, oh yeah, the last insertion there was in 2019. And then you start going, wait a minute, I remember this initiative. I remember working on removing this initiative. This absolutely is a file that got missed. And then, of course, AI being dumb, of course, it then says things like, "Well, you left this route in, so you need to go write the controller." And I'm like, no, no, we removed the controller. Try to catch up. We want to remove the route, not the other way around. MIKE: So, you're expressing a problem that we all have. My codebase isn't as clean as I would like. And, specifically, I want to find code that is not being used right now. Help me out [laughs]. And this agent will take initiative and go and identify those pieces and inform you about them. DAVID: And think about the individual tasks involved, right? Like, how do you tell if this file is unused or this symbol is unused, right? Well, we're going to scan the codebase. We might, if it's Ruby, we might look around for sends and evals that have that string near it. There's [inaudible 07:07] different ways, right? It's like, if this symbol is here, do we have any of the methods getting called? And it's more than just grepping, but even if it is just grepping, you have to teach an AI, this is how you go grep this codebase, right? We all tell Copilot to do a thing. And it says, "Well, first, I'm going to do, you know, I'm going to look at the first 20 lines of the code files in this directory." And it's just simple, little bash stuff that you and I could do at a terminal. That's literally what AI is trying to replace is just the mundane grunt work. JUSTIN: Yeah. So, I want to div

On this episode of the Acima Development Podcast, Mike hosts a large panel discussion about balance in engineering and why extremes tend to hurt teams. He opens with a cycling story about staying upright on a narrow strip of packed gravel, using it as a metaphor for finding the “middle path” instead of letting the pendulum swing from one extreme to another. The group quickly agrees balance is everywhere in work, from meetings to planning to personal wellness, and the question becomes how to recognize when you have drifted too far. Meetings become the first concrete example. The panel talks about how remote work made it effortless to invite too many people, schedule too often, and fill calendars until there is no time left to actually build. They debate what “enough” meetings looks like, noting that too few meetings can also be a problem when people lose context, alignment, or a clear understanding of priorities. Ideas include limiting meeting size, setting blackout hours for individual contributors, using short meetings with tight agendas, and treating unclear requirements as a sign to pause work rather than plow ahead. From there, the conversation shifts into sustainable pace, velocity, and measurement. Will and Dave share stories about burnout, crunch time, and how more hours do not necessarily translate into more output, especially when fatigue just pushes life admin and distraction into work time. Alfred and others extend the metaphor with cadence and “gearing down,” arguing that there is an effective operating range where teams move fast enough to be productive but not so fast they break. The group closes on the importance of self-assessment and metrics, like blocked focus time, screen-time signals, sleep, and other indicators that you are drifting, so you can correct early and keep the long-term trend line healthy. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. I have with me Kyle, for the first time, Alfred. We've got Will Archer. We've got Dave. We've got Sam. For the first time, Thomas, and also, for the first time, James, and Jordan. Those of you listening, you can look in the notes if you want [chuckles] any details. But we're all here to have a conversation on a topic I've thought about for a long time, and I thought today was a good time to bring it up. And, as usual, I'll introduce it by bringing up something outside of software. I've mentioned this a few times: I've done a lot of cycling in the last few years, a few reasons for that, but I've really enjoyed it. It definitely leads me to think a lot about balancing [chuckles], and actually, I don't think a lot about it because that's the thing about being on a bike. If you don't have the internalized idea of balancing, you don't stay on the bike. So, very quickly, as you learn to ride a bike, the balancing part becomes so internalized you don't think about it because that's what riding on a bike is, is keeping balance. You don't lean too far in either direction. Bad things happen, or it changes your control, right? It sends you in a direction, and you want to choose to do that, not do it by accident. I was thinking about this a lot, actually, I've thought about it off and on since a ride I went on earlier this year. I went to a hilly area in northwest Illinois, and it goes up into Wisconsin, and Iowa, and Minnesota. There's a place called the Driftless Area, sometimes it's called The Driftless. And it wasn't glaciated in the last Ice Age, and so it's very hilly, unlike what you normally think of when you think of the Great Plains, because it's not the plains; it's the hills [laughs]. And it's really pretty, really pretty area. In the summer, everything's lush and green, well, pretty anytime. But I was there right at midsummer and was climbing up a hill where they just...I looked at it on the map [chuckles]. I had not been there. I climbed up this steep, long gravel hill, and they had freshly laid soft gravel on it. That is hard on a bike, I'll have you know [chuckles]. It's hard on probably any vehicle, but especially on a bicycle. And, honestly, I couldn't make it up the soft gravel, except where I followed a tread where a vehicle had been up ahead of me. But that meant that I had about six inches of room to ride in, and if I went to one side or the other, I was stopped. I was hard stopped. I'd get off the bike, walk to a space that's a little flatter to get back on because you're not going to get back up on the gravel. And I've thought about that a lot since, you know, following the middle of that line is the right way. And there's lots of things in life, including in business, where we have a tendency to ride a pendulum. We swing to one side, then we swing to the other. We'll even add some moralizing to it, saying, well, if a little of something is good, then more is better, right? So, let's go really far that way. And that pendulum swing is often not very healthy. There's an alternative approach to seek for the appropriate middle path. There's a long philosophical tradition here. I'm not going to go into it deeply for the podcast. I'll say, many wise thinkers have found that seeking for balance is better than pursuing an extreme. You want to stay in the lane in your car? You want to balance your bike? You want to keep a canoe upright? You want to spend within a budget? You want to walk? You want to eat properly? The need to balance the system is all around us. So, how does this apply to software engineering? What are some things that we should actively keep in balance rather than going to extremes? I've got a list written down. KYLE: Meetings. MIKE: What's that? Meetings. Okay, let's talk about meetings. Please go deeper. KYLE: When your calendar is meetings all day, you can't get anything done. But a meeting to get onto the same page on a task, I mean, that's really needed. But I feel like, at some point, especially as a company grows, you're in meetings all the time. And rather than using other, you know, communication methods, which for some reason we kind of grow out of those, it kind of feels like, rather than defaulting back to those quick communications either over chat or in person, a lot of the time it's, "Hey, can we have a meeting?" before we even try any of those quicker approaches. Give me an email. MIKE: So, how do you go about balancing that? How do you find that sweet spot? WILL: I miss the days when you just kind of got it for free. Because if you had to book a meeting room, there's only five meeting rooms, so you better need the meeting room. You know, like, you couldn't just be like, "Oh, hey," like, I mean, think about right now, I mean, I haven't seen the new Acima office. But I saw the old-new Acima office. And if we needed nine seats to hang out at the old-new Acima office, it would be not impossible, but, like, certainly an ask, you know. But now it's just sort of, like, I could be in two meetings right now. Like, literally virtually occupying, like, two meeting rooms as a headless, you know, muted entity right now [laughs]. MIKE: Why stop at two? [laughter] DAVE: Yeah, there's only three numbers in computer science, and you have reached many [laughter]. MIKE: Yeah, it is hard to control. It's something that the pandemic threw all of us into, and we're still swimming in it [chuckles]. WILL: I don't know. I mean, you know, this is just dreaming or whatever. But, I mean, I feel like...I'll make a little pie in the sky, like, dream. Like, what if based on your level, right? Like, the organizer of the meeting can only invite so many people, right? So, if you're, like, you know, like maybe, like, let's say, like, an individual contributor, you know, senior and below, you're going to have a four-person meeting. If you want between four and eight, you need to get your manager. If you want, like, 10, you're going to have to get a director or whatever equivalent, you know what I mean? But, like, you can't just have meetings like that. Like, if somebody wants 20 people in a room, they may need to have a certain level of seniority to make that kind of demand on that many people's time. MIKE: Something [crosstalk 06:46] to that. WILL: And if you needed that many people in a meeting but you don't necessarily have the seniority to, like, command it, you probably should write it down anyway [laughs]. MIKE: There's the pizza rule that people have talked about, you know, as many people as can eat a couple of large pizzas is the maximum you're allowed to have in a meeting, some of those rules of thumb. But if we're not all meeting, and this is true...even in offices where most people are in person, you're going to have that contractor, right? Or you're going to have the person...I was in a meeting today with somebody who is laying in bed with serious back pain, [laughs] and technology lets them be in the meeting. Otherwise, they would not be in the meeting. They would just be in bed. So, you know, it's great, but you have to recognize that there's going to be people who are going to be there virtually. And so, it makes it really easy, like, oh, I can throw 100 people in here. It's really easy to throw people in. And I think that that's a muscle that we need to start flexing [chuckles] more than we have. WILL: I mean, if I'm being totally honest with you, like, I think individual contributors should have blackout hours, you know, like, blackout hours. I know a lot of people...I've been in many offices where they're, like, "We're not having meetings on Friday." I don't love that one because I'm still, you know, it's like you're sort of, like, waving the white flag on an entire day, and I got stuff to do, man. But, like, company-wide, like, individual contributors, like, two-hour block, where it's like, no, no meetings. No meetings during these two hours. You have to get some work done sometime, don't you [laughs]? MIK

The episode centers on miscommunication—why it happens so often and how to handle it better, especially in remote work. Mike opens with a story about baking baguettes for his in-laws: he and his wife look at the same “thin and crusty” loaves but interpret that comment totally differently. He thinks she’s critiquing what he intentionally made; she’s trying (poorly) to request thicker, softer loaves for garlic bread. Only when she circles back and explicitly explains what she meant do they align, adjust the next batches, and get the bread right. That small domestic example sets up the theme: communication is hard, assumptions are deadly, and clarity requires deliberate effort. From there, the group digs into remote work realities: cameras on, clear signals, and good tooling. Kyle and Will argue hard that turning on video dramatically reduces miscommunication by adding facial expression, body language, and a sense of shared humanity and accountability—especially across locations, time zones, and cultures. They rail against “Helen Keller mode” (muted, cameras off) and the bloated calendar of half-attended meetings that results when people aren’t fully present. They stress being “remote-first” even in hybrid environments, using the right tools (Slack vs. Teams vs. Jira/Confluence), and leveraging things like transcripts, screen recordings, and diagrams to convey ideas. Visuals and written records aren’t just nice-to-haves; they’re how humans actually process information and how teams keep “receipts” for decisions and responsibilities. The conversation then shifts to practical tactics for both preventing and repairing miscommunication. Preventatively, they recommend restating what you heard (“So what I hear you saying is…”), insisting on written decisions, documenting problems with specifics (what you did, what failed, error messages), and always answering the who/what/where/when/why/how when assigning work. Rich PR descriptions, Jira tickets with a clear “why,” and AI-assisted meeting summaries all make future understanding and debugging much easier. When miscommunication does happen, they suggest treating it like a production bug: regulate emotions first, acknowledge the other person’s experience, look for root causes rather than blame, and focus the discussion on “what happened and what do we do about it now.” They close with a quote: “The void created by the failure to communicate is soon filled with poison, misrepresentation, and drivel,” underscoring that silence isn’t neutral—if you’re not communicating clearly, you’re inviting confusion and distrust. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I've got, as usual, Will Archer. Welcome, Will. We've got Kyle, and we've got Jordan. Thank you for joining us. And we have a topic to discuss that's been on my mind. It's...yes, stuff has come up lately, but stuff comes up always on this topic. In fact, outside of work, something came up for me today [laughs]. I'm going to my in-laws tomorrow. I'm getting a family get-together. I get along well with my in-laws, so this isn't, like, a bad scenario [laughs]. It's an okay scenario. But I am bringing bread. We're having lunch, and I'm supposed to bring the bread. We're going to make some garlic bread. Anyway, so I was thinking, a couple of weeks ago, you know, I want to make baguettes. I love crust on my bread, so I want to experiment with that. So, I was making some baguettes, you know, baguettes are long and skinny. That's their thing. That's why you do them because it's crusty. And I was going to make three batches to take to my in-laws: sourdough, a white bread, and whole-grain bread. And I had made the sourdough one, and I had made a test batch earlier in the week. And this batch came out fantastic, exactly how I like them, because I like crust on my bread. I've been that way since I was little. I love crust on my bread. I love a crusty, you know, the more crust the better [laughs]. I love a crusty bread. So, baguette is perfect because, you know, it's so crusty: so thin, you know, thin loaves, lots of crust, love it. And I talked with my wife about it earlier in the week. She's, like, "Yeah, that's the kind you like. I like the bigger loaves because they're chewier in the middle." But she had some of the crusty ones, and she liked those, too. I kind of forgot about that conversation, and I went to make some bread today. I'd, like, raised overnight, got to the bread today. This is going somewhere [chuckles]. This is going somewhere. So, I made the first batch as a sourdough one because I'd let it raise in a warmer environment because sourdough takes longer. And they came out of the oven. And I put it up, and my wife looks at them. And she's, like, "Those are some really thin loaves [chuckles]. They're thin and crusty." And I looked at them, and I thought, yep. I think that's what I said [chuckles]. "Yep, they are. That's exactly what I was going for." And, in my mind, I thought, yeah, that is true. That's what baguettes are supposed to look like, and that's what I did. And as I was thinking about that, like, "Why are you even saying this? Are you thinking that I'm doing something wrong? Because [chuckles] I know you kind of like bread a little softer, but we're supposed to be having small loaves because we're going to be making garlic bread." So, my mind was running, and her mind was running as well because she was thinking, why did he not say anything? So, what she was thinking was, those aren't the loaves that I want. I want to bring bigger loaves. And what I was thinking is, yeah, they came out exactly the way I wanted them. So, two totally different perceptions of this conversation. She came up to me about 15 minutes later, and she says, "You know, I was talking to you a few minutes ago, and I said that those loaves were thin and crusty. Did that come across as an attack?" I'm like, "Well, no, not really [chuckles]. But I wasn't sure what it was." And she said, "What I was trying to say is that I want thicker loaves. I want us to bring loaves that are bigger around so that they're less crusty, softer on the inside." Like, oh, okay, so that's what she wanted. When she was talking about the bread, what she was trying to communicate is, how about for those other two batches you don't break it into three loaves but you break it into two? But that was not explicitly mentioned by either me...I didn't restate anything. Like, I didn't do anything to clarify. And her expression, you know, what she had said to me was true on its face, but didn't give me any information. So, neither of us had done anything to improve the communication to get to the outcome that I actually wanted to get the right bread over to the in-laws. But she came back to me. She followed up, and we coordinated. I made the second batch already during lunch. They came out beautiful, these gorgeous loaves. I almost want to take a picture and post [laughs] it with the podcast because, oh yeah, they came out really good. And the last batch I'm going to do this evening afterward. Everything worked out great because we got together to clarify and figured out what the exact requirements were. We went back and forth. I repeated, "Okay, so you want a bigger loaf. Do you want, like, one big loaf, or do you want two?" And we coordinated. So, she didn't want one really big loaf. Two was just about right. We tried it. It came out just like we wanted. The topic today is about handling miscommunication. There's an example from just normal life today. We've all had it. We've probably all had it today because this happens all the time. And if you're working with any other human being, it's happening all the time because it's hard. Communication is hard no matter what. Every time I try to talk to people, or if anybody tries to talk me, if somebody tries to talk to me, it's hard to get things right. And when you're working with people overseas, so they have different time zone, different culture, it gets even harder. There's all kinds of things that make this communication harder. And I want to be tactical for our conversation today. What can we actually do? And I've got some notes written down because I've got some ideas. And I'm kind of, like, in our overall, you know, look at the big picture of the map of our journey. So, I'd like to talk some about what you do before you make a decision so that you can avoid miscommunication in the first place, and then also talk some about, like, okay, miscommunication has happened. What did we do to deal with it? KYLE: One thing I've found...because, at Acima, it was very much, you know, you were talking face to face for the most part, and granted, miscommunication happens there. But when the Acima folks, which are located in Draper, when we started interacting a lot with the Rent-A-Center folks over in Texas, I ran into a lot of miscommunication. And I found that a lot of that was because of virtual interactions. And there was one button, be it in Slack or Teams, that really helped me, and that was the video button. Turning on, giving them my mugshot, just so that they could see me, and I could see them. Like, there's something about facial interaction, or, you know, yeah, facial features, and what you're doing as you're communicating. And being able to kind of read lips as well, I think, really kind of helps at least me. And that cleared up so much of the miscommunication that I was experiencing when working with the other guys, like, just that. WILL: Oh my God, yes. MIKE: [laughs] WILL: Oh my God, yes. I do not, so, like, you know what I mean, like, I, you know, consultant, hired gun, wandering samurai, you know what I mean. And I don't have the latitude to, like, rule with an iron fist in ways that I miss dearly. But I have no idea, no idea how people who manage distributed teams have allowed the r

On this episode of the Acima Development podcast, the crew leans into a Halloween “code horror” theme, using real-world stories to explore the scariest things they’ve seen in software. Mike opens with a literal horror from homeownership: a drain pipe so clogged with roots it had become a pipe-shaped root sculpture, a perfect metaphor for an ancient 3,000+ line Rails controller crammed with overlapping workflows, unclear entry points, and so much tangled logic that a junior engineer couldn’t ship a single change in months. That sets the stage for an episode about legacy systems, complexity, and the way neglected codebases slowly turn into haunted houses you’re afraid to enter. From there, the hosts trade progressively more terrifying war stories from their careers. Dave recalls a nightmare installer project where he had to write Pascal inside InstallShield to find and kill a running Rails process on Windows using SQL against the process table—an absurdly convoluted solution that nevertheless shipped and worked. Justin shares high-stakes fintech deployments where downtime cost millions per minute, quarterly release windows created brutal pressure, and failed rollouts meant rolling back three months of work. Kyle talks about discovering hard-coded secrets and shared keys scattered across repos, unrotated for years, then being told to fix and rotate them all “by end of day” with almost no historical context. Mike adds tales of a reporting system literally built on SQL injection, “fixed” by an enormous hand-rolled SQL builder that was later thrown away, and a credit card gateway acquisition where an injection flaw had already been exploited to steal over a million dollars. The horror then zooms out to systemic and operational failures: clickstream data sold by ad blockers that can easily de-anonymize users, HIPAA-reportable incidents that nearly trigger federal oversight, and outsourcing critical code to poorly vetted contractors only to see entire codebases appear on the dark web. They dig into how floating point differences between systems can change financial reports by a few dollars, how time zones and users changing their device clocks can break “simple” expiry logic, and how massive vulnerability scans can surface tens of thousands of “critical” issues across hundreds of repos. Add in AWS us-east-1 outages that turn disaster recovery plans into live-fire drills, layoffs that leave one engineer alone with a mysterious legacy system, and useless commit messages like “test” repeated 50 times, and you get a grim but funny campfire circle for engineers. They close by emphasizing the real moral behind the scares: every one of these stories carries a lesson about security, architecture, and process, so listeners can learn from others’ hot-stove moments instead of burning themselves the same way. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I have Justin, Dave. DAVE: Save yourselves. MIKE: And Kyle. And -- DAVE: I just realized this is not going to come out on Halloween. MIKE: [inaudible 00:37] DAVE: We are recording this on Halloween. MIKE: Exactly [laughter]. Well, that's what I was about to say. DAVE: Oh, sorry. MIKE: You're going to probably hear this in January, but we're recording this on Halloween [chuckles], Halloween of 2025, and so we're in a spooky mood [chuckles] with the Halloween theme. We're going to run with that, and, as usual, I wanted to connect this at least a little bit to something tangible. And what I was thinking of is, a couple of weeks ago, I was cleaning out a drain pipe. So, I've got a downspout from my house, and it goes into a perforated drain pipe that runs out to the edge...well, near the edge of the yard. So, when it rains, the water goes out near the edge of the yard rather than going down next to the house and going to the foundation. The problem is water was not going down the pipe, and [chuckles] that wasn't good. We tried to figure out why and noticed every time it rains, water is coming out the top of the pipe...at the bottom of the downspout rather than going up the other end. So, we ran a pipe snake up the end of the pipe, thought, okay, there's probably something in there, and gave it several tries. But one of the times I pulled, like, wow, that's really stuck in there, and I pulled it out. And I pulled out, like, a several-foot-long length of root that had fine roots shaped around the inside of a perforated pipe. It was [laughter] a very interesting pipe-shaped root. Oh, that's interesting, kind of creepy looking actually [chuckles]. This strange thing reminded me of an image I saw of some blood that somebody [inaudible 02:08] from a lung, you know, this very twisted intricate thing. And that still didn't even begin to get all the roots out of it. We were, like, oh, you know what, this is not going to work. Eventually, I just tore out the whole thing, threw it away, and replaced it with a new one because it was not going to work because that tangle of roots apparently had not been cared for for a long time. Where it had been, we'd had a bush, a weigela bush, that had grown unreasonably large for its location. Why did it grow so well in that spot? The light's not very good. It's very dry. Well, now I know why it had done so well [chuckles]. It had filled that pipe with roots. And the bush isn't even there anymore, but apparently it left the roots behind, and it's gradually, like, silted in and was just totally clogged. Water was not going through. I guess when you leave something to get tangled for that long, eventually, you end up with just this spaghetti that won't allow anything to be accomplished through that pipe. Not serving purpose anymore. Which leads me to an example [laughs]. Some years back, I was doing Ruby on Rails, and we had a Rails controller, and I don't remember the exact length, but I remember it was over 3,000 lines long in a single file. And there were multiple competing workflows all implemented in the single Rails controller. It just kind of did everything in that general area of the code. And, like I said, there are multiple competing ones. I think they're both still active depending on, like, what version. I don't even remember what exactly...how you got in one or the other. And, you know, you’d go into the one and, in the frontend, it would send you to another. And you had to know the details of the template to know how which action got called in the controller because of course it had, like, a hundred methods. It wasn't clear at all which ones should be public, which ones shouldn't be public. I put a junior engineer on that once to try to accomplish something. After a couple of months, they hadn't got a single PR out, and, finally, we just gave up and had them work on something else. JUSTIN: I've done that [laughs]. MIKE: I regretted sending them in there, into that dark cave, entangled and twisted, which is our introduction for our theme today. As we've already said, we're going to talk about the horrors that we have seen in code. And we've got some people who've been around for a while [laughs] and have seen some things. I started with my story, but, hopefully, I think we've got enough collective experience there to see all kinds of things that will scare you. So, what are some scary things that you all have seen in code? I've got a list, but I'll just sprinkle them in as we go. DAVE: I think a lot of these they can go in interesting ways, right? For me, the most horrifying code stories aren't the ones where you go in and you find a mess that somebody else made, you know, some cavalier cowboy, I mean, those don't scare me. They just make me mad [laughs]. The code that makes me just shake my head in wonder is often code that succeeds, code that actually works. So, I will tell a quick story. My story for this is my very first Rails programming job. I wanted to be a Rails programmer. I was doing a ton of PHP, which I hated. I was doing Perl and Python on the side. And I was getting into Ruby. I really liked Rails. And a guy called me up and said, "Hey, do you want to da da da...?" I'm, like, "I mean, if I can work in Rails, if can do it in Ruby, I will." And he's, like, "Sure". So, he puts me on a project. It's a Windows .exe file. So, you have to install it with Windows with install.exe. And we wrap up the Rails OCI. That was the one-click installer. This was an .exe file that you could run way back when. And it would give you Ruby and Rails and everything you needed to run a Ruby on Rails site on Windows. This is, like, 2007 era. So, I mean, this is actually significant, right? I mean, this is...we're playing games with, you know, like, Tomcat Manager and all that good stuff, and this one didn't use Tomcat; I think it used Postgres. But you get the idea that it was managing the whole stack. And I got given the job of updating the installer to chain either to add a gem...I think we wanted to change the Rails version. And the project was new enough－it had been out for a year or two－that we had never upgraded Rails. So, [vocalization] how hard can it be? I'm programming in Rails. So, I will skip a long involved, headachy story. But what I ended up with was the installer is written using InstallShield. InstallShield is written in Delphi, which is Pascal. So, I wrote a Pascal program to go into this installer. That Pascal program then, when you run the installer...by the way, sorry, I left out the most important detail, which is when you run the reinstaller, it will fail if Rails.exe is already running. So, I have to go look for it and tell it to shut down. It's just, like, I'm going to, you know, click here to kill the Rails process and restart, right? That kind of thing. So, that's what I have to do. And on Linux, you just PS and grep the table. On Windows, there's a thing called the system process table. This is 20 years ago, so I

On this episode of the Acima Development Podcast, VP of Engineering Elishia Williams joins Mike, Dave, Will, and Kyle to talk about her path from curious kid to technology leader—and the lessons she’s learned along the way. Elishia shares how her dad first sparked her love of tech by putting her “in charge” of maintaining the family computer, a moment that planted the seed for a lifelong career in engineering. As a woman in a male-dominated field, she reflects on how confidence, preparation, and a commitment to continuous learning have shaped her journey—whether that meant taking or teaching classes, or earning an accelerated MBA in cybersecurity during the height of the pandemic. Elishia dives into what great leadership looks like in practice: rallying teams around shared goals, shielding them from unnecessary noise, and creating space for both “thought leaders” and “thought followers” to thrive. She shares her philosophy on feedback—asking every team member how they prefer to receive it—and emphasizes that kindness and accountability aren’t opposites. Drawing inspiration from Radical Candor, she explains how authenticity, respect, and adaptability make feedback more effective than bluntness ever could. When it comes to operations, Elishia is laser-focused on quality and stability—especially in the high-stakes final quarter of the year. She encourages “shift-left” testing, insists on thorough reviews (“I want QA to be bored”), and balances the need for speed with the responsibility of reliability. Even though she’s never personally “broken prod,” her approach to postmortems is rooted in process, not blame. The episode wraps with her signature mantra—focus on stability—and an open invitation to keep the conversation going in future episodes. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, we have Dave. DAVE: Hello. MIKE: We've got Will Archer. WILL: Hello. MIKE: We've got Kyle. MIKE: And joining us for the first time, we have Elishia Williams. And Elishia is going to kind of be the star of the show today [laughter]. We brought her in to talk. She's actually my boss and [chuckles] also leads up engineering here at...not just Acima, but at Upbound. And I think that she has a lot of history and things that we'd like to ask her to share that we think could be of value. So, Elishia, I want us to begin. Often, the host tells a story, but I'd like to ask you, are there any stories from your career that you'd like to share - some compelling, you know, formative story you'd like to share to set the theme for our podcast today? ELISHIA: Well, first of all, thanks for having me. It's an honor to be here. And I've heard a lot about the podcast, so now I get to participate in it in this way. From a story perspective, I don't know, there's probably a lot of stories, but the one that comes to mind, especially when I think about kind of what you've shared we're going to talk about today for the most part, is really just how I got here. You know, it kind of starts back quite some time. And when I think about technology, right, I started off with a passion in technology as a child. So, I think a lot of people have that experience when they're growing up, and they're inquisitive about things and things like that. But I don't know that that was it, or maybe someone saw that. But my passion began when my dad introduced me to technology. And so, he actually gave me my first technical job. What I will say is, I was the person that had to maintain our home computer. Now, that was, of course, at a time when many did not have a home computer. And so, I'm not exactly sure how important my job was, but I sure thought it was at the time. And so, essentially, I had to run some application, and I'd love to remember what the name of it was, but I had to run an application that compressed and cleaned the files on our machine. And he had me do this multiple times a week. And so, I took that extremely seriously, because, of course, it was my dad, and it's what he asked me to do. And it kind of gave me some insight into what this thing was in our home that he brought to us. And so, to this day, again, I'm not sure how meaningful that was from a technical perspective. But it sure gave me my first sense of, I guess, technical responsibility. And so, I think from that point on, I pretty much knew what my career was going to be. I always knew that I was going to do something in technology. He also had us programming quite a bit as younger people. And so, I knew it would be software engineering. And so, that's kind of how I got here. MIKE: But there's probably a lot we could dig into in that story about [laughter] the value of mentorship and somebody who says, "Hey, you know, why don't you do this?" and how much influence that can have on your career. ELISHIA: Absolutely. It's a vivid memory for me, even that many years later [laughs]. WILL: My dad did the same thing. He bought a computer store. And then I was free labor [laughter], and he would just drop me off there, and be like, "All right, well, listen, I got all these computers, so..." ELISHIA: [laughs] Do something. WILL: Figure it out. ELISHIA: Absolutely. But it definitely...there was definitely a sense of pride when I ran those applications, and everything turned out great. And so, yeah, I don't know, I have four sisters, and each of us had some kind of job, but that was mine. MIKE: Nice. Well, and that's actually a good segue. You mentioned four sisters. Software engineering, it's long been a male-dominated industry, not always, but for the last -- ELISHIA: Pretty much, yeah [laughs]. MIKE: 40-plus years. So, what would you say to other women or others who find themselves minority in the software industry? ELISHIA: Hmm. So, that's, I mean, that's a good one. You know, I tell people, no matter who you are, what you're doing, just walk with confidence, knowing that you're in that place because you chose the field, and you're qualified to do it. I think if you're doing what you love to do, focusing on being the minority, or anyone else's differences, you kind of don't really have time for that to be your focus. And so, for me, I knew what I was getting into, and I decided to go to school for computer science. I looked at my classes. That was a good indication of what [chuckles] corporate America would look like at that point, right? And so, I mean, honestly, I learned a long time ago to just make sure I had individual experiences with everyone that I met. And so, I try to stay away from generalizations that even make me have to think about, oh, you're the this or the that. It's more about we're all here for something common. And so, when I think about how I feel on a day-to-day basis, I don't feel out of place. I've never felt out of place in this role, in this career. I wish I...no, I don't wish I could, but I try to think about, has there been a point where I walked on the scene, and I was like, I shouldn't be here? And I haven't had that. I just haven't. And I know that that's not everyone, by the way, because I talk to a lot of people. But that's been my life [laughs]. And so, I've only been in technology my entire career. And I'm comfortable in that setting, which makes me know that I'm in the right place. MIKE: I imagine that confidence goes a long way. ELISHIA: Oh, yeah [laughs]. Well, and, by the way, that's probably one of the things I hear the most, right? I go to a good bit of conferences, just walking in with confidence and being comfortable in the settings that I'm in. You know, a lot of people...I guess this is where some people think about, like, imposter syndrome. And I think no matter if you're a woman or you're a man, everybody could have it, right, if you just think you're somewhere that you've maybe, you know, gotten in too big for your britches. But it's just something that, you know, I try to, for me, I'm a lifelong learner. And I tell my kids, if you're nervous, you probably didn't prepare much. And so, for me, I just try to stay prepared. I try to work hard. I try to stay studied up. And it's what I've done for a while. That doesn't mean I don't get nervous, or, you know, I'm starting something new, and I wonder how it's going to go. But I will say, when it's time to go, then I have to put all that aside. So, I don't really dwell on it. I can think of walking in my first engineering job as a young 20-something. And I remember the company I started working for, most of the people there were no less than 10 years tenure. So, you got me, and then you got someone that's probably 40 years my senior at that point, right? And that was very different. But even in that, I, you know, I had done some internships. I'd done things that allowed me to see the world. And I think that really helped me to walk in. And I've always been more of a people-oriented person. So, once I get in, I tell people, I could probably talk to anyone. And so [laughs], then it's all good. But I remember this one person, I remember he, again, I was a young, young person. He's like, "What are you doing here [laughs]?" And so, some of my peers were like, "Oh, are you not offended?" I'm like, "No, I'm really not," because I know why I'm here. I went to school; I studied; I got the job [laughs]. And that was it, you know. But I try not to let, you know, those types of things be a personal thing for me. But, honestly, this person retired probably a year after I started. So, you got to kind of think about what he had seen in his life versus what I had seen in my life. And so, you know, sometimes you kind of have to just put your head where they their experience is, and it's not really personal to me. MIKE: Thank you. And that sounds like great advice to people who find themselves in the minority. What advice would you give to men in the industry, to flip the question around [laughs]?

The episode opens with Mike sharing two stories that set up a theme: context beats dogma. First, a bike rack bolt snaps seven miles from home with his toddler on board; he “hacks” a fix using a strap to limp back safely—imperfect but right for the moment. Second, he yells to stop that same child from leaning over a railing—normally a “don’t,” but justified to prevent harm. Bridging to software, Mike argues that sometimes you should break best practices: a hard-coded, partner-specific access control once shipped as a pragmatic stopgap, worked for years, and only now is being replaced with a proper, general solution. From there, the group explores when and why “best” practices stop being best. Dave frames it as “there’s always a best move”—for this context. Will and Kyle note performance work routinely trades readability and safety for speed; measurement is essential, or all you’ve done is make code harder to read. They contrast language and ecosystem philosophies (Python’s “one right way,” Ruby’s malleability, Java’s explicit structure), agree that humans are the expensive resource (optimize for mental load and boring, readable code), and acknowledge domains (firmware, game engines) where constraints force “ugly” but necessary code. The team also debates two coexisting feature-control systems—slow but self-contained env-based flags vs. instant, granular runtime flags—concluding both are needed because different roles value different trade-offs. They close on practical guardrails: prototype fast, even “sloppy,” to learn and validate; refactor after you’re green. Use YAGNI—don’t solve tomorrow’s problems today—and be kind to “future you.” Keep a backlog of intentional hacks, prioritize cleanup time, and recognize that some code paths matter far more than others (optimize the hot ones; duplicate templates when sharing adds needless complexity). Break rules deliberately in sandboxes to learn (e.g., Juice Shop, OWASP exercises), but in production favor simplicity: make it easy and explicit unless you’re forced not to—then measure, mitigate, and circle back to clean it up. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I will be hosting again today. With me, I've got Jordan, Will Archer. We've got Dave. DAVE: Howdy, howdy. MIKE: And Justin, and Kyle. And, as usual, I'm going to tell a story [chuckles]. Actually, I've got a handful of them here. I'm not sure if I can share all of them, but I think I want to introduce the story by first telling a story about cycling. The great Sandi Metz shares a lot of good stuff. She talks about cycling all the time. I can do lots of cycling stuff, right? So, I'm going to tell a cycling story. So, I was riding with my kids, and I had my youngest in a bike seat sitting on a rack that was over my back tire. And he was getting a little big probably for it [chuckles], but it worked fine. I could do it. What I didn't know is that maybe getting that top-heavy on the rack I had was putting a lot of stress on the bolts that were holding it up. And I was doing a loop, and it was, like, seven miles from home, luckily, not that far, but seven miles from home. And the bolt sheared off that's holding the rack up [chuckles]. Not a great thing, you know [chuckles]? DAVE: With him in the seat? MIKE: With him in the seat. That’s right. DAVE: Because of the weight on the bolts. Yeah. Okay. Yeah. MIKE: Weight on the bolts. And so, the rack drops on the tire, suddenly stopped. I’m going up a hill when this happened, you know, rocking back and forth because I'm going up the hill, of course, putting the stress on the bolts. I suddenly stop. You're not moving anymore, right? Now what [chuckles]? Seven miles from home. I can't really push the bike because now the rack's sitting in it. I can't take him off the bike and make him walk seven miles. He's, like, three years old [laughs], right? That's not going to happen. I also had a tether to pull the other two kids. So, it was a bad situation. What do I do now? No one was at home to come pick us up. I could have called, like, an Uber or something, but what do you do? "Uber driver, can you come put three bicycles and a car seat [chuckles]?" There was no good way out of the situation. DAVE: You got two kids on a tether. Dog sled. MIKE: Dog sled [laughs]? Not going there [laughs]. DAVE: Fair. MIKE: After some careful analysis, I got an idea, and I had a strap that I use for strapping stuff to the frame, like a water bottle. And I connected the strap to my bike seat, to the rails on the bike seat, to hold it up, and wrapped it around one side of the rack and pulled it really tight. So, it was just hanging from the strap by my seat. I found that if I sat down on my seat…and I was standing up to peddle, right? I went as gently as I could. It didn't hit my spokes very often [laughs]. I got back on, and I rode seven miles home that way. And I made it. And I took off the tethers. The other kids, they rode independently [laughs]. They can make it seven miles. It was fine. So, we did it. We made it home. And that was not the purpose that those straps were made for [laughs]. There was nothing in there that was serving the correct purpose, but we got home. Okay. So, that was story number one. I think it's a good one [laughs]. So, a tiny little story. You shouldn't yell at your kids, right? I think most people would say, “No, don't yell at children.” That accomplishes nothing. Yesterday, my youngest, again, he is a common thread in this set of stories, was upstairs, and he leans over the railing, just jumps up, like, jumps up on the railing and starts leaning way over. And I yelled because [laughs] I was horrified. “You need to get down. You're going to fall off and something terrible is going to happen.” And I don't regret that. He didn't like it. I didn't like it. There was some hugging and talking and making sure he was okay afterward. But, you know, I broke the rules, and I did something that normally I would not be proud of. And I made him sad, and I don't feel happy about that. But I was scared, and I wanted him to live. I didn't want anything, you know, any of the horrible consequences that could have come from this to happen. So, I said something, you know, I did not do what I would say that any parent should do. In this situation, those rules didn't apply [chuckles]. You know, you do what you can to save somebody. So, we talk about software, right? I'm talking about outside of software. Let's talk about software. Sometimes you should not follow best practices. Sometimes you need to strap something on, and that's the right thing to do. Go ahead. JUSTIN: I mean, if you're going to apply that back to your bicycle, I think you should still be riding with your kid hanging off that strap today [laughter]. That's really what happens [laughter]. MIKE: Well, okay, so, I've got a software story. Years ago, literally years ago…I don't think I'm saying anything that's exposing anything horrible [laughs]. There was a partner who had a feature request that was just for them, where they just needed certain employees to have access to a certain feature, and we didn't have a framework to make that happen. In this context, we just didn't need it, so there was no need to build it out. Nobody else was requesting it. And to build the framework to make this happen so that it would be generally applicable across all the users would take months. And the customer needed it, like, already, right? And there was no way that's going to happen. So, we put in a hack. We just hard-coded the users that got access to the feature. If you're one of these users, you get access. We didn't make it too terrible because it was configurable, and you could set up in your environment. It wasn't, like, in-line in the code, but, yeah, it was a hack. And the customer was happy. Didn't build the feature, and years later, it still works [laughs], you know, the straps holding it on. And, in this case, it wasn't that important, right? It was a pragmatic fix to a nasty problem, and it was kind of a nasty fix to the problem, but it worked. Not too many people…there are actually a few other people who have requested the same feature, so it's grown. There is a plan to mitigate this. It's actually probably going to be happening in the next quarter. But after years of doing good work, this hack is finally going to be retired. Man, it did its job, and I don't regret it [laughs]. I'm actually kind of proud that we solved this problem, and it worked, and nothing was harmed. Sometimes it's the right thing to do, and a brilliant hack, I think, deserves some respect. Oh, I've got some thoughts about some rules about when to break the rules. Well, I'm curious what you all's thoughts are. I threw some stories out there to seed some discussion. DAVE: There's a phrase that I've trotted out in front of most of the people on the call at some point, if we've been working together, which is there's a fantastic book from years and years ago called “Bobby Fischer Teaches Chess,” Chess Grand Champion from the ‘70s. One of the lines that I remember from Bobby's book is he says, “There's always a best move. You might not have any good moves, but there's always a best move.” And this is kind of what I see as that being, right? Is it OSHA-certified [chuckles] to strap a rack and then hang a child from it that you're actually related to and theoretically care about [laughter]? Of course not. But you're seven miles from home, right? That's probably the best answer, or at least one of the ones that qualify for that. If you'd had somebody with a pickup truck nearby, that would have been the better option, and it's fine. The thing that I get thinking of is when we say best practices, I hear Best with a capital B, or Practices with a capital P. And I see it engraved on a leather-bound book that looks suspiciously like scripture. MIKE: [laughs] DAVE: And all y

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 ha

The panel digs into the perennial question: how much SQL should developers know? Kicking off with a war story, Mike recounts a hyper-growth phase where ~20 performance issues were fixed—almost all by database changes, especially adding (or rethinking) indexes—yielding order-of-magnitude speedups. The moral: ORMs are great for safety and productivity, but when things get slow, it’s “usually the database,” and knowing how indexes, JOINs, and query patterns work is what unblocks teams. Will adds a blunt rule of thumb: apps are slow because of “bytes on the wire” or “the database,” and you can’t rely on ORMs alone to prevent N+1s or inefficient access patterns. From Ops, Kyle reinforces that troubleshooting still lands on SQL: monitoring tools can point to hot spots, but root-causing and backups often require direct database savvy. Eddy shares a counterexample: moving search from Elasticsearch to Postgres full-text revealed that a GIN index on a high-churn table actually slowed writes—illustrating the trade-off that heavier indexing speeds reads but taxes inserts/updates. The group also debates concurrency: for most web apps, you can push work “down the stack” to the database and avoid complex threading; true low-latency, hard real-time concurrency is rarer than many think. Stepping back, the crew frames SQL as a declarative, optimization-friendly paradigm—closer to functional transforms than procedural loops—which is precisely why database engines can do so much heavy lifting. Resources like SICP and Lisp/Scheme are recommended for learning to “think in streams” and transformations. The consensus: programming languages and frameworks come and go, but SQL endures—and senior engineers still write ad-hoc queries daily to answer business questions and debug production. They close with a teaser for next time: a lively debate about testing private methods and how to design for testability without committing “crimes” against your runtime. Transcript: DAVID: Hello, and welcome to the Acima Development Podcast. I'm David Brady, your host today. And we've got a fun panel today. We've got Kyle; we've got Eddy; we've got Mike; we've got Will, and we've got Matt Hardy. Welcome, Matt. Nice to see some new people, well, not new, recurring people. We don't have anybody new, new, new, but nice to see the regulars. Today we're going to talk a little bit about SQL. Like, do developers need to know it, and if so, how much? And this came as a suggestion from Kyle, who works more in ops rather than frontline web dev. And so, I'm very interested in hearing where he wants to go with this. But first, as our tradition, let's start with some story time with Uncle Mike. Mike, what do you know about SQL? MIKE: [laughs] So, I do have a story, and I was prepared for this. A few years ago, I say a few, at least five years ago, maybe five or six years ago, I was in a big application that was growing up [chuckles]. We were actually getting a lot of traffic where we hadn't been. It's the startup journey, right? And this actually was at Acima, you know, as we were in our rapid growth era, not that we're not still growing, but, you know, back in the startup days. And it's natural for every application, once you start going through that growth period, like, oh, wait, there's some things that don't work very well, let me say, that don't perform very well, that don't perform very well. There's things that work just fine when you had a data set of a thousand that don't work very well when you've got a data set of a million [laughs]. Things just don't work quite the same anymore. And so, I went through with the team, and we worked on that for maybe a couple of months. And over that couple of months, we made the application run about 10 times faster, which is a big deal, right [laughs]? That's a major performance impact. I think it was more than 10 times. I mean, it was a big deal. You know, going to 10 times faster has a big effect on your infrastructure, and I think it even went even beyond that. But I kind of quit keeping track after a while [chuckles] because it's, you know, you start resetting your baseline. Okay, well, we got to go faster than that, got to go faster than that. It’s not the only time I've done this, right? It's just the most recent time that I have fresh in mind. And one thing we found is...let me say a couple of things. Every single one of the performance improvements we made, except for one, were database improvements, and most of them were adding missing indexes. So, there's a database table missing an index, and, by the way, it's always a missing index. If you have a performance problem, it's a missing index [laughs]; I'm just going to say that, except there was a couple of them that weren't. A couple of them were some kind of weird cases. There was some really gnarly JOINs. It was running, like, JOIN against 10 things using a lot of LIKE queries. We fixed that one by using an external index, using a reverse, one of those external reverse indexes. It was Elasticsearch at the time. And that made a tremendous difference as well in our database load. And there was one that was not a database issue, you know, so we fixed, like, 20 issues, one of them wasn't. And it was because there was something that should have been in the database [laughs] but wasn't. There were some permissions that were being loaded really strangely from flat files and weren't being cached, and every request was reprocessing them. And by putting a little bit of caching and changing the processing, we took that from taking, like, half of every request time down to unmeasurable, right? It just went essentially to zero. It was great, you know, app went way faster. Everybody's happy. Everything's wonderful [laughs]. And we work on other problems. The lesson I learned from this, though, is that, yeah, it's always the database. And here's the critical thing: adding a database index is something that's really, really easy to miss if you don't know something about how databases work. And most of the time, you don't have to think about it at all, except for that time that you do, and it's the thing that matters most. I found that throughout my career, that yeah, it's always a database index [laughs] or something to do with the database because you don't have to think about it except for that time that you do. And if you don't know that time, then you're burned. And somebody who can come in and can fix that can make a tremendous difference in your application. Oh, there's the story that I was thinking about as we talked about this topic. DAVID: Awesome. MIKE: Do you have to know SQL? Well, I come from an older generation, right, where I cut my teeth writing raw SQL. And I thought it was kind of amazing when we started getting ORMs that would do some of that automatically. There's a whole lot of advantages to that. So, you avoid a lot of SQL injection flaws. You probably get better queries most of the time. So, overall, the switch that most applications have made to using an Object-Relational Mapper (ORM) is a great one. But that experience that we got when we had to do it manually is still incredibly useful. And I worry a little bit that the new devs coming in now are not getting that experience that you usually don't need, except for that time that you do. WILL: There's only two reasons that your app is slow: bytes on the wire, or your database sucks. That's it. MIKE: Right [chuckles]. WILL: And if your API is bad, it's just because their database sucks. That's how it works, you know. And, I don't know, I love an ORM. ORMs are great. ORMs are great, and I use them all the time. And, like, 99% of the time, it does it every time. But that's why we make our money. That's why AI is not going to come and get me this year. It's because sometimes...if the junior devs could do it, they would have done it, and it wouldn't be on my desk. And, I don't know, like, you've got to run some gnarly SQL. I'd also say two things: one, it's not like regular programming. It doesn't follow the same rules. It doesn't work the same way. It doesn't work the same way. SQL, if you're writing a for loop in SQL, you’re f***** up. My one F bomb for the podcast. Let me take it early. It doesn't work like that, right? And it's not that it's inefficient, but it's just it takes a foundationally different logic to it, and it's everywhere. My PM he was having terrible troubles in Jira this week because our team and all of our Jira stories were getting communicated up to management that was saying, like, “Thumbs up, thumbs down,” Roman emperor style. And this Jira query was screwed up, and I'm like, I don't know JQL, but I know JQL, and let's face it. And I just got in there, and I fixed it. And it's like, it's everywhere. It's everywhere. It's a foundational programming paradigm that is in everything. You want to do some GraphQL? You should know SQL. It goes in everything. There’s all these sort of, like, abstract layer data management things, and they're all heavily derived from SQL because they're solving the same kinds of problems. MATT: You should know what's under the hood if you're working on the car. Simple as that. And it's really easy, with an ORM, to get in trouble and write a bunch of N+1s if you don't understand what's going on and what's happening under the hood. WILL: Absolutely. Absolutely. Like, if somebody asked me and they came in and they were like, “Hey, listen, I have time to learn one thing this year. I could do concurrency, or I could do SQL.” I'd be like, “Just save yourself some time and learn SQL.” I believe, sincerely, that we're pretty close to the level in programming where most developers will never need to know anything about a thread, not really, you know? You've got an async/await. You can run some coroutines, just kind of spawn a job queue, which you can do, not knowing anything about real concurrency. And you can live and die a productive life wi

The episode frames engineering as an investment rather than a cost. Mike opens with a parable: leaders who put capital (or engineers) to work create value; those who “protect” resources without progress destroy it. The panel builds on that: impact comes from choosing work that improves tomorrow—planning enough to ship, avoiding ivory-tower perfection, and recognizing that “cheap” talent can be expensive in management bandwidth. Good contractors and senior ICs pay for themselves by shipping and by freeing organizational attention. They dive into technical debt with a pragmatic stance: prefer YAGNI, refactor when the change is hard so the right change becomes easy, and pay down debt “as you go” when you trip over it. Treat debt like a family credit card—budget a consistent tithe each sprint for the top, highest-leverage items and let the bottom 10% freeze or die. Too much debt maxes the card; you end up servicing interest (slow teams, broken features) instead of building. For growth and product strategy, pursue small, adjacent bets that serve existing customers and reduce risk rather than sweeping reinventions. A major throughline is investing in people. Effectiveness scales when seniors make others effective: clear plans for distributed teams, social onboarding, and apprenticeship-style pipelines that move interns, QA, and juniors into productive engineers. Pair programming and XP practices are championed as systematic knowledge transfer—training juniors up, spreading domain context, and keeping work flowing despite constant change. The most rewarding ROI, they argue, is the compounding payoff of people who grow, stay, and ship. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'll be hosting again today. With me, I've got Dave. DAVE: Hello. MIKE: Eddy. EDDY: Hello. MIKE: We've got Will. Yeah, we’ve got Will Archer. We've got Jordan. JORDAN: Hello. MIKE: We've got Justin, and we've got Ramses. RAMSES: Howdy. MIKE: I'd like us to start off with a story. This time I'm going to go biblical. WILL: Oh God. MIKE: [chuckles] So, [inaudible 00:00:51] I’m going to tell an old story in a new context. No religious context, but I think it applies here. So, a boss is going to go on a year-long sabbatical, maybe not that realistic, but, you know, humor me here [chuckles]. And they're going to leave, you know, put some employees in charge. And they're going to put them in, you know, these are, you know, leaders, leaders of the company, and they're going to give one person responsible for 10 million worth of funds, another one 5 million, the third one 1 million. So, they're going to be responsible for some funds here while the boss is on sabbatical. A year later, the boss comes back, and she asked each of the employees how things went. And the first employee, well, they've hired a new team, and they’ve built a new product that's going to bring in $10 million a year. So, "Well done," she says. So, the second employee has invested their millions in acquiring a small dev shop, brought them in, and they've increased the size of the dev team. And they expect that to contribute to $5 million in projected annual growth. So, "Well done," she says. So, the third employee let go of some of their developers because they wanted to save their money. They wanted to make sure...I've only got a million dollars. I got to make sure that it stretches for this year. Customers are complaining because now there's not the support on the product. The product's been losing users because everybody's complaining. Reviews are going down online. And the boss says, "You know, why didn't you invest the money? You could at least put an investment account. You just sat on it." And the employee says, "You know, I was just scared to lose the money. So, I made sure I kept it all." The boss says, "You're fired [laughs]." And she gives the money to the first employee. So, we hire engineers as an investment, right? Engineers are builders. And we build stuff because it makes companies money. You know, we're doing this on our own. We do it because we're trying to make money. I mean, we enjoy the job, but the reason that we get paid is so we can make the company money, and I think it's critical to remember that. Every minute we spend is an investment. And is it a good investment [chuckles]? Was it worth investing in us? When we get to next year, is the boss going to look at us and say, "Was it worth having them as an employee? Did we actually do better because of that?" And it also affects the way that the company sees the engineers. There's sometimes a mindset where we're seen as a cost, just net cost. Like, "Oh, they're just the cost we have of doing business." And I think that's a dangerous way to think because it doesn't appreciate that you've got to spend some money or, you know, I got to put in some risk to make money. Money doesn't just come walking in the door. It happens because you've built something and maintained it. So, in the broader picture, I'd like to talk, for today's discussion, I'd like to talk about what it means to treat ourselves as an investment and what that means for engineering. Go ahead. DAVE: Can I jump on a tail on that? MIKE: Please. DAVE: I love when ideas from very far apart in my brain snap together. It's a psychological thing called synthesis. And you just synthesized this thing for me, which is, are we investments, or are we a cost? And I took a financial literacy class 25 years ago. And the guy stood up and he said, "Do you have any assets? And what do you have are liabilities?" And we all started going through all the things. Well, I've got assets. I've got a car. I got, you know, and we just started listing all the things we had. And he's like, "Every single thing you just listed is a liability, not an asset." I'm like, "What are you talking about? My car is an asset." He’s like, "Is it going up or down in value?" "Oh, it's going down. And you had to pay for it." "Yep." And it doesn’t make you...well, I mean, it gets me to work. Okay, that's an investment. That's something you have to do. But you can't sell that car for more money than you had it. It is not an asset in and of itself. You can use it. And it's good, but it is not an asset. When you acquire a company or you're in a company that's getting acquired, the first thing management does is say, "Nobody leave," right? "Here's the retention bonuses. If you stay for the next two years, here's this." Why? Because you are an asset. You increase the value, and your continued presence here continues to increase the value of the system you are in. So, anybody who thinks their employees are a liability...you can point at a specific liability or a specific liability and call them an employee. That's an interesting wording, but you get what I mean. But that's like a onesie-twosie that the job, when an employee is a liability, is because they are failing to be the asset that you need them to be. WILL: That wasn't my experience, but that's a tangent. MIKE: So, well, what's worth investing in? If we are assets, if we're worth investing in, what is? What should we actually be investing in? Because there's a lot of stuff you can do in a day. There’s choices. That's a broad question, intended to be open-ended. JUSTIN: [laughs] DAVE: I think on our last podcast, I mentioned the generic advice of prioritize later. And anything you can do now to improve tomorrow or improve later, I think, is a great way of an asset. And so, that's a very generic answer to what should we do as employees, but that's the thing that I try to do. I try to look at, like, where does it hurt the most, and what can we do about it? MIKE: So, where does it hurt the most? WILL: The question I've got, right, is, like, sort of, like, in what context, right? I mean, sort of, you know, as an individual contributor, like, I manage a department of one, right? You know, so I have things that I need to be doing, right? It's all good, you know? And so, you know, my discretionary spending, right, is limited, not zero, right? Because there is lots of interstitial time that I'm waiting for something, right? You know, like the factory is idle for whatever reason. It’s just sort of, like, move up the ladder, right, as your scope gets larger, like, that sort of time, like, you know, the latitude you have to make decisions gets bigger. And so, I guess the question is, like, who, right? Who would be investing and, you know, what? MIKE: Well, I was thinking about this before the call as well. It also depends on the scale of the organization you're in. If you are alone, if you're the startup, you know, investing in yourself, building a new product, what matters probably is very different than if you're on a team of 50 or 100 or 1,000. WILL: What if you're a startup and, like, you're not, you know, like, if you're not generating a profit, everything's an investment, isn't it? You know? It's a thing. I mean, like, you know what I mean? Like, you're building something, right? Like, the investment is fairly direct and, like, unambiguous and kind of cut and dry. MIKE: But you can go for some perfect ivory tower implementation that's going to take you 10 years, and you don't make it to market before you run out of funds. So [laughs], I think it does matter. I think when you're that startup, you need to have a goal of getting in money fast. It's very sink or swim. Like, you need to prioritize, and you may make some cuts that you wouldn't do otherwise. JUSTIN: So, I think it goes back to a little bit what you mentioned right there, Mike, is, like, you've got to plan, or you've got to have a plan. And if you don't have a plan, you have no plan. And so, whatever you do may not fit within that overall plan of making sure that I get paid tomorrow, next week, and, you know, next year. So, time spent planning, I think, is, you know, you don't want to do too much. B

In this episode of the Acima Development Podcast, Mike hosts a roundtable with Eddy, Dave, Chloe, Jordan, Ramses, and later Will, to explore the differences between small and large projects. Mike kicks things off with a personal story about industrial dishwashing as a teenager and how that shifted his perspective on “small” problems like doing dishes at home. He ties this to software by noting that scale fundamentally changes how you approach problems, whether that’s navigating your neighborhood versus traveling cross-country, or building a small app versus managing a complex, multi-team system. The theme: what works at one scale may feel trivial or even inadequate at another. The conversation then moves into real-world engineering trade-offs. Dave contrasts working in application development versus database engineering, where different constraints (compute vs. storage) flip what’s considered efficient. Eddy stresses the importance of incremental, low-risk changes in large systems, while Chloe shares how her internship taught her that upfront design decisions carry far more weight in big projects than in small, flexible ones. Will and others riff on the “temptation of perfection”—the idea that if you just planned enough, you’d get everything right upfront. Instead, they argue for agile approaches: accept mistakes as inevitable, design for change, and value rework as part of progress. Several panelists tie this to the importance of embracing ignorance, asking “stupid” questions, and adopting a growth mindset to avoid paralysis when decisions inevitably prove imperfect. The group also digs into the human dimension of scale: coordination. Jordan notes that large projects require consensus and approvals, whereas small projects let you move unilaterally. Mike reframes bureaucracy as a natural outcome of needing structured communication and shared understanding, not just red tape. Dave and Will debate decision-making heuristics—how long to defer choices, what counts as “enough information,” and how to balance planning versus execution. They conclude that small projects build the fundamental skills and intuition needed for larger systems, while big projects demand humility, adaptability, and collaboration. Ultimately, the episode emphasizes that success isn’t about perfect planning but about making good-enough decisions, coordinating effectively with others, and being willing to course-correct as conditions change. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I've got Eddy, Jordan, Dave, Chloe, and Ramses. Now, Jordan and Chloe are our interns. You all were on before, right [chuckles]? CHLOE: Yeah. MIKE: So, it's not the first time. It's not the first time here. But today is the last day of the internship that we had for this summer. And as a result, we're choosing a topic that I thought would be really relevant, something that we've talked about some with the interns, if they can give us some insight as to what they've learned. And having somebody new on a problem often reveals things that other people don't see. That's why sometimes grad students make good teachers [chuckles]. They're fresh to it, you know, they haven't been so distanced. So, I'm really interested in hearing about this. Notice I haven't mentioned the topic yet. I'm going to give a little intro to introduce here. And I'm going to talk about a summer in my teen years where I worked at a Mexican restaurant [laughs] washing dishes, not just washing dishes. They also made me a prep cook and I heated up, like, beans [laughs]. But I washed a lot of dishes, and this was, you know, industrial dish washing. You can imagine what the pans looked like after they've been cooking whatever Mexican food they were cooking [laughs]. Just imagine, you're probably right. EDDY: Did you use a pressure hose? It's probably the best way to clean dishes, especially large dishes. MIKE: So, we had two things that happened. So, there was the customer dishes that came in, and those we had a big industrial dishwasher that we kind of did a conveyor belt style. You’d load them in, and they’d go in there, and they’d steam, and spray a bunch of water, and that worked pretty well. Except if you have, like, cheeseburgers, you know, cheese would melt onto it and stick to the plates [laughs]. I see Chloe smiling. She may have done this before [laughs]. And on the other side of the area where we did the washing, there was a series of three sinks, and that's where all of the stuff from the cooks, right, that's where that stuff would get cleaned. And that was the gnarly stuff. And a pressure hose...there was nothing that would take gunk off a pan when it first came over. And this wasn't, like, very authentic Mexican food [laughs]. They had, like, I don't know if it was blackened, you know, Cajun, but along those lines kind of fish that they would do. And they’d burn it all on the pan, all the seasoning that they would have around, and then we'd have to clean that off. So, imagine burned on fishy oil with spices and gunk. So, first sink was a soak with lots of soap. Second sink was for rinsing. And third sink was bleach. Soap, rinse, bleach. And I’d spend hours every night. Well, before I ended up, like, hosing down the floor and stuff. Weird smells come out from behind kitchen equipment when you hose them down at the end of the day [laughs] [vocalization]. It's unrelated, just something I think of sometimes, that smell [laughs]. This is this industrial operation, right? And I would spend hours doing this, you know, the soaking and then you go to scrub the thing and if it wasn't coming off yet, then you’d go back in the soap soak. And, eventually, it was like magic. You’d soak it long enough, even the worst caked on stuff would eventually come off. And you'd rinse it and get it over to the bleach and out, and rotate back around to the cooks. And I got used to this. I'd been doing this for weeks. And then came my rotation, remember, this is my teens, came my rotation to clean the dishes at my parents' house. And I went to do the dishes, and I just started laughing. It's like, what are these? Toys [laughs]? It's a little scrub brush [laughs] and, like, a sponge. Like, I used to think this was a chore. This is going to take me five minutes. What kind of problem is this [laughs]? And it totally changed my perspective around doing the dishes. This is an entirely different job. I have different tools. I don't have real tools anymore, like, and I had to, you know, find the scrub brush. Like, okay, the scrub brushes work better at this than the sponge [chuckles], but still, it just all felt like toys. I laughed. Every time I did dishes that summer, I laughed because it was just so much of a different problem than what I was doing at work. Today, we're going to talk about big projects versus small projects. And we're not washing dishes [chuckles], but maybe somebody's doing software for, like, a microcontroller for a dishwasher or something. So, maybe somebody out there is washing dishes. But a lot of these principles apply. The scale really matters. And this comes up often, actually, in our podcast. And you’re like, oh yeah, scale matters. It came up recently when we were talking about vendors. If you are very differently sized from a contract shop, then you're probably not going to get the right level of service because they don't cater to your needs. And when you're building stuff, scale matters, too. And I've got a lot of thoughts on this. You know what? I'm hosting, so I'm going to throw one other thought out here: Navigating inside of a neighborhood. In fact, this is something I've seen in my neighborhood. Where I live the most prominent landmark is the village water tower. We've got a big water tower. It's one of the larger ones in the region, and you can see it from almost everywhere in the neighborhood. We have a daughter of a friend who once got lost because she got into a part of the neighborhood where she couldn't see the water tower. And, you know, there's a little bit of hilliness, and so she got to a low spot. It's like, I don't know where I am [laughs]. And she was lost for a while because she had nowhere to go. DAVE: GPS is unreachable. MIKE: Yep [laughs]. And, you know, she may have been, you know, she was probably, like, she may not have had a phone. This was probably 10 years ago, maybe a little bit before everybody had a phone [chuckles]. She didn't have a GPS. But yeah, the water tower is the GPS that that's where you're going -- DAVE: That's what I mean, yeah. That’s what I meant, yeah. MIKE: The water tower is the GPS. And so, yeah, she didn't know where to go because navigation is different when you've got a small scope versus a large scope. Once you get outside of that, well, you actually have to know which way you're going. You have to know where your cardinal directions are maybe, right? You have to recognize more landmarks than one. And, you know, traveling across the country requires a different set of skills than walking around the block. They both require skills, but one of them is fundamentally different. And a lot of times it is hierarchical in that some of the skills that you would apply for that navigation of the, you know, of the small scale map may apply to large scale map, but you're going to have to say, “Okay, well, I need to get from Chicago to Des Moines.” And you figure out at a high level where that's going to take. But then when you get down to the actual implementation, you know, you have a detour. And then you switch down to a different level, and then you have a smaller map, a smaller map in your mind that you're dealing with. So, your hierarchy changes. So, you have to break down the bigger problem into smaller problems. I wanted to throw out a couple more ideas to kind of get the thoughts. Also, Will has just joined us. Will Archer,

This episode of the Acima Development Podcast focuses on the complexities of evaluating and selecting vendors, whether for software, contract labor, or specialized services. Host Mike opens with a cautionary tale about a vendor that initially impressed with a knowledgeable representative but turned out to have major security flaws, poor integration practices, and overall incompetence once the contract began. The group discusses how this mirrors a broader challenge—companies often get only a brief, curated glimpse of a vendor before committing, with little opportunity to see the full team’s capabilities. This leads to a conversation about the importance of scale in vendor choice: a large enterprise might thrive with a feature-rich, expensive solution, while a startup could be better served by a smaller, more agile provider. Needs change over time, and the vendor that fits now may not be the one you need later. The conversation then shifts to the vendor-client relationship from multiple perspectives—Mike, Dave, Will, Eddy, and Kyle all share stories from both sides of the table. Will highlights the unstable economics of contract shops and the difficulty in sustaining top talent, while Eddy points out the importance of assessing a vendor’s responsiveness to feature requests. Kyle and Mike discuss how larger organizations often limit vendor options through partnerships, which can lead to compromises in quality or fit. The group also addresses the consolidation push in big companies, where leadership may favor a single vendor for cost control, even if that means losing specialized capabilities. They emphasize balancing department needs, cost implications, and redundancy to avoid single points of failure. The episode wraps with a practical checklist of red and green flags. Red flags include security issues, legal troubles, impossible promises, conflicts of interest, overreliance on one “all-star” representative, and immature products. Green flags include a vendor that’s “boring” (reliable and consistent), mature, used successfully in your industry, and willing to connect you with your actual account rep. The hosts stress building vendor-agnostic integrations to allow easier pivots in the future, negotiating service levels, and reevaluating relationships regularly. Final advice: know your needs, verify vendor claims, plan for change, and avoid long-term dependencies on critical functions that should remain in-house. Transcript: MIKE: Hello, and welcome to the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me today, I have Kyle. I've got Dave. DAVE: Hello. MIKE: We've got Will Archer, and we've got Eddy. And we are going to be talking about something that comes up over and over again in the industry. And I'll just jump right into it [chuckles]. We're going to be talking about how to evaluate a vendor. We talked about build versus buy, I don’t know, a few weeks ago, maybe a couple of months ago. Today, we're going to go specifically into strategies when you do decide to buy. And this also applies even if you're going to go with, like, an open-source project. How do you evaluate the vendor? You know, how do you choose when there's a variety of options? And story time. Years ago...I think I can be a little open about this because the company isn't even in business anymore [laughs]. I worked for a company that did content management for publishers, mostly newspapers-newspapers and magazines, small newspapers. There's a lot of them out there actually. And we did a lot of their websites. And we were evaluating a partner, like, a business website builder. That's a common thing out there. There's lots of ways you can get your content out on the internet [chuckles]. And there are some niche products that allow you to do it in a specific way. We were looking for a partner to do it in this niche way. And I'll get a little bit into the business model because it actually is interesting. With the newspaper industry, sometimes people think it was killed by other media, and that's a little bit true, but not really. Newspaper industry was killed by Craigslist because they made their money off of classified ads. If you're old enough, you remember that when you used to want anything, you'd go get a newspaper. When you needed something like an apartment to go rent, for example, you'd go get the newspaper because everybody in the community knew it was there. All the business in the community knew it was there, and so they published there. And we were trying to come up with a way to kind of preserve that model where businesses could have a permanent presence within the newspaper website. And we were working with a partner to help with that. There was a friend of somebody in the executive suite who had a company to do something that was loosely associated with what we wanted to do, who said, “Hey, we'll just use my buddy's company.” And they sent a tech rep over to get some evaluation. They did most of the stuff without evaluating with the engineering team [chuckles]. They sent one person over to the engineering team. And I talked to this guy. He was their...well, I'll get back to that. But he was great. He talked very clearly. He was able to talk about their software. I talked to him about what you do with security. He answered it very well. He was able to talk about their stack. He knew what he was talking about. I didn't see any real red flags. And really, I was just supposed to be putting a rubber stamp at the end because the business deal was basically already made. Well, when we went to integrate with these folks, we never saw that person again [chuckles]. Turns out he was their best person. And he was trying to keep the company running because nobody else really knew what they were doing. Very quickly, we saw glaring security issues. We had to send a password to them, which they could provide to us in plain text. So, they kept all of their customer passwords in plain text. If you don't know, that is, like, the quintessential security faux pas. You never save a password in plain text [chuckles]. It's just the wrong thing to do. DAVE: That's not in OWASP anymore because we all know not to do it. That's the only reason...it would be top of OWASP if we were all still doing it. MIKE: Exactly. The partner was a disaster. The security issues were just the beginning of it. They were hard to integrate with. They were a difficult partner. And they're not the only company I've worked with that was like that. We brought in a vendor, and then it was a disaster. And none of us want to have that. I just read, earlier this week, there's a new website that allows you to rate your date. It's popular in urban areas where there's guys who will go around and be bad dates, mistreat their dates a lot. It's open only to women, apparently. It allows them to rank the guys and say, “No, this guy's a creep.” And they're happy about it, right? You can identify the creep. There's lots of problems with that business model, by the way. There's some challenges. There's several companies that started it and then failed because it can be abused. But it'd be great if we could have something like that, right? You get some crowd-sourced, semi-objective information to say, “Yeah, this is a bad vendor.” But we don't. You never get that. What you get is more like what I got, like, here's the best person from this company. Try to evaluate whether they're a good vendor or not. You've got 10 minutes. Go. And it's a challenging problem. It's a challenging problem. So, what do we do? How do we evaluate a vendor and determine they're the ones you want? How do you stack them against each other and choose which one to go with? And I've got some thoughts in here. I've got lengthy notes that I can start talking, but I don't want to do all the talking. I shared one horror story. You all probably have some as well. I'll kind of open the floor here. Do you all have any horror stories? And maybe you don't have horror stories. Maybe you've got positive stories. What are your horror stories, and what did you learn from it? DAVE: I have a quick scoping question. When we say buying from a vendor, this can be anything from buying a $100,000 site license for some software, to purchasing, to, like we were talking in the pre-call, to contract houses where we literally...where this is the opposite of buying, that we're literally renting workers. But it's the same idea, right? We’re going to go [crosstalk 06:34] for money instead of for a high-risk [inaudible 06:37] MIKE: Exactly. It's the same principle because our expertise only goes so far. There's only so much that you can build. And [chuckles] you're going to have to buy something, almost certainly, that's a rare company and probably doesn't even exist that can manage everything themselves. So, at some point, you're going to have to work with a vendor. DAVE: So, I wasn't going to tell this story, but you just jiggled it in the back of my brain. And Eddy’s heard this story this week. I built a project 20 years ago that I called Data Monkey. It was all written in Perl, and you gave it a DDL, basically a schema, a DSL of a database schema, and it would go build your database for you. And somebody told me, “Have you seen Rails?” And I'm like, “No. What's that?” And they’re like, “Oh, you need to see this.” And, Data Monkey, I had spent over a year and a half building this. And I was running a content management system for a bunch of online webcomics with it. It made us very happy. But it was clunky, and I was the only maintainer, and developing and adding features was hard. And I couldn't do migrations. I could not understand how to do deltas on a migration. So, you had to throw away the entire schema and then run Data Monkey again and build it all over again. It was a 1.0, right? It was a very early thing. And it only ran on MySQL because that was the only database that I used as a single person. S

In this episode of the Acima Development Podcast, host Mike opens with a gardening metaphor to frame the episode’s central theme: cultivating healthy company culture. Drawing from his personal experience transforming barren soil into fertile ground, Mike contrasts short-term fixes like chemical fertilizers with long-term strategies like feeding the soil itself—likening these to how companies often rely on perks or high salaries to attract talent rather than investing in sustainable, growth-focused environments. This sets the stage for a broader conversation about what truly nourishes both plants and people—ecosystems, relationships, and meaningful investment. The discussion evolves into a rich conversation among remote team members, including Justin, Javier, Jorge, and Will, who share their experiences working in international and distributed environments. They highlight the importance of communication, inclusive documentation, and feeling culturally and professionally supported. Javier and Jorge reflect on challenges faced by Latin American contractors, including language barriers and differing communication styles. They emphasize that well-documented processes and clear expectations can bridge time zones and cultural gaps, especially when employees are empowered to grow and contribute meaningfully. The group critiques superficial attempts at building culture, such as gift cards and perks, and stresses the importance of leadership that fosters personal growth, purpose, and strong communication. Leaders who spend time mentoring, understanding their teams, and clearing barriers can create “fertile soil” where people thrive. Whether it’s through offering growth opportunities, creating psychological safety, or enabling people to do impactful work, the team agrees: you can’t shortcut your way to a strong company culture. You have to invest in it intentionally, consistently, and with heart. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With me today I have Justin and Javier. And this should provide some good perspectives. Justin previously worked for Acima [laughter] [inaudible 00:39] and is now elsewhere; I'll leave unnamed [laughs]. Javier is a contractor that works outside the office, outside the country, which will provide some good perspective because we'll get good perspective to the topic today. I'm going to announce the topic in a minute [laughter]. Although you could probably see it from the title of the podcast recording but, you know, at least I'll pretend to leave some suspense there [laughs]. JUSTIN: I'm looking for a good story, Mike [laughter]. MIKE: I'm going to talk about my garden. JUSTIN: Oh. MIKE: I've enjoyed gardening since I was a kid. I like growing things. I like being outside. I do have a garden. To be honest, it's maybe a little neglected as of late, but [chuckles] I do have a garden. And I say neglected, I've let some things grow and spread. So, I've got a big patch of raspberries, for example, because I love raspberries. What's wrong with letting the raspberries spread [chuckles]? They're delicious. I've got quite a bit of garlic, and I've got some other berries. I’ve got some goji berries, some garlic chives. So things that have kind of spread some, but I like them, so it works great. And I have a lot of kale because I love kale. I eat kale every day. I've read a lot about gardening. I, at one point, considered changing careers. I was going to work for a gardening company on their tech side for a while. I didn't end up doing that, but strongly considered it. And my original major was botany, so definitely very interested in this topic. I've got, like, a hundred cactus plants in my office that I love. Most of them I grew from seed [laughs]. I like plants. Pandemic, you know [laughter]. So, I'm going to talk about a thing that people regularly get wrong, and even to the point of agriculture sometimes gets wrong, and they're turning from this. And there's been a turn over the last few decades to fundamentally shift the way people think about not just gardening but farming. Where I live, I have quite a bit of farms nearby. In the state of Illinois, there's a lot of corn and soybeans. If you've ever been there, you know what I'm talking about [laughs]. There's a lot of corn and a lot of soybeans. They used to just plow everything under every year or just treat the waste from the previous year's corn and soybeans as waste, and just kind of ignore it, let it blow away. And when they’d till it under in the fall, the soil would blow away all winter. And there's places you can go and they'll show you how deep the topsoil used to be and how deep it is now [laughs]. On the rest stops on the side of the road, they'll show you how much topsoil has been lost because it's a big deal, like, half or more of the topsoil has been lost in areas. And it's a really serious problem because now you can't grow crops as well because you've lost that deep reservoir of fertility that allows you to grow. And so, they've got techniques they do in farms. One of them is that they’re moving away from tilling. They allow the stubble to stay on the ground so the soil doesn't blow away. But it also means that it decomposes into the soil. And there's a reason they have corn and soybeans also. Because soybeans are legumes, they've got nodules on their roots that feed microbes, that take nitrogen out of the air and make it into a form that the plants can use. So not only are soybeans high in protein and nutritious, they also leave the soil better than before you planted them. So, they improve the soil. So, it's part of a rotation where they grow the soybeans to improve the soil. Then they grow the corn, which is really hungry and uses up all that nitrogen. And then, they'll grow soybeans again to improve the soil again. So, there is this cycle of rotation, which is something that was done years in the past. People have done crop rotation for probably a millennia, realizing that certain plants will take certain nutrients from the soil. This is getting to engineering, by the way. This is getting to engineering [laughter]. JUSTIN: I'm getting a minor in botany right now. [laughter] MIKE: In my garden, so my garden, when I moved into where I'm at now, I took the worst soil in the yard, along the back of the property. And they’d cut away the topsoil [chuckles] when they built the house, and it left just subsoil. And it's just...it's clay, and sand, and gravel, and really nothing else [laughs]. And I thought, this is a project. I want to see if I can make this grow stuff. And I guess the previous owner of my place was a grass seed salesman. He couldn't get grass to grow [laughter]. It was just bare dirt on the area where my garden is now, and there was ravines all over through it. Cutting down, you know, it was bad. And so, to the key point, what a lot of people do is they'll go buy some chemical fertilizers, and they'll throw that on the soil, and the plants can actually grow in that. You know, you can get some things to grow. In the extreme case, you can do, like, hydroponics, and you can actually kind of make it work with just chemicals [laughs]. It's a fussy business. And the minute that you stop augmenting with those chemicals, the whole thing falls apart, right? And everything dies [laughs]. You need to continuously add those chemicals in order to make it work. And they actually degrade the soil over time because they usually come with some salts that will build up in the soil. So, you'll get these minerals that build up and actually make it harder and harder to grow things. It's a problem. It's a real problem. And it reflects a misconception as to what you're doing there in the garden. Because I have a garden...it's a small scale. I can really focus on that. And the change in mindset that makes all the difference is you don't feed the plants. You feed the soil. You don't feed the plants. You feed the soil. If you feed the soil...so, think about the difference that would make. So, I'm going to focus on improving the soil. Going back to those farmers who have lost all the topsoil, like, oh, wait, we need to stop this, right? I need to preserve the soil I have and improve it. In some places, they actually are improving the soil. They're growing it again. If you feed the soil, then the healthy plants will follow because the plants don't live in a desert, in a vacuum. We're not on a space station. Even if we were on a space station, plants have not evolved to live in a sterile environment, and don't live well in a sterile environment. You may remember the book and movie The Martian that came out a few years ago [chuckles]. A guy had to poop in his garden in order to get microbes to grow because the plants wouldn't grow without it. It’s the same idea. You need to have this ecosystem, or the plants just don't do right. And if you build healthy soil by feeding all of the stuff that's living in the soil...because it's not just the plants. There is a huge network of fungi, bacteria, protozoans, insects [laughter], rodents. There are all kinds of things that live in that soil. And your plants are just one of them. If you have incredibly healthy soil, by adding things to feed the soil, feed that whole ecosystem, then the healthy plants will follow because you're focusing on the right thing. You're building the healthy ecosystem, the healthy environment, and then the plants will grow well as a natural consequence because they'll be in a place they want to live. All of the things that would be good for them are there. And so, you don't have to go and find all of those precise chemicals. Oh, I need this much nitrogen. I need this much phosphorus. I need trace amounts of copper, whatever the case may be. You don't have to worry about that because everything else is taken care of. That will just naturally be taken care of because

In this episode of the Acima Development Podcast, Mike kicks things off with a humorous comparison between the DMV and employee onboarding, using the DMV’s predictability as a metaphor for what onboarding should feel like: smooth and well-organized. The team, including interns Chloe and Jordan, along with veteran team members like Will, Matt, and Tim, dives into the realities of onboarding experiences. Chloe and Jordan reflect on the value of strong documentation, access to multiple mentors, and feeling emotionally supported. They emphasize how overwhelming onboarding can be when information overload hits or support is unclear, and how even small gestures, like developer lunches or Slack channels, can make a big difference in building comfort and connection. The discussion expands to include insights from more senior voices like Will and Matt, who underline the psychological and emotional complexity of onboarding, particularly for seasoned professionals used to excelling. Will points out that new hires, especially mid-career professionals, often face an identity crisis when they’re suddenly inexperienced again, and that trust between leadership and new employees must be earned, not assumed. He stresses the importance of proactive communication, asking questions, and building relationships over time. Meanwhile, Matt emphasizes that leaders must take responsibility for initiating that trust and creating a culture of safety and availability, even if time and organizational bandwidth are constraints. Finally, the group turns to strategies for remote and global onboarding, with Tim detailing Microsoft’s best-in-class processes that pair automation with strong support systems. The consensus is that technical logistics like IAM provisioning and documentation matter, but they’re not enough on their own. What truly shapes a successful onboarding experience is human connection: pairing new hires with mentors, creating safe spaces for questions, recognizing cultural differences, and setting realistic expectations. The episode closes with a collective realization that while automation can streamline processes, it’s trust, empathy, and communication that ultimately empower new team members to thrive. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. We've got a good crew here today. We've got Tim, Kyle, and we've got a couple of interns who are joining with us today¬¬—Chloe and Jordan, great having you. I’m excited to hear your input. It's very topical for today. We have Justin and Dave, and, finally, Will Archer, the crew here. I think I got everybody. Did I get to you, Kyle? I think I mentioned you. If not...[laughs] Let's start with an ordeal I'm going to have to go through in the next couple of weeks. So, it's been five years or so since I last renewed my driver's license, so I have to go to the DMV next week [laughs]. JUSTIN: I want to see how you're going to tie this together with new hires. This is going to be really entertaining. [laughter] MIKE: People do not look forward to going to the DMV. There's an old song that comes to my mind that says, "I've been to hell. I spell it DMV [laughs]." I think of that every time. I went and looked up the lyrics. There's some other lyrics in that song I'm not going to share [laughs]. I'm going to point out the reference. But it makes a point that I think most of us tend to agree with. However, when I go to the DMV, I know exactly what to expect because they have done this a million times, right? Maybe literally a million times, maybe more than a million, you know, many millions in a large state. They just do this over and over again. So, they have a routine. I know I walk in there. I'm going to get the number, and then they're going to send me down to a seat and wait for who knows how long [laughs]. They might have one of those little counters to let me know when the number is coming. At the one DMV I would go to, there's, like, three different desks, so there's actually three different lines [laughs]. You have to know which one you're getting to. But they have signs. They've got tape on the floor that sends you to the right direction. And then when they call you up, they've done this so many times that the people there they don't even, like, see your face anymore [laughs]. They just walk you through the routine. And it's so standardized because they need to make sure that it always works every single time. And it generally does [chuckles], as long as you didn't forget to bring whatever document you needed to bring, and then they send you to the back of the line or send you home [chuckles], and you have to come back. If you get everything right, it just works because they've totally standardized that process. Now, it's totally impersonal, and [chuckles] you wait forever sometimes, and nobody likes that. I have heard that they've got, like, some...There are offices in Utah, and I've heard that they've got, like, some express DMV out there that works really well. I've heard some people say some good things about that. I'm seeing some nods out there. Because they’ve cut the process...streamlined so you can go in there and just take care of that part that's fast, and they run you through. If you set up an appointment, you go right through. So, it actually can be pretty good when you have everything lined up and planned ahead of time. I think that we've all been involved in starting something before that did not go so well [chuckles], when things were not planned, and it can be an absolute disaster. We're going to talk today about onboarding new employees. And I bring up the DMV because if you have everything lined up, you might not enjoy it, but it'll be relatively fast. You're probably not going to be there for a week [chuckles], and they will take care of your needs, and you will leave with your business taken care of. And sometimes when we onboard new employees, it does not go like that at all. I've seen some horror stories where people did not get their computer for a month [laughs], and...I’ll work someday, you know [laughs], and nothing goes through. It can be a total disaster. And somehow, we've been doing this for however many decades we've been doing it in software, and it still takes...it's still hard. It's still hard. That's what we're going to talk about today. We talked about onboarding, actually, about a year ago. You can go back, and I think it was July of 2024. We talked some about this. And that time, we focused a lot on the mentoring aspects of it. Today I thought we'd talk a little bit more...to have a little more opportunity for horror stories [laughs] we’ve seen. And we've got some people who've recently onboarded. We can talk about the good and the bad. And we’re going to talk about a little bit more of the hands-on, nuts and bolts. How do we make this work? So, I would like to start by asking our recent hires here [chuckles], so Chloe and Jordan, what went well, and what did not go well about your onboarding process? CHLOE: I can start. I feel like one thing that went really well is there was a lot of documentation, so a lot of really good resources to get help when it came to onboarding, as well as I was paired with somebody who has recently onboarded just a few months prior. And so, they had a lot of really fresh experience as well as advice when it came to onboarding because they had just done it, so they had already kind of figured out a lot of the things that could go wrong or any problems that I might have encountered. Something that was a little bit more challenging was, I think, when you are onboarding, it just feels like you are in a pool of water, and there's these big waves. And it's really hard to feel like you can catch a breath and feel like you're understanding everything, and that's common to a lot of places. But it feels like there's so much to learn, and you always feel behind, which is a tough feeling to feel when you're coming into a new company. MIKE: Great. Thank you. Jordan, any thoughts from you? JORDAN: Yeah, so this is, like, something that is kind of obvious, but I think good documentation is a must. And this isn't any fault of the company, but maybe of my own from last year. Since we started the project, there's very minimal documentation for it [laughs], and it's simple enough where you can get it figured out. But I think that was a little bit of a struggle trying to remember what I did and asking some people, like, “Did I do this right?” So, there's that. But something I thought was helpful was having some early low-hanging fruit tickets that got ready for us, basically. He had chosen them and said, “These are good tickets for you guys to kind of remember what you're doing or learn how to do things again,” so that was very nice. MIKE: Nice. Well, thank you. Now, we've talked to you all who just recently started at Acima. But we also have some others here on the call. Will has recently started a new position, so I think he's got some fresh onboarding stories in mind as well, and I think some others as well. So, go ahead, Will. WILL: Well, I've onboarded a lot, and I think, like, oh gosh, like, I'm getting through it. I mean, part of it, like, the biggest thing, I think, to keep in mind is you're just going to have to embrace the suck. You know, like, it's going to be bad, and it's always going to be bad. There's no comfortable way, I think, for, like, ordinarily high-achieving people who are used to not looking like an idiot to be real dumb and real helpless and completely ignorant for a period of weeks, if not months. There's just no...you know what I mean? Like, there's not a lot of, like, C minus students [laughs] getting onboarded, but, like, you're just going to have to take...you're going to have to take a bunch of Ls. And I’ve sort of, like, as I look...so, I mean, like, having done it, I always find the process really

In this episode of the Acima Development Podcast, host Mike is joined by Kyle, Matt, and Ryan to discuss how technical interviews are evolving in the age of AI tools like ChatGPT and Copilot. The conversation begins with a story about a candidate who plagiarized code during an interview—years before modern AI assistance—which sets the stage for a deeper discussion on integrity and how easy it now is to cheat during remote interviews. The group reflects on how traditional coding challenges and rote questions are becoming less effective, given the accessibility of fast, accurate answers online. Instead of focusing on textbook knowledge or code syntax, the team advocates for interview methods that prioritize problem-solving, communication, and curiosity. They emphasize the value of questions like “Tell me about a project you’re proud of,” or “When did you break production?”—questions that reveal depth of experience, passion, and the candidate’s ability to troubleshoot in real-world scenarios. They also suggest leaning into pseudocode or open-ended challenges that require candidates to explain their thinking, not just deliver a solution. These formats are harder to fake and better assess a person’s reasoning and learning capabilities. The conversation concludes with a shared sentiment that the role of engineers is shifting away from just knowing code toward applying it creatively and collaboratively to solve meaningful problems. Tools like ChatGPT can assist, but they can’t replace real understanding, adaptability, and team skills. For both candidates and interviewers, the core takeaway is clear: be honest, be curious, and focus on showing—not telling—how you think. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I have Kyle from our platform engineering team, who often joins us, and Matt from...well, you do a bunch of things, Matt [laughs]. He's a leader, I'll say that, and he's a director here at Acima, and is involved in doing a lot of things. I'd like to defer introducing the topic and tell a story. I'm going to do that for...oh, and we also got with us, oh, there we go. We've got Ryan, who's a delivery manager here at Acima and should have some great input. I'm going to start by telling a story. Oh boy, how long ago was this? Over, actually, I don't remember how long ago it was. I think [laughs] I don't even remember which company it was at [laughs], whether it was at Acima or not. I think that this was, like, 12 years ago, so I think this was prior to Acima. I was interviewing somebody, and I thought that I'd give him a coding test. It was a little hard to tell whether he knew what he was talking about or not. And I think I asked him to write some Ruby code that would output a Fibonacci sequence, output the first 10 digits of a Fibonacci sequence. And he said, "Okay,” and he just got quiet for a bit. This was a remote interview, by the way. I think he was overseas. I waited a couple of minutes. He came, and he dropped some code, and there it was, and it worked. It was weird. It was, like, weird code [laughs]. There's stuff that's idiomatically normal for the language that you're writing in. And this was Ruby code, but it barely looked like Ruby code. It looked like somebody had pulled it out of some other piece of code that was doing something else and then tweaked it. It barely fit. It was just really strange. And you don't usually write really strange code when you're on the spot. You're going to write something really simple. And you might have a couple of quirks, but you're not going to have something that's just really weird. So, I finished our interview, and I went and I Googled some of the code because it was weird enough that it was unique. I Googled for it, and it came up immediately on Google. He just copied and pasted from something he’d found online. And not only did he not get hired, but the contract shop he was coming with took a real ding because of that. There were some bad vibes thereafter [chuckles] between us and the shop because you sent us somebody, and he just cheated on the interview. That was before all of the AI tools that we've got now [chuckles], before ChatGPT. Think about all the changes that have happened over the past 15 years or so. This was prior to that, and still managed to cheat. Well, he didn't get away with it [laughs], but he still managed to cheat the interview. And that introduces our topic today. We're going to be talking about how to deal with technology, how to do interviewing in a world where we have technology now, where it makes it very easy for people to pull out answers quickly and hard to verify. This is more broadly applicable even outside of engineering, you think about in schools trying to do testing. It's a general problem. We're going to talk specifically about the software engineering world, because that's what we do, and how to do interviews. How to do your interviews broadly, but specifically, how do you do interviews when it's really easy to cheat? So, I've told a story about [chuckles] somebody doing that sort of thing. Any of you have some stories or similar experiences that you've had? MATT: Well, I don't know if I have a story. However, prior to this call, I was just conducting an interview. And something I think is really important, especially these days where a lot of people are working remote and interviews happen virtually, make sure their camera's on. And ask questions that, A, might not be as easy to Google, but require some conversation. And a demonstration of understanding of concepts, I think, is important. I think these days you have to dig a little bit deeper and ask the whys, just not the hows, on a lot of these technical questions. MIKE: I've had other interviews where I've asked somebody a question, a technical question that was a little broad about architecture, and they answered it really fast. He talked about extracting services, for example, to clean up code and decouple things. And they answered them really well and quickly on all of them, but their answers were brief. This was, like, they gave the right answer really quickly and then never elaborated. And I'm thinking about one example where this candidate did that repeatedly, all the right answers, one after the other, like, "Okay, they seem like a pretty good candidate." Then, when we actually employed them, they didn't seem to do anything [laughs]. They apparently were really good at either Googling the question or had researched interview questions before, so they knew what to say, but they didn't actually have the deep knowledge. They were able to give quick answers. So, one thing I've learned is a red flag, and you've touched on it, Matt, you've got to ask questions that allow them to elaborate. Talk about that “Why?” That conversation is hard to duplicate. You can't fake it in the same way. If you can come up with a tool that will do that, well, then you've got a tool that can maybe do the job, but we’re not there yet. MATT: Or if I have my phone with ChatGPT on listening in conversational chat, it's going to respond as fast as I could, right? And that makes it a little tricky. By the way, I think I was present in that same interview with you. MIKE: [laughs]. You may have been. RYAN: So, I guess the question here is, are you guys against using such tools like Google and LLMs, agents out there that an interviewee can use to answer your question? MATT: Well, I want people to have an understanding of what they're being asked. I use tools all the time to help me with my work, and that's just the way of the world these days, right? If tools are available, let's use them. But I need to understand what I'm doing, or the next problem that comes along, I'm not going to solve properly. And these tools are not a replacement for a human being. All of us have probably used Codepilot at some point, or Copilot at some point, or Cody, or something similar out there, right? That code needs review, and it doesn't always solve your problem the way that problem should be solved. So, yes, I support using tools, but if I'm hiring someone, I want them to understand the problems they're trying to solve. RYAN: And I think that is the crucial point here that we want to discuss is, like, because ChatGPT or any of the LLM model what do they do? They go and surf the internet, right? So, when you get your answer back, it doesn't know whether that's the right answer or not. It just knows that this is an example it found somewhere on the internet, right? And the person who put that together had to understand what they put together. So, when Mike said, "Well, this guy found that answer on the internet, and it worked.” So, why does it matter if it's strange? If he understands and he can explain why, so why does it matter at that point if it's strange? MIKE: Well, you hit on something important. If he had told me, "Well, I'm going to Google something and then talk about it," then that would have changed the whole conversation, and we might have even hired the guy. That's not what happened. He passed off the work as his own. MATT: Integrity is important. MIKE: Yeah. So, there's deception there. I expect people to Google for their job [laughs]. I think we've talked about it here. That's a key aspect of engineering. It's hard to do engineering without Google. I remember the first time I used it. My boss told me, “Go use Google.” RYAN: It's going to change the nature of how we do interviews because there's no way we can...even with camera on, and even if we ask the questions that need interaction, there's no way to prevent them from looking up information on the side screen. We can't see it. I mean, you can probably have a big enough screen with multiple windows open. You can do that right there and get away with it pretty easily. But I think the nature of the interview has to change. Inst

In this episode of the Acima Development Podcast, host Mike welcomes returning contributors Kyle, Will, and Dave for a lively and insightful discussion on communication and its failure modes—especially in engineering and development teams. Mike kicks things off with a humorous but illustrative story involving his children, hoverboards, cactus spines, and a major context mismatch with his wife. This leads into the first failure mode: people interpreting the same situation differently due to differing contexts. The group agrees that a lack of shared understanding often derails conversations and projects, especially when assumptions go unspoken or expectations aren’t clarified. Will and Kyle emphasize the importance of providing full context when asking for help or collaborating remotely, noting that even minor omissions can significantly delay progress. The conversation then shifts to another failure mode: assuming communication is complete after initial planning. They highlight how this mindset leads to integration issues near the end of projects—when it becomes clear that vital tasks or dependencies were overlooked. Dave tells a memorable story about a sound engineer who foresaw this issue and left a self-contained module called “OYWNS” (“Oh Yeah We Need Sound”) that could be plugged in later, exemplifying proactive thinking. However, the team debates whether these are truly communication issues or just planning failures, ultimately agreeing that both planning and communication must be iterative and responsive, especially in complex, cross-functional environments. Mike brings in the Agile principle of “customer collaboration over contract negotiation” as a more effective framework to reduce these last-minute failures. Toward the end, the group introduces a third major communication failure: speaking without tailoring the message to the audience. Whether it’s explaining unit testing to a non-technical relative using car analogies or trying to influence C-suite executives without drowning them in technical jargon, they agree that effective communication requires strategic translation, not just transmission. They also discuss how hierarchy and communication chains create distortion, using examples like long managerial handoffs or segregated teams that never speak directly. The episode closes with a call to action: be deliberate about context-sharing, break down silos, speak in your audience’s language, and ensure someone owns the responsibility of facilitating true collaboration. Transcript MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With us, we have long-standing contributor Kyle and Will Archer. Kyle Archer, Will Archer-no relationship to each other [laughs]. We have Dave Brady-- DAVE: Howdy, howdy. MIKE: Who hasn't been here for a little while, but he's here today. He's been out on leave because of some medical challenges, so we're really happy to have him here with us today. DAVE: I'm delighted to be vertical and to be here. MIKE: [laughs] DAVE: Yes, that was optional. That was an elective for me, was being vertical. So... MIKE: So, great having you with us, Dave. We are looking forward to having a good conversation. And speaking of conversation [chuckles], that's what we're talking about today. We're going to talk about communication and communication failure modes. I'm going to start, as usual, with a story, but I’ll introduce the topic first. To tell you a story...A few weeks ago, I got to do a little bit of setup here. So, you probably all know about hoverboards. They're not hoverboards, right? But it's like a Segway without a -- DAVE: Segway with no sticks? MIKE: With no stick, exactly. The self-balancing scooter that you stand on and move around. They're ubiquitous, especially among young people and kids, and they're all over the place. We’d had one in my house for several years, and the kids played with it, and they enjoyed it. My wife discovered something. You can put a seat on it, with a bar that comes out from it, and you put your feet on it. And it's got handlebars that you can lift up and down, two bars that you can lift up and down. So, you can adjust, you know, you can move it forward or back like you normally would by using your hands. And it makes it into, essentially, a little electric go-kart [laughs] because you've got a really low center of mass, you can just go full speed and have all kinds of fun. So, my kids at home, at Christmas, that’s what they all got, and they love it [chuckles]. There's a ring around my house that’s...[inaudible 02:32] dead. [laughs] They have flattened it so much, not every day, but often. And [laughs] they have a great time. So, that’s the first line. So, I’ve got to tell a couple of things that are going on here. In my office, I actually have a lot of cactus plants. Back during the depths of the pandemic, I had a little extra time and started doing some grafting experiments with cactus. It was fun. I've got quite a few cacti that I had some fun with that are now growing [chuckles] and taking up a lot of space in my office. But I like to take them outside in the summer. So, a few weeks ago, late spring, yeah, the weather was going to be good, so I started bringing out these cacti. And I've got the gloves on, but sometimes you get the spines and especially the little fine...they're called glochids. I don't know if you're familiar with them, but they're fine, little spines, and they fall off really easily. And they get in your gloves, and they get in everywhere. And they're really hard to pull out, and they're itchy and awful [laughs]. So, they just get in everything. They are very hard to get rid of. It's like sand in the car after you've been to the beach, you know, it’s everywhere. Same kind of thing, it gets in your gloves. So, I was bringing out these cactus plants, and I was getting more and more in my gloves, and my hands were getting itchier and itchier. And I got most of them upstairs, and my kids were out [inaudible 03:49] around the house on their hoverboards. And [chuckles] my four-year-old he comes up a lot in these stories because he’s a great source of stories. He ran his into a raspberry bush [laughs]. DAVE: Those are spiny. Oh. MIKE: They are very spiny. I think he even did it deliberately, like, "Oh, I'm going to run into the bush, see what happens." Ooh, and then he realized that was not good. And then, he blamed the scooter because he thought...and he blamed the bush, “That shouldn’t be there [laughs].” So, he was angry at his scooter and refused to get on it because he thought it would hurt him again. And so, he started chasing my daughter, wanting her scooter. And -- DAVE: Because her scooter has never driven him into the bushes. His logic checks out, yeah. MIKE: That’s exactly right. So, he's chasing her around the house, screaming. And I’m like, I should do something about this. But my hands are full of spines. And the thing is, I’ve been going up and down. My belt was kind of loose, and my pants had been falling down. So, I’ve got this series of problems: If I start running around the house, my pants are going to fall off. But if I try to take my gloves off and redo my belt or pull my pants up, I’m going to get spines all over my belly, which I don’t want. So, urgent situation. I can do nothing about it. So, I take off my gloves [laughs], set them down, lift up my pants, adjust the belt, and I’m about ready to go out. And my wife comes out, like, “Um... what are you doing?” I’m standing there with my belly hanging out [laughs] with my belt while my son is screaming. He’s really yelling out there. Somebody’s going to, like, call the authorities. There was a lot of context that was missed in this situation. And the way she was perceiving this situation was very different than the way I was perceiving the situation. We both knew there was a problem and me standing there I was trying to solve the problem. And [chuckles] it certainly did not look that way to her. DAVE: Right. “What are you doing?” “I'm spanking our boy. What does it look like?” [laughter] MIKE: Not the topic—not spanking—but that kind of situation is incredibly common, where one person has context, the other person doesn’t. And you may be thinking you’re talking about the same thing, but you’re not, because both of you see the situation so differently. And neither of us was wrong. She looked “There is a real problem going on here. Why aren’t you doing something about it?” I was thinking, “I am doing something about this real serious problem, and you’re not seeing it.” It was very cordial, by the way—no yelling at each other. She just was wondering, “What are you doing? [chuckles]” We worked it out. But this kind of idea where people see things differently it’s just everywhere. And I think it's one of these failures of communication, not just this kind, but there are a variety of these failures of communication failures that happen in engineering. And they are the problem, I would say [chuckles], with almost anything. It almost always comes down to some sort of communication failure. And I could tell stories, a variety of stories, and I probably will tell a few here. We're going to talk about, what are these communication failure modes, and what do we do about them? My introductory story gives an example, you know, different context. You may be talking about the same thing, but your context means you're seeing things very differently, and unless you resolve that, you’re not going to see eye to eye. There is one example. Feel free to run with that. I would like to hear from the panel here: What are some communication failure modes you’ve experienced, and what’s the underlying reason behind it, and what can you do about it? WILL: The biggest thing that jumps out at me when I think about sort of failure modes of communication is a lack of, I don't want to say respect, like