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 88: Balance

    2D AGO

    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 work done sometime, don't you [laughs]? MIKE: Well, and

    55 min
  2. Episode 87: Handling Miscommunication

    DEC 10

    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. But I have no idea, no idea how people who manag

    1h 3m
  3. Episode 86: Scary Code

    NOV 26

    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's a thing called the system process table. This is 20 y

    47 min
  4. Episode 85: Leading with Confidence

    NOV 12

    Episode 85: Leading with Confidence

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

    55 min
  5. Episode 84: When Not to Follow Best Practices

    OCT 29

    Episode 84: When Not to Follow Best Practices

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

    52 min
  6. Episode 83: Outside-Work Programming Projects

    OCT 15

    Episode 83: Outside-Work Programming Projects

    In this episode of the Acima Development Podcast, Mike kicks things off with a cycling story that serves as an analogy for problem-solving in software engineering. Planning a long ride to Illinois’s highest natural point, he had to carefully map his route with handwritten directions before realizing he could quickly write a small program to calculate distances. The story highlights how coding, even outside of professional contexts, provides practical tools for organizing complexity and solving problems efficiently. This segues into the episode’s theme: the value of side projects as creative outlets that both challenge and refresh developers beyond their day jobs. Dave picks up the discussion by sharing his own side projects, ranging from building automated tools for games like Minecraft to recursive Sudoku solvers. He describes his habit of scripting repetitive tasks at work and how tinkering with small, often quirky coding challenges keeps his skills sharp. Will chimes in with his perspective on solving Sudokus using deduction instead of brute force, sparking a lively debate about problem-solving strategies and approaches to recursion. They also discuss playful experiments like writing adventure games in SQL or porting Doom into Postgres—projects that might not have practical business value but showcase curiosity, resilience, and creative problem-solving, traits they argue are vital in startup or complex development environments. Later, the conversation broadens beyond coding to explore balance, curiosity, and learning from outside experiences. Will reflects on being new in a role and choosing not to code outside of work, instead focusing on absorbing context, leadership, and finding inspiration in non-technical pursuits—whether it’s parenting, reading fiction, or woodworking. Dave shares his experience building cigar box guitars, while Mike recalls colleagues whose hobbies, from rose gardening to counseling, enriched their professional lives. They conclude that having creative or restorative pursuits outside of work—whether technical side projects or entirely different hobbies—ultimately strengthens problem-solving skills, resilience, and perspective in software engineering. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. Dave and I are going to do kind of a joint hosting thing today. DAVE: Hello. MIKE: We've got Dave Brady here, and we've got Kyle, and we've got Will Archer. Actually [chuckles], we've got the Archers [laughs]. WILL: No relation. MIKE: [inaudible 00:00:37] relation [chuckles], Kyle and Will. But the four of us are here today, and I'm going to start with a story. As Dave and I were talking, we were kind of debating on the pre-call who was going to host today. And we're both going to do this, but I've got the story. I've got the story. So, that's [laughs] why I [inaudible 00:00:57]. I have mentioned before that I've done a lot of cycling. I won't go too deep into it. I've done a lot with my kids, which has actually helped strengthen me. And, occasionally, I've gone out solo and had these great, long rides. I went on a long ride a couple of weekends ago. And the ride itself is not where I'm going here. But ahead of the ride, I needed to find out the route. I was planning a new way I'd never been before. I went to the highest point in Illinois [laughter]. DAVE: 12 feet above sea level? WILL: 13, baby. 13. DAVE: 13? MIKE: Okay. So, I misspoke. I went to the highest natural point in Illinois. The highest point in Illinois is not actually a natural point. It's the top of a high-rise in Chicago. WILL: Is it a tower? DAVE: Like the Sears or whatever, yeah. MIKE: Yeah. It’s now called the Willis Tower. DAVE: Is it still -- MIKE: It's called the Willis Tower. DAVE: Willis Tower. Is it still the tallest? MIKE: It is. But there is a...the highest natural point in Illinois is called Charles Mound. It's 1,235 feet, which my house is about 800 feet, so it's not that much higher. Except it's a ways away, so it's more about the distance. Okay, I'm going to detour slightly. It actually is relevant here. It's in a part of the Midwest known as the Driftless Area. That's sometimes just called driftless. They could put different words after driftless, but driftless is the key word. It was unglaciated during the last ice age. So, unlike what you'd normally think about as the Great Plains, which are made by glaciers scouring everything flat, it is not scoured flat, and it is actually extremely hilly, not mountains, but exceptionally hilly [laughs]. And this high point is actually just, like, a half mile from the Wisconsin state line. Wisconsin has this as well, this very hilly area. And there's rivers that cut deep canyons in between high hills on both sides, hundreds of feet high. And to get there [chuckles], I had to wind away through back roads through this hilly area, which means that there were a lot of turns. And if you ever tried using Google Maps, it only lets you get to, like, 10 steps along the way, and then it just bails. Like, nope, that's all you can do. And so [chuckles], that wasn't going to work. I actually did it in sections, and I carefully wrote down the turns and the distances between each one of them in a document. And I built this all out in just a text document because I'm a software engineer. That's what I do; I write it out in a text document. And [chuckles] I got through it. And there was one point there was an alternate. I wasn't sure if I was going to be able to go [inaudible 03:39] because it was just, like, a farm road, literally through a farm. But there were no signs posted, and Google said to go that way, and it was actually in Google Maps with Street View. I'm like, okay, well, I'm going to do it, and I did. It was beautiful, by the way [laughs], and it was fine. Nobody yelled at me. I wasn't sure [inaudible 03:55] way. So, you know, it was a text file, but there was some weird stuff in it. I got through it and said, okay, so how many miles is this? And [chuckles] what am I going to do? Hey, I will just write some code, so I did. I pulled up a console, and I had my answer in, like, three or four minutes. I had to do a little bit of cleaning to sanitize some of it, remove some of the stuff, and put it all together. And it reminded me just how useful code can be. It allows you to do amazing things to solve problems. This was something far afield of normal software engineering work, and it still ended up [inaudible 04:33]. I'm going to use code as a tool here, and it allowed me to solve the problem quickly. If I had tried to add that up by hand on a calculator, I don't want to think about that. Maybe I could use a spreadsheet, right [chuckles]? But then I would have to deal with all the edge cases in there because there's the alternate routes that would have been a pain. Pulled it off quickly just by writing some code. It's an amazing tool that helps us in many things. And today, we're going to be talking about our side projects. Normally, we talk about our day job, but we thought today we'd dig a little bit into the things we've been working on outside of work and how that's going. And it gives kind of some context to our day-to-day because these side projects tend to be weird [chuckles]. They’re the miles that you get to a high point. They just are way different than your normal work, which makes them fun. It breaks up the monotony. There's my story. And I've got a couple of other things I've worked on recently that I may bring up, but I'm going to start with that. Dave, over to you. DAVE: Well, I don't want to follow up story time with Uncle Mike with story time with Uncle Dave, but here we are. MIKE: [laughs] DAVE: So, I'm constantly writing stuff. My career hack for people is, if you have the time, which most people you got to decide. We all get 24 hours a day. But I no-lifed programming for most of my 20s and 30s. I would go to work. I would work all day. I would go home. I would keep writing code. And insert story about mental health here. Work-life balance was something for other people to do. And what I found is that there's not a problem...there's not an interesting question that I can come up with that I usually can't immediately think, I wonder if I could solve that with a computer? Off the top of my head, without going into full-on stories, although I might tell the clicker story because we can talk about AI for research as part of writing custom stuff. But in the last 30 days, I have worked on a planner sheet thing that literally people listening at home won't be able to see this. But if you've ever looked like a Franklin-type, you know, day planners, that kind of thing. So, I figured out how to make a program, draw it out, fill in all the dates and times, and send it off to the printer. I built an auto clicker for Minecraft because I was AFKing and needed resources. The other weird one, and this is harder than it sounds, or no, this is exactly as interesting as it sounds, is trying to calculate the cost of a recipe in Minecraft. If you want to build sticks, right, you need two boards to build four sticks. But to get two boards, you need one log, and that makes four, and there's, like, surplus numbers. And if you want to build, like, some of these late game, really complicated things, you can have these build palettes that are, you know, with thousands of blocks that you have to know what you need. And normally, we just stand next to the crafting table, next to your inventory, and just pull what you need and build the next piece. And you just keep, do I have what I need? And on the other times, sometimes I'm like, no, I want to know how many, you know, how many chest full of, you know, cracked bricks do I need to have ready to go before I start this? And being able to say, “I want three of these, but it's made up of this many of that,” you can see very quickly, like, this nested hash of, like

    32 min
  7. Episode 82: ORMs vs SQL

    OCT 1

    Episode 82: ORMs vs SQL

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

    45 min
  8. Episode 81: How Do I Invest Engineering Time?

    SEP 17

    Episode 81: How Do I Invest Engineering Time?

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

    58 min
See All (88)

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 - 2025
  • Episodes
    88
  • Rating
    Clean
  • Copyright
    © 2025 Acima Development
  • Show Website
    Acima Development