Working Software

Mike hosts this episode with Vivian Moore, Kyle Archer and Eddy Lopez, and Matt Hardy and Will Archer join partway through. Vivian suggested the topic: how developers keep their skills sharp when AI can write the code for them. Mike opens by asking why kids still learn long division when everyone has a calculator. Kyle quotes a UVU professor who said math is really about learning to think and break problems apart. Vivian adds that working through older concepts shows you how small ideas build into big ones. Eddy connects this to AI. He hands routine work like templates and specs to his agent, and when he tried writing a PR by hand, he had forgotten how to write a describe block. Mike mentions interview candidates who froze when asked to write code without their agent. The group disagrees about whether AI makes engineers weaker or stronger. Will says he has never been better at code review, because he reviews so much AI output. He also learns by asking the AI to explain its patterns. Matt recommends turning on reasoning mode and keeping tasks small, the way you would when pair programming. For older, messy codebases, he has the AI document a domain before working in it. Mike cites Anthropic research titled "How AI Assistance Impacts the Formation of Coding Skills," which studied 52 mostly junior engineers. The group that handed off the whole task finished fastest but understood the least. The group that used AI as a coach finished second and understood the code best. Vivian, speaking as a junior, asks how she can grow when the AI improves as fast as she does. Will points to chess "centaurs," human players paired with engines. Vivian counters that engines trained only by playing themselves now win anyway, though she agrees programming is much harder than chess. Will also argues that tools like Claude Code push you to hand over the problem and walk away, and he suspects that design serves the vendor's business model. Matt says people lose jobs when they refuse to adapt, and AI itself isn't to blame. Mike pushes back with the example of factory automation. Someone caring for an aging parent or living with a learning disability can't always retrain, and if change gets fast enough, nobody can keep up. Will cites a statistic that the dot-com era cut 2.8 million clerical jobs and created 4 million programming jobs. From there the talk turns to job titles and to engineers as productively lazy people. Mike wrote a quadratic formula solver in junior high, and Vivian did the same for box-and-whisker plots. Mike wraps up with the idea the group kept coming back to: engineers are paid to solve problems, and anyone who defines their job as writing code will see that job disappear. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting it today. With me today, I have Vivian Moore, Kyle Archer, and Eddy Lopez. And we've all been here before numerous times, so [laughs] no deep introductions are necessary. We have a great topic today, and this actually came from Vivian. Vivian's new-ish, right, to Acima and Upbound, and bringing lots of great thoughts with good discussion topics coming from this kind of outside perspective. So, her ideas may be driving a few of our discussions for a while. But today we've got a topic, and I actually am going to do something a little different from what I've often done. I'm going to ask a question to this group here before we dig in. So, why do we still learn long division? EDDY: You guys still learn long division? Just kidding [laughter]. MIKE: Yeah, I have been helping my kids with this, so yes [laughs]. It's a thing that still happens. And why? I mean, why do people...I mean, students in a certain year, they learn long division, just like they have for many years. EDDY: Can I ask, like, a wider net...or adding to that, has the way that we've done long division changed since then? I've seen videos on YouTube where, like, teachers are sort of reinventing the way they're presenting mathematics to kids, right? And so, like, how we learned how to do multiplication, for example, has suddenly, like, vastly changed, you know? And, like, there's, like, a new approach to get to the same solution. I'm curious, like, if the education system has reinvented, like, how long division... MIKE: What you're asking is important. What you're asking is if they're using the same algorithm that was taught historically, and the answer is, mostly. For multiplication, they often teach a different algorithm besides the traditional one because it's helpful for doing it in your head. And it's often the way I do it in my head, which is you do, like, 123 times 223. Like, oh, how do you do that? Well, if you do, like, the hundreds first in your head, okay, and you get an answer, and then you do the 20 times something first, you know, and then the 3 times something, and then you add it all together. That's basically the other algorithm they teach, is to think about it in parts that way rather than them working right to left. You can do it either way if you think about it that way and then add it differently. So, yes, different algorithms. And I think that you're hitting on something there, which is the algorithm isn't the important part, right? They teach that algorithm because it's helpful to know, but you're never going to use it again. Because if you want to do some long division, you're almost certainly not going to pull out a piece of paper and pencil and start doing it in your head. You're going to pull out your phone and start doing it on your calculator, right? Or you just, honestly, you're just using your search engine because it's going to go call a tool and do it. KYLE: I'd quote my UVU professor, because it was something where, you know, you started getting into the higher forms of mathematics, meaning calc two, calc three, and he said it really doesn't matter at some point. It doesn't. It's we're teaching you to think. It's how you're debugging; it's how you're breaking things up; it's how you're segregating how you solve a problem. That's why we still learn it, in my opinion. MIKE: I think that's exactly...I mean, I asked the question, you know, leading, you know, digging for an answer. Yeah, we don't teach that algorithm. We don't teach long division because it's ever going to be important directly in your adult life. It's because understanding how it works...and, in fact, I think that we do a lot of harm by saying, "Oh, long divisions means you use this algorithm," rather than saying, "Hey, there's a way you can do this by hand. And if you think about it, well, cut the hundreds into pieces, right? And then cut the tens into pieces, and then cut the ones into pieces, and you can make that work." And even if you don't necessarily understand all the little details, you have this idea that you can start it and get kind of a rough answer and then get more refined as you go. And that's a great idea. I think we should teach it better. I think we should teach math better in a lot of ways. But that learning to think really matters, and then the algorithm, eh, maybe not so much. Calculator's fine. VIVIAN: One other piece of that I'd actually like to add is that, I think, beyond just teaching you how to think, teaching old concepts that you won't necessarily use again in the future, even more advanced concepts, especially, like, as you're starting to get into those calculus areas, are often prerequisites for understanding how someone in the past got to the conclusion that they got to about the advanced mathematics. And understanding those kinds of building-block pieces, something that I really like about 3Blue1Brown's work, for example, helps you feel like you could have gotten to the answer on your own. And doing that allows you to piece together the foundations, which, in addition to teaching you how to think, also teaches you the patterns of how little pieces build into big pieces, which I guess is an additional piece of teaching you how to think, but kind of a broader picture of that. MATT: That's a relevant conversation to the problems we are facing today. And it's funny, you and I were talking about calculus yesterday, Mike. MIKE: By the way, we have some latecomers to our call. We've got Matt Hardy and Will Archer. And I haven't formally introduced the topic yet because I started a little differently and asked the...I started with a question. Today, I would like to talk specifically about how to keep your brain sharp, how to keep your skills meaningful, and your, you know, your ability to think and to build things going in an AI world where you've got all these tools that can do it for you. EDDY: So, keeping in theme with mathematics, one thing that I immediately drew to is, when we're talking about dependency, right, like, specifically, like, the dependency of AI, I attributed using a calculator to do long division similarly to how we'd have AI, you know, is to us programming, right? In a sense, you're sort of cheating, right? Like, you're shortcutting the thought process of getting to a solution by asking something else that will pop out the answer for you, right? So, if I'm in school and I'm learning long division for the first time, my innate reaction is, "Oh man, this is really uncomfortable. I'm just going to pop in: 'What's 10 divided by 2?' This is going to give me the answer, and we'll just move on," right? I feel like it...there's a very similar pattern there with AI. "Oh crap, I don't know the answer to this. Ah, screw it. I'm just going to ask the AI to give me the answer." Well, like, what benefit are you really getting from that long term, right? Because the moment you don't have a calculator, the moment you don't have the AI, what the freak are you going to do? You're back to square one, right? So, I think that's the parallel we're trying to draw here, right? Is how do you keep your mind sharp, right, when you have a

This week on the Acima Development Podcast, Mike starts with the fall of the Roman Empire. Rome guarded its borders with largely autonomous armies. When attacks came from too many fronts at once, the empire couldn’t hold them all off. Mike compares that to where software security stands today, now that AI puts world-class vulnerability tools in reach of attackers well beyond nation-states. Joining him are Justin Ellis, a longtime security engineer who now works in OT, and Tim Chaffin from the Acima security team. Will Archer brings experience from several large corporations, and Vivian Moore offers the view of someone who just finished school. The panel spends the first half on how fast the timeline has collapsed. Justin says attackers used to sit inside a network for 150 days or more before acting. Now an AI-assisted breach can go from first crack to ransomware in minutes. Tim says big telecoms take about 43 days to patch a critical vulnerability, but a proof of concept posted on a dark web forum gets exploited in about five. He also describes DEF CON capture-the-flag teams who handed their recon work to local models. Will notes that AI makes finding exploits easy, while writing a kernel patch remains beyond most developers. Vivian pushes back on Will’s idea of cutting hostile countries off the internet. Cheap streaming sticks and TV boxes sell their owners’ connections as residential proxies, so blocking by geography won’t hold. Mike then lays out what teams should do. His first step is constant observation, with automated watchers that block abnormal behavior without waking anyone up. His second is patching critical vulnerabilities within a business week, which Tim says only works with automated testing in the pipeline. Mike also wants teams to attack their own systems, the way Netflix’s Chaos Monkey shut off infrastructure on purpose. Tim adds countermeasures for specific AI threats, such as FIDO2 passkeys against AI-written phishing. His team is also building scripted proof-of-concept tests so patched vulnerabilities can’t come back in a new release. The group closes on people as the weakest link. Tim describes a phishing email that spoofed his dad’s name, and Justin raises deepfake scams aimed at older parents. Mike ends with a call to act today, because the barbarians are already at the gates. 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 have Justin Ellis, Will Archer, Tim Chaffin, and Vivian Moore. And I'm going to start with a topic that I usually avoid. I'm going to talk about the Roman Empire. I avoid it for a few reasons [laughs]. You know, there was all the, what was it, 2005 or so, they...there was all the social media stuff about adult men thinking about the Roman Empire multiple times a week. If you haven't seen that, it's a thing out there that have girlfriends ask their boyfriend, "How often do you think of the Roman Empire?" And they're like, "Oh, I don't know, a few times a week." And they're like, "What? Who think..." [laughter] There's this weird gender divide. I don't follow social media much, but it was enough that, you know, it made a thing, like, made the news. It can be kinda trite, and also, I think, people sometimes portray it as like, "Oh, well, the Roman Empire fell. What a tragedy," and well, in some ways, yeah. But, I mean, it was this brutal, violent entity that destroyed the lives of many people for what cause? So, you know, you can make arguments for and against. My point is that it's a complex, morally and ethically ambiguous topic to talk about the fall of the Roman Empire. So, I'm not going to dig into all of that. But I am going to say [laughs] that there was this entity that is commonly read about in history where there was a large, complex system that existed, you know, along the coast of the Mediterranean and Southern Europe for hundreds of years. And they were able to maintain that for a long time, right? And eventually...and they managed the borders of the empire by having armies that were largely autonomous, right [chuckles]? Somebody would build their own army and go out and man the frontier, you know, walk along the frontier and expand it and take spoils as they chose [laughs]. And there eventually were so many different attacks coming from, particularly from the north, that they couldn't wage, you know, defenses against all of those fronts. And they had not kept their defenses up, and they'd been kind of rot from inside for a long time. And, eventually, those attackers made it all the way to Rome, and, you know, Rome was sacked. And there's still holdouts of the Roman Empire today. I mean, the city still exists. There is a Rome. But after the Roman Empire broke up, you had a series of smaller city-states, right? And you had what we, you know, the medieval era, where you had easier-to-defend smaller units that could defend themselves more or less autonomously. Probably couldn't defend themselves against a big attack, but you moved from, like, a monolith to microservices kind of idea [laughter]. And, you know, there had to be that fundamental change. I actually read an extensive article about this once. It said that the...you know, it's not definitive, right? But that the complexity of the Roman Empire was too much to sustain. They didn't have a system for managing that complexity, didn't manage their defenses, and eventually everything fell apart, and fell into something that could be managed because each of those units was less complex and could be managed by the systems they had at the time. Fascinating idea. Where am I going with this [laughter]? TIM: Yeah, where are you going with this [laughs]? MIKE: The barbarians are at the gates [chuckles]. We have a rise of AI now, and the tools that are available to exploit vulnerabilities are now potentially world-class, available to not just nation-states, but...you know, and maybe not quite the script kiddies, you know, somebody in the basement thinks, "Hey, what can I do here?" But getting close to that level. Some of the main things that are preventing it right now are cost. And some of the large frontier models are, you know, big companies publishing frontier models are holding back the strongest functionality for vulnerability detection because they know they can cause so much trouble. There are a couple of projects out there, Project Glasswing from Anthropic and Project Daybreak from OpenAI, where they're partnering with large government and business entities to try to test their systems, test libraries, and get things hardened because the clock is ticking. In some ways, we've already reached the point where it's starting to tick up. We're already seeing news items all over the place. If you look at your logs in your servers, you're probably seeing attacks. You've always seen the kinda script kiddie kind of attacks. Low-hanging fruit have been out there for a long time, but it's ramping up, and I'd like to talk today about what we can do about it. I've got some thoughts, but with...we've got Justin Ellis here. He's a long-standing security engineer who has worked in Acima in the past, but is not currently. Tim comes from our security team. Will has worked for a variety of large corporations [laughs] and can speak from that perspective. And, you know, so I think we've got a good crew here. And Vivian's recently come out of school, so she can talk about [laughs] things from, you know, the perspective of somebody coming to the industry today, because it's very different than the industry looked five years ago. You know, we're in a different world. I do have some thoughts on here about some tactics we should be doing, but I'd like to stop talking myself and get some initial thoughts from y'all. JUSTIN: So, just one thing: I'd like to, like, share the current status, and then, you know, other people can share. It used to be where somebody would crack a network or crack an organization, and then they would sit in that organization, you know, hidden inside their network, trying to scout out other things that are vulnerable inside and slowly go through that and spider web, and then do something with it, whether it's a ransomware, or something like that. But it was, like, the average time that they were in that network was, like, measured in, like, 150 days, so it was measured in, like, 100-plus days. Now, if your outer defenses get cracked, you can lose your inner devices almost instantaneously because of the AI assistance that is part of that attack. And they can go out and, you know, crack all of the vulnerable devices inside your network very, very rapidly and then decide to do something with it almost autonomously. I mean, that's the whole point to the AI, right? And it's making it such that the, you know, crack to ransomware or, you know, compromise of your entire system is measured in minutes rather than, you know, days, where it used to be, you know, hundreds of days. And so, it's just a very different landscape for cybersecurity than it used to. So, I'll just leave that there to start off with. TIM: The median time for groups like Verizon or big telecommunications groups to patch a zero-day or something that, like a CVE 10, 9, somewhere in there, something that's pretty critical, is about 43 days. And with the advent of AI, the average time from exploit PoC publication on a darknet or a dark web community to demonstration of that exploit being exercised is about five days now. So, someone will find a zero-day, put it on their forum, and then people with enough GPUs to run Kimi 3 on their local rig at home will then use that PoC to then roll out a campaign against, you know, against whatever their intended target is. And they'll pop a target faster than that target will ever be able to roll out a rolling update or some kind of change to fortify against that. So, at this point, every security engine

This time on the Acima Development Podcast, Mike opens with Nitinol, the nickel-titanium alloy developed at the Naval Ordnance Laboratory that can be bent far out of shape and spring back more or less indefinitely. NASA has prototyped woven Nitinol mesh wheels for future rovers, which would spare them the battered look of Curiosity's wheels after a decade on Martian rock. Mike uses the alloy as the frame for the episode's real subject, which is pressure. Pressure at work is not optional, and in the right amount it is what keeps people from getting bored, so the question is how to bend under it and come back to shape. Will Archer argues that anything worth shipping costs you something, and he quotes bodybuilder Ronnie Coleman on the gap between wanting to get big and wanting to lift heavy weights. He has stopped punishing himself for needing a hard push at the end of a project, and he describes recording studio days that come in 12-hour blocks as the same bargain in a different industry. Mike adds that the author behind "follow your passion" meant something closer to finding work you care enough about to survive the misery of doing it. Tim Chaffin brings in what cybersecurity calls ethical pressure, the practice of rehearsing failure through penetration tests and chaos monkey runs so that a real incident calls for calm execution instead of improvisation. He compares it to the expansion joints in a Florida causeway, which are built to split so the rest of the road survives. That connects to the "Antifragile" idea Mike read about, where a muscle under load gets stronger and an unused one withers away, and to a study finding that people in hunter-gatherer societies burn about the same daily calories as an office worker while spending them very differently. The back half is about the other end of the bell curve. Tim points out that chronic urgency produces burnout, turnover, and lost tribal knowledge, and that on-call rotations need real recovery built in. Will describes the drop that follows a launch, the sprint or two where nobody is any good, and the doom loop that follows when leaders crunch a team on promises the capacity was never there to keep. Dave Brady brings up Dan Pink's "Drive" and its three motivators of autonomy, purpose, and mastery, then contrasts a boss whose reward for a 90-hour push was "you get to keep your job" with an employer who handed out comp days. He also tells the story of an engineer who lost the company a lot of money and was sent back to his desk with the line that the company had just paid $25 million to train him. Mike closes with Balaji's habit of handing a promising person a hard project, checking in weekly without micromanaging, and thanking them specifically when it lands. His last image is riding in front on long bike rides with his son, setting a pace the younger rider can hold instead of letting him burn hot and crash. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me today, I've got Thomas Wilcox, Will Archer, Vivian Moore, and Tim...It is Chaffin, right? You know, I've heard people say Chaffin all the time for your name. It's Chaffin, right? TIM: It's Chaffin, but, you know, elementary school just damages us all, and I don't really know [laughter] what it is, so... MIKE: [laughs] Yeah. As usual, I'm going to start with a lead-in. I'm going to go to aerospace. There is a cool alloy I learned about a few years ago. I've looked it up in advance of the call to make sure I knew what I was talking about. They call it Nitinol, which sounds like it would be some sort of alcohol, but it's not. They just stuck some words together for nickel, titanium, and NOL comes from the Naval Ordnance Laboratory, where they developed it. So, it sounds like it's an alcohol, but it's not. It's just nickel and titanium in equal parts. That's really it. And they just did some very slight variation, like a few percent between equal parts, but basically, it's equal parts nickel and titanium. And it's got a few interesting features, but the one that I want to talk about is that it can be deformed significantly and spring back to its initial shape pretty much indefinitely. You know, normally, you know, you think, like, steel. Steel's pretty good at having some elasticity, right? But, you know, you bend some steel bar, you know, steel bar enough times, it's probably going to lose something. To some degree, it'll do well. You know, if you have some springs, you know, they'll spring back a lot of times. This nickel-titanium alloy is even better. It's just basically forever, you know, it'll always spring back, and it's relatively light. And they've made wire out of it and woven the wire into a mesh, and they're using that woven mesh. It looks kind of like chain mail-like, so it's not...It kind of retains its shape. And they plan to use it for wheels, and they've got prototypes of this for future rovers for NASA. So, instead of having a solid metal wheel like they have...And have you ever seen, like, the selfies that the Curiosity Rover takes on Mars? Those wheels do not look good. They've been [laughs] riding around on rocks for, like, over a decade now, and they do not look good [laughs], all kinds of big holes in them. Because they kind of fly the...you know, send the thing up on a rocket, so they make them super light. These nickel-titanium alloy wheels are basically just a...they're even lighter because there's...it's not like foil; it's just this wire mesh, right? Just this really thin wire. But they can put a vehicle on it, and it'll behave like a rubber tire because it'll spring back as many times as you want. Super light. So, it takes the pressure from the vehicle above, and as it goes, it just springs back. There was a Kickstarter a couple of years back where they were selling bicycle tires made out of this stuff, and I didn't hear about it till after. " Oh, that would be cool [laughs]." Because if you put that on your bike, you'll never get a flat again, ever, and it lasts for, like, decades. So, it's the last tires you ever have to buy. Just, it's a really cool idea. I guess it's an expensive alloy to make; that's why we haven't seen it widespread. But they use it...I guess there's quite a few usages of it in aerospace and other places where they really need something that's resilient. So, cool stuff. Worth looking up if you haven't looked it up before, and just, like, watching videos of it. It's pretty cool. It has some other cool properties, too, that are a little off-topic, but I guess you can put it to a lower temperature, bend it, and it'll hold that shape. And then you raise it up to the original temperature, it'll spring back to its original shape. Interesting stuff. And there is a tie-in here because today we want to talk about pressure and resilience under pressure. We often talk about pressure as a bad thing, but pressure is reality [laughs]. We're all going to be under pressure of some sort. We are paid to go do a job. You could say, "Oh, it just doesn't matter," and just wander off, and that's not going to work very well. There are demands. There are demands in life, and they're not going to go away. And, in many cases, pressure can even be motivating. Like, you know, if you don't have any demands, you can get bored. People actively seek out more interesting and demanding work and activities. People who are retired still do something interesting because they want to have a little bit of pressure. We don't do well without it. Then again, people break, right? Burnout is a real thing, and it's something we got to deal with. So, there's the topic for today. How do we get ourselves in a position so we're like that nickel-titanium alloy, you know? Pressure...under pressure, we bend, we spring back; we're good, and keep going. How do we get there? WILL: We all know about the bad parts of pressure. Those are pretty well-established. We've sort of, like, gotten over them, like, many times. Foundationally, I keep on going back to the two things that I think most people want, right? I mean, people want excellence, right? I think that's a foundational thing that, like, most human beings, and certainly most engineers, are driven towards excellence. And people are also driven towards growth. And both of those things, I believe, are uncomfortable. They're painful. They're going to hurt, you know? One of my favorite quotes is from a guy named Ronnie Coleman, absolute monstrous freak of a man, one of the legendary bodybuilders of the world, and quite the wordsmith. And I quote, "Everybody wanna get big, but ain't nobody want to lift no heavy-ass weights." [laughter] You know, it sums up so many things in life. Getting the opportunity in the year of our Lord 20-odd-26 to work as a professional engineer is hard yards. People struggled for years. Even me, who grandfathered in in Gen X when it was, quote-unquote, "easy," I saw the wrong side of midnight a whole lot. I spent a lot of nights and weekends studying to, like, get an opportunity to do this thing. And if you can't deal with pressure, if you can't push yourself to an uncomfortable level of effort, it's hard to imagine people being successful or people being very good at this stuff. For a long time, I have held as my, like, sort of platonic ideal, like, a good marathon runner pace as what I aspire to in my professional career, right, like, where I'm running hard, and I'm feeling it, and I'm hurting. If you run for a long distance, it doesn't feel good, you know? But at the same time, like, you are in a flow state. You're rolling. You're in this pace that works. But as I've sort of gotten older, I've maybe come to a level of acceptance of, like, how I work and, like, kind of how everybody works forever. It's very rare, very much the exception rather than the rule, that if you're going to do anything, if you're going to accomplish anything, if yo

On this episode of the Acima Development podcast, Mike hosts a conversation about software development life cycle methodologies, opening with the line usually attributed to Mike Tyson: everybody has a plan until they get punched in the mouth. He illustrates it with a day from about 20 years ago in the suburbs of Chicago, when he and his wife planned to collect a free piano from an elementary school and a bunk bed with a slide from a seller farther south. The U-Haul turned out to be an hour away through traffic, the truck had no ramp, the movers he had hired gave up waiting, and the piano sat at the top of two flights of stone stairs. His wife's idea rescued it. They offered the movers' money to a construction crew working down the street, and the crew carried the piano out. Mike got home around 11 that night. From there he lays out the history, from the linear process Herbert D. Bennington documented in 1956 and nobody called Waterfall until the mid-1970s, to the 2001 Agile Manifesto, which he points out is four stated preferences rather than a process. The group resists the idea that Waterfall is simply obsolete. Justin notes that it got NASA to the moon on a budget worth several percent of GDP, and Kyle adds that it made sense when software shipped on CDs you burned and mailed, because there was no pivoting after the discs left the building. Dave recounts building the REALImage 3000 graphics card at Evans & Sutherland, where the chip spent six months in the fab and came back with two leads soldered backwards. Red and green were swapped, and the team had to write a very fast post filter to correct every pixel of every frame. He connects that to lean's idea of inventory, where the assumptions you have not verified bite harder the longer you carry them. Vivian questions whether Apollo was really Waterfall at all and argues the only genuine difference between the methodologies is the size of the planning scope. Will keeps pulling the conversation toward the business side, since engineering tends to love Agile while the people committing to quarterly numbers tend to hate it. Eddy floats a hybrid, Kyle calls it Wagilefall, and Mike credits Will with naming the version that fuses the worst of both: Whirlpool, because you circle the drain. The last stretch is about trust. Mike argues that iterative work only happens when leadership is genuinely willing to say go build something, which he compares to commissioning a Renaissance artist to paint a ceiling. Vivian asks whether psychological safety runs both directions, since managers also need confidence in their engineers, and wonders how an engineer earns that upward. Matt answers with communication and honesty about what might not work, and takes the position that a bad hire is the hiring manager's failure rather than the hire's. Thomas describes trust as a currency that compounds as you show progress. Mike closes with his friend's dairy farm, where the manure is unavoidable but gets washed into a reservoir, fermented, and spread on the fields. Software works the same way. You will not avoid the mess, but you can build a process that deals with it as you go rather than leaving one enormous pile to land in at the end. Transcript: MIKE: Hello and welcome to the Acima Development Podcast. I am Mike, and I am hosting again today. A little side note: Acima has a parent company, Upbound, and we're fusing more. Like, we're more of a family or a team or something. Like [laughs], somehow we're getting closer together. So, we may be putting Upbound in the title in the near future, so don't be taken by surprise if you're listening regularly. That's it. And with that, as usual, let's...Oh, I should introduce people who are here. We've got Dave; we've got Thomas; we've got Ramses; we've got Justin, Kyle, Eddy, and Vivian. I think we've all been here before, so we'll jump right in. I'm going to first reference a quote by Mike Tyson. Actually, it probably isn't by Mike Tyson, but it's attributed to him. I looked this up, and I guess there's no, like, clear connection, but he may have said it. And the quote says, "Everybody has a plan till they get punched in the mouth [laughs]." Whether or not he said it, he probably had the same idea. He probably had the idea at some point. And, you know, there's this idea plans don't last very long once you get into, you know, sparring. I was thinking of plans that I've had in the past that have failed. I had, like, a simple one. My family and I were going on vacation. As we went in the garage, literally in the garage, we were grabbing something out of the fridge before we left and noticed that the fridge wasn't running. Like, "Oh, that's not going to go very well for everything sitting in the fridge," and, you know, I had to redo the plan. But I got a better one that was further back. About 20 years ago-ish—it was a little less than that, but approximately 20 years ago—I determined there was a few things that I needed. My wife and I decided, oh, we need to get a couple...two things. There's two primary things we needed to get in the suburbs of Chicago. One, we found out that there was an elementary school that was giving away all of their pianos. They didn't think they needed pianos anymore. We thought, "Oh, great, we'll get a free piano and bring it home, and then we'll have a piano," because we didn't have one. So, we thought, "Oh, that'd be great. We'll get the free piano. We'll just have to pay to get U-Haul to bring it home." We also found that there was somebody farther south in the suburbs that was selling a cool bunk bed that had a slide, and it came down at the top bunk so you could take a slide, you know, it was cool. And we thought, "Okay, this is what our son needs." Came up with plans. So, I took work off that day, and I called U-Haul and asked them to find a location near where the piano was where I could pick up the truck, so I wasn't driving the truck through, you know, Chicago traffic. I'd pick up the truck, drive over to the school. I called some movers, and I was going to pay them to meet me at the elementary school, load up the piano, put it in the truck. And then we were going to drive down and pick up the dismantled bed from the house of the woman who was selling it; drive home, roll the piano down the ramp because, you know, you're going down. We could do that when we got home and pull everything off. Made all the plans. I got up, drove to the U-Haul facility, and found out that the U-Haul people had no idea what they were doing. And it was at least an hour away through dense traffic and neighborhoods over [chuckles] to the elementary school. You know, this was 20 years ago. This was before...You know, technology has advanced a lot. In those [laughs] years, they didn't have anything, and thus began the series of [chuckles] things that went wrong. We, like, "Well, this is the U-Haul we get." Turns out the lift haul that they had gotten for us also didn't have a ramp in the back. It just had a low bed. So, anything that went in and out had to be lifted in and out. Remember, this is just my wife and I and my, like, three-year-old son [laughs], and a very heavy piano. Like, "Well, this is what we get, I guess." And it took a lot longer to get there because of the traffic than I expected. I call ahead to the movers and asked if they could wait a little bit, but in the traffic, it was going to be, like, two hours. We weren't going to get there until hours after the movers were supposed to meet us. And, in fact, it took us so long to get to the elementary school that by the time we got there, they were just about to close. So, there was, like, one lady who was there who showed us where the piano was. There was one left. The others had all been taken. Like, okay. And this is this...It was an old school in this fancy, old building with, like, two flights of stone stairs being the only way out, and a really heavy piano, and my wife and I [laughs], and a truck with no ramp in the back. Like, oh, okay. It turns out we actually...There actually was an answer here. And my wife says, "You know, when we were driving down the street, I saw construction sky...There was a crew of people working there, crew of guys there building. How about...You had the money that you're going to pay the movers," you know, because they'd left hours ago. There's no way they were going to wait for us. "How about you offer them the money to come in and haul the piano down the stairs and into the truck?" Like, that's a good idea. Drove over there, and they were willing. They're like, "Yeah, sure," because we had, like, 100 bucks or something. Like, "Yeah, I'll do it. Sure. Free money." Well, not quite free, but close enough, because it was a big crew of burly guys. So, they picked up the piano, took it down the two flights of stone stairs into the truck. Okay, yay, we're that far. Next, we had to go pick up the bed, and the lady there had an appointment that night, and we had to...In order to get there ahead of that, we had to get there in, like, 30 minutes, and, by this point, it was rush hour. About two hours later [laughs], we arrived at her house. Luckily, she was really nice, and she had gone to her appointment or skipped her appointment just so she could get us the bed. I was so thankful [laughs]. There was no way. We were just driving through, you know, stop-and-go traffic for hours waiting to get to that place. And so, I was incredibly grateful. Finally, so now we've got the piano; we got the bed, and started driving toward home. And there was no way to get the piano out of the truck when we arrived there. And I had to have the truck dropped off that night, or I'd pay for an extra day. So, I called somebody. I called a friend. He ended up calling somebody else who had, like, three or four teenage boys [laughs] who were available. They ended up meeting us when we got home, and they came in, loaded up the piano, got it off the truck, and

In this episode of the Acima Development Podcast, the team digs into what happens to engineers when the org chart shifts underneath them. The timing is deliberate: Acima recently consolidated teams and realigned around value streams, the structure recommended in Team Topologies. Mike opens with sleep. After five years of falling asleep next to his youngest son, on the floor as often as the bed, he can now drop off anywhere. A habit he had held since infancy turned out to be trainable once he had no choice. Guest Seema joins from parent company Upbound on the eve of her 21st work anniversary. She traces a career that began in 2005 as a PowerBuilder developer in the servicing department, moved to classic ASP corporate applications when that department closed, pivoted to call center and IVR work during COVID, and landed on the RACPad point of sale team about six years ago. Six or seven office buildings and more reorgs than she can count later, two things have kept her there. One is staying relevant, which for her meant telling leadership she was bored and asking for harder work. The other is the community of coworkers she can call when a deadline like the RACPad Mexico rollout gets tight. She recommends Mel Robbins' The Let Them Theory and Simon Sinek on finding your why, and she starts her mornings by counting small wins. The rest of the panel pushes on where acceptance ends. Dave argues for judging change by its trade-offs instead of by good and bad, and defends leaders who cut through a stalled debate even when half the team ends up unhappy. Vivian, an intern about to join a new team, describes trust in the people around her as the thing that made two months of constant change workable, and notes that strong engineers tend to hold tightly to one or two things and stay loose about everything else. Jordan brings the counterweight from a startup acquired by a large bank, where the rules could not be changed and the honest options were acceptance or an exit. The point everyone converges on is the why. When leaders explain their reasoning and take feedback seriously, people absorb hard changes. When they skip it, the resentment is about not being heard rather than about the change. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. A bit of context before I give more of the intro. Acima is part of a parent organization, Upbound. And, you know, we've got people from Upbound that, you know, we have joined with, with lots of experience, which will be relevant today, as we've got Seema, who's joining us from, you know, from Upbound, who'll be joining our conversation today, will be very relevant for the conversation. But first, I'll give you a bit of an intro. I'm going to talk about sleep. So, you [laughter] ever tried to sleep in someplace different than your own bed [laughs]? And you know how hard that is. You know, it takes, like, days. You know, you go to a hotel, and you never sleep as well, wherever it is you have to sleep. And I think almost everybody has experienced this. It's a pretty universal experience, and something that I've historically had to deal with. A few years ago...it's getting to be a few more years ago now, probably more than five years ago. I used to be, like, a side sleeper and sometimes even sleep on my belly. And I did a lot of camping with my kids, like, in the backyard especially. And laying on your arm on the hard ground overnight doesn't do good things. And [laughs] I noticed that after a summer, like, wow, I'm getting tingling in my fingers. This isn't a good thing. So [chuckles], I had to learn to redo my sleep position, which was really, really hard at first because changing something that you've done for decades is just...it's a really hard habit to break, you know, something you've been doing since probably I was a baby, right? And [chuckles] making that change was really hard, and, eventually, I got used to it. I can now sleep on my back, roll over my side a little bit. It works. And then I've got [chuckles]...my youngest child is a terrible sleeper. He...well, let me rephrase that. He actually sleeps pretty well, but if he's alone, he just doesn't sleep well. So, I usually lay next to him to get him to fall asleep, and I've done that since...he's five. He's five years old. So, I've been...I had to do it so much, I ended up just usually falling asleep next to him, right [chuckles]? And I have fallen asleep on the floor. I have fallen asleep on his bed. I have fallen asleep somewhere in between the floor and the bed [laughs], you know, just about anywhere. And having dealt with that for the last five years, I'm to the point where he doesn't need to lay on my arm to fall asleep. He's okay with that. You know, I'll read a book to him while he's falling asleep. You know, he loves laying on my arm, but now he'll do without that. And I can usually go somewhere else for a while, but he'll still wake up in the night and say, you know, "Papa," and needs somebody there. So, I'll tell you, five years of sleeping in random places makes you get really good at dealing with sleeping someplace different, and now I can sleep anywhere [laughs]. I go to a hotel, I just drop right off, and I am fine. Uncomfortable, fine, you know [laughs], with sleeping on the floor, I sleep great. It doesn't matter. If you go through enough of these things, eventually it breaks you, and you're just okay. And [chuckles] I slept...I was traveling down to our corporate office in Texas about a month ago, and I hate hotel pillows. They always give me a kink in my neck. I got a terrible kink in my neck, but I slept through it anyway. I still got a kink in my neck a month later. Like, if you see me [laughs] wincing a little bit, that's why. But you know what? I still sleep fine. So, apparently, even though it's so hard to undo that, you can train yourself to be able to sleep anyway in different places. Today, we're going to be talking about dealing with change, particularly org changes, and all the changes that happen in an organization. You know, we like to hunker down and do our engineering work, but sometimes we can't always do that. Recently, we've kind of realigned our team structure to be oriented toward value streams, which is considered best practice in the industry. I mean, this is a pretty standard thing to do. There's a well-known book, Team Topologies, that goes in all the research about team structure that a lot of us have read. It says we should be doing exactly this. We have the stream-aligned teams, platform teams, enabling teams, complicated subsystem teams, is what they recommend. And, primarily, you should have these stream-aligned teams, and we've been organizing around that. We've been gradually moving this way for years, but, you know, we've really made a significant change where we consolidated some teams recently. So, it seemed timely to talk about change. Now, Seema has been with Upbound, I think, longer than any of the rest of us here, so she's a perfect person to talk to dealing with these org changes that happen over time. And you've survived, Seema, and you've survived it. And you're still here to tell the story, or more stories, and hopefully some dirt that we could hear [laughs]. So, that's the topic today, and tactically, how do you deal with it? Because it's disruptive, right? Anytime you have change, it's disruptive. It slows you down. It makes things harder, and it's painful; it's awkward. Change is not fun. So, what do you do? That's what we're talking about today. I'm going to start by opening things up. And do y'all have any initial thoughts, any of you, Seema or anybody else, about, you know, what do you do to deal with change? SEEMA: Yeah, what a great topic, Mike. But, first of all, thank you so much for having me here; what an honor. And, to be honest, definitely it's my first time to be on Acima Podcast, but it's my first time to be on any podcast. MIKE: [laughs] DAVE: Oh, nice. SEEMA: So, I'm super excited, but a little bit nervous as well, but looking forward to talking to you all for the next 45, what, 50 minutes, right? As I was mentioning earlier, talking about my name, in all our teams' transcriptions, you know, every time somebody says, "Acima" it shows up as Seema, so maybe it's time that I should change my name, right [laughter]? Well, that was one fun fact. Another fun fact about me, like, talking about how many years I have been here, Mike, I don't like to talk about this fun fact because I'm a little bit shy [laughs]. I don't want to share this, but tomorrow is my 21st work anniversary with Upbound, so yeah. So, I don't like to share it with people, but then, obviously, Mike has given me this opportunity to be on this podcast, so I wanted to share it with you guys. And I couldn't be more proud to be talking about RAC and changes and various reorgs we, or I, have gone through and still survived, I guess, you know? So, just to give you guys...can I go ahead and give a little bit of intro about myself, Mike? MIKE: Please. SEEMA: Yeah. So, I joined Rent-A-Center on August 8th, back in 2005 as a PowerBuilder developer. I don't know how many of you still remember PowerBuilder. It was a software used to develop the client-server applications. So, I joined as a developer to build applications in our servicing department. But then, I think, two or three years after I joined, they decided to close the servicing department because it was not cost-effective. So, basically, they gave the responsibility for servicing our items to the individual stores. So, at that time, I moved into our corporate applications department, the team that maintains or builds applications for the corporate departments, like HR, finance, legal, and things like that, right? So, I was...I learned ASP, classic ASP, not even .NET. We were not in .NET [laughter] at that time. So, it was classic ASP. So, I was doing corporate applications for a