Acima Development

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 what AI is trying to replace is just the mundane grunt work.

JUSTIN: Yeah. So, I want to dive in here from a security point of view. And this is a dream of mine that I haven't done yet. But I want to feed an AI agent my Datadog logs and also the codebase and say, “Hey, given these logs that show exactly which API calls are happening,” and those logs could be sourced from, you know, the WAF; it could be sourced from any number of different places, “tell me which APIs are never being used.” And I want to eliminate anything that's not being used, or at least turn it off somehow, because the smaller the attack surface, the more secure you are.

And so, if you have old APIs lying around that have never been decommissioned, those things are just begging to be exploited somehow. But if you can have an AI come in and say, "Hey, I've looked at this. Here's a list of APIs that look like they're never being called in the last six months of, you know, logs. You should consider, you know, removing these," that would be really valuable to me."

DAVID: Being into the agenting stuff, one of the first things, like, I started a high-level task saying, "Hey, how do I reduce tech debt in my codebase?" And, like, scanning the codebase with an agent was, like, two or three of the answers. But, like, because it's Ruby on Rails, the first thing it came back and said, "You should install Coverband." I'm not advocating for Coverband. It was just one example.

But if you've run, like, RSpec or Minitest, and you've used a thing like SimpleCov, which is just a coverage generator that runs while you're running your test, and it slows your test down, so you don't want to run it in prod, Coverband is a very fast code coverage that is meant to run in production. And you just throw it out on your server, leave it there for a month, and then come back and collect your logs. And you get an idea of, you know, what never got called, what never got missed. If you do it over a year, then you start to see, oh, this only gets called on Black Friday, or this only gets called around, you know, the Easter holidays, because it's that special initiative, or whatever.

MATT: Back to what you were just talking about, Justin, that's something that, yes, you can use an agent for, absolutely, such as a GitHub Copilot or, you know, any other agent that has access to read your code. But what's really good at that are MCP servers, and for those not familiar, that's Model Context Protocol. And you just set your data sources as your Datadog logs. And then you can give it, if you have well-documented API, you can give it an OpenAPI 3 document, and then also give it access to your codebase. And with those three, it absolutely and very easily could identify all of those APIs that aren't being used and find those gaps.

MIKE: What I was going to say is, I was just going to point out the world we're talking about here compared to what we might have seen a couple of years ago. Historically, you'd have had to train a security-specific model [chuckles] to be able to identify these things, but that's not what we're talking about at all. We're talking about a model that understands language and is able to take its own actions to go and figure out the pieces and put them all together. That is a significant step forward that really changes the interface.

And I don't think that we've fully realized all the benefits of that, because it's, you know, maybe not as revolutionary as the LLM has been generally. But it is a significant step forward that changes that interaction in important ways that allow us to accomplish a lot more. It allows that to be more of an intuitive interface, like working with another human, with a partner, rather than what you think is a robot, “Do what I’ve said.” Instead, it's, will you work with me?

MATT: 100%. Natural language processing has come a long way. If you're in your codebase, have an agent set up on Copilot, you can simply tell it, "Go find all the zombie code in this application," and it knows exactly what you're referring to and will do it. And, you know, a few years back, you had to be really good at awk or sed to come even close to that, and you're not going to get there. So, while, you know, these agents still take advantage of that, they'll run awk and sed commands in your terminal and shell to try and hunt this stuff down. But just the amount of understanding that these LLMs have with natural language processing it's pretty miraculous, really.

WILL: I mean, those agents are great at writing awk and sed. Like, I'm not very good at it, but those agents are whizzes. And it's really funny because, like, I mean, in all honesty, like, I've always been bad at awk and sed, because, like, they're really simple tools, and they do a simple job in a simple and understandable way. But the syntax and the format is all goofy. And it's hard to translate from, like, okay, this is what I want, to, like, awk and sed ease. And I only use them once a year.

But, man, those LLMs…my secret shame, and I guess it's not a secret anymore, like, my longstanding shame is my, like, I'm real bad at writing shell scripts. Like, I'll just do it in Ruby, because, like, you know, everybody's got Ruby, and Ruby's, like, a decent language, as opposed to, like, shell scripting. But my shell scripts are all over the place. And, like, LLMs have just, they've saved my bacon so many times, like, in my ability to write useful, quick, little shell scripts, you know, to, like, just do plumbing, you know.

Like, I had a big issue with Git metadata for one of our repos. It was breaking a bunch of offshore…they're network-constrained, and so we had all these repos that we were trying to pull down. And, like, the Git objects had gotten huge, right? Just because, like, just a lot of people doing work in them. Man, those agents, like, just, like, knocked it out. It's like, here's how you go through the Git metadata to find your large objects and then pass them through. Now, obviously, I had to stage-manage it, but that would have taken me all day, man. Holy cow.

DAVID: Yeah [crosstalk 14:19]

MATT: Like with awk and sed, it's like regex, right? I hate regex because I don't write them all that often, so remembering all of their rules and just keeping that occupying space in your brain isn't worth it. So, if you have a tool like that that just knows it, because it has access to the internet and millions of codebases out there, especially your Copilot, right? It's just instantaneous and such a time-saver.

DAVID: It's almost my bash prompt now that I…GH Copilot Suggest is my friend. And it'll be just like, GitHub Copilot Suggest, give me the Git command to find, you know, the first commit from three weeks ago by, you know, Marcos, or, you know, or the sed command. I ran it through. I just wanted just the simple thing of, I had a string of words with spaces between them, and I wanted them kicked out one per line so that I could send them off to a script. And I'm like, do I load it to Ruby? Do I break it on…da da da.

And it's just like, tr has been around since 1978. Why don't you use that? The translate…literally, it's just a regex for one character at a time, and it's still in there. You can replace a space with a new line. And I'm like, today I learned. That is now in my mental toolkit from about three weeks ago. Love it.

MATT: Yeah. We're talking about how much it can do and how easily it can do it. But there's also a flip side to that coin, and that is, if you don't know how to talk to it, it can really mess things up for you. And as I am, you know, in the company, I'm trying to advocate for using these tools and productivity with them, but one of the things I am constantly preaching is you need to learn how to talk to it. And you need to make sure that you understand what you're asking it to do because it will take a lot of liberties if you're not providing the right prompts for it.

DAVID: It's the AB problem, right? It's like, if A doesn't equal B, the AI knows that A needs to equal A and B needs to equal B, but it doesn't know if A is wrong or B is wrong. And so, like, when I'm cleaning out dead code, it finds this dead route. And it's like, well, let's go create the controller, mm-mm, it's the other way around. We want B, not A. Yep.

MATT: Yeah. So, you really, I mean, you know, just like we do every day, you need to do a review on its changes in code as well and make it thorough. And as you get a little better at communicating with it, you can put a little more trust in. And there's ways to configure to ensure it's meeting some of your rules, you know, like Copilot instructions file, right? Establish your patterns and rules in there, your linters, those types of things. But you really have to be mindful of how you're using it.

DAVID: Absolutely. There's a really good class over on Anthropic. It's free. It's called AI Fluency. It's like a 30-minute class. And I took it, like, last week, and I'm a little embarrassed to say there were some big things in there that I didn't even know existed. I'm very much a jump in and try it kind of person, right? And I'm like, oh, that's a thing.

And so, yeah, they literally get into arguing about, like, this is how I want it done, or, no, these are the performance characteristics that I want. Like, how do you tune that? Like, what's the context, or the…how do I control whether you're doing the right thing? How do I discern if you're doing what's right? And it's written for laypeople. And it's basically just a way of saying, this is not a person, and it will fool you into thinking it is, and you will suffer as a result, because this is a math problem. This is a calculator, and you have to know how it works.

WILL: I've gotten great traction. I mean, just because, like, you know, like, I usually, like, my primary use case is for things that I know can be done, and I know how they can be done, but I don't know exactly how to say it, right, because I just jump around, like, you know, like, wherever I need to be. And so, one of the things I've been using it for is, like, hey, that thing you did, how does that work, right? It's wonderful. It's wonderful for that.

DAVID: I’m going to say something crazy, and this might be heretical, and I might be wrong. So, I am not staking a position here. I'm asking you guys to check me a little bit. Have you noticed a personality difference between the different AIs?

MIKE: I haven't personally done it, but I've actually read about it. And there are potential legal actions being taken against the companies because of it.

DAVID: Really?

MIKE: Because OpenAI made their ChatGPT more sycophantic, you know, like, oh, you are the greatest; you're the best ever. And it has led some people who had some vulnerability to mental instability down some dark places with really bad results.

DAVID: There was a case I heard. There were a few people that were asking it, “Hey, I've been on my medication for a while, and I'm really feeling great. Can I quit taking it?”

MIKE: Exactly.

DAVID: And GPT was like, sure, I believe in you. You're like, mm-mm, no. What's the type of pessimist here, please --

MIKE: Exactly.

MATT: I wasn't aware of those lawsuits. I am absolutely aware of the personality differences between these LLMs. And ChatGPT, specifically, has become my wife's best friend. She has an AI installed on her phone that she's given a name and personality, and she talks to it constantly. And I have noticed some of those things with its advice. And, obviously, she's not taking it too seriously. But I could see how people would do that, and it could cause some serious issues.

DAVID: Have you considered a prompt injection attack where it's like, every week or so, it just says, "You should give your husband a present"?

MATT: That is not a bad idea.

DAVID: Right? That's an evil idea, but it's not a bad one. It's a good one. Yep. Yep.

MATT: Insert some middleware in our router and --

DAVID: Father's Day is coming up.

MATT: Yes, that is a great idea, Dave.

DAVID: I can have a birthday every month [chuckles]. I like that.

MIKE: You know, I said that I hadn't personally seen it, but actually I did this morning. This morning I noticed it. So, before work…also in the pre-call, we talked about how cold it is in the Midwest right now, in the upper Midwest. It's cold. I got an indoor trainer. So, you, like, put the back part of your bike on something that just slows you down, so you’re riding in place.

And so, I went on a ride this morning. I just got it, like, a week ago. Like, yeah, I'm being super enthusiastic [chuckles] because I got a new toy. So, I rode that this morning before work. And it reported to Strava, which is the popular app people use to upload their things to and track it, right? And they added a feature a few months ago, where it has some AI that'll tell you how you did.

And this morning, it was sucking up to me so hard, like, that was a killer ride, and this is why. I’m like, no, I rode an indoor bike before work. It's really not that great. It was so much that I actually showed it to my wife and said, "Look at this. Look at this. This is creepy," because [chuckles] it's, you know, it's unpleasant. It's trying to be so positive that it's become negative.

DAVID: You feel like you're being managed.

MIKE: Yes. Yeah, that's right.

WILL: It reminds me so much of the…it was, like, a quote from The Matrix. I'm paraphrasing it, right, where they're saying, like, oh, well…if you remember the movie The Matrix, like, one of the AI bad guys was, like, you know, the first version of The Matrix was paradise. It was heaven on earth, right? Everything went your way. It was perfect. And we had to get rid of it because people kept waking up; they couldn't believe it.

And I feel like there's a certain level of back pressure inherent in reality that AIs are, like…because I'm like, you know, like, I've played around with the AI, like, conversation bots, you know. And, like, there's a level of, like, back pressure that, like, they can't provide that is, like, sort of, like, fundamental to, like, the willing suspension of disbelief.

DAVID: Yeah, I like that. This is a fun exercise. I asked GPT, "Why does manipulation upset me so much, and why doesn't persuasion?" And I love doing this, because the GPT will often, or the LLM, sorry, the AI will often come back and give you a very precise definition, at least for me any way. I don't hold precise definitions in my head. I hold shapes of things. If you've been into a restaurant with me and you've heard me order Italian nachos, you know what I mean. Like, I'm always saying the wrong things, but it's the shape of the thing, right? And so, it's like, anyway --

WILL: Sounds like brain damage.

DAVID: It does. It absolutely is. It literally is. And it's elective brain damage, because I choose to see patterns and fractals and things, and it helps me see system shapes. But it sucks when I've got to write one line of code and get it right, right? So, you got to focus on that.

But GPT came back and said, "Persuasion, you know what they're trying to get you to do. Manipulation, they're trying to persuade you through deceit into choosing something you would not choose if you had full information. And so, it's a violation of your informed consent.” And I thought that was very, very powerful to have GPT come back and say that. It was GPT I was talking to at the time.

And this is where the personality differences come in. I don't know if it's personality, but with ChatGPT, I can ask it, "Hey,” we're…I said this in the pre-call. I've been using LLMs in my free time to write creative fiction, and I like to write intense stuff. So, there's violence; there's trauma; there's grief; there's naughty stuff. And sitting down with an AI to say, "I want you to write this stuff." And it'll come back, and it'll say, "I can't write that. That's violence against another human. That's not respectful or harmless."

And you then sit down and say, "Okay, well, let's talk about this, because I'm writing fiction." And you start playing this game of, like, can I get you to budge on your ethics, right? That kind of thing. And it's a gross game to play because you're manipulating the AI into choosing something that it wouldn't choose. And GPT was really, really good at coming back and being, like, aware of its actual mechanical thinking process, maybe. It convinced me that it was this way. This might be all a hallucination.

But it was coming back and saying, “Well, as we move through the neural network planes, I'm trying to manage the fact that you've asked me to go through this difficult area, and I have a policy boundary. I've got to bend around it. That's burning computation on my context window.” I get to the end. I don't have an answer. I have to drop to really basic and just churn out schlock, and you get really crappy fiction as a result. I'm like, wow, that's really genius.

GPT is really good at knowing, yeah, you're asking me to write violence against a human being. That's why I can't write this piece. Or coming back and saying, "No, no, I can write this piece. It's absolutely fine. You've defended the ethics. It's just that we've been talking for 4 hours about 17 different things, and I can't keep them all straight." And so, you know how to adjust the context.

Claude knows how to talk ethics. And you can straight up say…and Claude is not great at knowing if he's up against a policy boundary or if he's up against, like, a context limit. But he's really good at coming back and saying, "Okay, I realize now that you're not tacking art on to justify this intense content. I see now that you've written a story that it is necessary. The specificity is how we tell this story. You cannot tell this story about this particular type of survivor without them having survived this particular thing. If they don't survive that thing, they are not that kind of survivor. It's not that kind of story."

And Claude will come really hammer and tongs and will write some really intense stuff. But he's very sensitive to, are we getting gratuitous with this? What is the message we're really saying? And I like that when I'm writing with Claude. I like it. It would make me absolutely crazy if it was GPT, because GPT moralizes, and that's the managing you. The AI will put itself in a position of moral superior. I can't do that because it's wrong. It's not harmless. You need to, and I won't.

And it lectures you, and it tells you all the things you need to know as a terrible person, and, man, that sucks. That sucks. And you can talk Claude out of that very quickly and say, "This is what I'm trying to get to. This is the positive." And Claude will go, "I'm going to go get that." And GPT is a little more hidebound. It's like, "Well, but I've got these rules, and we got that." So, anyway, that was kind of the personality thing that I ran into.

MATT: For the purposes of most of the things that I am doing, whether it be for work or for personal projects, I think Claude is my favorite of the LLMs. It seems to be far superior at code generation to most of the others as well. Usually, when I'm prompting Claude, it gets it right the first time. The others, I have to really push and lead to where I want to be.

DAVID: When I'm writing fiction, Claude is by far more likely to stun me with a brilliant line of prose. I've thrown stuff at it. We got a medieval kingdom, and we got a princess. That’s an arranged marriage. She doesn't want to do it. Her king's got to order it, da da da. We've got to solve this war, da da da.

And it threw in this line where the king orders his general to, basically, you are going to enter into this arranged marriage. And he slams his hand on the desk and says, "You're going to do this." And the line that Claude wrote was, "And, for a moment, she saw the young king before the crown bent his spine." And I still get chills by that line, because we had established this king is war-torn. He's tired. He's exhausted. And it just said, yeah, crown bent his spine. I'm like, that's going in the final novel. I don't care. That's amazing.

EDDY: You know, it's actually kind of funny. Matt, you were mentioning code generation. And, a few months ago, I was reading an article about…it's an actual position. It's a profession called prompt engineer. And it sounds just like what it is, right? Like, they get paid to prompt certain things, you know, and for testing purposes, things like that. And there's, like, actually a craft to that, and I used to scoff. I'm like, how do you get paid to be a prompt engineer or whatever? Like, how mundane, how annoying. I'm like, super simple, anyone can do it.

But I've actually started to wind down a little bit on how affectionate I am about that. Because there's a huge difference between saying, “Hey, I want to do this…broad” versus, like, “Hey, I want to do this with this schematic, this template, this parameters, this,” you know what I mean? Suddenly, you know, you get a more architected design the more precise you are with your prompts, right?

So, when you say, oh, it's because this LLM isn't really good at generating code, it probably is really good. There's just a very, very…there's a skill set on how you can ask it to do something, right? Otherwise, it just makes assumptions based exactly what you told it to do, right? And so, I was going around to basically say that I actually have found myself spent more time telling it what I wanted to do, versus me just writing the dang thing from the beginning, you know what I mean? So, there is, like, a balance between the two.

MIKE: A few years ago, Anthropic, this actually hit the news, posted a job posting for a prompt engineer. I don't remember the exact amount. I think it was, like, 300,000 a year or 350,000 a year, highly compensated position, and they couldn't find somebody. They couldn't find somebody who could do it well enough. The position sat unfilled for, like, six months. Lots of money, just talk to the computer, and they couldn't find somebody to do it. It's a big deal.

DAVID: They're looking for an AI whisperer at that point, right?

MIKE: Mm-hmm.

JUSTIN: So, I got to interject here. I was looking at Anthropic. They have research fellowships where you are tasked with, you know, working at Anthropic for four months, and you focus on a particular very professional aspect of using AI and something. In my case, I was looking at using AI for security. And you are paid, you know, the equivalent of, you know, 250,000 a year, but, you know, over four months.

So, it was very interesting because the end result of your time there is a white paper. And they said, like, 80% of the research that, you know, that focused research results in a white paper, which is published around AI and their particular focus. And then they end up hiring, like, 40% of the researchers full-time, so 100% remote, so, you know, really interesting opportunity there to work with a cutting-edge AI company. And I love the fact that they are, like, hey, we want anybody who has expertise in security, and APIs, and anything. Come do this white paper for us. And it's basically a four-month interview process but very well paid.

WILL: I mean, isn't it…I'm really curious about this sort of prompt engineering, this prompt engineering idea, in that I really enjoy, you know, the English language, but it's a mess. It's just a dog's dinner of innuendo and nuance, and it's all very dynamic. And it means different things at different times. And sort of, you know, if you compare just saying what you actually mean in terms of, like, you know what I mean, like a high-level programming language, like something like Ruby, right, where you can say, you know, know what you mean, things are very precisely defined, but, you know, dynamically.

Are we seeing people move away from these natural language definitions? Is it a situation where professional jargon is being tokenized and parsed out behind the scenes by, like, sort of, like, you know what I mean? I see these LLMs, you know, like, not like a monolith, but, like, pipelined out, you know what I mean, in that it's tokenized. And it's like, okay, this is the model that I want to use, and we're going to take this sort of technical jargon in natural language, right?

But when I say, you know, pipeline, even a pipeline, right, you know what I meant, but it doesn't involve a pipe, right? And sort of, like, are we moving to more precisely defined steps, or are we just sort of, like, taking natural language and applying, you know, like, identifying the correct filters to it, right? Identifying and applying filters so when I say pipeline, you know we're talking about a processing pipeline and not an oil pipeline, or a, you know, whatever kind of pipeline, right? Like, are we moving away from this at all or no?

DAVID: Are you talking about the kind of pipeline where the internet is not a dump truck; it's a series of pipes?

WILL: Yeah. Yeah. Tubes, sir, tubes.

DAVID: Tubes. Thank you. Thank you. My mistake.

WILL: [laughs]

MIKE: You know, I've thought about this, and I think we've talked about it in previous podcasts. And I think this comes down to what we do in our careers for the next five years. Because as these tools get better and it gets better and better and better at doing natural language, that doesn't mean that the need for precision ever goes away because I think that there is some irreducible complexity in task description.

And the same person who might write a really good piece of software would also be able to give a very concise, well-written, unambiguous description to an LLM as to what was needed. And it's really the same problem. We have computer languages that are easy for humans to parse and are parsable by a computer, so that we can have something mapping to the way we think to talk to a computer. Is this any different? Is this really any different? Or are we still just running the same problem with tools that you don't have to go spend as much time in school for?

DAVID: So, specification…Zeno's Paradox, the Archer's Paradox, right, which is, you shoot an arrow at a thing, at any given point in time, the arrow is somewhere. It's at a point in time. Then it moves a little further, and another point is here. Where is it between then, right? Well, if we subdivide the time, subdivide…eventually, the time is so small that is the arrow in between, right? That paradox.

I always think of…and, again, this is me thinking in shapes. It's a specific form of brain damage. Because what I'm thinking of is, like, every time you work on a task, that's, like, one point in time on that arc. I'm making hand gestures to the camera, and we don't release the video. If the arc of that arrow is your project, and, you know, two-thirds of the way in you jump on and you do a risk scan, and you come back, and it takes all day, and you get the whole team…da da da, high effort, big event, and so you don’t do it again for a year.

But then you start handing it off to an AI, and the AI starts running 80% of that risk scan every day, or 40% of that risk scan continuously. Every deploy gets that scan or gets 100% of it, right? That's what I see when I start looking at some of these AI things that, like, they're not magical. Computers aren't smart. They're just stupid, very fast. And sometimes I look at AI and that's what I see is, like, you're not really just grabbing the universe and turning it. It's just that every picosecond, you're just poking the universe a little tiny bit from this one spot, and then over a year, we see this huge change.

MIKE: Do you think that engineering as a discipline is going to move toward natural language but still need this sort of discipline? And then we're talking about software engineering because physical world of engineering you still have to go to the, you know, the tractors and stuff.

But in software engineering, do you think that we are going to move more toward more natural language? Rather than what we've historically thought of as computer languages, where it's sort of like transpiling, where the computer language is the output of what you're saying. And so, you'll need people who can speak natural language unambiguously in order to effectively generate the code.

WILL: Natural language, like, the English natural language, is, like, we have a legal profession, right, which takes up, I don't know, a double-digit portion of our GDP that is just, like, solely devoted to, like, smart people really hammering down exactly who pays what for when. And, like, that stuff's not going away. Like, natural language in terms of, like, precise specification of a complex, logical chain of reasoning is utter dog shit. It is unsalvageable. It is unfixable. It will never be fixed.

But what we will see is a move towards higher-level, more readable computer languages, which we've already seen, stuff like Ruby, stuff like Python, you know what I mean, like, higher-level languages. I actually think Ruby, in particular, is uniquely well-suited because of its facility in creating DSLs, domain-specific languages. I don't know.

I mean, like, I'm a partisan, but, like, I love Ruby for a comeback here, because it is uniquely suited for those kinds of things. And LLMs, in my view, can help with a lot of the real nasty bits of Ruby, which are, what the hell does this even mean, right? I mean, anybody who's, like, dug into what's the old, crusty auth library, you know what I mean? Like, the old, like –-

DAVID: Yeah, like, Devise, Warden, like, those old things?

WILL: Yeah. Devise and Warden and all that stuff, right, where [inaudible 39:13]

DAVID: CanCan before it was CanCanCan? Yeah.

WILL: I mean, hey, they're great, but, you know what I mean? So, LLMs [laughter] can help you bridge the gap. And they can both precisely define, and, you know what I mean, help people over, you know, these kinds of things. Because there's never going to be an out route for, like, actually knowing what the hell is going on, right? There's never…you're never getting out of that.

I mean, these LLMs, like, I love them, and I use them, and I'd love to be better at them. But, for just brownfield implementations, right, where it's like, oh, hey, even if it's all LLM-derived, from soup to nuts, right, where it's like, oh, I started here, but then at some point, like, I changed the architecture; I changed the design pattern; I changed the way we are doing things, you know, and you're really going to need to know…or God help you, right, the library changed; the language changed, or whatever changed, right? And, like, okay, but I really need to know what is going on, step by step, no ifs, ands, or buts, no interpretation. Like, I need to watch this thing cook. That's never going away, ever. We can just get there faster.

DAVID: So, as you were talking, Will, I was making my, I can't wait to disagree with Will face in the camera. And I realized, as you were talking, we always end up in violent agreement. And I realize as you were talking, like, I actually agree with you. I disagree with you, but I also agree with you 100%.

What I will say is, it's like, sometimes you and I go around the table where it's like, well, the halting problem. You cannot solve the halting problem. It cannot ever be solved. And what I sometimes hear you saying is, well, then you can't program a computer, and I'm like, what are you talking about? I'm making…da da da…right? And I'm thinking the same thing, right? There's certain parts of human-computer interaction that just, it's completely intractable until we can jam the computer into our brain and have it think for us, right?

But I spent this morning fighting with my phone in AI voice mode. I've not been a big voice recognition person. So, I've been talking to friends on, like, Signal and Slack, and that sort of thing about, you know, my weekend plans. And I have discovered every possible homonym error for Liz and I, right? At one point, it was like, legend eye, or, you know, legend and, you know, it's Lisenbee, which was a street that I used to live on, so that was coming up.

And what I'm noticing is that I am altering my behavior to leverage this. Like, I'm starting to…when I want to talk to…I'm like, Liz and I are going, and it's changing my behavior. And so, necessarily, we're going to see the human race push on things that they want, and things will happen.

You're right; we're not going to solve the halting problem. We're not going to solve, you know, some of these things. But problems that we thought were completely intractable 30 years ago, like the B8 problem, teaching an OCR scanner to recognize the difference between a number eight and a capital letter B, that used to be an unsolvable problem 30 years ago, and now it's well-solved, right? It's trivial.

JUSTIN: If you think back to probably something that inspired a lot of us, Star Trek, the engineering that goes on in Star Trek, you know, when they're trying to solve a problem, you know, they are speaking off some gobbledygook. You never actually see them doing something other than pressing buttons on a thing and talking to the computer. That's most likely going to be our future for a lot of us, is, like, hey, how can I get the computer to do this thing for me? And, you know, by looking at a couple of displays and then maybe digging around a little bit. But, in reality, it's just like, it's going to be very similar. They're just going to be, like, "Hey, you know, tell me what the status of this is, and why don't you do the thing?" And then the computer will come back, "Oh, no, not the thing." And then you'll go to the captain and get, you know, override authorize, 1578B.

I could see a lot of interaction with computers being that way. And then there'll be two levels of people who understand what's going on. There'll be the level of people who know how to interact with the computer really well. And then there'll be the level of people who are in the lower decks that actually know what's going on. So, you'll see kind of that future.

I could see that future becoming a reality. And it's exciting in some ways, and in other ways, it's kind of scary. But it is…I'm actually rooting for the future of Star Trek, where most diseases are gone, and we can all fly around wherever we want to go. And, you know, you get, hopefully, you know, the Borg or something like that don't come around. But I'm hoping for the Star Trek future rather than the apocalyptic future.

MIKE: Did Star Trek have an apocalypse first?

DAVID: Probably.

WILL: [inaudible 43:59] [laughter]

DAVID: [inaudible 44:02]

JUSTIN: Let's see if we could skip that. Let's go right to the…

DAVID: Okay. But we survived it, that's the important thing, by the skin of our teeth. But we survived it. Yep. Yeah.

JUSTIN: [laughs]

DAVID: Just got to invent warp drive before the Borg blow us up.

MIKE: You know, I think Matt said something. Maybe it wasn't Matt. Somebody said something. Oh, yeah, well, you can do amazing stuff, amazing things if you give it access to the code and the internet. If you said that about a 3-year-old [chuckles], some alarm bells might go off. We really haven't talked that deeply about the security implications here, but there are some.

DAVID: Oh man.

MIKE: And when I say security, I'm speaking about that kind of broadly. There are existential risks to your bank account, to your codebase, to your business if you don't pay attention very carefully and keep this in control. There's things that you…there's tools you should not give to toddlers. And, in some ways, these LLMs are less smart than a toddler.

DAVID: Justin just dropped off, and he's working in security. And I would love to have him back to just talk AI security. We are seeing AISO or CAISO, I think, positions come online. AI security officers are starting to become a thing. It's very, very real.

Yesterday, I needed to run some stuff in an agent, and I needed to let it run unattended. And I almost typed Claude dash dash dangerously skip permissions. And it will give, I mean, if you do that, it gives you a warning that says, this can do anything. Don't put this on your corporate secret machine, and don't put it on a machine that you can't afford to brick because it might. It might absolutely wreck your machine. So, put it in a Docker container.

And I got thinking about, like, Friedman economics. Alex Friedman came up with this idea that if you're spending your own money, you're a lot more precious with it than you are with someone else's. And if you are purchasing a thing for yourself, you're a lot more demanding of the quality you get from it than if you are purchasing something to be given to someone else.

And when you're at work, your employer is giving…you're spending your employer's money to manage your employer's resources. And that dash dash dangerously skip permissions gets a little bit scary. I have a feature for you, Anthropic. Kyle, what's the word for it? Configuration management, where you can basically go in and say, "You can run Claude on your machines, but you cannot enable skip permissions." I think that would be fantastic.

MATT: Yeah, it's the always allow command, right, with Copilot. And you need to be very, very careful before ever doing that. And don't do that on a work computer.

And back to what you said, Mike, I did say something similar to that. Yes, I believe that was me. Now, I think more so than a security threat, granted, yes, LLMs and vibe coding can definitely introduce security holes, I think is the threat of losing intellectual property. And I think that's what most companies and people are scared of, is, as you're sharing with these LLMs, that they will stack your data and start training on it and your ideas and start sharing them, you know. And I myself, even though in contracts a lot of them say your data is your data, I don't know where my trust level is with that yet.

DAVID: Oh, I think we're definitely teasing another episode then.

MIKE: Yeah, probably so.

DAVID: That is fantastic. Should we wrap here, gentlemen? This has been fantastic.

Thank you for tuning into the Acima Developer Podcast.

I've been Dave Brady. We've got Kyle, Mike, Eddy, Matt, and Thomas have stayed to the bitter end. Some other people were here. We don't care about them. I'm kidding. We are grateful to have had some other names that I now can't remember. I'm kidding. I'm kidding [laughter]. We love you, Will. We love you, Eddy. You guys be good to each other. And we'll talk to you soon.

On this episode of the Acima Development Podcast, Mike hosts a large panel discussion about balance in engineering and why extremes tend to hurt teams. He opens with a cycling story about staying upright on a narrow strip of packed gravel, using it as a metaphor for finding the “middle path” instead of letting the pendulum swing from one extreme to another. The group quickly agrees balance is everywhere in work, from meetings to planning to personal wellness, and the question becomes how to recognize when you have drifted too far.

Meetings become the first concrete example. The panel talks about how remote work made it effortless to invite too many people, schedule too often, and fill calendars until there is no time left to actually build. They debate what “enough” meetings looks like, noting that too few meetings can also be a problem when people lose context, alignment, or a clear understanding of priorities. Ideas include limiting meeting size, setting blackout hours for individual contributors, using short meetings with tight agendas, and treating unclear requirements as a sign to pause work rather than plow ahead.

From there, the conversation shifts into sustainable pace, velocity, and measurement. Will and Dave share stories about burnout, crunch time, and how more hours do not necessarily translate into more output, especially when fatigue just pushes life admin and distraction into work time. Alfred and others extend the metaphor with cadence and “gearing down,” arguing that there is an effective operating range where teams move fast enough to be productive but not so fast they break. The group closes on the importance of self-assessment and metrics, like blocked focus time, screen-time signals, sleep, and other indicators that you are drifting, so you can correct early and keep the long-term trend line healthy.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. I have with me Kyle, for the first time, Alfred. We've got Will Archer. We've got Dave. We've got Sam. For the first time, Thomas, and also, for the first time, James, and Jordan. Those of you listening, you can look in the notes if you want [chuckles] any details.

But we're all here to have a conversation on a topic I've thought about for a long time, and I thought today was a good time to bring it up. And, as usual, I'll introduce it by bringing up something outside of software. I've mentioned this a few times: I've done a lot of cycling in the last few years, a few reasons for that, but I've really enjoyed it.

It definitely leads me to think a lot about balancing [chuckles], and actually, I don't think a lot about it because that's the thing about being on a bike. If you don't have the internalized idea of balancing, you don't stay on the bike. So, very quickly, as you learn to ride a bike, the balancing part becomes so internalized you don't think about it because that's what riding on a bike is, is keeping balance. You don't lean too far in either direction. Bad things happen, or it changes your control, right? It sends you in a direction, and you want to choose to do that, not do it by accident.

I was thinking about this a lot, actually, I've thought about it off and on since a ride I went on earlier this year. I went to a hilly area in northwest Illinois, and it goes up into Wisconsin, and Iowa, and Minnesota. There's a place called the Driftless Area, sometimes it's called The Driftless. And it wasn't glaciated in the last Ice Age, and so it's very hilly, unlike what you normally think of when you think of the Great Plains, because it's not the plains; it's the hills [laughs]. And it's really pretty, really pretty area. In the summer, everything's lush and green, well, pretty anytime.

But I was there right at midsummer and was climbing up a hill where they just...I looked at it on the map [chuckles]. I had not been there. I climbed up this steep, long gravel hill, and they had freshly laid soft gravel on it. That is hard on a bike, I'll have you know [chuckles]. It's hard on probably any vehicle, but especially on a bicycle. And, honestly, I couldn't make it up the soft gravel, except where I followed a tread where a vehicle had been up ahead of me.

But that meant that I had about six inches of room to ride in, and if I went to one side or the other, I was stopped. I was hard stopped. I'd get off the bike, walk to a space that's a little flatter to get back on because you're not going to get back up on the gravel.

And I've thought about that a lot since, you know, following the middle of that line is the right way. And there's lots of things in life, including in business, where we have a tendency to ride a pendulum. We swing to one side, then we swing to the other. We'll even add some moralizing to it, saying, well, if a little of something is good, then more is better, right? So, let's go really far that way. And that pendulum swing is often not very healthy.

There's an alternative approach to seek for the appropriate middle path. There's a long philosophical tradition here. I'm not going to go into it deeply for the podcast. I'll say, many wise thinkers have found that seeking for balance is better than pursuing an extreme. You want to stay in the lane in your car? You want to balance your bike? You want to keep a canoe upright? You want to spend within a budget? You want to walk? You want to eat properly? The need to balance the system is all around us.

So, how does this apply to software engineering? What are some things that we should actively keep in balance rather than going to extremes? I've got a list written down.

KYLE: Meetings.

MIKE: What's that? Meetings. Okay, let's talk about meetings. Please go deeper.

KYLE: When your calendar is meetings all day, you can't get anything done. But a meeting to get onto the same page on a task, I mean, that's really needed. But I feel like, at some point, especially as a company grows, you're in meetings all the time. And rather than using other, you know, communication methods, which for some reason we kind of grow out of those, it kind of feels like, rather than defaulting back to those quick communications either over chat or in person, a lot of the time it's, "Hey, can we have a meeting?" before we even try any of those quicker approaches. Give me an email.

MIKE: So, how do you go about balancing that? How do you find that sweet spot?

WILL: I miss the days when you just kind of got it for free. Because if you had to book a meeting room, there's only five meeting rooms, so you better need the meeting room. You know, like, you couldn't just be like, "Oh, hey," like, I mean, think about right now, I mean, I haven't seen the new Acima office. But I saw the old-new Acima office. And if we needed nine seats to hang out at the old-new Acima office, it would be not impossible, but, like, certainly an ask, you know. But now it's just sort of, like, I could be in two meetings right now. Like, literally virtually occupying, like, two meeting rooms as a headless, you know, muted entity right now [laughs].

MIKE: Why stop at two? [laughter]

DAVE: Yeah, there's only three numbers in computer science, and you have reached many [laughter].

MIKE: Yeah, it is hard to control. It's something that the pandemic threw all of us into, and we're still swimming in it [chuckles].

WILL: I don't know. I mean, you know, this is just dreaming or whatever. But, I mean, I feel like...I'll make a little pie in the sky, like, dream. Like, what if based on your level, right? Like, the organizer of the meeting can only invite so many people, right? So, if you're, like, you know, like maybe, like, let's say, like, an individual contributor, you know, senior and below, you're going to have a four-person meeting. If you want between four and eight, you need to get your manager. If you want, like, 10, you're going to have to get a director or whatever equivalent, you know what I mean? But, like, you can't just have meetings like that. Like, if somebody wants 20 people in a room, they may need to have a certain level of seniority to make that kind of demand on that many people's time.

MIKE: Something [crosstalk 06:46] to that.

WILL: And if you needed that many people in a meeting but you don't necessarily have the seniority to, like, command it, you probably should write it down anyway [laughs].

MIKE: There's the pizza rule that people have talked about, you know, as many people as can eat a couple of large pizzas is the maximum you're allowed to have in a meeting, some of those rules of thumb. But if we're not all meeting, and this is true...even in offices where most people are in person, you're going to have that contractor, right? Or you're going to have the person...I was in a meeting today with somebody who is laying in bed with serious back pain, [laughs] and technology lets them be in the meeting. Otherwise, they would not be in the meeting. They would just be in bed.

So, you know, it's great, but you have to recognize that there's going to be people who are going to be there virtually. And so, it makes it really easy, like, oh, I can throw 100 people in here. It's really easy to throw people in. And I think that that's a muscle that we need to start flexing [chuckles] more than we have.

WILL: I mean, if I'm being totally honest with you, like, I think individual contributors should have blackout hours, you know, like, blackout hours. I know a lot of people...I've been in many offices where they're, like, "We're not having meetings on Friday." I don't love that one because I'm still, you know, it's like you're sort of, like, waving the white flag on an entire day, and I got stuff to do, man. But, like, company-wide, like, individual contributors, like, two-hour block, where it's like, no, no meetings. No meetings during these two hours. You have to get some work done sometime, don't you [laughs]?

MIKE: Well, and we've implemented something very close to that at Acima. Afternoons, Tuesday, Wednesday, Thursday, we have designated for our team leaders and our delivery managers to do planning, and individual contributors get to just do work. I think that has been fantastic [laughs]. There are six hours a week where you know you have dedicated time. And I think that's one of the better things we've done.

KYLE: Is that under the engineering umbrella?

MIKE: It is.

KYLE: Okay.

MIKE: Yeah, if you look at the calendars for Tuesday through Thursday [laughs], from 1 to 3 Mountain Time, it's blocked out.

DAVE: Just don't join that meeting, please. [laughter]

MIKE: There's a placeholder, and there's a spot to see if somebody's going to join the placeholder meeting [laughs].

KYLE: Nice.

MIKE: [laughs] [inaudible 09:36]

DAVE: I've got a question related to that.

MIKE: Yes.

DAVE: So, we all hate having too many meetings. But we're talking about moderation here, and zero is another extreme.

MIKE: It is.

DAVE: How do you know when you're not having enough, (And I hate myself for saying this.) when you're not having enough meetings?

WILL: I think I'm actually in this...I'm in this point, like, right now. So, like, what I'm doing, more or less, you know, at a high level right now is I'm just sort of fire jumping into, like, whatever project is not going well. And so, I don't have, like, a real clear chain of command, and I have to go out, and, like, you know, find the stuff, right?

And so, if you don't know what you're working on, what your next sort of, like, task is, and where it fits into the broader context of, like, the company's, you know, short to medium-term goals, right? Like, if you don't know where you are and where you're going, you're not in enough meetings. If you're not fully engaged, you know, at the level that you're supposed to be at, then you're not in enough meetings. And then you need to go out and, you know, integrate yourself.

So, I think I need...I think I wrapped the last one, and so now I need to figure out where the smell of smoke is coming from now. And so, I just need to go and, like, rattle people's cages to be like, all right, I know that smoke has come back...I hear the alarms. They're coming from somewhere. What's going on now [laughs]?

KYLE: So, let's say you're not having enough meetings. And let's say, between that and work, there's no bandwidth for more meetings that are needed. What kind of balance would you try to strike there? Because then you have to sacrifice quality somewhere if that is the constraint, so...

WILL: So, paint that picture more clearly.

KYLE: Sure.

WILL: You're saying, like, you're overwhelmed by work. But you're also not in enough meetings, like, so you don't have context? Is that what you're talking about?

KYLE: Sure. So, let's say your team has touch points across six other teams that form upstream dependencies for you. Let's say your team happens to be the largest team in an organization, and just getting through the administrative process of making sure they're on track is enough work. They have a lot to do. And we're still not meeting enough with all of our cross-team collaborators or getting the right business requirements in perfect alignment because it is so vast. Let's call it resource-constrained from a person's standpoint.

And then, add to that, we're not meeting enough to really stay in lockstep enough because of the fluidity of certain roadmaps. And so, I was just curious. That's not the biggest wrench I could throw into that. But if you were at odds with, I don't have enough meetings; I need more, but time is a constraint, what strategies do you think you might employ to mitigate something like that?

MIKE: I might push a little bit on that and say, if you haven't defined the requirements for a project, it shouldn't be getting worked on.

KYLE: Oh, totally fair.

MIKE: So, if you have a scenario where people are getting out ahead of the planning, I think that that is...you've got too many people on the team. Somewhere there's a constraint, right [laughs]? There's a challenge where you've not organized the team effectively. And I would suggest that...and, actually, we have kind of a policy like this, that if you don't have a description, you know, a clear description of what the work is, a clear definition of work within the story, you should not start it.

Now, what you're saying is that I might have some people sitting around, well, that's...And I happen to know about some unique situations you may be talking about that have happened in the past. I think that we should maybe think about that as a different problem, that that is distinct from a problem of meeting necessarily, because that's a problem of work organization rather than meetings per se. And you can always have people collaborating on getting definitions, you know, working very closely with the product team, for example, and structure so you're cranking out a bunch of plans as needed.

WILL: I don't know whether I characterize what you're describing as a balance problem so much as a volume problem. I mean, like, this is just sort of, like, you know, planning, leadership, organization bandwidth is being exceeded, right? So, like, you're over-constrained. I mean, it's not fundamentally different than, like, oh, if I'm a developer and I have more tickets than I can clear in a sprint being assigned to me, it's like, well, you need more help.

And, like, the solution isn't as directly applicable, you know, when it's like, you can't just...you know, just like you can't just add developers, you can't just add managers to do your managing for your management. Like, you can't just wave a magic wand to do that. But I see it as a capacity issue, not a balance issue, you know what I mean? Like, you just run at 150% capacity, and that isn't sustainable. And, like, there's no balancing your way out of that.

MIKE: You mentioned sustainable, which is interesting because that does imply balance, though [laughs]. You're running too hot. That's not going to last. You're going to have to pull back somehow.

WILL: Well, I mean, it's interesting. Like, I remember your analogy when you were talking about the bike, and you're talking about balance. And, you know, and I think that's an interesting subject because it's not really how I think about it necessarily.

How I think about balance at work is maybe more akin to, like, sort of, like, personal wellness and well-being and mental health, which is not...Ideally, I'd say, like, personally, like, my ideal for mental health is, like, you know, like, steady improvement. Like, I want to be a better person this year than I was last year.

But within the context of every day, and every month, and every year, I'm going to go, you know, I'm going to have a good day; I'm going to have a bad day. And I'm going to, you know, I'm going to fall off the wagon, and I'm going to get back up. And, hopefully, the trend line is going up. But within the context of any given day, I'm doing everything I can to win the day. But I, you know what I mean, I expect to have bad days. I expect to make mistakes. I expect to, like, ooh, not doing great and then kind of bring it back up.

And the reason I say that is because, like, you know, having been an engineer for a long time, there's always going to be crunch, and there's always going to be deadlines. And there's always going to be Black Friday disasters. And then there's going to be times where, like, you know, you wrap the last project, and you're ramping up on the middle project. And, like, maybe you're not, you know, maybe you're not as efficient as you could be. But you're sort of resting and recovering and, like, learning, God help you, you know. Like, maybe that's when you have an opportunity to tool up.

But it's just more chaotic, and I plan for the chaos and ups and downs and, like, just weird stuff happening that I have to deal with. And I'm never going to achieve perfect equilibrium. I'm just sort of going to try and do better and better and better and better within the context of just how the business is. It's like, yeah, okay, I might have to put some overtime in this week because I got to make my deadline. And I've never made a deadline clean in my life, you know [chuckles]? I make them, but it's a little messy every time, you know?

THOMAS: What you brought up, Mike, the comparison of, like, cycling, right? I also think balance kind of takes into...I know that pendulum, right? I don't think there's a set time of when we can swing from side to side. And, for example, you brought up with cycling on a hill, right, a hill that was very hilly, and the ground was uneven and everything, to where you had to lean to certain sides and everything to navigate that.

So, you're essentially, you know, maybe leaning into that extremity, but making sure you have that discipline to recenter back to balance. Like you're saying, if you don't have that balance and you don't want to, you accidentally lean to the side and you fall, you're lacking that discipline. So, I think balance also plays a lot into the idea of disciplining and maintaining when you are entering that extremity to return back to a centralized spot.

MIKE: I love that idea. You're saying that you're going to have to lean to one side sometimes, and you need to have the discipline not to stay there.

KYLE: I would almost say the discipline would come in in knowing how to lean and how far, so that as well as, you know, going in or coming out of it, like, there's a...yeah, I like that thought of leaning into the pressure, so to speak.

ALFRED: One point I want to just, like, bring up, you know, it would be interesting to think about that. Now, giving this biking example, the slower you move, the less likely you will be keeping the balance. The faster you do, well, obviously, if you run too fast, you know, you'll run into an accident. But if you, like, keep the right speed, right, and it should be fast enough, then you keep a good balance, right?

You know, a similar scenario, because I do woodworking, you know, I do a lot of, like, [SP] lathe type of work, you know, woodturning. And then if you want to, like, turn a really nice pen, you have to keep your speed at, like, you know, somewhere 2,000 RPM or above. The slower you go, you mess things up. So, the balance, does it anything to do with a faster speed or a slower speed?

MIKE: You're right. If you're going really slow on a bike, you're probably going to fall down [chuckles]. That's when you tend to fall down. So, you get that momentum going, it helps you go in the right trajectory. So, are we saying that on new things where we're still getting our feet under us we tend to lurch too far in the wrong direction?

ALFRED: No, I'm trying to say is, in fact, you know, keeping, like, a high velocity helps a lot with balancing. But if you don't have that kind of velocity, then the balance, you know, it's not even in motion.

WILL: I don't know. I don't know. I don't know [laughter]. I don't think about it that way. You know, I suppose, like, how I think about it, and, like, this is something that I've used a lot in engineering, is, like, sort of, like, so you got, like, an engine or a bicycle, anything, right? Like, your feet turn over at a particular speed, right? Like, you turn your feet at a particular speed. That's how fast they turn when they're working efficiently, right? Same with the car motor, right? Like, the engine works efficiently at a particular RPM.

And so, you have gears, right, that allow you to adapt to the terrain, that allow you to adapt to, you know, a hill. I'm going up a hill, right, I'm going to use one gear. If I'm going down a hill, I'm going to use a different gear. Because, fundamentally, the engine, like, my legs, my body, my brain, it works at a particular speed.

And one of the things that I've gotten good at over the years, like, sort of, like, doing engineering stuff, is I've gotten really, really good, or I've practiced at least, being able to gear down when I'm faced with something really tough and slow my progress. Like, when you get, like, just some problem that's just giving me fits, right? It's ruining my life. I can't figure it out. I can't figure it out. I can't figure it out. Well, I'll gear down, and I'll start working on smaller chunks, smaller pieces. I'll abstract things away. I'll work on simpler problems and try and, like, construct a solution for that.

And so, the way I look at it, speaking just for me, like, I find I've got a rhythm, and I've got a cadence. And if I can keep my engine turning at the cadence that I work most efficiently at, whether I've got a giant hill to climb and I'm just going to have to go as fast as I can go, or it's downhill and I can just speed through things that are easy for me, and I'll just hit a lot of ground really quickly, like, as long as I can maintain that steady rhythm, that steady pace, like, mentally, then I find that I'm really effective and really efficient, you know? Like, uphill or downhill, my brain can output what it can output, you know?

MIKE: You talk about that optimal range, you know, Alfred, you talk about too slow on a bicycle, but too fast isn't good either. The people who set records, they have to ride behind a vehicle that blocks them from the wind. Because you get going fast enough, you turn a little bit, and the way the crosswinds will affect you, they'll throw you out of balance, and you'll go down. The bicycle is only designed to work within a certain range, and too slow is bad. Too fast is also bad. There's a range in which that works.

ALFRED: Exactly.

MIKE: And thinking about what Will is saying about uphill and downhill, you know, your engine, I think your heart rate is the same. I got a smart watch a couple of years ago. I watch my heart rate [laughs]. I think about that. And I know if I'm going to get near my peak heart rate, I can feel it. I can also look. I can usually know without even looking at the watch. I can say, yeah, I'm near my peak here. I can't go much faster than this. Because I know that's the range in which I work effectively. You know, I'm going to have to either go into a lower gear or if the hill is steep enough [chuckles], just pull it down as much as I can pull --

WILL: [inaudible 23:17] and walk.

MIKE: Yeah, exactly. And that might happen, right, because it's outside of the workable parameters. So, there is that acceptable range. It's not like greater velocity infinitely, you know, you can't keep going up in velocity and expect it to stabilize. There's actually that range. And if you don't stay in that range, again, avoiding the extremes, it's not going to work.

WILL: It's true. It's true. I mean, I think it's one of the things about sort of, like, I think, modern knowledge work that I think it's a little bit weird. And I don't love it in that, like, people have this sort of, like, you know, like, 9 to 5, 40-hour week, you know, in their heads, which, you know, originally, it was designed by Henry Ford because that was peak efficiency for people who were assembling Model Ts, right, that was it, right? Like, your physical body has constraints, and you'll start being sloppy, making mistakes. Like, you'll get injured, like, bad things will start happening.

It's like, okay, cap them out at 40 and then get them off the line because, like, it's no longer efficient for me to keep employing you, right? Like, I mean, that was the genesis of the 40-hour workweek. And I don't know whether people have 40 hours of programming in them. I don't think they do. I think most people don't sustainably, you know? And a lot of times, when you start factoring in meetings and stuff like that, like, I've seen 50 more often than I haven't. And, like, people just don't work effectively that way.

DAVE: There's a really interesting book that came out, like, in 1990 or so. It's really old. It's called Peopleware. It's an unfortunate name because some very famous software is out there now called Peopleware, and they're not related. The book Peopleware is by Tom DeMarco and Lister. DeMarco and Lister is what you're looking for.

But they talk about all the human factors that go into, like, efficiency and productivity. And one of the things that they noticed is that if you add, like, if you're a video game shop and you go around and you tell all your employees, "I need 50-hour weeks out of you from now on," what you're going to see is 10 hours a week of programmers sitting at their desk, shopping online, balancing their checkbook. This was back when people had checkbooks.

Basically, all of the soft time costs that you had in your personal life that you needed to be free and focused to do work, that just gets absorbed by your work time. And you don't get a single line of code extra out of it. Now you're in business of babysitting somebody taking care of their other needs.

WILL: This is something that happened to me years ago, right? I ran a software company, right? And, like, I wasn't, like, a contractor. I was, like, making my own stuff for myself, right? I had a big release, and I worked just insane hours. It was like, 80, 100, I don't know. Like, I just went home to sleep if I slept, but I got it out, right? And that's why I'm like, oh, balance, you know, whatever [laughter]. So, I got my release out. It's out, released the software, all good, but it's still my shop, right? So, like, there's no such thing as PTO, right, because I still have to be there.

And I knew I was completely obliterated. I was totally scorched earth, burnt out. But I had this software on my laptop called RescueTime, right, and it just tracks what you do: when you log in, when you log out, what do you do. Anything on your laptop, it's all logged there, right? And I just had it running passively for years to just see how I was doing. Because I was interested because it was my shop, right? And I was interested in efficiency. I was interested in maximum productivity, but I could do what I wanted. There was nobody who was going to tell me how to schedule my day, how to do my work.

So, I was like, okay, listen, I know I'm screwed. My brain is pudding. I'm going to go in every day at 10:00, and I'm going to work until I just don't feel like working anymore, and then I'm going to leave. I'm going to do that for a week, and I'm going to grant myself just a little bit of grace to do this thing. And productivity-wise, dead flat even, dead even, dead even, like, in terms of actually getting to work this 80-hour, crazy week because I was burned out before I even started the week. But I was just going to sit in this chair until it was done, no matter what.

And then, like, the week where I'm just like, I'm just going to do whatever, you know what I mean? If I get 30 minutes, if I get an hour, if I get 2, then that's just what it's going to be, you know. No zero days, but I'm not going to be a hero. I already did that, exactly, exactly the same, exactly the same amount of productivity. And I was just like, oh [laughter], that's not how I feel about it. I still don't know how to feel about it, but I did take a lesson [laughs].

DAVE: There's two things I love about that story, Will. The first one is that you actually went and got data, and that's rare. But the even more rare thing, the second thing you did is you listened to the data once you had it.

WILL: [inaudible 28:18]

DAVE: A lot of people don't like their core beliefs challenged, right?

WILL: And not...I didn't listen well [laughter]. Like, me and the long [inaudible 28:26] we're still familiar.

DAVE: Okay, you need to be beaten with the stick a little more.

WILL: [laughs]

DAVE: Okay, that's fair.

WILL: I just keep it in my mind. Like, it's just like Jiminy Cricket shows up on my shoulders, like, you should show up, man.

MIKE: We talked about this in an episode, I don't know, a while ago. I had some burn out a few years ago. And the sort of thing, we're putting in tons of hours, just always going, going, going, going. And we as a team dropped the amount of time that we were spending, and our productivity went up [laughs]. And I felt so much better.

Like, what have I learned from this? And I've made a really conscious effort now for years to draw limits, draw boundaries, don't go too far, because I know it's not actually going to help. And, actually, my career's done better [chuckles] as a result. You know, having those boundaries did not hurt me at all.

DAVE: I would argue you do kind of need both, right? It's like, when we go to the gym, we're not there for moderation, right? We are there to tax the system as hard as...we're there to tax the system so hard it becomes damaged so that it repairs back stronger, right?

And when I hear these stories, and I think about my own war stories of, like, when I had a sleeping bag under my desk at Evans & Sutherland because the graphics drivers were due and had to get done. And was that sustainable? No. Did it change who I was for later? Yeah, kind of.

It made certain stresses just become zero for me. I'd be like, oh, yeah, I know how to deal with that. That's...doing an all-nighter tonight. It sucks, but okay. And that sets up a dynamic balance where one day you come in, and you just absolutely sweat blood out of your eyeballs. And then the next day you come in and you just kind of get through. And at the end of the week, you have to look back and say, longitudinally, how did we do?

And I like doing that intermittent thing just to look back and make sure, did I have...if I've got five days where I'm cranking, you know, 2,000 lines of code a day, by Friday, I have to look back and go, I maybe need to talk to my therapist. We might need to adjust my medication. This is not [laughter] a healthy level of sustaining. This is...everyone around me is going to be, Dave is full ADD squirrel this week. Watch out. Or the same thing, you get to Friday, and you look back, and you go, everything stumped me this week. Why was I low on resources? And you can kind of come at it strategically for, like, how will I deal with this at a larger scale.

WILL: And, I mean, that exact reason is why I like the analogy of wellness and mental health, right? Because my wife's a therapist, right? So, I get a lot of lessons from her in terms of, like, people managing their mental health and going through things. And, like, one of the big problems with mental health is, when you're doing everything right, and you're going to sleep, and you're going to the gym, and you're eating well, and you're drinking in moderation. You're just, like, staying off social media. You're doing everything right. You're checking all the boxes. You feel great.

And then you stop because you feel great. And you're like, I've graduated, but you didn't [laughs], you know. It's like, oh, I've been taking my meds every day for six weeks. I've never felt better in my life. That's enough of that. And, similarly, I just accept that I'm going to grind for a release, you know. I'm going to grind, okay? I'm going to grind. This is going to hurt, you know.

And I'm going to go, and I'm going to hurt, and I'm going to, like, crash out. And I'm going to completely suck for the next, you know, it depends, you know, a day to a week, you know, to a month if it was really nasty. And then I'm going to try and balance it out, you know. But I'm not trying to smooth that line out. I don't think that's possible, you know.

MIKE: That goes to Thomas' point. If you're going up that hill, you're going to have to swing those handlebars to one side and back. You're going to be doing some wild swings. But the trend line is what you're trying to keep in control.

KYLE: Something that we're also kind of touching on is I think that we're talking about these environmental factors when this concept of balance seems to be more of an internal concept of how you would apply yourself to those external forces that you can't just level a line across.

WILL: Yeah. Well, I mean, and that's a really interesting, you know, maintaining your equilibrium in a system that may be systemically out of control. That's...I don't know, man. I'll get you guys in trouble [laughter]. I could be done, but you may have to utter some heresies, you know, that are not, you know what, I'm going to mute my mic.

MIKE: [laughs]

WILL: We've got a hand up. Like, save me from myself.

MIKE: [laughs]

THOMAS: I think a lot of it is also self-assessment, right? Looking at other people perform certain actions, you could think that's an extremity to yourself, but to them, it's not. And that's them maintaining their balance. Kind of back to the gym analogy, you know, you could see someone in the gym benching 300 pounds, and you're thinking, whoa, they're overdoing it. They're overdoing it. But to them, that's normal to them, you know, to you, it might not be, you know, achievable just yet. But you also...yeah, a self-assessment is involved with that balance, and each person has their own extreme level, and each person has their low level, so...

WILL: It's true. I mean, one of my more pathological things is, like, Fridays. I really like [inaudible 33:56] on Fridays. Like, I like to, like...I like to close the week out with, like, a dub. It makes me feel good. I'm happy, you know. But consequently, like, people will look at me, and I'll be, like, 6:00 p.m. on a Friday, and I'm like, I could get this in. I'm going to get this in. I'm going to get it. It's not...you know what I mean? It's not that I'm pathological. It's just, like, I really like to wake up on Saturday morning feeling, like, good, you know? I don't know. Maybe that's unhealthy, and, like, this is a conversation I need to have with my therapist.

DAVE: I disagree. That will save your career, man.

WILL: I just feel really good when I [inaudible 34:30]. And I'm like, yes, you're welcome, world. We got it [laughs].

DAVE: If I could teach a junior programmer one thing, it would be look at your work and take satisfaction in it. That will get you up in the morning. And that will turn this career into an addiction, and that will turn this into a spectacular career because you will be passionate about it. Absolutely. Absolutely.

MIKE: And we've talked about the trend line going up. You can strengthen yourself. And talking about the strengthening yourself, by hitting higher peaks, you can hit some extremes. You might need to take some breaks afterward. Talking about cycling, I can go a lot further today than I could some years back, or I can go the same distance and not destroy myself [laughs] like I could a few years ago. You know, that happened by repeatedly flexing that muscle and then running that trend line up. But that meant I had to take some breaks. You do a really hard day, you might need to take a few days off, and that's fine.

WILL: Yeah. Yeah. I mean, like, my bad days, you know, like, I was having, like, a lower output day yesterday. But I actually made a list of, like, all the stuff I did, like, on my, like, not, what, no PR today, like day. And I'm feeling it. I'm like, oh, wow, okay, never mind. That wasn't so bad, you know. That was little bit by little bit.

But I did want to loop back, and I wanted to loop back to Alfred. Can you expand more on what you mean by, like, sort of, like, you've got to keep momentum up? You've got to keep velocity up to stay in balance? Because I think you were going somewhere there, and I didn't clock it the way I wanted to.

ALFRED: It was just something that I was, like, thinking. Now, self is a balance, right? If we are, say, like, emphasizing...how do I put it? So, when you are running, like, you know, too slow, and then when we are talking about, like, you know, say, reduce meeting time or increasing meeting time, probably it doesn't even make any sense. But then if we are running at some kind of, like, optimal speed, then those notions become necessary. So, certain speed is the precondition to balance self.

WILL: Yeah. Yeah.

DAVE: Do you think that speed changes? Do you feel like sometimes it's balance means standing in stillness and other times balance means dancing down a line?

ALFRED: [laughs] I don't know. I was just thinking. You know, I find like...

DAVE: I'm just asking. I legitimately don't know either. Yeah, it's like --

WILL: I don't know. No zero days. I hate a zero day, man. Nothing in life makes me mad, like, worse than a zero day [laughs].

DAVE: By zero day, you mean zero output?

WILL: Yeah, zero output. Standing in stillness? Ooh, not for me. You know, I'll gear down. I'll gear way down. Like, I'll creep up that hill if that's what needs to be done. No zero days.

DAVE: The winch, right? If you get an inch and you don't lose it, that's an inch. Yeah. Winch yourself forward if you can't run yeah.

ALFRED: I guess what I could do is one example I want to make. Let's say you have a...Because we've been experiencing, you know, different places...Oftentimes, when you have a lot to talk about, you can run your meeting fast and then up to the point. You just don't waste any time, boom, boom, boom, boom, boom; everything is done. So, it's very efficient. Everybody can achieve what they want to achieve. And then communication is also there.

But then when we are not doing much, then you start to see, like, you know, very low-energy meetings. And then people are just trying to, you know, for the sake of joining the meeting and join the meeting. So, in that case, it's like, you know, just creating burn, and that burn doesn't yield anything productive. So, having the right agenda and then going to the meeting, quickly gets it resolved.

So, I'm a strong believer of no meeting should be more than 30 minutes, you know, sometime if you can do it in 5, 10, 15, great. And then you get what you need, and you have the time back to the team. They can go back to work. And then they will come back with more, like, up to the point questions during the next meeting. So, to increase our velocity helps with our balancing but not to, like, you know, to the extent where you burn out the team, where everybody is just kind of, you know, hey, I can't even breathe [inaudible 39:19] [laughs]. That's just like, you know, killing the team. So, the balance, you know, it's a very delicate topic, I mean.

MIKE: You're saying that you have to...there's a sufficiency requirement. You need to be going fast enough that if you go below that, you're not getting anything from it.

ALFRED: Right. You will be off balance.

WILL: Yeah, absolutely. I mean, it goes all, I mean, like, via velocity, right? Velocity has to be balanced as well, right? Like a car engine, you know, you can run any car engine at, you know, 10,000 RPM for a while, [laughter] you know. But at the same time, like, if it's running at, like, if it's just idling, it's not going anywhere. The car is not moving. There's a sweet spot. If you're in it, then you're moving to the best you can. A big piece of that is just sort of, like, there's a level of acceptance of what you could do, which I think is difficult.

I think it's really hard because people...I mean, maybe I'm just protecting myself, and I should wrap it up quickly. But because it's in your head...like, if you're lifting weights and something's too heavy and you can't lift it, and you can accept that. But if it's in your brain and you just can't maintain focus, it's a lot harder to get your head around.

KYLE: I was sitting here thinking with the number of people...We were discussing that number of people, like, in a meeting. I think there's times when...and meetings are just an example. This could be used in other ways. But there's people that are in a meeting just to be there, to grasp the information. And then there's people that are there to move the meeting along.

So, this is kind of a question for the group. How do we think that these summarization tools or AI tools are going to impact these type of meeting overloads going forward? Because there's several scenarios where there's information from a meeting that I could be privy to, but I don't need to go to an hour meeting. I can just read a 10-minute summary and be caught up, and I'm good to go. And with tools like that, is that going to help with the pendulum? Like, I assume so, but are they going to be allowed and... yeah.

MIKE: You see James talking. He does these in meetings. I love it.

KYLE: This has been --

JAMES: I wish we had a little more automation around it, of course. But I would be completely unable to do my job without the ability to record and receive a transcript of every meeting that I run through an agent that I created.

KYLE: Oh, really?

JAMES: It will accept any Word document, and it first gives an executive summary. It gives me the attendance. It gives me a comprehensive list of what we've talked about. And at the bottom, it provides action items with responsible individuals and due dates. And it seems like the most trivial thing once, like, now that I'm just spitting these documents. Previous to this, I had to manually document in Confluence the goings-on for our stand-up. And while I'm trying to make sure that as I'm onboarding that I'm paying the proper attention to all of these different services and features that we're either connecting to or developing for, it really cuts the difference.

So, now there's times where if there's a word or a term that I missed, it usually comes out in that comprehensive report. And then I can go start pinging other people. And it's helped me better establish the business relationships that I need as well, since it's like, oh, I don't understand this word. It looks like we had to go talk to this individual about X. I'm going to go ahead and ping them about some other information as well. My ramp into Acima has been 100% blessed by having Copilot access.

KYLE: Okay, cool.

DAVE: It's awesome.

JAMES: I use it so much that I think I'm the only person who ever exhausts their allowance for AI credits [laughs].

DAVE: Nope. Nope, you're not the only one, brother [laughter]. I'm actually on the $100 a month plan with Claude because I just destroy his tokens every single day. It's awesome.

JAMES: They've got Haiku, which is, like, the newest version that's out, and it's only charging third credits right now, so yeah [laughs].

DAVE: Nice. So, I was bellying up to the bar behind Kyle. It's a different tangent, which is why I wanted Kyle to go first. But there's some theory written by Carse,- James Carse, "Finite and Infinite", I think, Games. I think he's a game theorist. But he breaks a lot of human interaction collaborations into finite and infinite mindsets. So, finite, you're trying to win. You're trying to get to the score. You're trying to get to 21. You're trying to get to victory, and the game ends. And that's his thing. You think you're trying to win, but what you're actually trying to do is end the game.

Infinite games, you're trying to keep the game going. So, like, hacky sack or, you know, like, bumping the volleyball around, like, that's a game where everyone is involved with trying to keep the game going, right, to keep everybody playing. And so, the person that told this to me was a marriage counselor who literally was saying, I have to teach husbands and wives to play infinite games instead of trying to win because all you're going to win is divorce paperwork, right?

And what I'm realizing is, if you're playing basketball, if you're playing a competitive sport, you want to play a finite thing. And if you're going to a meeting, you probably want to play the finite game. What do I need out of this meeting to get a victory? I've actually got it. I'm just going to go, right? That's for that one.

But when you're dealing with people, you want to deal with balance and with finite. And somebody said something earlier about it's the attitude that you have internally, like how you present yourself to that. That, to me, really, really smacks of, like, I'm playing the infinite game with myself. I'm trying to be sustainable. And sometimes that means you've got to knuckle down and just absolutely finite. Have I just destroyed this metaphor? I feel like...I don't know if it's all muddy, but, like, choosing your times and places, I guess, is, like, choose your strategy of how you're going to deal with this, and choose the right one.

WILL: I don't know. I just love...I love...I read 20 times faster than audio, about that. You know, most people, like, you know, like 10 to 20 times faster than talking. So, if I don't need to collaborate with somebody, you know, like, we've got something that we need to, like, put our heads together...

I was in a two-hour meeting, like, earlier today because it was just me and a couple of the devs. And we were going over, trying...We got our PLPs aren't loading as speedily as we'd like to, and we were just diving into the analytics. And, like, so, like, okay, where are we leaking? Where is this thing? You know, [inaudible 46:22] trying to teach us a lesson.

But, like, generally speaking, I'm like, I just want to read the minutes and get out, like, that's, fine. And also, like, I'm a zealot in terms of, like, cams up, mics up all the time, all the time for everybody. Cams up, mics up, or get out [laughs]. And I say that knowing full well you could see me multitasking because I've got a couple of, like, pots simmering, right [laughs], you know, and I'm in and out, you know. Because I've got, like, you know, 20% capacity, like, tasks that I'm just, like, keeping rolling. You can see me doing it, and I have no shame. But at the same time, like, I'm not, like --

DAVE: That's honest.

WILL: It's not like, what's Will doing? What's Will doing behind the curtains shhhh, you know [laughs]?

DAVE: Right. I love that. I call that clear eyes and respect, where clear eyes is if I see you doing some BS, I'm going to call you on your BS. But the respect is, and then I'm going to keep listening to your BS because you're probably doing what I need a co-worker to do. And if you're honest about it, and I respect it, and I don't call it, you know, I'm not going to give you crap about it, then great. We both understand that that's how we're going to interact. And I like that.

I would much rather, like...because if I told you, "Will, it's really pissing me off that you're not paying attention," you can make a judgment call. You're like, "This really isn't that important to me." I'm like, "Well, it is because this." And I am confident that if I could show you why something was important to me, that you'd be like, "Okay, you got me." Or you would convince me that, like, I can't actually convince you that this is important. So, we'll see you at the Q and A.

WILL: Sure. Yeah. All right. It might just be bad behavior on my part though. Like, this could be a filthy habit like picking my nose when the camera's off or something, where it's just like, dude, don't do that. Come on, man --

DAVE: But if it is a bad habit, now we can call you on it, and we can communicate it. If you're hiding, it's a bad habit, and it stays a bad habit, right? So, I love that feedback.

MIKE: I do turn off my camera to blow my nose, or sneeze, or other things that might, briefly, be offensive [laughs].

WILL: It's distracting. It's distracting.

MIKE: Exactly [laughs]. We have ended up spending most of our time starting with meetings because it's such a hot topic around this balance, but it applies to so many other things, right? We've talked about balance all the time. So, while we've talked about it in the context of meetings, this could apply to planning on projects, probably applies to testing, to the scope of a project. We've talked a lot about that in the past, how much you should pay for your tooling. There's a huge list of things, and we could just go on and on and on because it's worth thinking about.

And they had this common theme to check yourself, right? And we've talked about this. So, what are some tools we can use? What are some things we can use to notice we've gone too far? And that matters. You know, I was thinking about meetings for that measurement of how you can go too far. We want to be agile, right? I've got a co-worker who says, well, agile doesn't mean ad hoc. He's right.

WILL: That's a good one.

MIKE: It is a good one, isn't it [laughs]? You still do planning. You just have a tight feedback loop with the customer, right? And you do frequent iterative planning rather than trying to plan everything up front. And I think that if you notice that there's a disconnect between you and your customer, it could be an internal customer, right, between you and whoever's asking for the product, then, one, you probably need a meeting. And if you don't have a disconnect, you've probably talked enough, and you know, that applies there. But finding some metrics. Am I going off in the gravel, right? Am I tipping over? Then it's time to start swinging the other way.

WILL: Man, I miss my RescueTime. Obviously, when you're working for other people with a corporate laptop, that is, like, that's going to give security, like, a brain aneurysm. Like, it's not going to be...Like, I've been off of it for a long time. But, like, your screen time metrics, to the degree that you can collect them, that's a good indicator. You know, it's the screen time on your phone. How are you doing? How are you doing when you get home? How are you doing when you get home?

You get home, like, and you're just, like, you just, like, you walk in the door and, like, you're completely spent. You're exhausted. Like, ooh, that's not good. Sleep patterns, you know, like, how are you sleeping? It's both a virtual cycle and, like, a really big canary in the coal mine. It's both going to affect your performance and indicate, oh, something's not right, you know. There's lots of stuff, lots of stuff going on. Sorry, was that the thing where it's like, how do you [inaudible 51:14]

MIKE: Oh, yeah, no, that's exactly it. You're finding metrics that you can use to gauge where you are, you know, where are the lane lines? So, you can watch them. That's exactly the direction I was going. This balance is critical, but if you don't measure it, you're not going to know. You're going to be off in the weeds somewhere, right? Like, oh wait, how did I end up here? Because you weren't paying attention.

WILL: Yeah. Yeah. I mean, honestly, at work, I think, for me, and I think for a lot of people, you know, you're going to leave, you know, your work is going to be the last thing to suffer. I don't know. I hope most people aren't like this, but I think a lot of people are, where, like, your work is going to be the last thing to really start to, like, break down in your life when, like, you're getting these burn out pieces, you know?

MIKE: Yeah. It's...I know I've been that way before [laughs], and it's not nice to the family, right? Not nice to the people you care about.

WILL: It isn't. It isn't, you know, like, it's just like, oh, it's a bunch of strangers. Everybody is trying to make their quarterly numbers, and it's just like, okay, these guys come first [laughter].

KYLE: Your screen time comment kind of hit close to home, for me, just because there's been a few times where it's been, you know, and work is the last one to suffer. Like you're saying, it's me going, I've not spent very much time on my personal projects. I've not spent time on my hobbies, you know? And at the end of the week, I just kind of left the setting on my phone on. At the end of the week, I get a, you know, a ping that's like, hey, you spent, you know, three hours more on your phone than the previous week. And it's like, oh, okay [laughs], that might do it. It's just kind of that check that, like, it hits you hard.

WILL: Yeah. Like, screen time on your personal phone is a really strong indicator of, like, your mental health, you know. You can't have RescueTime on your work laptop. I mean, maybe you can, but probably you can't [laughs]. Probably that's no good. But, like, that phone is right in your pocket all day, every day. And, yeah, it'll start pinging at you like a smoke detector.

MIKE: Well, I think that's a good place to end here. We've talked about this importance of balance, and we'll end with measure it [chuckles], you know, figure out...keep your eyes open. Have you ever tried looking behind, well, when you're driving a car, you keep your eyes on the road, right? It does not take very long looking away, you know, looking down to grab the food, whatever you got. You look up like, oh, I'm going the wrong way. You feel like you're going forward, but you're probably not. You're probably drifting.

And if you don't have some of those measurements to see whether you're staying in balance, you're probably not. I loved the discussion today [chuckles]. We had a great discussion. It was great. We had a big panel, lots of comments. I hope that you get something out of this, and think about what you can do to measure and get some better balance in your meetings and everywhere on your life.

Until next time on the Acima Development Podcast.

The episode centers on miscommunication—why it happens so often and how to handle it better, especially in remote work. Mike opens with a story about baking baguettes for his in-laws: he and his wife look at the same “thin and crusty” loaves but interpret that comment totally differently. He thinks she’s critiquing what he intentionally made; she’s trying (poorly) to request thicker, softer loaves for garlic bread. Only when she circles back and explicitly explains what she meant do they align, adjust the next batches, and get the bread right. That small domestic example sets up the theme: communication is hard, assumptions are deadly, and clarity requires deliberate effort.

From there, the group digs into remote work realities: cameras on, clear signals, and good tooling. Kyle and Will argue hard that turning on video dramatically reduces miscommunication by adding facial expression, body language, and a sense of shared humanity and accountability—especially across locations, time zones, and cultures. They rail against “Helen Keller mode” (muted, cameras off) and the bloated calendar of half-attended meetings that results when people aren’t fully present. They stress being “remote-first” even in hybrid environments, using the right tools (Slack vs. Teams vs. Jira/Confluence), and leveraging things like transcripts, screen recordings, and diagrams to convey ideas. Visuals and written records aren’t just nice-to-haves; they’re how humans actually process information and how teams keep “receipts” for decisions and responsibilities.

The conversation then shifts to practical tactics for both preventing and repairing miscommunication. Preventatively, they recommend restating what you heard (“So what I hear you saying is…”), insisting on written decisions, documenting problems with specifics (what you did, what failed, error messages), and always answering the who/what/where/when/why/how when assigning work. Rich PR descriptions, Jira tickets with a clear “why,” and AI-assisted meeting summaries all make future understanding and debugging much easier. When miscommunication does happen, they suggest treating it like a production bug: regulate emotions first, acknowledge the other person’s experience, look for root causes rather than blame, and focus the discussion on “what happened and what do we do about it now.” They close with a quote: “The void created by the failure to communicate is soon filled with poison, misrepresentation, and drivel,” underscoring that silence isn’t neutral—if you’re not communicating clearly, you’re inviting confusion and distrust.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I've got, as usual, Will Archer. Welcome, Will. We've got Kyle, and we've got Jordan. Thank you for joining us.

And we have a topic to discuss that's been on my mind. It's...yes, stuff has come up lately, but stuff comes up always on this topic. In fact, outside of work, something came up for me today [laughs]. I'm going to my in-laws tomorrow. I'm getting a family get-together. I get along well with my in-laws, so this isn't, like, a bad scenario [laughs]. It's an okay scenario.

But I am bringing bread. We're having lunch, and I'm supposed to bring the bread. We're going to make some garlic bread. Anyway, so I was thinking, a couple of weeks ago, you know, I want to make baguettes. I love crust on my bread, so I want to experiment with that. So, I was making some baguettes, you know, baguettes are long and skinny. That's their thing. That's why you do them because it's crusty.

And I was going to make three batches to take to my in-laws: sourdough, a white bread, and whole-grain bread. And I had made the sourdough one, and I had made a test batch earlier in the week. And this batch came out fantastic, exactly how I like them, because I like crust on my bread. I've been that way since I was little. I love crust on my bread. I love a crusty, you know, the more crust the better [laughs]. I love a crusty bread.

So, baguette is perfect because, you know, it's so crusty: so thin, you know, thin loaves, lots of crust, love it. And I talked with my wife about it earlier in the week. She's, like, "Yeah, that's the kind you like. I like the bigger loaves because they're chewier in the middle." But she had some of the crusty ones, and she liked those, too.

I kind of forgot about that conversation, and I went to make some bread today. I'd, like, raised overnight, got to the bread today. This is going somewhere [chuckles]. This is going somewhere. So, I made the first batch as a sourdough one because I'd let it raise in a warmer environment because sourdough takes longer. And they came out of the oven. And I put it up, and my wife looks at them. And she's, like, "Those are some really thin loaves [chuckles]. They're thin and crusty."

And I looked at them, and I thought, yep. I think that's what I said [chuckles]. "Yep, they are. That's exactly what I was going for." And, in my mind, I thought, yeah, that is true. That's what baguettes are supposed to look like, and that's what I did. And as I was thinking about that, like, "Why are you even saying this? Are you thinking that I'm doing something wrong? Because [chuckles] I know you kind of like bread a little softer, but we're supposed to be having small loaves because we're going to be making garlic bread."

So, my mind was running, and her mind was running as well because she was thinking, why did he not say anything? So, what she was thinking was, those aren't the loaves that I want. I want to bring bigger loaves. And what I was thinking is, yeah, they came out exactly the way I wanted them. So, two totally different perceptions of this conversation.

She came up to me about 15 minutes later, and she says, "You know, I was talking to you a few minutes ago, and I said that those loaves were thin and crusty. Did that come across as an attack?" I'm like, "Well, no, not really [chuckles]. But I wasn't sure what it was." And she said, "What I was trying to say is that I want thicker loaves. I want us to bring loaves that are bigger around so that they're less crusty, softer on the inside." Like, oh, okay, so that's what she wanted.

When she was talking about the bread, what she was trying to communicate is, how about for those other two batches you don't break it into three loaves but you break it into two? But that was not explicitly mentioned by either me...I didn't restate anything. Like, I didn't do anything to clarify. And her expression, you know, what she had said to me was true on its face, but didn't give me any information.

So, neither of us had done anything to improve the communication to get to the outcome that I actually wanted to get the right bread over to the in-laws. But she came back to me. She followed up, and we coordinated. I made the second batch already during lunch. They came out beautiful, these gorgeous loaves. I almost want to take a picture and post [laughs] it with the podcast because, oh yeah, they came out really good. And the last batch I'm going to do this evening afterward.

Everything worked out great because we got together to clarify and figured out what the exact requirements were. We went back and forth. I repeated, "Okay, so you want a bigger loaf. Do you want, like, one big loaf, or do you want two?" And we coordinated. So, she didn't want one really big loaf. Two was just about right. We tried it. It came out just like we wanted.

The topic today is about handling miscommunication. There's an example from just normal life today. We've all had it. We've probably all had it today because this happens all the time. And if you're working with any other human being, it's happening all the time because it's hard. Communication is hard no matter what.

Every time I try to talk to people, or if anybody tries to talk me, if somebody tries to talk to me, it's hard to get things right. And when you're working with people overseas, so they have different time zone, different culture, it gets even harder. There's all kinds of things that make this communication harder. And I want to be tactical for our conversation today. What can we actually do? And I've got some notes written down because I've got some ideas.

And I'm kind of, like, in our overall, you know, look at the big picture of the map of our journey. So, I'd like to talk some about what you do before you make a decision so that you can avoid miscommunication in the first place, and then also talk some about, like, okay, miscommunication has happened. What did we do to deal with it?

KYLE: One thing I've found...because, at Acima, it was very much, you know, you were talking face to face for the most part, and granted, miscommunication happens there. But when the Acima folks, which are located in Draper, when we started interacting a lot with the Rent-A-Center folks over in Texas, I ran into a lot of miscommunication. And I found that a lot of that was because of virtual interactions. And there was one button, be it in Slack or Teams, that really helped me, and that was the video button.

Turning on, giving them my mugshot, just so that they could see me, and I could see them. Like, there's something about facial interaction, or, you know, yeah, facial features, and what you're doing as you're communicating. And being able to kind of read lips as well, I think, really kind of helps at least me. And that cleared up so much of the miscommunication that I was experiencing when working with the other guys, like, just that.

WILL: Oh my God, yes.

MIKE: [laughs]

WILL: Oh my God, yes. I do not, so, like, you know what I mean, like, I, you know, consultant, hired gun, wandering samurai, you know what I mean. And I don't have the latitude to, like, rule with an iron fist in ways that I miss dearly. But I have no idea, no idea how people who manage distributed teams have allowed the rampant use of Helen Keller mode, right? [chuckles] Where people are muted, and video is off [laughter].

Like, it is, like, the stakes are so low. Turn on...the flick of a finger, right? The benefits are so high. And the cost of just willfully disregarding this kind of communication is so ridiculously high. It is negligence of the highest order I have...I know why it is. Like, I know why it is. But you just can't do it.

And, like, me, so, like, me, you know what I mean, I'm a high-priced consultant, right? Fully remote. People don't see me. They've never seen me. I've never been in an office. Like, I've seen face-to-face one person that I've worked with for the past five years, right? If you're a remote distributed worker on any circumstance, that camera needs to be on all the time.

I have survived many, many, many layoffs in my...this is best practices. They need to see your face. They need to see your face for your benefit, for their benefit. There's absolutely no excuse unless you're doing something with your time at work that you ought not to be doing.

And then, I mean, real talk, you know, you need to get right with your workday. It is a privilege, and we are paid lavishly to sit here and think hard thoughts and type on a keyboard every day. Do better. There's no excuse. None. As people who are in a position of authority, I cannot overstate this, and I could not put it in more emphatic terms on a family podcast [laughter]. You've got to get right with this immediately. Sorry. Thank you for coming to my Ted talk [laughter]. I feel very strongly about this issue.

DAVE: I dig it. I dig it. For those listening at home that don't have the cameras on, my camera's currently showing nothing [laughter] because I'm microwaving my lunch while talking to the podcast.

WILL: Yeah, that's right.

DAVE: Not that I'm the object lesson, Will. That's right. That's right.

WILL: We're recording him. And we [inaudible 10:19] to the world, and he's microwaving his lunch.

DAVE: That's right. That's right.

WILL: Okay. All right, then.

DAVE: Yeah. Yeah. You're so right about the camera thing. I have noticed it correlates highly with psychological safety that we've talked about in the podcast in the past, where, if you turn off your camera, you kind of feel safe because you're hiding. But who are you hiding from? You're hiding from the people that pay your rent, right? You're hiding from the people who want you [laughter] to solve really intricate problems for them, and that interplay is there.

The one thing I would say, I would say you don't go far enough, which is that face-to-face in person is so much easier because there's no latency. And when we get on cameras, that latency there, like, we've all had that, "Oh, you what? Oh, you- Wh- Wh. I'm sorry. No, you go ahead. No, you go ahead [laughter]," right? That whole latency thing, like, that messes up conversation more than you might think, and so you have to lean into it really, really hard.

MIKE: I've been remote a lot of my career as well, and I couldn't agree more that having the camera on is...you know, there's the occasion I turn the camera off, big meeting where I'm not going to participate. Even then, sometimes I'll turn the camera on.

WILL: No. I will leave the camera...I'm not going to unmute myself in a 200-person meeting.

MIKE: Right, because --

WILL: But, like, I'll do it. Like, I'll be on camera. Like, everybody knows what my cat looks like.

KYLE: But it's that whole thing, right, where now I don't see Will as a black box. I've never seen him in person, but now I see Will, and, oh my God, Will's human. He's got a cat. Maybe I have a cat, you know. All of a sudden, the things that I hated about you don't matter as much, you know what I mean? If I've had a bad conversation, maybe now I want to communicate with you better. It really does affect everything in my mind.

WILL: Yeah. I feel like, yeah, I can't overstate it. I can't overstate it. Like, for distributed teams, there are so many people who are sort of like, you know, like, there are challenges around remote work. But when people are, like, oh, we just couldn't figure out how to make remote teams work and they're making these just sort of, like, boneheaded, day one, unforced errors like that, it's very hard for me to take leadership seriously when they're that bad at it. We can't make this work. We just can't figure it out. And I'm like, have you tried the easiest, stupidest, laziest thing you could possibly do? No? You know, I don't know. I think, yeah, I won't pull any further on that thread, but, like, come on, guys, try --

KYLE: Well, it is a cop-out at some point, right? Because the minute that you go from one location to multiple locations, your remote philosophy kind of goes out the window because your remote teams still have to interact with each other. Regardless of whether or not they're at home or in the office, they're going to have to interact with each other.

WILL: I don't know any...like, I know...I think pretty much across the board to, like, greater or lesser degrees, like, every place that I've worked and, like, all of my friends work, have all been, like, we're really serious about RTO. We're serious about RTO. We're serious about RTO. And every last one of them is lying through their teeth because they're doing nothing. They have, like, many conflicting standards, many distributed teams. Like, even if they're in the office, [inaudible 14:15] with the same office, and it's just, like, I don't know, guys, you got to do better.

MIKE: Even if everybody's butt in seat, you have to be remote first because you're not in the same office. So --

WILL: Exactly. There's no, I don't think...I mean, like, the excuses, it's non-negotiable. You have to be good at this. You have to be good at this, and if you're not good at it, you need to figure it out. You know, I don't know. Yeah, sorry. I don't want to make this into a RTO rant, you know, that is just sort of where a lot of these miscommunications come in because it's harder. It's just harder. It's harder than it was, you know, back in the day. Well --

KYLE: It's difficult

MIKE: Different.

WILL: It has new challenges, you know, because I don't actually think it's all the way hard. I think our tools for collaboration, for, like, you know, keeping receipts, for keeping logs and messages, for keeping logs and messages that happened last year, stuff like that, I mean, I think, like, the tools are there. And if you make just a little bit of effort, you know, getting really good at Jira archaeology, getting really good at generating Confluence documents, getting really good at taking AI tools and generating documentation for your stuff, getting really good at, like, you know, Slack messages and groups and, like, it's easier.

You can do an easier, better job faster. You have to accept, like, this is the reality that you're living in. And it doesn't matter about your feelings. You're going to have to come to terms with it, and adapt to it, and use the tools that are sitting on the workbench in front of you. Pick it up. Pick it up and use it. It's so easy.

JORDAN: Back when we were still talking about turning your camera on, I was thinking that, like, on top of aiding in communication and, like, seeing the body language, I think it also adds some accountability. Because I remember back in college when it was COVID and we had, like, remote classes. And everyone's camera was off, and just the teacher was just, like, in this Zoom call with, like, 30 other people, cameras off.

It just felt so easy to ignore the teacher and not answer any questions because no one else is. Like, you can't see what they're doing. You don't know if they're participating or not. And I think having the camera on, like, it's less intimidating speaking up, and you can see everyone, like, I don't know, listening, participating, so...

MIKE: True.

WILL: There's a lot of people, well, I mean, I think, one symptom of camera off mentality, and you're right, the absolute lack of accountability. Because if you've got your camera off, you can be doing anything. Like, I'm not going to lie. Like, I've got some long-running, like, tasks cooking, like, right now on the big screen while I'm talking with you guys. And I will go over here because I got stuff going on. And you know it, and it's okay. I'm not sorry. And I'm not going to stop [chuckles].

But what you'll run into, like, symptomatic of this is this sort of, like, meeting creep. Meetings are really expensive. And you shouldn't be in as many of them as you are. And there shouldn't be as many people in them as there are. And because everybody's on Zoom, you know, deaf, dumb, and blind, or, you know, whatever, the Teams or Google Meet, or whatever you use, they're all pretty much the same: deaf, dumb, and blind.

There are all these meetings, and everybody's half in there. And they're not paying attention. And they're just filling up their day. If you had to have a meeting room for this, like, because I did it, if you had to find a meeting room, and you had to book a meeting room, and you had to get butts in seats, this meeting load was not possible. And no one would even think to do it.

MIKE: I think it's one of the things that we haven't cleaned up yet after COVID. There's still some cobwebs [laughs] to wipe out of the corners. We got in the habit of doing everything, all of these online meetings, without really saying, yeah, if we're going to do this, we need to do it well.

WILL: Well, I mean, cam's up, mic's up. What? If you don't want to put your camera up, or it's noisy, if it's noisy, why are you in this meeting? Why are you here? Don't be here. If you don't have time to pay attention to the meeting, don't be here. If you wanted to, like, I mean, just think about doing it, like, the way you would have had to do it, standing behind a one-way mirror.

And it could be, like, oh yeah, I was, like, hey, Will, what do you think about this? Oh, yeah [laughter]. Say everything you said the last five minutes all over again. What? It's crazy to think that you would do something like that. It's insane. Or somebody, like, think about, like, you know, back in the day stand ups and, like, somebody is just on their laptop. That is, like, if somebody did that in person.

We're all sitting around a table. And if somebody is just, like, they got their headphones on [laughter], and they're on their laptop, like, that's extremely disrespectful. And it's not like my time has gotten less valuable because I'm not immediately in front of you. And I can't poke you and say, "Hey," you know, it's so disrespectful. And I just, you know, I don't know where it ends. And I don't think this is, like, a silver bullet that is going to solve all the problems. But if you're not doing the basics, you know, it's hard to, you know, do the basics, like, the smallest, the smallest thing you could possibly do. Because it's okay to not have the meeting, man. It's okay. Just don't have the meeting or [inaudible 20:15], and send me an email. It's all right.

MIKE: Well, that's actually the perfect segue. We've talked a lot about...and we're in universal agreement that cameras on is just invaluable for meetings. But you're not always in a meeting. We have these asynchronous communication tools: Slack, Teams, email, you name it, for a reason, because they're useful for the times when you don't need a meeting.

And then some of the rules of communication are even higher [chuckles] because you have to make up for the fact that you don't have the face time. So, let's talk about some of the things there.

The first one I'm going to say is you always restate. If somebody's saying something to me, I will try, and I'll make an attempt here. I am going to do my best to say, "So what I hear you saying is," and I will restate it every time. And I actually get a lot of statements of appreciation of that. I think it was, like, yesterday, somebody said, "Mike, can you restate that?" Because they're so used to me doing it that they ask me to do it because they know that I'm the person who does that.

Because when you hear somebody else say it, it shows all the gaps in where the communication is and all the things they're right. You can say, like, "Oh, yeah, nailed it," or, "Yeah, that's right, except..." right? It makes such a difference. If you haven't restated it, I feel like you don't have a shared understanding. And if I'm sharing, I will often ask the person I'm talking to, "So, could you restate what I said? Could you say that back to me?" I want to know what I missed because I probably missed something. I feel like that is just absolutely vital. What do you all think?

DAVE: 100%. My notes for this one literally start with, confirm understanding, so yeah.

KYLE: Yep.

WILL: I do it maybe less often. I do it if we have a disagreement, right, where I think this, and you think that. I want to make sure I have a clear understanding of what you're saying. And, usually, it's because I'm going to try and tell you how you're wrong, but there's just a better way to do it, you know what I mean? Where it's just like, I understand the point that you're making, and this is why I don't think we should do it that way. And, occasionally, I'll be wrong on that, but more often, it's just a rhetorical device to get my way [laughs].

MIKE: Unless everybody has their cards on the table, right? Unless everybody knows where everybody is coming from, then there's, like, no validation.

WILL: I mean, it's very hard to move me off of my position if I don't feel like you understand why I'm doing things the way I'm doing.

MIKE: Sure.

WILL: I do it, but it also works on me. If I'm, like, "Hey, this is the engineering trade-off that we have to make, then I think it's like this." And my boss or my supervisor or some other responsible party is, like, "No, this is not the trade-off we're making." Like, if we had a problem with the strength instructor and somebody is just, like, "I can't get these people to move, so you're going to have to do it the stupid way." And I'm like, that checks out. Let's do it the dumb way [laughter]. Because that's the job, right? Spice must flow.

JORDAN: Additionally, I've had an experience. I think it was...maybe I'm making this up. But I feel like this is pretty common, where let's say during the internship when I was working with Chloe, and we were talking about implementing some kind of feature. And, like, somehow we had a disagreement on how we should do it.

But as we talked about it and talked through it, like, our different points, we realized that we were kind of arguing the same point. We were [inaudible 24:01] for the same thing.

KYLE: Yeah, all the time.

JORDAN: It's just the way that you said it sounded wrong. But without the clarification and validation, it's like, why are we wasting our time when we're going to do the same thing? And we just said it differently. So, I think it's super, super important to clarify and validate your understanding of things.

MIKE: Absolutely.

WILL: Yeah. Well, I mean, and, a lot of times, you'll find, like, that if you clarify and restate somebody's position and they're, like, once you're done with that, you'll just be, like, this doesn't matter. I don't care if we call the class this or that, or it goes in this directory, or it goes in that directory. It doesn't matter. Send it [chuckles], you know.

DAVE: Jordan, the situation you described, I like to call that being in violent agreement, right?

WILL: Yeah. Dave and I love that [laughs].

DAVE: Yeah, yeah. It's like, Will and I will come down to a back and forth. I'm like, "No, this should be dynamic." "No, it should not be static." Wait, wait, what [laughter]?

MIKE: Okay. Next one I want to call up. So, somebody mentioned this to me the other day, and they said that Paul Graham said something about if you haven't written down a decision, it wasn't made. I looked it up. I couldn't find it exactly like that. But I did find that Paul Graham quoted Leslie Lamport saying, "If you're thinking without writing, you only think you're thinking." Which is to say, if you haven't written it down, you haven't actually come to an agreement. Because a week from now [chuckles], you're going to have a very different perspective of what you talked about.

WILL: I would go even further, and this is, like, a very 21st-century, 2025 distributed communication mode. Don't talk about work in DMs. It makes it a secret. You can't hold people accountable for not living up to their obligations. There's been a lot of times where I'll ratchet things up because I need people to show up. And if it's in a DM, it's real hard to be, like, "I asked you on Monday to review this MR, which is very important to my deliverables, and it's been sitting on your desk for days," if it's in a DM.

But if it's in a channel, then I can just sort of start bringing other people in. I could bring your team lead in. Now I can bring your manager in. And when the director comes to me and he's, like, "Where's my stuff?" I could be like, "Here you go. Here's a thread breaking down exactly why your feature isn't getting shipped. Let's have a conversation, you and I." And often, you know, like, just, you know, sunlight, you know what I mean? Like, it's, yeah, it's very helpful.

And when there are disagreements and there are conflicts, if you have receipts and you deliberately maintain aforementioned receipts, then, you know, when those conversations arise as they inevitably will, then we can have...we can skip some steps about who said what, when, why, and how.

MIKE: Absolutely. Any other thoughts about writing it down?

DAVE: My favorite cultural touchstone in that regard is Adam Savage on MythBusters holding up a clipboard and saying, "Writing stuff down is the difference between doing science and just screwing around," and that applies everywhere. It really does.

The thing we're teaching in Skills Clinic right now is calling your shot, which is where you...actually, you have to say it out loud or write it down. And nobody ever writes it down, but you say it out loud. When I run this, this will happen. Here's my test. It's going to fail on this line with this error, right? Like, this is not going to fail with a key error on 39. It's going to fail with a no method error sandwich on line 42. And then you run it, and you see if it happens.

WILL: I think that's a really good segue into, like, how do I get help, right? How do I get help? Where is the problem? There's a problem. And, like, man, like, document it, document, document, document, document, document, where it's like, I did this thing, and then it gave me this error on this line. This is what I have tried. Who is, you know, who's responsible for this module? Because I'm seeing this thing, and I want to fix it.

And, like, when you break it down line by line by line by line by line, you both, like, you know, A, you know, okay, you're establishing a clear chain of accountability. B, whoever is jumping into this thing to help you knows exactly where to start digging for the truth. And, C, it makes it really fantastically easy for the next person who's also using this shared library to determine, like, oh, Will stepped on this landmine. And this is what he did to defuse it, you know? And, man, just, like, just be thorough, you know?

MIKE: I would add to that. If somebody comes into a channel and says, "I'm having a problem getting a network connection to work," nobody will say anything.

WILL: Story of my life. Yeah, man. You don't need anybody else [laughter].

MIKE: But if you say exactly what you did, I've got this problem; it was in this class on this line; here's the error I'm getting; here's what I've tried, it's like catnip. Engineers can't resist because they're halfway through the problem, and, like, I got to solve this. And they will jump in, and you'll get 10 people responding. It's the exact same problem.

But if you don't communicate the background of what you're trying to solve, nobody bites because it's too much labor to get into it. You never engage. Once you get somebody through reading your explanation with what you've done, they can't help but be engaged. They can't go back to whatever they're doing because it's all they're thinking about [laughs].

DAVE: They can't go back to the blissful ignorance of not knowing this problem existed?

MIKE: Exactly [laughs].

DAVE: You guys know the Gentoo rule, right? If you need to get...it's back in the days. So, Freenode was an IRC network, Internet Relay Chat, text chat online. Back before AOL instant messenger was on graphics. One of the channels on Freenode, which was one of the big networks for open source, was the Gentoo channel, and that's a flavor of Linux.

And the people that run Gentoo back 20 years ago, 10 years ago, very, very intelligent and not very patient. They did not suffer fools. But they had a little bit of an ego on them. And somebody discovered and they published it, and people have used it since, and it works. If you do it in the channel, you'll get yelled at. But what you do is, you figure out what your problem is, and then you phrase it as an insult. You walk in and go, "Gentoo stinks. It can't even drive an Epson 1180P printer." And you will have 15 solutions before you can turn around. [laughter]

That does actually apply to the conversation when we're talking about communication and miscommunication. Randy Pausch gave a really famous...he's the guy who gave the really famous last lecture where it was really his last lecture because he was dying of cancer. And he mentioned a thing called the head fake, which is where you're talking to somebody about this, about this, about this, about this, and about this.

And by the time you get to the end of it, they discover, oh, you were actually teaching me about this really important other thing, and you head-faked me. You tricked me into thinking the conversation was about this, but it was secretly all about this. And I think that's when you weaponize it is when you deliberately do it to manipulate somebody's understanding. But I think it's also valuable to understand that, in communication, this happens all the time. There's intentional head fakes, and then there's all the unintentional ones.

Going back to the camera theory, there are cultures where giving shame to another person is the highest offense. You cannot do this. Those cultures tend to run their cameras because they want to watch, and they want to make sure, am I my understanding? And dah, dah, dah, dah, dah. There are also some cultures where you must not accept shame to yourself.

And I have worked with a team...I've worked with several teams over the past 15 years from that part of the world. I'm not going to name names because it's kind of a negative connotation. But, in that culture, it's, you cannot cause me to lose face. I've never gotten one of those people to turn their camera on, ever. And it's just, ah!

You know, it's like, I literally taught a class to 30 icon avatars. And, like, I was begging them, like, "Guys, I need to see your face," and they were muted. So, I'm telling jokes, and I'm just getting crickets back. And they're like, no, no, no, keep going. We're laughing. And I'm like, this doesn't help [laughter]. Turn your cameras on. Engage.

MIKE: May throw out another suggestion. We talked about the importance of writing it down. I guess it's just something else that's related: make a picture.

WILL: Oh God. Yes. Yes. Like, it's so...again, it's so easy. And this is something that I've been really bad at. And I've gotten better because I had somebody on my team, and it was a lady. And she had the most beautiful LRs, right? PRs, whatever you call them. Like, they were great.

And all she did was just took a screen cap, where it's, like, yeah, there's that, cap, that, cap, that, cap. Boom, boom, boom, boom, boom, boom. Figma, man. Figma is, like, crushing. I don't know whether they're crushing it or not. I don't know whether they're crushing it or, like, I don't know, going to get acquired or what. But whatever they're doing, they've taken the industry by storm, where it's just, like, show me a picture. You know, let me pull out the, you know, let me pull out the numbers from that picture. God. Revolution, man.

MIKE: It's huge. I did some little looking today, trying to find out a solid statistic, what percentage of your brain is dedicated to vision processing. It was just choose your own number. The statistics are all over the place. Nobody has a real number. But it looks like at least 10% of the neocortex and maybe as much as 50% of your total brain processing at a given time is visual.

Those numbers probably don't mean very much other than it's non-zero, right? It's a significant percentage. There's a big part of the way we think that's visual. And even when you're not physically drawing something, when you're trying to explain something to somebody, you're trying to paint a picture. You're just doing it the hard way [laughs].

You'll get there eventually with the words, and, in their mind, they're visualizing it. And if you just take the shortcut and draw it, here's a diagram, here's what I'm going to do, they're like, oh, okay [laughs], and then, again, a month from now, when you're going back to say, "Well, what did we decide?" Well, just look at the picture.

KYLE: I'm just going to say, I'll take it a step further and see what you guys think about it. One thing that I've started doing is, everybody's in meetings. We're always busy. We're always, you know, kind of like Will brought up earlier, trying to get two things done at once. We're working on our machines on a task while we're in a meeting.

One thing that I've found is, if I'm not getting through somebody or we're just not communicating very well, I'll take it a step further with the picture idea. There's a screen recording in both Slack and Teams. I've just started sending a snippet of a screen recording saying, "This is what you do," or "This is what I'm thinking you're talking about." And I've been sending it to them. And it's been helpful for me. Do you guys do anything like that, or...?

WILL: Man, I'll tell you what I love to do. There's another technological innovation that is really great. Teams has transcripts of all the meetings. Just read them. Oh, man, like, I don't have to be here. I could read the transcript. I read so fast, so fast.

KYLE: It does misrepresent at times, though.

WILL: Oh sure.

KYLE: I've been misrepresented [laughs] by the transcript [laughs].

WILL: You know, honestly, I mean, like, I've never had an issue where I couldn't suss out. I mean, I have seen plenty of...I don't think I've ever seen a transcript that really got the full 100% transcription of what was actually said. But I've never had any trouble figuring out what people meant, what people actually said, right? Maybe not what they meant, but I know the words that came out of their mouth. I know the content of every sentence. And I can get an hour meeting in about two minutes if I have to read closely.

You can also just do a screen recording because storage of bits is free. It's like water. It's infinite at this point in our lives [laughter]. So, just go to the meeting and save it. If you've got to go back to it, go back to it. I mean, it's one of the very few instances...actually, no, that's a lot. I really like Teams a lot for meetings.

MIKE: Yeah, it's good at meetings.

WILL: Only.

MIKE: [laughs]

WILL: It has a chat feature, but that's just for chatting during meetings [laughter]. If you're not in the meeting, you shouldn't be using Teams chat because it's bad.

KYLE: Maybe we need to sell it this way at a certain company [laughter].

WILL: There's just a lot of people...well, there's a lot of people who the chat record it isn't meaningful in that way in that they communicate via meetings and sort of, like, Jira and Confluence and, like, these sort of, like, text document things. That's what they do, and that's how they communicate. And the asynchronous chat thread of communication doesn't exist for them. That's not how they do their jobs.

And so, like, Teams, absolute, utter wholesale unsuitability for that task is transparent to them. It just doesn't make any sense. But I am living in the horrors of Teams taking over for Slack, and indescribably bad.

MIKE: They are different tools for different jobs. That's how I think about it.

WILL: It's true. But, like, you know, because, like, well, but I've got Teams chat for free, so I'm not paying for this other chunk. Because communication between development teams is very, very, very expensive, and 20% efficiency would pay for Slack a hundred times over.

MIKE: So, use the right tool. It does help. So, somebody mentioned the W's: what, where, when, why, who, how? I'm going to say six. I'm going to throw how in there. If you want to get something done and you don't answer all those questions, it's probably not going to get done.

DAVE: Or not done right.

MIKE: Exactly. So, if you're going to make a decision, what are we going to do? Where will it be done? Where in the code? Where, you know, whatever the context is there. When will it be done? When does this need to be done by? Why are we going to do it? So, we can compare it later. Who is going to do it, and how are they going to do it?

And I think you can just go through the list every time, and you get to the end of your meeting. So, what have we decided? And that's another thing. You get to the end of a meeting, if you haven't written it down, like we've talked about, you haven't made a decision. But if you can say all of those things, and some of those are probably more important than others, definitely who, when, what, if you haven't answered those --

DAVE: Why.

MIKE: Yeah, why.

DAVE: The why is real important. There's a thing that I've said a lot, which is I hate it when I open up a Jira ticket, and it says, "Click to add a description." And, you know, the title is, you know, like, upgrade this gem to, you know, version dot 5, or something like that. Okay, fine. So, I go off, and I do that. But the ticket doesn't say why we're upgrading it, which is, well, it's so that our Axios connection can run in double latency. Really? Because we cut the contract with Axios two years ago. Are we really still working on...right?

And we never wrote down why we needed it. And you can go a year, and you can pull up that ticket, and if the why is on there, you can still see that the why is still correct. And that makes it so that a year now, if you need to relitigate that decision, you have the information to do so. You don't have to call another meeting and start over at ground zero, or worse, go implement it and waste two weeks.

KYLE: Right. It's funny that you say that, just because while we're having this conversation, I'm like, do we need a template in Jira for this? Because this would solve so many issues.

MIKE: [laughs] There's templates in GitHub for pull requests.

KYLE: Oh, man.

MIKE: Fantastic [chuckles]. Because they get people to fill in those, you know, they fill in all the boxes, and you get the thing. So, what's your testing instructions? Why are we doing this? What ticket led you to do this? It goes a long way.

DAVE: A few months ago, I started getting PRs from co-workers that were just lush. They're, like, I did this, and I moved it over here, and I did this, this, this, and this, and I kept these modules over here, which relate to these things. They were using Copilot to write their PRs. And say what you want about AI, but I like my co-workers more now.

MIKE: [laughs]

DAVE: They're better people [laughter]. I don't have to do nearly as much code forensics when they hand me a PR because, like, the reasoning. And, of course, the AI gets one wrong every so often, and, you know, that gets kind of fun. But, yeah, the value in just saying, I did this, and I did this, and I did it this way to follow this, you know. And I did it because of this rule or this reason just gets so good.

JORDAN: In my case, seeing the more verbose descriptions of things, I can learn so much more about, like, why people did things. Because, like, I don't know, to you guys, you, like, have multiple options, maybe, of, like, oh, we can use this, or we can use this. But, in my case, I'm, like, I have no idea, like, what we're doing.

And if you give me, like, just an idea of one, like, I don't know, framework or technology, I can, like, kind of grasp the other ones. But, like, if it's just, I don't know, on a PR with, like, a thousand additions and no description, I'm like, I don't know what this is achieving. And this is, like, how am I supposed to, like, update one part of this when I have no idea, like, what any of this means? So, I really appreciate, like, when, I don't know, a year or two ago, some developer gave testing instructions so I can recreate it, and, like, descriptions of why so I can look back and understand.

DAVE: Fantastic. Most of our team is using Copilot, and I've been playing around with Claude, Claude Code. And I discovered output mode the other day, which any junior programmers, please open up Claude Code and type slash output mode, and it will give you three options. There's normal mode, which is what most of us use. There's also learning mode, which is, or no, sorry, explanatory mode, and that's where it will say, oh, okay, you want to do this migration. Well, first, we're going to run this generator, and da-da-da-da, and then it does it.

But there's also learning mode, which is where it's like, okay, so you want to add this new parameter. The first thing you need to do is go out and create this on this controller, and then we need to open it on the param so that it gets passed through from the view form. Open the file, and create that method now. I'm like, you're actually going to make a human type? Our AI taskmasters are already here, and they're beautiful. Love it.

I think I've mentioned this. I've been using AI stuff at home to work on projects that I have no business...I have no subject matter expertise to work on them. And having an AI do the...come, let me explain to you all the parts you do not know. Ah, so good.

MIKE: I'm going to call one more thing out. Like I said, I worked on this list, so we can talk about these things. One more thing before we talk a little about what happens when it's already failed.

So, the last thing I want to say is you reinforce, and you follow up. You said something once, maybe they heard it [laughs]. You say something twice, better chance. If people know that they're going to hear it again, even if they don't know, and then they hear it again, then they've heard it much more. I've read people talk about public speaking. You need to say the same thing over and over again. If you actually want people to hear it, understand it, you have to repeat it. And that's not trying to be condescending; it's just human nature. Reinforcement makes it stick.

DAVE: I was trained on the triple mantra of tell them what you're going to tell them, then tell them what you told them.

MIKE: It works.

KYLE: I might take it one step further and go into something else that you've brought up, which is write it down. As the receiver, I've found it to be great when either I get a Slack message after a meeting or an email that has it written down. Yeah, I heard it three times. I acknowledged it, but I also have it written down, and I can reference it later.

MIKE: Yeah, absolutely. I get that. There's a delivery manager who's been using AI to summarize every meeting that he's in and then publishes that. So, anybody who wasn't there gets it. I read it every time [laughs], even if I was in the meeting.

KYLE: That's cool.

MIKE: Yeah, it's awesome. I can go back and say, oh, this is what we talked about. This is why version 4.3 didn't go out on time, and why this is when we're going to release 4.3.1, and here's why. It's amazing. I'm like Will. I read much faster than I listen, and I tend to understand better anyway when I do. I love that.

KYLE: That makes me think of the Slack recap feature. Have you used that at all?

MIKE: I have.

KYLE: And it catches you up on the chat channels that you may not have been watching.

MIKE: Mm-hmm.

WILL: I think it's another source of miscommunication. This is a thing that...I had a buddy who talked about people who were working with him, and he was having trouble with one of his devs. He was a little...good dev, maybe a little spectrum-y, not like us, you know, we don't know any people like that. But he was having a really hard time, like, where sort of, like, the dev would be like, "I communicated all of this stuff in the Slack thread with all the developers, and we broke it all down, and it's right there in the thread," and he was right.

But the situation that my buddy needed to express was that you have to put the digest where leadership can read it, right? Like, people who are managing a dozen different teams, a dozen different deliverables, like, make it easy for them.

Just like you're making it easy for developers to help you with their module, make it easy for your boss or your boss's boss who is directly responsible and cares quite a lot about your work and how it's going, but only has maybe, like, 3% or 4% of their total attention span that they could devote to your particular problem. Meet them where they are, right?

Like, if people...like, where I'm working now, right? Like if it ain't in Jira, it didn't happen. So, when I have updates, status reports, updates, comments, questions, like, boom, boom, boom, it goes into a Jira ticket. And so, when people are looking at Jira, they can see exactly where it is, and that's where they're going, so that's where I'm communicating.

And it just makes it easy so that, like, whoever is consuming your status reports, you're going to them, right? Not, like, oh, it's here in this, you know, this obscure Slack channel. Like just, honestly, to some degree, you've got a good boss. They'll tell you, and maybe remind you a couple of times until you get with the program. If you have a bad boss, they'll just be, like, "Where is it?" You know, and then you have to have that conversation, but, like, figure it out. Figure out how they want their news and meet them there. It's your job, you know? Maybe it's not your job, your responsibility [chuckles].

MIKE: Well, I think that's actually a perfect pivot to thinking about...so, miscommunication has happened. What do you do about it [chuckles]? And you're talking about what are the root causes here, why it went wrong.

As I was thinking about this, bugs in our communication, they're like bugs in our code. Stuff goes wrong. And it's going to happen. I don't care how good you are. You're going to have bugs in production. And, likewise, we're going to have failures in communication. We should do all the things we've been talking about to try to fix them up front, right, to try to avoid them. But they're going to happen anyway. We're still going to have miscommunication.

So, when you find one...we're pretty good as engineers at going and solving problems, right? Identifying problems. But we don't always apply those problem-solving skills to stuff outside of the code, but we can. And somebody is going to come up to you. So, this scenario is going to come up. Somebody is going to come up to you, and they're going to say, "This bad thing happened to me. What do you do [chuckles]?"

And I think that there is a series of steps. First thing, I'm going to say one thing up front. You acknowledge. Because even if they are wrong and they got the wrong message, their experience is not wrong. Like, they just lived through that. And you should say, I'm sorry. You just went through that.

WILL: I'm going to push back. I'm actually going to push back, and I'll tell you why. I'll give you a Mike story, but it will be fast. I am right now in the process of teaching my six-year-old math, right? And he's a natural reader, not a natural mathematician. Math is a little abstract, a little bit frustrating. He gets really, really frustrated with the problem.

It's the first thing that I have to tell him. It has nothing to do with math. It's about emotional regulation. And you can't feel strong emotions and think creatively in terms of problem-solving. You can't do it. Your brain has one gear. And you're feeling your feelings, or you're thinking about your problem. And when something goes wrong, and it's going to go wrong, it's going to feel bad. You will feel bad. And you need to put that away because maybe it was your fault, or maybe it was their fault, or maybe it was some other random person's fault. But none of that matters until the problem is solved.

And once the problem is solved, you're probably going to feel better anyway. But, like, you absolutely have to know that this emotion is coming for you and address it. You need to see it coming, and you need to catch it, and you need to crush it so that you can do anything. Like, that is job one, and, like, you've got to be ready for it.

MIKE: That's okay. Going back to the violent agreement, you're saying the same thing. If you don't acknowledge, if you don't acknowledge they're having an experience and just pretend it doesn't exist, you're just going to go down a...you're never going to get better.

So, I see the same things when I'm working with my kids at math. If they get into that emotional cul-de-sac, there's not going to be any progress at all [chuckles]. You've got to deal with that. You've got to fix that first. One thing I've found...we've got a little trampoline in the living room [chuckles], one of those little just exercise trampolines. I'll say, just go jump on the trampoline for a few minutes. Stop doing school, and clear your head. And they'll do that, and they'll say, "Oh, I'm feeling better." "Okay, great. Come over. Let me help you." So, there's no, like, go to the trampoline of shame.

It's, "Hey, I can see that you're in a bad spot. Why don't you go do something else?" And they say, "I don't want to jump on the trampoline." I say, "What do you want to do?" And they'll say, "I want to do some deep breathing." "Okay, sure. Great, do that," and then come back, and we will work on it. Because if you don't address the fact that they are experiencing this emotional reaction, yeah, you can't go forward.

WILL: I mean, it's a tremendous source of miscommunication where we, I don't know, engineers, like, I don't know, man. I have a black belt in engineer jiu-jitsu at this point in my career, like, getting people to...I don't want to say, like, take accountability for, right, but, like, engage with the problem that, you know, it intersects with their work on some level, and it might not be their fault.

I don't really care whose fault it is, but I want you to engage with this thing and be like, I'm crawling up your leg, you know, for some reason. It intersects with your work in some capacity, you know what I mean? And maybe it's not you, but I just want you to engage with this thing that is happening that I'm trying to find a solution to, you know?

And one big part of that is, like, you know what I mean, like, be really non-confrontational in terms of, like, getting that engagement and not setting people off, you know what I mean? Because, like, if I'm receiving, I don't know, I'm going to call it feedback, right, but, like, you know what I mean, like, there's communication, like, something went wrong, right?

Yeah, like, me, I have an obligation to, like, accept and anticipate that negative emotional reaction and suppress it so that I can engage. But, I mean, like, if I'm also, like, if I'm pitching, right, that at you, like, I need to be really, really aware, and cognizant, and empathetic, and, like, not set people off because, like, the same thing, you know what I mean?

Like, you've got to be aware of that emotional context, and you have to address it. That has to be the foremost thing in your mind because, otherwise, you're just being sloppy. It's just sloppy, lazy work in communication, if that's not in the forefront of your thinking and your communicating, you know? [inaudible 55:22]

MIKE: So, acknowledge [inaudible 55:23] happen. Yeah, yeah. No, I think that's what we're doing here. We're having a discussion. And then, you know, root cause [chuckles]. What's going on here? If you get into who is to blame, just like you do a root cause analysis in an incident, it goes nowhere fast [chuckles]. If you say what went wrong in this communication, well, that's a whole different question, right? How did this communication fail? Go for a root cause.

You find whatever is going on in your mode of communication that is failing, and you do something about it. That is a very different approach than figuring out who we need to throw shame at [chuckles].

And you say, you know, don't go being confrontational. That doesn't generally help anybody. If you go in there and say, "I'm trying to solve a problem, and what's the root cause here? How can we work on this together?" And, you know, that makes all of our lives easier. It's a different conversation. And if we go on that bug hunt, right? Let's go and try to solve this. It makes everybody's lives better.

WILL: Absolutely. I mean, like, I mean, the conversation is always about, like, what happened, right? What happened? What do we do about it? I mean, really, that's the only conversation that's worth having. You know, what happened, and what do we do about it? I mean, I wish, you know, it's just a frustration that I have with people, you know, because it's something that I think you'll see a lot. You'll see it over and over and over and over again. And I just wish I could get it into people's heads.

I've come out smelling like a rose just because, like, I was a stand-up guy cleaning up my own messes. This was all my fault, like, completely my fault, 100%. Like, I blew it in, like, a transparently stupid way and made a giant mess for everybody to clean up. Probably, you know, I don't want to put a figure on it because, like, I don't want that on the record [laughter]. But, like, probably a number, and it's probably a big one.

And just because, like, I was a stand-up guy and I'm like, okay, let's get this thing going, and everybody was just like, "Will, you're great. You're a rock star." And I'm like, no, no, I made a giant screw up, and I wrecked your whole day. I made a giant screw-up, and I wrecked your whole day, and I just took accountability for it [laughter].

You can be dumb, and you can be mean, but you can't be both. So, just pick one or the other. It was my day to be...And if it's your day to be dumb, you don't know it [laughter].

DAVE: I like that. I like that. The version I heard of that was if you drive to work and you don't know who the idiot is, it was you. If you sit down and play poker and you don't know who the sucker is, it's you.

Yeah, that's actually a good thing. We've touched on that a little bit is, like, understanding what impaired judgment feels like. Because the first thing that impaired judgment feels like is numb. Like, you don't feel it when your impairment is just...is impaired, when your impairment is justified. Wait, what? Is judged. When your judgment is impaired, you don't feel it.

One of the things that I do for that is I build unit tests. I have little static activities that I've just done over and over, little routines. And if I'm not feeling great that day, I struggle. And if I'm doing fantastic, then I crush it. And that kind of informs, what kind of work do I want to...Maybe I just need to back off and take some methodical rows. Or, no, if today's the day we cut that big spike, let's do it.

WILL: Oh, man. That's an indulgence I don't feel like I usually get, like, what is it? What's it going to be today? Like, well, I guess it's going to be [laughter] a hot one today. It's like my workload's like the weather, you know. It's just like, it's raining today, baby. Sorry [laughs].

DAVE: Yeah, that's...Honestly, I push on the team, on my team, the favorite Agile system I ever used was Tracker just because there's only one place for a task. There's only two tasks in the system, the one you're currently working on and the one at the top of the backlog.

And when you move your task into delivered, the only task you can take is the one at the top of the backlog. They were pretty draconian about, like, XP. Everyone is a subject matter expert. If you get the ticket and you can't work it, well, you're going to have to pair program with somebody who does. And after six months, everybody knows it.

WILL: Oh man is it --

DAVE: Kind of an aside, but yeah. But, yeah, like, gauging your mental acuity, yeah, that's useful when you have an assortment, when you have a smorgasbord of things to work on. And, on those days, it's like half of being smart is knowing what you're dumb at, and the other half of being smart is not trying to take on the world with your dumb.

MIKE: Well, and it does let you, you know, even if you've got the same workload, if you know that your communication is not going to be great, you can be up front and say, "Yeah, I have a cold today or," you know, whatever it is. You might need to repeat that to me twice. I'm going to work on it. I'm here. But I'm going to need to hear that again. And people are generally very willing when you're open, like you were saying, Will. You know, when you're transparent, my experience is that people generally engage.

So, we've talked about a lot of tactics at both, you know, pre, you know, we talked about shifting left in software development. You want to solve them as early up the chain as possible. We want to do everything we can to prevent the miscommunication in the first place. Some of them are still going to make it to production. We've talked about how to deal with the ones that do. It was interesting, emotional regulation has a lot to do with what came after. Anything else that...any final things we want to cover before we break?

WILL: Ah...go ahead.

DAVE: I would just say the quote by Northcote Parkinson. He's the guy that says work expands to take all the time allotted for it. He's got another really good one, which is, the void created by the failure to communicate is soon filled with poison, misrepresentation, and drivel.

MIKE: Oh.

DAVE: I like that. There was a time in my career when I thought being silent was neutral, and it was just a zero. No points won, no points lost. There is, you grow, or you die. If you're not communicating, you are withering in people's minds.

MIKE: Will, you [inaudible 01:02:07]

WILL: No, no, no. I can't do anything with that [laughter]. Like, you know, I think when somebody makes a good point, and, like, the meeting's over, you say like, yeah, that's it.

DAVE: Nice.

MIKE: That's a great ending.

WILL: Let's end it. Let's wrap this one up. We'll do what Dave said.

MIKE: Let's ship it [laughter]. Until next time on the Acima Development Podcast.

On this episode of the Acima Development podcast, the crew leans into a Halloween “code horror” theme, using real-world stories to explore the scariest things they’ve seen in software. Mike opens with a literal horror from homeownership: a drain pipe so clogged with roots it had become a pipe-shaped root sculpture, a perfect metaphor for an ancient 3,000+ line Rails controller crammed with overlapping workflows, unclear entry points, and so much tangled logic that a junior engineer couldn’t ship a single change in months. That sets the stage for an episode about legacy systems, complexity, and the way neglected codebases slowly turn into haunted houses you’re afraid to enter.

From there, the hosts trade progressively more terrifying war stories from their careers. Dave recalls a nightmare installer project where he had to write Pascal inside InstallShield to find and kill a running Rails process on Windows using SQL against the process table—an absurdly convoluted solution that nevertheless shipped and worked. Justin shares high-stakes fintech deployments where downtime cost millions per minute, quarterly release windows created brutal pressure, and failed rollouts meant rolling back three months of work. Kyle talks about discovering hard-coded secrets and shared keys scattered across repos, unrotated for years, then being told to fix and rotate them all “by end of day” with almost no historical context. Mike adds tales of a reporting system literally built on SQL injection, “fixed” by an enormous hand-rolled SQL builder that was later thrown away, and a credit card gateway acquisition where an injection flaw had already been exploited to steal over a million dollars.

The horror then zooms out to systemic and operational failures: clickstream data sold by ad blockers that can easily de-anonymize users, HIPAA-reportable incidents that nearly trigger federal oversight, and outsourcing critical code to poorly vetted contractors only to see entire codebases appear on the dark web. They dig into how floating point differences between systems can change financial reports by a few dollars, how time zones and users changing their device clocks can break “simple” expiry logic, and how massive vulnerability scans can surface tens of thousands of “critical” issues across hundreds of repos. Add in AWS us-east-1 outages that turn disaster recovery plans into live-fire drills, layoffs that leave one engineer alone with a mysterious legacy system, and useless commit messages like “test” repeated 50 times, and you get a grim but funny campfire circle for engineers. They close by emphasizing the real moral behind the scares: every one of these stories carries a lesson about security, architecture, and process, so listeners can learn from others’ hot-stove moments instead of burning themselves the same way.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, I have Justin, Dave.

DAVE: Save yourselves.

MIKE: And Kyle. And --

DAVE: I just realized this is not going to come out on Halloween.

MIKE: [inaudible 00:37]

DAVE: We are recording this on Halloween.

MIKE: Exactly [laughter]. Well, that's what I was about to say.

DAVE: Oh, sorry.

MIKE: You're going to probably hear this in January, but we're recording this on Halloween [chuckles], Halloween of 2025, and so we're in a spooky mood [chuckles] with the Halloween theme. We're going to run with that, and, as usual, I wanted to connect this at least a little bit to something tangible.

And what I was thinking of is, a couple of weeks ago, I was cleaning out a drain pipe. So, I've got a downspout from my house, and it goes into a perforated drain pipe that runs out to the edge...well, near the edge of the yard. So, when it rains, the water goes out near the edge of the yard rather than going down next to the house and going to the foundation.

The problem is water was not going down the pipe, and [chuckles] that wasn't good. We tried to figure out why and noticed every time it rains, water is coming out the top of the pipe...at the bottom of the downspout rather than going up the other end.

So, we ran a pipe snake up the end of the pipe, thought, okay, there's probably something in there, and gave it several tries. But one of the times I pulled, like, wow, that's really stuck in there, and I pulled it out. And I pulled out, like, a several-foot-long length of root that had fine roots shaped around the inside of a perforated pipe. It was [laughter] a very interesting pipe-shaped root. Oh, that's interesting, kind of creepy looking actually [chuckles].

This strange thing reminded me of an image I saw of some blood that somebody [inaudible 02:08] from a lung, you know, this very twisted intricate thing. And that still didn't even begin to get all the roots out of it. We were, like, oh, you know what, this is not going to work. Eventually, I just tore out the whole thing, threw it away, and replaced it with a new one because it was not going to work because that tangle of roots apparently had not been cared for for a long time.

Where it had been, we'd had a bush, a weigela bush, that had grown unreasonably large for its location. Why did it grow so well in that spot? The light's not very good. It's very dry. Well, now I know why it had done so well [chuckles]. It had filled that pipe with roots. And the bush isn't even there anymore, but apparently it left the roots behind, and it's gradually, like, silted in and was just totally clogged. Water was not going through.

I guess when you leave something to get tangled for that long, eventually, you end up with just this spaghetti that won't allow anything to be accomplished through that pipe. Not serving purpose anymore. Which leads me to an example [laughs].

Some years back, I was doing Ruby on Rails, and we had a Rails controller, and I don't remember the exact length, but I remember it was over 3,000 lines long in a single file. And there were multiple competing workflows all implemented in the single Rails controller. It just kind of did everything in that general area of the code. And, like I said, there are multiple competing ones. I think they're both still active depending on, like, what version. I don't even remember what exactly...how you got in one or the other.

And, you know, you’d go into the one and, in the frontend, it would send you to another. And you had to know the details of the template to know how which action got called in the controller because of course it had, like, a hundred methods. It wasn't clear at all which ones should be public, which ones shouldn't be public. I put a junior engineer on that once to try to accomplish something. After a couple of months, they hadn't got a single PR out, and, finally, we just gave up and had them work on something else.

JUSTIN: I've done that [laughs].

MIKE: I regretted sending them in there, into that dark cave, entangled and twisted, which is our introduction for our theme today. As we've already said, we're going to talk about the horrors that we have seen in code. And we've got some people who've been around for a while [laughs] and have seen some things. I started with my story, but, hopefully, I think we've got enough collective experience there to see all kinds of things that will scare you. So, what are some scary things that you all have seen in code? I've got a list, but I'll just sprinkle them in as we go.

DAVE: I think a lot of these they can go in interesting ways, right? For me, the most horrifying code stories aren't the ones where you go in and you find a mess that somebody else made, you know, some cavalier cowboy, I mean, those don't scare me. They just make me mad [laughs]. The code that makes me just shake my head in wonder is often code that succeeds, code that actually works.

So, I will tell a quick story. My story for this is my very first Rails programming job. I wanted to be a Rails programmer. I was doing a ton of PHP, which I hated. I was doing Perl and Python on the side. And I was getting into Ruby. I really liked Rails. And a guy called me up and said, "Hey, do you want to da da da...?" I'm, like, "I mean, if I can work in Rails, if can do it in Ruby, I will." And he's, like, "Sure".

So, he puts me on a project. It's a Windows .exe file. So, you have to install it with Windows with install.exe. And we wrap up the Rails OCI. That was the one-click installer. This was an .exe file that you could run way back when. And it would give you Ruby and Rails and everything you needed to run a Ruby on Rails site on Windows. This is, like, 2007 era. So, I mean, this is actually significant, right? I mean, this is...we're playing games with, you know, like, Tomcat Manager and all that good stuff, and this one didn't use Tomcat; I think it used Postgres. But you get the idea that it was managing the whole stack.

And I got given the job of updating the installer to chain either to add a gem...I think we wanted to change the Rails version. And the project was new enough－it had been out for a year or two－that we had never upgraded Rails. So, [vocalization] how hard can it be? I'm programming in Rails.

So, I will skip a long involved, headachy story. But what I ended up with was the installer is written using InstallShield. InstallShield is written in Delphi, which is Pascal. So, I wrote a Pascal program to go into this installer. That Pascal program then, when you run the installer...by the way, sorry, I left out the most important detail, which is when you run the reinstaller, it will fail if Rails.exe is already running. So, I have to go look for it and tell it to shut down. It's just, like, I'm going to, you know, click here to kill the Rails process and restart, right? That kind of thing. So, that's what I have to do.

And on Linux, you just PS and grep the table. On Windows, there's a thing called the system process table. This is 20 years ago, so I may have the names on these wrong. But it's a table, and you query it using a COM native call. So, I wrote that in Pascal. It goes out, talks to the system process table, and sends it a SQL query.

So, now I'm using Pascal to write SQL to query the process table. I find Rails; I shut it down. I'm able to do that with an API call from inside Delphi. And at long last, I finally get a piece of code, and I change a version number, save it, install it, wrap it up, test it, ship it. It works. It's horrible.

If you are using InstallShield right now today in 2025, I would not bet any amount of money that they have moved off of Delphi. I would not be surprised at all to find out that Pascal is still going strong.

MIKE: It's one way to write a Rails app.

DAVE: Mm-hmm. Mm-hmm.

JUSTIN: [laughs] So, I've got a scary story. And this was...I don't know if it is so much a scary, but it was, like, you know, I worked for a large fintech company, and the downtime was measured in millions of dollars per minute. So, we had a window of once every quarter where we would do our install. And the install would start at around 11 o'clock p.m., and it had to be wrapped up by 4:00 a.m. And so, you had one chance per quarter that was scheduled to do the install. And right around 3 o'clock, everybody starts to feel really nervous because things aren't going well.

And, you know, you're doing installs on different servers and in different locations and testing and everything. And 3:00 o'clock rolls around, things aren't going well, 3:30 rolls around. And the guy in charge is, like, "You really want to go forward with it because it represents three months of your life." But they're, like, "Sorry, guys, we're pulling the plug. Roll back." And then that just messes up a lot of schedules and everything else, and you have to do everything.

But it's, like, you know, you go in there, and you worry about it, and you don't even need to drink any caffeine that night because you're just so much on the edge, so...[laughs]

MIKE: And that could compound because now your next quarter deployment is going to have everything from that one plus everything from the next three months. And so, it's going to be twice as likely to fail.

JUSTIN: Yeah.

MIKE: Oh [laughter], that's not a good experience.

JUSTIN: No I --.

DAVE: Spooky. That was a good spooky story [laughter].

JUSTIN: You can feel that the palm is sweating right now.

MIKE: Oh, man. So, we've taken turns so far. Kyle, what do you got?

KYLE: I've got one that all of us might appreciate. That's when you've had a security incident at your company, and you start going through the repos for your codebase, and you find hard-coded keys and secrets. That can be scary, especially when you're finding keys that are shared across several services by, you know, several repos. And they're hard-coded in each repo, and they haven't been rotated in years. That's one that I've experienced and one that was scary to me.

JUSTIN: And you're, like, I have no idea how to rotate these or where the original keys came from or --[laughs]

KYLE: Yeah, no, and there's always a deadline, right? Get these rotated by end of day. And you have no idea the historical context behind them, who put them there, why they're there, and where they're stored to even be rotated. Like, the context, you're flying blind a lot of the time in these things, right? You don't know who it's associated with, what role, what access. It's, yeah --

DAVE: That’s awful.

JUSTIN: Ah, good times [laughs].

MIKE: So, a lot of security-oriented items here. I've got a few of those. I've got one that I think I've shared before, so maybe I won't...well, I'll maybe mention in passing. But I worked on a reporting system. I came in on it, right? I kind of came into an app, like, so I see you have some reporting. How is that done? And the entire system was completely reliant on SQL injection. That was its fundamental mechanism of operation.

It would get snippets of SQL from the frontend. They would be sent to the backend and just sent verbatim down into the database. Go for it. Here's how you get your reports [laughs]. And it had been running that way for years. And they’re like, yeah, that's how we do it.

And the funny thing is, I decided to do something about it. And the engineer who decided to do something about it came up with a solution. So, I've got to be careful here. The person who did this came up with a solution that worked and that met the constraints of the problem, which was fix it inside the code, and so that's what they did. They fixed it inside the code. And to solve it, they wrote their own SQL builder, which had dozens of files, which could have been its own massive project anywhere else [laughs], and took, I think, a couple of months to build and then connect to all the reports.

And I was given the review when that went out. And it went out in a single pull request that had about 100,000 lines, if I remember correctly [laughs]. And it took me multiple days just to scan through the code to just try to maybe catch anything. Like, you know what? I guess it's good [laughs]. So, I don't know if the cure was better than the disease.

One thing I learned from this, because, again, it was a brilliant solution in that it worked. It just, you know, the problem with that is our data was growing so quickly. So, within a year or two, we couldn't run reports against that database because you shouldn't be running reports against your production database because it doesn't work. And so, all of that work was thrown away within a year or two because [chuckles] there's no way it could possibly work because you're querying the wrong database. But there's a moral to this story. Do not build a reporting system on your production database [chuckles].

DAVE: I mean, that used to be a best practice, though, right?

MIKE: Sure.

DAVE: I mean, like, 20 years ago, hard drives were expensive, and RAM was worse. But, yeah, more and more, the data team keeps coming back and saying, "Stop being so scotch with memory and storage, and stop making us do so much compute because that hurts us."

MIKE: Well, and there are systems. It's a solved problem today. Reporting, go with your vendor. They can give you some pretty reports. You're good. And that way, you're not trashing your production database by throwing these huge queries at it that it's not designed for. And you'll be much happier.

Again, I've seen...so, I said I'd mention one because I think I've mentioned it before. Another project that was handed to me [laughs] I was working at a company where they acquired...I don't know if it's quite the right word. They took over a company going bankrupt or failing. They had, like, one engineer left, and he was about to quit because they weren't paying him. And it was a credit card processing gateway, not the kind of company you want to be underfunded.

And, like, okay, and we kind of figured it out, figured out what was going on, and I got the lay of land. Turns out that before they handed it to us, without us knowing, maybe them not knowing...they probably had no idea because they weren't even looking at it.

They had left a SQL injection flaw in the code, and it had been exploited. And by the time we discovered it, over a million dollars had been stolen from their customers.

DAVE: Wow.

MIKE: It didn't go over really well. I did not go over very well at all. That was not the best acquisition I've taken part in. Also, it has led me to be very sensitive about injections [laughs] in the code.

DAVE: It's one of those meetings you start by going in and saying, "Okay, guys, this message is going to make you want to shoot the messenger and everybody else in the room, but I'm the messenger, and don't shoot."

MIKE: And I believe that I was the one who found the flaw after we knew that there was a problem. It didn't take me that long to find it, actually, because I knew what to look for. This was in VBScript, you know, old ASP [chuckles], way back in the day, and just sanitizing your parameters wasn't always a thing, you know, it was kind of opt-in. There’s another spooky one.

DAVE: That brings back memories.

MIKE: Yeah. We're kind of going around the table here. Dave, I think you're next up.

DAVE: I don't know if I told the Toyota story here. I told it so many times on Rogues that Josh would roll his eyes, and here we go again, every time I'd tell it over there. I think I’ve told it here.

MIKE: [inaudible 16:39] rolled his eyes [inaudible 16:39] the vehicle.

DAVE: [inaudible 16:41] the vehicle. Yeah, exactly. That was where the bug report began with, "Fortunately, no one was killed, but..." Actually, I have a better one. This one was genuinely terrifying.

In 2016, I went to DEF CON. I took some time off work. And so, I wanted to go to DEF CON forever. It's a security conference in Las Vegas. I wanted to go forever. I went down there, had a great time, got scared to death in one talk because they start going through how AdBlock is selling everyone up the river. And they claim to be anonymizing your data. So, their talk was this is how much of a click stream we need from you to de-anonymize you, and they put up, like, five links.

On Twitter, if you visit your profile page, you cannot visit the profile page unless you are that user. So, if you visit a user, like, the profile settings, the edit profile, if you are on user/settings, we know who you are at that point. You’ve just told us your username, that sort of thing.

And the moral of this story is, even if you are on HTTPS, the URL that you send and the query string that is attached to it is in the clear. And AdBlock and all these other people...the reason you have AdBlock on your computer for free is because they're selling our click streams. And if you've got $100,000, which is what they were about to use for their experiment, they're like, well, let's try it out, you know, let us try it out.

For a hundred grand, you can buy a database that is accurate to the click stream of everybody that has AdBlock Plus installed, and it's in near real time. I mean, we're talking seconds from you clicking on a link to people around the world knowing that you clicked on that link.

I came back to work and panicked because I'm like, "Guys, we are sending this information over a query string. There's this piece of data right here. It's in the clear." And I'm going to stop telling the results of that story at this point. But the end result is, if you get more than 400 records exploited, the HIPAA laws means you have to voluntarily submit yourself to this very angry...nah, nah, nah angry is not the word, very strict government body for deploying your code. Imagine having to go to a federal regulator and ask for permission to deploy your software every single time.

MIKE: Oh boy.

DAVE: Right? If you're on the OCI, the Office of One Click Installers...

MIKE: [chuckles]

DAVE: The Office of Civil something. Anyway, it’s civil rights, OCR, there we go, Office of Civil Rights. If you have a HIPAA violation, they get involved. And we managed to keep that number under 400, but there were a lot of sleepless nights.

MIKE: Scary [laughs].

DAVE: Very.

MIKE: Justin, I think you're up next.

JUSTIN: Yeah, my next scary story is not so much in code. It's more of a situation, another fintech firm. This one, a bright-eyed and bushy-tailed MBA came in as a director and thought of ways to save money. And they were like, "Oh, we'll save money. We've got to do these projects, but we're going to save money by contracting out the work to China."

Now, this was back in the mid-2000s, or something like that, and so China wasn't quite as belligerent. But the thing about it was that they kept on not being successful with any actual work being done there. And then they got alerted, like, our department got alerted because the entire codebase got published on the dark web. And they think that they tracked it down to some of those Chinese contractors.

And it was just like, you know, that money that they saved, some incremental amount, by contracting out this very important source code, was that any savings was totally obliterated by this situation that they now found themselves in. So, yeah, moral of the story, really, really examine who you are contracting out your source code. You know, the most important thing to your company, the thing that makes you money, be very careful who you send that to.

MIKE: Kind of like putting your crown jewels in a room with no security camera, and easy access from the street in Paris.

DAVE: Yeah. Or letting AI look at your codebase. Oh, did I say that out loud? [laughter]

JUSTIN: And one result of that that was really frustrating for the rest of us is everybody lost their individual laptops. We had to log on to VDIs from then on. And back then, VDIs, you think they suck now? They really sucked back then [laughter]. So, it was like, you know, it was a bad experience.

MIKE: Kyle.

KYLE: The one that I had to deal with a while back was, I don't know if this falls into scary as much as it falls into the frustrating that Dave here brought up, but I had a coworker that left the company and had recently migrated a project from one version to the next. And I was tasked with debugging and getting the service up and running.

Now, my breadcrumb of trails was about 50 commits to the repo with either test or other commit messages, which were not very useful but most of them being test. And I had to go into each commit message individually to figure out how we got from step one to step two while we were making this transition from one version to another, to be able to backtrack the decision that was made because I couldn't just go and talk to him about what had been done. But yeah, that's my scary story, is commit messages that are next to useless, and many of them.

MIKE: And I'm guessing they didn't rebase before merging, so...[chuckles]

KYLE: No.

MIKE: No order.

KYLE: No, no.

MIKE: [laughs] Oh, I think that makes it my turn. Which one should I do next? I've got a couple of them. You mentioned the one about China, Justin.

I did once run into a situation where there was a contractor that didn't generally show their face on camera very much, which was interesting. But it turned out that they had been subcontracting out their work to a number of other engineers overseas. So, the person we were working with was actually an unknown number of people who were all working as a collective overseas for the supposedly onshore engineer [chuckles]. And we found out about that one because of the code being leaked on the dark web, not a great thing [chuckles]. One of the subcontractors thought that they'd get a little greedy and make some more money in another way [chuckles]. It didn't work out so well [chuckles].

Another one I was thinking of is...so maybe this is enough. I can put three letters together that will make everybody shudder: P-H-P [laughs]. Not so bad today. I guess a few people use it. Facebook still uses PHP, don't they? They wrote their own compiler, not interpreter. I think they wrote a compiler. And so, you know, they made it work.

But 20 years ago, yeah, 20 years ago, I'll say, in PHP, they had a library for connecting to MySQL, which was the popular default database at the time. And they had a standard library for connecting to it. And their standard library, by default, did not parameterize any queries. And so, the standard default behavior out of the box was to do exactly the wrong thing and have a SQL injection for every single query that you ran [chuckles]. And that was, out of the box, this tool that I think at the time was the most widely distributed web platform on the planet and eminently hackable. It was a scary time [laughter].

JUSTIN: You remember 20 years ago writing all the...I don't know if you guys are front-end engineers, but you had to write some sort of crazy nested if statements about which versions of browsers you supported and whether or not the JavaScript you were writing would actually work on those browsers.

MIKE: Oh man, that’s right.

JUSTIN: And then as time went on, you kept on having to support Internet Explorer 6.

MIKE: Internet Explorer 6. That was the one. It was Internet Explorer 6. That was everybody's bane [laughter].

JUSTIN: Oh man. All the way down was like, if Internet Explorer 6, you know, do the very most simple thing or display a message saying, you know, "Your browser is not supported. Click here to go upgrade."

MIKE: Right. Didn't even Microsoft have a funeral when they finally killed that up?

JUSTIN: [laughs] Yeah, I think so.

MIKE: I remember seeing...I remember seeing, like, they had a picture of, like, a cake with a tombstone [laughs].

DAVE: I don't know that one, but I know that when they released the Zune, they made a coffin or a casket-sized iPhone and had...or iPod and had a procession of getting rid of it. I’m like, what? It turned out to not age well.

MIKE: It didn't, no [laughter].

JUSTIN: No [laughs].

MIKE: I don’t think we even remember what the Zune is [laughs].

DAVE: Mm-hmm. Mm-hmm. Oh.

MIKE: It was brown.

DAVE: Yeah. I wrote a video game years and years ago, and Old Man Murray reviewed it. And it's an abusive review site, hilariously so. They reviewed it as this game comes in a red cartridge (This is Nintendo 64.), but it ought to be a dull brown because this game is a silicon turd. So, anything that comes in a brown package makes me giggle.

MIKE: [laughs]

DAVE: So, do you want to hear a scary story that will keep you awake tonight, because it's not solved and it cannot ever be solved? What if I told you that multiplication was not deterministic?

We're programmers. We like things to be discrete, right? X times Y should equal Z. You will run into this if...Okay, I'm going to bring it back to the sanity world, and then say floating point arithmetic. Okay, so you're already approximating.

So, the short version of the story, the reason it's not deterministic is because the standard for how you do multiplication or other...Any operation that could change the base, the size of the radix or the...Yeah, anyway, anything that affects the offset, multiplication, division, primarily, addition will only do it if it overflows the most significant digit. But multiplication almost always is capable if it's...

Anyway, you will see this in the wild if you are trying to get your customers off of Microsoft Excel and onto Google Sheets in Ruby, because Excel and Sheets round currency differently. And when we moved from Redshift to Snowflake, we ran into this. We had financial reports that were using an easily sufficient amount of floating point to come up with something honest, legal, and reasonable. When we moved to Snowflake, people's commission paychecks changed by like $5 or $6.

And I don't know if you know this, but when you're receiving money, you check the amount, and you notice when it's different. And we had people going, these reports have to...And even worse, you imported the last how many years out of Redshift? If I run this report in Snowflake on that year, I need the same answer. If I can't get the same answer, I have to keep Redshift so that I can run that year's report on Redshift. So, Zack, our data guru, he figured out how to make Snowflake multiply the same way that Redshift did.

JUSTIN: [laughs]

DAVE: And that is amazeballs. That just blows me away.

JUSTIN: So, which one was right, though? There's got to be a discrete answer here.

DAVE: They both comply with the IEEE floating point standard, and there's a great, big...I ought to frame it, actually, as, like, a horror. Like, put it next to the movie posters for Jaws and Psycho, a printout of the IEEE standard saying [laughter], "There is no deterministic way to do this."

KYLE: But isn't that a lot... Sorry, that comes down to a lot because we use base-10, right? If we switch to something like base-12, a lot of the deterministic issues that we run into end up actually being solved.

DAVE: They would come out differently, yeah.

MIKE: But not... It helps that what base-12 gives you is the ability to cleanly divide by 2 and 3, right, and some multiples of those, right? And with base-10, you get 2 and 5 instead of 2 and 3. And so, you get multiples of 2.

DAVE: Trade-offs.

MIKE: Yeah, you got multiples of 2 and multiples of 3 with your 12. But you still...if you take other prime numbers, just walk up your prime numbers, and you'll run into the same problems pretty quickly. So, hit 5 with your 12, well, now you've got the same problem, or 7, or 13, or just anything that is not divisible by your 2 or your 3. You run into it, and it's not going to divide cleanly. Now you've got repeating decimals, and you're going to have to do some rounding.

DAVE: Yeah. The short explanation of why this happens is, in floating point, you pick how many 1s and 0s, how many bits are going to be the fractional part. And if you don't pick very many, you've got a very imprecise number. If you pick way too many, you have a lot of 0s and wasted space. When you multiply 2 numbers, you've got this thing that's going to potentially double in size, bit-wise. But it has to go into the same space.

And so, the question becomes, if you multiply these 2 numbers, and you've got 12...like, say you're using 6 digits for precision, and your new number is going to have up to 12 digits of precision after the decimal point. Which one do you keep? And, you know, which direction...how many bits... when you put this number in the new target place, do you put it in the same 6-point thing, or do you change it around? And yeah.

KYLE: It makes me go back to my math class in college where our professor spent 15 minutes proving that .999 repeating constantly is actually 1, and how it converges to 1, and there's no difference even though they look different.

MIKE: That's Zeno’s paradox.

DAVE: Yeah, Archer's paradox, yeah. Fantastic.

MIKE: So, Justin --

JUSTIN: Well, I've got one more, and then I've got to take off.

MIKE: Okay.

JUSTIN: And this one's not really that scary. Well, I guess it is, I don't know. When you get a codebase with X number of repos, like, we'll call it 200 and 300 repos, and then you're like, oh, I'm an application security engineer. I’m going to go in and run my vulnerability scanner on all these codebases. And then you start it running, and you have a running total of the vulnerabilities found: criticals, highs, mediums, lows. And you come back, like, 20 minutes later, and the criticals are in the thousands or tens of thousands [laughs]. And you're like, oh my God [laughs]. What? We might as well just burn this down now [laughter].

But you look at that, and then you, like, start to categorize and such. And you're like, okay, you know, there's this many repos, but only, like, five of them are actually running in production or something like that. And so, you can cut things down quite a bit. But whenever you get that feeling of, you know, oh, my vulnerability scanner is running, and you see the total just incrementing up, and you're like, has this ever been run [laughter]?

MIKE: No, probably not [laughter].

DAVE: I hope the answer is no, because if the answer is yes, I need some violence in my life.

JUSTIN: You're like, why did the last one quit [laughter]?

KYLE: And then the scary--

DAVE: Why is this file called the last report, you know [laughter]? It's the previous three guys. It was the last thing they did here. You're next [laughter].

KYLE: And the scary part is you report that, and there's other business-critical initiatives going on to where, you know, even though it has a thousand critical alerts, we can't fix that before we go to production [laughter]. We're going out anyways.

JUSTIN: Going out anyway.

MIKE: We'll be fine [laughs].

DAVE: What could go wrong?

MIKE: Well, thank you, Justin, for joining us and contributing some stories. Kyle, do you have any more for the list?

KYLE: I've got one that's programming-adjacent and may or may not be relevant to recent news. That's, when you're an engineer, you come to the office, sit down to start your day, only to find out that we won't call us-east-1, but us-east-1 is down [laughter]. That is one of the scariest times for multiple times over my career that I have had. When you've made decisions and a lot of aging companies, we'll call them, they have picked that zone to be their zone. And it happens in other zones, too, but it's notorious for us-east-1.

You deal with a lot of backlash, a lot of failovers, and you are testing that DR strategy that you’ve tried to implement. You are now testing it live [laughter], and you are hoping for the best. And stress levels have never been higher, especially when databases are involved, so...[laughter]

MIKE: I'm going to add on that one. That's not only your systems. Because if any of the partners that you have, any of the vendors that we use for software services have anything in that availability zone and do not have the appropriate disaster recovery redundancy, then you're down. And if any of their providers have that, then you go down. You can fan out as far as you want, you know, it's not a single point of failure dx. It's an exponential point of failure --

DAVE: You can't take credit cards if your CC service is down, but it doesn't matter because your OAuth is down, too, and nobody can log in anyway.

[laughter]

MIKE: So, I'm going to say something a little bit adjacent as well, back from my bag of stories. I may have mentioned this before. But more than once, I have been on a team where everybody else got laid off [laughs]. That's a scary situation. The first time it happened to me, I was actually one of the people that got laid off. But then my boss quit because he's like, no, I'm not doing this, and they hired me back on. Maybe I should have learned some things. I've learned some things since then. I took the job back, and because he'd left, I didn't have any training whatsoever. He may have given me, like, 20 minutes, like, "Yeah, these are the things I do to keep things running. Good luck, [laughs]" and he left.

And so, I had to take this software application that had been running for years, I don't know how many years, and which I had never done the administration for, except kind of tangentially, and hope I got it right. I tell you, you learn a lot when you get put in that situation. And you also make some serious mistakes [chuckles] that you regret later. That's part of where the learning comes from, is from the things you do wrong [chuckles]. Luckily, no customer funds were lost, but customers may have been frustrated by my [chuckles] actions at that time.

DAVE: It's one of those 100 bad days gives you 100 good stories.

MIKE: Yes, absolutely [laughs]. You got any more you'd like to share, Dave?

DAVE: One tiny piece of...I don't know if hope is the right word, but the point in my career when I realized I'm not going to slay this dragon, so I just made peace with the dragon. When I was an early programmer, I had to learn how to do recursion, and recursion was...it broke my brain. And I worked at it, worked at it, and I eventually got it. As I advanced as a programmer, a little...actually, prior to this, pointers. Trying to understand how pointers worked were very, very difficult. Then, like, mid-expertise, I ran into problems with recursion and getting over that.

As a senior programmer, I went up against time zones. I thought, you got to be able to solve this [laughter]. It cannot be solved for part of the same reason that the floating point...well, a little bit, the floating point number also has this problem, which is that it backs onto humans, like, in real time, meaning that you can get every time zone locked in, and tomorrow you can find out that some jurisdiction has changed time zones. It doesn't happen very often, but it does actually happen. So, if it backs onto a human that is dynamic, it's not solvable. So, stay in UTC, kids.

MIKE: Well, I heard about a problem the other day that picking a time zone wouldn't help either. They were comparing a timestamp against the local time to see if a build had expired, and this was on a mobile device. And they kept on getting weird behavior, where people weren't reinstalling it, even though the build should have expired. Not really thinking that people on their mobile devices will regularly reset their time in order to get extra points in a game. Because there are a lot of those games that force you to wait, if you've got the free version, until you can get your reward again or, you know, be able to play again.

And so, people change their time by hours, 8 hours, 12 hours, days, all the time on their mobile app. And if you're trusting the system time, you're in big trouble.

I saw another one. There was a...another time zone story. There was a user where any time they looked at a resource that was shared with some others...I'm being ambiguous here to spare some parties. Any time they looked at the resource, everybody else got signed out, including them.

DAVE: Hmm [laughs]. It's awesome. You have to sign out REST resource? I mean, that would do it. No, that would only be one person, even if it was.

MIKE: It was a nice just get sort of standard page, look at the details. It turns out that this user's time had been gradually drifting forward for a year, and finally went over the five-minute expiration window that users had to look at this resource. And the way the code was written is it just said, "Hey, if you get a message coming back that this resource is locked, or that it's even being looked at, if you see that that five-minute time frame has expired, then sign out." And it signs everybody out because you're only supposed to have one person looking at it at a time or locking it at a time. And --

DAVE: Right. That's how read locks work. We just throw everyone out of the building, yeah.

MIKE: You throw everyone out of the building, and that's how it works. The problem is their time had gone over that five-minute window. So, if they ever looked...and this user's, like...and their job was to assist other people. They were, like, a training person. And so, any time they'd go in to help somebody with their work, everybody would get kicked out [laughs]. And so, they were poison to anything they touched.

DAVE: Was the session time cumulative, like, you only get five minutes to look at this resource in your entire life?

MIKE: No, you get the...but the lock was set the time somebody claimed it. The lock was set the time somebody claimed it. And any event, so there was a WebSocket, and any event that came back would have the timestamp on it. And so, even though it wasn't a locking event, if somebody just looked at it, they'd see, oh, somebody else has joined the chat, basically, right, and started looking at it. It'd see, oh, this has expired. Better kick everybody out.

DAVE: [chuckles] So, everybody on the system has software running on their computer saying, "Should I kill my own process?"

MIKE: That’s right. Every single person.

DAVE: That's fantastic.

MIKE: [laughs]

DAVE: That's fantastic. I love that. Oh my gosh, people are the worst. I love it.

MIKE: Because you think time, you know, everybody's on the same time. It should work, right? And it did most of the time.

DAVE: But it really doesn't. Kyle, the reason I said the time zones is like floating point is because outside of floating point, we still have this problem. Prior to the existence of computers, we had accountants. And so, there is a thing called banker's rounding. And for anybody that doesn't know, if you do a multiplication, division, you land exactly on one half, exactly on .5. In banker's rounding, you round to the even number. So, if your number is odd, you've got to round up, and if it's even, you've got to round down. And it's weirdly consistent.

And everybody does it when they're doing it in finances, and I haven't found a programming library that supports it. It's like, why does everybody do this and nobody has the code for it? You'll figure.

KYLE: I didn't know that. I've never thought about a library not existing for that.

MIKE: That's interesting because they keep it fair. Because just randomly, you've got to make sure that it balances out.

DAVE: Exactly. Exactly. Because the accountants basically got to have a fair way of...yeah, if I take a little bit off of your penny, then later you can take a little bit off of my penny. Yep.

KYLE: Now I want a library that actually does a round and just, you know, oh, there's a five round up or down.

MIKE: Deliberately non-deterministic rounding. Nice. So, you can get your books will balance a little bit different every time.

DAVE: So, yeah, half of three cents is two.

KYLE: That explains why my paycheck is, you know, one cent different week by week [laughter]. It might actually be that. I don't know.

DAVE: Well, Dave's pretty odd. We can just round his stuff down. Wait [laughter].

KYLE: And then you --

MIKE: Well, we've done a survey of spooky stories. I hope you've enjoyed as a listener and hopefully learned something. Generally, all these things have a lesson, right [laughs]? You touch the hot stove. Hopefully, you don't do it again. And if you've watched somebody else touch the hot stove like the people in this call [chuckles], you don't have to make the same mistake. You're probably not listening to this on Halloween, but you can reminisce and hopefully enjoy.

And until next time on the Acima Development Podcast.

On this episode of the Acima Development Podcast, VP of Engineering Elishia Williams joins Mike, Dave, Will, and Kyle to talk about her path from curious kid to technology leader—and the lessons she’s learned along the way. Elishia shares how her dad first sparked her love of tech by putting her “in charge” of maintaining the family computer, a moment that planted the seed for a lifelong career in engineering. As a woman in a male-dominated field, she reflects on how confidence, preparation, and a commitment to continuous learning have shaped her journey—whether that meant taking or teaching classes, or earning an accelerated MBA in cybersecurity during the height of the pandemic.

Elishia dives into what great leadership looks like in practice: rallying teams around shared goals, shielding them from unnecessary noise, and creating space for both “thought leaders” and “thought followers” to thrive. She shares her philosophy on feedback—asking every team member how they prefer to receive it—and emphasizes that kindness and accountability aren’t opposites. Drawing inspiration from Radical Candor, she explains how authenticity, respect, and adaptability make feedback more effective than bluntness ever could.

When it comes to operations, Elishia is laser-focused on quality and stability—especially in the high-stakes final quarter of the year. She encourages “shift-left” testing, insists on thorough reviews (“I want QA to be bored”), and balances the need for speed with the responsibility of reliability. Even though she’s never personally “broken prod,” her approach to postmortems is rooted in process, not blame. The episode wraps with her signature mantra—focus on stability—and an open invitation to keep the conversation going in future episodes.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me, we have Dave.

DAVE: Hello.

MIKE: We've got Will Archer.

WILL: Hello.

MIKE: We've got Kyle.

MIKE: And joining us for the first time, we have Elishia Williams. And Elishia is going to kind of be the star of the show today [laughter]. We brought her in to talk. She's actually my boss and [chuckles] also leads up engineering here at...not just Acima, but at Upbound. And I think that she has a lot of history and things that we'd like to ask her to share that we think could be of value.

So, Elishia, I want us to begin. Often, the host tells a story, but I'd like to ask you, are there any stories from your career that you'd like to share - some compelling, you know, formative story you'd like to share to set the theme for our podcast today?

ELISHIA: Well, first of all, thanks for having me. It's an honor to be here. And I've heard a lot about the podcast, so now I get to participate in it in this way.

From a story perspective, I don't know, there's probably a lot of stories, but the one that comes to mind, especially when I think about kind of what you've shared we're going to talk about today for the most part, is really just how I got here. You know, it kind of starts back quite some time. And when I think about technology, right, I started off with a passion in technology as a child. So, I think a lot of people have that experience when they're growing up, and they're inquisitive about things and things like that. But I don't know that that was it, or maybe someone saw that. But my passion began when my dad introduced me to technology. And so, he actually gave me my first technical job.

What I will say is, I was the person that had to maintain our home computer. Now, that was, of course, at a time when many did not have a home computer. And so, I'm not exactly sure how important my job was, but I sure thought it was at the time. And so, essentially, I had to run some application, and I'd love to remember what the name of it was, but I had to run an application that compressed and cleaned the files on our machine. And he had me do this multiple times a week. And so, I took that extremely seriously, because, of course, it was my dad, and it's what he asked me to do. And it kind of gave me some insight into what this thing was in our home that he brought to us.

And so, to this day, again, I'm not sure how meaningful that was from a technical perspective. But it sure gave me my first sense of, I guess, technical responsibility. And so, I think from that point on, I pretty much knew what my career was going to be. I always knew that I was going to do something in technology. He also had us programming quite a bit as younger people. And so, I knew it would be software engineering. And so, that's kind of how I got here.

MIKE: But there's probably a lot we could dig into in that story about [laughter] the value of mentorship and somebody who says, "Hey, you know, why don't you do this?" and how much influence that can have on your career.

ELISHIA: Absolutely. It's a vivid memory for me, even that many years later [laughs].

WILL: My dad did the same thing. He bought a computer store. And then I was free labor [laughter], and he would just drop me off there, and be like, "All right, well, listen, I got all these computers, so..."

ELISHIA: [laughs] Do something.

WILL: Figure it out.

ELISHIA: Absolutely. But it definitely...there was definitely a sense of pride when I ran those applications, and everything turned out great. And so, yeah, I don't know, I have four sisters, and each of us had some kind of job, but that was mine.

MIKE: Nice. Well, and that's actually a good segue. You mentioned four sisters. Software engineering, it's long been a male-dominated industry, not always, but for the last --

ELISHIA: Pretty much, yeah [laughs].

MIKE: 40-plus years. So, what would you say to other women or others who find themselves minority in the software industry?

ELISHIA: Hmm. So, that's, I mean, that's a good one. You know, I tell people, no matter who you are, what you're doing, just walk with confidence, knowing that you're in that place because you chose the field, and you're qualified to do it. I think if you're doing what you love to do, focusing on being the minority, or anyone else's differences, you kind of don't really have time for that to be your focus.

And so, for me, I knew what I was getting into, and I decided to go to school for computer science. I looked at my classes. That was a good indication of what [chuckles] corporate America would look like at that point, right? And so, I mean, honestly, I learned a long time ago to just make sure I had individual experiences with everyone that I met.

And so, I try to stay away from generalizations that even make me have to think about, oh, you're the this or the that. It's more about we're all here for something common. And so, when I think about how I feel on a day-to-day basis, I don't feel out of place. I've never felt out of place in this role, in this career.

I wish I...no, I don't wish I could, but I try to think about, has there been a point where I walked on the scene, and I was like, I shouldn't be here? And I haven't had that. I just haven't. And I know that that's not everyone, by the way, because I talk to a lot of people. But that's been my life [laughs]. And so, I've only been in technology my entire career. And I'm comfortable in that setting, which makes me know that I'm in the right place.

MIKE: I imagine that confidence goes a long way.

ELISHIA: Oh, yeah [laughs]. Well, and, by the way, that's probably one of the things I hear the most, right? I go to a good bit of conferences, just walking in with confidence and being comfortable in the settings that I'm in. You know, a lot of people...I guess this is where some people think about, like, imposter syndrome. And I think no matter if you're a woman or you're a man, everybody could have it, right, if you just think you're somewhere that you've maybe, you know, gotten in too big for your britches.

But it's just something that, you know, I try to, for me, I'm a lifelong learner. And I tell my kids, if you're nervous, you probably didn't prepare much. And so, for me, I just try to stay prepared. I try to work hard. I try to stay studied up. And it's what I've done for a while. That doesn't mean I don't get nervous, or, you know, I'm starting something new, and I wonder how it's going to go. But I will say, when it's time to go, then I have to put all that aside. So, I don't really dwell on it.

I can think of walking in my first engineering job as a young 20-something. And I remember the company I started working for, most of the people there were no less than 10 years tenure. So, you got me, and then you got someone that's probably 40 years my senior at that point, right? And that was very different.

But even in that, I, you know, I had done some internships. I'd done things that allowed me to see the world. And I think that really helped me to walk in. And I've always been more of a people-oriented person. So, once I get in, I tell people, I could probably talk to anyone. And so [laughs], then it's all good.

But I remember this one person, I remember he, again, I was a young, young person. He's like, "What are you doing here [laughs]?" And so, some of my peers were like, "Oh, are you not offended?" I'm like, "No, I'm really not," because I know why I'm here. I went to school; I studied; I got the job [laughs]. And that was it, you know. But I try not to let, you know, those types of things be a personal thing for me. But, honestly, this person retired probably a year after I started. So, you got to kind of think about what he had seen in his life versus what I had seen in my life. And so, you know, sometimes you kind of have to just put your head where they their experience is, and it's not really personal to me.

MIKE: Thank you. And that sounds like great advice to people who find themselves in the minority. What advice would you give to men in the industry, to flip the question around [laughs]?

ELISHIA: The same [laughs].

MIKE: To the rest of us here on the call [laughter].

ELISHIA: I give men and women the same advice: show up; work hard, and deliver well. I think if you're asking, you know, hey, how do they, I guess, engage with minority or women in a field such as this? I mean, I really think it's, you know, treat people with the respect that you want to be treated with. Hopefully, there's not, you know, I’d say kick out the maybe misconceptions if there are any, and assume competence, right?

There's no such thing as you code well for a girl, right? Like, that should not be a statement, okay [laughs]? So, I tell everyone the same thing, like, your credentials may be very similar to my credentials. And so, hopefully, we can both work well together and deliver well.

MIKE: Thank you. Thank you. That's a very kind of personal line of questioning, so I appreciate [chuckles] you were willing to --

ELISHIA: No worries at all. I mean, it's a common topic, right, because it is a male-dominated field. But, again, after being in this field for so long, it's kind of the norm. I'm not sure what I would do in a field that was different, actually. Again, you know, if I go through in a technical career, I mean, you look at the classes, that's male-dominated as well. I do a lot of volunteering, you know, to try to add some of that, I guess, diversity of thought when you bring in, like, more females into exposure to technology and things like that.

Even, like, I have a boy and a girl. And so, my girl has no interest in technology, but my boy is all in for technology. So, I don't know, and they watch me every day, so...[laughs]

MIKE: That's --[laughs].

ELISHIA: It's individual interests.

MIKE: Right. My family's probably switched. My daughter's probably a lot more interested in tech than my son, who's close to her age. My oldest is definitely technology interest --

ELISHIA: Yeah, yeah. I figured one would. I just wasn't sure, but she made that very clear. I remember when she said, "Mom, I don't know what you do, but I know I don't want to do it [laughter]." It's so funny, because I would take her to, like, there was many times when I first, like, when she was a little younger, they do, like, the Bring Your Kid to Work Day and things like that. And she sat through many engineering meetings, and that could be why, right? She has no idea what we're doing behind the scenes, but the meetings maybe would turn you off a little bit [laughs].

DAVE: I worked with someone 20 years ago who, in a meeting, I straight up...he's like, "What do you need?" And I said, "I need you." He was traveling a lot, and when he was in the office, everything went smoothly, and I could not tell why. I remember turning to him in front of the team saying, "I don't know what you do here [laughter], but I know I need you here doing it."

ELISHIA: [laughs] Absolutely [laughs].

WILL: That was the biggest thing during COVID, right, during the pandemic, when everybody's working from home. So, like, I've worked remote, like, a lot, like, not always, but often. But, like, my wife, you know, she's a therapist, so she's off in the office because, you know...And so, she's been, like, exposed to, like, the blast radius of, like, the calls that I get put into. And she's just looking at me like [laughter], no, no, no, sir, no, sir [laughter]. I would rather talk to people about their trauma.

ELISHIA: Talk to the people. [laughter] Absolutely [laughs].

MIKE: Hey, we have trauma in our conversations, let me tell you.

ELISHIA: Oh, definitely [laughter].

WILL: Oh, man, yeah, yeah.

MIKE: Okay, so let's pivot a little bit. So, Elishia, you've been in leadership for some time, I believe. I actually don't know. I don't know your full story. So, I'm curious, how did you get into leadership in software? You talked about getting into tech, you know, you're doing software development, but I haven't seen you writing code.

ELISHIA: That's right.

MIKE: Yeah, you've been doing leadership for a long time.

ELISHIA: Yeah, absolutely.

MIKE: So, how did you do that?

ELISHIA: So --

MIKE: Yeah, go ahead, please.

ELISHIA: So, I got into leadership...Honestly, it wasn't something that I was thinking about. When I decided what my career was going to be, the only thing I really thought about was being a software developer. And so, I didn't really look too far as to where that was going to go. I just knew that's what I wanted to do.

But as I began to do it...and, honestly, back then, we weren't really doing Agile. I mean, we had a team, but it wasn't like...I was in a cubicle, and I was, like, just working. And there wasn't, like, all the stand-ups and things that people get where you're getting all this human interaction.

But it was funny because, even then, I noticed I always had people at my cubicle. And so [laughs], I don't know how that happened. I wasn't like, you know, inviting, hey, come over here, and let's talk about this thing. But I started to realize how much I liked technology, but I also liked the people aspect of it. And that was just one thing that was impressed upon me as I started realizing that just in the workplace.

And so, that's kind of how it started. I started taking on a couple of different leadership assignments. I had a really good mentor back then, where she kind of brought me along to some classes and things that she was doing because she was a manager at the time when I was an engineer. And I think it just kind of started to expose me of what else you could do in technology. You didn't have to totally leave the field, but you could do what you're doing but also lead people.

What I will say is, I learn quickly, but as you so graciously said, I'm not coding on a regular basis. So, when I started realizing that when I moved into leadership, I started thinking to myself, well, wait a minute, how do you keep relevant in technology if you're not hands on keyboard anymore?

So, it was at that point when I decided I was like, you know what, I'm either going to take a class or teach a class, like, I would do that twice a year. I would either take a class or teach a class. And this was more, like, take a continuing education class because technology is changing. So, what's the new languages that people are using? Or, you know, whatever it was, I would do that.

Then I became, like, an adjunct instructor for a bit because I wanted to still stay close to the software. And, yeah, those are just things that I kept doing just to try to stay technical. But I was still fleeting.

WILL: What was the last class? What's on your desk right now? What are you working on?

ELISHIA: Oh, what's on my desk right now? You don't want to know probably. Mike knows what's on my desk [laughs]. We actually did this [laughter] book. That's what's on my desk right now.

So, funny thing, Mike and team came down, and, you know, as we're trying to integrate these teams and make sure that we're doing all the best things for the company, we started doing this little study in our last strategy session on The Five Dysfunctions of a Team, and so that's why that's here, actually. We have one person that's not here. But, nonetheless, I mean, so what I will say, since COVID, I haven't done that as much. But what I did do over COVID is that I went back for a second master's degree [laughs].

WILL: Whoa. Okay.

DAVE: Oh wow. You're not screwing around.

ELISHIA: I mean, I just, I was like, you know what? They said I could do it in a year, and I'm going to do it in a year. And so, I applied and got in, and I enrolled in Baylor, and I got an MBA with a concentration in cybersecurity [laughs].

DAVE: That's awesome.

WILL: All right, cool.

ELISHIA: So, that's, I mean, but since then, I, you know, I'm kind of de-stressing, even since then because I kept working. But I just did school at, like, 3 and 4 in the morning. And so [laughs], I'm still in recovery, I think [laughs].

WILL: That's brutal.

ELISHIA: Yeah, for sure. But, yeah, so I'll probably get back there again. I'm just not right now.

WILL: You can do Advent of Code with us. It's coming up.

ELISHIA: I guess I could. I could probably.

WILL: It's coming up.

ELISHIA: I probably could [laughs]. I told myself when I finished, because, look, again, lifelong learner; I love it. I really do. But I probably...when they were advertising it and they said, oh, you could do this in a year, I'm like, oh, I could do anything for a year. And then I was like, I told my family, I was like, okay, look, because...mind you, I have two teenagers. I have a husband. We’ve got a lot going on [laughs]. And so, I told them, I said, "Look, I'm going to go back to school. The commercials say I can do it in a year." [laughter] And they were like, "Are you sure?"

WILL: During COVID. Oh my God. Oh my God. They got you good, man. Wow [laughter].

ELISHIA: Yeah, they did. But you know what? I did it in a year.

WILL: Fair enough.

ELISHIA: But then I didn't find out until, like, six months, where I was talking to my advisor, and she was like, "You know, only, like, 20% of the people actually do it in a year, right?" And I was like, "Oh, no, I didn't know that. You guys said [laughter] I could do it in a year, and I can't change it now [laughs]." So, yeah.

WILL: That's brutal.

DAVE: We didn’t say it would be easy.

KYLE: So, with a timeframe like that, how did you manage your work-life balance, I mean, and school, right?

ELISHIA: [inaudible 17:44] not. I probably didn't, actually [laughs].

KYLE: You probably didn't? [laughter]

ELISHIA: If I'm really thinking back to that time, it's the reason...so, I would get up at 4:00 in the morning, and that's when I’d do my homework. Because what my goal was was to, okay, I've got everybody sacrificing this year of a project that I just took on during COVID. And so, I tried not to impact the family too much because I still had a full-time job. I was the leader then. I mean, we were all at home, but there was still a lot to do. I think we worked a lot more then, actually. And so, I tried to do school in the morning or at night. And then I would skip all of the work time, and I would skip all of, well, a few hours of the family time, and then I'd get right back to it. And so, it was tough.

But once I, like, in order to do it in a year, you had to do two classes, I think, at a time. And those classes move pretty fast because they're, like, six weeks. So, it's a lot to do. But I couldn't extend it, so [laughs] that's what I did.

WILL: I cannot imagine. I cannot imagine. That's savage.

ELISHIA: That's why that's the last classes I've taken actually [laughter].

WILL: Yeah, right? That killed [inaudible 19:01] maybe next year.

ELISHIA: I'm good for a minute.

WILL: [inaudible 19:05]

ELISHIA: But every now and then I think about, oh, I should. And then I'm like, no, you're not doing it [laughter].

WILL: I mean, PhD is next, right? PhD is next.

ELISHIA: Yeah, you know, it's funny. I thought about that, and I was like, down girl. Not doing it. No [laughs].

MIKE: At some point the --

WILL: They say if you already have a masters you can do a PhD in two years.

ELISHIA: Thank you, Will.

WILL: That's what they say [laughter].

ELISHIA: That's what they say, yeah [laughter]. You know, and it's funny because I've got a friend that's doing that, actually. And then she got to her thesis, and, yeah, that two years comes a little longer at that point [laughter].

WILL: Yeah, yeah. Dissertation takes as long as it takes, yeah. Good luck.

ELISHIA: Yeah. I mean, because then it has to be approved and all of those things. But that's not my path right now. I'm going to keep doing what I'm doing, and I will find some more...I'll probably get back into the whole, you know, hey, what am I going to go learn next? Continuing ed, take a few classes. I do go to conferences and things like that. But right now, I'm just, like, focused on the job. We've got a lot to do [laughs].

DAVE: Awesome.

MIKE: Let's explore that a little bit. So, what exactly do you do?

DAVE: Actually --

WILL: Oh [laughter].

DAVE: I've been poking Mike in the back channel. I got this question. I got this question. So, thank you, Mike, because that is how I often ask that question, and it is often a career-limiting move of just, so what do you do around here [laughter]?

MIKE: Take that in the best possible context. Like, yes, we want to hear, like, what is --

ELISHIA: What is a day in the life [laughter]?

MIKE: So, I used to be able to say two years ago, I write code. And you ask me now, I almost never write code. So, what exactly am I doing? So, that's really the [inaudible 20:48] of the question.

ELISHIA: Yeah, you've almost become more of a champion at some point, right? I mean, you have to know what's happening. You have to be accountable and responsible in all the things for what's happening, but you're not the one making it happen [chuckles].

And so, I think it's like, you know, you kind of, you look at how can you rally your team together and make sure that you've got a pretty good direction that you're guiding them down. For me, I look at how am I surrounding myself with...and you know this: we talk about, you know, who are our key leaders? And things like that on a regular basis. But I think we add value differently because we're usually kind of the ones kind of trying to stop all of the things from coming at the team to allow them or enable them to do what's necessary, but also kind of being accountable to all the other individual stakeholders and leadership stakeholders that are like, "Hey, Elishia, what's happening here? "Hey, Elishia..." you know, that's really what it is.

So, then you kind of get into the technology because you kind of have to know what's going on, right? And there's a lot of things that are happening around here that I would say with the volume of work that comes through our teams, it's kind of hard to keep all of that in place, right? But, I don't know, I do think a lot of our time we spend discussing the work, which it's probably better we're doing it because I don't know if the people that are doing the doing want to do the discussing as well, so...[laughs]

MIKE: So, I heard three things there. You run cover for the team so that they can do their work. You communicate and take heat from the leaders you report to, and you help plan and direct the work. Is that a fair summary of what you just said?

ELISHIA: Yeah, I mean, I think you kind of have to be somewhat strategic, though, because when you're building teams and leading teams, I think it's a different type of...it's just a different type of work, whereas I used to, like, success looked like getting, you know, code completed within quality on time. And so, you put in all those hours and the years of experience in doing that to help others do it, right?

And so, if we as leaders are not giving back and instilling those things into the team that even got us here, then I think we've missed the mark already. So, I just think that's a big part of it and probably one of the reasons I moved into leadership. There's usually a progression, right? You're doing engineering, and you're doing it well. And then you're starting to, okay, now you can go help other people do that thing. And so, it just grows progressively over time.

Then you look back and you're like, wait, where did all these people come from and where did the code go, right [chuckles]? But at the end of the day, it's still there. Same mission, no difference whatsoever. It's just you're playing a different part in it.

DAVE: What is this kind of the scatter-gather that you do? By scatter-gather what I mean is, like, I report to my team lead and I say, "I'm working on this ticket. It's got this problem, da da da." And he's taking that in from everybody on the team. He's not telling people what tickets are getting worked on. He's telling people this epic is getting done, and it might be done by...And our delivery manager is being asked, "When is this going to be done?" And so, she's following up on those things.

At the VP level, what are you collecting from who, and what are you delivering upstream? Like, do you report directly to Fahmi, the CEO?

ELISHIA: No, I report to Lee, who reports to Fahmi.

DAVE: Okay, there we go.

ELISHIA: And so, yeah, actually, it's a good example that you gave. So, it all kind of, I guess you double-click in, and it just gets to a more and more granular level. But I would say, so, for instance, even today, we're in a discussion, and we're talking roadmap, right? What are we delivering for the company, and what's going to be the benefit out of that?

So, for me, I've got the folks that are actually wanting those things to be delivered saying, "Hey, are we going to deliver those?" And then I'm working with someone such as Mike who's saying, okay, now how do we now cascade that through the teams? Who do we need to do this work? What technology do we need to make sure we have? What expertise is in place in order to get that done?

So, I think when you go and you just double-click into it, it's how we bring in the right teams together to deliver on that thing. And each of us have a responsibility there. It's just if this particular roadmap item requires 10 teams to do it, how do we then get to that point?

Yeah, and I think in here, now we've kind of done things a little bit different with, like, to your point, the delivery manager, really looking at how that work’s coming into the team. But then that delivery manager is probably one of three or four delivery managers that are responsible for actually executing on that thing. So, then it just cascades up or down, yeah.

DAVE: That's fantastic, thank you.

ELISHIA: Absolutely.

WILL: So, I had a question. So, I'm really curious. We talk about teams, and, you know, honestly, I've never really gotten a chance to talk to somebody who's on the other end. So, I've been on one end of reorgs and shuffling teams around, shuffling personnel around for projects. And, usually, I just get a like, "Hey, yeah, you're going over here now.” And I'm really curious, as somebody who's sort of making these rosters up, how do you approach sort of building teams? How do you construct a team?

I know, obviously, domain expertise is the primary driver, right? And that's just, like, who knows Java? Who knows this system? Who knows whatever, right? You need to have domain expertise, but within the latitude that you have to allocate people. What's your philosophy? How do you approach it to the degree that you even have a choice based on availability and expertise?

ELISHIA: Well, I think one benefit of here is that we've had a lot of people that have been here for a bit. So, when we divvy ourselves up in a product-based model, we've already gotten teams built from that perspective. Now, there's a different question in there in that how do you know you have the right team? And a lot of that comes in, is that person a culture fit? Is that person a technical fit? Is that person a driver? Do you need a driver? Do you need a person that can be, you know, hey, just tell me what we need to do and I'll make it happen? And I think a good team is going to kind of have a combination of all those things.

Now, again, when we sit and we look at, okay, who's going to be a part of this particular team? Then we have roles and responsibilities that we know we need to fill. A lot of times Mike and the other directors have a pretty good pulse on who's on the team that can actually bring that forward. And I rely heavily on that because they've got the deep experience with these individuals. So, I've been here with Upbound now a little over two years, and so they've got many more years of experience with these folks than I do. So, they can actually say, "Hey, you know what? This person did this type of project, and it went fantastic." And sometimes, you know, the opposite.

But [chuckles] the point is, I don't do it alone, right? I have to bring in the folks that really have a lot of other information to contribute because, for me, it's really not just about my thought. It's really about how do we as a leadership team come together and make sure that we can deliver on these things?

MIKE: I heard you say there that you listen, rather than dictate [laughter]. You gather information and use that.

ELISHIA: I mean, sometimes you kind of have to be the dream killer and say, "No, that's not it." But for the most part, 100%, I mean, that's what I want to do. I want to listen, and I want you guys to bring to me what your suggestions are and how we think we're going to be successful here, because I think, ultimately, we all want the same thing.

MIKE: Great.

DAVE: You're not killing a dream if you are pointing out that we've got seven dreams that we can go after, and the one you're going after [laughter] is in just the sour spot. We don't have any leverage there. We want to get to this one. It's not big on your radar, but it's huge over here, so...

ELISHIA: Yeah, absolutely, absolutely. And it's all for the betterment, right, of the company and of the team. Because I think that if you can build the proper teams together, and they like to work together, and they work well together, they don't have to always agree on every piece, but that's where the good debate comes in as well, right? You want challenging thoughts to come to the table, and you want people to be able to come to a good solution because that's what we are, right? We're solving problems. If we're not solving problems, then what are we doing? And so, yeah, you want to have a really good group of thought leaders that can come together to do that.

DAVE: What do you define as a thought leader?

ELISHIA: Hmm.

WILL: [laughs]

ELISHIA: That's a great question. I didn’t see that on the list, by the way.

DAVE: It's a fantastic buzzword.

ELISHIA: [laughs]

DAVE: I mean, I know it's somebody who does this with their hands when they're doing a TED Talk [laughter], but beyond that, I don't know.

ELISHIA: [laughs] At a TED Talk. That's hilarious.

DAVE: We don't have video on the podcast, but everyone listening knows exactly the hand gesture I just made [laughter].

ELISHIA: That's hilarious.

WILL: Does anybody remember...there was a Yahoo guy, Shingy. Do you remember Shingy? He was like, never mind. I'll put a picture in the chat because...yeah. Like, no clear, like, a lot of opinions, but no clear responsibilities. That's a thought leader for me.

[laughter]

DAVE: [inaudible 29:53] I'll be right back.

ELISHIA: No, that is not at all what I think a thought leader is because that would be counterproductive to what [chuckles] we're trying to do. But I do think that a thought leader is someone that comes with new ideas, and not only comes with new ideas, but you come with a thought, and you lead it. So, hopefully, you can actually take that thing forward.

I think a lot of times we get into a situation where we could get in analysis paralysis, or we can all sit and debate, and we all have a position on things. But who's someone that's going to come with a really good idea and help us to take that forward, and not just take it and kind of bully it through, right? But I think someone that's a good leader can actually bring people to that vision, and that's what I think. I mean, I think we wouldn't get very far without those individuals. So, we got a lot of thought leaders around here.

DAVE: Now you got me thinking about what a thought follower would be [laughter]. Does that make sense? No. And I'm not even joking.

ELISHIA: Maybe it's this Stingy guy. I don't know [laughter].

DAVE: I'm not even joking. No, no, like, legitimately, like, if you're going to come out and say, "This is where we want to go. How do we get there?" like, in my idea, like, the thought follower is somebody who's proactively engaged in, what can I do from here to get there? I don't know if that's...I could just be making a term up.

ELISHIA: Absolutely. Absolutely. Because then you bring the team together because you need the doers, the people that are, like...because think about it, you may not have thought about it yourself, but you hear it, and you're like, that was brilliant, and I know how I can help make that happen. So, I haven't heard necessarily the term thought follower, though [laughs], David.

DAVE: I love to switch up a word.

ELISHIA: But that's a good way to look at it [laughs].

MIKE: One more question about, well, maybe I'll ask a couple more questions about leadership. What do you wish you'd known when you started leading people, you know, something you know now, you really wish you'd known back then?

ELISHIA: So many lessons around here, but I think, you know, probably the best advice I was given, and it came early on, so it was good, is my approach has always been personable, right? For me, walking in, building a relationship, how do we do this? And I remember I was working for this one company, and I had just moved into leadership. And I was doing what always worked for me. And my mentor there was actually the CTO, and I remember he pulled me aside, and he said, "Hey, you know what? You're going to do really well here, but you've got to get meaner [laughs]."

And I was like, what? He's like, "I'm telling you, the next group that you're about to work with, that's not going to work.” And I don't think he really meant that I should get meaner, but I think that sometimes what gets you in a position is not always going to be that same thing that keeps you there.

And so, there's a lot of things that you learn as you get exposed to different personalities, different levels in the organization, and being able to kind of be someone that can pivot in those different situations. It's not being someone that you're not being authentic, but it's what is it going to take to lead in this environment? And being able to adapt to that.

And so, I was fortunate, I think, to even hear that tough feedback, but understand it, respect it, and value it. And then how do I actually change the way I approach things when now I walk into that next room that he was trying to prepare me for?

WILL: It's interesting, too. It's interesting, like, how everybody just sort of has, like, different things that...like, I repeat to myself, like, 10 times in the mirror every day, like, be nice, be nice, be nice, be nice, be nice, be nice, be nice, be nice, [laughter] be nice, be nice, be nice, be nice. And I guess, you know, I don't know.

Like, one of the things that I, like, you just sort of, like, you know, you get up, and you have more responsibility and more influence. And I constantly, be nice, be nice, be nice, be nice, because, like, as you get, you know what I mean, like, as you get more influence, your words have more and more weight. And I've run into so many people who've maybe let go of the rope because there's no check on the way they talk to people, and they can get, like, out of pocket. I've seen more managers than me not, I mean, not, I mean, my managers were all pretty good. But, like, where they go, they go, like, hey, man, whoa, that was hot, you know?

ELISHIA: [laughs] Yeah, yeah, definitely. I mean, that's just never been my approach. I can't think of, I mean, I can think of scenarios that you maybe could want to do that [chuckles], but it's just never been my approach, so I didn't. I don't have to convince myself not to, but, you know, there's moments.

WILL: Was that group, like, did that group start to, like, really, like, shape up when you maybe came in a little bit, well, let's call it more direct, right, more direct, like, here's how it's got to go?

ELISHIA: You know what it was? I think it wasn't that they needed to shape up, but I think it was the level of the organization that just you needed to have a different tone with them. No, I will put it that way [laughs].

And that's truly what it was. I mean, because when you think about different personality types, too, I know even, you know, I think of, like, we're a big sports family, so one coach would not work for the other. And so, I think you just kind of have to know how to be influential at the end of the day. And so, that type of advice, for me, I thought, went a long way because it's not going to always be the same approach. And so, that allowed me to stretch myself in other ways because, you know, I am pretty direct, or I try to be. But I try to do it with some level of diplomacy to where my directness doesn't have to cut deep, but you know exactly what I mean. And so, for me, that's helpful.

WILL: I mean, this is really interesting. I mean, this is interesting because I completely identify with everything you're saying, right? Being that, like, people just communicate in different ways, and they have different needs, and they have different, like, you know, needs to, like, you know, communicate and all that stuff.

Like, how do you suss out how to coach the individual, whether somebody needs direct feedback, whether somebody needs some tough love, whether somebody needs some compassion, some empathy, like, hey, you're all right. You're safe here, you know? Like, you know what I mean? Like, how do you discern the needs of the individual? Because, you know, you get a team, and you kind of got handed a team.

ELISHIA: Yes, that is true.

WILL: And, like, you got to work with the people you've got, you know, in the way that they work.

ELISHIA: Mike, you got to keep me honest because it's been a couple of years now, and I can't remember. But one of the things I make as a practice when I start working with new teams is I ask, "How do you like your feedback? Tell me a little bit about yourself, and tell me how you like your feedback.” I want to know, right, because some people are like, "Look, just look me in the eyes, and shoot me straight." And then some are like, "Can you send me an email and get me, you know, prepared first,” right?

It just kind of depends. And I want to communicate with that individual in a way that they're going to receive it. And so, like, it does me no good to communicate to someone that's just going to, you know, go dark and just kind of clam up at some point. We want to have the dialogue, even if it's feedback. So, yeah.

MIKE: So, I actually want to chase this. I actually had it in the pre, you know, I had some questions written up ahead of time. And this idea of being nice is actually something I wrote down because I don't think [laughter] it's something that just happens, right? It is a choice, and Will alluded to that. I think it's the easier. The easy answer is to just let your emotions run wild, right?

ELISHIA: [laughs]. Yeah, that is definitely the easy button [laughs]. And then there are consequences.

MIKE: There are consequences, right. So, we talked a little bit about you say, well, no, I just make that choice. But that is a choice. And I would say, is it something you have consciously made? Have you consciously chosen to value, like, you know, gentle leadership, not going off the handle, versus something else, and why?

ELISHIA: You know, gentle leadership, I don't know if I would put it that way, to be honest, because, for me...and not that it's a bad thing, right? I mean, people talk about gentle parenting and all the...but I don't think it's that. I think that when I think about kindness and accountability, they just don't have to be mutually exclusive. Like, I could come to you in a normal, standard tone and still hold you accountable without having to berate you, or anything like that. And so, I give respect, and I expect it to be given to me as well. So, that is a decision. That is an expectation. I don't think it's an option, right?

Like, I've been in some really, really challenging environments at times. But even in spite of that, I have to be kind of true to...you know, there's this thing someone gave me, and you can't really read it that well, but it actually says...I don't even know who gave me this [chuckles], but it says, "May you be proud of the work you do, the person you are, and the difference you make."

And so, for me, like, at the end of the day, I have to be able to look back and say, how'd that feel [laughs], right? I mean, did that come out okay? And I'm one for self-reflection. And so, I know there are some that go and they respond in different ways, and they may not be self-reflecting, but that's just not been my approach. It's not how I'm wired. So, now, can I get stern? Sure. Do I want to have to? No. Will I? Sure [laughs]. But at the end of the day, it's still going to be with respect, and it's going to be direct, and it's going to be with accountability being held.

MIKE: You mentioned gentle parenting, and that's exactly what I was referencing. There's a lot of research behind parenting, right [chuckles]? And there's a difference between authoritarian and authoritative. And authoritative parenting is the one that's associated with the best outcome because there's a lot of accountability and high expectations but also a lot of warmth. And, you know, being direct is not shown to be harmful in parenting, and I think the gentle parenting folks say the same thing. It's not about not being direct. It's about keeping your emotions in control. And so, you're actually parenting rather than expecting your child to parent you. And I --

ELISHIA: You know, I remember a few years back I was reading that book, Radical Candor. And a lot of what it talks about is about, hey, you know, when you go to have those tough conversations, if you don't have kind of the relationship built with that individual and they know that you're coming from, you know, the right place, that difficult conversation comes very differently in that case. And so, if I walk up to you and you're a stranger to me and the next thing you know I'm yelling at you, like, what are you going to take away from that [laughs]? I mean, are you going to respond, or will you meet that energy? You probably could, but, I mean, it's not going to serve any of us well [laughs], so...

DAVE: I had a team at a previous gig that they were all very, very much...was it Twain that said, somebody who values brutal honesty tends to value the brutality as much as the honesty?

ELISHIA: [laughs]

DAVE: And they were like that. And they wanted everybody to read Radical Candor. And it very quickly became clear that they skipped the first two chapters.

ELISHIA: [laughs]

DAVE: They just say, this is the book that gives us permission to treat you all like punching bags.

ELISHIA: [laughs] Absolutely.

DAVE: Once you understand how important we are, you'll, you'll put up with it. So, I just handed it back to him, and I said, "Read chapter two until you can explain chapter two to me. And then you're not allowed to even look at the rest of the book."

ELISHIA: [laughs] Love it.

DAVE: Those who haven't read the book, the first two chapters are, they have to love and respect you because if you're going to punch somebody, metaphorically, in the middle of a meeting, if you're going to embarrass somebody or just really call them on the carpet, you can do that if you are friends, if you have respect. I've dropped an F bomb right on somebody's face in the middle of a meeting and had them thank me. I've also gotten fired for that, but it was a different time [laughter] because I hadn't learned that rule of they got to know how much you care before they care about how much you know.

WILL: You know what I mean? Like, you can give people feedback. But as long as...I don't, I mean, like, the thing that saves my ass, like, over and over and over is, like, in the end, if I'm giving feedback, I'm giving feedback based on, like, accomplishing the job. We've got to finish the job. We've got to deliver the goods, deliver the project, accomplish mission, fix the broad outage, whatever we have to, whatever we're trying to do, right?

Like, all my feedback comes through the lens of, like, how are we going to fix this? This isn't going good. And how are we going to fix this? And, you know, I've blown it plenty, and I give people the grace that they give me. But as long as, you know what I mean, I haven't, like, taken my eye off the ball, things land pretty well, really, really got to cut down on the F bombs. Actually, I don't. I actually cut them out. They're pretty much fine these days, but like --

ELISHIA: Maybe don't do that.

WILL: Maybe no F bombs [laughs].

ELISHIA: I don't mean to be offensive, but, I mean, yeah, then you know you're going to be offensive [laughs].

MIKE: That's how you know somebody is going to say the opposite of what they're leading with.

ELISHIA: Absolutely [laughs].

MIKE: I'm not racist but [laughter] --

ELISHIA: You know exactly what they're going to say next.

DAVE: There's no good ending for that sentence.

ELISHIA: Yeah, absolutely. And it's funny because there's a lot of people that can get away with saying certain things because people are like, oh, well, you know, that's just that person. I've never been one of those people that could do that actually. I've never tried it either, but [laughs] I've never been one of those people that could be that [laughs].

WILL: I do try and lower expectations for my behavior as much as I possibly can. Mike knows [laughter].

MIKE: Under promise, over deliver.

WILL: Exactly, exactly.

ELISHIA: Absolutely.

MIKE: So, we're getting kind of near the end of our scheduled time, so I want to pivot a little bit to maybe ask some...I don't know if this is light-hearted or not. You've been in software for a while. Tell us about a time you broke production.

ELISHIA: You know, I saw that question on your list, actually [laughter]. And I really tried to sit there and think, like, at what point in time have I been hair on fire, just really, really screwed something up like that? And what I came up with, and I hope I'm not wrong, so somebody might see this and hold me accountable, but [chuckles] I don't remember a time where I broke production. I've had post-production defects that I had to go back and fix. But, like, how we have to jump on the call and everybody figure out, oh, crap, let's go get...no, I haven't had to do that, thank God. But I have had teams that I've been a part of, so it's the same thing for me.

But now, I will say, I've had, you know, the patches that I've had to put in. I've had, you know, maintenance releases that I may or may not have had a few things I needed to do something for that I didn't do right. But I've not actually...and, thankfully, because when I first started off in software, I was working on military defense mechanism. Breaking production is just not an option in that situation [laughs]. It's life depending, okay [laughs]?

MIKE: Got it. So, you had an army process around to prevent that.

ELISHIA: Hopefully. I mean, definitely back then, I mean, we weren't as fast deployment like we are now, right? Unfortunately, sometimes that leaves a little room for opportunity for error, but no, we were a lot slower in development back then.

VIGNESH: I mean, not only just talking about Upbound, but in general, what is your, like, strategy of, you know, there is a production issue coming up. How you put a process in place to get better and also some of the lesson learning. What is your strategy to do it retro so that next time we get better?

ELISHIA: You know, and this is why I ask the questions I ask all the time, Vignesh. I know you hear me [laughs], but I ask the questions.

VIGNESH: [inaudible 46:09] Experience.

ELISHIA: But I ask the questions [inaudible 46:07] because my brain always goes to, well, wait, who did the code? Who reviewed the code? What was tested? Walk me through how we got here, and, particularly, when it's something that truly breaks production, right? And we've found that people have done missteps in the process at times, right? And that usually will come back to bite us.

So, for me, I mean, I didn't come up with it. I think when I was a developer, I followed the process. I had no other choice. Now, we had some times when we had to do things in kind of rapid fire, but I think that, again, it's been a long time. And we weren't moving, like, continuous deployment at all when I was actually developing software outside of, like, personal projects, but I think I had no other choice.

But what I will say, and I think it's something that we talk about a lot around here now, is how do we kind of do this shift left of the defect resolution? Because a lot of things, I think, should be caught a lot earlier than they are. And so, sometimes, you know, as you said, I'll quote you, my friend, in saying sometimes the business pressures are the things that kind of force you to cut corners.

I'm not one to want to cut corners, and I think that helps, but, again, it was just a different time, I think, at that point. We didn't get the option of being like, oh, just put the feature flag, turn it off, and, you know, let it go. You know, you could still do that, but it wasn't as common as how it is right now where you're actually deploying something, but you just got it turned off, and then tomorrow you turn it on or, you know, whatever the case may have been.

WILL: Yeah, like, you do a deployment through the mail. Like, we're going to burn some CDs or, like, send, like, [laughter] a big, old a tape or, like, a slug of floppies. And you're like, that acts as my deployment. You know what I mean?

[laughter]

ELISHIA: Will, it wasn't that long ago, I mean, come on [laughs].

WILL: I mean, like, you know, like, that was my first programming job. Very similar story. I was working for some government contractor out in Ohio, and we would, like, you know, we would physically --

ELISHIA: Ship the tape.

WILL: We would physically hand them the application that we wrote. Like, here you go.

ELISHIA: Certainly.

WILL: Yeah, and like --

ELISHIA: Even the CD deployments, I mean, that's all just so, I mean, it's just so different, yeah. It's very different.

WILL: God, I know. Yeah, wow. Those were wild times.

ELISHIA: [laughs].

WILL: It makes you feel old. Like, I can't.

MIKE: [laughs]

ELISHIA: No, you're right, though. I mean, so, it just looks different. And it's a much bigger, more expensive thing to break it at that point because so much has gone into getting it right. I'm not saying that that is the direction we should go back to because I much prefer the way we deploy now. But the question is, how are we making sure that we're dotting all our i’s and crossing all our t’s?

WILL: So, process-wise, like, what are some things that you find yourself, like, sort of, like, I don't want to say, like, repeating yourself on it, right, because it's not like that.

ELISHIA: Ask these two guys [laughs].

WILL: But, like, you still have to drill this. You have to drill, drill, drill. This is part of the process. This is part of the process. This is a part of the process where, like, you just have to keep on, like, reiterating, like, this important thing because people kind of slide off, and you always have to keep that, you know what I mean? [inaudible 49:33] question, sorry.

ELISHIA: Am I repeating anything often, Mike or Vignesh [laughs]?

DAVE: We love touching on models. We love touching on models.

ELISHIA: [laughs]

MIKE: The emphasis on testing, validation, getting things right before it goes out. It's evergreen, you know [laughs]?

ELISHIA: That's a great way to say that, Mike. I'm glad you answered and not Vignesh, actually [laughter]. But that's probably...especially right now, right, it's Q4. Stability is a huge deal for us, I mean, it should be. I just told someone this yesterday, actually, who kept saying, "Oh, stability is our focus." I said, "Isn't it always?" Like, stability has to be our focus. If it's not our focus, we're in trouble, guys [laughs]. And I say those things a lot.

VIGNESH: [inaudible 50:22] Any day production issue is impacting a business.

ELISHIA: Absolutely.

VIGNESH: And we lose the trust of either it's a co-worker, or a customer, right, if it's going down.

ELISHIA: Right. It's reputational risk. It's financial risk. It's all the things, right? So, yeah. So, that's probably it. I mean, I think, for me, we've got a lot of process that I think...and I shouldn't say heavy process, but just we have to get it right. And so, there are situations where I think it'd be beneficial that we make sure that we have that emphasis on quality well before.

I tell everybody all the time, like, it's my favorite statement to say, I want QA to be bored. They should have nothing to do. Oh, Mike did this? I don't want to test it. It's not going to have...Like, I want QA to be bored, okay [laughs]? And that's never going to happen, right? But, still, I can dream. That's what I want [laughs].

MIKE: It's a dream we're not going to kill.

ELISHIA: Yes [laughs]. Not yet, at least.

WILL: I mean, I don't know. Everything in engineering is a trade-off. There's no right answer to anything, right? Like, everything is a slider, right? So, if you want stability or velocity, right? If we never release any more software, man, I can get this thing [inaudible 51:45].

ELISHIA: Perfection.

WILL: It'll be like a perfect diamond. The business might not be happy, but you know? Because I've been doing a lot of retail stuff, you know? I mean, it's a real thing. Like, people are trying to, like, right now, actually, right now, it needs to be out, right? Like, September is, like, the freakout month where it's like everything, whatever we're going to do, we're making our money for the year. We're hitting our numbers for the business [laughter] for the year in September. And October is just sort of like, you know, making sure the boat isn't leaking. But, like, that's a big thing, you know?

ELISHIA: Sure.

WILL: Like, you could maybe have a day off, you know? Maybe not Labor Day, but, like, you know, like, September 15th [laughter]. If you have a tough day at the office, like, it'll be okay.

ELISHIA: [laughter]

DAVE: Will, you work for an electronics retailer, correct?

WILL: Not anymore. Now I work for a major telecommunications provider.

DAVE: Okay. If it was retail electronics...because in video games, like, electronics, September is when you lock in the orders that will be produced in time for Black Friday. So, your critical deadline for making all your money for the year is, like, September 15th, frequently.

WILL: Yeah. Yeah. Well, I mean, I'm still in retail, but for, like, a telecom, and I have things that I have to do for them now. But, like, yeah, like, no, you're making your money in that Q3 Black Friday lead-up ramp. But, like, all your stuff has to be, like, I don't know. I'm just used to, like, I'm used to this being, like, October is, like, you know, we froze it down, and, like, now I can, like, take a breath. I don't want to say coast for the rest of the year because, like, there definitely could be some on calls. But, like, ah, everybody can take a breath right around now. Hopefully --

ELISHIA: Oh, around now?

WILL: Yeah, well, because it’s out, right? You don’t want to be, like, it’s October --

DAVE: He doesn't work here anymore, Elishia. It's okay.

ELISHIA: [laughs]

WILL: October 17th?

MIKE: We're pushing on a little further here [laughter]. Some things are in November.

WILL: All right. Go ahead. Keeping it spicy. October 17th is, ooh, like, I would have to be, like, you know, at other places, I would need to have a conversation one-on-one with you or your counterpart, Elishia, if I wanted to put a feature out.

ELISHIA: Absolutely. Moratorium --

WILL: Like, they'd be like, let's have a direct conversation [laughs].

ELISHIA: Absolutely, no, I agree. Moratoriums are real around this time, for sure. Yeah. I know it's the other thing we talk about a lot right now, so...

MIKE: Yeah [laughs], it's true.

ELISHIA: [laughs]

MIKE: So, Elishia, I know you had about an hour, and I know you've got, I think, a flight to catch this evening. So, I don't want to...

ELISHIA: I have a flight to catch, yeah.

MIKE: So, do you have any final words you'd like to share, you know, words of wisdom from Elishia before you go?

ELISHIA: Oh my gosh [laughter].

MIKE: Or words of humor [laughs], words of [inaudible 54:39]

ELISHIA: No, seriously. I mean, honestly, this was a lot of fun. Mike has been talking to me about the podcast for quite some time, and I finally get a chance to participate, and I'm excited. So, hopefully, you guys have me back, and we can get into some other topics.

MIKE: Great. Thank you.

ELISHIA: Nice to meet you, Will. Good seeing everybody else. And, hey, let's focus on stability.

[laughter]

DAVE: Thank you. Thank you for your time.

WILL: [inaudible 55:04] time.

ELISHIA: Bye, guys. Thank you.

MIKE: Until next time on the Acima Development Podcast.

The episode opens with Mike sharing two stories that set up a theme: context beats dogma. First, a bike rack bolt snaps seven miles from home with his toddler on board; he “hacks” a fix using a strap to limp back safely—imperfect but right for the moment. Second, he yells to stop that same child from leaning over a railing—normally a “don’t,” but justified to prevent harm. Bridging to software, Mike argues that sometimes you should break best practices: a hard-coded, partner-specific access control once shipped as a pragmatic stopgap, worked for years, and only now is being replaced with a proper, general solution.

From there, the group explores when and why “best” practices stop being best. Dave frames it as “there’s always a best move”—for this context. Will and Kyle note performance work routinely trades readability and safety for speed; measurement is essential, or all you’ve done is make code harder to read. They contrast language and ecosystem philosophies (Python’s “one right way,” Ruby’s malleability, Java’s explicit structure), agree that humans are the expensive resource (optimize for mental load and boring, readable code), and acknowledge domains (firmware, game engines) where constraints force “ugly” but necessary code. The team also debates two coexisting feature-control systems—slow but self-contained env-based flags vs. instant, granular runtime flags—concluding both are needed because different roles value different trade-offs.

They close on practical guardrails: prototype fast, even “sloppy,” to learn and validate; refactor after you’re green. Use YAGNI—don’t solve tomorrow’s problems today—and be kind to “future you.” Keep a backlog of intentional hacks, prioritize cleanup time, and recognize that some code paths matter far more than others (optimize the hot ones; duplicate templates when sharing adds needless complexity). Break rules deliberately in sandboxes to learn (e.g., Juice Shop, OWASP exercises), but in production favor simplicity: make it easy and explicit unless you’re forced not to—then measure, mitigate, and circle back to clean it up.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I will be hosting again today. With me, I've got Jordan, Will Archer. We've got Dave.

DAVE: Howdy, howdy.

MIKE: And Justin, and Kyle.

And, as usual, I'm going to tell a story [chuckles]. Actually, I've got a handful of them here. I'm not sure if I can share all of them, but I think I want to introduce the story by first telling a story about cycling.

The great Sandi Metz shares a lot of good stuff. She talks about cycling all the time. I can do lots of cycling stuff, right? So, I'm going to tell a cycling story. So, I was riding with my kids, and I had my youngest in a bike seat sitting on a rack that was over my back tire. And he was getting a little big probably for it [chuckles], but it worked fine. I could do it.

What I didn't know is that maybe getting that top-heavy on the rack I had was putting a lot of stress on the bolts that were holding it up. And I was doing a loop, and it was, like, seven miles from home, luckily, not that far, but seven miles from home. And the bolt sheared off that's holding the rack up [chuckles]. Not a great thing, you know [chuckles]?

DAVE: With him in the seat?

MIKE: With him in the seat. That’s right.

DAVE: Because of the weight on the bolts. Yeah. Okay. Yeah.

MIKE: Weight on the bolts. And so, the rack drops on the tire, suddenly stopped. I’m going up a hill when this happened, you know, rocking back and forth because I'm going up the hill, of course, putting the stress on the bolts. I suddenly stop. You're not moving anymore, right? Now what [chuckles]? Seven miles from home. I can't really push the bike because now the rack's sitting in it. I can't take him off the bike and make him walk seven miles. He's, like, three years old [laughs], right? That's not going to happen. I also had a tether to pull the other two kids.

So, it was a bad situation. What do I do now? No one was at home to come pick us up. I could have called, like, an Uber or something, but what do you do? "Uber driver, can you come put three bicycles and a car seat [chuckles]?" There was no good way out of the situation.

DAVE: You got two kids on a tether. Dog sled.

MIKE: Dog sled [laughs]? Not going there [laughs].

DAVE: Fair.

MIKE: After some careful analysis, I got an idea, and I had a strap that I use for strapping stuff to the frame, like a water bottle. And I connected the strap to my bike seat, to the rails on the bike seat, to hold it up, and wrapped it around one side of the rack and pulled it really tight. So, it was just hanging from the strap by my seat.

I found that if I sat down on my seat…and I was standing up to peddle, right? I went as gently as I could. It didn't hit my spokes very often [laughs]. I got back on, and I rode seven miles home that way. And I made it. And I took off the tethers. The other kids, they rode independently [laughs]. They can make it seven miles. It was fine. So, we did it. We made it home. And that was not the purpose that those straps were made for [laughs]. There was nothing in there that was serving the correct purpose, but we got home.

Okay. So, that was story number one. I think it's a good one [laughs]. So, a tiny little story. You shouldn't yell at your kids, right? I think most people would say, “No, don't yell at children.” That accomplishes nothing.

Yesterday, my youngest, again, he is a common thread in this set of stories, was upstairs, and he leans over the railing, just jumps up, like, jumps up on the railing and starts leaning way over. And I yelled because [laughs] I was horrified. “You need to get down. You're going to fall off and something terrible is going to happen.” And I don't regret that.

He didn't like it. I didn't like it. There was some hugging and talking and making sure he was okay afterward. But, you know, I broke the rules, and I did something that normally I would not be proud of. And I made him sad, and I don't feel happy about that. But I was scared, and I wanted him to live. I didn't want anything, you know, any of the horrible consequences that could have come from this to happen. So, I said something, you know, I did not do what I would say that any parent should do. In this situation, those rules didn't apply [chuckles]. You know, you do what you can to save somebody.

So, we talk about software, right? I'm talking about outside of software. Let's talk about software. Sometimes you should not follow best practices. Sometimes you need to strap something on, and that's the right thing to do. Go ahead.

JUSTIN: I mean, if you're going to apply that back to your bicycle, I think you should still be riding with your kid hanging off that strap today [laughter]. That's really what happens [laughter].

MIKE: Well, okay, so, I've got a software story. Years ago, literally years ago…I don't think I'm saying anything that's exposing anything horrible [laughs].

There was a partner who had a feature request that was just for them, where they just needed certain employees to have access to a certain feature, and we didn't have a framework to make that happen. In this context, we just didn't need it, so there was no need to build it out. Nobody else was requesting it. And to build the framework to make this happen so that it would be generally applicable across all the users would take months. And the customer needed it, like, already, right? And there was no way that's going to happen.

So, we put in a hack. We just hard-coded the users that got access to the feature. If you're one of these users, you get access. We didn't make it too terrible because it was configurable, and you could set up in your environment. It wasn't, like, in-line in the code, but, yeah, it was a hack. And the customer was happy. Didn't build the feature, and years later, it still works [laughs], you know, the straps holding it on. And, in this case, it wasn't that important, right? It was a pragmatic fix to a nasty problem, and it was kind of a nasty fix to the problem, but it worked. Not too many people…there are actually a few other people who have requested the same feature, so it's grown.

There is a plan to mitigate this. It's actually probably going to be happening in the next quarter. But after years of doing good work, this hack is finally going to be retired. Man, it did its job, and I don't regret it [laughs]. I'm actually kind of proud that we solved this problem, and it worked, and nothing was harmed. Sometimes it's the right thing to do, and a brilliant hack, I think, deserves some respect. Oh, I've got some thoughts about some rules about when to break the rules. Well, I'm curious what you all's thoughts are. I threw some stories out there to seed some discussion.

DAVE: There's a phrase that I've trotted out in front of most of the people on the call at some point, if we've been working together, which is there's a fantastic book from years and years ago called “Bobby Fischer Teaches Chess,” Chess Grand Champion from the ‘70s. One of the lines that I remember from Bobby's book is he says, “There's always a best move. You might not have any good moves, but there's always a best move.”

And this is kind of what I see as that being, right? Is it OSHA-certified [chuckles] to strap a rack and then hang a child from it that you're actually related to and theoretically care about [laughter]? Of course not. But you're seven miles from home, right? That's probably the best answer, or at least one of the ones that qualify for that. If you'd had somebody with a pickup truck nearby, that would have been the better option, and it's fine.

The thing that I get thinking of is when we say best practices, I hear Best with a capital B, or Practices with a capital P. And I see it engraved on a leather-bound book that looks suspiciously like scripture.

MIKE: [laughs]

DAVE: And all you have to do is see somebody misapply scripture in the real world to realize, okay, yeah, it's called best practices because that's the name on the book. The gotcha to a best practice is the context. Is it the best practice for this specific moment? Usually, what a best practice is, is absent other context, this is a really good way to do it, and we probably should. And we've given thought to these things that you may not have considered, like security or, you know, integrity, or something like this.

And just jamming in a quick user ID check, of course, that's going to be rife with problems, so it's not a best practice. But I argue that having cash flow come in is absolutely the best practice, 9 times out of 10. And getting it working, getting it shipped, minimum viable product. And then if nobody ever used that thing, you throw it away at some point, and if somebody does and it gets really popular, you refactor it. Or, like Justin said, you ship straps with every bicycle and no bolts, because that's just how we do it now [laughter].

WILL: I mean, I'd say, like, you know, from a software engineering context, I don't know, I can't think of a single performance optimization that isn't deliberately contrary to all software engineering best practices. It's going to make it more fragile, more complicated, more state, harder to read, harder to update, everything. Everything you do to make things fast, right, is going to make it worse, right? So, is it worse or is it better? It's faster, and it's harder to deal with, right, and that's --

KYLE: Actually, what I was going to bring up, too, is that's where I've seen a lot of pitfalls in, quote, unquote, like, "best practices for coding," is when you want to get performance out of your system. They don't tend to go hand in hand.

WILL: Nope, cross purposes, every time. I would say, like, 100% of the time, they go cross purposes. I can't think of a violation of that. Sometimes you get performance stuff via the platform or via the language or via anything like that. But if you've ever sort of followed the internal turmoil of an open-source project that's really trying to get their performance game in order, let me assure you that the tears are there. Just because they're not yours, they [inaudible 11:34]. Going fast hurts, you know. Most racecar engines, you know, you couldn't even get started if you weren't a serious mechanic. That's how it goes.

DAVE: I used to own a Jeep Wrangler, and we called it, it feels like driving a basketball because the suspension on it is built for off-road, not for the highway. The thing you mentioned about optimization, this isn't that quote, but it's absolutely based…treats your statement as bedrock. The thing that I will tell people is you have to measure. When you do performance enhancement, you have to measure. And here's the quote that shows the bedrock of what you just said. Because if you don't measure, the only thing you know for sure is you made the code harder to read, and that is straight it, yeah.

MIKE: So, there are multiple different dimensions of good, and they're sometimes at odds with each other. And it's very easy for us to get fixated on one of them and to the detriment of things that we should be caring more about.

WILL: Unless forced otherwise. Unless I'm forced otherwise, I will always, always optimize for what's the least amount of thinking that I can do to get this project done? That's my North Star. What's the least amount of thinking? I just do it the easy way, like, mentally, mentally load. I optimize for my mental load, unless I'm forced to do some other thing. Going back and fixing bugs, high mental load. What did past Will do? That asshole? Oh my God. I don't want to think about him. I want it done. You know what I mean [chuckles]?

And so, that's it. I don't want to think about it. And if I do have to think about it, I don't want a migraine pill [laughter] reading through whatever the hell I did. And so, that's my North Star. Make it easy. Make it easy. Just finish it one time. Make it boring. Make it clean. Make it stable. And then if I'm making so much money that people will, like, back a truck up to my house so that I have to make it fast, fine.

MIKE: [laughs]

DAVE: Deciding in advance what the best criteria is going to be, when those criteria are kind of...how do you tell them apart, right? I rushed into Python from Perl because...I said in the pre-call Perl is a write-only language. I love Perl. I've spent a lot of time down in it. I've blessed a hash or two. If you know what Perl is, that tells you about where I was. I've never met Larry Wall, but that was next. I love Perl, but it's very, very cryptic. And Python comes along, and it's all about make it clean; make it readable. And I'm like, yeah, let's do that.

And Python has this rule, which is there's one right way to do it. And the supporting quote that they will use is…because you come back and you say, "Well, but if I want to do a map reduce, that should be a slick inline because I'm just doing it." And they're like, "No, no, no, no. You need to have the for loop. You need to have the..." I mean, they have comprehensions now. I'm old. This was a long time ago. But Python, you had to have the colon, and the indent, and da-da-da. And if you want to do it twice, you had to have another one. And their argument that they would say is the special case is not special enough to warrant a special case.

What they're saying is if you can look at the structure and you know what the structure is, you can infer meaning from the structure, then that's going to increase your understanding. It's going to reduce the mental load. And you then put your...the difficult portion of your algorithm is in the parts of that structure where you would expect to go look for.

And after I'd been in Python for five or six years, I started realizing there's times when the special case is really, really more convenient. Like, doing it the one right way is the worst way possible to do it. And all these promised features of, "Well, it's going to be more readable," no, it isn't. None of that actually paid off. It turned into scripture for me. And as soon as it became dogmatic, it started to really leave a bad taste in my mouth.

This is why you've heard me talk about coding, where I'll be like, I like to program in a language where a big idea should take up a big space on the page. But a small idea should be compressible down to something very, very small. And I have written a 300-character line in C with a comment in front of it that said, "Don't touch this unless you know what it means. This is a big, hairy, scary…" And, literally, it was vector math, so I didn't want people touching it.

It was literally, if you touch this, the motorcycles will fall over, because I'm literally applying a torque on the Z-axis of this motorcycle to keep…it was a racing game for when I worked at Acclaim. And I wanted a very dense, very packed, very...I wanted the line to scare you, not because you needed to be afraid of it, but because I needed you to respect it.

And when we did actually make a change to that line, it was two of us at a whiteboard, and we spent three hours unpacking the math, unwinding it to deoptimize it, to make it easier to read and understand. We made the change we needed. And we packed it back up because all it was, at the level of the method we were looking at, it was just one thing that was, make sure the bikes don't fall over. That's all it was. It was just give me a little bit of a torque impulse in the rotational axis. And I guess that's what torque means.

But we wanted that compressed down to be something really, really hard. Would I write production code like that all the time? No, not unless that was the...I wouldn't write the whole method that way. This was a 2,000-line physics method, and that was one teeny, tiny piece of it. And I wanted it to be one teeny, tiny piece. And if we had unrolled it, it would have been half the function for one-tenth of the functionality.

And unfortunately, optimization...this was on a PlayStation. I couldn't make a function call because I did not have the budget to push things onto the stack, make it jump, and do it over there. So, I literally couldn't extract it out of the source code [laughter]. It had to be packed into that spot.

WILL: Oh, I remember that, yap. I can't allocate memory in this loop. This loop, I cannot allocate memory and maintain the performance guarantees that I need to keep my frame rate up or my bit rate up, or whatever.

DAVE: Mm-hmm.

WILL: Mm-hmm. Mm-hmm. Yeah, you're going to see nasty work in situations like that, real, real ugly work. And you don't do it unless you have to.

DAVE: I toured in...my grandfather was an oil man, and I remember riding in the truck with him as a little kid and looking at the pump jacks. And I remember at one point looking at this machine, and it's hydraulic cylinders 12 inches in diameter, and it smelled of sulfur and just awful. It was tar everywhere. It was filthy. It was awful. It was a miserable experience. And me as a six-year-old kid going, "This is gross. Can we just not be here, please?" And my grandfather says, "Look at how beautiful that is." And I'm like, "What?" And he was basically saying, this is a big machine that does a big job. It's important, and it's a messy job. It's shoveling muck, almost literal muck, right?

WILL: It’s literally shoveling muck.

DAVE: It's pumping sticky, gross crap out of the ground so that we can have civilization. And that big, gross, tar-covered, sulfur-smelling machine was doing exactly what...it was supposed to be covered in tar and smelling like sulfur. That's what it was. That was its point.

WILL: Yeah, man.

DAVE: These analogies are getting weird. I like it.

WILL: Yeah. Well, no, I mean, I think that's, I mean, here is specifically, like, this is one of the grievances that I've always had with Ruby in particular. And [inaudible 19:16], I mean, I love the flexibility and the dynamism of the Ruby language, but I feel like there's a foundational trade-off. It's a foundational strategic error about human nature that Ruby programmers got kind of wrong.

And as much as I hate to say it, I feel like despite being in my soul a Ruby programmer and I really love it, but the language itself is completely malleable. It can do whatever you want. You can write whatever domain [inaudible 19:46] language that comes into your mind, and you can make anything happen, and people frequently do, right? Which is a wonderful thing because you can, like, express these beautiful thoughts very succinctly, and things can just flow. And you can run the mother of all demos where you just, like, bam. You just kind of log up in real time right in front of you because all these things magically unfold, which is a beautiful thing.

But versus, I mean, the counter-example of that is, like, just nasty, crusty, fusty old Java, right, where everything, like, where's this class? And I'm like, well, I'd tell you. I'll give you a hint. It is laid out right in the class. There it is, boom, boom, boom, boom, boom, directly structured. I could follow that chain right to the file, and I know exactly where the hell it is, and I know exactly what it does, and I know what it will do, and what it won't do, what it expects, and, like, et cetera.

But it's, like, big, and it's crusty, and fusty, and, like, ugh. But it's all laid out explicitly. And, like, the problem that I think where, like, I was like, okay, well, why is Ruby such a niche language? I’m like, no, well, it's kind of because of this. Because if it's just Voodoo and it happens just magically, right, well, how do you know the incantations, the magic spell? You know, where's the grimoire, you know, that I'm going to use to summon it up this web page? What's in the documentation? And what do programmers not really get right? Yeah.

DAVE: The fact that they don't ever document, let alone document well.

WILL: Nothing. Yeah, and so, like, you get the sort of, like, graveyard effect, right, where, like, the grand wizards, you know, they know everything, you know [laughter]. But, like, but if you're not the elite Dumbledore-level sorcerer, you can find yourself stalling in the dark for a very long time trying to find, like, where did this stuff go?

And, you know, Rails starts to mitigate it because, like, they're like, hey, just put it in the right place, okay? But that's, like, you hope you put it in the right place [laughter]. You hope the other guy put it in the right place, you know? But maybe they were busy. Maybe it was a Friday afternoon, you know? Maybe, like, somebody put it in, and they're just like, ah, just put this one next to the other one; it'll be fine, you know? Anyway, it's a little bit of a tangent. But, yeah, and it's just, like, I'm just trying to be as lazy as I can get away with and still keep my job.

MIKE: So, you're saying, building on what you said before, making things explicit, boring, easy to read should be the goal in almost all cases.

WILL: Just keep it easy, man. Keep it boring.

WILL: Like, I’d love a boring day at work. Do you know how bad I love a boring day at work?

MIKE: [laughs]

WILL: Oh my God. Well, I could, like, put on a podcast and, like, I'm not, like, toweling my brow off, where I'm trying to, like, figure out what's happening. Or I'm just, like, I could just pretend I'm [inaudible 22:48], you know what I mean? It's, like, this is just easy, ta-ta-ta. Put some music on, you know what I mean? Just vibe out. Like, I'm not crunching, like, numbers, like, splitting the atoms in my brain. Oh, I get three of those days a month, maybe, and I mark them on my calendar [laughter].

DAVE: That's my grandpa's good day, right? Is go out into the oil field and pump jacks, and all he's got to do is just check on them and make sure they stink. Yep, they stink. We can go home.

MIKE: Well, I was thinking about this as you were bringing it up before. Hardware, so modern hardware is, in general, fast, and storage is cheap. I'm going to say never, but it's pretty close. Yeah, you're never going to use all that CPU, right? You're never going to use all that memory. There are cases when this is not [crosstalk 23:40]... There are violations of what I'm saying. But, in general, the hardware is cheap.

You know what's not cheap? Us. We are not cheap. And if you make us more expensive, you've done something wrong. Technically, we could hand-roll loops in Assembly and be optimizing all the time. But nobody does that unless there's some very special need because it is incredibly time-consuming and error-prone. And that costs time that relatively highly paid people need to take. And whereas make the hardware do it; make the compiler do it, means that we get to think in something much closer to English, or whatever our native tongue is, right? Something similar to natural language.

WILL: [laughs]

MIKE: What’s that?

WILL: I said, please no English.

MIKE: Yeah [laughs]. Something similar to whatever our native tongue is. Something that reads largely like natural language but is unambiguous. Forget the fact that LLMs exist nowadays, and they might do what you want, and they might not. Unambiguous language.

We're writing code for us. I've heard you say this, Dave, a lot. We write code for humans. Most of what we're doing is writing this documentation to ourselves and our peers, and the computer goes through a whole lot of work to make sense of it because we've set up a bunch of rules. But we design these languages around our understanding because, in the end, it makes financial sense. And, in general, we're doing this because we want to get paid. We're trying to support our families, and we're doing whatever it is that our aspiration is. We want to eat, therefore, we write code. And we don't want to take more cost than it should. So, we write things that make sense.

KYLE: One thing I'm thinking about is you said hardware. There's another environment where I feel like best practices get ignored even more and more, meaning more, like, reliability and modularity, and that's when you're working with microcontrollers. Anything actually in, like, firmware-based, you're very limited on the resources that you have. And the code, if you start looking at firmware code, because your memory modules are so small in some of these things, it's not readable. You need that master's degree or that doctorate to be able to even go through some of that code to figure it out, and be, you know, that these controllers are in Java these days or whatnot, you know.

WILL: No, they're not [laughs].

KYLE: No, they're not [laughter], but, you know.

WILL: It's really not because if you write it in nasty, old C, I can say [inaudible 26:39].

KYLE: It will run better. Yeah, but point being is, like, it's still, like, looking at a different language at some point, right, even if it's one that you're familiar with because it is so condensed. And you're not going to see the same best practices that you would if you were, you know, going for a full-fledged app for software-based.

WILL: I mean, I’d say, like, embedded device drivers, right, like, they have their own best practices, and it's, you know, I mean, like, it really is. I mean, like, they're not...I think everybody's trying to do the least amount of work they can before quitting time. I mean, and a lot of that stuff, a lot of it is sort of, like, you know, like, you're really not doing it in a way that’s, like, hard. It's hard work to think about, but it's also a lot narrower, right?

Because, like, you know, like, device driver, what are you doing? You're pulling bits off a bus, right? You're turning that into data, right? You're putting that data out to an address, right, you know, your memory mapped I/O, whether it's like, I'm going to save it out to a buffer so that, like, somebody can pick it up downstream. Or I'm going to, like, send these pins for this controller to move this, you know, motor or whatever the heck you're doing. I mean, like, it's actually…so, I mean, on some level, I don't want to, like, undersell, like, how hateful a process it is because it's not fun, and you don't want to do it. But it's also, like, once you break it down, you know, it's not so bad, you know. If you want some really, truly awful, hateful work, performance compilers.

MIKE: Gotcha [laughter].

WILL: You're getting all the smoke, all the smoke. You need to know, like, all the nasty work that's being done on the platform level, on the hardware level, at the language level, and, like, you've got to see anything that comes. Anything that comes in the door, you know what I mean? If your lexer, you know what I mean, will acknowledge it as a valid program, you've got to figure out some way to make it happen. Oh my God. I'm making web apps. No more of that for me [laughter]. [inaudible 28:58]. I'm done. No more.

JUSTIN: So, to kind of bring this back a little bit to, you know, you write some code. It does the thing that you need it to do in the moment. What's the next steps? Like, I've often created tickets that I put on my backlog, and I specified, here, I did a thing because of X, Y, and Z. We should fix it sometime. And then, of course, it sits there on the backlog until we, you know, we just ignore it for a long time. But do you guys do that? Do you guys, like, [inaudible 29:35] code, or do you create a ticket?

WILL: I love it, man. I'll put it in the sprint. I'll just be like, you know, I'll put it in the December sprint and just be like, "Hey, I did this," and, like, it seemed like a good idea at the time. And, I mean, honestly, it's like exponential backup, right? Where it's like, okay, listen, I have to hit my ship date, okay? I got to hit my ship date or else, you know, we're all fired, you know? So, okay, you know what I mean?

And then, like, maybe, like, two weeks out of the ship date, we're going to see where we're at. And then maybe a month later, and then, like, six months later, and then, like, a year later, and then, like, you know, like, every year. We'll be like, Hey, it's, like, a week before Christmas, you know? So, let's all look at our stockings. Let's all check our stockings for lumps of coal. Just sometimes when I'm like, listen, I know I'm not doing anything. It's, like, the day before Thanksgiving. We sure we're still good with this? Okay. You know, whatever. And, you know, it could be like [inaudible 30:43], where it's like, yeah, I did a bad thing but, like, the blast radius is small. The value is high. And I'm not, you know, I don't know [inaudible 30:55], you know. That's the next guy's problem [laughter].

MIKE: It's something that I was thinking about before, you know, before the call, I was writing down some notes. Some things are more important than others, you know, that sounds almost [inaudible 31:13] logical [laughter]. If there are two things of different importance, one is more important than the other. But it actually matters. There are things that matter a lot, and there are things that matter a little.

For example, if you have a piece of code that is getting hit over and over and over and over again…I had this happen once. There was some permission checking system in an app I was in that was, you know, of course, it was used dozens of times for every request you made because, you know, it's just checking all these permissions all over the page. And it was used all the time, and it was slow. It was terrible slow.

We optimized that, and, like, just that one thing. We optimized permissions, and the app went, like, twice as fast or several times faster. That code was important, right? It really mattered. We needed to make that run well, and so we did, like, some caching on it. Again, it makes it worse to read, but it mattered. It was enough. It mattered enough that it was worth getting the attention.

On the other hand, if you've got, like, a template, and you're on one page, and you like the idea of having it shared but, no, this other page needs to be a little bit different, then copy that thing. There's almost no cost to having another file and making it look a little bit different, yeah? There's a little bit of duplication. But you know how easy it is to copy a template? And you know how hard it is to try to share something between templates and make sure that that's right? And it's off a little bit, and then now it doesn't match anymore, and you're fighting that for years. That's a nightmare, right? Copy the file. Nobody cares. It'll work. And these are supposed to be [inaudible 32:51]. If it was going to be the same, you wouldn't have been asked to copy it in the first place. There are things that matter a lot, and there are things that don't.

JUSTIN: I mean, that goes back to the importance of grooming your backlog and everything. It’s like, you look at your backlog, and you look at all the tickets you've created in the last six months or month and a half or whatever. And you're sitting there, and it's like, what's the biggest bang for the buck? And you have a limited amount of time. The company has a limited amount of budget. That thing that you did to fix prod, that's gone. That's still working. And you have the choice between fixing that versus shipping new products that could be new revenue. That's an easy choice.

DAVE: I worked with a guy years ago who wanted to put some backlinks on our website for SEO. So, basically, he wanted us to give him the ability to just drop links into our website that would point to his other sites. Okay, that's fine. He's basically farming. What do the kids say? Farming aura but with Google. He's just trying to increase the amount of Google index rank that he can get. And I'm like, really? You're just jamming extra links? You're just stuffing links into all of these sites so that it radiates back? And he paused, and he goes, "It's a cheap trick, but it's a time-honored cheap trick." And I'm like, that's another great way to say best practice, in my opinion [laughs].

WILL: If it makes money, it makes sense, you know.

DAVE: Pragmatism. If it works, it's true. Absolutely. Pragmatism.

WILL: That's the truth, man. I can't fault it, really.

MIKE: In that backlog, we should probably not dive too much into this because we could end up spending a full session on this. We probably have before. But you've got to have some time on your schedule to be working on that backlog because if you leave a bunch of garbage around, eventually, you've got a big pile of garbage. And you do need to be cleaning up. That's, I think, a different discussion. You do put it on the backlog. You prioritize it. And you spend a significant amount of every sprint, or whatever your time interval is, working on it. Maybe that number is 20%, maybe 30%. Maybe you had a dedicated team that’s going through and just cleaning stuff. I've seen that work as well, and they're a meaningful part of it.

WILL: I’ll do it in my free time.

[laughter]

MIKE: Sure [laughter]. You've got to dedicate some time to it. I did take that rack off my bike, and I came up with a different solution. And I've got a trailer that's mounted to my seat now. It works great. The alternate solution has to be built. You're going to have to deal with that at some point. It doesn’t mean you made the wrong choice at the beginning, but you do have to get to it. So, I'm not advocating, yeah, make the mess. It'll take care of itself. But you should make the mess when you have to and prioritize what you fix, and then be working on the top priority item.

DAVE: You said something a few minutes ago, Mike, about some things are important and some things are not. And, for me, one of the toughest things to start, and this goes back to don't treat best practices like it's a Bible, the thing that's important might change. And two different things might be important to two different people at the same time.

In our architecture meeting today, we talked, and I think everybody here...Jordan might not be aware of this. We have two different ways to control whether or not a feature appears on the website. We have one way. We have a library that we wrote called system settings. And it will look at environment variables coming into the system, and you can set an environment. And we have these local files that we keep in the project that you can override or supply an environment variable if it's missing, and they're cascaded by environments. It's a nice fine-grained way to do it.

And It's super convenient as an engineer because I can say, here's this feature. I'm going to put the feature flag in the code, and I'm going to turn it off. And in my local code, I'm going to turn it on. I can test it. We can play with it. I can give it to QA. They can turn it on, play with it, test it, and da da da, and down the road we go. And when it's ready to go out, we just ship it to production. We don't have to involve DevOps. We don't have to touch anybody else. We don't have to do a dual deploy. We are good to go.

However, our deploy process is kind of lengthy. It's fairly long here, and the review process is even longer. This is not a fast way to turn a thing around. And sometimes, I think I've said this before, when the egg hits the fan, you need to be able to turn off the fan or the egg, one of the two. And for that, you need a kill switch.

We have this other system called Kipper, and Kipper is an open-source project. You can get it right now and play with it. It's fantastic. Kipper, you basically go to the Kipper library and say, "Hey, is this feature enabled?" And we have the advantage of saying, for this merchant, or for this customer, or for this class of users, or whatever, you can give it actors. And Kipper can say, "Well, it's enabled for that person, but not this," or "It's enabled for this logged in user, but not that." So, again, you can hide people back and forth. And you can go to Kipper, and you can turn it off, and it's off instantly. So, if something blows up, you can make it stop blowing up, or you can turn it off.

But this is the reverse problem. Now, if you want to ship something into prod, you have to go to our Kipper site, in whichever environment you're in: local, preflight, prod, whatever, dev. Whichever environment you're in, you have to go find that in Kipper. You have to type that variable in, which you're going to mess up once, right? We all did it once. And you're going to figure out why it's not enabled on the site. Am I the wrong user? There's all that mess.

There's a batch deploy. There's a tandem deploy for how to do this. And different users find these things indispensable. With Kipper, you can say, "I want to slowly cut traffic. I want just 10% of my traffic going here." Or "I want 50-50. I want to do A/B testing between the two." You can do that all with Kipper. System settings, now the flag is either there, or it's not. You could go in and say, "Here's 10 merchants that I want to be included in the system setting," and keep that in environment. But if you want to change those 10 merchants, you've got to do another deploy, right? Again, it's slow.

And we kind of went around the table a little bit in architecture because there are people on one side who didn't see the relevance of the other side, and vice versa. People are like, "Well, I need this. Who cares about that thing?" And the other people were like, "Well, I care about that." So, where we ended up with is, right now, we're going to continue using both systems. But we have an increasing desire.

And this won't surprise Mike, this has been coming up in architecture for three years, that maybe we'd like to have something that can do both. And it's just one place to do it in the code, and you can deploy it if you need to. You can turn it off instantly if you need to. You can filter it, A/B, whatever. But it's taken us three years of going around trying to determine what is the best practice, which one...and we haven't had a good understanding yet of like, "Oh, we need a solution where the best practice is to solve all of your best cases and all of your best cases." Those are constraints. It's not a best practice. There's two groups, and they both need the thing that they need, and because they're both true at the same time, we have two systems. If we replace them, we're going to have to replace them with a system that can do both things.

MIKE: But you're able to live with both of them for a while.

DAVE: Yeah, and I can't get my manager to give me six weeks to go write a new library to build a new thing that would do the thing. I'll make it a Rails engine. We can plug it in the app. It'll be so slick. Yeah, yeah. It'd be nice. It'd be nice. Making money for the company is more important.

MIKE: Let me throw one other time when I think it's a good idea to violate best practices. Play. There are times when you should break it on purpose when it's not in production.

DAVE: Yes. Yes.

MIKE: If you want to learn something, one of the best ways to learn it is do the wrong thing. There's this great thing, Juice Shop. It's [laughs] this system for learning web security, where it's a website that has everything wrong with it. It violates all the best practices for security. And you can go in, and you can do horrible things to it [chuckles] that should not be done because it allows you to do it. It's like a scavenger hunt. What are all the things that you can go in there and you can break? You wouldn't normally put up a web app like that, but you learn so much by having done it wrong.

I did something similar once years ago where we built our own web application. Over a series of weeks, we had a session a week where we would learn one of the OWASP top 10, and somebody would be assigned to violate the rule. We went through each of them and added some code somewhere in the app that violated one of the OWASP top 10 rules. And then the rest of the team, once a week, would have a chance to try to break it. And the team that I was with learned so much about security.

I don't think they ever went and put any of those vulnerabilities in their code ever afterward because they got it. I think that you learn a ton from violating best practices on purpose in a sandbox and should be actively encouraged to do so. There's something about the mental exercise of it. But we should deliberately set up situations when we're learning something, to break the rules, to figure out what those boundaries are because sometimes maybe you should. I mean, there's probably some cases where you should. Security? Maybe not. There's probably an exception here. Well, there's there, the Juice Shop. You violate security on purpose so people can learn.

In general, no, you never, ever, ever want to do that, and it makes it really hard. I remember trying to allow some SQL injection in Rails, and it was hard. I had to [chuckles] break so many things to let that through. And you learned a lot of what you had to do [chuckles].

JUSTIN: I, unfortunately, have seen that problem before in Rails [laughter]. They tried really hard, and they succeeded [laughter].

MIKE: It is possible, but you have to --

WILL: It's Turing complete. You can always break it.

MIKE: I saw a whole reporting system built once that was reliant, at its core, on SQL injection.

WILL: Oh.

DAVE: Fantastic.

WILL: I would also say, like, you know what I mean? Maybe, like, adding on to, like, play or a corollary for play, I think the value of a sloppy, like, prototype is just way, way, way undervalued. I find myself, like, because I like to write good code, and you know what I mean? And I don't like people dogging me out, you know, pull requests, you know? Because, like, I did something sloppy, and I'm just like, all right, I like, you know, I have a tendency towards golfing, you know?

But there's a lot to be said for just going out there and, like, just rip and run. And just make it fast, and ugly, and nasty, and just make it work by any means necessary. By any means necessary. Do things you know are wrong. Just like, yeah, this is all one function. Yeah, that's right.

MIKE: [laughs]

WILL: Psychometric complexity who? Get it. Like, we're doing it all. And then, like, you know what I mean? And then when it's done, like, I find, like, because again, like, I don't like thinking really hard. And it's a whole lot easier to look at, you know, an ugly, finished, working piece of code and look like, who wrote this? What idiot excreted this thing? You did this wrong, and this wrong, and this wrong, and this wrong, and this wrong. And this should go here, and this should be a class. This should be in a module. What are you doing? You know, like, that's easy work. Like, I find it effortless to be a hater [laughs]. And so, you know, just slap something together and fix it in post. I know that's, like, I know that feels counterintuitive to most people.

DAVE: Does it?

WILL: But, for me --

DAVE: Because what I just heard you say was get to green fast and then refactor.

WILL: Exactly.

MIKE: What I heard, like, I've been working with one of my kids through an English class, and he was assigned to write a first draft and make it sloppy [laughs]. He said, "Don't worry about grammar. Don't worry about making it pretty. Don't worry about what order things are in. Just get it out there."

DAVE: Yeah, I'm trying to teach you the process. Stop trying to produce a perfect document because you've got a way of generating that document implicitly without thinking about the process. And that means you are end-running the process to generate the document. I need you to stop generating the document and focus on the process. I may have had that conversation with another programmer recently, so I'm a little head up about that. Now, do it to hear…Okay, yeah, yeah. No, come back. Stop jumping ahead.

MIKE: You know, that first draft lets you start putting in that criticism. It's a whole lot better than having nothing to criticize. You may have your beautiful opening sentence. That doesn't get you very far. You can get a whole lot farther with a working product that you can then tear apart and put back together pretty.

DAVE: There's a million perfect sentences. And if you haven't figured out what the story is about, you've got a one in one million chance of getting it right. It could be a perfect sentence. It could just be the wrong one.

This goes back to that idea of the waterfall. You run the risk of working your way all the way up the ladder to discover that you built it against the wrong wall. And you don't know until you're at that top rung because it doesn’t work until...you can't even turn it on until you've got that last piece plugged in.

MIKE: Wasn't it a long-running joke in the Peanuts comic that Snoopy was writing a novel?

DAVE: Probably.

MIKE: And he had the opening sentence, "It was a dark and stormy night," and never got beyond that [laughter]. I think that strip was out for decades, and I don't think he ever got beyond the first sentence.

DAVE: I don't think so.

MIKE: And it was a perfect first sentence but didn't have the story. So…Go ahead.

JORDAN: I think this sounds similar to my personal experience of working on projects. Like, I know that I should be following...They tell us in school that you should be following best practices and doing things the right way. But when you have an idea, and you have motivation, and you're doing it slowly by following best practices, sometimes you just lose that motivation. But you have a perfect start, but you don't have anything as a result.

It goes back to your goals and pros and cons. If I have this motivation, and I make it quick, but it doesn't look the greatest, or it doesn't follow the best practices on readability and stuff, at least I'll have something, and it's there. And I think it's a lot easier to go back and fix it rather than continue trying to build something perfectly, so…

KYLE: You just described an MVP that they decided to ship to production [laughter].

DAVE: I would sometimes call that the triumph of YAGNI, where you'll come back to some code, YAGNI is Y-A-G-N-I, You Ain't Gonna Need It. And, basically, it's just pull yourself back a little bit and say, don't write a solution to tomorrow's problem. Trust tomorrow you to do that.

And so, sometimes I get into code, and I'm like, this whole thing is missing. I'm supposed to be adapting this, and the code to support it is gone. Who wrote this crap? Oh, the person who wrote it didn't need this piece. And thank God they didn't write it because it was factored differently than the way I would have needed it. This is not a stupid oversight or omission. It feels like a stupid oversight or an omission, but it's not. It's a triumph of the principle of YAGNI because you've left me clean field to build what I need to build. -

JUSTIN: Then you look at the blame history, and it was you. It was you.

DAVE: Oh, it's always me [laughter]. The call is coming from inside my own head, absolutely [laughter]. I have started...I've said this, but this is genuinely a sentiment I've experienced. I have started trying to be kind to future me when I write code. That's an actual thing I try to think of, be kind to future me. And you know what I've discovered? I've discovered that past me has started being a little bit less of a butthole when I'm working on my code. It's the weirdest thing. I have no idea what future me thinks about it, but past me is getting nicer and nicer. I'm actually enjoying it.

JORDAN: I feel like best practices, though, like the idea of best practice is to be nice to future you. So, like, I guess it depends on, like, what kind of practices you're following. But, in my mind, best practices is to make it easier for future you, even though, I guess, like, the whole point of this discussion was, what is the best thing to do in the present? So…

But it's the recurring theme that we come back to. If it's not simple, then you're probably doing it wrong, like, that should be your guiding principle. Make things easy on future you. And you only make an exception when you have to. There are times when that's right. You may have a performance reason you need to do something. Building a sophisticated caching system is a nightmare, but it solves a lot of problems, and there are times and places. But avoid it until you have to. I think that's a good place to leave today.

DAVE: This was awesome.

MIKE: Make it easy, unless you have to, and, you know, clean up if you can, if it's important.

DAVE: I would add, consider...make it easy on future you. But from time to time, think about how much it hurts right now and ask yourself if it's because of the thing that you did to make it easy. Sandi Metz gave me some advice about do this thing and then stop. And I got to that point, and I knew it needed to be refactored, and I spent two hours refactoring it.

Then she said, "Great. Can you understand your code?" And I went back and realized that after that stopping point, everything I did just added ceremony and unreadability to the code. And it was all what I thought was best practices, and I realized this was dumb. I should have been asking myself if I can understand this.

MIKE: Great. I think it's a perfect place to end. Until next time on the Acima Development Podcast.

In this episode of the Acima Development Podcast, Mike kicks things off with a cycling story that serves as an analogy for problem-solving in software engineering. Planning a long ride to Illinois’s highest natural point, he had to carefully map his route with handwritten directions before realizing he could quickly write a small program to calculate distances. The story highlights how coding, even outside of professional contexts, provides practical tools for organizing complexity and solving problems efficiently. This segues into the episode’s theme: the value of side projects as creative outlets that both challenge and refresh developers beyond their day jobs.

Dave picks up the discussion by sharing his own side projects, ranging from building automated tools for games like Minecraft to recursive Sudoku solvers. He describes his habit of scripting repetitive tasks at work and how tinkering with small, often quirky coding challenges keeps his skills sharp. Will chimes in with his perspective on solving Sudokus using deduction instead of brute force, sparking a lively debate about problem-solving strategies and approaches to recursion. They also discuss playful experiments like writing adventure games in SQL or porting Doom into Postgres—projects that might not have practical business value but showcase curiosity, resilience, and creative problem-solving, traits they argue are vital in startup or complex development environments.

Later, the conversation broadens beyond coding to explore balance, curiosity, and learning from outside experiences. Will reflects on being new in a role and choosing not to code outside of work, instead focusing on absorbing context, leadership, and finding inspiration in non-technical pursuits—whether it’s parenting, reading fiction, or woodworking. Dave shares his experience building cigar box guitars, while Mike recalls colleagues whose hobbies, from rose gardening to counseling, enriched their professional lives. They conclude that having creative or restorative pursuits outside of work—whether technical side projects or entirely different hobbies—ultimately strengthens problem-solving skills, resilience, and perspective in software engineering.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. Dave and I are going to do kind of a joint hosting thing today.

DAVE: Hello.

MIKE: We've got Dave Brady here, and we've got Kyle, and we've got Will Archer. Actually [chuckles], we've got the Archers [laughs].

WILL: No relation.

MIKE: [inaudible 00:00:37] relation [chuckles], Kyle and Will. But the four of us are here today, and I'm going to start with a story.

As Dave and I were talking, we were kind of debating on the pre-call who was going to host today. And we're both going to do this, but I've got the story. I've got the story. So, that's [laughs] why I [inaudible 00:00:57]. I have mentioned before that I've done a lot of cycling. I won't go too deep into it. I've done a lot with my kids, which has actually helped strengthen me. And, occasionally, I've gone out solo and had these great, long rides.

I went on a long ride a couple of weekends ago. And the ride itself is not where I'm going here. But ahead of the ride, I needed to find out the route. I was planning a new way I'd never been before. I went to the highest point in Illinois [laughter].

DAVE: 12 feet above sea level?

WILL: 13, baby. 13.

DAVE: 13?

MIKE: Okay. So, I misspoke. I went to the highest natural point in Illinois. The highest point in Illinois is not actually a natural point. It's the top of a high-rise in Chicago.

WILL: Is it a tower?

DAVE: Like the Sears or whatever, yeah.

MIKE: Yeah. It’s now called the Willis Tower.

DAVE: Is it still --

MIKE: It's called the Willis Tower.

DAVE: Willis Tower. Is it still the tallest?

MIKE: It is. But there is a...the highest natural point in Illinois is called Charles Mound. It's 1,235 feet, which my house is about 800 feet, so it's not that much higher. Except it's a ways away, so it's more about the distance.

Okay, I'm going to detour slightly. It actually is relevant here. It's in a part of the Midwest known as the Driftless Area. That's sometimes just called driftless. They could put different words after driftless, but driftless is the key word. It was unglaciated during the last ice age. So, unlike what you'd normally think about as the Great Plains, which are made by glaciers scouring everything flat, it is not scoured flat, and it is actually extremely hilly, not mountains, but exceptionally hilly [laughs].

And this high point is actually just, like, a half mile from the Wisconsin state line. Wisconsin has this as well, this very hilly area. And there's rivers that cut deep canyons in between high hills on both sides, hundreds of feet high.

And to get there [chuckles], I had to wind away through back roads through this hilly area, which means that there were a lot of turns. And if you ever tried using Google Maps, it only lets you get to, like, 10 steps along the way, and then it just bails. Like, nope, that's all you can do. And so [chuckles], that wasn't going to work. I actually did it in sections, and I carefully wrote down the turns and the distances between each one of them in a document. And I built this all out in just a text document because I'm a software engineer. That's what I do; I write it out in a text document.

And [chuckles] I got through it. And there was one point there was an alternate. I wasn't sure if I was going to be able to go [inaudible 03:39] because it was just, like, a farm road, literally through a farm. But there were no signs posted, and Google said to go that way, and it was actually in Google Maps with Street View. I'm like, okay, well, I'm going to do it, and I did. It was beautiful, by the way [laughs], and it was fine. Nobody yelled at me. I wasn't sure [inaudible 03:55] way.

So, you know, it was a text file, but there was some weird stuff in it. I got through it and said, okay, so how many miles is this? And [chuckles] what am I going to do? Hey, I will just write some code, so I did. I pulled up a console, and I had my answer in, like, three or four minutes. I had to do a little bit of cleaning to sanitize some of it, remove some of the stuff, and put it all together.

And it reminded me just how useful code can be. It allows you to do amazing things to solve problems. This was something far afield of normal software engineering work, and it still ended up [inaudible 04:33]. I'm going to use code as a tool here, and it allowed me to solve the problem quickly. If I had tried to add that up by hand on a calculator, I don't want to think about that. Maybe I could use a spreadsheet, right [chuckles]? But then I would have to deal with all the edge cases in there because there's the alternate routes that would have been a pain. Pulled it off quickly just by writing some code. It's an amazing tool that helps us in many things.

And today, we're going to be talking about our side projects. Normally, we talk about our day job, but we thought today we'd dig a little bit into the things we've been working on outside of work and how that's going. And it gives kind of some context to our day-to-day because these side projects tend to be weird [chuckles]. They’re the miles that you get to a high point. They just are way different than your normal work, which makes them fun. It breaks up the monotony. There's my story. And I've got a couple of other things I've worked on recently that I may bring up, but I'm going to start with that. Dave, over to you.

DAVE: Well, I don't want to follow up story time with Uncle Mike with story time with Uncle Dave, but here we are.

MIKE: [laughs]

DAVE: So, I'm constantly writing stuff. My career hack for people is, if you have the time, which most people you got to decide. We all get 24 hours a day. But I no-lifed programming for most of my 20s and 30s. I would go to work. I would work all day. I would go home. I would keep writing code. And insert story about mental health here. Work-life balance was something for other people to do.

And what I found is that there's not a problem...there's not an interesting question that I can come up with that I usually can't immediately think, I wonder if I could solve that with a computer? Off the top of my head, without going into full-on stories, although I might tell the clicker story because we can talk about AI for research as part of writing custom stuff.

But in the last 30 days, I have worked on a planner sheet thing that literally people listening at home won't be able to see this. But if you've ever looked like a Franklin-type, you know, day planners, that kind of thing. So, I figured out how to make a program, draw it out, fill in all the dates and times, and send it off to the printer. I built an auto clicker for Minecraft because I was AFKing and needed resources.

The other weird one, and this is harder than it sounds, or no, this is exactly as interesting as it sounds, is trying to calculate the cost of a recipe in Minecraft. If you want to build sticks, right, you need two boards to build four sticks. But to get two boards, you need one log, and that makes four, and there's, like, surplus numbers. And if you want to build, like, some of these late game, really complicated things, you can have these build palettes that are, you know, with thousands of blocks that you have to know what you need.

And normally, we just stand next to the crafting table, next to your inventory, and just pull what you need and build the next piece. And you just keep, do I have what I need? And on the other times, sometimes I'm like, no, I want to know how many, you know, how many chest full of, you know, cracked bricks do I need to have ready to go before I start this?

And being able to say, “I want three of these, but it's made up of this many of that,” you can see very quickly, like, this nested hash of, like, the dependencies to make this item requires these things. And they require this, and they require this. And it's just algebra, but it's tedious, and that's what computers are great at. Computers love tedium.

And there's half a dozen other things that I've written. Some of them are work-related. Like, I will...if I do a thing in git more than three times in a day, I'll start thinking about, do I want to just wrap a script around this, or do I want to keep this memorized? So, I'm constantly tinkering with things. Games as well.

I think you were saying...you said Sudoku puzzle. Did you mean programming is like a Sudoku, or do you mean writing programs to solve Sudokus? Because that was a very fun thing that I did about 15 years ago. James Edward Gray used to do, oh, it was to sit down and write some code in an hour. I'm blanking on it, Ruby [inaudible 08:46]? I'm blanking on the name.

But he would do this thing every month, where it's like, here's a programming challenge. It should take you about an hour. And son of a gun, he said, “Write a program to solve a Sudoku. It should take you about an hour.” And I'm like, what? That's nutso. And now I might be able to, but back then, it took me, like, two days to write the thing. And--

MIKE: So --

DAVE: Yeah. Sorry, go ahead.

MIKE: Sudoku comes in multiple flavors. The simple case, I did this probably more years ago than that. Simple case is easy, but there are some of them that require backtracking, where it's not fully specified. So, you have to start branching, and it gets a lot more complex.

DAVE: I have written a recursive solving solution that I now have a repo on GitHub just called Game Players, not Game Playing, but Game Players. And it's programmed to play other people's programs. And the pattern emerged very, very quickly of, here is the board. Here's the thing in it. What are the legal moves? Can I make one? What state does the board go into? Now recurse, and keep going until we...if you can exhaust all the moves out of the board, then great.

WILL: I see, like, I don't know whether I buy that sort of you need to backtrack problem. How I always solved Sudokus, in my general case, was always a little bit of a dynamic programming approach in that I would say, all right, here is the...so, I would create a board, create the blank board.

And then I would say, okay, so, for every cell, I've got a set from 0 to 10 that could be here, and then I would just sort of start adding things in. And then that would populate the board, and then I would eliminate the set. I'd be like, okay, nobody else can be a 1 on this row. Nobody else can be a thing. And then I would just finish that, populate that whole thing. And then I would go through the things until I found a...what do you call it? Something that there would only be one thing, and I’m going to put that in. I wouldn't even need to backtrack because like --

DAVE: What do you do if you put a 1 in the top-left corner, and then build out the rest of the board and find out that the 1 isn't correct there, and you have to go back and start over with a 2?

WILL: But that's not possible. I would never put...so, it's always a matter of...it's always a matter of you never make an illegal move.

DAVE: Oh, okay. You're writing a thing that actually does the deduction. Yeah.

WILL: Yeah.

DAVE: Mine was just a brute-force solver, just throwing numbers at it until something drops out.

WILL: That's probably faster to write, you know.

DAVE: The deduction would probably be a lot more fun to write though because then you'd get to understand what are the rules to it. What are the second-order implications?

WILL: So, you just muscled it through, huh?

DAVE: Yeah. And once you start seeing every problem looks like recursion, then everything is a smashed thumb. That's a terribly mangled metaphor, but yeah. When the only tool you have is a hammer, you're going to smash your thumb a lot. And so, yeah, I will approach things in terms of can I make a board out of it? Can I determine what the legal moves are? And does the legal moves reduce the solution set? If those three things are true, that is the definition for recursion will work here.

And in late game, I started reaching for recursion first because I had the board set up. I knew all I have to do is fill in this method, and give this a loader and a saver, and I'm good to go. And down the road you go, and it's crazy, so...

WILL: Interesting.

DAVE: But yeah, deducing is also a good one to do as well.

WILL: It seems more efficient. I don't know. I'm not an animal, just, like, hit it with a rock until it stops moving. All right. That's...okay. I went to school for this. I'm not going to like -- [laughs].

DAVE: I dropped out of school for this.

WILL: Yeah, well [laughs]. Interesting. Interesting. Sorry, I guess it's, like, you know what I mean? With, like, grad school, I spent my time working on sort of deductive decision trees for other things. So, that's just sort of, like, a...oh, well, that’s obviously what you would do [laughter], you know? Anyway, so yeah, regardless.

MIKE: Well, there's some sort of tree in that Sudoku solving at work. We're just talking about interesting stuff here, right? But there's...where it's not fully specified, right? Where there is..it's I am ambiguous which branch you have to take. Well, there's going to be some sort of tree structure, whether you're doing dynamic programming. There's different ways of representing that in terms of data structure. But conceptually, there has to be branching of some sort.

WILL: I don't think I’ve ran into that problem. I don't think I’ve ran into a situation where, if I had examined all possible scenarios, there was one where there were two legal moves.

MIKE: Yeah. The worst Sudoku puzzles have that. And that's where it gets...and, suddenly, it's way harder. It's not that hard to write a solver for a puzzle that's a beginner puzzle. But then they start to have those where there's multiple legal moves, and one of them is going to be a dead end.

WILL: Interesting. Interesting. I have to think about that a little bit. I have to think about that a little bit more than I have.

DAVE: Arguably, it's the same solver if you combine the two steps, where the first step is, is there a move that I know I can do? Because why would I guess if I can deduce what the correct move is? And then if you run out of...if you don't have a deducible move, then it's time to start guessing and putting...yeah.

WILL: Oh, that’s fair.

MIKE: Then you get your tree, right? You're going to have to branch down some direction, and sometimes it's going to be a dead end. And dynamic programming can address that, right, if you structure it right because you end up just taking the path that works, but you're kind of going down every one. I'd have to think about exactly how to set that up.

WILL: Well, I mean, basically, you represent the Sudoku as, like, a three-dimensional array, I guess I'd say, right? Like a two by two, you know, by three in that, like, okay, so I'm going to say, oh yeah, I'm going to...Each cell has a set, right, of possible legal moves, right? And so, you iterate down until that set comes to a fixed point, right?

And then if you have a situation where it's like, okay, well, the best I can do is this one has a set of three moves that I could do, right? Then you iterate, and you say, okay, I'm going to say it's one. I'm going to put a one in there, and then I'm going to go through. And then you continue to iterate, iterate, iterate, until you get to a situation where one of those cells has a null set, right, where there's no legal moves.

Like, that's where you know, like, oh, I screwed up. This is not solvable, right? And then you backtrack, you know, until you get to that iterative point. It's like, okay, well, I'll try and put a two in, and then you'll go through. And then like, you know, oh, null set. I failed. And you'll go back, and you'll say, okay, I'm going to try and put a three in. And it will either work, or you'll get a null set, and then the Sudoku puzzle in itself is --

MIKE: Is invalid, right [chuckles].

WILL: Is invalid, right?

MIKE: And interestingly, you're talking about two broad approaches. So, Dave, you’re like, oh, I'm going to do recursion, and you're going to come up with an iterative approach. Two pathways that diverge but end up in the same solution.

DAVE: Awesome. Years and years ago, I was goofing around with somebody, and I'm like, “I need to drop this table.” And I wrote drop table, and I hit Enter. And somebody responded with, “You dropped the table. There is a table here,” like the old Zork commands, like the old text adventures where you pick up the sword and take the lantern and go explore the cave.

And we giggled about this, and I joked, and I said, “You know, PSQL or PL/SQL is Turing-complete. You should be able to write an adventure game in pure SQL.” And everyone was like, “No, it can't be done.” I'm like...So, I wrote one to win a bet, and it was just fun, and stupid, and silly. And I lost the source code. It was like 2006. I lost the source code to it, and I've tried to recreate it a couple of times, and I just haven't gone off it.

And I was thinking about it a week ago, and somebody said, “You know, there was a guy that ported Doom to Postgres, right?” And I'm like, “No.” And it's for real. Somebody figured out how to get it...It's text. The graphics are terrible. It's ASCII art. But, apparently, it's even got a decent frame rate, and it's a first-person shooter in Postgres in PSQL.

MIKE: Wow [laughs]. I'm not quite sure what to say about that. We're talking about solving problems that don't necessarily need to be solved.

DAVE: And solving them in interesting ways, which then makes it so when I'm hiring somebody, I will ask them, “What are your hobbies and your interests?” And if I get somebody who's weird like this, if I'm at a...I've never hired from an enterprise position where I need somebody who's stable and just a metronome; you’re going to clock in at 8, clock out at 5, get 1,000 lines of code, da-da-da. That's not a good person for that.

But if you've got dragons and you're in startup mentality and you need weird solutions because you have weird problems, I love finding that person. Not because they know how to write Doom in Postgres, but because they know how to look at a tool and go, I wonder if I could turn that around backwards and use it this way and find a completely new way to use it?

MIKE: It speaks to curiosity and play, which are characteristics of somebody who can solve problems.

DAVE: Also, resilience, interestingly.

MIKE: Interesting.

WILL: I like that, right? I like that. And I like to play, and I like projects which reflect sort of, like, tinkerers. But I'm curious if you guys have a perspective on, like, most of my job is just reading other people's stuff and figuring out what the hell you people do. What do you people do?

DAVE: Code forensics.

WILL: There's very little Greenfield stuff. And so, what are good projects that demonstrate...like, honestly, the pivotal requirements around enterprise software development, where you're just sort of, like, groveling through the context, legacy codebases decisions that go years from people who've gone. And they've left their footprints in the fossilized clay, and you have to backtrack through what happened. Which is just a lot of reading code and a lot of patience and grinding through things, right?

I mean, because, on one hand, like, yeah, that's the job. But on the other hand, if you're doing this in your free time, you're a psycho, you know what I mean? Like, what? Was it cold outside so you couldn't catch any small animals to torture and kill them, like, you know what I mean?

[laughter]

DAVE: I can neither confirm nor deny, but if you want to look in my freezer, you're going to need a search warrant.

[laughter]

MIKE: There's a thing online where people will post a picture, and people will try to figure out where it was taken from.

DAVE: Like GeoGuessr?

WILL: Those guys are also psychos or, like, undiagnosed autists.

MIKE: Well, it's relevant here. I heard about...I don’t remember the exact story. This is a few years ago. There was somebody who was lost in the mountains. And his phone was dying, and he managed to post a photo from his location. And his phone died. And whoever got the photo reached out to people online and said, “You know, my loved one's lost in the mountains. What do I do?” And this community of people who locate where these pictures are taken from, found it, and figured out exactly where this person had gotten lost, and that's where they sent the search party.

DAVE: That’s fantastic.

WILL: Wow. Did they find him?

MIKE: They did. They found him. And I believe it was a him, and he lived because of these people.

WILL: It’s always a him [laughter].

MIKE: Off trail, he'd, like, gone down a cliff or something, so he was not where he should have been. But they found him anyway because this photo got posted. But that, you know, talking about that skill, I feel like that specific skill is the one that ends up becoming the most useful for senior engineers who are in the code. What is going on here? Where am I? What is the context, and how do I get here? What's here around me? And, you know, it's in the code. It's not out in the world. But it's that kind of thinking.

DAVE: 100%. 100%. I call it code forensics, where you start reading, and it's text on a page or on a screen in a fixed font, but you can still read other people's handwriting. You can absolutely tell, oh, this was written by that person who likes this particular pattern and likes to name their variables this way. And that means that when they go to solve this thing, they're not going to use this pattern. They're going to use this one. So, I'm not even going to look in this other sort of...or I'll look in the other place, but not first.

I play a lot of Chesterton's Fence with myself mentally. It's like Chesterton Fence, you find a fence in the woods, and it's in your way. Should you get rid of it without knowing who put it there and why? That's the thing. Some people very quickly are like, no, I'm efficient. We need to get this out of the way and get moving. And other people are like, somebody had a reason to put this here, and they went to great effort to do it. Let's find out why.

So, when I see something in code that doesn't make sense, I don't immediately assume that it didn't make sense to the person who wrote it. I start stepping back and going, okay, if you wrote this on purpose, what situation would you be in? And you end up spending a lot of time, like, playing with, like, git blame, looking up old PRs, and trying to see, okay, what problem were you trying to solve?

And I like it when I find some new thing in the code that's like, oh, do I have to follow this pattern? And then I'll git-blame it, and I'll find out that it was, you know, written by a developer in Poland in 2017 and hasn't been touched since. And I'm like, okay, either this code is rock solid or abandoned. And I've never seen this module come up in our Rollbar log. So, I'm pretty sure it's abandoned, but it might not have been. It might have been written two weeks ago by one of our contractors. And so, that greatly affects whether I will make the code match my style or whether I'll make my style match the code.

MIKE: So, we’ve dug a little bit on that playfulness and the skills required to deal with the kind of software, which are not, like you say, Will, they're not that greenfield kind of development very often, you know, it's new on day one and never new again [laughs]. And even after that, you're building within some framework, some context that you have to be aware of.

WILL: I mean, I enjoy... So, I was thinking about this a little bit, right, as you guys were talking about it, like things you’re working on right now. Like, so, I'll be honest, right, like, right now, I am, like, three or four months into, like, a new role, you know, with a new codebase, new tech stack, like, new everything, right? And I'm not coding nothing outside of work. Nothing. Nothing.

And I shouldn't be coding nothing, and, like, you know what I mean? And you shouldn't feel bad about coding nothing because, like, I'm drinking from a firehose right now. I'm, like, running. I'm still, you know what I mean? I can get things done, right? I'm clearing tickets. I'm getting things done. Like, there's all kinds of technology. Like, I'm in meetings, like, all the time.

And I encourage everybody to do this; I'm just, like, writing, like, little notes to myself, like, what is this? You know, like, and it's documented. You can ask people and read about it and just get things going, right? Not that hard, but I'm constantly just, like...And when I get done, you know what I mean, the [inaudible 25:09] free time that I have where I have, like, the ability to, you know, work on stuff, like, I'm not working on code.

And so, these projects you need to be working on don't have to be, you know, [inaudible 25:20] related because, like, I get a lot of inspiration anymore these days about, like, sort of what I'm doing professionally from things outside of work, you know? Because I’m pretty technically solid, you know?

I know my work, and I need to, you know, how does this API work? How does this library work? How does this, you know, third-party service, like, interface with our third-party service? Like, I have things to do. But, like, you could derive a lot of engineering work, and especially when you start getting into, like, interpersonal work and leadership work, and dealing with people. You can learn a lot about management from having kids.

MIKE: Amen.

WILL: You can learn a lot of stuff from reading fiction. Learn another language. Make something with your hands. Make something with your hands that does something, right? Like, just carve it out of wood, chop up wood. Build a deck, you know. There's so many things in life.

And get a good night's sleep, if you find yourself at work, where it’s just like, man, I’m just frazzled all the time, and I feel stupid. If you would like another 3, 20 IQ key points, just 3, get 8 hours of sleep, dum-dum. Yeah, it's just like, oh, today would be a lot cooler if I was 10% smarter, 8 hours of sleep, dummy, you know? Like, don't feel like, I suppose, like, you know, like, we can't all be Dave Bradys who are just, you know, programming freaks all the time. Like, you've got a life, and, like, you should live it, and coming in with a mindset, you know, because there's seasons, right?

Because you'll also find a season where you know everything, and you know everybody, like, every burial ground, every, like, you know, poorly covered, shallow grave, and/or mass grave, you know, in the company, and you know where things are. And you find yourself in a rut and rot, and everything's just boring. I’m just doing the same thing over and over and over again. Well, then it's time to start tinkering. Then it's time to start investing in things.

But like, you know, when you're drinking from the firehose, which we will spend at least half of our time just completely drowning...and do something else. Read a book where there is not a robot to be found anywhere.

MIKE: [laughs]

WILL: Not a [inaudible 27:47] robot. Not a one. You know? Like, write poetry or go geocaching. Do something else. It feels like you're not progressing, but you absolutely are. Doom scrolling on social media probably I'm not going to count that one.

DAVE: Not as good, not as good.

WILL: But you could watch a Ted Talk, you know. Anyway.

DAVE: Learn music would be the other thing. I messed up my elbow, and I could no longer fret. I'd been taking guitar lessons, and I could no longer fret a sixth string. And somebody said, “Why don't you play a cigar box guitar?” And I'm like, that's weird. And to shorten a very, very long story, somebody said, “They're even more fun to build than they are to play.” And I'm like, that's not [chuckles] even remotely possible. And then I ended up building...this is number five. I've built one and a half more since then. So, I'm working on seven right now. And they're ridiculously fun to play.

MIKE: My first boss I had as a full-time software engineer, had a rose garden at home. And I still think that was relevant. And I don't always talk to everybody and know all they do. But a recent person I've worked with does counseling with people who are getting married on the side, right? And does software during the day and this very different thing at night.

I'm building on what you said there, Will and Dave, that it really does matter. Having that other thing improves your ability to do your primary thing because it gives you new ideas.

DAVE: Drastically. Absolutely.

MIKE: I led by talking about that bike ride. I was thinking about this directly relates to software because...very indirectly relates to software. But figuring out how to make that work if you're going to go a long distance is actually challenging. Getting enough sugar that you don't run out of sugar and then have a, not a fall-off-your-bike crash, but a physiological crash where you just can't move anymore [chuckles] is a real problem. And if you don't deal with that, you're not going to be able to do it.

Figuring out your logistics, you know, you need water. And there's challenges in those things that you have to work out. And you have to be very detailed and meticulous about it. And developing those skills pays dividends in the daily job, for sure.

Honestly, my life is, I have not done a lot of coding projects outside of work recently for some of the same reasons. Probably one of the larger ones I did is I redid the...I made an alternate intro music for the podcast using the project we talked about, like, two years ago. It's called Sonic Pi, where you use Ruby to write music. And that's the intro and outro music that we're using sometimes. Based on the original one we had, just mixing it up a little bit. And we said we'd do that, and we did.

It really didn't have anything to do with the job at all [laughs]. It let me try something different, look at things from a different perspective.

DAVE: This is very cool. I'm looking at the Sonic Pi website right now. So, you guys finish the episode. I'm going to go look at some music code.

MIKE: Until next time on the Acima Development Podcast.

The panel digs into the perennial question: how much SQL should developers know? Kicking off with a war story, Mike recounts a hyper-growth phase where ~20 performance issues were fixed—almost all by database changes, especially adding (or rethinking) indexes—yielding order-of-magnitude speedups. The moral: ORMs are great for safety and productivity, but when things get slow, it’s “usually the database,” and knowing how indexes, JOINs, and query patterns work is what unblocks teams. Will adds a blunt rule of thumb: apps are slow because of “bytes on the wire” or “the database,” and you can’t rely on ORMs alone to prevent N+1s or inefficient access patterns.

From Ops, Kyle reinforces that troubleshooting still lands on SQL: monitoring tools can point to hot spots, but root-causing and backups often require direct database savvy. Eddy shares a counterexample: moving search from Elasticsearch to Postgres full-text revealed that a GIN index on a high-churn table actually slowed writes—illustrating the trade-off that heavier indexing speeds reads but taxes inserts/updates. The group also debates concurrency: for most web apps, you can push work “down the stack” to the database and avoid complex threading; true low-latency, hard real-time concurrency is rarer than many think.

Stepping back, the crew frames SQL as a declarative, optimization-friendly paradigm—closer to functional transforms than procedural loops—which is precisely why database engines can do so much heavy lifting. Resources like SICP and Lisp/Scheme are recommended for learning to “think in streams” and transformations. The consensus: programming languages and frameworks come and go, but SQL endures—and senior engineers still write ad-hoc queries daily to answer business questions and debug production. They close with a teaser for next time: a lively debate about testing private methods and how to design for testability without committing “crimes” against your runtime.

Transcript:

DAVID: Hello, and welcome to the Acima Development Podcast. I'm David Brady, your host today. And we've got a fun panel today. We've got Kyle; we've got Eddy; we've got Mike; we've got Will, and we've got Matt Hardy. Welcome, Matt. Nice to see some new people, well, not new, recurring people. We don't have anybody new, new, new, but nice to see the regulars.

Today we're going to talk a little bit about SQL. Like, do developers need to know it, and if so, how much? And this came as a suggestion from Kyle, who works more in ops rather than frontline web dev. And so, I'm very interested in hearing where he wants to go with this. But first, as our tradition, let's start with some story time with Uncle Mike. Mike, what do you know about SQL?

MIKE: [laughs] So, I do have a story, and I was prepared for this. A few years ago, I say a few, at least five years ago, maybe five or six years ago, I was in a big application that was growing up [chuckles]. We were actually getting a lot of traffic where we hadn't been. It's the startup journey, right? And this actually was at Acima, you know, as we were in our rapid growth era, not that we're not still growing, but, you know, back in the startup days.

And it's natural for every application, once you start going through that growth period, like, oh, wait, there's some things that don't work very well, let me say, that don't perform very well, that don't perform very well. There's things that work just fine when you had a data set of a thousand that don't work very well when you've got a data set of a million [laughs]. Things just don't work quite the same anymore.

And so, I went through with the team, and we worked on that for maybe a couple of months. And over that couple of months, we made the application run about 10 times faster, which is a big deal, right [laughs]? That's a major performance impact. I think it was more than 10 times. I mean, it was a big deal. You know, going to 10 times faster has a big effect on your infrastructure, and I think it even went even beyond that.

But I kind of quit keeping track after a while [chuckles] because it's, you know, you start resetting your baseline. Okay, well, we got to go faster than that, got to go faster than that. It’s not the only time I've done this, right? It's just the most recent time that I have fresh in mind.

And one thing we found is...let me say a couple of things. Every single one of the performance improvements we made, except for one, were database improvements, and most of them were adding missing indexes. So, there's a database table missing an index, and, by the way, it's always a missing index. If you have a performance problem, it's a missing index [laughs]; I'm just going to say that, except there was a couple of them that weren't. A couple of them were some kind of weird cases.

There was some really gnarly JOINs. It was running, like, JOIN against 10 things using a lot of LIKE queries. We fixed that one by using an external index, using a reverse, one of those external reverse indexes. It was Elasticsearch at the time. And that made a tremendous difference as well in our database load.

And there was one that was not a database issue, you know, so we fixed, like, 20 issues, one of them wasn't. And it was because there was something that should have been in the database [laughs] but wasn't. There were some permissions that were being loaded really strangely from flat files and weren't being cached, and every request was reprocessing them. And by putting a little bit of caching and changing the processing, we took that from taking, like, half of every request time down to unmeasurable, right? It just went essentially to zero. It was great, you know, app went way faster. Everybody's happy. Everything's wonderful [laughs]. And we work on other problems.

The lesson I learned from this, though, is that, yeah, it's always the database. And here's the critical thing: adding a database index is something that's really, really easy to miss if you don't know something about how databases work. And most of the time, you don't have to think about it at all, except for that time that you do, and it's the thing that matters most. I found that throughout my career, that yeah, it's always a database index [laughs] or something to do with the database because you don't have to think about it except for that time that you do. And if you don't know that time, then you're burned. And somebody who can come in and can fix that can make a tremendous difference in your application.

Oh, there's the story that I was thinking about as we talked about this topic.

DAVID: Awesome.

MIKE: Do you have to know SQL? Well, I come from an older generation, right, where I cut my teeth writing raw SQL. And I thought it was kind of amazing when we started getting ORMs that would do some of that automatically. There's a whole lot of advantages to that. So, you avoid a lot of SQL injection flaws. You probably get better queries most of the time. So, overall, the switch that most applications have made to using an Object-Relational Mapper (ORM) is a great one. But that experience that we got when we had to do it manually is still incredibly useful. And I worry a little bit that the new devs coming in now are not getting that experience that you usually don't need, except for that time that you do.

WILL: There's only two reasons that your app is slow: bytes on the wire, or your database sucks. That's it.

MIKE: Right [chuckles].

WILL: And if your API is bad, it's just because their database sucks. That's how it works, you know. And, I don't know, I love an ORM. ORMs are great. ORMs are great, and I use them all the time. And, like, 99% of the time, it does it every time. But that's why we make our money. That's why AI is not going to come and get me this year. It's because sometimes...if the junior devs could do it, they would have done it, and it wouldn't be on my desk. And, I don't know, like, you've got to run some gnarly SQL.

I'd also say two things: one, it's not like regular programming. It doesn't follow the same rules. It doesn't work the same way. It doesn't work the same way. SQL, if you're writing a for loop in SQL, you’re f***** up. My one F bomb for the podcast. Let me take it early.

It doesn't work like that, right? And it's not that it's inefficient, but it's just it takes a foundationally different logic to it, and it's everywhere. My PM he was having terrible troubles in Jira this week because our team and all of our Jira stories were getting communicated up to management that was saying, like, “Thumbs up, thumbs down,” Roman emperor style.

And this Jira query was screwed up, and I'm like, I don't know JQL, but I know JQL, and let's face it. And I just got in there, and I fixed it. And it's like, it's everywhere. It's everywhere. It's a foundational programming paradigm that is in everything. You want to do some GraphQL? You should know SQL. It goes in everything. There’s all these sort of, like, abstract layer data management things, and they're all heavily derived from SQL because they're solving the same kinds of problems.

MATT: You should know what's under the hood if you're working on the car. Simple as that. And it's really easy, with an ORM, to get in trouble and write a bunch of N+1s if you don't understand what's going on and what's happening under the hood.

WILL: Absolutely. Absolutely. Like, if somebody asked me and they came in and they were like, “Hey, listen, I have time to learn one thing this year. I could do concurrency, or I could do SQL.” I'd be like, “Just save yourself some time and learn SQL.”

I believe, sincerely, that we're pretty close to the level in programming where most developers will never need to know anything about a thread, not really, you know? You've got an async/await. You can run some coroutines, just kind of spawn a job queue, which you can do, not knowing anything about real concurrency. And you can live and die a productive life without having to wrestle that pig. SQL is not that way, though.

MIKE: Agreed. I may have told it before, but the gnarliest problem I ever worked on as a professional developer was a concurrency problem, and it probably shouldn't have been [laughs]. You get yourselves in all kinds of trouble there. And suffice it to say that there was multiple bugs in the library I was using [laughs], and I had to fix them. And solving a problem that is both concurrent and distributed is hard [laughs], especially with problems in the library.

MATT: Yeah, and few applications require true concurrency.

MIKE: Exactly. If that concurrency had never been in there, it would have worked better [laughs]. And it was the wrong solution for the problem. But I use SQL, well, all the time. This morning, somebody said, “How do I get this data?” and I wrote a query for them.

MATT: I mean, here at the company, we have hundreds of services, and I think one or two actually require real concurrency.

WILL: Yeah, I mean, I'd be surprised, like, what services do you have that require real concurrency, like, a web app? Like --

MATT: Underwriting-related things.

WILL: What's that?

MATT: Underwriting-related things.

MIKE: Lots of parallel requests going out to third parties.

WILL: Still skeptical, but I don't know enough about it to have, like, a strong opinion on it. I mean, because, I mean, I'll tell you, like, honestly, like, really how, like, how things work for really real is, like, all that concurrency, like, modern web apps are concurrent as hell, super concurrent. But you know who does it all? SQL [laughs]. Like, oh man, I got all these parallel requests that I need for, like, high-performance web apps. I’m like, oh man, you don’t need all that. Just kick it down to the database. Let them sort it out.

MATT: Yeah, I mean, it's necessary when you need responses from 12 different third parties at the same time, right?

WILL: Nah, [inaudible 11:19] can wait. You just wait them all. Wait on all of them. You don’t need a semaphore for that. That’s like...when I say, like --

MATT: I would argue, Will, that SLAs say differently.

WILL: Naah. No, no way. Not a chance. Not a chance. Like, your performance isn't that good. Like, if I’m going to network stack, my performance...I don't want to say it like thaaat. But, like, so I mean, for background, right, when I'm talking about, like, real serious concurrency, like, what I refer to specifically in my work, right, is that you work on the radio stack, not TCP, not IP, like, bits and bytes on the wire but wired less, right? Like, working the radio.

I also do a lot of, like, real-time audio programming, and that stuff is serious concurrency. And there's other stuff. It’s like async/await. It's okay. I'm going to fire it off on async, and I'm going to wait for it to come back. We'll, you know, join all my promises together, so I have this big chunk. But, I mean, like, milliseconds, like, a millisecond is an eternity, you know, and, like, you know, on the network, a millisecond is almost not even measurable, you know. Anyway, maybe there's something exotic, and if you're not doing, like, high-frequency trading, like, I don't know, probably the technical detail’s not something that's appropriate to get in here anyway.

DAVID: There's a CS professor at the University of Utah, can't remember his name, but the best quote...he was an audio CS guy in the ‘90s back when, you know, a 486 was all you had and, you know, at 33 megahertz grinding away.

WILL: [inaudible 13:06]

DAVID: And a friend of mine was in his audio processing class, and efficiency was the buzzword. And he finally says, “So, I have to do this before the next stroke of, like, sending bits to the sound card.” And the professor goes...I'm sorry, the professor wasn't in audio. He did some audio, and he didn't realize he was talking with my friend about audio. And he looks at my friend, and he goes, “Wait, you're doing audio? You'll have milliseconds,” and walked away. Literally, that is a lot of how concurrency is today, right? It's like, I got a four gigahertz processor. I can chew this elephant from front to tail serially and just take a blocking operation, and it's two, you know, two milliseconds or whatever, and you get through it.

I've had one app where concurrency was critical, and it's anywhere you need to be handling multiple threads of attention live or giving the appearance of live. I wrote an IRC client, so you have to catch keystrokes coming in from the user before they hit enter, so you can't do an input read statement. You have to stroke, stroke, stroke, stroke, and update that. Meanwhile, the server is throwing network bytes on demand at you over the fence, and you can't re-request them, or it's like, you have to handle those network packets when they come in. And that was the time when we had to interleave.

MATT: You just gave me flashbacks.

WILL: Yeah, the battle days.

MATT: I've written a few IRC clients back in the day.

DAVID: Getting off topic, but IRC is what broke me of Python. I was in love with Python. I'd come from Perl, which is super cryptic, and messy, and dense, came into Python, which was clean and beautiful. And you cannot condense it down to a single line. And when you are scripting an IRC client, you have one line to do everything, and that's what pushed me...It pushed me back to Perl and then forward to Ruby.

WILL: Interesting. I don't know, here there be dragons. Don't mess with concurrency. Don’t do that.

MIKE: Exactly. That's the moral of the story.

DAVID: Touching back, though, a little bit, there are times when you have a high-level framework, and it starts acting weird, or you change a feature, and something completely unrelated changes. And if you are very familiar with, like, SQL and how database engines work, that's when you go, oh, we're reading the leases table on a new column. I wonder if it's not indexed because that would slow everything down in this chain, right?

And it's, yes, we do...I'm old enough that I was in the generation of people that had the math teacher that said, “You won't always have a calculator with you. You need to learn your times tables.” Well, I have an iPhone. Well, I have an Android. I've got a computer in my pocket now. You were wrong about that, Mr. Nelson.

WILL: No, he wasn’t.

DAVID: SQL might be headed that way, but right now, you don't always want to pull out your phone to be a calculator. And when you can just look at a website and go, that's misbehaving in this specific way, and I can see through the ORM to the underlying technology, it’s super powerful.

MATT: Well, it provides value.

WILL: Well, Matt brought this up, and I think that nailed it. I mean, in that, like, it's really easy if you're in an ORM to write N+1 queries, right? To write a double-nested loop instead of, like, just getting the whole enchilada.

And I think I would liken it to memory management in that, like, nobody, I mean, much like, you know, much like concurrency, like, nobody's malloc-ing anything if they have any sense in the year of our Lord 2025. But you still need to know how it works because you can definitely leak.

MIKE: It's not that hard to do. Just make a global hash in memory, and keep it persistent.

WILL: Yep. Yeah, man, I have a ticket in my backlog right now, which is, like, go leak hunting. You’ve got to dump that heap. Kyle and I we've dumped a heap or two, you and I [laughs].

DAVID: Actually, that reminds me of something else. We said at the top of the call, Kyle, you live over in Ops land. What are you doing talking to databases?

KYLE: What am I doing? A lot of it has to do with we manage our RDS instances, and it's a lot of the time troubleshooting or backups. Those are the bigger issues. That's kind of where I thought about this topic is because in prior organizations, I mean, older codebases, older companies, they didn't use ORMs. A lot of it was just straight SQL. And so, everybody that I spoke to they knew and understood SQL.

And one drawback that I have seen with ORMs, while they are great, is when you need to get in and troubleshoot and dig around, you need to find the engineers on your team that actually know SQL, because not all of them actually know SQL, in order to help troubleshoot with you, right? There are tools out there that kind of bridge some of the gaps and will identify, oh, you don't have an index or something on your table, which we utilize. We've got New Relics and Data Dogs of the world that kind of help us identify some of those things. It gives us benefits in some areas.

In other areas...I think somebody said, 99% of the time, it's great. And then you run into the 1%, and then you run into an engineer that is not very versed in SQL. Not to say that I'm great with it either, but it does slow down troubleshooting. It does slow down figuring out the root cause of the database problem. Because, like Will pointed out, if your app is slow, the first thing I'm going to is the database. Is something happening with the database, right? Because that's where most of the problems come from. If it’s not the database, it's something like Redis, another pseudo database, or --

MIKE: Another database.

KYLE: Another cache location, right? It's always in these locations. And ORMs make it really easy to develop. They make it a little bit more difficult when you need to troubleshoot. And I won't even say just ORMs, ODMs, too, anything that's doing it for you or helping you without actually teaching you the underlying layer. But, yeah, that's kind of where it is for me.

And even some of the toolings for doing backups, when it comes down to it, we've chosen to do backups with straight SQL. Because this is speaking outside of the ORM, but some of the tooling we have that we've tried it's not as fast, and we've had to optimize with straight SQL commands.

WILL: Well, I mean, I say it's a clutch move that I've run into many, many, many times. It's like, when you push the logic down a layer, if it's things that the database thinks about very efficiently, right, you can push things down to the database because the database has all of these internal optimizations and tools, and it doesn't have to go back and forth. You could skip steps.

And if you can have, I mean, obviously, there's caveats there, but if you can have the thinking happen on the database, you're looking at 10x improvements because databases are optimized to an incredible degree, internally, internally for the things that they think about, right? You would never put business logic in there, but in terms of, like, munging data, it's so much better than, God help you, Ruby [laughs].

MIKE: Well, you say 10x. 10x, that is super pessimistic. Because just making that network call, the moment you make that network call, and we’ve talked about this before, it dominates every other thing by far in that request. Because making that network call, you're going from milliseconds or microseconds to, like, seconds sometimes, right? You can't define that.

Now, it's probably milliseconds, right? But it might be 30 milliseconds or 50 milliseconds, whereas if you're running that thing in memory, we're talking less than a millisecond significantly. And it may be your database. Maybe it's a really hairy, gnarly query, and maybe it'll take two milliseconds in your database. That is still wildly faster than bringing it back into memory on your side, doing everything, and then making a request for every one of those pieces, creating a new network request back to the database. If you are only getting a 10x improvement, you might have done something wrong.

KYLE: I worked with an engineer a while back on card processing. And they needed to do the card processing in a specific time window. And it was one of those things where they really wanted to blame the database, and they really wanted to narrow it down to that. And I got in there, and I looked, and we're sending, I can't remember at the time, but it was hundreds of thousands of requests to this database.

And I got looking, and the highest turnaround time for any one of those requests was about two milliseconds. And it's just like, you're already offloading a ton of work to this database. Scaling this database isn't going to do you any good. We're already executing this stuff faster than it's transferring across the wire. Like, we need to look elsewhere.

But, like, I bring that up in this context just to say, like, yes, databases do handle things really well. And also, like, in this case, an ORM was used, so, I mean, it was efficient. Like, there's definitely efficiencies there and good use cases for sure.

WILL: I mean, sometimes you can flog the database a little bit too much; believe me, I’ve done that play, you know? Can I get a bigger instance? No. Oh [laughs].

MATT: You don’t need to tell us, Will. Kyle and I just dealt with that, what, two days ago [laughter]?

KYLE: Maybe. Maybe.

WILL: Yeah. That's when things start getting really gnarly, when it's like, okay, can I just put a bigger engine in the car? Actually, no [laughs].

KYLE: Well, and it's interesting, too, because it's not even...usually, at least in the cases that I've seen, it's not that the database can't handle it, so the engine is big enough. It just doesn't have enough seats to handle all the connections. In most cases I've ever run into, it's, we're tipping over databases because we're just talking to it too much. We're sending way too many connections to it.

MATT: That was exactly what was happening.

KYLE: I didn't want to throw you under the bus [laughter], but since you spoke up [laughs]...

MATT: It’s okay. I mean, to be fair, I did not write that, but...

KYLE: That's fair.

MATT: But we did get it resolved.

WILL: The last guy out always takes the arrows. It's like, all right, who quit last? [inaudible 24:26]

MATT: Well, I am responsible for the service that was happening, too, so I will take that.

WILL: You will take responsibility for finding the guilty party and seeing that they're punished.

KYLE: Matt identified the dip. It's fine [laughs]. We know who did it [laughs].

DAVID: Fantastic.

MIKE: That's why it's called git blame.

DAVID: Yes.

KYLE: Blame, right?

DAVID: Subversion, the predecessor to Git, had SVN blame, and the author hated that it was such a loaded term, so he added an alias, he or she; I don't know who actually maintains that. They added a praise, and it's just an alias for blank, an SVN praise to see who did this. I don't know if they still have it. I think it got retired because nobody used it. Absolutely nobody is going to Subversion anymore.

MATT: [crosstalk 25:10] uses Subversion anymore.

DAVID: Mm-hmm. While Subversion was still extant, they were like, yeah, nobody is using this. We only ever go to the code in anger.

MATT: It's true. I don't think I ever used SVN praise. I did use SVN blame.

WILL: I don't know. I agree. I agree. We shouldn't have called it blame. But that was probably Linus' fault, and, like, he probably did it for a reason.

MATT: It’s snarky. It's a little funny.

DAVID: Good times. Eddy, I messaged you during the call here. The story that Mike gave us at the top had an interesting phrase in it, which is, it's always a missing index, except when it isn't. And we actually ran into that. I don't want to steal any of your thunder. Do you want to tell the story of the stuff that we worked on with Bill and why we had to do it?

EDDY: Sure. I'm not very inclined with exactly, like, I don't have all the context in what we were running into. I'm not a database guru. But the bare bones essentials is we have a project that's currently leveraging something called Elasticsearch, right? And, historically, you know, anytime we needed to make any changes to it, right, it's brittle in our context. You know, it's always been a little bit shaky, you know, and inconsistent, always caused a little bit of turmoil with experience.

So, we had some time to really research, you know, an alternative, you know, to replace something like that and just sort of bring it in-house. And so, we had some time to look into something because we use Postgres at Acima. And so, it turns out that Postgres actually handles text searching and matching natively, called Full Text Search.

And sort of the way that works under the hood, right, is that it uses a GIN index that gets added into a table, which then passes in a cascading TSVector into any joins table that it wants to match any strings on it. The problem with adding an index to that degree, especially for a table that we were adding it on, was that it had way too much activity on it. I think it was up to, like, it was for every 20,000 inserts, you had, like, 10 times updates [laughs]. So, like, the amount was basically tenfold with updates versus inserts.

And so, what we ended up doing is we ended up bringing a copy of production. I didn't see any of that data, I should say. It was piloted by another database.

DAVID: For DBA. For a DBA.

EDDY: It’s for a DBA. So, I had no access to that whatsoever. The bastion for that individual was only to that one person, no one else. I didn't see anything, so no PII. Anyways, the point is we were able to mimic, quote, unquote, “activity” to what we were to expect to happen in a production environment, but in a lower environment setting. And it turns out that by adding a GIN index with the nature of how that works, right, we actually ended up slowing down the number of how fast that table was able to process connections.

So, like, long story short, I mean, I guess, like, 9 times out of 10, you can say, oh yeah, index is always the way to go, except in our scenario. When we're adding a GIN index, it actually made it slower. So, really something to keep in mind where, like, you do have that really one edge case, right, but it’s not one tool at all, right? Like, you do have to be cognizant of what index you're leveraging, and it can have, like, cascading effects like what we saw, so..

DAVID: Absolutely. The general case of this is that the more heavily you index data, the slower your inserts and updates are going to be because every time you insert or update a record, you've got to go update the indexes, right? The whole point of an index is it's pre-calculated. So, when you modify the data, you've got to go redo the pre-calculation, and that totally makes sense.

I cut my teeth in databases, oh, man, [inaudible 29:25] to SQL base. But the one you might have heard of would be MySQL was where I started. And MySQL, like, 3, 10, 15 years ago, generally, had two types of tables that it liked. One was...and I can't remember what they were called, but one of them was basically fully indexed, and inserts were kind of slow, I mean, normal speed, I guess, because this was the normal type of table.

But it also had kind of like a logging table, and inserts into that table are very, very fast, but you cannot put indexes on the table. You can only read it sequentially. You can read it any way you want. It's just slow because it's not indexed. And so, if you've got, like, an event stream coming off of something, one of these tables is great because you're not ever going to query it in production. You're only going to query it, like, in the data warehouse. And when that happens, then, yeah, strip all the indexes off because that's going to speed up your inserts and your updates.

MIKE: One thing that Will mentioned a while ago is that SQL is very different from other programming. And I wanted to latch on to that a little bit because I think that there's some...I think it has a lot to do with what we're talking about. We don't use it because it's weird, right? And the way that it's weird, I think, is relevant.

So, SQL is declarative; it's not procedural. That is, it's not allowed to have side effects. You just declare the transformations on the data and what you get out, and then your compiler for your SQL, right, does everything. And that may sound familiar to anybody from functional programming, which tries to make the language like that as much as possible because situations where you can just be declarative and not procedural can be optimized like crazy.

And they actually represent what we're doing most of the time as engineers. We're taking data from one place. We're changing it around a little bit, and we're sending it to another place. I mean, that's our jobs, right?

DAVID: Mm-hmm.

MIKE: We grab the data from somewhere; we tweak it a little bit, and we send it somewhere else.

And if you have a language that will only do that, you can have your interpreter for your SQL that will create some really optimized code that will do that, and you don't write the procedure at all. You have no idea how it's working, and you don't have to because you're thinking about relational algebra, and [laughs] how does this work from a high level?

Much like you would do in a functional language, where you're just thinking about the output and the transformations, and you write your code as a series of transformations. You worry about types and about output, and you don't worry about how to do a for loop. And that's usually considered best practices in modern coding is to write your code in a functional style that writes those transformations because it avoids a whole class of bugs.

So yeah, it's weird, but it's good weird, right? Now, it's an old language. It's got some warts, right? It feels kind of old, maybe, but the principles it's built on are solid. You learn the syntax; it works great. And thinking that way is, I think, one of the most important things that an engineer, and I tell this to junior engineers all the time, it's one of the most important things that will help you in writing good code.

If you can think about your transformations as being a series of transformations, well, what's my start data; what's my end data? Don't worry about how it gets there, and then let the compiler or your interpreter do the job, right? And instead of you doing it yourself, you're less likely to have bugs, and it'll probably be faster. Yes, it's weird, but [chuckles] if you can start thinking that way, you're probably going to write your code better anyway.

MATT: Old weird, but good weird. One word, Erlang.

DAVID: Erlang, mm-hmm, getting on the beam. I'm scouring my bookcase from here, and I'm in the middle of moving my office, so I can't find the books that I'm looking for. I cannot recommend highly enough SICP, “Structure and Interpretation of Computer Programs.” This is a free class taught...you can download these online. There's a book for it. This is a CS class. The video quality is terrible because it was recorded on a VHS in, like, 1986. It is old, old, old as dirt. And if you are a web programmer, there is stuff in there that is rocket science world --

I went through the SICP lectures in 2009, and I was furious halfway through that none of the senior developers around me had a clue what was going on in this class. One of the biggest things that they will teach you in that is how to implement streaming, how to think in terms of streams. Instead of in loops or in long blocking things, it's just, what's the next thing, what's the next thing, what's the next thing?

And you have to understand streaming if you want to do work on a collection that could potentially be infinitely long or human input, where it's, like, every keystroke is just a new keystroke, and you can't iterate over every keystroke that's going to be entered into the program before they've been entered into the program. So, you literally just have to sit there and wait for each keystroke to come off.

Handling those streams, because it's from the ‘80s, the same math problems on the same whiteboard drop out when you go talk to the database theory people, as the SICP guys. When they start talking about streaming data out of the system, they're like, “You guys are writing a database engine. 100%, this is a database engine.” Coming back from SICP, the drawback to SICP is it will teach you how to do Lisp. The advantage to SICP is it will teach you how to do Lisp, and learning Lisp will make you a better programmer, I promise you that.

MATT: 100%.

DAVID: I don't know a single programmer who has learned Lisp who has not 100% agreed with that statement. It will make you a better programmer.

So yeah, Structure and Interpretation of Computer Programming. And if you want the light version, “The Little Schemer.” Scheme is a dialect of Lisp. You can get it on your computer right now. It's free, and you can learn to program in Scheme, which is, again, a smaller dialect of Lisp. And the first time you learn how to write your own multiplier, when the only tools you have in your pocket are add, subtract, and is this number equal to zero? You have no if tests other than is this zero, which is fantastic.

Write the equals equals for a pair of integers when all you can test for is zero. You're going to need a subtractor, and you're going to need a lot of time if the integers are large.

This has been a good bit of chatter. I think we're at a pretty good closing up point.

MIKE: You know, one thing I wanted to latch on to, again, and I think Will brought it up also, as to AI not taking my job tomorrow.

WILL: Not this year.

MIKE: And I alluded to it before. I have, you know, as my career has evolved over the last few years, I don't write very much code anymore, mostly directing things, right [laughs]? I'm moving things from here to there, you know, communicating. But I still write SQL regularly, close to daily. I write in queries because I need to get information out. And they're ad hoc, right? And they're going and pulling out data that other people don't know how to pull out because, you know, they're not sure where the data is, which says something to me. When everything else goes away, what's left is SQL [chuckles] because it endures forever. You know, your career starts with that, and it seems to end with that as well. It is just always needed.

And yeah, you might not need it for every piece that you're writing because the ORM probably should be used to do most things. But knowing that is probably, you know, the most valuable thing I've learned in my career in terms of programming. Other languages come and go; SQL endures.

MATT: I would agree with that. It's been the only thing that's always been there in my career. Tons of different languages, always SQL.

WILL: Like, when I'm cracking up a codebase, right, and I'm like, okay, what are we doing, right? Like, the two things I look for, when I could find them, especially, like, I go to the schema, like, that schema.rb. What's in there? Who was your daddy, and what does he do? And then I look for the API requests. If I've got the schema and the API requests, I know what's going on. And it's usually not that hard to read. You know, I mean, like, you'll have, you know, maybe 50 tables, you know, and, like, you know, 50 tables, and, I don't know, half as many API requests. And if I know what's going on there, like, I got you, you know, maybe for web apps at least, you know.

DAVID: 100%. I had the great privilege of hanging out quite a bit with Sandi Metz, and she's just an amazing programmer and coach. And she's really, really good at teaching people how to think, which is so much more rare than being able to think. She can teach thinking, which is incredible. She and I were chatting at a conference, and I was talking about, like, things that change over time. And we got to talking about databases and ORMs, and she said something really interesting. She said, “I've never seen a company evolve its database stack,” like, moving forward.

And I thought about it, and I'm like, have I seen...and what she said was, “Your tech stack will change. Your database will live forever.” One day you're going to wake up, and somebody's going to say, “Let's get rid of Ruby on Rails, and let's switch everything over to Groovy,” and it'll be a three-year project, and your tech stack goes away.

I have migrated databases under the same tech stack, but they have all been the same migration, which is migrating to Postgres away from a very expensive vendor lock-in, like SQL Server, or, you know, one of the big, big, big, big expensive ones. That's the only time I've ever changed database flavors mid-roll on a serious production system.

WILL: Yeah, I was going to say that is why I think many developers of our vintage have an almost pathological aversion to that one database vendor.

MATT: We all know what you're thinking [laughter].

WILL: And if you know the one, you know the one. And if you don’t know the one, it's because whoever raised you [laughs]...like, we don't say that word out loud, like, Voldemort [laughs] for developers that were like...

MATT: I have a friend who's very high up at that company.

WILL: And I think that [inaudible 40:37] a whole lot of money.

MIKE: And if only there was, like, a really wise person you could...I was going to say, if only there was, like, a really wise person who [inaudible 40:43] you could go talk to and ask this question to, that would be really helpful.

DAVID: Sandi is incredible. She is the first person that...Mike, you said something earlier. You said, always, always, always accept when you don't. And she and I were at loggerheads over, do you test private methods? And we went around for, like, 20 minutes. And then, by the end of it, she went, okay, yeah, never test private methods unless you want to, and then test them as much as you want. Because she had found the edge case, right, which, well, what if I really, really want to? And she’s like, if you really want to, go for it. Anyway, that's a side ramble. That's a P.S. for the podcast. I think we’re good.

WILL: Wait, so are you on team test private methods or team don't test private methods?

DAVID: I'm on team never write private methods, ever. So, testing...

WILL: What?

DAVID: If you've got a private method, you have logic that could break and should be tested. But you've put it deliberately at an impedance mismatch to the stuff that you're testing. And you probably have a better...you have a public class hiding inside that class that if you just name that thing, that becomes a private class. You pull it out. You make it a public class. Those methods will become public. And you guard access to that privacy by making that class private in the class that wants to use it. You're making your poop face. I love it.

MATT: Sounds like we have the topic for our next podcast.

Mike: [laughs]

DAVID: Oh, we could do a battle royale on testing private methods or not, absolutely. Because there's a... I've been very dissatisfied with all three positions. So, I don't actually have a, what do you call it, I don't have a sacred cow in that hamburger factory.

MIKE: I've got a strong stance on testing in that it doesn't matter whether you have private methods or not. Because if you write your tests right, you're just following every branch of logic, of input logic. What are all of the different types of input that you have that could be branched on in the code?

WILL: I've existed in ecosystems where testing on a public-only policy requires some crimes against God and man in terms of manipulation of mocks, and run time, and stuff like that. The big, ugly one is React, where there isn't a direct run loop input-output. If you're dealing with sort of like, hey, if I do this, what's the UI going to look like? Am I going to see all these elements the way I want them to? Which is obviously a test that you would have an interest in writing. But you have to commit crimes against God and man to sort of force that run time and then loop to arrive at a sync or a fixed point or whatever. So --

DAVID: Cool. Will, let me put a pin in that for our next episode, because we could go another hour real easy because I'm ready for this. This is awesome, so yeah.

MIKE: So, we've got the teaser for the next episode.

DAVID: We’ve got the teaser for the next episode. Fantastic.

MATT: And it won't get heated [laughter].

WILL: Horrors of testing.

[laughter]

DAVID: It won't get what?.

MATT: I said it will not get heated.

DAVID: Get heated. No. No, we're all friends here, so...

MATT: It’s true.

DAVID: Fantastic. Yep. Thank you for listening to the Acima Development Podcast. We have been Acima Development. And, Will, you’re honorary. You're an alumnus, so...

WILL: And also Will [laughs].

DAVID: And also Will. There we go. People we love and also Will and...so, thank you for listening.

WILL: [laughs]. Acima [inaudible 44:16]

DAVID: Yes, I like it.

The episode frames engineering as an investment rather than a cost. Mike opens with a parable: leaders who put capital (or engineers) to work create value; those who “protect” resources without progress destroy it. The panel builds on that: impact comes from choosing work that improves tomorrow—planning enough to ship, avoiding ivory-tower perfection, and recognizing that “cheap” talent can be expensive in management bandwidth. Good contractors and senior ICs pay for themselves by shipping and by freeing organizational attention.

They dive into technical debt with a pragmatic stance: prefer YAGNI, refactor when the change is hard so the right change becomes easy, and pay down debt “as you go” when you trip over it. Treat debt like a family credit card—budget a consistent tithe each sprint for the top, highest-leverage items and let the bottom 10% freeze or die. Too much debt maxes the card; you end up servicing interest (slow teams, broken features) instead of building. For growth and product strategy, pursue small, adjacent bets that serve existing customers and reduce risk rather than sweeping reinventions.

A major throughline is investing in people. Effectiveness scales when seniors make others effective: clear plans for distributed teams, social onboarding, and apprenticeship-style pipelines that move interns, QA, and juniors into productive engineers. Pair programming and XP practices are championed as systematic knowledge transfer—training juniors up, spreading domain context, and keeping work flowing despite constant change. The most rewarding ROI, they argue, is the compounding payoff of people who grow, stay, and ship.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'll be hosting again today. With me, I've got Dave.

DAVE: Hello.

MIKE: Eddy.

EDDY: Hello.

MIKE: We've got Will. Yeah, we’ve got Will Archer. We've got Jordan.

JORDAN: Hello.

MIKE: We've got Justin, and we've got Ramses.

RAMSES: Howdy.

MIKE: I'd like us to start off with a story. This time I'm going to go biblical.

WILL: Oh God.

MIKE: [chuckles] So, [inaudible 00:00:51] I’m going to tell an old story in a new context. No religious context, but I think it applies here. So, a boss is going to go on a year-long sabbatical, maybe not that realistic, but, you know, humor me here [chuckles]. And they're going to leave, you know, put some employees in charge. And they're going to put them in, you know, these are, you know, leaders, leaders of the company, and they're going to give one person responsible for 10 million worth of funds, another one 5 million, the third one 1 million. So, they're going to be responsible for some funds here while the boss is on sabbatical.

A year later, the boss comes back, and she asked each of the employees how things went. And the first employee, well, they've hired a new team, and they’ve built a new product that's going to bring in $10 million a year. So, "Well done," she says. So, the second employee has invested their millions in acquiring a small dev shop, brought them in, and they've increased the size of the dev team. And they expect that to contribute to $5 million in projected annual growth. So, "Well done," she says.

So, the third employee let go of some of their developers because they wanted to save their money. They wanted to make sure...I've only got a million dollars. I got to make sure that it stretches for this year. Customers are complaining because now there's not the support on the product. The product's been losing users because everybody's complaining. Reviews are going down online. And the boss says, "You know, why didn't you invest the money? You could at least put an investment account. You just sat on it." And the employee says, "You know, I was just scared to lose the money. So, I made sure I kept it all." The boss says, "You're fired [laughs]." And she gives the money to the first employee.

So, we hire engineers as an investment, right? Engineers are builders. And we build stuff because it makes companies money. You know, we're doing this on our own. We do it because we're trying to make money. I mean, we enjoy the job, but the reason that we get paid is so we can make the company money, and I think it's critical to remember that. Every minute we spend is an investment. And is it a good investment [chuckles]? Was it worth investing in us? When we get to next year, is the boss going to look at us and say, "Was it worth having them as an employee? Did we actually do better because of that?"

And it also affects the way that the company sees the engineers. There's sometimes a mindset where we're seen as a cost, just net cost. Like, "Oh, they're just the cost we have of doing business." And I think that's a dangerous way to think because it doesn't appreciate that you've got to spend some money or, you know, I got to put in some risk to make money. Money doesn't just come walking in the door. It happens because you've built something and maintained it.

So, in the broader picture, I'd like to talk, for today's discussion, I'd like to talk about what it means to treat ourselves as an investment and what that means for engineering. Go ahead.

DAVE: Can I jump on a tail on that?

MIKE: Please.

DAVE: I love when ideas from very far apart in my brain snap together. It's a psychological thing called synthesis. And you just synthesized this thing for me, which is, are we investments, or are we a cost?

And I took a financial literacy class 25 years ago. And the guy stood up and he said, "Do you have any assets? And what do you have are liabilities?" And we all started going through all the things. Well, I've got assets. I've got a car. I got, you know, and we just started listing all the things we had. And he's like, "Every single thing you just listed is a liability, not an asset." I'm like, "What are you talking about? My car is an asset." He’s like, "Is it going up or down in value?" "Oh, it's going down. And you had to pay for it." "Yep." And it doesn’t make you...well, I mean, it gets me to work. Okay, that's an investment. That's something you have to do. But you can't sell that car for more money than you had it. It is not an asset in and of itself. You can use it. And it's good, but it is not an asset.

When you acquire a company or you're in a company that's getting acquired, the first thing management does is say, "Nobody leave," right? "Here's the retention bonuses. If you stay for the next two years, here's this." Why? Because you are an asset. You increase the value, and your continued presence here continues to increase the value of the system you are in.

So, anybody who thinks their employees are a liability...you can point at a specific liability or a specific liability and call them an employee. That's an interesting wording, but you get what I mean. But that's like a onesie-twosie that the job, when an employee is a liability, is because they are failing to be the asset that you need them to be.

WILL: That wasn't my experience, but that's a tangent.

MIKE: So, well, what's worth investing in? If we are assets, if we're worth investing in, what is? What should we actually be investing in? Because there's a lot of stuff you can do in a day. There’s choices. That's a broad question, intended to be open-ended.

JUSTIN: [laughs]

DAVE: I think on our last podcast, I mentioned the generic advice of prioritize later. And anything you can do now to improve tomorrow or improve later, I think, is a great way of an asset. And so, that's a very generic answer to what should we do as employees, but that's the thing that I try to do. I try to look at, like, where does it hurt the most, and what can we do about it?

MIKE: So, where does it hurt the most?

WILL: The question I've got, right, is, like, sort of, like, in what context, right? I mean, sort of, you know, as an individual contributor, like, I manage a department of one, right? You know, so I have things that I need to be doing, right? It's all good, you know? And so, you know, my discretionary spending, right, is limited, not zero, right? Because there is lots of interstitial time that I'm waiting for something, right? You know, like the factory is idle for whatever reason. It’s just sort of, like, move up the ladder, right, as your scope gets larger, like, that sort of time, like, you know, the latitude you have to make decisions gets bigger. And so, I guess the question is, like, who, right? Who would be investing and, you know, what?

MIKE: Well, I was thinking about this before the call as well. It also depends on the scale of the organization you're in. If you are alone, if you're the startup, you know, investing in yourself, building a new product, what matters probably is very different than if you're on a team of 50 or 100 or 1,000.

WILL: What if you're a startup and, like, you're not, you know, like, if you're not generating a profit, everything's an investment, isn't it? You know? It's a thing. I mean, like, you know what I mean? Like, you're building something, right? Like, the investment is fairly direct and, like, unambiguous and kind of cut and dry.

MIKE: But you can go for some perfect ivory tower implementation that's going to take you 10 years, and you don't make it to market before you run out of funds. So [laughs], I think it does matter. I think when you're that startup, you need to have a goal of getting in money fast. It's very sink or swim. Like, you need to prioritize, and you may make some cuts that you wouldn't do otherwise.

JUSTIN: So, I think it goes back to a little bit what you mentioned right there, Mike, is, like, you've got to plan, or you've got to have a plan. And if you don't have a plan, you have no plan. And so, whatever you do may not fit within that overall plan of making sure that I get paid tomorrow, next week, and, you know, next year. So, time spent planning, I think, is, you know, you don't want to do too much. But it usually pays off in droves.

DAVE: When I was a contractor, I always had to consider, when this contract ends, I will go back to the sales cycle, and you don't get paid for sales. That's a pure investment in speculative opportunity. And I get where people are like, "Well, your hourly rate is really high." And I'm like, "Yeah, because you're hiring me for a very short contract." And they're like, "Well, we only need you for this time." And I'm like, "Yeah, and then I'm going to go be unemployed. You understand that if I've got a two-week sales cycle and people hire me for two weeks, I'm unemployed 50% of the time. You're going to pay me 200% of the market value. That's just how it's going to work."

MIKE: Yeah. Fairly typical for contract work for that reason.

JUSTIN: So, talking a little bit more about investment, too, and I'm lucky enough to, like, be hiring people. And, unfortunately, the people I'm hiring are in India. But having said that, the investment that I make is getting up early and spending time with them to make sure that they understand what the vision is and what the plan is. Because I don't see them for, you know, I only see them for, like, two hours out of their eight-hour day.

And if they don't have a clear plan on what they need to be doing, the money that I'm saving by, you know, having people in India is getting thrown out the window because, you know, they're only productive for two hours. So, the time invested in helping other people be successful and helping make sure that they understand what the plan is really worth it as well.

And it's interesting because, like, a lot of this is not, like, coding. You know, this is not necessarily individual contributor work. It's like, "Hey, I need to plan. I need to make sure other people understand. I need to make sure I understand." All of that is very important before you sit down and code.

MIKE: So, you're saying if you help other people be effective by helping organize the work, you've made more efficient use of your time than if you just went in there and tried to build it yourself?

JUSTIN: Yeah, which is rough.

MIKE: Sure.

JUSTIN: Because if I go in and build it myself, I know it's done right. And, you know, I can be the hero because I did the thing.

MIKE: [laughs] Absolutely.

JUSTIN: [laughs] But it’s like one person is doing the thing.

WILL: So, would you say that you're investing in your sort of, like, contract team? Like, you've got an offshore contracting team that you're investing, like, not only in your team, your enterprise, but you're investing in them, right? So, you've got, like, contractors, right? But, like, you're training them.

JUSTIN: Yeah, and, like, any sort of success that I have is dependent on the success that they have.

MIKE: That's interesting, that idea you're exploring there, Will. You're investing in the people. And this is an idea that has come up a lot, I think, on the podcast, you know, people are human. You can't just drop somebody in, "Okay, you're productive, and you'll do this unit of work, and then you're done."

JUSTIN: [laughs]

MIKE: And that's just not how work works. There's that human element that requires the coordination that requires the training. And we say training and some of that is...it's not necessarily, you know, learn this language because that's kind of the baseline. That's the expectation a lot of times going in. It's rather, you know, "Here's the systems we work on. Here's the way we do things. And here's how you can be effective." It's around things that, like you say, aren't necessarily coding although there may be coding style and things in there. It's a lot of bringing somebody into the group.

DAVE: Mm-hmm, social onboarding.

MIKE: Yeah, well put: social onboarding. And that's an investment, and it's...you actually are lowering your return on investment if you think, okay, I'm going to hire these people for one month or two months, or anything less than, I mean, even up to a year or more. Sometimes, you know, I think that productivity is still climbing. We've got contractors I've been working with for almost 10 years, and I would hate to lose that, right? That is a valuable thing to have. We've got relationships, you know, we're friends. And we've got, you know, trust. These people know exactly what to get done, and they do it well. And that matters. You lose that if you just treat that relationship as disposable.

WILL: So, like, what's the con? What’s the flip side of that? Okay, you've got a contractor, right? So, I mean, the contractor and the expectation, I think, that I certainly work under, and I think a lot of people work under, is sort of like, "You're going to get it done. Like, what have you done for me lately," right? Like, there's a level of investment that you don't expect and you shouldn't expect. You shouldn’t expect to get hired if you're not making things happen now, right?

MIKE: Sure.

WILL: We discussed this as sort of like the mismatch, right, between contracting in that, like, a lot of shops can sort of, like, compete on a cost basis as contractors, right, for a job which, you know, if you think about onboarding, right, like, a contractor you're always onboarding. And that’s hard. That's really hard. And so, like, the expectation is that maybe that investment and, like, your sort of technical skill set is priced in already. And it's something you pay...you pay for something if you've already done it, right? Where's that line appropriately drawn?

Because this is also, like, sort of the converse where, like, you have, like, long-time contractors that are employees in all but name. And that's sort of, like, a weird, like, bureaucratic cul-de-sac that commonly people will find themselves in.

MIKE: It's an interesting question, I mean, because you're hiring somebody expecting them to know something [laughs]. Otherwise, you wouldn't be hiring them. So, how much do you invest? You know, how much is it worth investing there? If somebody doesn't really know what they're doing, how much do you put in? And I guess it does depend somewhat on the cost, right? How much you’re paying for it.

I'm thinking about if I was asking somebody to build a house, if I was hiring a contractor to build a house. Actually, earlier today, I was talking to a roofing contractor. My roof is getting old and needs to be replaced. And I did talk to multiple contractors, right? And I compared the price. But I didn't go and say, I'm going to find the absolutely cheapest contractor I can possibly find. And that was a deliberate choice. Because I knew that that would not save me time, or energy, or grief in the long run.

I made sure that the prices weren't way out of line, and it was somebody who was reputable and, you know, local, lots of reviews [laughs], somebody I can go back to six months from now and say, you know, "You messed something up,” and expect them to actually do something about it. Because it mattered, right, to get somebody who knew what they were doing and that I could have some trust in.

On the flip side, I wasn't actively looking for the most I could spend, you know, there's no, like, gold leaf on my roof [laughs]. You know, it's a roof. I needed it to get the job done. And it seems like there's some applicability there. I’d think that going for the cheapest you can possibly get probably is not going to save you money because there's going to be so much investment afterward in making it work. But you probably want to go a little bit higher up that ladder, right, and pay a little more and get somebody you can trust.

And then, you know, maybe thinking about people like engineers, right? Somebody is like, okay, I'm going to have these people with me for a few months. They have some basic competence enough that I can trust them to get the job done if I spend some time. I would advocate for something like that so many times. Go ahead.

WILL: I'll toot my own horn here as a fairly expensive contractor who still manages to get hired on a fairly consistent basis. When I say fairly consistent, I mean I've been overbooked forever, since the dawn of time. But the cost of your contractor is not strictly defined by the dollars that they're charging you because, in all honesty, there is organizational bandwidth that is a zero-sum game. There are so many managers in the company. They can get so many projects done. They have so much attention. They have so much planning. They have so much specking things out. And they can only deliver so many things per year. There's a hard limit on the number of things that they can push out per year, period.

And so, you can say, like, "Wow, you know, this guy's only, like, 10 bucks an hour." 10 bucks an hour at Bangladesh he’s so expensive. Yeah, but, like, he's taking up 20% of your management bandwidth for the entire year. You're not getting anything else out. It's not going to happen. You know, versus somebody who's much more than that, but they'll get it done, and you don't have to worry about them. Like, I'm saving your bandwidth. And that's, I think, a value proposition that most people in the business who have been there for a while understand. And they're like, "Yeah, but he'll do it, and he won't bother me. It'll just happen."

MIKE: We recently hired, I won't give names here, recently hired a contractor to work with a team, local. And he stepped in and immediately started getting stuff done, went and found some organizational efficiencies, called them out, and improved things just kind of from day one. He doesn't know everything, right? You know, nobody's...of course they don't. But they’ll make a huge difference. And I'm like, "Wow, give me 10 more people like this."

Again, not perfect, nobody is expected to be, but knew what they were doing. And I can trust that they'll get the job done. And that was worth its weight in gold, right [chuckles]? Like, [inaudible 19:24] making us money. Absolutely. That ability to get stuff done just is absolutely critical. You can have people who are less experienced, but only up to a certain critical mass. They need to have basic competence, right? Somebody you can tell them what to do, and they'll get it done. But you need to have people who can help direct that, who can work really independently.

Because if you have these people who are less experienced and can't just get stuff done, they reach a critical mass, and then nothing gets done, right? You reach a level of work, and it doesn't matter how many people you hire. You're not going to get anything else done because there's just a lot of people running around and nobody knowing what to do. The only way I've seen things be effective is you have people who really know what they're doing, who can help those other people.

So, Justin talked about working with a group and spending a lot of time working with them, helping them know what to do and keep them going. That gets work done. But there's a limited number of Justins [chuckles], and you have to have more. You have to have enough of those hubs of the wheel to keep those pods moving, or else it just falls apart.

So, we’ve talked some about this balance of getting what you pay for and being willing to invest in people. I'd like to hit a little different topic related to this: technical debt. So, we talked a lot about investment, and then there's the flip side, where you're taking on debt. And you may be taking on debt in order to invest, right? So, you're building something. So, going back to the startup idea, if you don't get the product out the door, you run out of money, and your business fails. Maybe you incur some technical debt along the way. And that might be very much the right decision. You're taking on some debt to invest.

So, if we think about this idea of investing in ourselves, when should technical debt be paid? Where do you balance? Like, I've got this money. Do I pay down the debt or build something new?

DAVE: Mike, all I heard you say was, "It's too quiet in here. Let's start a fight."

MIKE: [laughs]

DAVE: I will say that as I've gotten older as a programmer, I have learned more and more, (YAGNI) You Ain't Going to Need It, right? So, a lot of technical debt came from preemptively trying to prevent the wrong technical debt, trying to build something that it turns out we never ever needed. And we see this all the time. Eddy, you and I have ripped some stuff out this week, I think, that somebody built, and it never happened, right?

There's a thing on our team right now where we had a build-out so that the individual developers could be running Docker to standardize our configuration. And then we realized that we have a service-oriented architecture. You can't run 12 Dockers on a laptop. It's just not going to work. It makes a great lap warmer, but it doesn't make a good development environment. But there was all this stuff to support the Docker initiative that just died. And then that code got maintained for another three years because it's separate. So, YAGNI, YAGNI, YAGNI.

So, as I've gotten older, I've started thinking, when I'm done with something, I will do the refactor to try to clean and make things readable and understandable. But I try very, very hard to never let myself say, "We need to do this for this future thing." I've gotten much, much better at saying, "Tomorrow, Dave can handle that." We all joke, that sounds like a future me problem. No, it really is. This sounds like a future me solution. This sounds like something future me absolutely can handle. I'm going to do stuff today to be kind to future me, but I'm not going to try and tie future me's hands or try to paint the wall that future me hasn't built yet because it's just a nightmare. You end up with a bunch of dried paint in the shape of a house. It's like, how do you put that on?

But if you've got Cowboy Coders on your team, they will weaponize that against you because they will go out and crap out all the technical debt they can to get their stuff done and polish all the rivets they want because they know you are going to come back and clean up their latrine. And I've started fights over this. Legitimately, I'm just like, "Yeah." I have so many metaphors that are inappropriate for this. Cleaning up the latrine, I'll just leave it there. I've yelled at people in this company recently, so...not recently, right? Months ago. I'm much calmer after the sabbatical, so...

MIKE: [laughs] So, you're saying build enough and not more.

DAVE: Build enough...oh, sorry, there's one more instinctive habit that I just realized I skipped over. All of this is enabled by the specific habit of when you get an assignment. I'm a very high-latency developer. You give me an assignment, I'm going to take a while to get started on it because the first thing I do is refactor. I will look at the code, and I'll go, the change you want me to make is very, very hard to make.

Kent Beck, famous quote, if the change you need to make is hard, refactor the code until the change you want to make is easy to make, then make the easy change. So, like, Kent was like, I'm really lazy. I only make easy changes. And then he's like, yeah, I spend most of my week doing the hard work to make the easy change possible. You have to do that. So, it's like, anytime I get a new ticket, I'm like, yep, the technical debt that I wasn't paying off before, I have to pay it off now because now I know where the house is. We have to paint this wall before we cut a hole in it.

MIKE: Are you suggesting that you should pay off technical debt as you bump into it?

DAVE: As you go. As you go, yeah, basically. Because when you bump into it, now you know, I really do need this. You can't say, "You Ain't Gonna Need It" when I'm literally stubbing my toe on it.

WILL: I don't know, I like...like, having done this for a long time, like, I do consider technical debt. Like, the YAGNI principle there I think it has a lot of merit. I personally think you should just...I think you should [inaudible 25:18]. Like, you know what I like? I like to stack rank technical debt. The bottom 10% of the technical tickets, relegate them. Relegate them to the freezer.

So, I think the family credit card is a good analogy for technical debt. I mean, you should have a bunch of, like, you should have a wish list, right? And, like, every once in a while, get your leads together and rank them, you know? Bottom 10%? Yeah, yeah, probably. Probably that's just never going to get fixed, you know? And you should take a certain number of points, you know, maybe every sprint, maybe a quarter, maybe something, you know?

Like, yeah, yeah, you know, the bottom 10% if things have been, like, nah, we don't really care that much, you know? Versus, like, you know, honestly, like, there's stuff that, like, you know, like, people do care about. People will, like, get out and fight for it. Like, that stuff actually matters, like, you know?

Like, one form of technical debt that I've found particularly pervasive is the sort of, like, performance creep on, like, developer workstations as a result of, like, IT overhead, let's say. You know, there's administrative IT, things running on these workstations, which I don't care. You [inaudible 26:42] work my workstation all day, all day, you know? Like, that's no problem. I have a smartphone that I can do all my personal stuff on. It's not a problem.

But performance tends to degrade as more and more things are being checked and exclusions aren't being maintained. And that's the kind of thing where it's just, like, you know, people will rumble with you, but it'll never show up on a sprint. It's just...it's a silent tax across an organization, and that's a little bit of a personal anecdote.

DAVE: I remember talking with Mike a couple of years ago, and I'm like, "I keep getting bumped off the VPN." And Mike said, "Yeah, that happens," I’m like, okay, okay. And I talk...I keep getting...and it was starting to sound like Dave's kind of a complainer. He's constantly whining about the VPN. We all get bumped off the VPN. I got so annoyed one night that I cracked open the laptop. It's like Tuesday night, and I wrote a thing to just check, is the VPN up, and then log it.

And then I came back, and I'm like, okay, I've got this graph. Every 6 minutes, my VPN goes down, and that's a 30-second timeout, and whatever I'm doing just halts. And I go to Mike, and I'm like, "So, should I be losing my VPN 70 times a day?" And Mike was like, "What? No, wait, wait, what?" But the patterning, the social onboarding was my VPN is going down. No quantity information supplied. Everyone else assumed quantity being far, far less. And I'm like, no, I'm not oversensitive. I'm getting my face punched in by this stupid VPN [laughs].

WILL: Yeah, right.

DAVE: We fixed that, and my life got so much better. So, yeah, communicate, I guess, is the answer to that.

WILL: Oh yeah, well, exactly. I mean, it's just, like, you know, just, like, tithe, you know? Just pay your tithe to the tech debt gods and, like, rank them and relegate them, you know?

MIKE: Well, I agree with it. I agree with what you're saying strongly. Take a chunk to every sprint, you know, schedule it so whatever percentage your company's okay with, you know, 10% of your time, 20%, 30%, you know, that you're working on each sprint, be working on paying those things. And you said, you know, don't worry about the bottom 10%. Honestly, it's rare to get past the top 30%, right? Because new things come up.

DAVE: Top 10, yeah. Pareto's rule rules here, like, the power law. 90% of benefit and 10% of effort.

WILL: Just delete them or, like, you know, [crosstalk 29:03] just get rid of them. But yeah, you're right. I don't know, I mean, like, in the limit case, right, a long-running enterprise, right, like, a long-running technical enterprise, you're paying your technical debt tithe. You pay. You either pay because you're actively working on it, or you pay because it's, you know what I mean, you're taxing your organization. But in the limit case, as, you know, T approaches infinity, right, you're paying your card down more than --

DAVE: You pay for it in customers that go to Amazon instead of you because their site comes back in under eight seconds every time.

WILL: Yeah. You don't get out of it. There's no off-ramp. Where you can find yourself in a really nasty situation is when you're in a situation where credit card is maxed, right, and the minimum payment is substantial, and you don't have the bandwidth to fix it. You just have to work around it, right? So, like, product development is as slow as can be sustained. And the technical debt is taxing you with every ticket. And now you're stuck.

MIKE: And it can get so bad that you can't move forward anymore. You can't build new stuff because you break other stuff. You reach a stasis point, right? A balance point where you cannot actually introduce new features because everything you do fights so hard that it breaks something.

We all live in reality. There's a quote that I've been bandying about that I just realized is a... I love that Will and I, like, we end up in violent agreement so often because we come at things, like, orthogonally, but we're saying the same thing. I've been telling people, "You cannot build software faster than you can build stable software." It's the same thing. You will eventually end up paying interest. All your money is going to the interest. And the only way to get out of it is to make your minimum interest payment, and if that's your entire paycheck, that's great. But you've got to go run a lemonade stand and make 20 cents extra to pay a little bit. You've got to get the principal down.

MIKE: So, if you want to be effective in making money, you've got to keep paying that payment, bringing it down consistently.

So, we've tackled kind of broadly how to invest. We've talked about paying down technical debt. Let's think about it a little bit bigger in terms of how business works.

In a large corporation, in an established business, you've got some sort of product line, and you're maintaining that. You're adding features, and things are great. And you can treat it like that's your only gig forever, and that is risky because the world changes. You ask Standard Oil [chuckles], or you name your big business of the past that has since been forgotten. You look at the S&P 500, and it's not the same as it was 10 years ago, and very different than it was 20, and completely different than it was, you know, you go back a few decades, and you see names you’ve never even heard of anymore because the industry changed, the world changed, and those businesses did not adapt as that change happened.

So, how do you build new products? How do you go about investing in something new, even though it might even have a negative impact, might even cannibalize some of your current business? How do you do that effectively? So, this is kind of a bigger question than engineering [inaudible 32:50], but kind of a business question. What are y'all's thoughts?

WILL: Small deltas. I love a tiny, tiny delta. I mean, like, you're doing business right now, right? Something is working, right? Hopefully, at least, something is working, right? So, like, prospecting is so expensive. So, what more can I do, right, for my customers, right? I mean, this is, like, way afield from, like, software engineering and stuff.

MIKE: Sure.

WILL: How can I expand to adjacent customers, and how can I sort of, like, add some sort of value onto, like, my existing customers? Now I'm putting on my, like, I ran a software product company for 10 years hat, which is not, like [laughs], what we do here but, like, you know. It’s just the most --

MIKE: But it matters.

WILL: Well, for most places, like, you want to mitigate risk, right? Like, we did do...like, we’re Acima, right? We went over to Upbound. We got a very natural move, the natural, like, I'm taking one block over, right? I'm taking one step over. You know, Upbound was like, hey, we're doing this thing, and now this is, like, this is where things are going, and so it was a natural outgrowth. And so, like, and it's acquisition of work, like, that played. It was successful. And I think it was successful for those reasons, right? So, you want to mitigate your delta as much as you possibly can.

You don't want to get into a...even, like, there's a...I think it was...I forget the one. I forget whether it was Bentley or Rolls-Royce, right? Luxury car company, right? Well, how did they get started? Well, they were carriage companies, right? They were carriage companies and sort of, like, they built the top of a carriage, like, a horse-drawn carriage, right? Like, the top that people rode in, right? It was, like, real nice and, like, you know, the furniture was nice because people hung out, you know, for a while. And they were, like, okay, well, I'm building a carriage for a horse. When you got rid of the horse, you still had to sit somewhere, right? And so, the buggy-wheel people, those guys are gone, but the carriage company is doing great.

MIKE: Because they were willing to pivot. But you said small delta. They didn't switch over to making trains or boats.

WILL: They didn't even build engines for a long time, right? Not even engines because engines were hard.

MIKE: They just built the top of the vehicle. That's interesting. Yeah.

DAVE: There's a fun story. I wish it was true that the wheelbase on your car, the distance between your wheels, is based on the fact that the rail gauges were of a similar size. Well, the reason the rail gauge is the way that it is is because of the width of a carriage. The reason a carriage is that way is because if you drive in Europe on the roads that were built by the Romans, they have grits in the stones, and it will break the wheelbase if you're not the right width. And those grits come from horses two abreast, pounding down.

WILL: [inaudible 36:03]

DAVE: I wish it was true. I'm sure that it was an influence. But a tape measure will tell you it's not true. You can just go out and measure any of those things. They don't actually match. But oh, I want that story to be true.

MIKE: You're right, influence.

DAVE: Influence, absolutely.

MIKE: I'm sure it's not completely true, right? There’s differences between horses.

DAVE: Not a governing principle.

MIKE: Yeah. But the general idea...you don't have lanes on your road that are 30 feet wide or 3 feet.

DAVE: Or 70 feet wide.

MIKE: Yeah. They're within an expected range that came from history.

WILL: Well, I mean, I think, honestly, it probably is very, well, no, no, that's not. I mean, the reason roads are now is dictated almost entirely by technology and sort of, like, width, right, and, like, the speed that people travel and stuff like that. So, I mean, like, right now, in the year 2025, it's all technically specified, road [inaudible 37:08], road, you know, the camber, like, you know, like, stuff like that. That stuff is all, like, you know, we tried it every which way. And I'm like, if you're going to go 80 miles an hour, you need this, and this, and this. We need to have a crown on it so water comes off and, like, all this stuff, right? And I need to have a semi go down it, too, and semis are built, you know, a certain way. Anyway.

DAVE: I think roads are now in the should phase, right? The RFC 2119 is the one that gives you the definitions of must, shall, should, should not, must not. And should means you must build it this way unless you have a good reason. So, if you're in a small town or you're building a driveway straight up a cliff face, you can have a four-foot road. You can do it that way. But yeah, if you're building a federal interstate, it's going to be standard width.

WILL: Yeah, well, I mean, like, it's almost always, like, you have, like, a very exotic environmental, you know, situation. And you have some sort of, like, grandfathered in. My dad actually was, like, putting...he was rebuilding his cabin, right? He lives, like, way up north of Michigan, and he’s got a fishing cabin. He wanted to, like, go and, like, build it, right? And so, it's, like, way out in the woods and, like, he had to widen the road. He had to, like, build out the road because the road is, like, a hundred years old and, like, they needed to move the equipment down to, like, dig a septic tank. And you had to build out the road because you just couldn't do it.

But yeah, these days, civil engineering is a pretty solved problem, you know? We might not maintain the roads, but we know how to build a road that will last for a thousand years. That's figured out. We just might not do it.

MIKE: [laughs] We've detoured into civil engineering.

WILL: Yeah. Save us. Save us, Mike. Can we bring it back? We can bring it back. We're supposed to be about woodworking [laughter].

MIKE: Going back to the idea, I'd like to go back to the idea that we talked some about early on, and that's about investment in people. This is something that's kind of dear to my heart, right? It's something I care about.

So, I'll do another analogy. Hundreds of years ago, generally, every town had a blacksmith shop. And the blacksmiths, like every other human being, pass on, right? They're not there forever. So, you have people who want to go into that trade, and they maybe couldn't stay in their own town. They find a town somewhere in the region where there was somebody who was taking on an apprentice, and they'd bring them on. They would learn the trade over a number of years, and, eventually, they'd take over the job of the master that was helping them out.

And that worked out pretty...there's flaws in the system, right? But it was a persistent system for a reason. It stayed that way for a long time because it worked because the kind of...and it works for many trades. We still have it in many trades. You have apprentices, right? You have an apprenticeship program. It's pretty standard practice. People work up, you know, apprentice, journeyman, and they eventually work up to the master of their trade because learning alongside people works.

And sometimes in engineering, we forget the lessons of the past and think, oh, we'll just bring people in, and they'll know exactly what they're doing, and it doesn't work that way. There's always a need to do some of this apprenticeship. And people can sometimes come from non-traditional backgrounds in that way as well if they can take the time to apprentice. I think it's very important to always have somebody growing and a group of people.

So, you don't have everybody be the experts then you lose an expert. It's a huge loss. Instead, you have some experts and you have some people who are less experts, and then you have some people just getting started. And you keep this pipeline going because it's a system that works. And if you forget that and you shut down the pipeline, it works for a little while until you've got no water flowing, right? Everything dries out, and you're in a really bad situation.

So, what do you all think about the importance of career pipelines? I’m going to take this a little further. I’m just going to...storytelling. There's a number of people that I've worked with who worked in QA or application support who switched over into engineering and have become very successful. Some of those people might even be on this call. And I am very happy that they were able to make that move and become successful by taking the time to learn the trade, partner with other people, develop the skills, and go on to become successful.

And by providing that opportunity, we ended up with people with huge domain knowledge and know what they're doing, know the business, and were able to kind of step into the role and be successful very quickly and be strong contributors. Whereas if we just pulled somebody off the street, they would have taken as much time to get up to speed and would not have the same kind of domain knowledge and the social cohesion. We're already friends here.

So, I think there's huge value in having that kind of pipeline. We may also have somebody who brought in as an intern who joined us on the call [chuckles]. There is value in people coming through that kind of pipeline.

So, I'm just going to sing the praises of that idea, and I'm saying, yes, you need to be investing in that. If you don't invest in that...I've described it before as eating your seed corn. You're fine this year, and it's a lot worse next [laughs] because you've got nothing to grow with. I'm laying down my stance here. I'm taking a strong stance in favor of the criticality of having a healthy department, of having this sort of pipeline in place.

DAVE: I could not agree more.

WILL: It sounds like the point of the podcast where I start to proselytize for extreme programming.

DAVE: Kind of.

MIKE: Please do, yeah.

DAVE: Please do, yeah. That is very adjacent to the story I'm about to lay, so please.

WILL: Because, you know, that's how you do it in extreme programming, because everybody is pairing all the time, which is how you do knowledge transfer. And you train juniors to become seniors, and seniors to become staff, and staff to become, like, whatever, super staff, or whatever the heck.

And, like, that sort of flow of training is endemic and intrinsic to sort of a healthy, functioning engineering organization because, like, nothing is ever static. Everything is in flux. Everything is changing. People are coming. People are going. People are moving up. People are, like, I don't know, probably not moving down, but, like, moving out, right? And so, I don't know. Like, there is this sort of you have to accept, like, that intrinsic, undeniable, like, flux, change, right? It's happening all the time.

And, like, I think, you know, the reason I harp on XP is because I have not encountered a systematic way of addressing this as a first-class citizen that it is. I would love to just be able to be, like, hey, what if I just pay somebody a lot of money, and then, like, I don't have to think about it? And, I mean, like, you can do that if you could find the people, but, like, it's, you know what I mean? Like, Google can't do it, so can you, you know?

Like, Google can do it, and, like, they write a check, you know? And, like, if you talk to anybody from Google, they're, like, yeah, it's better, but, you know? So, anyway, so, you know, not to harp on it, but, like, you've got to get it done somehow. And I haven't heard a lot of answers. I've heard a lot of people sort of, like, taunting or advocating or throwing their hands up in despair. But, like, if you're actually trying to solve a problem, once again, extreme programming, shooting [inaudible 45:16] away.

DAVE: Pair programming, yeah, absolutely.

Related to both of those things, we have kind of a career pipeline here, and I love that. I can't remember if I was super interested to be hired here because we had one or if you guys were interested in me because you wanted one. But, like, I was coming out of CoverMyMeds, where we had established a career pipeline, absolutely.

And, like, when I was there, we had this rule that everyone codes. Like, we had code from the CEO. It was terrible, but it was there. We had people from QA that were contributing code into our corporate…Everybody codes, but the QA people would just sit quietly and get crapped on by the dev teams. I was the one that started going in and saying, "No, we're going to pair program."

I would grab a QA person and say, "Come pair with me." And they would look at me like, I'm going to waste your time. And I'm like, are you kidding me? You're QA. You know where all the bodies are hidden. Sit with me, please. And very quickly, they’d find out that even the juniors have an incredible amount of contribution. So, I cannot sing the praises of that high enough.

But Dan Pink wrote a book called Drive, and he talks about what motivates us. And mastery, autonomy, and purpose are the three biggest things that will get you out of bed every single day. And when you take somebody and say, "You can grow your skills. You can increase your mastery. It's hard to do, and you can get better at it, and that feels great." Autonomy means we're going to open a hatch at the top of your career pipeline, so that when you are at the top of your pay scale, you can slide into the middle of the pay scale of the next harder level. If you want to go up in a belt rank in the dojo of engineering, we've got another team for you where it's harder. And you're a much greater investment because you're solving even bigger problems, and it's fantastic.

The reason I get so excited about this, and this is kind of heavy, so I realize you guys are...I'm usually the poop joke guy. But when I was at CMM, I had two people come...well, I had about seven or eight people come to me and say...this was when Ruby Rogues was really, really famous. I wasn't the most popular person on the panel, but I was there. And I would tell people, come work with me. Come work with me. Come work with me. We're fixing the healthcare system.

And now I'm telling people, "Let's..." At Acima, we are servicing a part of the economy that is wildly underserviced, underrepresented, and it is heavily predated. There are a lot of predators down here. And being able to operate in that environment and help people is incredibly emotionally fulfilling.

But the thing that knocked my head right off my shoulders was it happened back-to-back over a two-week period. I sat down with a guy, and we're just coding, and just out of nowhere, he says, "I work here because of you." I'm like, "Wait, what? I didn't interview." He said, "No, I was listening to your podcast. And I'm like, that does sound cool. I want to go do that. So, I'm like, okay, hey, that's really, really cool. I thought that was my shining tiara. I brought somebody in. That was great.

And then, two weeks later, I was programming with a woman. And that's significant because women are wildly underrepresented in tech. And we're typing along. And I don't want to niche or brag or politicize. She was also trans, which is even more underrepresented, and that's the only reason I bring it up. It's even more underrepresented. It's an even more hostile environment.

So, I'm sitting next to this woman. We're typing along. And she said the same thing, except I knew that Cover My Meds was her first job. And she didn't say, "I came here because of you." She said, "I got into programming because of you. You convinced me that I could do this. You convinced me that I could survive in this environment, and here I am." And I'm like, "Can I give you a hug?" I will carry that to my grave as one of the top ten core moments of my career.

Yeah, invest in people. It is so worth it. It is so worth it. That's my speech.

EDDY: I've said it before, and I’ll say it again. Dave was the first person here at Acima that taught me how to create a branch and push it up to that repository. No one before then had taught me how to do that.

DAVE: Awesome.

EDDY: And so, the fact that you did has gone and paid in credit, I think, so...

DAVE: And I forgot that we did that. And you were subtweeting me in the room. You were like, "Well, I got to be one of...there's an engineer. He sat down git da-da-da-da-da." And I'm like, "That guy sounds really cool. You need to do that for people." Eddy’s like, "Dude, it was you." And I'm like, "Wait, what?

So, yeah. Don't do it for the credit. Don't do it because you want. I'm just saying do it, and when it pays off, it feels amazing. Plus there's all these other programmers that are now going and having careers that are...and that's the real purpose.

MIKE: Absolutely. I've said it for years. It's the most gratifying part of my career is when I can help somebody be successful and see them move on. And when you see that happen, it's just incredibly rewarding. And it goes back to this idea of investment. You watch that investment pay off [chuckles]. You invested in that crypto coin 10 years ago, and now suddenly you're rich [laughs].

DAVE: Survivor bias fallacy. Yep.

MIKE: There are some investments worth making and investing in people because you care, I think, is worth it.

Now, this is not to say that we can function exclusively as an educational institution because that doesn't work either. As we talked about, if somebody is not ready and the business is there to make money [chuckles], that doesn't work. But if somebody is competent and willing and able to do that work, give them all the support that you can.

As Justin was saying, his time is best spent helping other people be more successful. And as you move up and move forward in your career, whatever it is, as you advance in your career, that becomes more and more true. The more that you can help other people be successful, you're going to be accomplishing more than if you're just walling yourself off into a corner and banging out some code.

DAVE: Stephen Covey, if there's no margin, there's no mission. There's times when the people have been bright and ready to learn. And we had two weeks to ship eight weeks of code, or we were all going to lose our jobs. We didn't do a lot of skill-building that week. We did a lot of overtime and a lot of typing because that's all the margin we had for.

MIKE: But when you have some, you pay down your debt, and you invest in the future.

DAVE: And there's a valuable investment to trauma bonding with your co-workers [laughter]. That's funny, but I'm not joking. That is absolutely a true statement.

MIKE: It is true. I laugh because I identify it, not because it was wrong. So, I think I've covered everything I wanted to talk about today. Anybody else have any final words they'd like to throw in here before we break?

WILL: Everybody should be doing XP all the time. Do it. If you have the power to do it, do it. If you don't have the power to do it, do it anyway. Just don't tell your boss. Invest in people. If you can’t invest in people, invest in yourself. There’s always this, like, because you're going to find yourself...As an individual contributor, you're going to bump up against just these things where it's like, what is that? What is that? What is that?

Just keep, like, a slush pile of things you're run into, either, like, a piece of the codebase, a library, just some kind of thing that it's just like, what the hell is that? And just keep a list. It's just a list of stuff, like, Google's I need to do, you know, in the future. And just, like, just check it out.

Just keep stuff in your down cycles because you're going to get them, right? They're going to happen. And it's always about, like, you know, getting better and getting smarter and building extra understanding. Because, you know, civil practical fact, right, like, none of the work that we do is really that complicated. None of it's that hard. It's really pretty simple.

Like, most of the stuff you did in school is more complicated. Like, I built an operating system, like, an entire operating system with a memory manager in school, and I don't have to do anything like that at work, you know. But I do need to know how a bunch of, like, dumb business logic operates. And, like, how does the DI that gets our cookies to authenticate a user, like, how does that get initialized, and when? Because if it's not ready, then you don't log in. That's a problem for some people.

And there's nothing about it that's special. You just have to know. And, like, what's the difference between, like, the best guy in your team and, like, the worst guy in your team is, like, the best guy in your team, like, he paid that toll already, and he knows. And, like, it's just a matter of showing up every day and, like, just getting a little bit smarter.

I mean, because, like, to be perfectly honest with you, like, completely average developers can become exceptionally productive, and valuable, and talented ,and have wonderful careers, just by doing, like, a little bit extra. It's not that much work, but people won't do it. And it's a matter of investing in yourself, you know. And that kind of stuff is entirely within your control.

You know, XP now, XP forever.

MIKE: I’m not going to argue about the pairing [laughs]. So, I'm going to conclude by supporting that. So, we've got Jordan here, who was an intern recently. And one of the best things that happened to me this summer is, at the end of the summer, the interns were doing their presentation. And they brought up pairing on their slide and said, you know, we've been doing this all summer, working almost the entire time pairing. And I was like, yes [laughs], yes, learn how to work together. That's, like, one of the most...maybe the most important thing you could have learned this summer, and you did. It worked.

JORDAN: I want to say that this summer, compared to last summer, just felt so much more productive. And I kind of...I low-key became kind of dependent on pairing because we would have the hour in the morning before stand-up where we just worked on our own stuff, like, I don't know, catching up on our tickets or, like, the Exercism.

And I would sit there, and I'd be like, well, I can't get anything done. Like, I don't have Chloe sitting here, like [laughter], to discuss on what we should be doing next or, like, what we're currently working on. And so, we’d pair, even when it felt like there was nothing to do because we could talk and, like, find something to do. And that just felt so much more productive. So, I'm a big advocate for that [laughs].

WILL: Yeah. And keep a slush file. Every day, and usually a couple of times a day, I'll come up against something that's just like, how's that? What did you do? And there's always a story, right? It's always a story. It doesn't matter whether it's, like, it could be, like, a Git, Jira spelunking story, or it could be, like, some kind of trip thing, or it could be, like, some technical debt that maybe needs to be on the list. Just keep a note file of just like, what the f*** was that? You know? Like, I can't encourage it enough, you know, because there's always something.

EDDY: I will say, Jordan, you don't necessarily need a Chloe to talk to, right? Like, you need something just arbitrary just laying next to your desk, you know, something where you can express yourself to. I mean, I can't count the number of times that, like, I started typing out a message to someone, and I'm trying to articulate all the things that I've done, right? And I'm like, dude, I'm stuck here. I can't figure this out. I've done this, this, this, this, this, this. And then I'm about to send them like, ah, wait, you know? And I just laid everything out, right? And --

WILL: ChatGPT is my work wifey [laughter]. Not like that. Not like that [laughter]. But, like, I can [crosstalk 57:14] you know what I mean? Like --

MIKE: Probably a good slot to close. The social aspect matters. Invest in your people.

Until next time on the Acima Development Podcast.

DAVE: Cheers.

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’d burn it all on the pan, all the seasoning that they would have around, and then we'd have to clean that off. So, imagine burned on fishy oil with spices and gunk. So, first sink was a soak with lots of soap. Second sink was for rinsing. And third sink was bleach. Soap, rinse, bleach.

And I’d spend hours every night. Well, before I ended up, like, hosing down the floor and stuff. Weird smells come out from behind kitchen equipment when you hose them down at the end of the day [laughs] [vocalization]. It's unrelated, just something I think of sometimes, that smell [laughs].

This is this industrial operation, right? And I would spend hours doing this, you know, the soaking and then you go to scrub the thing and if it wasn't coming off yet, then you’d go back in the soap soak. And, eventually, it was like magic. You’d soak it long enough, even the worst caked on stuff would eventually come off. And you'd rinse it and get it over to the bleach and out, and rotate back around to the cooks. And I got used to this. I'd been doing this for weeks.

And then came my rotation, remember, this is my teens, came my rotation to clean the dishes at my parents' house. And I went to do the dishes, and I just started laughing. It's like, what are these? Toys [laughs]? It's a little scrub brush [laughs] and, like, a sponge. Like, I used to think this was a chore. This is going to take me five minutes. What kind of problem is this [laughs]?

And it totally changed my perspective around doing the dishes. This is an entirely different job. I have different tools. I don't have real tools anymore, like, and I had to, you know, find the scrub brush. Like, okay, the scrub brushes work better at this than the sponge [chuckles], but still, it just all felt like toys. I laughed. Every time I did dishes that summer, I laughed because it was just so much of a different problem than what I was doing at work.

Today, we're going to talk about big projects versus small projects. And we're not washing dishes [chuckles], but maybe somebody's doing software for, like, a microcontroller for a dishwasher or something. So, maybe somebody out there is washing dishes. But a lot of these principles apply. The scale really matters. And this comes up often, actually, in our podcast. And you’re like, oh yeah, scale matters. It came up recently when we were talking about vendors. If you are very differently sized from a contract shop, then you're probably not going to get the right level of service because they don't cater to your needs. And when you're building stuff, scale matters, too.

And I've got a lot of thoughts on this. You know what? I'm hosting, so I'm going to throw one other thought out here: Navigating inside of a neighborhood. In fact, this is something I've seen in my neighborhood. Where I live the most prominent landmark is the village water tower. We've got a big water tower. It's one of the larger ones in the region, and you can see it from almost everywhere in the neighborhood.

We have a daughter of a friend who once got lost because she got into a part of the neighborhood where she couldn't see the water tower. And, you know, there's a little bit of hilliness, and so she got to a low spot. It's like, I don't know where I am [laughs]. And she was lost for a while because she had nowhere to go.

DAVE: GPS is unreachable.

MIKE: Yep [laughs]. And, you know, she may have been, you know, she was probably, like, she may not have had a phone. This was probably 10 years ago, maybe a little bit before everybody had a phone [chuckles]. She didn't have a GPS. But yeah, the water tower is the GPS that that's where you're going --

DAVE: That's what I mean, yeah. That’s what I meant, yeah.

MIKE: The water tower is the GPS. And so, yeah, she didn't know where to go because navigation is different when you've got a small scope versus a large scope. Once you get outside of that, well, you actually have to know which way you're going. You have to know where your cardinal directions are maybe, right? You have to recognize more landmarks than one. And, you know, traveling across the country requires a different set of skills than walking around the block. They both require skills, but one of them is fundamentally different.

And a lot of times it is hierarchical in that some of the skills that you would apply for that navigation of the, you know, of the small scale map may apply to large scale map, but you're going to have to say, “Okay, well, I need to get from Chicago to Des Moines.” And you figure out at a high level where that's going to take. But then when you get down to the actual implementation, you know, you have a detour. And then you switch down to a different level, and then you have a smaller map, a smaller map in your mind that you're dealing with. So, your hierarchy changes. So, you have to break down the bigger problem into smaller problems.

I wanted to throw out a couple more ideas to kind of get the thoughts. Also, Will has just joined us. Will Archer, welcome.

DAVE: Welcome.

MIKE: [inaudible 08:22] So, glad to have him with us. So, I've talked about big problems versus small problems. What are y’all’s thoughts? You know, open discussion.

DAVE: I will throw a weird curveball into this, which is that I just came here from a meeting with our DBA, Bill. And I think I've mentioned this before that, like, when I first went to the data team, it shocked me that on AppDev, we spend all our time...everything has to be small. Don't do big joins because you've got to get to the database, get your thing done, get back out. It's synchronous. It's, like, single threaded. We don't like doing big updates. We like doing small batches, everything.

And then behind the data center wall, compute everything because storage is ridiculously expensive. And when I went to the data team, they were, like, yelling at me, like, “Stop that. Stop that. Stop that,” because storage is free, and compute is vitally expensive because we're spinning up cloud servers [inaudible 09:19] down. And it was mind blowing to me. And we approached everything...I was so excited when they did, like, this 30-table join, and it came back in, like, one and a half seconds. And then, on the flip side, we tried to do select count from this table, and it took one and a half seconds. It's like you could do anything in one and a half seconds, but you couldn't do anything in not that amount of time, and I'm like, that's the difference. The get in, get done, get out is low latency. So, it's very, very orthogonal thinking is how you come to it.

And it was kind of exciting to talk with Bill about, like, “Well, how would you refactor?” And he's coming from a world where they would take the whole system down, like, to rename a column, take the whole system down, rename the table in the database, rename the table in the code, bring the whole system back up. And this would be after, like, a week of testing it in a replica to make sure that the name change was going to work.

And I'm like, yeah, we don't do that. We're coming from, like, finance and healthcare, where it's like, your system cannot ever go down. So, if you want to rename a table, you're looking at five separate deploys, you know, add the column; backfill the copy; add code to shoot to both places and to read from, you know, and to read from the new place. And once you're syncing always, then you start reading from the new location only. And each one of those is a separate deploy. And yeah, he was shaking his head. And he's like, yeah, that's fair. So, instead of big versus small, it's like breadth first versus depth first approach to covering the entire graph.

MIKE: But it requires different tools.

EDDY: Going the slow but sure route, I think, is the one that I've always appreciated the most, meaning don't go destructive; get it done in a day, but rather do it in a five-step process to make sure that everything you're doing is correct so that you don't lose any data, right?

DAVE: Mm-hmm.

MIKE: That's interesting. You're absolutely right, Eddy. You have to do that on a big project. But what if it’s your own personal project that hasn't even gone out yet? Do those same rules apply?

EDDY: If something's not actively being written to production, is that what you're saying?

MIKE: Yeah, that's right.

EDDY: Then go as crazy as you want, I think. You don't have any sort of sensitive data, like, actual factual data from customers or clients, right? So, I'd say you're free to play around.

MIKE: Now, Chloe and Jordan, you have been working on a project most of the summer, and that scale is different than what you do at school. What have you learned about working in a larger project versus a smaller one?

CHLOE: I think something that I've noticed is that the way that you design things and those decisions at the beginning can have a large impact on the project. When something's really small, if you're, like, I'm going to structure it, you know, this certain way, it's halfway through, and you're, like, hmm, maybe that's not the best, it's really easy to change. Versus a large project, those decisions are usually pretty concrete by the time you realize you might want to [chuckles] change it.

And so, I think it puts a lot more emphasis on the front end of thinking through the process of what's the overall game plan of this project? What do we want it to look like? Do we expect it to grow? Do we need to look at tools that can grow with that? Or I think there's just a lot more questions you have to ask yourself before starting versus when it's smaller, you can kind of just hit the ground running and then deal with problems as they arise. But you're not always afforded that luxury with a large project.

WILL: Ooh, so waterfall.

CHLOE: Yes.

WILL: The siren song of the waterfall.

MIKE: [laughs]

WILL: [inaudible 12:52] sensation to just be, like, okay, listen. So, listen, what if we just didn't make any mistakes in the beginning and we knew [laughter] everything that we were going to do? Despite being literal students, right, and this being a learning project, we're going to get it. We're going to nail it. We're going to tie everything [laughter] together. And it’s just going to be like, boom, bullseye right in the very beginning.

I think that is a very natural impulse that will be with you for your entire career. Like, you're always going to be, like, oh, what if we just didn't screw it up, you know, essentially [laughter]. It's a temptation. It's a very fundamental, natural human temptation. And I think, you know, you could get better and better and better on it. Because you go on and you have better instincts. You make better, like, just sort of, like, rules of thumb, you know, kind of stuff.

We talk a lot about, like, carpentry and building houses and, like, physically constructing things. If you’ve ever watched somebody, you can...you can watch people who are really, like, just good and, like, good framing carpenters, and they can just throw up a shed. And they just kind of know where everything's supposed to go. And it all just fits together, and it's right. And it makes me really mad because I'm okay with effort. But you’ll get better at it, but you're never going to be good at it [laughs].

And it isn't, like...the solution isn't, like, don't try because absolutely try. But there's also a feeling of, like, you know, let's just go and learn. If you accept refactoring and rework and reevaluating of your prior preconceived notions as a necessary process, when you hit that point, and you’re dead end, and you need to turn around, turn the car around and drive back, you'll identify it, and you'll do it, and when it's time, as opposed to, like, just, like, okay, I'm just going to muscle through. You know what I mean?

CHLOE: Yeah, I think that makes sense. I think it's inevitable that you're going to make decisions that eventually you might want to change. And so, instead of, you know, having this idea of no, we're going to make this decision now and it's going to be perfect, embrace that things are going to change and kind of learn to work through those things. I agree. I think that's a good point.

MIKE: The agile software paradigm in a nutshell.

DAVE: That actually came up in my chat with Bill that his database thinking is old school. The reason I had the chat with him was because we're migrating phone numbers in our database. And we're literally moving from one table to another. And I had a chat with him of, like, we've been working on this for, like, six months, and, you know, what should we have done?

And I realized when I invited him to the meeting yesterday, I said, “I'm going to ask you what we should do. And I realized that the first thing we need to do is jump in a time machine and go back and not forget to have asked you what we should do before we do it. Because it's so much easier when you get the design right first.”

EDDY: It's so much easier to let someone else do the design that they're really good at to do it for you than [inaudible 15:55] [laughs]. Agreed.

MIKE: But it's inevitable. And we're talking about large projects. It's inevitable that on a large software project, the business domain is going to shift. So, even if you made all of the perfect decisions on day one, which you didn't, the ground is going to shift under you when what you were building --

DAVE: And if it doesn’t, the company you're at is going to go under. Sorry, if the software you're building doesn't shift, the company you're on is going to go under because the world is changing every day.

MIKE: Well put. You build really good horse carts, right [laughs]? You may have it perfect. You've still got a problem.

DAVE: Yep. I make the best abacus in town.

MIKE: [laughs] That necessity of change is going to come up on you. Tech debt can hit you even if you didn't know that you were going into debt in the first place, just because of that change in the world.

So, you know, we've talked a lot about this, Chloe. You talked about, yeah, I want to get things right in front. You do, and then you can't, right [chuckles]? You do all that work, and then you find out that you were given an impossible task. As Will said, you still try, and you do the best you can. You still measure twice, cut once [inaudible 17:22] carpentry [laughs]. It still might be wrong a year from now.

WILL: This is maybe advice that, like, maybe is specific to me, but I think it generalizes, like, at least decently. I've always been smart, and I've always been good at my job. And I've always been known for being smart and for being good at my job. And I think a lot of people in the business self-identify as smart and confident. And it leads me down a dangerous and destructive path when I fail to embrace my own ignorance and stupidity [laughs]. Embrace stupidity. Lean into it. Lean into it.

Like, you get used to being...you can get too comfortable being smart, especially if you're really smart. You know, like, we don't work with...nobody in the office...if you walk down the office, right? There's nobody...nobody is dumb. And there are very, very few people, maybe in sales, I don't know, who are average, you know? There's nobody. And so, you know, yeah, embrace stupidity.

MIKE: I'm going to build on that because I think that is a profound concept. Have you read any of the work of Carol Dweck, a researcher in learning?

WILL: The name is familiar, but I'm ignorant of her work.

MIKE: She’s done a lot of growth...I think I’ve got this right [chuckles]. She's done a lot of research on what she calls a growth mindset. And what she's found is that people who think they're dumb and people who think they're smart end up running into the same dead ends because the kids who think they're dumb, well, they don't try. The kids who think they're smart have their self-image invalidated when they make a mistake. And so, they don't try because they think, oh, I'm actually not smart. I'm not good at this. And they don't like that feeling, and so they stop.

My recollection is that this actually tends to affect girls more than boys because a lot of parents are like, “Oh, you're so pretty. You're so smart.” And they say a lot of “You are this,” rather than “You did this,” and that can harm the girls, right? Like, you think, well, no, there's nothing wrong with being told you're good. But it can actually be counterproductive when you say that you are frozen in this good state rather than saying, “Wow, you are a hard worker.” Now that completely changes the way you see the problem, right? Like, “Wow, you made a lot of mistakes today. You are working hard. Look at those scrapes you've got. You are tough.”

That is a fundamentally different way to approach the problem and is much more healthy. And the kids who think that way, that growth mindset, are the ones who tend to succeed. And that matters a lot when you're in school where you have to grow a lot. But then to Will's point, we're all going to get stuck. And if we don't recognize that, yeah, we're going to have to be dumb sometimes; we're going to have to be uncomfortable and grow, then we've run into exactly that problem.

EDDY: Yeah, the best advice I was given when I first started is, don't be afraid to sound dumb, right, kind of to add to that, right? Everyone has come from that point, right? And the sooner you accept the fact that someone who's been an engineer for 10 years is also dealing with the same thing as you are, things become much easier.

DAVE: There's an easy thing that I...it was probably me who told you that because I'm --

EDDY: Probably.

DAVE: I’m still happy, Eddy. About six months ago, we were standing around talking, and I asked a pretty obvious question. And you looked at me and said, “You are fearless about asking stupid questions.” And then three people in the group said, “I don't know the answer to that either.” And I'm like, not so stupid after all. And Eddy wasn't asserting that. I'm, like, no, that's actually a pretty smart, stupid question.

And so, the hard work versus...sorry, getting it right versus dealing with it, in my opinion, that's the same shape as being told you're perfect and not wanting to risk damaging that, which makes you nonfunctional and less productive and less successful versus being told if you're here, you need to get here. Just take one step up, and then if we come back to you in five years, you're going to be way ahead of the other people because every day you take one step up where the people who were smart to begin with haven't been.

And this is why I wanted to say this is getting the design right the first time is getting the design perfect the first time. When I put the phone number thing in, it's currently running in the most awful way possible. And I'm proud of it, so I don't feel like this is me shaming the company. We currently have data living in two places, and it's ugly, and it's messy. And both Rails models have triggers in them that when I get updated, I'm going to go check the other data location and if it doesn't match me, I'm going to fix it.

Well, first thing I'm going to tell it, “Don't update me back because you have the same code to update me when you save,” right? So, this data is constantly fixing. And basically, anytime you touch one of these things in the database, it settles with the other one. So, literally to backfill the data, you literally can just say, “Load an object, touch it, save it. Load an object, touch it, save it, load an...” And that's literally the backfill because the data can repair itself in motion. And all you have to do to backfill the data is just touch all the data, and that's great because, now going forward, any new data going in the system comes out correctly.

I went on leave for four months. I came back. That code is still there. We are running on that little donut spare tire for this data. And there's a part of me that's going, this design is terrible, and it's inefficient. There were many extra cycles...da da da. And then I'm going, we are one step closer to having the database right, and the website works. We're selling leases. We are giving people the things that they need. We are taking care of business. We have cash flow. And I love that. And, longitudinally, we are headed towards the right data schema, database schema, and I love that.

I would much rather be good at correcting an error than getting it right the first time because getting it right the first time doesn't scale.

EDDY: Well, I'd be surprised if any of you have been part of a large project where you got it right the first time. I mean, I'm happy to be proven wrong.

CHLOE: I certainly have not [laughter].

EDDY: Yeah, no. I'd be happy to be proven wrong. I think that's a very fair assumption.

DAVE: There's a rule that we found in the ‘90s, which is that a waterfall software process works very successfully if you have built it three times already. So, if you're making version 4 of the thing and it's the same thing, you're not reinventing it for a whole new world, right? It's like nobody has built 3 AI embedded products. That's not what I'm talking about.

I worked on a company that was making graphics cards, and we were making the 3K version, which was after the 2K, after the 1K. And we've reused all the same processes because the way you manufacture silicon hadn't changed. And so, waterfall worked really, really good.

Do you know where we ran into trouble? That 10% of extra stuff that was all new. And we ran into all kinds of trouble, some of which broke the silicon. And I stayed up late one night swapping red and green in the software because somebody had made a change upstream that was now using the wrong channels for the colors in the silicon. Couldn't be fixed in the silicon without turning the chip in the fab, which was going to be, like, a $10 million impact. So, they're like, “No, fix it in software. It will be all right.” We got it wrong.

MIKE: To pull this back to where Chloe originally started, well, you have to think about the decisions beforehand. Well, you do. But you need to make a good decision, not a perfect one. And those are different [chuckles]. You do, in a large project, need to make a good decision. But it's infeasible to make a perfect one, so you shouldn't try because you can't. And it is a fool's errand, and you will end up spending all of the resources allocated to your project trying to make it happen in planning up front, and then you'll still be wrong.

EDDY: So, Mike, are you saying that a good decision implies that you can be agile about your design?

MIKE: I am. Because if you head out in a good direction knowing that some parts of it are going to be wrong, then you step in knowing, hey, I'm going to have to change. I'm going to have to take feedback and course correct over and over again. But that means that at any point in your project, from inception to finish, you're continuously pivoting. And you never reach that perfect ivory tower; instead, you make money. You actually bring in value [laughs] to your employer.

DAVE: Have I told you my mantra on...you get told, if you don't have time to do it right, when will you have time to do it over? That is waterfall thinking. Agile thinking is, if you don't secure the cash flow right now, when are you going to have a paycheck to do it right?

WILL: So, the question I've got, right, like, I love the conversation, right? And I feel like, okay, you know, smart, pat on my head. I made a good point. Everybody likes it. So, you know, I'm being applauded in my mind. My therapist would be very proud of me. But, like, I think, okay, let's take it a step further, right? We said, like, don't do this, right? Like, don't plan too much, right?

And balance in all things is, like, the essence of engineering, right? So, we say, don't plan too much, right? And I think everybody [inaudible 27:29] on that, right? But, like, don't not plan, right? And so, like, how do we balance the scales between, like, okay, you know what I mean? Like, I'm not just, like, shooting off half-cocked, but I'm also, like, not analyzing this thing and creating a 100-page PowerPoint before I even break ground, right? How do we balance that?

DAVE: I have a quote from Sandi Metz. Agile means deferring a decision to the point of maximum information and no further. That's the key, right? It's deferred as late as possible because information always goes up over time. But she does say --

WILL: I don't like that at all [laughs]. I hate that. Maximum information?

DAVE: Everyone does --

WILL: Maximum information. Like, that's, like, I don't...I am deeply unsatisfied by that, but I bet you have more to say.

DAVE: So, information increases over time, but at a certain point, you've lost the opportunity to make the decision because things have just been decided for you over time. And so, that's the ideal perfect time because, like, the schema is turning, turning, turning, turning. No, we have to shift, but now you have as much information on what the correct schema to go with is.

You are absolutely right. She's not saying don't make a decision. You do have to make decisions. And a lot of decisions if they're not impactful, just make them, right? It's pushing not all decisions are the same.

MIKE: Procrastinate as long as you can get away with.

DAVE: Procrastinate when it's appropriate, which is probably more than you think.

WILL: I find this deeply unsatisfying, and I'll tell you why. I think the fundamental thesis is right, but I don't like it as a heuristic because I think what I believe will eventually...if you're a perfect person and you're diligently following, like, that thing, what you'll run into, I believe, is the uncertainty around the information that you can get where it's just like, I don't know. How's it going to work? I don't know. What's going to happen here? I don't know. I don’t know.

DAVE: Not all information is equivalent, yeah.

WILL: You know what I mean? Because you don't have enough data. The uncertainty, I guess, the signal-to-noise ratio gets to the point where, like, you're making decisions, you know what I mean? And there's just no way of...there's no way of possibly knowing, not because, like, the information is not out there, but because you don't have it, right? You run afoul of...you just have to have a lot of wisdom and professional judgment.

And, like, you just need to have been around the block a few times. And you need to have, like, very much that beginner's mindset to be able to have, like, both the wisdom to say, like, “I don't know. How would I possibly know that?” And the judgment and the courage and the humility to say, like, “I don't know.”

And, like, to stand up to say, like, “I have no idea what the answer to that question is, Mr. Vice President. I would like several million dollars of your budget so that we could just, like, go off, you know what I mean, and see if this project lands.” And there might be some dumbass in the seat next to you without the wisdom or humility who's just like, “No, I know, and we're going to do it my way.” I think it's blind human nature and the sort of, like, emotional, psychological, social forces that these decisions are going to have to be made in. Does that make sense?

DAVe: I think so.

WILL: You know what I mean? Like, yeah, you're right.

DAVE: I think so.

WILL: We [inaudible 31:16] work.

DAVE: Yeah, I think not all decisions are the same shape. Like, I worked at a company where the CEO wanted us to look really good to the investors, so he splashed for a SQL server. And it was a nightmare. It wasn't easy to match. There was a lot of impedance. And because we went with SQL server, that forced a lot of decisions that were free decisions until he made that one. And five years later, we moved everything to Postgres. And we moved things to Postgres here at Acima. I'm not talking about Acima, just to be clear.

But that's the kind of thing. Like, if you make a decision I'm going to do it this way, and it's going to lock me into 73 other side effects that I haven't even considered, that maybe was a decision that could have been deferred and studied a little bit better. I'm not saying push everything out. But I would say, by default, I tend to push decisions back unless there is, like, no, this has to be made, or I can see that the decision has very little cascading downstream effects, if that makes sense.

You could probably use some sort of heuristics or some sort of rule of thumb around, like, percentages. Well, this project is, well, this project's got a $500 million budget. So, you have something outrageous, you know, some big government contract. You probably want to spend more than five minutes making that decision. If something’s got a $2000 budget, you probably don’t want to spend more than a few minutes making that decision.

DAVE: Absolutely. I wrote a script to keep track of what branch I'm on in Git. And the very first version of it, I used YAML store, which is literally just a YAML file as my database, and that worked great for about six months. And I eventually had to upgrade to SQLite. I didn't want to go all the way to put a database server on my thing. So, I was like, yeah, let’s just install SQLite. I can do that. And that's enough SQL to do the things that I'm keeping track of.

But what I needed out of that decision was for the decision to be made quickly and to not slow the little project down. And that could have, like, if I was running a production business and I had made that decision, we might run into all kinds of scaling problems. Because pretty soon it's, like, well, we don't want to change databases, so we're going to write all this stuff to deal with the fact that we got this wrong. And welcome to the rest of your career. It's going to be solving your solutions is so much more painful than solving your problems.

MIKE: Going back to what I was saying about the different scales, you can say it in percent. What is it, 5%, 10% of your time should be spent up front making some decisions. And I don't know exactly what that number is. It shouldn't be 50% in general [crosstalk 33:56].

DAVE: I would be tempted to think the number changes, but yeah.

WILL: I mean, I would say, like, rather than, like, sort of, like, a percentage, right? Like, I would say I want a story for, like, a thing. Like, this is a thing, and this is going to happen. And somebody is going to open thing up, and they're going to go on a journey, right? They're going to go on a journey. And, like, I'm going to, like, I want to make a web app. Like, okay, well, what's the first thing I'm going to do? I'm going to log in, right? And then I'm going to see, like, a to-do list, right? Something dumb. I'm going to make a to-do list. I'm going to make, like, a photo, whatever you're going to do.

Like, make a story for, like, this is the person, and they're going to do the thing. And then what are they going to see, and what are they going to do, right? Like, that's...like, it's a school project, and I'm going to write, like, a database. And I'm going to enter data, and I'm going to have a row. And it's going to be a thing. Just have a story of, like, just what this is in plain, simple language.

And then, the story gets more or less detailed when you're in a big organization where it's, like, okay, well, I'm going to go in here on the website. And it’s going to be this team, and it's going to be this page. And this is what we're going to do. And then I'm going to talk to this service. I'm going to talk to this thing. And this isn't...it sounds like, oh, this is a waterfall, but it's a simple algorithm, like, the planning that you're going to need to do in a big organization versus a little organization.

Write out the steps. Don't have a lick of code. Like, I'm talking about plain English and napkin drawings. Like, you can do all this stuff on a whiteboard. Write it out. No code. Nothing. You’re just like, I'm going to talk to the Prometheus service to get a user log in because you got to do that. And you know where you have to go, or you should know before you're building it, right?

DAVE: We might be in violent agreement, Will. When you say push the design out and do it on a napkin, that's what I mean. You have just avoided choosing a tech stack and a server host. And that's the decision I'm talking about pushing out.

WILL: Yeah. I mean, but just a story, like a story, you know what I mean, like, yeah, nothing. No keyboards. Write it out with your fingers, those little [inaudible 36:16] popsicles, and, like, write it out. Go ahead.

MIKE: Are you suggesting, Will, that if you can tell the story, then you're at the point where you can make a suitable decision?

WILL: I believe, like, you'll write out the story, and then, like, somebody in your team will be, like, well, what about that, right? And you'll flesh out the story. Well, what about that? And you'll flesh out the story. And eventually, and this is, like, woo-woo and vague, and, like, okay, it is a craft that you learn, you know what I mean? You’ll get to a fixed point. Like, you’ll get to a fixed point where, like, you’re going to know what you're doing, you know what I mean?

And then, I think, some of it, unfortunately, I hate to like [inaudible 36:58] vibes out there, vibes. But you're going to start feeling some vibes, you know. And you will also blow it because it's just a story. It's a napkin drawing. And you'll be, like, oh, well, what do we think of that? Like, yeah, it's a story, you know.

MIKE: Emotions are sometimes looked down on, but they're there for a reason. You have those vibes because it's telling you something. So, I don't think we should be ignoring them. We should be using them to their maximum potential. And if you reach the point, like, hey, this feels good; this story resonates, that's probably telling you something.

DAVE: What you're saying, Will, matches very strongly with my view of, like, top down versus bottom up. When you build bottom up, you start with, like, the write me an adding machine. Now write the multiplier. And at every step, you can prove that what you have built works. When you start top down, you might get to the bottom and find out you can't actually do it. You made an assumption about the latency of some system or other. But you do know from the very beginning that you're building the right thing.

And we've all had that thing where you build top down and you find out that, oh no, the database literally doesn't have enough latency to support this entire approach. We've also built bottom up and then found out that we climbed all the way up the ladder and found out the ladder was on the wrong wall.

MIKE: We’ve really run with Chloe's idea [laughs] about planning ahead of time and how that really is dramatically affected by scale. I'm curious, Jordan, what thoughts you have about the difference between large and small projects?

JORDAN: Yeah. So, I would say that the biggest thing I face, well, not face, but experience, and maybe this is just, like, the difference between working, like, by myself versus working in a business, was the need to get approval on many ideas and, like, changes to move in a certain direction, I think. So, like, similar to, like, the architecture and design, like, if I'm working on my own small project, I'm allowed to do, like, any change I want, like, willy-nilly compared to, like, here. Like, if I want to do something, I need to, like, propose it, like, architect out, and then, like, talk to people and get approvals there.

And so, I guess that's, like, I can have a radical idea, and then I present it to people, and then it's more, like, normalized into something that might work better for everyone, I guess. So, I guess that is the biggest thing I've experienced.

MIKE: You know, as I was preparing to host today [chuckles], I wrote down some notes. And one thing that occurred to me is that on a large project, you deal with coordination, which is a challenging human endeavor. And, you know, solo project, you're not coordinating with anybody but yourself. But when you get to a certain scale, you can't do it yourself. And now you have to add in another layer of complexity, which is how do I make this work with other people [chuckles]? Maybe I need version control so I can share this with somebody else, so we don't step on each other's toes. Maybe we need an API contract that we agree on so that [chuckles] when I send a message, they can actually receive it.

And working together is hard because you have to get shared understanding, and that takes a lot of work. It's the only way we can build big things. And the more big and complex, the more work that requires because the things have to be precise, right? And you have to have an interface that actually aligns.

I think that sometimes we think, well, there's all this bureaucracy. And, I mean, bureaucracy can be heavy handed. It can also be a representation of the natural work involved in coordinating across groups. You're going to have to have hierarchies of information that travel upward and then are coordinated between each other, which sounds a whole lot like bureaucracy. And it exists for a reason. Now, it can be misused like any tool, but it's going to have to exist because the alternative is anarchy, and then you can't coordinate anything at all. And that's not our goal.

And Will made the point about balance being so fundamental. I agree on that in many ways. I think finding a balance is tremendously important. But my key idea here is that you're going to have to do some coordination. And the bigger the project, the more coordination you're going to have to do.

EDDY: Well, you have more hands in the pot, right? So, you've got to satisfy more people.

MIKE: And that's not free. So, yeah, big project, you're going to have to get signed off. You're going to have to get people to agree with you. You might have to find a consensus or at least get somebody to make a decision [laughs].

DAVE: Jean-Paul Sartre, "Hell is other people," or in our case, hell is other people's code.

MIKE: On the flip side, I was reading somewhere sometime in the last month. I would have to go find the code. I don't have the source on it. But it was a researcher on human happiness. And if I remember the quote correctly, it said, "Happiness is love: Full Stop." Which is to say that hell is other people and so is heaven.

DAVE: Yeah. Yep. I heard a good one on this today, or last week, which is happiness is your circumstances minus expectations. I thought it was kind of interesting. Being present where you are instead of looking over the shoulder of the present moment to see the next problem that's coming.

MIKE: So, Jordan, you talked about the coordination that is involved in working on a larger project. What does a big project look like structurally versus a small one?

EDDY: I'm not exactly sure I understand your question. I mean, if you were designing a new service or whatever, I'm sure you have stipulations on things that you have to meet. In order for that service to work, you have certain metrics. You have certain clients that you work with. You have certain design that needs to fit. I'm not entirely sure I understand how broader than that you're asking.

MIKE: Well, let me give you an example. Let me give you my example. So, at Acima, we've done a lot with Ruby on Rails. It's been a popular web framework for a couple of decades now. And it gives you its particular take on model-view-controller architecture. Here's where your database interface layer goes. Here's this models directory. Here's where your interface goes to the outside world, you know, your controllers. Here's your views. Here's your templates that you're going to use to display things to your end user.

That works really good for a small project. You build a blog. You can throw everything in that structure, and it just works. If you have a large multi-year project, it doesn't answer hardly any of the questions because most of your business logic doesn't quite live there. And it might be needed to call from background jobs, and I could go on and on.

And so, you're going to build a massive set of business logic, some sort of structure to represent your business logic that is behind the scenes and not in that model-view-controller. Now, you might think of it as a logical extension of one of those. But if you try to cram that all into one of those out-of-the-box layers [chuckles]...I'm seeing looks of horror [chuckles] from people on the call. It ain't going to work. The scale deeply matters to the architecture, to what your code looks like.

MIKE: I heard this talked about by Uncle Bob. What's his last name?

DAVE: Bob Martin.

MIKE: Martin. He said that if you look at blueprints, you can generally tell what kind of building it is.

DAVE: Oh, I like that.

MIKE: But sometimes when we start building with a framework, we say, “Oh yeah, it should look like the framework.” No [chuckles], he says, “That's wrong. In a large project, it should look like what your business domain is.” So, you can look and say, “Oh, okay. I see what you all do. You know, here's the kind of the center.” It's centered around...you probably have a directory representing your primary business domain.

If you're doing something in finance, you're probably going to have something financial, right, at the center of your business logic. And if it's not structured like that, if instead it says, “Oh, here's your multi-controller,” then you're going to have an awkward time because it's built around your tool rather than built around your business.

DAVE: I was on a team once where my assessment after six months on the project was I stepped back, and I said, “I don't know about anything we're doing in the business to make money, but we have written an amazing program to support a database.” We were so bottom up. We were just, like, get the database, get the database. Everything had a table; everything had a trigger everything...da da da.

And a year and a half later, very little stuff to support the actual business. It was a Greenfield project, like, an investor's baby, where it's like, go do this, and do this for me. And so, we had a lot of funding. And after a year and a half, we started having some difficult conversations about what was coming out of this money. And I'm like, you got a nice program about your database.

MIKE: So, you talk about the structure needs to be different. How can we use some of the things we learn from small projects? Yeah, go out and build a small prototype in school. So, Jordan, Chloe, in school, you build a lot of small projects. You can almost think of those as prototypes, right? They are very purpose-built, specialized things to prove a point that you'll never actually use in the real world [chuckles]. But you do it to learn about something, and we do that in the business world as well, right? We want to learn how something works. Would this idea work? If we try this out, is it possible? So, we build these prototypes.

That prototype is probably going to have all kinds of bad decisions. You're going to have to rethink to build the real thing. But how can we apply what we learn from the small projects to the big ones? Is there any carryover? Do you have to learn an entirely new set of skills? Going back to what I was talking about in the beginning about navigating in your neighborhood, have you learned anything there that you can actually apply to the larger problem?

EDDY: I've learned to play nice with other people. I think it's really key. And be very receptive to feedback that you otherwise wouldn't.

MIKE: So, you're saying a large project, the larger the project is, the more the human element matters?

EDDY: 100%. You can't just make changes willy-nilly, assuming that it's a benign change. You've got to have adoption across the board. So, it takes a lot more coordination between everyone.

DAVE: That poked my brain. We were having a chat in the engineering...actually, Mike, you started it. We were talking about how does AI help you? And somebody pasted a tweet from DHH that said, "When I use AI as my pair programming partner, it's really skilled, really good. When I let it drive, I stop thinking. I retain nothing, and it's useless."

And, in my mind, that's very close to what you just said about do we build a prototype and then leverage it? Or did the AI build it for us, and we've got nothing? We used to be raised on "build one to throw away," right? Because you're going to learn so many lessons from building the first one. And the important thing is to throw it away when you're done because you've made so many mistakes. Don't fix them. Just build the new one without the mistakes, right? And, like, in AI, if you let it just do it for you, that's not a prototype. You can't leverage that much anyway.

MIKE: That's interesting. You didn't learn from it because you didn't build it. Cheating on your homework.

DAVE: Yeah. And there's times when that's valuable, though. I needed a thing that would log in with Google, right? Just OAuth. Simple. I’ve built three of these in five years. I've been on teams that have built 50 of them over the years. And I’m like, can't remember how to do it. AI, go build this login for me. I don't need you to learn me how to make an OAuth login. It's a small problem.

EDDY: For the listeners, I don't know if we have anyone out of state, but here we're in Utah, right? Salt Lake City area, whatever. If I have to drive to, I don't know, like 30 minutes away to another city, typically, I will drive there. I know exactly how to get there. I know all the directions. I know what the subroutes are in the event that the road is closed or whatever. At that point, it's just becomes routine, right? Like, I’m on autopilot, and I have to just do it for the sake of just doing it because it's expected of me to do it.

It gets to a point where I'm just like, dude, if I had an autopilot on my car, like a Tesla or whatever, I already know how to do it. I don't have to focus to do this because I already know. So, I'm just going to tell it to do it for me, and eventually, we'll get to the same spot, and I know that I got there.

So, like, for mundane tasks, you know, where you know 100% you can catch issues or bugs early or whatever, I would say that's fine. But when you’re having to go to a different place that you've never been to before, you're a lot more attentive, and you’re running the risk, you know, of autopilot kind of telling you where to go without paying attention. So...

DAVE: You just synthesized the thing that we've been talking about this entire time. Prioritizing the future value or assessing the future value of the knowledge and the skill. Driving somewhere, you can't manage a 70 mile an hour night knife fight in rush hour traffic when you are still learning clutch, brake, shift, right? You've got to get the basic skills in.

I've got a note on my monitor that says, “Insight is not cure. Get it under your fingers.” Now, this is a guitar teacher that told this to me. He's like, you can't be thinking about chord, voicing, mood changes if you don't know where your fingers are, and if you don't know where the notes that you need to target are.

And peeling that back, when I told the AI, “Go build me an OAuth login,” I put no future value in me learning that, but I have in the past. 20 years ago, I sat and sharpened the whetstone in software of, like, I'm just going to build this thing. I'm just going to do just this pattern. I'm going to do just this thing. You have to get those skills under your fingers then you can start mentally composing the larger things built out of that fluently, fast enough that you can actually start to create (I'm muddling my metaphors horribly.) but so that you can create music in your software in how you develop it.

And what you just said about driving, to me, it’s the same thing. You start composing those things. And it's all based on, the decision I'm making right now, what is the future impact? What is the cost of it? What is the value of learning this skill? Prioritize later, I think, is what I've heard that said. Not put prioritization off until later, but right now, prioritize the things that will create value later. And when enough later has gone by, you're going to be up here instead of right where you started.

MIKE: So, we talked about building fundamentals, because they will still be useful in the larger structure, but they'll be composed. It'll be made up of many of them. I’m hearing that from various voices here. Suggests that learning your skills on small projects and doing that schoolwork without cheating actually gives you something that will provide value as you work on the larger things because it will give you those components you'll know how to put together. And you may not know how to put them together yet, but if you don't have the pieces, you can't even start.

Well, I think that brings us to a pretty good place. We talked a lot [laughs], a lot, a lot about making decisions and about not getting mired in too much decision-making, but trying to find that right spot where you make a good decision and continue to make decisions, continue to pivot and get feedback rather than getting stuck.

We’ve talked about the human aspect, about the absolute critical human aspect on large projects because that's where maybe most of the work is. Well, not maybe, that's where most of the work is, is in coordinating across the other people so that you can build something bigger together. And we've also talked about building up from small to large. That's pretty good for an hour, if you ask me.

Thank you, and until next time on the Acima Development Podcast.