Episodes

  • Episode 89: Agentic AI

    Episode 89: Agentic AI
    Jan 7 2026
    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...
    Show More Show Less
    48 mins
  • Episode 88: Balance

    Episode 88: Balance
    Dec 24 2025
    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 ...
    Show More Show Less
    55 mins
  • Episode 87: Handling Miscommunication

    Episode 87: Handling Miscommunication
    Dec 10 2025
    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....
    Show More Show Less
    1 hr and 3 mins
  • Episode 86: Scary Code

    Episode 86: Scary Code
    Nov 26 2025
    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 ...
    Show More Show Less
    47 mins
  • Episode 85: Leading with Confidence

    Episode 85: Leading with Confidence
    Nov 12 2025
    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 ...
    Show More Show Less
    55 mins
  • Episode 84: When Not to Follow Best Practices

    Episode 84: When Not to Follow Best Practices
    Oct 29 2025
    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 ...
    Show More Show Less
    52 mins
  • Episode 83: Outside-Work Programming Projects

    Episode 83: Outside-Work Programming Projects
    Oct 15 2025
    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 ...
    Show More Show Less
    32 mins
  • Episode 82: ORMs vs SQL

    Episode 82: ORMs vs SQL
    Oct 1 2025
    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 ...
    Show More Show Less
    45 mins