Acima Development

Mike Challis
  • 4,5 (2)
  • Technologies
  • Toutes les 2 semaines

At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.

  1. -16 h

    Episode 106: Dealing with Change

    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 doin

    Episode 106: Dealing with Change

  2. 19 août

    Episode 105: Time Management

    On this episode of the Acima Development Podcast, Mike opens with military surgeons as his model for triage, doctors who decide fast and accept ugly outcomes because the only goal that matters is getting the patient home. He uses that to introduce time management, and Will immediately splits the problem in two, since a downed server and a rough quarter call for very different responses. In a real emergency Will cuts off limbs to save the body. He kills the API that is taking the server down, flags off the broken subsystem, or pulls a bad release, and he describes a feature flag as a tourniquet that stops the bleeding without killing the patient. Mobile complicates this because a shipped version cannot be clawed back, so the circuit breakers have to exist before anything catches fire. Kyle pushes on the harder case, which is triage when one boss wants revenue, another wants the release, and another wants one customer happy. Vivian answers with mass-casualty triage, where hospitals categorize patients by tag and pre-decide who gets treated, and Kyle counters that his problem is everything arriving tagged as immediate. That leads to the episode's core argument, which Matt states plainly: priority is singular, and juggling several at once means none of them get done well. Will adds that ranking the queue is a manager's first job, so a manager who cannot rank has already lost the plot and left the engineer to figure out which failure will cause the least grief. He admits he keeps a second thread going anyway, because the first one gets blocked waiting on another team. The panel gets specific about human throughput. Will puts a good work block at roughly two hours, task-switching cost at thirty minutes, and realistic coding time at about six hours a day. Vivian objects that productive hours vary by person and by life stage, citing her own 1:00 to 4:00 a.m. window in high school, while Will argues that a schedule nobody else shares collapses the moment you need to coordinate. Mike admits to twelve to fifteen meetings a day and triaging which of four stacked invitations to attend. Matt estimates that eighty percent of meetings could be eliminated, and the group agrees a meeting should be small and should end with a decision or an action item. On decision-making itself, Mike points to the psychological cost and to fear of being punished for a wrong call, which pushes teams into paralysis. Matt's position is that a decision beats no decision, and Will's tactic is to make the call himself, email his boss, and keep receipts. The last stretch turns to sustainability. Vivian argues that leaders have to avoid putting people in positions where every option causes damage, and she uses competitive swimming as her example, where teammates blew out their shoulders training twenty-five hours a week instead of the twenty they could sustain. Companies want twenty-year employees to stay another twenty, so breaking people the way a military breaks soldiers does not pay off. Mike compares it to parenting, where rule by beatings works at first and then works less and less, while respect and clear consequences take longer and actually hold. He notes that his own boss makes a point of leaving at 4:30 so the team sees what a normal day looks like, and stays late only when the situation genuinely calls for it. Mike closes with his personal system, which is early morning quiet time before the day fills up, often on a bike ride, where he picks the few critical items and launches them first so they can move through other people while his calendar takes over. Vivian gives the line the episode lands on when she asks whether the first priority should be prioritization, and Mike agrees. Transcript: MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With me, I've got Vivian Moore, Will Archer, Kyle Archer. We've got Eddy Lopez and Ramses Bateman. And I'm going to start off today by talking about military surgeons. I've not served in the military, but I've read about this. You can imagine that, in the military, particularly, you know, in, like, active warfare, there are a lot of injuries. And they've got to set, you know, a whole medical establishment within the military. The striking thing that I've read about...and, again, I haven't served there myself, so I'm speaking secondhand or thirdhand, having read about it. The military surgeons are incredibly pragmatic. That is, if somebody comes in and they're badly injured, they don't think about the plastic surgery this person might have to get later. They think, "I need to save this person's life. I want this person to walk away." And, you know, if they've got to remove the leg, they're going to remove that leg, you know, whatever it is they've got to do. I'm not going to go into the details because it's graphic [chuckles]. But, you know, they have to be exceptionally pragmatic about what they do. In general, they're not being sentimental. They're saying, you know, "What can I do to save this person's life? Everything else is secondary. How do I keep this person moving along?" And so, that's what they do. And they've got to deal with all the gruesome details of it. But because they are so concerned about making those decisions, making them early, making them immediately, right, and having one priority: how do I keep this person alive? How do I get this person, you know, home? They save lives. They make all the difference between that person going home and not going home. And those are tough choices. But if you think about the end goal, they're making the right ones. They've made the choice there that they're not going to get caught up in the stress of the moment because they care about saving somebody's life. We're building software. We're not on a battlefield. Hopefully, you're not on a battlefield. There may be some people out here, you know, building software for the battlefield. That does happen. But most of us are doing stuff that's much more mundane. But there's some lessons that we can learn there [chuckles], lessons we can learn about prioritization. So, I gave that intro because today we're going to be talking about time management. And if you're like me, there is...And, I think, like most people, there's more to do than you can do. There's always more to do than you can do, and sometimes it's just a complete torrent. There is such a constant stream of stuff coming in that you can't even think about it. You can't even think about prioritizing because it's just...it's just a flood. And that is a hard situation to deal with, right? It is an endless challenge. We were talking a little bit in the pre-call about how we all deal with this, and I certainly do. So, we're going to talk about that today because I think that it's something that we can all grow from. So, I'm going to start with thinking about these military surgeons as the kickoff point and their pragmatic prioritization with a solitary goal in mind, because I think that's a great place to kick this off. And rather than add anything else myself, because I've been talking for a few minutes now, where would you all like to run with that? WILL: Well, I just want to...I want to narrow this down to, like, are we talking about an emergent situation where the server is down and you need to fix the server right now? How do you do it? Or are we talking about, like, a rough sprint or a rough quarter? Because they're different. MIKE: Ah, they are different. And I think that's a critical distinction. I was thinking about that again ahead of time myself, because it's different rules, right? Going back to the military triage, there's some situations where if you don't act now, then you don't get a chance, and there's other situations that can wait a little bit. And in any emergency room anywhere, they make those decisions all day, right? They do the triage, and that's why you go, and you sit, and you wait for three hours in the emergency room. Again, I haven't had much experience in the emergency room, luckily, but I know that's -– EDDY: I'm trying to equate, like, how you're mapping that to, like, engineering, right? So, are you saying, like, someone is on their deathbed; they need priority. Is that equivalent to a software engineer saying, "Oh, the house is on fire. We're no longer...Our server's not up. That takes precedence"? MIKE: It does. So, server's down, server's down. You're bleeding money, right? Your lifeblood is that revenue coming in, and if you're down, then you're not doing business. Depending on the size of your business, you might be losing millions of dollars a minute, you know? That is a direct threat to your livelihood. And the tech debt you have that makes everything really slow, yeah, that's important, but it'll be the same way tomorrow. WILL: It's true. Well, I mean, like, in those situations, like, really what you're trying to do, like, I, think, you know, like, I am much like a civil war surgeon. I'm lopping off limbs. I'm applying tourniquets. I'm applying, like, real, like, macro carpet bombing type solutions. Like, oh, this API is taking the server down? Not anymore. Like, we're just not going to, you know, we're not going to run leases, or we're not going to do...Whatever it happens to be. Oh, this SKU is crashing with 500s, and it's taking all that stuff down? Like, what SKU? I've never heard of that. We don't sell it. We're done [laughter], you know? And I will do those things, you know, like I will cut off a limb to save the body. Those are the sort of actions that I'm immediately looking to take. Like, is there a feature flag? Can I feature flag this off? Can I turn this gateway off, you know what I mean? This subsystem, can I turn it off? I'm turning things off, you know? It's like, oh, did we push a version? Well, we're not pushing that version no more. That version [laughter] goes away now. Like, 11.9? It

  3. 5 août

    Episode 104: Job Hunting in Tech

    This episode of the Acima Development Podcast tackles how job seekers, especially new grads, should present themselves to employers. Mike opens with an analogy comparing modern hiring to online dating: both have shifted from relationship-based filtering to app-driven processes that strip away the context you'd normally get from a trusted network. Interns Vivian and Jordan share their recent experiences, with Vivian noting that her degree, hard classes, and high GPA did almost nothing to land interviews, while the opportunities she did get came through people who knew her. The panel adds that credentials can even backfire, since some hiring managers screen out prestigious schools or high GPAs, assuming those candidates will be hard to work with or quick to leave. The group converges on what actually matters to interviewers: evidence that a candidate can think, solve problems, and tolerate the constant frustration inherent to software work. Jordan's apartment-scraping side project, built to solve his own problem, was what interviewers consistently asked about, and Mike recalls hiring someone whose homeschooling app proved she could identify and solve real problems even if the code was rough. Dave and Will emphasize the psychological side of the job, including grinding through failure, reading far more code than you write, and managing imposter syndrome. They also make a half-joking but sincere case for taking work at sketchy startups, since even dubious employers provide real experience, connections, and a paycheck while you build toward something better. The dominant through line is that connections beat credentials. Nearly every panelist got their jobs through people they knew, and Dave offers a detailed playbook: cultivate loose acquaintances rather than close friends, ask curious questions over lunch, and let warm introductions bypass corporate filtering. Justin recommends joining active local industry groups like OWASP or user groups, where presenting your work makes you visible to people who hire. On the AI question, the panel agrees on tailoring effort to the audience: if an AI will screen your resume, let AI write it, but a human touch still differentiates when real people are reading. Vivian's closing takeaway captures the consensus, that human connection transcends any amount of resume optimization, and Will signs off urging listeners to add everyone they've ever worked with on LinkedIn. 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 Dave Brady. DAVE: Howdy, howdy. MIKE: We've got Eddy Lopez, Vivian Moore, Justin Ellis, Will Archer, Kyle Archer, and Jordan Dickerson. And we had a lot of interest in the pre-call here today, and I've been thinking about how to present the topic. So, there's been a huge transformation in the way people meet each other over the last couple of decades. 20 years ago, you say, "I met somebody online," you'd get some side eye. "You met them where? On the internet? Are you one of those people [laughs]?" And now date using an app, right? It's how it's done. DAVE: It's de facto. MIKE: Yeah, de facto, exactly. So, fundamental shift, right? Fundamental shift in the way that that's done. There's some consequences to that. There is a loss of a lot of the filtering that you got previously because a lot of times previously you'd get people out of this network of people that you knew. It still happens, right? People still meet each other that way. They don't follow the de facto route because that's not working. They still meet somebody through somebody they knew. But, you know, there's this lack of filter because you're going to be meeting somebody you met on, you know, on your dating app. You don't have all the context that you have, and the people say, "Oh no. Stay away from that guy [laughs]." And so, there's a lot more of this...who am I talking to? And the sudden evaluation that you got to do. Now, I haven't been dating for a long time. Very happily married, I have been for [laughter]...28 years now. It'll be 30 years in just a couple of years. I've been married for a long time. Glad I'm not dating [chuckles], that can be painful. But I don't even hardly remember doing it that way [chuckles] back when. But there's that evaluation process you go through very quickly. You know, is this...first of all, am I safe with this person [laughs]? Are they going to kill me? Followed by, you know, what's the next choice? You know, are they gross? Do they smell bad? You know [chuckles], to the acceptable...[laughs] Are they an acceptable person to be around? And, you know, they gradually move into your circles of trust, and you see how close they're going to get. And you have to go through the evaluation process. The same thing has happened in hiring, where hiring has very much been taken over, in many cases, by this whole stream of filtering that happens online before you ever meet people. And people spend a lot of work carefully crafting their resume to meet keywords. And sometimes we miss the right people. Sometimes we miss the right people because they didn't have the right keywords. And then when you meet somebody, you know, you have to go through that evaluation process. I've done a lot of interviews. I've done a lot of interviews over the years. I interviewed two people today, as a matter of fact [chuckles]. It's a thing I've done many times. And it's always tricky, right? Because you have to try to go through that filter because you don't have the context. You know, how do I quickly evaluate whether this person is somebody I want to work with? And coming from the other side, if you're looking for work, that's a tricky problem, too. I know, Justin, you've recently done this. We've got Vivian and Jordan who were recently applying for an internship. You know, so we've got some folks here who've recently been through this process. It's hard. What do I put on my resume? And this broader sense of, "How do I present myself to employers?" is a tricky one. And that's what our topic's going to be today. How do I represent myself, and what do I do? Just kind of a broader sense. What do I do? Should I get certificates? Should I not get certificates, or should I even put them on my resume if I've got them? Should I do networking? Should I go do volunteer work? Should I go and work on projects and put them on my GitHub? Do none of those matter at all [laughs]? I just have to put the right keywords on my resume. That's the topic we're going to talk about. And I could throw some of my spin on this because I have, like I said, done quite a bit of interviewing. I might actually start with the interns we've got here because I know that they have very recently been going through the hiring process. And I'm curious: the first question I'm going to ask is, what did you focus on? And that [laughs] can give us a launching point. You know, what did you focus on that you thought, "Hey, this will maybe work," as you put it on your resume? And then we can maybe talk about how that landed. VIVIAN: Coming out of college, I assumed that a degree, working hard in school, taking difficult classes, having a high GPA would be the ways that I would get a job after college. I was immediately confronted by the fact that that did absolutely nothing to do anything for me, especially in the industry that I came into in 2024. WILL: Not nothing. Not nothing. Not enough [laughter]. VIVIAN: Not enough. Definitely not enough. I would say, for sure, not nothing. It taught me the skills that I needed to eventually do the jobs that I could potentially apply for. But in terms of actually securing an interview and moving on to the next steps, that was next to inconsequential in terms of what it actually provided for me. The situations where I have been able to, at the very least, have an interview to potentially move forward to the next step, it has been finding a place where not a lot of people are applying for, or knowing someone who already works there who can give me a reference for something that I can apply for that either, again, not a lot of people are applying for. Or they know that I'm capable, and so they can vouch for me to get me onto the top of the pile. WILL: God bless a sketchy, trashy, bottom-feeding, scum-sucking, borderline felonious startup. MIKE: [laughs] WILL: Who among us, who among us didn't break in, like, on the bottom of the barrel [laughter]? Oh yeah. Oh yeah. Oh yeah. I want to see...I mean, go lower. How [laughter]...how low can you go? If it pays [inaudible 06:38] better than DoorDash and the check only bounces [laughter] half the time -- DAVE: Half the time [laughter]. WILL: You're in, baby. You're in. VIVIAN: So, the lesson I'm learning from this is compromise your morals and values. WILL: Yeah. Yeah. DAVE: It's just...be ready to settle. WILL: Yeah. Yeah. There you go. Yeah, you got it. That's a wrap, boys. MIKE: [laughs] KYLE: I was going to say, I think it's interesting, too, for new grads to join the job market. I don't know how many hiring managers had the bias of...I won't give names, but the location that I went to [laughter] after college, he had a bias in the sense of what schools. If you had certain schools on your resume, he wasn't interested. He had hired those schools before and no longer wanted to deal with them. If you had certain GPAs and you're thinking, "Okay, cool, 3.9, 4.0, that's great," nope, you were out of the list. He didn't want the high GPAs. He wanted 3.4s. He wanted 3.0s. He had a certain opinion of those. So, I'm saying, sometimes, it's even awkward in the sense that your school, your GPA, your classes, those might even negatively affect you for some individuals. WILL: I have run into people who will not hire from certain top-tier schools, right? KYLE: Oh yeah. Top tiers are not uncommon for...especially

    Episode 104: Job Hunting in Tech

  4. 22 juil.

    Episode 103: Organizational Complexity

    This episode of the Acima Development Podcast centers on organizational complexity, using NASA's root cause analysis as a jumping-off point. Mike opens by contrasting the military's rigid hierarchy with the failed free-form communes of the 1970s, arguing that both extremes reveal something about what makes human structures work. NASA's finding was that technical complexity should not be matched with organizational complexity; simplicity is the path to success in both. Dave reinforces this with a Microsoft study showing that bug severity correlates with organizational distance between the people involved, growing exponentially with each layer of hierarchy separating them. The group discusses product-vertical "pod" teams, where cross-functional members own an entire stack and success is tied to customer outcomes, versus discipline-based teams like a dedicated database group. Justin describes guilds, a parallel structure where specialists across teams meet and share expertise, as essential for keeping vertical teams from becoming siloed, and Mike ties this to the Team Topologies framework of four fundamental team types with clearly defined, unambiguous roles. The conversation shifts to how expertise is actually developed, with strong consensus that software engineering is fundamentally an apprenticeship trade. Will argues that engineering has always worked this way and attempts to replace mentorship with formal structures fail. Vivian, an intern on the call, agrees, noting that simply sitting in meetings watching senior engineers reason through decisions has taught her things she otherwise wouldn't learn for a decade. The group critiques code review as a mentoring tool (too late in the process) and advocates for pair programming instead. Vivian draws an analogy to the brain: intelligence comes not from the number of neurons but from the depth of their interconnections, so 10,000 employees who never talk to each other are just one person 10,000 times over. This leads to discussion of how leadership scales, with Kyle and Will emphasizing that approachable leaders matter, that "open door policies" can be declared but trust must be earned, and that policies made without consulting end users (like tool purchases) create dysfunction. The final stretch becomes practical career advice prompted by Vivian's questions about building trust as a newcomer. The panel's answers converge on consistency: show up, do the work, take responsibility when things go wrong, and never pretend to know something you don't. Will offers his "secret silver bullet" for getting help from anyone: make a genuine effort first, document what you tried, and ask a specific question, and people will do backflips to help you. Dave adds the notebook rule (never ask the same question twice) and a rough heuristic for when to stop grinding on a problem alone: value your time like a senior's, and escalate when an hour of their help outweighs hours of your spinning. On Vivian's tendency to hyperfocus, Will and Dave both encourage her to "let it cook," arguing that obsession at her career stage builds lasting skill, as long as she's engaged and learning rather than stuck. The episode closes by looping back to psychological safety as the throughline connecting organizational design, trust, and team success. 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 Dave Brady, Thomas Wilcox, Justin Ellis, Vivian Moore, and Kyle Archer. And I'm going to start by sharing, not a personal story, but one I read. Actually, I'm going to share two things. Well, first, a little bit of context before my story. We've been talking for several weeks now, several episodes. We're going to continue on our final, final episode talking about the NASA root cause analysis that they did─I think it was back in 2012─talking about things that led to some institutional failures that they needed to pivot from. And I'm going to start by talking a little about the military. I've not served in the military, and, frankly, I haven't wanted to [chuckles]. That's a tough thing to do, you know, all of the risk that's associated with it, all of the risks of PTSD, and so on. But I give respect to anybody who has served, because, you know, that's a real thing. The one thing that the military does do is they have a very rigid hierarchy, so everybody always knows who they report to, and that's pretty universal, I think, in militaries, you know, successful militaries. They have this rigid hierarchy. And so, there's this question: why do they have such a rigid hierarchy? And rather than answering that question, I'm going to share another thing that I read, and it's brief. I read...I don't know if story is the right word. I did an analysis of counter-cultural communes back in their heyday, back in 1970s. The opposite of the military hierarchy, right? As far from it as you can get. And in one of these particular communes, there was one where they said, "We're not going to have anybody married to each other, free love, you know, and everybody just be with whoever they want." And they interviewed somebody, and he said, "There is nothing more lonely than every night having to find a new partner," you know, like, begging them to spend the night with you. And I thought that was fascinating. In one case, you know, you have this rigid hierarchy with all the constraints and all of the potential downsides that come with that. It's hard to be in an environment with such a rigid hierarchy. I report to this person; I do what I'm told. But on the flip side, if you have no hierarchy and no commitments, it can be even more crushing. And almost all of those societies have fallen apart. They were experimental, and they fall apart because there is that lack of commitment. And the social structures just deteriorate, you know, you don't see very many. There do exist some communes, but most of those experiments that happened in, like, '60s and '70s have fallen apart, and they don't exist anymore, or exist only at extremely small scale. And the ones that did tend to exist are those that look very hierarchical, much like monasteries, where you have people with a strong dedication to a cause, and, you know, single-minded, and not that kind of social conflict. Once again, they've ended up looking more like the military, and that's fascinating. It says something about what is effective in running human structures. Also, my heart broke for that poor guy, the loneliness. He said, "There's nothing more lonely..." and you picture just kind of begging for somebody to care enough about you, and you have to do that every day. Coming back [chuckles] to this NASA study -- JUSTIN: I was thinking of how you're going to relate that, you know, begging for somebody to relate to you at work, or something like that [laughs]. MIKE: No. So, NASA's final element in the root cause analysis...and I'm going to read this just straight verbatim from their report, because I think it's interesting. They said, "The final root cause is closely related to the fourth and is driven by the technical and organizational complexity. Space systems are highly complex and very sensitive to small uncertainties. This complexity requires in-depth penetration and understanding, where small technical glitches result in major problems. The technical complexity leads one to think that the technical complexity must be matched with organizational complexity." I'm going to pause there for a second. So, they have this innate technical complexity, right? You're building a rocket. It's complicated. And you might think, "Okay, so my organizational structure needs to be complicated." You have 20 bosses, right? And I go back to what they said, "We know that when managing the organizational complexity becomes as large as or larger effort than managing the technical, then the product success is in question. Simplicity is the pathway to product success, both technically and organizationally." Now, we tend to focus a lot on technical simplicity. Well, we know the simplest solution that's almost certainly the best. But we don't always think about the organizational simplicity. DAVE: Mike, I love that you hit on this. Last week, when I hosted when you were out, one of the things that I mentioned is that, at Microsoft, they did an in-depth longitudinal thing on, like, what's likely to cause a bug and how severe and difficult is it to fix? And the dominant variable was how far away in the organization the person who fixes it is from the person who wrote it, or the two modules that have to interact. And they measured it by how many layers up the hierarchy you have to go to get to the common person to take you back down to approve this other person working on your thing, and it's exponential. Somebody on your team, pretty straightforward. Somebody on the next team over, kind of difficult. Somebody in the next department, very, very hard. And if it's in another business unit, forget about it. You might as well just open a ticket and pray. MIKE: You're saying if you don't have that person that you know and trust and can rely on, things fall apart. DAVE: Mm-hmm. MIKE: It's fascinating to me how much human aspect there is to software engineering. We have talked about technical stuff. Sometimes we've gone deep into unit testing here, right? But here we come back, and this is going to be a very human-focused episode. We're talking about that idea of organizational complexity driving, as they said at NASA, product success. Product success is in question when your organizational complexity grows. So, Dave, you mentioned the study at Microsoft [chuckles]. DAVE: Yeah, it's straight-up complexity and the hierarchy. And if you think about hierarchy like a snowflake or a star graph, it becomes fractal, right? You've got these two great big branches, and then lot

    Episode 103: Organizational Complexity

  5. 8 juil.

    Episode 102: Distributed Authority

    This episode of the Acima Developers Podcast continues a series on a NASA paper about engineering failures, focusing this time on decentralization of authority. The core question Dave poses is where breaking things down and simplifying goes wrong, and the group lands on a shared answer: complexity doesn't disappear when you split systems or teams apart, it migrates into the seams between them. Will frames organizations as multi-threaded programs, arguing that distributed work is inherently less efficient than a single mind holding everything, and that the real failure is that nobody budgets for that inefficiency. Teams plan sprints as if they operate at maximum efficiency, then get blocked waiting on other teams like threads waiting on a mutex. The conversation moves into war stories about organizational structure. Kyle describes how Acima's DevOps team, once embedded with engineering under one budget, now sits in a separate department requiring alignment several layers up before work can happen. Dave cites a Microsoft study finding that bug difficulty scales dramatically with org-chart distance between the person who needs a fix and the person who can make it, and recounts a previous employer where carving out a DBA team concentrated all database authority in one group while the blame stayed distributed everywhere else. Will's proposed remedy is cross-functional "tiger teams": pull a dedicated body from every needed discipline (DBA, DevOps, security) onto one team for the life of the project, deliberately over-allocating rather than pretending ticket queues between silos are free. He argues for institutional checks and balances over exhortations to "speak truth to power," since pressure, layoffs, and optimistic scheduling make honesty structurally difficult. The back half turns philosophical, sparked by Vivian's observation that startups work like mesh networks (everyone connected, nothing precious to break) while enterprises are hierarchies protecting a "golden goose." That leads to a warm tangent on being kind to your future self: Dave's story of leaving network diagrams inside junction boxes that paid off 15 years later, Vivian's "second brain" note-taking practice, and the YAGNI principle of trusting tomorrow-you to solve tomorrow's problems with better information. Will counters with a lament about corporate chat retention policies deleting institutional knowledge after three months, which he calls "leadership malpractice." Vivian closes with a fitting meta-observation: without Mike there to keep them on track, the decentralized conversation never actually reached a conclusion about decentralization, inadvertently proving why some centralized accountability matters. Transcript: DAVE: Hello and welcome to the Acima Developers Podcast. I'm your host today, Dave Brady. We have got a really good panel today. We're still talking about the NASA disaster stuff. Today on the panel, we've got Will Archer. We've got Eddy Lopez. We've got Vivian Moore. We've got Kyle Archer. We've got Will's dead camera connection from his previous dropped call, and we've got Ramses Bateman on the call. So, we've been talking about this NASA paper, if you've been following along at home. You can get this on the Googs or wherever: Elements of Engineering Excellence by J.C. Blair, R.S. Ryan, and L.A...Oh boy, Shutzenhofer, from AI Signal Research in...if you find that, Google for that, you'll find this. And, basically, it was...they prepared this paper for NASA telling them, "This is why your stuff keeps breaking, and you keep killing people when they try to go into orbit or come back from it." And we've already talked about, like, normalization of deviance and, I don't know, some other stuff. We did a whole show a couple of times, and I kept making it a forum for AI. So, I'm hosting today, so I'm going to be asking questions and trying not to turn it into the Dave show. We're really excited to have Vivian on the show. Vivian, you're one of our interns for the summer. Do you want to say hi to the audience, just tell them who you are? VIVIAN: Yeah, sure. So, I'm Vivian Moore. I'm going to be one of the software engineering interns for the summer. I've been actually listening to the podcast for the last, like, couple months or so, kind of getting prepared for the internship, getting to know everybody. So, it's kind of a weird experience being on here now that I'm actually at the company, but it's very fun. DAVE: Right on. Welcome. So, Mike always starts with a story, and I usually have 20 of them on hand, but all stories that I have are going to go immediately onto a tangent. So, I kind of wanted to just kind of open the floor a little bit. Mike commented to me...Mike's running late today. He might make it. I'm hoping he does make it. But he sent me the meme from Office Space of, like, when you have eight bosses, nobody's actually in charge when you answer to eight people, right? It's the bystander problem, bystander effect where, you know, if a crisis is happening and there's eight people standing there with their cell phones, and you say, "Call 911," nobody calls 911 because everyone assumes that everyone else will do it. Paper hones in a little more sharply on this, that it has almost more to do with siloing teams and isolating teams from each other and stopping them from communicating in between each other. And, in the pre-call, I mentioned that the devil kind of lives in that space. I've seen so many software ideologies come down the pipe over the past decade or two, where people have, you know, like, "I've got the answer, and this is going to solve everything. All you have to do is simplify the piece that you're working on." And they show you this really simplified thing, and it looks good. It looks clean. It's obviously true, but it doesn't solve the complexity. It just pushes the complexity outside the thing you're actually working on. And if the other team on the other side of the wall is pushing that complexity back at you, that complexity now lives in between. Honestly, that was my big grief with, like, the way Java architected things out by default. I mean, like, Java's great. It's a good plan. But the naive approach to the way Java breaks everything down into tiny, tiny, tiny, tiny, tiny, tiny...Like, I can remember people saying, "You should not have a class longer than 25 lines of code, and you should not have a method longer than 5 lines." And I wish I could write software like that. I know people who can, and, I tell you what, they are very, very good at finding the file they need or the seven files that they need because they're all over the disk, right? Which arguably is probably better than trying to sift through a 3,000-line chunk of code, which actually might be an allegory for this organizational problem. But my issue is that you start having problems with how the modules get picked up and put together, because complexity starts to live in the seams, not the units, but the integrations between them. What do you guys think about, like, decentralization, breaking stuff down? We all know simplifying things is good, but where does it go bad? If we just take simplifying and breaking things down as an objective good with absolutely no qualifications, where does it go wrong? WILL: So, whenever I think about, like, sort of, like, these sort of, like, distributed processes, right, like, across engineering organizations, individual engineers, like, I always think about a multi-threaded program, right? So, one of the things that we've seen over the past, like, you know, however many years, like, really since we broke out of the 486, you know, line of computing is more and more and more cores, right? More and more cores: 18 cores, 16 cores, 32 cores, lots and lots of cores. Well, the problem with lots of cores is there's lots of threads. And one of the sort of dirty, little secrets of, like, this sort of, like, nitty-gritty systems-level programming is your efficiency, as you have these multi-threaded processes, intrinsically, like...And I think this is mathematically provable. It always goes down relative to a linear A to B to C to D to E to F, all the way to Z, like, one at a time, right, maximally efficient. But, you know, then you only have one person working one way. For people who've experienced, like, the joy of creating a system, or a service, or a program, or a protocol soup to nuts, and it all lives in your head─you made all the decisions; you did every single thing; you know where all the bodies are buried─you will never in your life experience efficiency like that. But you're still only one person of flesh and bone. You only have 24 hours in the day, just the same as everybody else. And if the enterprise is going to scale, you're going to have to scale out to different people. And that comes with inherent inefficiency. If you did it right...and writing multi-threaded programs is astonishingly complex if you've had the burden. A lot of people don't really do it. It's pretty rare for people to write hardcore, nitty-gritty, multi-threaded programs anymore. All of that heavy lifting has been done by, like, really, really, really, really smart people at several different layers, you know, like, to the database, to the operating system, to the sort of, like...Anyway, the frameworks, all that stuff has been done, but it's astonishingly hard to do. We have, you know, general organizational principles to do it, and they're all pretty good. They're all easier said than done, but, like, where I feel like things break down foundationally is we don't allocate for the inefficiencies inherent in the system, like, that's the problem. Every team schedules themselves. They plan their prod. They plan their releases. They plan their sprints, their production quotas, you know what I mean, their timelines for this maximally efficient thing. And it's always wrong because you're always g

    Episode 102: Distributed Authority

  6. 24 juin

    Episode 101: Critical Thinking

    This Acima Development Podcast episode connects a NASA document on critical failures to the modern temptation to over-rely on AI. The hosts open with examples of reward-function failures: a reinforcement learning agent in the game Coast Runners that racked up points by endlessly circling a lagoon instead of finishing the race, and an early GPT model that compulsively opened a calculator because its reward was dialed too high. These illustrate NASA's identified root cause of major incidents: lack of critical thinking and over-reliance on computers, processes, and procedures. The recurring metaphor is "playing with your head up," meaning you execute a strategy efficiently while continuously re-evaluating whether it's still the right one rather than blindly trusting the process. The middle of the conversation explores how much to trust AI, particularly for code review. The consensus rejects all-or-nothing thinking: AI is another tool, like a human reviewer, and catches different things, so the best approach is using both. Dave shares wins (AI flagging a subtle nil-returning bug he'd have missed) and failures (AI ripping out a carefully crafted Arel query to jam in raw SQL, or re-implementing a feature the team had deliberately killed). The takeaway is that AI can't run unattended because it lacks institutional lore, and an experienced human needs to stay in the loop, especially for high-stakes changes. Low-risk, templatized work like certain database migrations are good candidates to let AI handle, applying risk frameworks (mitigate, eliminate, transfer, accept) to decide where it can safely "cut its teeth." The discussion broadens into how skills evolve as technology shifts. Using analogies of welders replaced by robots, miners re-skilling into adjacent jobs, and the Pony Express being rapidly outpaced by the telegraph and railroads, the hosts argue that giving up certain "critical thinking taxes" (like manually smelting iron, or writing low-level compilers) frees people to build at higher levels, while foundational skills survive in niche "ranching" spaces like microcontroller programming. The unifying through line is proprioception, a visceral, grounded feel for what you're doing. Even as AI tools do more, you can't fully let go of the reins, because grounding in the underlying craft is what lets you sense when something is going wrong. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me today, I have Eddy. I've got Dave.  DAVE: Howdy, howdy.  MIKE: Ramses and Kyle. It's possible we'll have a little bit of ebb and flow in who we've got here, as we sometimes do, which is great. We have a group here that can go into a good topic. Just a heads-up: we're going to talk a little bit more about the NASA document we've been talking about on the last couple of episodes. So, as usual, I'm going to start with some background story. This one, I'm going to go more on the technical side.  There's a great example, and you can look it up. It refers to a game called Coast Runners. So, there's a video game called Coast Runners. And some years ago, they built a number of reinforcement learning agents to play it. This is some of the early days of, "Hey, we can actually build AI that can play games, and it's working." Because there were a lot of years where they couldn't make that work very well, and it's kind of some of the first steps, "Hey, this is actually working." It led to some of the breakthroughs where we saw, you know, amazing things happen a few years back in video game playing, you know, including beating human players in a variety of games.  Well, this game, you know, it's not chess; it's not Go. It's a video game where you drive a boat, and you try to win the race. And they built the environment, and they built these reinforcement learning agents to play it. And not surprisingly, the reward function was to maximize your score. And here's where things get interesting. The score in Coast Runners is partially determined by winning the game, but it's also determined by how many of these little boxes that pop up that you can hit along the way. And what the agents learned to do is there's a lagoon that you can go into on the side. And...well, I'm going to read this. This is taken directly from a write-up that OpenAI did on it. It said: "The reinforcement learning agent finds an isolated lagoon where it can turn in a large circle and repeatedly knock over three targets, timing its movements so as to always knock over the targets just as they repopulate. Despite repeatedly catching on fire, crashing into other boats, and going the wrong way on the track, our agent manages to achieve a higher score using this strategy than is possible by completing the course in the normal way. Our agent achieves a score on average 20% higher than that achieved by human players, [laughs]" which is to say, computers will do exactly what you tell them to do.  DAVE: A follow-on that. In one of the...I think it was ChatGPT, in their training —the early ChatGPTs —if you'd ask a math problem, it would get it wrong because it was just doing words and tokens, right? It wasn't actually conceptualizing the numbers. And one of the things that they started reinforcing was open the calculator. If you get a math problem, open the calculator, type in some numbers, and add it, and when you hit equals, you get a cookie, right? We're going to increase your reward satisfaction score.  And they shipped this thing, and I want to say it was GPT-3, 20 to 40% of queries that you sent, no matter what they were about, it would silently open up the calculator, add one plus one, and hit equals, and give itself a cookie, and then go back and resume [chuckles] and answer your question. They had prioritized use the calculator instead of confidently guessing off of the words, right? Because AI's confidently [inaudible 03:42] the wrong way. They had dialed the reward up so high that it liked playing with the calculator. And it just reminded me of being a junior in, like, geography class playing [inaudible 03:51], you know, waiting for math class. Bless his little heart.  MIKE: Exactly, well, yes. And the reward will be maximized. So, NASA looked at some of the failures that they had had, and we've been talking about this document they published about a decade ago. And they said that one of the root causes of the key failures that they've had in some of the major incidents was lack of critical thinking. They refer to it as over-reliance on procedures and computer codes.  And there's a longer paragraph; I'll quote from this as well. Sorry for reading the quotes, but they're well-written [chuckles]. It's worth giving some context. "The third root cause is closely related to second. It is the lack of critical thinking with an over-reliance on computers, processes, and procedures. Computers, processes, and procedures are necessary but can never take the place of the human mind. In the end, all of our resources, tools, et cetera, are there as an aid to the human mind and the human creativity and decision-making." Now, this is fascinating a decade later, where we have AI becoming so much more successful, and we're outsourcing a lot more of our thinking. And if we rely on that without supervision, we get what we ask for. You know, like King Midas [chuckles], we may get exactly what we ask for and regret it for the rest of our lives. DAVE: There's a fun takeaway to this as well. I'm going to take this immediately and go meta, which is that, like, when I was in college, somebody barked at me and said, "Dude, you need to learn to play with your head up. Did you not ever play basketball?" And I'm like...I was not athletic at all. I don't even know...That's the round one, right?  MIKE: [laughs] DAVE: And, yeah, right? So, he said, "When you play basketball, what they teach you is don't look at the ball. You have to play with your head up because you have to be watching. You have to be looking at the net. You have to be looking at the other players. You've got to be able to dribble the ball without watching the ball." That stuck with me because he wasn't talking about dribbling the ball. He was talking about I was writing a piece of software that nobody in the room wanted. And one of the executives who had direct control over my paycheck directly did not want, and it was costing me dramatically politically. And so, basically, it was like, read the room, right? But the phrase "play with your head up" has stuck with me as, once you've decided on a strategy, you should execute the strategy efficiently. But you constantly have to be evaluating: Is this still the right strategy? When you find a good idea, it's very valuable; but also valuable is when you get rid of an idea that's no longer valuable —that's no longer earning its keep. And if we say, "Don't use AI because you won't learn nothing," we are at risk of falling into the very same trap that we just outlined because, for instance...I told this story on a previous podcast. I needed an auto clicker in Linux, and I know how to write one, kinda. I mean, I know the principles. I know how to write a timer. I know how to send input to the mouse. I know how to capture keystrokes. I know conceptually that I'm going to need to intercept a keystroke in another application, and that's going to require elevated privileges because that's technically a keylogger, right? And I don't know how to do any of that in Linux. 15 years ago, I could tell you from memory how to do it in Windows because I was a Win32 programmer for years and years. But I never learned how to do it under Windows, under the X11 system. I went to an AI, and I said, "I'm just playing Minecraft, dude. I want to AFK and grind some resources. I just want an auto-clicker, and apt search on open-source repo isn't turning up an auto

    Episode 101: Critical Thinking

  7. 10 juin

    Episode 100: Normalization of Deviance

    This episode of the Acima Development Podcast centers on "normalization of deviance" — the pattern where small anomalies get repeatedly ignored until they cause catastrophic failures. Mike opens with the Space Shuttle Challenger disaster as the anchoring example: engineers warned that cold O-rings could fail, but their concerns were drowned out by schedule pressure and accumulated tolerance for small deviations. The crew connects this to the Columbia disaster years later, where the same organizational lesson went unlearned, and to NASA's own "Elements of Engineering Excellence" report, which lists not questioning anomalies as a major root cause behind their biggest failures. The conversation then wrestles with the tension between safety culture and velocity. Will pushes back on pure risk-aversion, arguing that heavy regulation has real costs and that tech's "move fast and break things" ethos has produced enormous value. Dave introduces the META framework (Mitigate, Eliminate, Transfer, or Accept) and contrasts NASA's culture with SpaceX, which celebrates blowing up unmanned rockets because the risk was already accepted and the explosion yields data. Mike reinforces this with an analogy from his kid's rocket-themed birthday party, where different risk levels (model rockets, sugar rockets, thermite) warranted very different safety boundaries — treating everything as maximum-risk would have obscured where the real dangers actually lived. The group lands on a key reframe: rather than trying to control everything, build a monitoring culture that instruments heavily, tests to failure, and pays attention to the signal inside the noise. The final stretch applies these ideas to current software practice, including AI-assisted development. Matt and Dave debate whether vibe coding will dominate production code soon, with everyone agreeing humans must remain accountable for what ships. Will gives concrete examples of normalized deviance developers live with daily: thousands of ignored compiler warnings (some of which are genuinely dangerous), bloated mobile web performance, and test suites nobody expects to run clean. He notes AI could finally make the ditch-digging cleanup work economically viable. Mike closes by tying it back to the opening theme: entropy is the default, letting things slide is easy, but flipping the culture toward actively watching the data is what prevents small deviations from becoming the next tragedy. 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've got Will Archer, Dave Brady, and Kyle Archer. DAVE: Howdy, howdy. MIKE: I'm going to start with a story, as I typically do, actually two stories, but one funny and one not at all funny. I'll start with the funny one. My wife, when she was in her late teens, decided to drive with her sister to college. She wasn't going to college yet, but she decided to road trip with her sister to college. And they made sure the car was good the day before, had been doing some maintenance, and they cracked the case of the cooling fan for the engine. WILL: Oh. MIKE: So, when the fan was running, it was bumping against this cracked part of the case, so you can imagine the sound of that, not good, right? They actually took it to a mechanic and got kind of a loose sign-off that, "Yeah, well, this isn't going to make the car break, but it's going to sound terrible, and you should get it fixed soon," like, "Okay." And they drove cross-country [chuckles] with that thing rubbing the whole way. And what they did is they just turned up the radio, so full volume, full road trip. They drove for, like, two days [laughs] with the volume cranked up, just ignoring it. And she's told the story for years. It's funny, you know, everybody in the family laughs. You can just imagine, just turn up the volume, and the problem goes away. That is one way to make a problem go away. The other story is related to what we talked about in our last episode. And we're going to continue with the topic we talked about in the last episode, which is the Space Shuttle Challenger disaster, which happened in, let me check my dates here, '86. I believe this happened in... DAVE: '86? MIKE: '86. That's the date that I was remembering, so 1986. There it is: 1986. So, I actually looked this up. I read about it on Wikipedia. As a kid, I remember watching this [chuckles] in school, and it was, you know, horrifying. So, they had O-rings around the booster engines that, you know, like rubber or rubber-like material. And they had had record cold, I guess, at the launch pad the night before. And that cold caused the O-rings to, you know, shrink and stiffen. And so, in the launch, they lost integrity, so air started getting into the fuel. Eventually, that caused a catastrophic explosion, and the entire spacecraft disintegrated. I remember the horror of seeing those booster engines just randomly wandering, and there was not anything left of the main craft. It was a tragedy, you know, a horrible tragedy. Anybody who was around that time remembers. I was talking to somebody else like, "Oh, that was our JFK moment," you know? Everybody remembers that. Where were you when that happened? And it turns out the engineers had warned this might happen, and they were ignored, because there was enough noise in the data. They're like, "Oh yeah, well, there are so many things that can go wrong [inaudible 03:18] DAVE: Not just ignored, though, right? They were told to stay in their lane. MIKE: I think that's right. DAVE: If I recall. Yeah. They were told to be quiet, yeah. MIKE: The interesting thing about that is there was another space shuttle disaster some 20 years later or so, where Columbia broke up in re-entry. And the diagnosis afterward essentially said, "We didn't learn from the last time." There were likely problems that were pointed out by engineers, and there was just so much pressure to make this thing work that the concerns were ignored, and people died as a result. And in the document that we started talking about in our last episode, which is...certainly you can look it up yourself. It's titled...this was published by NASA titled Elements of Engineering Excellence. It was published in 2012. They made a list of root causes behind the major problems that NASA had had over the decades previous. Last time, we talked in depth about the importance of hands-on experience, that unless you have people who really have, you know, kind of gotten their hands in the work and understand it deeply, then you're going to miss stuff. The second point is what they call normalization of deviances. They also refer to it as not questioning anomalies. I'll quote from the report, "As was evidenced in the Challenger failure, we see deviations, and they're not quite normal, but seem to have no major consequence. After seeing these deviations a few times, we accept them as normal and ignore them. The result is a major failure where the deviation becomes catastrophic." So, that's our main topic for today, is the importance of questioning those anomalies and being able to see that signal inside, you know, a bunch of noise, because there's always noise [crosstalk 05:18] DAVE: There are a couple of interesting extrapolations on that as well. WILL: So, I have some thoughts about, like, sort of, like, these sort of, like, normalization of deviances and ways that it can go wrong. But, like, I suppose, like, and maybe this is just my priors, but I'm very much a believer in, like, a move fast and break things sort of ethos. Like, I'm familiar with heavily regulated, heavily controlled industries where, rightly or wrongly, there are high stakes, people die, right? And let me tell you right now that there is a cost to that. There's a substantial cost to that. And I do think that technology, in general, is pretty out of control in terms of, like, accountability, right? I mean, if you look at, like, you need a license to braid hair [laughter]. But, like, I didn't even need to graduate high school to do the job I'm doing. I just needed to convince somebody to give me a shot and then not get fired for long enough, and then you're in. DAVE: And we're writing software that handles people's money for them. WILL: Yeah, to the tune of billions of dollars, you know? And it's just like, "Yeah, you know, he sounded like he knew what he was doing. Let's roll," you know, which is fun. I think that's wrong. But, I mean, you can't argue with results of the industry that we've been in, right? And I think there's benefits there, and there's a lot of stuff where, yeah, you can let it slide until it blows up. You could do that. That's a strategy. It's a valid [crosstalk 06:56] MIKE: Well, and not only is it a strategy. It's a critical one. WILL: Initially, right? MIKE: Yeah. Well, absolutely. And even in regular life, you can't pay attention to everything. Attempting to do so would not end well, right? Our brain is very good at removing extraneous information. You can't pay attention to everything. So, you have to prioritize what you actually give attention to, and that better be the important stuff. DAVE: There's a rule in insurance, which is if you can afford to replace it, don't buy the insurance. But if you can't afford to replace it, don't even ask how likely it is that you're going to lose it. You have to get the insurance. The entire science of risk assessment is getting people to stop thinking about reducing the likelihood of a catastrophic fault and dealing with the case of when it is catastrophic, right? It's like, if you're going to take, "Oh, this hash collision can happen one in 10,000 times, and it will bankrupt the company," and I turn the PR back to you, and you say, "Okay, well, I've reduced the likelihood to one in a million times, and it still bankrupts the company." No, I'm not going to app

    Episode 100: Normalization of Deviance

  8. 27 mai

    Episode 99: Hands-On Expertise

    This Acima Development Podcast episode centers on a NASA root cause analysis document from 2012 that concluded the agency needed to "reestablish the culture of technical excellence based on hands-on work." Mike opens with stories of Dutch Renaissance painters Rachel Ruysch and Maria Merian, both of whom spent decades honing their craft and improved continuously through sustained hands-on practice. This sets up the core question that drives the episode: does technical leadership require having done the technical work yourself? Dave kicks off the debate by asking whether the CEO should write code, prompting Will to share the "toxic and unpopular opinion" that technical executives should have built software at some point in their careers. The group largely agrees that hands-on experience matters, but the conversation gets more nuanced as it goes. Justin highlights how technically credible leaders create better engineering cultures because people can't pull BS on them, while Matt pushes back as the lone dissenter, arguing that communication, problem-solving, and trust in capable people matter more than personal technical skill, especially for CEOs versus CTOs. Will draws a distinction between line-level engineering managers (who he thinks should spend half their time writing code, ideally pairing) and higher-level managers who can step back. Kyle adds that genuine desire to understand the work can substitute for direct expertise, and Mike Porras connects it to decentralized authority, citing Atul Gawande's The Checklist Manifesto and the Katrina response failures as examples of why subordinate leaders need autonomy to act within their domains. The final third pivots to AI as a new threat to that hard-won technical grounding. Justin raises the concern that engineers are increasingly surrendering judgment to LLMs, which could produce the same erosion of expertise that NASA documented. Will frames LLMs as power tools and force multipliers, glorious in skilled hands but capable of taking your arm off, comparing them to rocket jetpacks. Mike Porras shares a more optimistic view, describing how AI lets him reach the PR stage faster on unfamiliar work and creates more space for higher-level architectural conversations with reviewers like Kyle. Mike closes by tying it back to the central thesis: the tool keeps changing, whether it's outsourcing, AI, or whatever comes next, but the need for grounded expertise, humility, and continuous learning never goes away. Transcript MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. And I've got a big crew here today. I think we've got a topic we all care about [chuckles]. Here with me, we've got Eddy Lopez, Mike Porras, Dave Brady, Thomas Wilcox, Ramses Bateman, Matt Hardy, Justin Ellis, Kyle Archer, Will Archer, no relation [chuckles], Tim Chaffin, and Jordan Fong. Big crew of us here to talk about our topic today, and our topic today is triggered by a blog post by...her name is Vicky Boykis... Man: Vicky. MIKE: Yeah, Vicky Boykis. I ran into her from a newsletter, but, so I don't know her personally. But she wrote a fantastic blog about engineering, software engineering in the larger sense, machine learning, AI engineering specifically. Well, and interestingly enough, twice this week, I've randomly run into people writing about ancient Dutch painters. I say ancient, like, Renaissance Dutch painters, that era, and [chuckles], you know, women who were exceptionally skilled at their craft of painting during that period of time. And so, I couldn't just leave that alone. We're going to talk about that in our podcast [chuckles]. There's two women I read about this week. One of whose name...and these are Dutch names, so I'm probably going to butcher them. Give [chuckles] me some grace and patience on this one: Rachel Ruysch and Maria Merian. Both of them were Dutch painters. Rachel Ruysch was a painter of flowers who had painted, I guess, for decades, over a period when flower paintings were extremely popular, extremely sought after as a way in the long Dutch winter to bring a little bit of nature into your home. Maria Merian was not just a painter but a naturalist. She, as a child, was fascinated by nature and loved watching insects. And she carefully documented the process of metamorphosis, insect metamorphosis, which had not previously been documented well, meaning that many people in that era in Europe really didn't get it. You know, a lot of us as kids now, we think, "Oh yeah, caterpillar, butterfly. Got it." That was not the case back then [chuckles]. They did not connect the two. And we can thank Maria Merian for a lot of that understanding. She put things together that were not well understood for years. She actually, later in her life, traveled to South America and documented some of the amazing insects they have there, and people back in Europe didn't believe her. They just thought she was making it up [chuckles] because they just couldn't...you know, they were in Europe where it's cold, and the bugs are small. They just couldn't believe that there were these amazing tropical insects. And years later, her work has come to greater appreciation, that she beautifully captured and accurately captured things that the broader science community didn't catch up to for quite some time. One thing that both of these women had in common is they worked for decades, both of them starting, you know, like, in childhood. They were surrounded by mentors, and they worked, you know, they kept on working. You can find pictures of both women, because they were painters, right, paintings of them later in life, because they were experts. And here's the thing: they got better. One thing you do as a painter is you get better, right? So, their work improved over decades. It's part of why both of them are acclaimed today, is they just got really, really good from all this practice. Well, we're talking about Dutch painters, right? Let me connect this to one other thing before we jump in. About...well, I say about this many years ago. It doesn't matter how many years ago because you might be listening to this five years from now. In 2012, NASA published a document doing root cause analysis on problems that had led to some of the issues they had within NASA that led to deterioration of quality, accidents, that sort of thing. And they wrote a list of five items, and we may get to those as we talk, but then they summarized it. And here's the one-sentence summary that I've got. To prevent problems, NASA needs to reestablish the culture of technical excellence based on hands-on work. That's what I'd like to talk about today. We talked about the painters [crosstalk 04:49] DAVE: Like the CEO who writes code? MIKE: Possibly [laughs]. DAVE: Okay. MIKE: And that's an opportunity to dig in. Like, should the CEO be writing code? DAVE: [inaudible 04:57] I'm not challenging. Yeah. MIKE: Yeah, no. And I open it up. You know, I like to open things up and then be quiet for a while. So, you led out with that, Dave. Should the CEO be writing code? DAVE: I mean, not in prod [laughter]. When I worked at CoverMyMeds, that was the policy. If you work here, you write code. And so, there was a data migrator that was written by the CEO. And yeah, like, five years on, it read like code that had aged, had been written by an executive, and, you know, hadn't been kept up to date, and it was fine. The important thing was he had his fingers in the guts of the system, and that kept him a lot more present to how the system worked underneath him. WILL: I have a toxic and relatively unpopular opinion that, like, technical executive leadership should have, at some point in their careers, written software. I tell you, man, in terms of, like, CTOs that had the experience of working under possibly a third qualify, I don't know, I mean, that's, you know, I'm coming in with the hot takes. MIKE: I've had some conversations with our recently hired CEO. He is very much an advocate of engineering excellence and really wants to lean into engineering. He wouldn't have given it as a hot take, so...[laughs]. But he would have shared a similar sentiment because, in his feeling, if you don't have the background, then it's really hard to make the right decisions. WILL: So, yeah, 5 years ago, anytime [inaudible 06:37] 20 years ago. [laughs]. JUSTIN: I've been in a couple of places I've worked where the CTO has had technical excellence. The vast majority of the time, that has resulted in, like, a better engineering culture than, you know, those without. And by that, I mean, like, engineers wanted to stay because this was...yeah, not like now, but this was during the time when it was hard to hire engineers. And you spent a lot of thought about how to make a good engineering culture. If you did not have a good engineering culture, people just left, and they weren't happy there. And having a technical leader in technical leadership was key to that because they just...they got it, and you weren't able to pull BS on them, or they had less BS pulled off on them because they've been in the trenches. And those who haven't been in the trenches, they're up in their...I wouldn't even call it an ivory tower. They're off in their palace somewhere doing politicking, and politicking always sucks [laughs] so... MIKE: You know, Dave, I think you asked at the beginning: should the CEO have written code? Well, maybe, maybe...So, here's a take on that. Our CEO currently was the CFO before, so he's deeply experienced with finance. He comes from a background where he knows that. And I probably trust him more as CEO because of that, because I know that he knows where to, you know, watch the money, and he's not going to let things get out of hand. WILL: It's a financial company, right [laughs]? You know. MIKE: Yeah, exactly. It's [laughs] a fin

    Episode 99: Hands-On Expertise
Tout afficher (106)

Notes et avis

4,5
sur 5
2 notes

À propos

At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.

Informations

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