Episodios

  • Episode 82: ORMs vs SQL

    Episode 82: ORMs vs SQL
    Oct 1 2025
    The panel digs into the perennial question: how much SQL should developers know? Kicking off with a war story, Mike recounts a hyper-growth phase where ~20 performance issues were fixed—almost all by database changes, especially adding (or rethinking) indexes—yielding order-of-magnitude speedups. The moral: ORMs are great for safety and productivity, but when things get slow, it’s “usually the database,” and knowing how indexes, JOINs, and query patterns work is what unblocks teams. Will adds a blunt rule of thumb: apps are slow because of “bytes on the wire” or “the database,” and you can’t rely on ORMs alone to prevent N+1s or inefficient access patterns. From Ops, Kyle reinforces that troubleshooting still lands on SQL: monitoring tools can point to hot spots, but root-causing and backups often require direct database savvy. Eddy shares a counterexample: moving search from Elasticsearch to Postgres full-text revealed that a GIN index on a high-churn table actually slowed writes—illustrating the trade-off that heavier indexing speeds reads but taxes inserts/updates. The group also debates concurrency: for most web apps, you can push work “down the stack” to the database and avoid complex threading; true low-latency, hard real-time concurrency is rarer than many think. Stepping back, the crew frames SQL as a declarative, optimization-friendly paradigm—closer to functional transforms than procedural loops—which is precisely why database engines can do so much heavy lifting. Resources like SICP and Lisp/Scheme are recommended for learning to “think in streams” and transformations. The consensus: programming languages and frameworks come and go, but SQL endures—and senior engineers still write ad-hoc queries daily to answer business questions and debug production. They close with a teaser for next time: a lively debate about testing private methods and how to design for testability without committing “crimes” against your runtime. Transcript: DAVID: Hello, and welcome to the Acima Development Podcast. I'm David Brady, your host today. And we've got a fun panel today. We've got Kyle; we've got Eddy; we've got Mike; we've got Will, and we've got Matt Hardy. Welcome, Matt. Nice to see some new people, well, not new, recurring people. We don't have anybody new, new, new, but nice to see the regulars. Today we're going to talk a little bit about SQL. Like, do developers need to know it, and if so, how much? And this came as a suggestion from Kyle, who works more in ops rather than frontline web dev. And so, I'm very interested in hearing where he wants to go with this. But first, as our tradition, let's start with some story time with Uncle Mike. Mike, what do you know about SQL? MIKE: [laughs] So, I do have a story, and I was prepared for this. A few years ago, I say a few, at least five years ago, maybe five or six years ago, I was in a big application that was growing up [chuckles]. We were actually getting a lot of traffic where we hadn't been. It's the startup journey, right? And this actually was at Acima, you know, as we were in our rapid growth era, not that we're not still growing, but, you know, back in the startup days. And it's natural for every application, once you start going through that growth period, like, oh, wait, there's some things that don't work very well, let me say, that don't perform very well, that don't perform very well. There's things that work just fine when you had a data set of a thousand that don't work very well when you've got a data set of a million [laughs]. Things just don't work quite the same anymore. And so, I went through with the team, and we worked on that for maybe a couple of months. And over that couple of months, we made the application run about 10 times faster, which is a big deal, right [laughs]? That's a major performance impact. I think it was more than 10 times. I mean, it was a big deal. You know, going to 10 times faster has a big effect on your infrastructure, and I think it even went even beyond that. But I kind of quit keeping track after a while [chuckles] because it's, you know, you start resetting your baseline. Okay, well, we got to go faster than that, got to go faster than that. It’s not the only time I've done this, right? It's just the most recent time that I have fresh in mind. And one thing we found is...let me say a couple of things. Every single one of the performance improvements we made, except for one, were database improvements, and most of them were adding missing indexes. So, there's a database table missing an index, and, by the way, it's always a missing index. If you have a performance problem, it's a missing index [laughs]; I'm just going to say that, except there was a couple of them that weren't. A couple of them were some kind of weird cases. There was some really gnarly JOINs. It was running, like, JOIN against 10 things using a lot of LIKE queries. We fixed that one by using an ...
    Más Menos
    45 m
  • Episode 81: How Do I Invest Engineering Time?

    Episode 81: How Do I Invest Engineering Time?
    Sep 17 2025
    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 ...
    Más Menos
    58 m
  • Episode 80: How Is a Big Project Different from a Small One?

    Episode 80: How Is a Big Project Different from a Small One?
    Sep 3 2025
    In this episode of the Acima Development Podcast, Mike hosts a roundtable with Eddy, Dave, Chloe, Jordan, Ramses, and later Will, to explore the differences between small and large projects. Mike kicks things off with a personal story about industrial dishwashing as a teenager and how that shifted his perspective on “small” problems like doing dishes at home. He ties this to software by noting that scale fundamentally changes how you approach problems, whether that’s navigating your neighborhood versus traveling cross-country, or building a small app versus managing a complex, multi-team system. The theme: what works at one scale may feel trivial or even inadequate at another. The conversation then moves into real-world engineering trade-offs. Dave contrasts working in application development versus database engineering, where different constraints (compute vs. storage) flip what’s considered efficient. Eddy stresses the importance of incremental, low-risk changes in large systems, while Chloe shares how her internship taught her that upfront design decisions carry far more weight in big projects than in small, flexible ones. Will and others riff on the “temptation of perfection”—the idea that if you just planned enough, you’d get everything right upfront. Instead, they argue for agile approaches: accept mistakes as inevitable, design for change, and value rework as part of progress. Several panelists tie this to the importance of embracing ignorance, asking “stupid” questions, and adopting a growth mindset to avoid paralysis when decisions inevitably prove imperfect. The group also digs into the human dimension of scale: coordination. Jordan notes that large projects require consensus and approvals, whereas small projects let you move unilaterally. Mike reframes bureaucracy as a natural outcome of needing structured communication and shared understanding, not just red tape. Dave and Will debate decision-making heuristics—how long to defer choices, what counts as “enough information,” and how to balance planning versus execution. They conclude that small projects build the fundamental skills and intuition needed for larger systems, while big projects demand humility, adaptability, and collaboration. Ultimately, the episode emphasizes that success isn’t about perfect planning but about making good-enough decisions, coordinating effectively with others, and being willing to course-correct as conditions change. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I've got Eddy, Jordan, Dave, Chloe, and Ramses. Now, Jordan and Chloe are our interns. You all were on before, right [chuckles]? CHLOE: Yeah. MIKE: So, it's not the first time. It's not the first time here. But today is the last day of the internship that we had for this summer. And as a result, we're choosing a topic that I thought would be really relevant, something that we've talked about some with the interns, if they can give us some insight as to what they've learned. And having somebody new on a problem often reveals things that other people don't see. That's why sometimes grad students make good teachers [chuckles]. They're fresh to it, you know, they haven't been so distanced. So, I'm really interested in hearing about this. Notice I haven't mentioned the topic yet. I'm going to give a little intro to introduce here. And I'm going to talk about a summer in my teen years where I worked at a Mexican restaurant [laughs] washing dishes, not just washing dishes. They also made me a prep cook and I heated up, like, beans [laughs]. But I washed a lot of dishes, and this was, you know, industrial dish washing. You can imagine what the pans looked like after they've been cooking whatever Mexican food they were cooking [laughs]. Just imagine, you're probably right. EDDY: Did you use a pressure hose? It's probably the best way to clean dishes, especially large dishes. MIKE: So, we had two things that happened. So, there was the customer dishes that came in, and those we had a big industrial dishwasher that we kind of did a conveyor belt style. You’d load them in, and they’d go in there, and they’d steam, and spray a bunch of water, and that worked pretty well. Except if you have, like, cheeseburgers, you know, cheese would melt onto it and stick to the plates [laughs]. I see Chloe smiling. She may have done this before [laughs]. And on the other side of the area where we did the washing, there was a series of three sinks, and that's where all of the stuff from the cooks, right, that's where that stuff would get cleaned. And that was the gnarly stuff. And a pressure hose...there was nothing that would take gunk off a pan when it first came over. And this wasn't, like, very authentic Mexican food [laughs]. They had, like, I don't know if it was blackened, you know, Cajun, but along those lines kind of fish that they would do. And they...
    Más Menos
    55 m
  • Episode 79: Evaluating Vendors

    Episode 79: Evaluating Vendors
    Aug 20 2025
    This episode of the Acima Development Podcast focuses on the complexities of evaluating and selecting vendors, whether for software, contract labor, or specialized services. Host Mike opens with a cautionary tale about a vendor that initially impressed with a knowledgeable representative but turned out to have major security flaws, poor integration practices, and overall incompetence once the contract began. The group discusses how this mirrors a broader challenge—companies often get only a brief, curated glimpse of a vendor before committing, with little opportunity to see the full team’s capabilities. This leads to a conversation about the importance of scale in vendor choice: a large enterprise might thrive with a feature-rich, expensive solution, while a startup could be better served by a smaller, more agile provider. Needs change over time, and the vendor that fits now may not be the one you need later. The conversation then shifts to the vendor-client relationship from multiple perspectives—Mike, Dave, Will, Eddy, and Kyle all share stories from both sides of the table. Will highlights the unstable economics of contract shops and the difficulty in sustaining top talent, while Eddy points out the importance of assessing a vendor’s responsiveness to feature requests. Kyle and Mike discuss how larger organizations often limit vendor options through partnerships, which can lead to compromises in quality or fit. The group also addresses the consolidation push in big companies, where leadership may favor a single vendor for cost control, even if that means losing specialized capabilities. They emphasize balancing department needs, cost implications, and redundancy to avoid single points of failure. The episode wraps with a practical checklist of red and green flags. Red flags include security issues, legal troubles, impossible promises, conflicts of interest, overreliance on one “all-star” representative, and immature products. Green flags include a vendor that’s “boring” (reliable and consistent), mature, used successfully in your industry, and willing to connect you with your actual account rep. The hosts stress building vendor-agnostic integrations to allow easier pivots in the future, negotiating service levels, and reevaluating relationships regularly. Final advice: know your needs, verify vendor claims, plan for change, and avoid long-term dependencies on critical functions that should remain in-house. Transcript: MIKE: Hello, and welcome to the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me today, I have Kyle. I've got Dave. DAVE: Hello. MIKE: We've got Will Archer, and we've got Eddy. And we are going to be talking about something that comes up over and over again in the industry. And I'll just jump right into it [chuckles]. We're going to be talking about how to evaluate a vendor. We talked about build versus buy, I don’t know, a few weeks ago, maybe a couple of months ago. Today, we're going to go specifically into strategies when you do decide to buy. And this also applies even if you're going to go with, like, an open-source project. How do you evaluate the vendor? You know, how do you choose when there's a variety of options? And story time. Years ago...I think I can be a little open about this because the company isn't even in business anymore [laughs]. I worked for a company that did content management for publishers, mostly newspapers-newspapers and magazines, small newspapers. There's a lot of them out there actually. And we did a lot of their websites. And we were evaluating a partner, like, a business website builder. That's a common thing out there. There's lots of ways you can get your content out on the internet [chuckles]. And there are some niche products that allow you to do it in a specific way. We were looking for a partner to do it in this niche way. And I'll get a little bit into the business model because it actually is interesting. With the newspaper industry, sometimes people think it was killed by other media, and that's a little bit true, but not really. Newspaper industry was killed by Craigslist because they made their money off of classified ads. If you're old enough, you remember that when you used to want anything, you'd go get a newspaper. When you needed something like an apartment to go rent, for example, you'd go get the newspaper because everybody in the community knew it was there. All the business in the community knew it was there, and so they published there. And we were trying to come up with a way to kind of preserve that model where businesses could have a permanent presence within the newspaper website. And we were working with a partner to help with that. There was a friend of somebody in the executive suite who had a company to do something that was loosely associated with what we wanted to do, who said, “Hey, we'll just use my buddy's company.” And they sent a tech rep over to get some evaluation....
    Más Menos
    1 h
  • Episode 78: Building Company Culture

    Episode 78: Building Company Culture
    Aug 6 2025
    In this episode of the Acima Development Podcast, host Mike opens with a gardening metaphor to frame the episode’s central theme: cultivating healthy company culture. Drawing from his personal experience transforming barren soil into fertile ground, Mike contrasts short-term fixes like chemical fertilizers with long-term strategies like feeding the soil itself—likening these to how companies often rely on perks or high salaries to attract talent rather than investing in sustainable, growth-focused environments. This sets the stage for a broader conversation about what truly nourishes both plants and people—ecosystems, relationships, and meaningful investment. The discussion evolves into a rich conversation among remote team members, including Justin, Javier, Jorge, and Will, who share their experiences working in international and distributed environments. They highlight the importance of communication, inclusive documentation, and feeling culturally and professionally supported. Javier and Jorge reflect on challenges faced by Latin American contractors, including language barriers and differing communication styles. They emphasize that well-documented processes and clear expectations can bridge time zones and cultural gaps, especially when employees are empowered to grow and contribute meaningfully. The group critiques superficial attempts at building culture, such as gift cards and perks, and stresses the importance of leadership that fosters personal growth, purpose, and strong communication. Leaders who spend time mentoring, understanding their teams, and clearing barriers can create “fertile soil” where people thrive. Whether it’s through offering growth opportunities, creating psychological safety, or enabling people to do impactful work, the team agrees: you can’t shortcut your way to a strong company culture. You have to invest in it intentionally, consistently, and with heart. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With me today I have Justin and Javier. And this should provide some good perspectives. Justin previously worked for Acima [laughter] [inaudible 00:39] and is now elsewhere; I'll leave unnamed [laughs]. Javier is a contractor that works outside the office, outside the country, which will provide some good perspective because we'll get good perspective to the topic today. I'm going to announce the topic in a minute [laughter]. Although you could probably see it from the title of the podcast recording but, you know, at least I'll pretend to leave some suspense there [laughs]. JUSTIN: I'm looking for a good story, Mike [laughter]. MIKE: I'm going to talk about my garden. JUSTIN: Oh. MIKE: I've enjoyed gardening since I was a kid. I like growing things. I like being outside. I do have a garden. To be honest, it's maybe a little neglected as of late, but [chuckles] I do have a garden. And I say neglected, I've let some things grow and spread. So, I've got a big patch of raspberries, for example, because I love raspberries. What's wrong with letting the raspberries spread [chuckles]? They're delicious. I've got quite a bit of garlic, and I've got some other berries. I’ve got some goji berries, some garlic chives. So things that have kind of spread some, but I like them, so it works great. And I have a lot of kale because I love kale. I eat kale every day. I've read a lot about gardening. I, at one point, considered changing careers. I was going to work for a gardening company on their tech side for a while. I didn't end up doing that, but strongly considered it. And my original major was botany, so definitely very interested in this topic. I've got, like, a hundred cactus plants in my office that I love. Most of them I grew from seed [laughs]. I like plants. Pandemic, you know [laughter]. So, I'm going to talk about a thing that people regularly get wrong, and even to the point of agriculture sometimes gets wrong, and they're turning from this. And there's been a turn over the last few decades to fundamentally shift the way people think about not just gardening but farming. Where I live, I have quite a bit of farms nearby. In the state of Illinois, there's a lot of corn and soybeans. If you've ever been there, you know what I'm talking about [laughs]. There's a lot of corn and a lot of soybeans. They used to just plow everything under every year or just treat the waste from the previous year's corn and soybeans as waste, and just kind of ignore it, let it blow away. And when they’d till it under in the fall, the soil would blow away all winter. And there's places you can go and they'll show you how deep the topsoil used to be and how deep it is now [laughs]. On the rest stops on the side of the road, they'll show you how much topsoil has been lost because it's a big deal, like, half or more of the topsoil has been lost in areas. And it's a really serious problem because now you ...
    Más Menos
    46 m
  • Episode 77: Onboarding Yourself

    Episode 77: Onboarding Yourself
    Jul 23 2025
    In this episode of the Acima Development Podcast, Mike kicks things off with a humorous comparison between the DMV and employee onboarding, using the DMV’s predictability as a metaphor for what onboarding should feel like: smooth and well-organized. The team, including interns Chloe and Jordan, along with veteran team members like Will, Matt, and Tim, dives into the realities of onboarding experiences. Chloe and Jordan reflect on the value of strong documentation, access to multiple mentors, and feeling emotionally supported. They emphasize how overwhelming onboarding can be when information overload hits or support is unclear, and how even small gestures, like developer lunches or Slack channels, can make a big difference in building comfort and connection. The discussion expands to include insights from more senior voices like Will and Matt, who underline the psychological and emotional complexity of onboarding, particularly for seasoned professionals used to excelling. Will points out that new hires, especially mid-career professionals, often face an identity crisis when they’re suddenly inexperienced again, and that trust between leadership and new employees must be earned, not assumed. He stresses the importance of proactive communication, asking questions, and building relationships over time. Meanwhile, Matt emphasizes that leaders must take responsibility for initiating that trust and creating a culture of safety and availability, even if time and organizational bandwidth are constraints. Finally, the group turns to strategies for remote and global onboarding, with Tim detailing Microsoft’s best-in-class processes that pair automation with strong support systems. The consensus is that technical logistics like IAM provisioning and documentation matter, but they’re not enough on their own. What truly shapes a successful onboarding experience is human connection: pairing new hires with mentors, creating safe spaces for questions, recognizing cultural differences, and setting realistic expectations. The episode closes with a collective realization that while automation can streamline processes, it’s trust, empathy, and communication that ultimately empower new team members to thrive. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. We've got a good crew here today. We've got Tim, Kyle, and we've got a couple of interns who are joining with us today¬¬—Chloe and Jordan, great having you. I’m excited to hear your input. It's very topical for today. We have Justin and Dave, and, finally, Will Archer, the crew here. I think I got everybody. Did I get to you, Kyle? I think I mentioned you. If not...[laughs] Let's start with an ordeal I'm going to have to go through in the next couple of weeks. So, it's been five years or so since I last renewed my driver's license, so I have to go to the DMV next week [laughs]. JUSTIN: I want to see how you're going to tie this together with new hires. This is going to be really entertaining. [laughter] MIKE: People do not look forward to going to the DMV. There's an old song that comes to my mind that says, "I've been to hell. I spell it DMV [laughs]." I think of that every time. I went and looked up the lyrics. There's some other lyrics in that song I'm not going to share [laughs]. I'm going to point out the reference. But it makes a point that I think most of us tend to agree with. However, when I go to the DMV, I know exactly what to expect because they have done this a million times, right? Maybe literally a million times, maybe more than a million, you know, many millions in a large state. They just do this over and over again. So, they have a routine. I know I walk in there. I'm going to get the number, and then they're going to send me down to a seat and wait for who knows how long [laughs]. They might have one of those little counters to let me know when the number is coming. At the one DMV I would go to, there's, like, three different desks, so there's actually three different lines [laughs]. You have to know which one you're getting to. But they have signs. They've got tape on the floor that sends you to the right direction. And then when they call you up, they've done this so many times that the people there they don't even, like, see your face anymore [laughs]. They just walk you through the routine. And it's so standardized because they need to make sure that it always works every single time. And it generally does [chuckles], as long as you didn't forget to bring whatever document you needed to bring, and then they send you to the back of the line or send you home [chuckles], and you have to come back. If you get everything right, it just works because they've totally standardized that process. Now, it's totally impersonal, and [chuckles] you wait forever sometimes, and nobody likes that. I have heard that they've got, like, some...There are offices in Utah, and...
    Más Menos
    1 h
  • Episode 76: Interviewing in the AI Era

    Episode 76: Interviewing in the AI Era
    Jul 9 2025
    In this episode of the Acima Development Podcast, host Mike is joined by Kyle, Matt, and Ryan to discuss how technical interviews are evolving in the age of AI tools like ChatGPT and Copilot. The conversation begins with a story about a candidate who plagiarized code during an interview—years before modern AI assistance—which sets the stage for a deeper discussion on integrity and how easy it now is to cheat during remote interviews. The group reflects on how traditional coding challenges and rote questions are becoming less effective, given the accessibility of fast, accurate answers online. Instead of focusing on textbook knowledge or code syntax, the team advocates for interview methods that prioritize problem-solving, communication, and curiosity. They emphasize the value of questions like “Tell me about a project you’re proud of,” or “When did you break production?”—questions that reveal depth of experience, passion, and the candidate’s ability to troubleshoot in real-world scenarios. They also suggest leaning into pseudocode or open-ended challenges that require candidates to explain their thinking, not just deliver a solution. These formats are harder to fake and better assess a person’s reasoning and learning capabilities. The conversation concludes with a shared sentiment that the role of engineers is shifting away from just knowing code toward applying it creatively and collaboratively to solve meaningful problems. Tools like ChatGPT can assist, but they can’t replace real understanding, adaptability, and team skills. For both candidates and interviewers, the core takeaway is clear: be honest, be curious, and focus on showing—not telling—how you think. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I have Kyle from our platform engineering team, who often joins us, and Matt from...well, you do a bunch of things, Matt [laughs]. He's a leader, I'll say that, and he's a director here at Acima, and is involved in doing a lot of things. I'd like to defer introducing the topic and tell a story. I'm going to do that for...oh, and we also got with us, oh, there we go. We've got Ryan, who's a delivery manager here at Acima and should have some great input. I'm going to start by telling a story. Oh boy, how long ago was this? Over, actually, I don't remember how long ago it was. I think [laughs] I don't even remember which company it was at [laughs], whether it was at Acima or not. I think that this was, like, 12 years ago, so I think this was prior to Acima. I was interviewing somebody, and I thought that I'd give him a coding test. It was a little hard to tell whether he knew what he was talking about or not. And I think I asked him to write some Ruby code that would output a Fibonacci sequence, output the first 10 digits of a Fibonacci sequence. And he said, "Okay,” and he just got quiet for a bit. This was a remote interview, by the way. I think he was overseas. I waited a couple of minutes. He came, and he dropped some code, and there it was, and it worked. It was weird. It was, like, weird code [laughs]. There's stuff that's idiomatically normal for the language that you're writing in. And this was Ruby code, but it barely looked like Ruby code. It looked like somebody had pulled it out of some other piece of code that was doing something else and then tweaked it. It barely fit. It was just really strange. And you don't usually write really strange code when you're on the spot. You're going to write something really simple. And you might have a couple of quirks, but you're not going to have something that's just really weird. So, I finished our interview, and I went and I Googled some of the code because it was weird enough that it was unique. I Googled for it, and it came up immediately on Google. He just copied and pasted from something he’d found online. And not only did he not get hired, but the contract shop he was coming with took a real ding because of that. There were some bad vibes thereafter [chuckles] between us and the shop because you sent us somebody, and he just cheated on the interview. That was before all of the AI tools that we've got now [chuckles], before ChatGPT. Think about all the changes that have happened over the past 15 years or so. This was prior to that, and still managed to cheat. Well, he didn't get away with it [laughs], but he still managed to cheat the interview. And that introduces our topic today. We're going to be talking about how to deal with technology, how to do interviewing in a world where we have technology now, where it makes it very easy for people to pull out answers quickly and hard to verify. This is more broadly applicable even outside of engineering, you think about in schools trying to do testing. It's a general problem. We're going to talk specifically about the software engineering world, because that's what we do, and how ...
    Más Menos
    43 m
  • Episode 75: Communication Failure Modes

    Episode 75: Communication Failure Modes
    Jun 25 2025
    In this episode of the Acima Development Podcast, host Mike welcomes returning contributors Kyle, Will, and Dave for a lively and insightful discussion on communication and its failure modes—especially in engineering and development teams. Mike kicks things off with a humorous but illustrative story involving his children, hoverboards, cactus spines, and a major context mismatch with his wife. This leads into the first failure mode: people interpreting the same situation differently due to differing contexts. The group agrees that a lack of shared understanding often derails conversations and projects, especially when assumptions go unspoken or expectations aren’t clarified. Will and Kyle emphasize the importance of providing full context when asking for help or collaborating remotely, noting that even minor omissions can significantly delay progress. The conversation then shifts to another failure mode: assuming communication is complete after initial planning. They highlight how this mindset leads to integration issues near the end of projects—when it becomes clear that vital tasks or dependencies were overlooked. Dave tells a memorable story about a sound engineer who foresaw this issue and left a self-contained module called “OYWNS” (“Oh Yeah We Need Sound”) that could be plugged in later, exemplifying proactive thinking. However, the team debates whether these are truly communication issues or just planning failures, ultimately agreeing that both planning and communication must be iterative and responsive, especially in complex, cross-functional environments. Mike brings in the Agile principle of “customer collaboration over contract negotiation” as a more effective framework to reduce these last-minute failures. Toward the end, the group introduces a third major communication failure: speaking without tailoring the message to the audience. Whether it’s explaining unit testing to a non-technical relative using car analogies or trying to influence C-suite executives without drowning them in technical jargon, they agree that effective communication requires strategic translation, not just transmission. They also discuss how hierarchy and communication chains create distortion, using examples like long managerial handoffs or segregated teams that never speak directly. The episode closes with a call to action: be deliberate about context-sharing, break down silos, speak in your audience’s language, and ensure someone owns the responsibility of facilitating true collaboration. Transcript MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With us, we have long-standing contributor Kyle and Will Archer. Kyle Archer, Will Archer-no relationship to each other [laughs]. We have Dave Brady-- DAVE: Howdy, howdy. MIKE: Who hasn't been here for a little while, but he's here today. He's been out on leave because of some medical challenges, so we're really happy to have him here with us today. DAVE: I'm delighted to be vertical and to be here. MIKE: [laughs] DAVE: Yes, that was optional. That was an elective for me, was being vertical. So... MIKE: So, great having you with us, Dave. We are looking forward to having a good conversation. And speaking of conversation [chuckles], that's what we're talking about today. We're going to talk about communication and communication failure modes. I'm going to start, as usual, with a story, but I’ll introduce the topic first. To tell you a story...A few weeks ago, I got to do a little bit of setup here. So, you probably all know about hoverboards. They're not hoverboards, right? But it's like a Segway without a -- DAVE: Segway with no sticks? MIKE: With no stick, exactly. The self-balancing scooter that you stand on and move around. They're ubiquitous, especially among young people and kids, and they're all over the place. We’d had one in my house for several years, and the kids played with it, and they enjoyed it. My wife discovered something. You can put a seat on it, with a bar that comes out from it, and you put your feet on it. And it's got handlebars that you can lift up and down, two bars that you can lift up and down. So, you can adjust, you know, you can move it forward or back like you normally would by using your hands. And it makes it into, essentially, a little electric go-kart [laughs] because you've got a really low center of mass, you can just go full speed and have all kinds of fun. So, my kids at home, at Christmas, that’s what they all got, and they love it [chuckles]. There's a ring around my house that’s...[inaudible 02:32] dead. [laughs] They have flattened it so much, not every day, but often. And [laughs] they have a great time. So, that’s the first line. So, I’ve got to tell a couple of things that are going on here. In my office, I actually have a lot of cactus plants. Back during the depths of the pandemic, I had a little extra time and started ...
    Más Menos
    53 m