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 financial company.


WILL: It's a financial company. 


MIKE: [laughs]


JUSTIN: So, I got an opinion about that one, too. The CEOs, like, the best CEO that I've known personally was, or is, the CEO of SoFi, Social Finance. He started out; he came in; he had to clean up a mess. But, basically, his job was to, one, clean up the mess that he found himself in, found the company in, and two, sell the company. 


WILL: [laughs]


JUSTIN: And, like, not sell the company, but, like, market the company. Sorry, sell the company, bad kind of takeaway.


WILL: [laughs] No judgments. Sometimes you've got to do that. 


MIKE: So, promote the brand.


JUSTIN: Promote the brand. 


MIKE: Promote the brand, not get acquired.


JUSTIN: Yeah. And promote the brand and raise money. And this guy, Anthony Noto, look him up, he brought SoFi from, you know, being a small company that focused on student loan refinancing to being an investment bank, being a retail bank, being a commercial bank, basically where it is right now, having a freaking stadium named after it, which, you know, seemed like a huge gamble at the time. But now you hear the word SoFi associated every time, you know, down in LA, whenever they play in the SoFi Stadium.


The guy put down a million bucks on the chance that the Super Bowl would go into overtime. And he got, like, a minute commercial just on the chance that the Super Bowl would go into overtime, and it paid off. And SoFi's servers almost suffered a meltdown just based on the traffic generated from that ad. I forget which Super Bowl it was. I think it was, like, 2018, 2019, or something like that. So, this guy, you know, I'm amazed at what he's been able to do and the importance that he has had and the confidence that he had in the company. And he grew the company a ton, and he was able to get a lot of outside investment.


So, he is very good at being a CEO, and there's a special set of skills at doing that. And I think there's a special set of skills at doing whatever your title is, and if you don't have that special set of skills that corresponds to your title, you're not going to have the respect of the people beneath you. 


And I think this goes back to the technical leadership at NASA. It's, like, you know, you've got to lead by example, and if you have the technical chops to lead by example, I think you'll gain the respect of the people that you're leading. 


WILL: So, I've got a question, right? It's always, like...I mean, none of these answers have, like, a real clear pathway. So, I mean, so I'm an engineer, right? And I think, like, you know, you should be able to make things with engineering. You should be able to engineer a solution to a problem, right, at some point in your career, if you want to be a leader of an engineering organization that makes things, right? 


Well, so what about people in the engineering organization that don't make things? What about your product managers, you know? My dad's a prior...he used to be in the military, right? And, like, in the Navy, they had a real big problem with women being promoted in the Navy, in Air Force, in whatever, because, like, foundationally, the military is a combat operation. 


And if you want to be an admiral in the Navy, you have to command. You have to be a ship captain, right? Like, that's how you do it. You'd be a ship captain. If you want to be a general in the Air Force, typically, you're going to need to fly combat missions, combat aircraft missions. And so, like, they had created a lane for women to fill these roles so that they could eventually, like, rise up and become an admiral and become leadership in these organizations.


And so, are project managers just sort of, like, ceilinged out, right? Like, is there no way for them to advance? You know, because, like, they're part of this technical organization, or, I guess, are they, right? Like, should they be put under this umbrella, you know what I mean? I'm just...so, I threw this out here, and I'm just sort of, like, now I'm thinking about the counter to it. What's the counterargument?


MATT: The counter to that is, yes, I think they can grow. What they're good at is managing projects. Running a company is managing projects. It's managing your strategy. It's managing direction. It's managing multiple departments and keeping those things organized. I think the key here isn't so much as what you specialize in as it is surrounding yourself with the people who are good at the things you need done.


MIKE: One thing I was also struck by that you said, Will, there, you talked about being promoted in the military, that they wouldn't even consider promoting you unless you'd had that hands-on experience. And they deliberately carved out a path to allow people who may not have had access to that initially to get that access. That isn't a, like, a testimonial, right [laughs], to this topic we're talking about. I don't know what is. It's just, without that hands-on experience, you don't get it.


WILL: Yeah, but, I mean, like, you just can't...how do I put it? Like, there's a lot of people...it's pretty easy to go from engineering to project management if you have the aptitude for it, right? It's nearly impossible to go from project management into engineering, like, the bar is just...you know what I mean? It's kind of a one-way gate. It's not that nobody could do it. It's just, like, the wall to climb to be a credible junior engineer is just...I struggle to think of any project managers that have gone the other way.


MIKE: Well, we've talked about this in previous episodes, that your first embarrassingly long length of time as a junior engineer you're going to feel stupid. And [laughter]...what's that?


WILL: I said you're going to be stupid [laughs].


MIKE: Yeah. If we're to put it politely, you're going to be ignorant [laughs] in a way that's going to look stupid [laughs]. And it's going to be incredibly uncomfortable [laughs]. You know, there's a comment in the back chat here. I still feel it.


Yeah, we've talked about imposter syndrome. It's a real thing. Because we all struggle working with something that we don't fully understand, and we're never going to. It's too big. It's too much. We're never going to get all of it. And when you're an engineer, you're right in the middle of it. And you have to create something, make sure it works, and have a bunch of people evaluating you for it every day. So, every one of your flaws is perfectly visible. It's the worst sort of performance anxiety [laughs] inducing thing. I'm not saying it's a bad thing because you come out the other side having learned amazing things.


I started by talking about artists, similar sort of thing. Well, yeah, if everybody can see your painting, right? And if it doesn't sell, that's...it doesn't sell. But you have to do it, and I think that that's what makes it so hard to get over that gate is because you're going to have to go and feel like a little kid again for maybe years. It's uncomfortable.


WILL: Well, right. I'm sorry. I feel like I wrecked the discussion, right? Because I posed one side, and then I posed the other side, and, like, there's just no answer to it.


MIKE: Who was it? 


WILL: [inaudible 15:35] center, you know. [inaudible 15:37] You're supposed to do a hot take and then die on the hill. [inaudible 15:42]


MIKE: [laughs] We're the kinder, gentler podcast [chuckles] that aims for, you know, collaboration and an earnest pursuit of truth [laughs] rather than hot takes, although there are occasional hot takes. But I think this idea that you have to have expertise in the field you're working in. Justin talked about the CEO who was really good at that job. And a project manager, I think, could get really good at that job. But I wouldn't want somebody leading my company that hadn't spent a long time managing projects, managing money, thinking a lot about those sorts of problems. 


WILL: And I wouldn't hire him as a CTO, respectfully.


MIKE: Sure. 


WILL: You could be head of product. That's great. Like, Lord knows we need more product-minded people. 


MIKE: No pushback at all [laughs]. The specializations matter. If you think otherwise, go to your hospital and ask for a specialist in a different area to come do your surgery, right [chuckles]? If you're foolish enough to do that [chuckles], more power to you [chuckles]. So, you know, it seems like we've got really strong agreement here, this idea that getting hands-on matters, and we've talked about it mattering in engineering. So, if that's the case, how does that apply every day? Is this once you've done it good enough?


WILL: At some point, you've got to stop, you know? Like, at some point, I think you have to stop because, like, just keeping the ability to, like, do an MR, right, or even build the app, you know? Build the app is, like, it's not worth your time to do it any longer, and it's not really relevant to your day-to-day stuff, right?


I mean, the problem as I see it, if I'm being honest, is that we abandon that way too soon. Way too soon. Like, I think line-level engineering managers should spend half of their time writing code, probably in a pairing situation, so that you're educating people, you know what I mean, on best practices, standards, and things you know, infrastructure, stuff like that, half your time. I'll die on that hill. 50%  of your day should be leading your team directly. I'm talking about line-level managers. 


You go up as, like, a manager of managers, eh, you know, like, yeah, maybe 25% percent, you know? And then if you're, you know, a manager of manager of managers, okay, grandpa, just, you know, you take a knee there. Take a knee, old man. And I think that's fair, too, right? Because, you know, you have influence, but maybe, like, you're not paying the toll to have, like, a real nitty-gritty technical perspective. But I think L1 managers, like, you'd be lucky to get 20% of your time. You'd be lucky.


MATT: We have 11 people on this podcast today. 


WILL: Yeah. Let's go, Matt.


MATT: And I think I'm the one outlier in this conversation, and it probably wasn't expected, but I don't agree that the leaders have to have the technical skills. I really don't. Do they need problem-solving skills? Absolutely. What they need is communication skills. They need to have trust in the people who are helping them lead. That's important because if they try and micromanage a technical company and technical projects, they're going to fail. But I don't really feel that it's necessary to have those technical skills to be able to run a technical group, provided you're surrounding yourselves with the right people and you have those communication and problem-solving skills.


WILL: Yeah, but how do you know, or how do you know efficiently, right? Because I agree with you, right? I would not now nor will I ever say that this is a hard requirement, right? Like, that's fine. Sometimes you can make a lot of money betting on an inside straight. It can be done. I've seen it happen. I'm still mad about it [laughter]. But it's not the way to bet, right?


JORDAN: Something kind of similar is, like, I've heard this thing where just because you're, like, really good at a job...like, let's say you're an engineer, and you're really good at being an engineer, and you get promoted to being a manager. It doesn't mean that you'd be a good manager. But I think at that level of, like, being a CTO, knowing the process would be nice, but I think you're more managing people. [crosstalk 20:34]


MATT: Yeah. And that's the difference between CEO and CTO, right? You look at the company we come from, most of us on this call come from, the person who leads that company is an attorney, didn't come from an accounting background, not a CFO. He's an attorney, one of the best leaders I've ever worked under. We are a tech company. We are a software company. He does not write software, nor should he or does he have to. But what he is good at is leading, and that's the most important skill in leadership, is being able to lead people, not be a boss, but be a leader. Show that you have the integrity and the desire to work and work for your people, and you're going to have the right people follow, and you're going to be successful.


WILL: So, forgive me because I'm outside of, like, Acima, right? I don't know how to org chart. Are you talking about the CEO or the CTO? Because a CEO could come from anywhere, and if you promote an engineer to CEO, you'll have a different set of problems, right? Because they don't know how to sell stuff, but a CEO better know how to sell stuff, right? I mean, so are we talking about the CTO or the CEO?


MATT: Well, that's when I was differentiating, right? I said there is a bit of a difference between CTO and CEO, and I was referring to the CEO.


WILL: Yeah, and the CEO, I mean, yeah. I would never say that product is more important than engineering, or finance, or sales, right? Like, you know, you've got to have four legs on the chair, or you're going to fall down, you know. Which one's better? Who knows, right? But I'm talking about technical leadership. 


MATT: Right. I think --


MIKE: I think it's technical leadership we're mostly focused on here. 


MATT: But I think someone coming from, say, a product background, absolutely capable because they understand the product that they're working with, right? They don't need to understand the deep-level inner workings, low-level stuff. But they do need to understand how things communicate, what's downstream from your services, you know, those types of things are important. But we --


MIKE: Well, I'm thinking --


MATT: Go ahead.


MIKE: You may be thinking about somebody similar to who I'm thinking of.


MATT: I am. 


MIKE: So, I'm thinking about a very capable product manager who I think could move into engineering leadership. But she is also very experienced. She's written code. She maybe didn't do it for years, but she has enough technical background and has spent a period of time over, you know, like, months or years actually grappling with those problems that she gets it. And I think that's why she's such a good product manager is because she does get it. I think that there are some of those skills there that maybe she's not using right now that she's used in the past. And that's part of what's made her effective at her current job and what would make her also effective as an engineering leader.


MATT: Yeah. I think organization size and structure are extremely important in this equation as well, right? If you don't have the right structure, then it's going to break. It's just like software. If you have really bad architecture, your software is not going to be scalable. It's not going to perform the way you want. But if you have that right architecture in place, then it's just going to work, right? And that means support. 


So, if you have the architects there working with you, if you have good data people working with you, if you have good engineering directors and contributors working with you, it's a lot easier to be successful than if you're a small company, a team of five, and you really have to get into the grind of things. It's a different scenario, right? So, I think that really makes a difference also.


MIKE PORRAS: I think that leads into what the NASA article was about that you're referencing, Mike. Like, it's the same thing with a CEO. Like, a good CEO, whether they're technical or not, they ask questions like, "Who should own this? What system makes this decision repeatable? Where is the capital best deployed?" And then they hire and enable people that are smarter than they are. So, they hire credible CTOs, credible, effective CISOs. They give them authority, not just responsibility.


And then the CEO should be judging outcomes, not the cleverness or the personality of that leader. And then you get that...what do you call that? Decentralized authority model, you know? It's no longer up to the CISO or a small body of leaders to execute decisions. It's really up to the leadership structures and independence of the subunits that those kind of, quote, unquote "juniors" of the CEO would be executing.


So, anyway, your article from NASA made me think of a book that I was reading on a road trip I had. It's by Atul Gawande. It's called "The Checklist Manifesto." And it's this doctor and his thesis is all about how repeatable actions, checklists, things like that, are prevalent in so many industries. NASA, he mentions about that, airlines, pilots, things of that nature. 


And then he goes into how it was introduced into the medical field, and now it's a part of a procedure. But in one article, he mentions Hurricane Katrina and how the model for responding to that disaster was, look, if the incident gets so bad, the federal government is going to be the governor of that situation, and they're going to make decisions. And then we need all the local governments and communities to fall in line.


And that was one of the biggest problems why Katrina was so bad was because, at key moments, federal leadership was unable to enable DoD choices, get the right funds, get all the resources they need, and so it just got worse and worse. And that was one of the shared lessons learned from that, was, look, if it gets so bad, we need teams, C-level executives under a CEO, local governments, whatever the situation is going to be, doctors. They need to be able to act on authority for their own domain and have that ability to execute without having to kiss the ring for every single thing they do. Otherwise, bad decisions get worse, or even worse, they just don't get done.


MIKE: I want to try to restate what I'm hearing. Rather than having purely hierarchical top-down decision-making, you need to have people at every level of the hierarchy who are able to act independently and with autonomy, to have a resilient response to whatever the stressor is.


MIKE PORRAS: Yeah. I mean, to a certain extent, I think that's right. And, honestly, sometimes I know, like, I should be doing something, and I know the right choice to make, and I know it'd take two days for me to get approval from my boss and his boss's boss. So, sometimes I just do it, and then if it was wrong, I'll ask forgiveness, not permission [laughs]. And almost 95% of the time, it was the right choice to make. And if it was that 5% percent, great. I'll be good enough at my job to roll it back as soon as it becomes a problem [laughs].


WILL: Well, that's a big...I mean, that's almost a management culture sort of a difference, in that what kinds of people do you promote and why? And are you promoting the kind of people who are sort of bureaucratic, turf war, cover your ass type people, or are you promoting people who will just get it done? And, I mean, that's, you know, gosh, I don't know. That's a thorny side. I come from startup land, where you just have to have that or, like, nothing will get done, because there is no backup. But I would say that those attitudes and the kind of people that ascribe to them are particular kinds of people, and there are trade-offs in hiring a bunch of them [laughter].


MIKE PORRAS: Yeah. Well [laughs], okay, I've seen this trend happen, right? So, what happens if a CISO...oh, sorry, if a CEO hires a bad CTO, or a bad CISO, a kind of a senior VP-level executive, but they turn out not to be credible, or they don't have good ability to lead within their domain with experience and critique, then what happens is exactly what you described, Will.


Because I noticed that the people below a CISO or a CTO will pick up on, "Oh, that guy doesn't actually know what they're talking about." So, now it becomes a game of, am I doing my job well? It's, does the guy above me think I'm doing my job well? Which then turns into political performance and, you know, big talk meetings without actual outcomes and results. And that is a pattern I've seen throughout the industry, even places where I don't work, you know? I think bad leaders beget subleaders [laughs].


WILL: Over and over and over, yeah. Yeah, well, you get bad leaders, you know what I mean, because, you know, what is it? You know, victory has 1,000 fathers and defeat, you know, is just one...Well, there's going to be the Hunger Games when things go bad. And is your leader going to be able to identify and take action as to, like, what actually went wrong? 


Nobody's going to care more than their boss about outcomes, you know? Like, nobody's going to care more than you. Nobody's going to be smarter than you. This whole like, "I'll hire people smarter than me," you can hire people who have skills that you don't have. But, like, you're never going to hire anybody smarter than you, and you're never going to hire anybody that cares more than you do, you know? That's a hard limit. You've got to be smart. You've got to be real smart, and you've got to care. You don't necessarily have to be able to do every job, but, like, those two things are non-negotiable, and it sets a ceiling on everybody under you.


MIKE: Well, it sounds like you're putting a specific definition around those smarts and caring that goes back to our central thesis that we're talking about here today.


WILL: I'm specifically not putting a specific definition on being smart or caring, right? Being smart or caring, like, there's lots of ways to be smart, and I...so, I'd say, okay, right, you could be technically smart. You could say, like, "I know exactly how to architect and design and diagnose a system because I've been doing this for 20 years, and I've seen it all," right? You could do that, right? And then you could be maybe a little bit less sharp in terms of people skills because you've got the technical skills, and you can...you've got a couple steps ahead, and it all evens out and, you know, you could be less strong on that. 


And you could have excellent people and interpersonal skills and know how to communicate and know how to, I don't want to say interrogate, but, like, you could get answers in difficult situations from smart people who are trying to snow you, [chuckles] because that's going to happen. You're going to have to deal with that one way or the other, you know, you look at 10 candidates who are all smart and be like, "No, no, that's the one. That's the person I want." It's got to balance out. You don't have to have a specifically defined set of intelligence, but you've got to be on your game. And if you don't have one, you better have plenty of the other because the job is going to be harder for you, intrinsically.


MIKE: Yeah. You're not defining a specific skill, but you're saying that you must have skills and apply them. You know, without engagement of the talents that you've got, you shouldn't be in the role. So, we've talked a lot about these varying talents that suggest that, well, maybe you don't have to have this specific tech stack of experience in order to, I mean, like, something really specific in order to be a good leader. But you have to have some sort of experience that you have cultivated over an extended period of time. You have to have something hard-won because you get something from that that you don't get otherwise. Does that seem to be a fair synopsis of where the conversation has gone so far?


WILL: Yeah, or, you know, or talent. You know, honestly, hey, listen, man, talented people exist, and, like, they didn't have to go through every step, you know? They could skip a rung or two because they're just that good, and when you meet them, it'll be obvious. But, you know, exceptions can be made for exceptional people. 


But generally speaking, you know, I personally like the statistical average of people who can demonstrate technical excellence in technical leadership positions. It's just safer, you know? And, I mean, that's it. But there's all kinds of ways to be successful, and exceptions for exceptional people always need to be made. If you're in charge, you should be able to identify. It's like, "No, no, no. Yeah, okay, they don't tick every single box, but this one is special, and I will make room for them."


KYLE: Talent is definitely one thing, and maybe it's a natural talent that I'm going to express here. But I think more than anything, it's also a desire. And what I mean by that is I went through a bit of a shift in my career where I had my first few managers, direct managers were tech. I mean, they were very technical. You know, I could ask them basically how to do my job, and they were able to give insight. 


But then I've also had a couple of managers that, probably a couple of my best managers, really, they would not be able to know how to do my job. However, they still had the desire to learn, to be able to understand what was going on. And I think that's the big differentiator, at least in my mind, is somehow you need to make sure that the people that are responsible still have the desire to at least understand to an in-depth level of what's going on, even if they aren't experienced.


JUSTIN: I kind of want to shift a little bit in the direction of the conversation and bring it more towards, like, what I saw when you sent out the NASA prompt. 


Two years ago, I could see this being very applicable in the classic engineering sense. But now, with AI, I see a new hazard where people are surrendering their technical experience or surrendering technical expertise to the LLM and just trusting whatever the LLM says. And that hazard or that bad thing that is coming down the pipe, that's just going to get worse and worse over the next couple of years as people depend more and more upon the LLM because the LLM is really good, and it's getting better. But is it causing this...could it cause the same thing that NASA saw, you know, 10 years ago or whenever this paper was written? So, I just wanted to throw that out there and get you guys' thoughts on that.


MIKE: And, honestly, that was the thrust of the original blog post I read that led to our discussion, is exactly that, that the AI doesn't have the years of hard-won experience, whatever that experience is. And we've been talking about, well, there's different kinds of experiences, but you have to have that drive, the desire, and the curiosity to be able to pursue it. And without that, if you're outsourcing your mind, you know, your...because we all use tools, right? There's nothing wrong with using a tool. But if the tool's wielding you, then you get in trouble.


WILL: Maybe I'm going to be Matt Hardy for a minute and say, like, you know, I have a different opinion. I'm not worried about it because here's the thing about writing software. It's going to come **** you up, you know? There's no...technical debt is technical debt, is technical debt. It will be paid. You will pay it. And if people start writing bad software, they're going to get got. 


I was just recently on an enormous company-wide email training tool rollout push, which was disastrous, and I don't even know. I don't even want to think about how many millions were spent on it. But, foundationally, like, these LLMs are great tools. They're great force multipliers for skilled hands. They're like a power tool. They're like a band saw or whatever. But they will take your finger. They'll take your whole arm. And I just don't see it changing, and I don't see people getting out of writing crappy code. Like, it's a force multiplier, and it will multiply force in good or bad directions. But I just don't see people getting out of this fundamental thing. And, you know, as I learned in my high school shop class from a man with 8 fingers [laughter].


MIKE: Well --


JUSTIN: I love how you said it's a force multiplier, and you bring it back to, like, what an LLM is. It's like calculating the distance between vectors and stuff like that. You have one vector that you want to go to get the job done correctly. And this force multiplier will push you in that direction if you choose to go in that direction. But it's very easy to be force multiplied in any other of your dimensional space other than the way that you want to go. And you will go so far out of there so quickly that finding your way back, you might as well just throw it away and --


WILL: Yeah. It's like rocket boots, right? We invented rocket boots. You can look at it on YouTube, where it's like, "Hey, wouldn't it be cool if we all had, like, jetpacks or, like, Iron Man jet boots, or whatever?" And some lunatics, they built them, and it's so cool, and it's fantastically, fantastically dangerous. If you want to die, buy yourself some rocket jetpacks on eBay and take it for my benefit, you know? I don't know. It's great, but you still got to drive a car. You still got to land a plane.


MIKE: Absolutely. 


WILL: I might get laid off temporarily between here and there because some executive got pixie dust in his eyes, but don't lose that number.


MIKE: Interestingly, I know somebody...about 13 years ago, they did an interview with the owner of a company, a startup, and they said, "Well, you know, I'm interested in starting. You know, I'll help you out, but these are some things you have to do." And the owner really wasn't interested, and he said, "Okay, that's fine." "Here's what's going to happen." And he gave him a list of things that would happen. This is a very successful engineer. 


About two months later, the owner called him back and said, "You know what? I want to hire you because exactly what you said would happen is what happened. It went that way." And, basically, they had outsourced everything, right? It's something that you can always do, outsource your work, don't own any of it. Very similar to what we're talking about here, just a different mechanism. And all of the failure cases that [chuckles] he expected to happen were exactly what happened. He came back, hired him on, you know, developed more of a culture of excellence. The company was very successful. 


It doesn't change, right? The fact that you still need somebody with a steady hand who knows where they're going, regardless of what the disruption is, whether it's AI, or outsourcing, or, you know, the tool du jour [chuckles], whatever it is today, it doesn't change. That expertise still matters, and they'll come back if they know what's better.


So, we've talked about AI and about how we could surrender ourselves, but no, don't. Make sure that you're in control. We've talked about leadership. With so many temptations to offload some of your agency to these tools and maybe give a little bit [chuckles], to lose some of your personal excellence. How do you keep it sharp? If you're the CTO [chuckles], that's going to matter, right? Somehow you're going to have to stay sharp, even if you're not writing code. 


And if you are a contributor writing code every day, maybe that's not as much of a problem, but yeah, it kind of is, because you've got AI there to take it from you. You've got the newest tool, and you're still writing COBOL. It's going to come along. You know, what advice would you give? What's your experience in staying relevant, keeping that engineering excellence?


MIKE PORRAS: What I've noticed is, by using AI to augment my workload, I get good at things that I would not have had an opportunity before, because I never would have had that bandwidth. So, for example, you know, Kyle can attest, this past two weeks, I've just been writing nonstop code to build a web application firewall. In AWS, that's a major pain because it's just...I don't like this particular part of AWS. It's one of their biggest shortcomings. 


But as I noticed, the pull request process, you know, I know what I need to write, and I know what that would look like. I have the Terraform experience to know how that should be done well, and so I think I would do a good job. And I would tell Copilot or whatever I'm using, "Hey, you wrote this, but I actually want it to be this, this, and this." So, I am being critical with Copilot, and I'm spending the time reading the code to make sure it's doing the job. 


But as soon as it gets to that PR level, Kyle, or someone from platform ops, will read in there and be like, "Actually, I think you could do this better." And that point of reflection when it's...it's almost like I'm rubber ducking everyone in that pull request. And just by doing that, having that conversation of bigger, better architecture is something I would have never had before because I would have taken so much time and energy just to get to the point of a PR that I can never have that flexibility of saying, "Oh, I'm at the point of a PR, and what this person just suggested is such a better idea." 


And it's an idea that Copilot, or whatever tool I've had, wouldn't even come close to doing because it's a completely different paradigm, different context window of everything I'm doing. That is the part that I think we're getting good at with Copilot, or AI augmented engineering, is the ability to spend less time and energy getting the basics done and spending more time and energy thinking of bigger and better ideas than what we're bringing to the table. That's what I like a lot.


WILL: I feel like, foundationally, right? And, I think, correct me if I'm wrong, but I think the actual, like, genesis of the LLMs was in solving translation problems, right? Like, translation between natural languages. I think that was one of the major, like, drivers and use cases behind LLMs. And so, what I have noticed is that they're fantastic, just absolutely transcendental for those sorts of jobs. 


And what is, you know, I don't know Python, for example, right? Python. But I wouldn't even blush at picking up a Python project. I'd be like, "Yeah, put me in, coach. Let's go. Let's do some Python." Because I know Ruby real well, and I know Java, and I'm pretty good at Scala, and ML, and Common Lisp, and JavaScript, and between all of these idioms to express a logical, procedural outcome. I'm not really worried about doing something in Python, or doing something in Go, or doing something in, I don't know what, you know, Erlang, whatever you want to call it.


And so, like, one thing that I've always been...this is a deficiency that I've always had in tech. I can't stand writing shell scripts. I hate it. And I already used my F bomb, so I'm not going to tell you how much I hate it, but I hate it. And I bet you can imagine how that would go. But I don't have to anymore because I can have the LLM write it for me. Check this directory, check these files, you know, filter this thing, give me a little awk, you know, to, like, process some stuff and, like, bing, bang, boom, we're good to go. I know what I want. You just don't know what the word for it is in your language. And that's been absolutely just glorious. 


And there's so much stuff I think, you know, as a very experienced engineer, where I know what I want, but I know I don't know how to say it. And I know what a schlep it would be to find the exact expression in Esperanto, you know, in the documentation, and so I just don't. Or maybe I should say before, I didn't, but now [vocalization] we're off to the races, which is a thrilling time to be in tech, in all honesty. I feel like I've been superpowered, you know? Because I could fly a plane, and now somebody handed me my jet boots, and I'm like, "Let's rock."


MIKE: That's maybe a good place to...well, I'll take that further, to land this. That [chuckles] we have this ability to have, you know, this great power, whether in leadership or as a contributor, with this AI backing us up. The need to have that grounded somewhere never goes away, and to have the humility to recognize where that is and embrace that, keep at it, to keep learning from it so that we don't blow ourselves up, it's a good thing. We could probably talk about this for a long time, and we may revisit this. This idea of caring about being grounded, I think, really matters. 


Until next time on the Acima Development Podcast.