Acima Development

Mike Challis
  • 4,5 (2)
  • TECHNOLOGIES
  • TOUTES LES 2 SEMAINES

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 91: Surviving This Job Market

    -5 J

    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
  2. Episode 90: SQL as a Superpower

    21 JANV.

    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
  3. Episode 89: Agentic AI

    7 JANV.

    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
  4. Episode 88: Balance

    24/12/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
  5. Episode 87: Handling Miscommunication

    10/12/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

    1 h 3 min
  6. Episode 86: Scary Code

    26/11/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
  7. Episode 85: Leading with Confidence

    12/11/2025

    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 ad

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

    29/10/2025

    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

    52 min
Tout afficher (91)

Notes et avis

4,5
sur 5
2 notes

À propos

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.

Informations

  • Création
    Mike Challis
  • Années d’activité
    2022 - 2026
  • Épisodes
    91
  • Classification
    Tous publics
  • Copyright
    © 2026 Acima Development
  • Site web de l’émission
    Acima Development