Coding Myths

About this Episode

On this episodes, the panelists dive into common myths surrounding software development. Kicking off with a reference to Fred Brooks' "The Mythical Man-Month," the conversation challenges the notion that adding more developers to a lagging project will speed up its completion. The discussion quickly expands to explore contexts where adding skilled, senior developers might indeed be beneficial, drawing analogies with emergency services during crises where more hands on deck can mean saving more lives.

As the episode progresses, the group delves deeper into the complexities of software development projects compared to other types of engineering and construction tasks. They discuss the unique challenges of software development, such as the dependencies and the need for sequential progress in certain areas, which can create bottlenecks regardless of the number of developers. This leads to a broader conversation about the necessity of strategic planning, the value of experience, and the pitfalls of assuming that increased manpower translates directly to increased productivity.

The dialogue culminates in a reflective discussion on the philosophical and practical aspects of software development beyond mere coding. The group touches upon the ongoing nature of software projects, the critical role of stress management, and the adaptability required in the tech industry. They highlight that, unlike more tangible engineering projects, software development is often about continual iteration and improvement rather than reaching a definitive endpoint. This conversation underscores the blend of technical skill, strategic thinking, and emotional resilience necessary to navigate the evolving landscapes of modern software development.

Transcript:

TAD: Hello. Welcome to another episode of the Acima Development Podcast. I'm Tad, and I'm going to be hosting this episode today. I'm joined by Will, Justin, Mike, and Ramses. The topic we're going to be discussing today is Common Myths About Software Development. And when I heard this, I thought of one of the classic myths.

There's actually a book called The Mythical Man-Month by Fred Brooks, and he talks about how adding extra developers to a late project isn't going to make that project go any faster. Or one of the interesting examples he gives, I think it's from that book, too, is you can't have nine women produce a baby in a month. You know, human development process, nine months, there are no shortcuts. Have you ever worked on a project where they thought, oh, we'll add more developers to this project, and it's actually worked out?

MIKE: There's a very specific context where I've seen adding developers to a project actually helps, and that's when they are developers who are already very experienced in the industry and deeply familiar with the code at play.

WILL: Yeah, we write it small, right? Like, your team lead or your engineering manager, you know, your senior engineers they kind of fill that role, right? And they sort of, like, parachute in firefighter. If things aren't going well, you need to deploy special forces to, like, help get this thing over the hump. Yeah, I think that's kind of standard, right? And, like, you know, you could deploy as many senior resources as you have available and familiar, you know, which is usually not as many as you'd like.

MIKE: You had one phrase in there: as many as you have. Those three words are doing a lot of work [laughs]. Because if you've got an army, you have very few, like, Navy SEALs, right [laughs]? The elite forces are a small subset of your total workforce.

JUSTIN: It's also worth noting that it's very expensive, both in time and treasure.

MIKE: Ah, yes.

JUSTIN: But going back to your original point, Tad, I think it's like, it is something that is not the norm. Like, you just can't hire contractors to come and solve your problem.

TAD: It's a little counterintuitive, though, because in a lot of cases, adding more resources to something does increase the productivity, right?

JUSTIN: I don't know. Like, can you cite some examples?

WILL: Well, I mean, if I had an emergency room, right? I had an emergency room, holy cow, I'm so backed up. There was a train crash, and I have a lot of, like, patients coming in. I could bring in doctors, you know, I could bring them in or on call. And if I had to the degree that the facility could accommodate them with operating rooms and stuff like that, you know, I could bring in ER doctors, you know.

TAD: More nurses, right?

WILL: Fairly --

TAD: And you should probably increase the throughput in your ER if you did that.

WILL: Yeah, fairly linearly. And you could treat more people, right? And that's a high-skill profession, right?

MIKE: Exactly. Exception proves the rule because you're talking about one of the most notoriously highly paid professions out there [laughs] because it does take that deep expertise.

JUSTIN: So, another example that I'm familiar with is I worked in construction for a while, and, you know, this was back when I was in college and such. And you're working on a big project, and you're building a large building. Like, in this specific example, we were building a library, like a college library. And you can paralyze some things, but other things they have to be done before you can work on other things. And so, there's these natural choke points that you literally can't throw more people at or resources at because, like, the concrete has to set, or the dirt has to be, you know, prepared, and packed, and everything.

WILL: Exactly, yeah, yeah.

JUSTIN: And so, it's the same sort of thing when you're developing software. You have to decide on architecture. You have to decide on, you know, the third-party APIs you're calling. You got these things that you have to do, and you all have to follow the same pattern, hopefully, as you do the various things that you need the new thing to do. And if you have everybody doing different things, you might finish it, and it may be functional, but it's not going to be fun to maintain.

WILL: Yeah, and, I mean, I think it goes back to like, sort of, like, running projects. I mean, I think there's really deep parallels between, like, sort of, like, you know, sort of sequential and parallel programming. It's like, you know, multi-cores, right? We've all got eight cores on our desktop. If you want to keep those cores hot, all of them hot, like, that is ferociously difficult programming, right? So, like, to create, I take a process and parallelize it. That's a fantastically difficult programming challenge.

And I think analogous to that is okay; I've got eight people on my team. We all have to get this thing done. You know, how do I keep all these keyboards hot at the same time to, like, not choke point out, right? Because it's exactly as you say, there are natural choke points. And, like, you know, do you set up scaffolding? Do you set up, like, a fake API server so people can do the front end while the back end is still cooking? You know what I mean? All of these things. And that's a very difficult engineering challenge to, like, maximize the productivity of a squad with these natural in-built choke points. It's tough to do, really tough.

MIKE: Well, and that's a really good...thinking about getting parallelized work on your processor, some of that algorithm is to guess, right? To make a best decision and have it start doing some work that you might have to throw away. To get that parallel, that level of parallel work, you're probably doing a lot of throwaway work.

That is part of the price of trying to get that parallelism is that sometimes you have to go down, you know, rabbit holes that you just have to completely drop. And, you know, that may be true even when it's serial load, but even more so when it's parallel. If you don't know which way you're going to go, you have to do both. And, again, there's cost that comes from that. And if you want to massively parallelize, you're probably going to be doing a lot of throwaway work.

WILL: Absolutely, absolutely. I mean, it's a fact, an absolute fact that parallelizing, multi-threading a process is always less efficient, you know what I mean? If for no other reason than the job-switching infrastructure, you know what I mean? If you're real dorky, you could spend a lot of time on that. But, like, you got to do stuff every time that thread switches context. Every single time. You know, say nothing of deadlocks and all that stuff, so, you know, yeah. Absolutely.

But I do actually think developers are too afraid of scaffolding that's intended. Going back to construction again, right? You're building infrastructure with the explicit end goal of tearing it all out. You know, it gives somebody a platform to work on while the stairs don't exist. I think embracing that with both hands winds up being a pretty big net win, in my opinion.

MIKE: That's an interesting observation there. You say you deliberately build something you know you're going to throw out because it expedites the other work getting done.

TAD: Because it's pretty disheartening to throw code away. As a developer, you take an emotional hit when you've been working on something for two weeks, and they say, "Ah, we're going to go in a different direction." You're like, "Oh, sad [laughs]. Well, into the trash goes all my efforts."

WILL: Yeah, absolutely.

EDDY: And it hurts more when you have it tested. Like, when [laughter] you have all your tests [inaudible 07:55] out, and it turns out you don't need it anymore, and it's like, ah.

MIKE: There's a mindset thing here, though, of what value we're trying to provide to the business. We're not trying to provide code. We're trying to solve problems. And [laughs] if we approach it from that perspective, we say, "Yeah, this was a step in working towards solving that problem." You know, I think we have to be kind of relentless at ourselves that way. The code is not the end product here. We're talking about myths. Our job is to code? Boy, that is not our job.

TAD: Well, it's a component of our job, right?

MIKE: It is.

TAD: Well, maybe we should flesh that out a little bit. What are the other aspects of software development other than code?

MATT: Number one, communication.

TAD: Right, because you're talking about what you're going to build before you ever write a single line of code, usually.

EDDY: Stress management.

MIKE: Think about big construction like a bridge. You would not consider hiring an engineering firm that wouldn't take a year planning before they ever put a shovel into the ground, right [laughs]? Because it's recognized that for big projects, planning is a big part of the work. You've got to coordinate. You've got to figure out what you're doing. You've got to figure, you know, you've got to do surveying [laughs] to figure out what's going on.

You may not have that if you're doing small-scale construction, but absolutely for the big stuff. And even for small scale, I mean, you're going to have a blueprint, hopefully [laughs]. Even if you're building a shed, you probably have a drawing, right? That is work. There is a great deal of work that goes into that construction project that is not the hands-on laying down the materials.

MATT: Then it becomes like putting Legos together, right? If you plan everything well, you know the pieces that need to be put together, and then you just need to put them together.

WILL: Yeah, but, I mean, that's the standard. That's the standard. That's your waterfall model, right? That's waterfall development, which, I don't know, I mean, like, I'm pretty partisan, you know, in terms of I like smaller pieces of work, even if the overall strategy is like, I want to get this big thing done, you know what I mean? Like, I like small pieces of work because I just, you know, and we touched on it, I think, the last session.

Like, I am deeply...I'm not skeptical or cautious of overestimating how smart I am and how good my strategy is and stuff like that. With construction, if I'm building a dam, that's where it is, you know? Like, there's a lot of stuff where it's like, you can't go back, or it's prohibitively difficult to go back. But with software, you do have great flexibility for most projects.

MATT: Yeah. You've called out a good point. I think remaining agile is super important in today's software development world, right? It's necessary. Preloading the planning, yeah, sounds very waterfall-ish. If you can do that, maybe it's just the time before it hits engineering that happens, you know, and by the time it gets to engineering, then it's broken down to smaller problems. And you break it down into simple stories, and you can work from there. That's, I mean, to me, that's agile programming.

TAD: Is there a myth, though, that programming is predictable? Because what's that quote? You know, everyone has a plan until they get punched in the mouth [laughter]. I've never worked on a software project that has gone exactly according to plan.

JUSTIN: If it's a very simple well-known use case, you can do it very quickly. So, like, you know, I want to set up a blog, you know, have comments and everything, and that's, like, every single tech demo ever. So, you got every single language that you could do it in, in datastore and such. I was thinking of a really good example of something that is well-defined, and that can be put together in the real world.

And there was, like, a news story about the U.S. Navy putting together a port in Gaza to unload supplies for the refugees or the people who live there. And they basically could put together this pre-assembled port that the Navy uses on any combat situation, and they could put it together very rapidly and people who know exactly what to do. And all of a sudden, you have this port where huge ships can unload supplies on.

And it's just an example of, hey, if you have a well-defined problem and you have the tools to solve it, you can do very big things very fast. But if you go off that path, then you start having to, like, call in the experts and decide, okay, now that we're going off this path, what should I do in such a way that I'm building something that will last and that is durable? So...

WILL: Right. Well, I mean, and that's the nature of software sort of consuming itself in that, like, when you have that sort of, like, pre-built port roadmap, that's a software product, you know what I mean? Like, when it comes to software, like, when you have things defined to that degree, then it's just, like, push a button, you know what I mean? Like Shopify, right? If I want an e-commerce store, Shopify can get me up in an hour, you know, and they do a pretty good job at it. And so, it becomes, well, what else do you want to do? And fortunately enough for us, they always want more, just a little more.

[laughter]

MATT: And if you want to integrate with Shopify, that's another story.

WILL: Sure. Absolutely. But, like, if you wanted to integrate with Shopify, well, that's something, you know, new that Shopify doesn't do. And then, we're into custom software land, and I'm making my [inaudible 13:37] payment this month.

TAD: That does touch on one of the myths I was thinking about earlier today that a lot of times we parallel software development with things like building a dam, or construction, or things like that, and those things get finished, right? They complete the project, and then they walk away and move on to another project. And software, just because it got released, doesn't mean that you're done.

WILL: Oh yeah.

MATT: Never done.

WILL: Yeah, yeah. I think that's a myth.

EDDY: But when you --

WILL: So, the software is released, right? It's done [laughter]. Like, it's –-

MATT: [crosstalk 14:16] that you're finished, right?

EDDY: Sure, but you got to have people to go back and maintain whatever it is you built, whether it's software, whether it's a building, a car; it doesn't matter. There is a level of maintenance that still is required.

TAD: Even saying built makes it sound completed or finished.

MIKE: Yeah, and to take that further, some software products that we use were created for some utterly different purpose. Didn't Slack come out of, like, an internal messaging video game or something?

WILL: Some, like, in-game chat or something. Or was it just inside the company?

MIKE: I think it was just inside the company. So, they went to build a video game, and they ended up building a business messaging platform. Like, when we say build and release, like, yeah, I went to build a video game, and I built business software. And if you were going to build a bridge, you say, "I went to build a bridge, but I actually built a skyscraper with an airport on top." It doesn't work that way, but we have to do that all the time.

Think about that planning that was brought up before. Yeah, that planning, that cost still has to happen. But recognizing that we have to do these iterations, we still do the planning, but we do it on a smaller loop. We don't spend two years doing it upfront because we know that work is going to be thrown away, right? But we still have to do the work. It's just done in a smaller loop. So, you're spreading it out over the two years rather than doing it upfront.

You still have to have that feedback, and there's still the work involved. There's still the job of communicating, figuring out where we are now and where we go next, and that never goes away. Whether it's upfront or whether it's later, it's still there. And if you try to pretend it's not there, you'll get in trouble quick, I don't know.

And that brings me to another myth. I pointed...it's xkcd number 2030, two zero, three zero. I think about this all the time. It's about voting software, which is kind of irrelevant. There's a line from it where the character says, "I don't know quite how to put this, but our entire field is bad at what we do. And if you rely on us [laughter], everyone will die." And if there's one myth I see about software, you expect that people just know what they're doing. No, we don't [chuckles]. We don't know what we're doing. We don't even know what we're building.

We're building a video game that's going to end up business software, right? And that's not even necessarily a bad thing. We're building something out, and then we'll have something of value and see if we can use it. You know, it's this weird product that's kind of, like, other things and kind of unlike, I say, other things in that it's flexible, and sometimes it meets different needs. And it means that it's kind of hard to talk about, kind of hard to deal with. And we make a lot of foolish mistakes.

I've seen this with new developers, particularly people who change career later in life. They come in and they think that we all know exactly what we're doing, and it takes a while to be disillusioned. You got to kind of break that early and say, "It may look like we know what we're doing, but a lot of our job, maybe not most, but a good portion of our job is trying to figure out what we're doing. We're researching it as we go. We don't know how to use the tools. We don't even know what tools we're using, and we don't understand the requirements. So, a big portion of our job is figuring all that stuff out so that we can get something that works out in the end."

TAD: And a lot of times, you can't know what is needed, and what you need to do, and what the requirements are until you actually jump in and start poking around and doing the coding, doing the research, doing the things, getting both hands into the project. And you're like, oh, now I'm starting to see what shape this needs to take.

WILL: I mean, that ties into something that Eddy mentioned in passing, and it's a myth that I think...let me see how to put it. So, what Eddy was saying was, like, stress management is, like, most of what we do. And I think the myth of...and, I mean, I agree with that, and I think I'd maybe, like, broaden it out to say, like, I think people think of software development as this intellectual exercise. And there are sort of fairly specialized slivers of it that can be that. But by and large, you have to be smart enough and willing to sort of, like, bulldoze your way through thinking about the problems, thinking about the requirements, thinking about the legacy source code and how it works, thinking about, like, you know, how you do the stuff.

I mean, if you even look at, like, sort of, like, these programming puzzles that some people like for interviews, right? LeetCode medium, right? It's far in excess of anything that we actually have to do on an intellectual problem-solving level. What we need to do is maintain, like, a sort of, like, emotional equilibrium and focus on this fairly mundane, ditch digging, systems integration, team collaboration, requirement, negotiation, source of problems. Like, that's what will make you...

Like, if you're, you know, slightly above average intelligence but you have exceptional drive and emotional equilibrium, you know what I mean? Then you're going to be a very successful programmer. But, like, if you have exceptional intelligence and, like, you're a little bit squirrely in terms of, like, just grinding through, like, the necessarily frustrating tedium of, like, professional software development within a business organization, you're going to have a very difficult time, you know what I mean?

TAD: Yeah, and I think there's a myth that all software is kind of the same and that the skills needed are kind of the same. For example, I hear a lot of people ask, "Oh, are you really good at math? You really need to be good at math for software development". And then, I have to say something like, "Well, yes, if you're writing software for a nuclear collider, then you're going to need a lot of math. But if you're a front-end developer wanting to make some really cool interactive thing, maybe you need to know a little bit more design, and you don't really need that much math." Or the example earlier, set up a blog. I don't think you need any math to set up a blog probably, right? But those are all software development.

MATT: Yeah. And maybe this is just me, but I think the people who are just naturally good at math make good software engineers, just that mindset and the way they do things. They may not make the best front-end people, but there's a place for them, right? I think a myth also could be that, hey, I should just switch over to software engineering because the pay is great. I've seen a lot of people make that mistake. It's not for everybody.

WILL: They're having their day right now. I think there's a lot of people who came in for the bag, you know what I mean? And now we're in tech winter and, like, those doctor money FAANG jobs are a little short on the ground. And so, it's just like, "Would you only do this for a paltry $120,000 a year like a peasant?"

MATT: [laughs].

WILL: Like, "Whoa, whoa, whoa, whoa. I'm going to go back to finance," or whatever, right? And those kind of people. And then, you know, you have to wake up every day and want to do it, you know what I mean? I mean, just because, like...I'm pretty good at programming, but every project, you know, like, I got to wrestle the pig every time. It's a brand-new pig, and you're going to have to get in the mud every time. Every time. It doesn't get easier. You just get, I don't know, stronger, you know?

I was having a conversation with somebody who was talking about like, you know, like, needing to hire somebody and the difficulties associated with hiring people and how you'll have these people who, they'll go in, and they'll crush their interview. Like, they'll do really good on these algorithmic problems, you know. And then, you'll take them into the actual workplace where they have to go out and, like, you know, do the actual nitty-gritty nuts and bolts jobs. And they'll struggle or, like, they'll do good for a while. And then, sort of like the morale will fall off, and they'll struggle. And, you know, and, like, you'll have smart people who just can't maintain the focus of, like, staying after it, you know. And then, they will be bad because it's a nonstop grind and, like, yeah, it's tough.

TAD: I've heard it compared to a treadmill.

MATT: That's one of the reasons, Will --

TAD: If you enjoy the exercise, then a treadmill is not bad. But if you're constantly learning and you're constantly working on things, maybe you're frustrated some of the days, right? Not everyone enjoys exercising on a treadmill.

MATT: That's one of the reasons I don't ask the mapping of matrices and things like that in interviews. I just don't. I don't ask really computer sciencey questions because that isn't the real world most of the time.

EDDY: Okay, but the real question is if someone came up to you from your family and said, "Can you fix my computer?" Can you? Can you fix that computer?

MATT: Ugh. I hate that. That is the worst question ever, Eddy.

EDDY: [laughs]

TAD: Yes, that's why I have a master's degree.

EDDY: [laughs]

MATT: Sometimes. I mean, you know, sure, we know that stuff, but it's not what we do.

TAD: Yeah. I mean, I can Google as well as the next person.

WILL: I can Google much, much, much better than the next person.

TAD: Actually, that's true.

MATT: Which is what we spend a lot of our time doing, right?

MIKE: That's one of the most critical development skills is Googling.

TAD: Finding the right information, right?

MIKE: If you think that managing hardware and setting up something with, like, the TV is what we're good at, then you should see any engineering meeting trying to figure out the presentation, like, the hardware in the meeting room [laughs], just trying to get a meeting going. It never works.

MATT: Let's not even get started on spreadsheets.

WILL: I'm terrible at spreadsheets. I don't know how to do them. Like, as soon as...whenever I've had a spreadsheet, like, challenge, like, I Google it. I learn everything I need to know for the next, like, 15 minutes of work, and then immediately cash dump it. I'm just like, pfft, flush. That's out. I'm out.

MATT: I do the same thing.

WILL: Pivot table, whatever. I know the word pivot table is usually the answer to my problem.

TAD: [laughs]

WILL: And then, if you put a gun to my head and ask me to write up a pivot table in Excel, you better have a bucket and a mop.

MIKE: You know, you said something about we're focusing on the, you know, the grind and the treadmill. I read a quote from a bikepacking racer. I don't remember which guy it was, but I read it recently. And he said that that kind of racing, like endurance racing, and it could also apply to marathons or ultra runners, that kind of thing, he said that it's mostly about fatigue management. And you think, oh, you know, it's about building strength. And he's like, "No, it's, like, about eating the right food and managing your sleep and not pushing yourself too hard."

None of those are, like, things that you might necessarily think about have to do with racing. Like, eating? Racing? What? No, it's about managing your body and your equipment so that it can keep going. And that sustainability, you know, trying to think about that metaphor, that sustainability really is, like, a central aspect of our craft. And you can get off, right? You can get unsustainable, and that puts you in a bad spot.

MATT: You end up in burnout. Be good at compartmentalizing, right? I know you and I have talked about that before, Mike.

WILL: It's legitimately tough to do. I think there's a lot of places that are in...I will call them...I mean, honestly, I'd say, like, go at doom loop, you know what I mean? And I was talking about this with Mike a little bit, like, before we got on. It's one of the things that I've been seeing because, like, you know, we're in tech winter now, right? So, things are rough. You know, layoffs are happening, you know what I mean? Like, teams are squeezed pretty tight. I think it's across the industry. Even if you made it, even if you're still working, like, you still have, like, the reaper's hand on your shoulder being like, "How are the tickets going?"

[laughter]

And so, you have these situations where, like, you know, you have a business downturn. You have business pressure. And then, they'll have layoffs, you know what I mean? So, like, that impacts morale. You lose head count. Maybe you don't have nine women to make the baby in a month. Maybe you only have eight. And then, that impacts productivity, and then...you know what I mean?

And a lot of it really is sort of, like, it impacts people's emotional equilibrium, their feelings about their work, you know what I mean? Like, I think it's very understated, you know because it all exists in your brain. And without that focus, that willingness to focus, that willingness to, like, really concentrate, things become extremely tenuous. And you get into the burnout mode, you know.

But you can't stop peddling because, you know, you got business pressure. And, like, you got to make your deliverables. You got to make...you have to make money so that the business can give it to you. And you find yourself with these doom loops, these ugly, ugly, ugly spirals. And I see a lot of that in a lot of places when I talk to folks in the business right now.

MIKE: Which comes back to the same thing, that tenacity [laughs] and fatigue management is going to be the thing that gets you through that winter. My grandfather lived through World War II in Norway. And his family survived through the winter on a barrel of pickled herring [laughter]. [inaudible 27:54] through the winter on a barrel of pickled herring [laughs] is how you get through the winter. Recognizing that it may not always be very nice. There probably will be spring on the other end.

WILL: Oh yeah, and it always will be. Nobody's throwing their computers at the dumpster. I don't see it. It's like people would just be like, "Ah, the internet. We're over it. We're done [laughter]," right?

MATT: At least in my experience, there's always a light at the end of the tunnel. You're going to experience burnout. It happens to everyone. Like Mike's grandfather, you just power through it, and you do what you have to do to survive. And, eventually, you know, this can be the greatest job in the world. It can also be the hardest job in the world. And you're going to experience both of those.

WILL: It depends on the day [laughs]. It depends on the day. Sometimes, it depends on the hour. I mean, I will say that, like, that grind...I don't remember where I heard this, but, like, tenure of a software developer is they usually make it, on average, to about 36. That's not a lot better than playing in the NBA.

[laughter]

MIKE: Well, that's interesting.

MATT: That is very interesting.

WILL: And I believe that number could be out of date, at the very least. I remember it very clearly that I definitely read that, and it could be, you know, maybe a shaky study. But, I mean, I remember the number because it struck me so viscerally. I'm like, oh my God. Like, if you look at somebody like, I don't know, like me, I'm 44, right? If I was a physician, an MD, I'd be, like, just entering into my best years, entering it. It's like, well, you know, he's still a little green, but he's starting to get his feet under him. You know, I think he's ready to go.

But, like, as a software developer, it's just like, you know, people looking at you like Old Yeller, you know what I mean? [laughter] Where it's like, you're walking into the office with a limp, you know what I mean? Like, let's take you back behind the shed.

MATT: Well, just with this group here, we're doing pretty good with those odds, right?

MIKE: Yeah [laughs]. I'm thinking people I've known who have gotten past that or maybe the people who did have the ability to keep going. I've worked with some experienced people. I do work with some experienced people that I find their experience to be indispensable. I don't know how they could do their job, or I could do my job without being able to rely on those years of experience that they wouldn't have had at 36.

WILL: I've found that older developers tend to be pretty bimodal, you know what I mean? Like, there's not a lot of, like, developers, you know, like, north of 40 that are in the middle. Like, it's not really a bell curve. It's kind of like you're either --

MIKE: [laughs]

WILL: Awful or you're fantastic. I'm trying really hard to head towards the light because I have met some awful ones, some truly, truly bad ones where it's just like, you gave up several years ago.

MIKE: So, that can happen when you step off the treadmill for a while [laughs].

TAD: It's something that you got to keep working on all the time because technology keeps advancing, and you got to keep up with the advancements, right? Not necessarily all of it everywhere, but at least the stuff that's relevant to what you're working on.

MATT: We're all going to be prompt engineers before you know it.

WILL: All ready. All day.

MIKE: [laughs]

WILL: I think that's where things are going. I think that AI tools I think they are going to be a fantastic force multiplier, but they're not taking anybody's...well, I wanted to say they're not going to take anybody's jobs, right? But, like, if they double your productivity, you know, the head count's going to go down by 20% probably.

MIKE: There was an agricultural revolution back, what, in the 1800s? And that doesn't mean we don't have farmers. We still have farmers. But they generally operate at a much larger scale, and they're a much smaller percentage of the population. And interestingly, new fields of labor opened up because everybody wasn't farming anymore. I don't think our jobs are going away. Like, there's still people developing software.

And it took a while, you know, but agriculture still exists. It's an important industry. And, you know, there are farmers. Farmers exist, but the way they operate is different. And there's new industries that didn't exist, like I was saying. You know, they've enabled different ways of working. And so, a lot of people who would have been farmers are now doing stuff that's adjacent to that or maybe totally different to that because it's enabled by the farmers being more effective.

I think we'll have similar kinds of transitions that are a little hard to think about. You couldn't have explained a software developer to a farmer back in 1830. Conceptually, that work didn't really exist, and we couldn't even conceive of it. But I think that we'll have that similar sort of transition where, yeah, there'll still be people developing software, but it'll be a different format. And the jobs people have it might not be prompt engineer. It's going to be something that is going to be kind of incomprehensible, I imagine, to us right now. But it would make sense if you saw the evolution over time.

TAD: But I think it's kind of a different beast, right? Because I don't know of any organization that's like, "Oh, you guys have doubled your productivity? Oh, well, we're going to keep the same number of feature requirements that we had," right? They're like, "Oh, you've doubled your productivity? Sweet. We can, like, have twice as many features as we wanted before," right?

Well, I haven't experienced it yet where they've run out of ideas or new software projects or things like that, where they're just like, "Oh, well, we're kind of running low on places to spread our software or new places..." you know, it's like...because I imagine, like, even if we suddenly, like, 10x our productivity overnight, they'd be like, "Oh, sweet, we're going to move into, like, more countries than we were planning," or "We're going to have more features per year than we were planning."

WILL: And I'd also say, like, even more so that because of the nonlinear increase in complexity as software scales, right?

TAD: Yeah.

WILL: Let's say everybody doubles developer productivity, which is, like, a pretty bold statement, but, like, attainable, attainable. But that's probably the top edge of attainable, in my view, with, like, the AI, like, stuff. That's, like, 20% more features because, like, it isn't linear, you know what I mean? 20% more features. Because if you have 20% more stuff, like, I mean, so, within Acima, I mean, think about, like, it would be maybe one other big initiative, you know what I mean? You know what I mean? Like, you'd add one more team feature thing, right? I don't know how many teams you guys have now.

MIKE: I think you're onto something really important there. We talked about the planning and the non-coding aspects of the job. The AI stuff really helps mostly with the coding aspect, right? Does it help with getting requirements from stakeholders? Probably not. If 50% of the job is coding and you completely eliminate that [inaudible 34:59]

WILL: And the style, right?

MIKE: 100% productivity will increase in coding, right? Like, it all goes away. You only get to work on twice as many things --

WILL: Absolutely, absolutely. So, you know, honestly, like, I've been really having a tremendous amount of fun with it just because, like, generally speaking, I know what I want done, and I can express it in a reasonably concise, understandable way. I just might not know, like, all its syntax, you know. And so, like, that has just been, like, cleared from my past. It is an absolute delight, as far as I'm concerned, because a lot of the, like, I just [inaudible 35:37] BS ticki tack jobs are just, like, I have an assistant, you know, with a broom, you know what I mean? Like, I could build a house, and I have a helper handing me boards and, like, doing the sweep up for me. I'm like, ah, this is...yes, all day. I love it.

TAD: Yeah. I think that's a great place to kind of stop. So, thank you, everybody, for participating. Thank you for all of your comments.