Breaking Down Work

About this Episode

In this episode of the Acima Development Podcast, Mike and the team delve into the importance of breaking down projects into manageable iterations to avoid stagnation and inefficiency. Mike shares a story about a past experience with a developer who struggled to produce releasable code, which led to the realization that breaking projects into smaller milestones can significantly enhance workflow and productivity. This approach allows for continuous integration and deployment, preventing the team from getting stuck on incomplete tasks. Mike emphasizes that this skill of breaking down work is crucial yet often overlooked in engineering education.

Will adds to the discussion by highlighting the value of creating "jigs" or scaffolding in both woodworking and software development. He explains that in his experience, especially with mobile app development, creating temporary structures or mockups can facilitate progress even when back-end systems are not fully ready. This method allows for continuous progress and testing, making it easier to adapt and iterate on the final product. Will’s anecdote about using a reverse proxy to simulate API endpoints underlines the practicality and effectiveness of this approach.

The conversation wraps up with broader reflections on iterative development and its applications in various fields, including aerospace and automotive technology. The team discusses how companies like SpaceX have revolutionized their industries through iterative processes, emphasizing the importance of starting with a functional but imperfect product and continuously improving it. They conclude by stressing the necessity of having a clear roadmap and the willingness to "cheat" by using tools and frameworks to eliminate human error, thus ensuring consistent and reliable outcomes. The episode ends with the advice to always build a jig and embrace iterative development for better efficiency and success in engineering projects.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting again today. With me, I have Will, Ramses, and Eddy. I have a story I'm going to tell before I introduce the topic, and I think about this a lot. I was thinking about it this morning. I think I thought about it yesterday. I think about it probably at least monthly about..., and I've probably even shared it on the podcast before [laughs].

But several years ago, I worked with a developer who was assigned to a project. We had talked about it as a team. We were all really excited about it. We had this new idea. It was kind of a developer-driven initiative. They worked on a little bit here, a little bit there, and a [chuckles] little bit over there. And this kept on going for, like, a month, and we thought that, you know, in a month, you'd have some code out. And looked at it, and there was kind of a framework or something there but there was nothing that was releasable. There were just pieces here and there, and it really felt like it stalled.

Now, they'd been working on this day in and day out for weeks, but nothing had made it into production. And in a continuous integration, continuous deployment environment where you can get stuff out there piece by piece, that was unusual. And I thought, you know, what's going on here? And I consider this a failing on my side. And I thought about it, so what am I doing wrong here?

But I think there's some maturity in career experience here for this developer. They hadn't learned how to take a project and break it down into iterations. I worked with the team to do that. And I say I worked with the...we kind of talked about this idea, and the team jumped in, you know, and I was just a minor player. But as they became aware of that, it completely changed the workflow of the team I was working in, where everybody focused on, well, how do I break this up into milestones? And, on a large scale, like, having a big project, how to break it up into milestones, and then, a small scale, developers are breaking up.

I had one developer come onto the team who made it like a singular focus. They'd come from another company where they spent, like, months on something [laughs] before they released it, and now they spend, like, multiple pull requests a day. And it's like their life is totally changed, and they're completely happier [laughs] because they've completely changed their workflow. They really embraced this and became kind of an evangelist. And I've seen it; I've seen this just be so successful for people who do this. And even for teams that get good at breaking things up, versus people who just stall for weeks or months. I've seen other...and that's certainly not the only instance I've seen. I just saw that one change, and then that developer became successful.

I've seen other scenarios where somebody jumps into something, you know, a challenging problem, and they spin, and they spin, and they spin, and they get weeks in, and then farther in, and just never get anywhere [laughs]. And it's frustrating for the person who's doing it. And there's a few things that feel worse than being deep in a problem you just can't solve it. And you just feel like there's no light at the end of the tunnel. It's frustrating for everybody who's working around them. It's frustrating for everybody.

Like I said, I think about this over and over again because I feel like it's one of the big skills in engineering that nobody really teaches, and that's a problem. It's just breaking up work. How do you break up work? And that's our topic today is, you know, how do you break up work, and why?

WILL: The North Star, for me...I do kind of want to pull on this a little bit because I've done stuff that just doesn't work like this, right? I mean, like, most of the business development, product ticket stuff that we work with can be addressed in this way. And then, basically, it's just sort of, like, what can you get out into someone's hands? And I would say, like, I don't know how to translate...I don't know how to segue in this, right? But, like, get it out into people's hands, right? And the thing that I think tends to jam people up is, maybe it's just me, but I think other people as well, is, like, you got to be okay with sort of like, let's call it, like, call it actual construction, right, where we're woodworking, or something like that.

You have to be okay making a jig for something, right? You have to be okay making scaffolding for something, right? Where I'm going to build this entire structure, right? Entire structure. But it isn't actually ever going to go out. Like, I'm building it so that I can do the small steps. So, one of the things I'm working on, right, not at Acima, at another very large retailer, is that I work on a mobile app, right? And so, the thing about the mobile app is a lot of the time, we're front-running the back-end API stuff, right? And so, what I'll do is I will scaffold out all kinds of stuff. I'll go and I'll negotiate back and forth with the back-end team, and I'll say like, "Okay, okay. Well, what's the data going to look like?" And they'll say, like, "Okay, it's going to look like this," right?

So, we'll do a contract, right? Which is just a contract. It's just aspirational, right? This is pure vaporware. But I'll get the contract going, and then I'll start charging ahead, right? And I'll just be like, okay, mock data, you know what I mean? Promise that's going to result to this thing, right? And then, I use a tool. It's a reverse proxy. And I can use that to create, like, a fake API endpoint, right? Where it's like, if you go to this API, this URL, it's going to give you back [vocalization], right? It's going to give you just...it's going to serve up this static file, right?

And now, oh, okay, now I'm making, like, real API requests to fake API, right? And all this stuff is junk, right? It's junk. It'll never go live. But I can actually release the thing. It is real stuff. It might even really be on the server hidden behind, like, some feature flag wall, right? And so, it's out. It's in production. It exists. It's a real thing. But, also, no, it's not, right? It's walled off, and it requires, like, all this fake stuff. I'm like, hey, hey, you know what?

And I'll tell you, like, honestly, like, I have hit on a contract before, but I am much more likely to miss on something. And it's like, oh, well, I have to go to the pricing and availability service, so it's going to be here. And I have to make another call. This JSON's going to...and you know what? It's fine. It's fine. I will have to go back and rework, but parsing Jason is really not that hard. In the end of things, it's really not that hard to parse some JSON. And so, like, you know, and then you'll go back.

But, like, if I wanted to do it, like, the quote, unquote "right way," and get it a hundred percent, then I would have all of these sort of, like, blocking features, where I can't move until the feature's done. I can't move until this is done. I can't move until this is done. And I'm just like, eh, F it. Let's roll. And so, you just do it that way, right? And so, you're making assumptions, making trade-offs, debating stuff, and scaffolding, and, like, you know what I mean, going with prototypes. But you're always putting something out into the world. And that has been very, very, very successful. And it's allowed them to get things out at a pace that they ordinarily just...there's no way [laughs]. There's no way.

MIKE: Yeah, it's interesting you mentioned the woodworking. My dad spent most of his career as a professional woodworker. That is exactly what [laughs] they spent most of their time on was: building those jigs, building the tooling to actually do what you needed. I don't know how much time my dad spent building tools. He still...he makes tools. Like, he'll see a problem. He'll go and make a tool because that's how he thinks now [laughs].

About ten years ago, my brother-in-law was showing him some grips for a handgun. My dad's never been, like, a huge gun enthusiast, but he saw that as a problem. He got curious about it, and he went and built a jig and made grips. And it turns out they were better than most of the stuff on the market. And he ended up doing it as kind of a side project hobby that kind of made him a living for several years [laughter] because he took the time to make that jig. Like, I don't really even hear that word outside of that industry, you know, outside of woodworking, but that's the word they use. And it's not exactly a tool, right? It's like a template.

WILL: Yeah. Yeah. Like a template. So, for people who are not necessarily, like, wood butcher nerds...so, I'll give you an example, right? So, a guy I know he made this really beautiful grill table, right? And you could think of it like an outdoor kitchen table with this circular hole, and his grill goes in the middle. And you've got, like, your whole cook surface out there, and it's super, super cool. And I looked at it, right, and it's like, it's this beautiful table. His grill goes right on the side, and you could do all this stuff.

But, like, what he did is he had this beautiful three-foot circular hole for his grill to go on, right? One does not just cut a perfect three-foot circular hole. Like, one does not just walk into Mordor or cut a perfect circle [chuckles] in a butcher block countertop. And so, I was like, "Oh, what did you do," right? Well, he created this, like, not exactly, like, a router. The router was a part of it, but, like, it was this thing to hold the tabletop in place. And he had, like, a thing, and it had an arm that it swung out, and the router cut this perfect circle. But he built, like, a scaffolding machine so that he could cut this perfect circle because you couldn't possibly do that by hand precisely.

I might have dogged it and done it with like a, you know, done it with, like, a jigsaw and then just, like, put a little trim over it, like, a little metal, [laughter] like, a fat metal piece of trim, like, that big. And it's just like, ah, it's bad, but you can't see it, so who cares? So, that's what a jig is, you know what I mean? Like, it holds the work in place so that you can work on it effectively and precisely a lot of the time. Because if you just try and freehand it, you're screwed. That's why [inaudible 10:07] shop projects, you know what I mean? Like, when you did woodshop, if you did woodshop, they all look terrible because...

MIKE: [laughs] Right.

WILL: Because you tried to freehand it. You're just like, oh, well, let's just cut this. And I'm like, no, no, no, no [laughs]. You get something to hold it precisely so that you have a template, and you can do everything perfectly.

MIKE: No, that's exactly it. The professionals, it's not that they're better at freehanding it, although they might be, is they don't trust themselves to freehand it.

WILL: Exactly.

MIKE: And so, they don't [laughs]. They build a system so that they eliminate the human mistake. That completely changes it, and that's how you end up with a quality piece of work. It's such a perfect analogy. You take the time to build the jig, you know, to build the scaffolding, to build the framework that allows you to test and deploy independently a component without necessarily having the other pieces in place. And without that, though, you're blocked, right? Because there's always going to be some other thing that you're working with.

What we do [chuckles] is we read data from one place, and we transform it, and we write it somewhere else. That's what we do for a living. If your data sources aren't ready yet, then you're blocked, unless you define a contract and you code to that. And then you say...you have some sort of test harness that you can test against that contract, knowing what they have may not be ready yet. And you might even have the wrong contract. You might have to make some changes later, but at least you'll have something that you can make tweaks to rather than having to start from scratch.

WILL: I think it's a good rule of thumb. I think it's a good rubric. Although I have been involved in projects where, like, you know what I mean, things were...you had to do...actually, you know what, honestly, I think I've always done that. I haven't always had the latitude to, like, front-run as much as I wanted to. Like, one of the things that I did, like, way back in the day, is I did a bunch of audio processing stuff, right, for phones and stuff like that back when, like, you know, the world was new on the iPhone. And I would do audio processing.

And the thing about audio processing is audio processing, like, there's not a lot of, like, intermediate steps. You really got to, like, you got to kind of, like, do the whole thing. You know, like, you have to have, like, the machine has to, like, do finished products. But, like, honestly, like, I still did the same thing. I mean, in that I would just make it play a song. I was like, oh, I can't play a song, right? Because, like, okay, oh, you want to play a song, right? Well, I had to have all kinds of stuff.

I had to have, like, a wave decoder, and then a wave, you know what I mean, like, a wave consumer, and stuff like that. And so, I was like, oh, that's too hard. I'll just make a sine wave because I could do that in math. I could do that mathematically. That's a mathematical function, right? Then I don't have to have codecs or anything like that. And then, I did that. And I was like, oh, okay, I did that. Okay. And now, I'll do a wave. Okay. Now I'll do a wave, right? It's like, okay, now I'll do an MP3 into a wave into, like, the speaker. I was like, okay, now I did that.

Now, I will take the MP3 into a wave. I'll capture the audio and do nothing, right? Nothing, just a hand, just passing it through, right? And it'll go out. And then, I'll, you know, and then I'll just do, you know, something else, and then, you know what I mean? And so, I would, you know, just kind of do stuff like that.

MIKE: But the process, like, even if you're not releasing it, in order to be able to...and this ties into testing, it seems like, right? Like, you mentioned the testing. At every step, you're doing something that you could verify. You wanted something that was kind of tangible. And I know none of this is purely tangible, but it was...the closest you're going to get to tangible is something...like, it was making it into sound that was making it into your ears. There was something that you could measure that you could validate on. And once you have that, you could build around it.

WILL: Yeah. Yeah. And I built all kinds of jigs. One thing that I did is I was...so, we were working on, like, continuous DJ mixes, right? And so, it was a bunch of MP3s that were encoded and recorded, you know, in such a way so that there would be a continuous stream of music. So, it'd go play from track one to track two to track three to track four to track five. You would never hear a transition, right? You could do that. But I was transforming and manipulating the stuff, right?

And so, like, when it would go over, it would pop. It would be a hitch. And I was trying to debug that one particular thing. And I was like, ah, like, my ADD brain won't let me sit and wait for the thing to roll over. So, I was just like, okay, I'm going to make a jig so that I just jump in five seconds before it ends. And then, I'll play through the transition, and I'll go and do five seconds again, and then I'll, you know, and that's how that goes through the song.

So, I'm only doing, like, the specific part that I want to see because I don't have time for all that, you know? It's just jigs. Just that's a way of doing it, I guess. My dad always taught me...my dad was an engineer, not a woodworker, but he always said, "Go from the known to the unknown." You always want to be working from a known good state, you know what I mean? It can be as stupid as you want it to be.

MIKE: [laughs]

WILL: As dumb, as useless, like, I've looked at a lot of blinking, red lights, bright in my heart.

MIKE: [laughs]

WILL: Like joy. Like, where I'm just like, look at that. Let's blink it, baby. Yeah, we're blinking. We're blinking hard. And I'm just like, is that it? That's what you did today? It's like, yeah, baby. Look at it [laughter]. If you're a real engineer, you're just like, ooh, that's a good blink.

MIKE: [laughs]

WILL: What does that mean? What [laughs] does that mean? What does that light flashing on and off signify in your brain? You know, what is that? It represents progress towards some goal, you know? But, like, yeah, just that stupid, easily that stupid. All day [laughs].

MIKE: You mentioned a blinking light. You say it represented something, signified something, right? You've got that [inaudible 16:18]. You've got something that you can actually wrap your head around. You can verify there is blinking light. I have power [laughs], and it is making something happen.

WILL: We're blinking hard. We're blinking hard today, Mike [laughs].

MIKE: There is a project that was challenging to test because [laughter] there's a...and probably [laughs] anybody who's done this for very long, you probably have encountered this situation before. It's not unique. And you have a partner who doesn't have a sandbox, or they do, and it doesn't work very well. So, you try to test against this third party, and it just doesn't work right. Like, there's not a good ability to test against the API. And when we're running unit tests, we run into this all the time, and we just say "No," right? There's no way you're going to run your unit test suite against the third-party service. And if you do, you're suffering because [laughs], you know, it's so unreliable.

You can't have reliable tests that actually test something if you're running against an unreliable service. And they'll be, like, 100 times slower, and all the problems with that. You know, you build. You mock it out, right? You build a fake service so you can test against that, and that's what you work with. But sometimes we don't think to do that when we're doing manual testing. Like, well, my unit test does it [inaudible 17:39] manual test. I need to test against the real thing. You know, I want to do an integration test. It has to be perfect. Instead of building the tool to test against.

And, in this project, I regret, in retrospect, not pushing hard to say, "Build the test service. Build the test service. It's going to save you so much time." People spun their wheels for hours and hours trying to get stuff done, trying to share a staging environment to test against this sandbox on the service that was sometimes up and sometimes down. Or if they had just had a service running locally that maybe wasn't perfect but it was pretty close to the third party, they could have saved themselves a lot of grief.

WILL: Mm-hmm. Mm-hmm. Yeah. Yeah, absolutely. I mean, I will say that, like, a little...one of the things I've learned at Acima is the many blessings of the VCR gem. If anybody's listening who doesn't know about VCR, basically, all you do is you run your test suite against a, you know, a third-party, or external or, like, whatever, external API source, and you go out, and you hit the real API. And you save it.

And then, you're testing against the real call, but you don't have to, like, go out and do all that every single time, you know. And you could configure it in various ways so that, like, you refresh the stuff, or you make sure it doesn't get stale, and stuff like that. Because, like, yeah, I want the real, real, you know. I don't trust any of you people. You guys are all liars. Engineers cannot be trusted [chuckles].

MIKE: It does give you...you get exactly the response, the real thing. But then you can save it so you don't have to hit them again. So, you get your reliable test. And you can build a service that will respond with that data and run it in your test environments. You can do some manual testing and stuff through the process. Why not?

WILL: Like, I love my reverse proxy for mobile development, right? Mobile development against unstable APIs, shifting APIs, you know, like, I found something today, just today, and I just patched it. If every single thing failed on me, right, I'm hitting a bunch of endpoints, and I'm aggregating together, and, like, none of them should fail. And almost always, at least one of them would come back. But if every single endpoint that should never fail actually did fail, then it was taking down my whole...not my whole app, but my whole, like, page within the app.

I made a jig, right? And I made a jig because I was in a hurry. And I was just like, I'm just going to take this API call and I'm going to, like, I'm going to butcher it so it could never fail, right? So, it's just going to fail all over the place. I'd, like, dug into the source code, and I'm just like, and you will die. Promise dot reject abort, you know what I mean? And then, fixing the problem was really easy because I was sort of refreshing, refreshing, refreshing, but I couldn't get this intermittent failure to go. Unfortunately, I work for a very large retailer, and I will get those millions of requests in the wild, you know, very quickly, you know. And so, anyway, make a jig [laughs].

MIKE: I think Will hit on something critical, which is, you know, you build the support structure so that you can build these incremental pieces. One thing that we really haven't talked about is you get a project, and this happens at any scale, you know, whether it's something that takes two hours, something that takes two days, something that takes two months, something that takes two years. You've got this big thing, and you got to start somewhere. And I think that sometimes we want to see progress, so we just start somewhere, right [chuckles]? Let's chip away at something. And that's one way to do it.

And going back to our starting, where we started this podcast, you can chip away here and there. You end up with a lot of this and that, but the whole thing doesn't move forward. I think you need to be really methodical about choosing what you do first. And it goes back to that jig idea. You have to have some sort of framework, mental framework, to map out how you're going to do the work.

I'm thinking of another project that I worked on a few years ago. I had spent several weeks in meetings with product and business, and they were laying out these ideas. And mostly, what they had was mockups. It's like, this is what it's going to look like. But nowhere in there was anything about how it was actually going to work [chuckles]. And there were a lot of really big questions. You know, here's how it looks like in the user interface. But how on earth are you going to make this work behind the scenes? You know, go and work with whatever providers, and leave out the details. But, you know, you're going to need third-party data to make this work, and it's not trivial.

And after doing this, I got together with a skilled product manager, and we sat down for a few hours and hashed out a roadmap and said, "These are the milestones we need to hit." And that roadmap, more or less unchanged, ended up being how that project got done. It was on a really tight timeframe. We got it out in about three months, made it before Christmas, and you get the release. It wasn't the greatest product [laughs], but we got the thing done.

And the problem was actually not our implementation as much as that we were trying out a new business idea that wasn't as good as, you know, as they'd hoped. It happens. The important thing is we got it done. And the only reason we got it done, instead of spending the next two of those three months in endless meetings talking about the user interface, is that we sat down and said, "Well, what is the practical plan? What could we do first?"

And the thing that we could do first...and then, we went and actually talked to the business and said, "What do you need first?" "We need to be able to accept a credit card payment," or whatever it was. And having that first thing opened the gate to do another thing. It's like Will's blinking lights or being able to play a pure tone sine wave [vocalization] [chuckles].

You get that. You get something to play. You get something to start with. That zero to something is so much more than even the subsequent steps. Something to hang on is just wildly better [chuckles] than nothing. The zero to something is the biggest, hardest part. And getting that tangible sort of thing made a huge difference. And then, other people can start talking about, where do they fit in the process? You know, you can start coordinating across teams to figure out where they fit. And pretty soon, you have a project running. And you do that a lot.

I've worked many projects like this. I'm working on one right now, where the very first thing we did is we sat down, laid down the roadmap, and the project's going well. It's going to be...other than some challenges dealing with a government entity that's just sort of slow [laughs], like, we're going to be on time, close to on budget, you know, it's just going to work out because we've mapped it out like that.

You see, the difference is really not that much. You know, you take a few hours and grapple with the problem and think about how to break it up, rather than getting overwhelmed and just chipping at something and getting one little piece. You're probably never going to make it very far. Now, chipping one little piece is better than nothing, but I think...well, maybe [laughs]. But I think that taking some time to analyze the problem and it's work, and figure out what comes first, and then what comes next, and then what comes next...well, where are your most risky pieces? Maybe you have some government entity you have to get something approved by. Well, you better get that done first.

You know, laying out an order of operations and doing those is just, I think, one of the most valuable things that we do. And I don't think I was, you know, I don't know that it's something they teach in school. They just expect you to know it. But I feel like that's something that ought to be just repeated over and over and over again.

WILL: I couldn't possibly agree more. And I'll tell you, like, also, like, I mean, it's like, you know, sort of, like, in terms of, like, the tactical sort of, like, thrust and parry dealing with, like, business product, stakeholders, stuff like that. It is...how do I put it? Like, if you can distill a feature set down to, like, the absolute, absolute, absolute minimum, like, when you're faced with sort of, like, you know, a lot of demands, a lot of shifting demands, a lot of crazy deadlines, a lot of pushes, and stuff like that...And I understand that, like, what I'm saying here is just, like, plain vanilla, basic agile. But it's the kind of thing it's that's easy to say but very, very difficult to do.

But, like, the more you could distill it down to, like, just the basic core, raw functionality, and then, like, you add stuff on it, I found that when you get that sort of, like, that core workflow finished and you find yourself in a situation where it's like, hey, I'm not going to make this deadline, most product people, like, that I've dealt with, have been very practical, and pragmatic, and reasonable. If you give them something and you say like, "Listen, I can do this other stuff, right, but it's going to push it by a month. Do you want me to do that?" And then, they'll just be like, "No," like, they can make a purchase. They could buy a widget. They can do this thing that they want to do.

And, like, really distilling that down, finding the stuff, where it's like, oh, well, you know what? I'm not going to handle errors gracefully. Like, I'm just going to be, like, is it right? Cool. And then, you get the green check. Is it wrong? No. I'm bailing you out. I'm dumping the whole thing. I'm just dumping, right? No slickness, cleverness, anything. If you can give product scenarios like that, then I've found my ability to have an untroubled existence as an engineer while still maintaining a reputation for actually putting out products has, like, it's gotten so much better.

I don't know, I mean, they get it, but, like, when it's not done, when they don't have a done thing that they can either invest more in or they can ship right now, then, like, that's when the sort of, like, the wish list grows, and grows, and grows, and grows, and grows because it's not finished, right?

And this is real tactical stuff, but if it's done, and they have it, and they can either go to market, or they can delay. If you give them the choice, they almost always go to market. If you could give them something that works, they'll take it, but if you don't, then it's just like, oh, I got to have that. I got to have this. I have to have this feature. We couldn't possibly go without this feature because it's not something or nothing. It's nothing or another flavor of nothing, whatever. That's your problem, you know.

MIKE: That, what you just said, you know [laughs], if you've got nothing, like, you imagine any kinds of nothing, and what you have is nothing. But if you have something, something, right, you can work with that. And maybe it's not enough to go to market with, but it's at least something you can talk about.

Like you said, this goes back to the agile process. The core idea of agile software development is around communication loops. You want to have an iterative cycle rather than no cycle, you know, just planning upfront, build it, and then done. And you can only have that iterative loop if you actually have something to iterate on. And we've talked about this before a lot of times.

You look at aerospace [laughs] because it's big, and things blow up, and it's easy for us all to see. You look at what SpaceX has done to just absolutely dominate, not just, like, the U.S. market, but they launch more rockets than, like, the whole world put together. Like, the nation-state, right [laughs]? And it's because they have this very iterative process. You know, they're like, well, we're not going to build a perfect rocket. Let's build something that's maybe going to blow up, but at least it should be able to get off the ground, and we can measure some stuff on it. And they do that, and it probably blows up.

But they got those measurements, and then the next one gets a bit higher. And the willingness to let things blow up and to be interested in that interaction, right, in that iteration more than in the perfection, drives the costs wildly down.

WILL: I'm actually really interested in, like, so one of the other Elon projects that I'm personally extremely interested in is, like, the full self-driving mode on the Tesla. And one of the things that I'm very, very interested in, in that capacity, is willingness to...I hate to say, like, blow up some rockets, but, like, willingness to put out a full self-driving automobile that is just a little bit better than a human, right? Because, I mean, we're all right. We're not great, you know, we're all right, you know.

But I think if General Motors, you know, or one of the large institutional players was going out and putting together a self-driving car, or even somebody like Google that has a lot to lose, I think they would and do really struggle with, sort of, like, something that's just better and not perfect, right? Like, no, I don't want it to be worse. I don't want it to be worse. That's not cool, you know what I mean? Like, we can't have, like, flying, like, battering rams just barreling down the freeway murdering people. Like, that's not okay. However, what if it's just, like, 20% better than a human, 20% safer than a human? Isn't that better?

MIKE: That is better.

WILL: You know? Anyway, I mean, and so I think that that mindset, I think is, I don't know, I'm interested to see how it goes out. Because, like, it's also one of those sort of things where it's like, you know, you're kind of, like, gambling with somebody else's life there a little bit, Elon. And move fast and break things is not meant to be taken quite so literally.

MIKE: [laughs] That's an interesting one because to drive better than a human, you have to have superhuman skills, and let me explain what I mean. I'm going to have a very specific meaning that may not be what you're interpreting me to mean. And they call this the March of Nines. Have you heard this Match of Nines? If you want to have 90% accuracy, it takes a certain amount of work. And then, to get to 99% accuracy, you've only got one digit further, right? It's like ten times as much work. And to get one digit further, you know, 99.9, you got to do about ten times as much work, and so on.

And each one of those is harder, and part of the reason for this is that you think about driving, and most of the time, driving is pretty boring. Most of the time, driving is pretty boring until the nearby zoo has an error, and then a kangaroo ends up jumping across the road in front of you. And to deal with that situation, you have to have the concept...well, maybe it's not even a kangaroo, right? You know, maybe it's something that you've never even seen before. I almost hit a possum the other day, literally almost hit a possum on my bicycle. And [laughs] had to slam on my brakes, or I would have run over the possum [laughter]. That's not something that happens every day, right? You don't every day go riding along and almost hit a possum.

And I didn't necessarily need to recognize it was a possum, although it took me a moment before I realized what it was. You just have to know that there is something that is walking across the road, and I need to stop. But having that concept of an animal, and that it has direction, and knowing which way to steer because you can tell which direction it's going, and this is very much out of the norm, requires an understanding of a lot more than driving, right? You have to understand something about biology, and something about physics, and some other problems.

What if the street sign's broken, and there's a police officer standing in the middle of the intersection, and they're waving people with their hand, and doing hand signals to say which way to go? Now, your car needs to not just understand traffic lights. They need to understand human gestures. And maybe the police officer is just yelling at you, "Hey, please! Your turn. Go." Now, you have to understand human speech and have a microphone.

Like, as you deal with more and more of these situations, there are situations that require human understanding because our world of driving is built around humans. And I've actually heard this talked about by self-driving engineers. It's on my mind. These roads are not designed for the machines. And so, the problem is a challenging one and challenging in ways, like, it's hard to measure.

Now, this doesn't really go against what you were saying before. You may be able, like, because humans aren't that great at drivers, make the car 20% better, and then have, like, a data center somewhere where people are sitting there, and they'll take over. And they'll have a little camera and see, "Oh, the police officer is waving. Okay, make the car go left, you know, and take over manually." I mean, you might have something like that where you actually take human control or give it back to the human and say, "Hey, you know what? I'm not going to self-drive anymore. Your job." There are solutions like that where you just bail.

WILL: I mean, honestly, like, what I think ought to be done, I mean, like, I don't know. I mean, like, everybody's sort of, like, dumping money into this intention of, like, you know, like, carving out their, like, little digital fiefdom monopoly thing. And I don't think transportation is, like, the kind of thing that can really support that kind of a capitalist enterprise because it's public good, you know?

And so, I think it should be a public-private partnership, where we start creating roadways that have, you know, affordances built into them for self-driving cars. And, like, this is just me, but it goes right back to, like, what we've been talking about. What if your self-driving car was just good on the big streets? That's it. It's good on the big streets, you know what I mean? Like, get it to, like, a four-lane road, you know what I mean? Like, whatever your four-lane stoplight road is, you know what I mean? And you push a button, and you say, "Bang it out. I'm watching Netflix," you know what I mean? And that's it.

MIKE: [laughs]

WILL: That's cool. That's cool. We're good. We're good, man. This is a good gig. Like, I could watch Netflix. I could check my email. I can do my stuff. I don't have to sweat the traffic jams on the highway. I don't have to sweat stop-and-go traffic. I'm cool. We're all right. And more over than that, you know what I mean? I could do even better than that. And I could just say like, hey, you know what? I got my e-bike. Like, I'm just going to go to the city bus...and my city bus, instead of being the bus, you know what I mean?

So, I have to, like, pedal, you know, a block or two to, like, my transit point, throw my e-bike on there. And then, it just takes me right to my office, and we're good to go, you know what I mean? And cars have gone away. We didn't solve the hard part. I don't need to know what...like, my car doesn't know what a zebra is. It doesn't care, you know what I mean? Like, I just built, you know, I built the car to deal with, like, you know what I mean? I bounded the problem, right, so that the self-driving stuff works. And I made the roadway in a way so that the self-driving stuff can, like, process it and, like, we're all good. Any true engineer is always looking to cheat.

MIKE: [Chuckles] And that's been kind of the theme of the conversation, right? A good engineer as Will is interested in cheating. Don't freehand it.

WILL: Don't freehand it, yeah.

MIKE: Because that's a solvable problem [laughs]. But you can take away the human element, and then you have a different problem that's solvable.

WILL: Exactly. Yeah. My hand shakes just as much as yours does. That's why I made a jig, and that circle is flawless every time. I can make a thousand of them, and each one would be just as perfect as the last.

MIKE: Well, that feels like it kind of ties things up, doesn't it [laughs]?

WILL: I love it [laughs].

MIKE: We went from solving our everyday problems to dealing with the big problems of the world. And they have the same constraints. We will close this up. Thank you, all, for listening. And, you know, build a jig [laughs].

WILL: Build a jig.

MIKE: Build a jig.

WILL: Good engineers cheat. Build a jig [laughs].