Acima Development

Mike Challis
  • 4.5 (2)
  • TECHNOLOGY
  • UPDATED BIWEEKLY

At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.

  1. Episode 93: The State of AI

    6D AGO

    Episode 93: The State of AI

    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:

    51 min
  2. Episode 92: Technical Hobbies

    FEB 18

    Episode 92: Technical Hobbies

    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 langu

    44 min
  3. Episode 91: Surviving This Job Market

    FEB 4

    Episode 91: Surviving This Job Market

    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? Ye

    52 min
  4. Episode 90: SQL as a Superpower

    JAN 21

    Episode 90: SQL as a Superpower

    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

    56 min
  5. Episode 89: Agentic AI

    JAN 7

    Episode 89: Agentic AI

    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

    48 min
  6. Episode 88: Balance

    12/24/2025

    Episode 88: Balance

    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 wor

    55 min
  7. Episode 87: Handling Miscommunication

    12/10/2025

    Episode 87: Handling Miscommunication

    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. Bu

    1h 3m
  8. Episode 86: Scary Code

    11/26/2025

    Episode 86: Scary Code

    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

    47 min
See All (93)

Ratings & Reviews

4.5
out of 5
2 Ratings

About

At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.

Information

  • Creator
    Mike Challis
  • Years Active
    2022 - 2026
  • Episodes
    93
  • Rating
    Clean
  • Copyright
    © 2026 Acima Development
  • Show Website
    Acima Development