Episode 16 | The Automagical Future of Software Engineering

Eiso: [00:00:00] Welcome to Developing Leadership. The podcast where I Eiso Kant and my co-host Jason Warner share our thoughts and lessons learned on engineering leadership through the years.

In today's episode, step into our time machine, as we look forward and try to guess what the state of software engineering will look like in 20 years, how will autonomous coding evolve what kind of software will we be building? What will software engineering leaders face in two decades as engineering organizations continue to grow? Are self-driving cars are really just around the corner? And as always, this episode comes with a accompanying show notes, featuring our favorite moments from the chat and a deep dive into today's topics. Find them at developingleadership.co or linked in the description.

Hi everyone, Jason and I are back with another, episode of developing leadership. We have a great topic in store for you today, which is our ramblings on what does the future of software engineering and engineering leadership look like [00:01:00] if we got to imagine 20 to 30 years from now. 

So Jason, I'll let you kick it off today. I know both you and I have a ton of ideas on this topic. Why don't you give us a starting point?

Jason: Well, this is gonna be a fun one. So what do we think it might look like in 20 or 30 years? And then that's sufficiently far out where it's almost nothing we say it's gonna be accurate, but hopefully directionally correct to some degree. And there's a whole different type of areas that we could explore. Who is doing it, how they're doing it, where they're doing it, all of those sorts of things. 

But the first thing I will jump into and say is, I, I greatly suspect that, you know, a lot of what we're building in today and how we build it, just won't even look like at all, what we're doing in the world. Think back 30 years from what, how we were doing things today to back then. Language types might be kinda similar, but the concepts of what we're building are so far different. I think that'll obviously hold.

 I do think given that, you know, I [00:02:00] was at Github for a years trying to build the future of software. I thought about this quite a bit. I feel like the, the closest thing that we currently have in the world to where we'll start to see some of that glimpses for 30 years from now is the last thing I released at GitHub, which is Co-pilot. Which I think is gonna take multiple years to find, to build out and to get right. And when I say multiple years, I'm, I'm thinking closer to 10 than it is to, to one. You know, it'll get better, it'll get smarter, it's already quite good. 

But then once it gets really smart and really good, it'll get scary good. Then we'll adapt other tools around it and it'll become commonplace. And I think that we'll have more AI based software development in the future. We'll have more predictive ways that we can build things that will lead to like, you know, DSLs that can expand out or simple constructs that sit on top of a lot of these tools, et cetera, et cetera, that sort of thing. That's probably the first place I think that we'll see like true, true, true, true software advancing.

Eiso: So it's interesting [00:03:00] you say this, I spent five years of my life focused on, on building a startup in this space. I remember us coining the term ML on code and, and we started getting early glimpses of that future years ago. And I think you're absolutely right that we're probably a decade away of getting to the part where we get, wow, this is truly changing the way that we, that we interface with what we're building, it's already, I think co-pilot is a fantastic example of a glimpse into what that could look like.

One of the things that I, I keep coming back is that almost everything today that we have and, and innovations have come, they've come just incremental steps. And we can even, if we look back at, you know, if we look at the hardware space or, or the devices we use, there have been several key moments, right? The introduction of, of the iPhone, the final intro like wave of machine learning that, that really became useful.

But after those kind of moments of like excitement, you could probably say the same about, about crypto [00:04:00] today. Then it just becomes incremental building step by step. And, and we usually underestimate what that compounding effect looks like, you know, 20 years from now.

Jason: I, I entirely agree. In fact think it's also a function of how businesses approach these things, which is, "Hey, let me see the minimum viable thing out of this," and they'll try to monetize it. And that leads to kind of rounding down. We've had this conversation about Copilot on this podcast, which was, "we showed a proof of concept to something. And the first question was, when can we monetize this?" Like, hold up. It would be better if we spent more time developing this before we tried to market this, but it's the nature of the beast. 

But I still think that it's directionally correct. And I think close to 10 years, it'll become commonplace. Co-pilot, won't be the only one. It might not even be the best one. It might not even be one of the better ones because we'll have advances, we'll have new techniques and styles and things of that nature and it will happen. It definitely will happen. 

But I still think [00:05:00] 100%, like I don't, I'm not a believer in self-driving cars. Like, I'll just say that out here on this podcast, I'm one of those people that says the closer you get to full self-driving level five, the harder the gains are going to be. We all know that from engineering in general, you know, full self driving, step one, pretty easy that's GitHub Co-pilot today. Full self-driving step two, actually pretty easy as well, take a couple of years, but you get there. But the moment you get to three, four, and five, you're like slugging it out to get percentage gain in here.

And, you know, to get full self-driving level five, where you have full authority and autonomy of these cars, and there's no steering wheel in it, blah, blah, blah, all that sort of stuff. I don't know if we're gonna see that in my lifetime to the degree where I would actually feel comfortable with it. If we do great, but it's not going to be around the corner no matter what Elon says, we're talking 20 years still to get this, to that point.

That's what GitHub copilot could possibly achieve for us, autonomous coding, could be. But it we're decades away from that. What we'll get closer to it and it'll look smarter and smarter and smarter like that over time. 

I also think [00:06:00] that we're gonna change how we think of software engineering. I think software engineering today is pretty, pretty nascent. We don't have the same sort of visibility into pipelines. We don't have the same sort of visibility into flow, in productivity, into output, into inputs as any, almost any other organization in the company, let alone discipline.

And we call it software engineering and it should be more like software art because it's not like we're, we're that disciplined in how we approach these things. I think we'll get more software engineering built into the systems and we'll see more of those things pop out and more people will have kinda rigorous views. I don't think we'll ever get away from the software art side of it though, because I think that's where a lot of the early value is created. But then once we have that, the value created, we can have the discipline to scale it.

Eiso: I wanna take a step back here because we're talking about 20 to 30 years from now, right? And what you're saying is, you know, we might get to some form of closer to autonomous coding, several decades out. [00:07:00] What do you believe? And I'll share my thoughts afterwards as well. Are the consequences of these things happening when we're gonna look back in 20 years from now and say, "Wow, what are the big jumps that we made in terms of who's creating software? And how does that look like at all?"

Jason: I think we'll have more people creating software for sure. Think of more people around the world. More people have access to it. If I were to project forward right now, I think software engineers are high prestige, but maybe high prestige is the wrong word, but they're high paying they're, they're compensated extraordinarily well. And I think that's kind of equivalent to what I would say when I was growing up where maybe like lawyers, dentists and doctors. Which were, I remember growing up and I didn't grow up well off in my town. If you were a lawyer, dentist and doctor, you were thought of as the richest person in town, maybe the most well off most well educated, whatever.

If you look today and think about what lawyers, dentists and doctors are, they're squarely upper middle class, or maybe lower, whatever. I don't know what [00:08:00] the class structures around the world, how they think about these things, but it's not what it was 20 or 30 years ago where they were thought of in this high prestige high, whatever. It's more thought of as "okay, you're a doctor that's great, you're helping the community." Or, "oh, you're a dentist, that's great, you must have a really good lifestyle", but it's very different in that way.

 Software engineers almost always make more than any one of those, except for maybe Wall Street level lawyers who charge a thousand dollars an hour or something. But the average software engineer is probably making more than the average doctor in the United States, Canada and Australia, almost guaranteed. I don't think that that holds, I think software engineers still make that much, but I think it's, it's more conceptually conceived to be kind of in that where doctors', lawyers, dentists are today than it was 20 or 30 years ago.

And I think more than what happens is entrepreneurs and founders and stuff they're gonna become the high prestige ones, which I have thoughts on and maybe qualms about. But that's where I think it'll push people who are starting and then pulling in engineers and pulling [00:09:00] in product folks and designers and things of that nature. But that's kind of what I can see happening. I don't know sure it's gonna... I think a lot of people would disagree with me, and think it goes the other way, but I think the more people that come in, that's just what what's gonna happen.

Eiso: I have a slightly different viewpoint here. At least maybe one that we end up converging and agreeing on. There is obviously a function of, of salary and price and compensation. That's just a, a mismatch of demand and supply, right? The fact that if we, I, I still remember this when I started coding it, it was a, a very niche thing that maybe around the world, less than I believe a million people were doing. And today, if you look at, you know, I think it's, GitHub's user base is over 70 million users today. And I still remember five, six years ago that, that number was at, at, around the 20 million. As we're starting to balance out that demand and supply I absolutely agree that there will be, let's call it a normalization of the role in probably 20 years out, any mismatch in demand and supply for any function would balance out.

But I do think we're gonna see [00:10:00] this separation between the engineers that are building the foundation to build software. The tooling that actually builds the software that are likely, still gonna be massively paid, versus the engineers that, and maybe we won't even be calling the majority of them software engineers anymore. The people who are going to be building really the end user experience.

And I think that's where we're gonna see just like so many more variations and gradients of what it means to be a software engineer. And I think today we have like early glimpses of that in with like low code or engineers that are maybe primarily doing, you know, headless CMS implementations. It's a very, very different type software engineering, not saying better or worse but definitely more specialized when you're, you're building, you know, the, the cloud products or the developer tools that are enabling those things to happen.

Jason: I agree entirely with that nuance perspective inside the topic, which is, and we know this about any industry, the best of the best will [00:11:00] always get paid. And I don't mean best in terms of like their abilities, but when you're dealing with like the hardest of hard problems, the it's a narrower, narrower set of people that can possibly work on them. That's just a, it's a, it's a kinda like scientific statement of, of fact.

And I think that will happen in the future. I think the aperture gets widened, but also it gets harder. So what I mean by that right now is actually, it's, it's harder to be an infrastructure I'm using air quotes for as a podcast, but air quotes, infrastructure engineer these days than it was 10 years ago than it was 20 years ago, because the size of infrastructure has grown so large.

So, you know, I'm a distributed systems engineer. I fell into it. I, I happened to be good at it. I also happened to be the most sought after engineering discipline in the modern world today 'cause that's where our systems went through to distributed scalable systems. But when I was starting out, it was literally, could you scale, you know, CGI-bin, could you scale Java? Could you scale that sort of stuff?

 It wasn't that [00:12:00] difficult to go do. It was more about how you threaded applications or sent messages back and forth to each other, or maybe like how you optimized databases and partitioned and charted them and all that sort of stuff. Now it's exploded into the point where you're talking about like specialized data systems for each sector of your application, you know, reads and writes and materialized views and streams and Caches. And then you got the stores and then you've got the partitions on the stores themselves.

And you get, you get what I'm going for here. Anybody who works at that layer I think is, is one will be thought of, yes, I agree with what your saying Eiso. So they're going to have be sought after because that is where the, the most value is gonna be created because up all the value gets upstreamed from that in terms of the ease of use. So imagine if you just take Copilot as an example, fast forward 30 years from now and autonomous coding is a thing so everyone could write code.

Well, it's not it... The people who are using Copilot are [00:13:00] creating immense value are, are using autonomous coding tools are creating immense value. And I'm sure they're well compensated for what they do in that way, but the people who could write and create and maintain the autonomous coding systems, that is a completely different level of care that they're going to be, and they're gonna be compensated and s- and thought of very differently in that way.

Eiso: I wanna come back to an earlier point that you made, which is today software engineering is an art. I think it's always anyone who writes code, gonna feel like an art. I think that's the passion that we all share. But we are moving more and more into a world where due to the importance of software engineering, it needs to become more of an engineering discipline. 

Talk to me a little bit about how you imagine an engineering leader, running a software engineering org in 20 years from now. What's accessible to them. What are they looking at out? What do the teams have available to them? And, and how is it more of a discipline then than it is today?

Jason: Well, so this is where I feel like this, the sci-fi space [00:14:00] age stuff that we talk about. If it comes to fruition, it's gonna be magical, if it doesn't, we're just gonna be working in these massively fragmented systems that are hard to manage harder and harder we're building like weaker and weaker abstractions on top of them that have more and more bubble gum bandaids and bailing wire.

I've always thought that the best conceptual internal engineering system that I ever heard of was probably Google followed by what Facebook I, I conceptually know about what Facebook does internally. I know Google's more so I'll speak to that one a little bit more. But how I think about a lot of the engineering disciplines of the world is that things just the right thing just happens for you. That's what I basically have been building my entire career with Canonical, Ubuntu, Heroku, GitHub, I was trying to bring the magic of what Google did. 

What I thought Google did I never actually worked there, to engineers around the world, which were, "Hey, if it needs to scale, we can do the automatic scaling for you. It needs to scale it down 'cause you're seeing less traffic we could [00:15:00] do that too." If it needs to horizontally scale, vertically scale, if it needs to change your networking structures, if it needs to auto deploy, if it needs to redeploy, if it needs to roll back. All of those sorts of things, the systems themselves, could conceptually do these things automatically for you.

We are so far from that world, even with what we've built in the last five years. And I know Google doesn't actually fully operate this way, but that's conceptually what I was trying to build. But we're so far from that, that just that statement alone if we got to there in 20 or 30 years, I think would be a magical way of course to get to. 

On the flip side, running the organization, man, I, I don't think we're anywhere close to this, but I, this is what I would, I would hope you would see is that an engineering leader wakes up every day. They understand how, how the systems are running automatically. They understand what had happened overnight, where all the distributed system or all the distributed engineers by distributed I mean, they're all around the world, working on things. They all have tasks that they can work on autonomously. They know what they need [00:16:00] to work on today. What are the highest level of priorities? All the business metrics that come in, are well understood from a business prioritization perspective, they automatically can see how their teams are doing towards those systems. They know where they have to spend their energy. 

30 years from now if an engineering leader can wake up every day and have a their calendar triage saying, "I've canceled your one-on-one with Susan because her project is going well. And she has no no need of the conversation today, but I've prioritized a conversation with Johnny because that project is behind schedule and red. And Johnny has a, an issue he needs to talk about." I don't know, I made something up, but you can get conceptually what I'm trying for here. Right now we have too many of these triage moments in our brains, where we have to figure out on a daily, weekly, monthly, quarterly basis where to spend our time and energy. Frankly, that's why if I were still in the CTO seat, that's why I'd be paid so much is because it's not a very easy job to go do. We should be able to automate me away.

Eiso: Okay. So I'd love for you to [00:17:00] dig even further into this because I think this doesn't just hold true for engineering, this holds true for a lot of managerial roles. Why do you think in engineering, we're gonna be able to automate, or at least augment you to an extent that makes you just significantly more efficient and also just what makes you probably enjoy your time more and become more effective?

Jason: You know, it's, it's hard for me to fully describe it, but why I think we're gonna be able to is because it's worth it to go do that. Because one, we don't, we, you know, we've had a couple podcasts in the past where we talk about how many high level leaders there are in the industry and the lack of them and how it's difficult to find these people. Now, what will happen is we'll round down and we'll start to promote people who don't have those same skillsets. That requires that we automate some of these things, but it's worth it because the incremental gain you get from a mid-level leader to a world class leader, it's a, it's a massive difference.

And I'll go back to sports analogies that they always do. A replacement [00:18:00] level quarterback in the NFL versus the hall of fame quarterback of the same years and vintages, their abilities and their ability to impact wins and losses are so astronomically different. That if you could trade your entire team, almost theoretically for a hall of fame in their prime quarterback to, to replace your replacement level quarterback, you would.

And that is literally what we're talking about. Differences between a replacement level engineering product leader to a world class leader. So it's worth it for us to figure out what those things, what they do differently and how they do them differently and try to automate some of those things, to bring them to some people, to some people, to augment them. Basically to give the average person, an engineering leadership Ironman suit, to where they can augment their abilities to a degree.

Do I think we're actually going to achieve it? I think we'll will make, we will make people average people better when they're gonna make a world class. I just don't think it's possible to go do those things because you can't fully abstract away judgment and taste, but we're gonna [00:19:00] make the average better. We'll make the below average to average the average above average, but there will always be exceptional people.

Eiso: Let me take a second here to, to paint a picture of, of the 20 to 30 years from now that, that we've started describing. In 20 to 30 years from now an engineering leader wakes up and is able to get visibility into what happened in the last 24 hours. How are we tracking towards the main things that we care about? And you said something as a business. And I think that's really important, not just like that we release or that we ship it out, the, the impact of engineering on the business and a calendar that, that is populated with almost automatically or automagically where they should be spending their time throughout the day.

The engineers in that organization are, let's say writing code, but writing code at this point is probably highly augmented with really more time spent thinking than actually writing the code. One of the things that I personally always look at, at the space of, of autonomous coding, because I've spent so many [00:20:00] years trying to tackle that problem is that it doesn't abstract away the engineer, because what you see in most great software engineers is that the thinking that's important to writing the code is almost the, the subsequent thing you do after you've solved the problem in your head, or if you've after you've thought about the architecture.

And so they're, they're writing code with some form of assistant or autonomous way of doing so. And this is where hopefully at this point, getting it reviewed, sharing it, getting it into production is really just a click away. One second click to get it in prod, one second click to get it back, maybe even automatically in case there is. And the entire abstraction of scaling up, scaling down the issues that come from that, the rollbacks, the deployment processes the length and time that we wait for, for tests is, is hidden in the background. 

Now, living in that future, it still sounds a lot like today, just a little bit better. What are some of the [00:21:00] things that the future could look like in your opinion, that absolutely shatter our future image that we have today and the things that we might be not thinking about at all? Like how could software engineering look radically different if I'm asking you to probably be wrong in what you're saying?

Jason: Well, I think what you could literally do in the future, I, I don't know if this is satisfies your curiosity on this one, but we've seen it with some of the GPL stuff where it's like, "give me an app that does this for this customer." And it creates an entire code base for you. Spins it up. It does the right thing, all that sort of stuff. It would be the, the height of experimentation. I wanna see in a day with a marketing campaign, if I could, you know, pull up a really simple application just by speaking something into the computer, you know, "Hey, computer build me an app that serves the travel market for niche audiences, traveling to Puerto Rico, et cetera, et cetera." And it does all of the things.[00:22:00] 

Or you do almost like a Cartesian product where you say, "Hey, Google, plus a travel app, plus a thing." And it pulls together all of that stuff for you. Like that's a at the app creation level. And you know, that's conceptually interesting. It's probably not even radical enough. I would assume if we're talking 30 years from now, I guess like part of the problem is that I've lived through 30 years of software development and it's not that radical. It's actually kind of, kind of, it, it, we don't have flying cars. If it was the 50s and we're projecting forward to the 80s, the 1950s and 1980s, we always said, "Hey, we're gonna have flying cars."

But once you live through that, you realize how mundane the 30 years actually are. So I, to not be encumbered by that, trying to write the I'm gonna be wrong. And I'm gonna say this flying cars type of thing here. I don't know, maybe harvesting like geothermal energy and all of our data centers are underground somewhere and the ocean dropped down and we figured out how the fact that these things are net positive to the environment, and we're [00:23:00] trying to run more workloads in them.

And we're building more computationally intensive types of things because that's, that's good for the world type of deals. Like almost, it's like a 180 from where we are right today when we're trying to optimize, you know, that'd be kinda fascinating. Maybe we're putting more stuff off world we're using like the net, the, the internet is completely off world startling style, but like, it's up there trying to go around instead of coming down to fiber optics down here and all that sort of stuff.

Software development in general, I would hope that at some point we basically remove all of the steps from between the, the, your fingers touching the keyboard and the code going to production. We got bills, we got packages, we got releases, we got manifests, we got pins, we got all that sort of stuff. We're adding more steps every time we do this, we're adding more of those things.

Well, 30 years from now, if we could actually remove all of those. So it's, every time you touch a key on the keyboard, it basically is affecting production in a safe and obviously secure and fascinating way that would be radical. And that would be [00:24:00] conceptually, like almost don't think we're gonna be able get there, but like, that's where I, I think we could possibly go. And then you take away the keyboard entirely too. And then it allows everyone to basically be a software engineer.

Eiso: We're back to when we wrote code and it automatically synced to our FTP server and was working online.

Jason: I, you know, as silly as it sounds, I think a lot of us who build things for, for engineers around the world are actually just trying to capture that first magical moment that we experienced something in software. 

Mine was, remember, I remember getting push Heroku master. That was one of those magical moments. I remember the very first time I got a a program to work and it, it was a graphical game. You know, you get into display on screen. You're like, "oh my God." And then PHP. PHP, like had one of those magical experiences, like a lot of engineers, likebag on PHP and stuff. Honestly, PHP was one of the better experiences for a long, long time.

Eiso: That was my first magical experience as well. I, I was first taught assembly as a kid, very random language to start in and I got to jump from assembly to PHP directly. And I [00:25:00] just still to this day, just remember the fact that like you save it and you see it on your screen. Like it it's absolutely. And I think a lot of us, like you said, are getting back to wanting to get back to that. 

So you, you said something I thought was very interesting. It's like, "Hey, I've lived through 30 years and actually the, the incremental parts are quite mundane." The question I have for you were those 30 years, linear improvements, super linear, exponential. In the realm of, of software development.

Jason: You know, I think so in those 30 years we've lived through movements as well as improvements. And I think most of the improvements came from the movements. So like the open source movement I think led to a lot of the improvements. I think if, if we didn't have those, I don't think that we would've had nearly as much improvement. 

That said when we brought some of those improvements, we also brought complexity because with the movements, people had religion inside some of the [00:26:00] movements, therefore they had fragmentation like, well, that's what happens in religion is that you have, you have disagreements, so you have splinters and you have fragmentation. So there wasn't as much cohesion.

 I, I think that it, it doesn't look linear. It, it looks like kind of step functions where you go up, then you go down, back and forth up, you know, it's, it's jagged saw toothed more than anything. I think it's, it's obviously been net positive in 30 years. But if you think about the distance travel versus the, the slope gained, if they're nowhere near analogous. 

We should have gone much further, except that we went, kept going up and then coming down and then going up and then coming down again.

And like a good example of this is just spend time on developer infrastructure, open source Twitter, and see how many times we rehash the exact same arguments every couple of years. There's one right now. I'm not sure when we'll publish this, but a maintainer of two very popular JavaScript libraries just basically burned them to the ground in protest, quote, unquote, protest of something that was going on. But if you [00:27:00] dig in, you realize the, the story is a lot deeper, but that's not the point. The point is like the conversation that's happening around this moment in time is the exact same one we've been having for the last 15 years in open source about whether or not, you know, you should get, you should have an expectation of compensation or not, or like how you approach it or what's sustainable, blah, blah, blah. And we've not solved this problem. We just kind of like, "Yeah, that's really hard let's just keep going and making leftpad over and over again."

Eiso: I have a, a hypothesis and I have to admit, this is one that that's really come up on this spot and I probably am wrong. Or maybe if I think about it later after this episode, I'll, I'll change my point of view, but we really are living through the first 30 years of professional software creation, right? Maybe a little bit longer than that. And a lot of us don't spend more than two generations. And I'm pretty sure if we had Amjad from Replit on this podcast today, who would Replit it kind of [00:28:00] spans the third generation in, in their user base, right?

 The next 12, 13, 14 year olds who are writing code. We might be even getting far more out there ideas because we are like the systems we build. Living legacy, right? Even, even I can say. And I think you, you and I have, you know, almost a gen- a small generational distance between us. We're still talking about the same legacy things, right? The world that we're coming from, our introduction with PHP, we're getting back to the, the open source movement and, and the same gripes that are coming back. But I wonder today, if an engineer who's, you know, 12 years old who is now writing their first program on Replit and is running it has a completely different point of view on the future and is probably gonna shape the future far more than you and I might, that doesn't actually deal with that legacy.

Jason: I agree with you entirely. I think their views are gonna be very interesting because they're not bound by legacy and they're not bound by some of the, that didn't work in the past. [00:29:00] And I think that their enthusiasm is warranted. And you want to kinda capture that. And I think it would be interesting to get Amjad on because his views are so out there in some ways. And I agree with all, by the way, I just think that his are, are really ambitious and I quite like them.

But a good example that we're seeing that in right now is the crypto world. And there is a lot of people in the crypto world. People don't know this on the podcast and people, my infra people are gonna be annoyed with me when I say this, I'm actually a believer in crypto. I believe that it will bring some, some changes to the financial systems. But it's hard to say that because people get, say, "Oh, you're against, or you're for Bitcoin."

Like, no, that what I'm saying is there is stuff in crypto that's amazing that we should learn from and build in the future. However, what happens is that people in both camps pro and anti crypto at the moment are having a conversation that looks like this. The pro camp is saying the future financial system, freedoms, religious movement, it looks a lot like the open [00:30:00] source world of the past.

The older camp is basically saying X, Y, and Z can't be done because you're missing these points. The people in the pro crypto camp don't even know that those problems exist. They have never encountered a world where those problems exist. And the anti crypto camp is actually 100% th- well, 1,000, 1,000,000% correct that those problems exist. And the pro crypto camp is not gonna find them until they find them. And then they're gonna have to figure them out if it's a ever going to be a thing.

And so you hear, you see these conversations happening, they're talking past each other essentially. And that's why I think like the younger generation talking about future would be amazing to see in this regard is just, you, you gotta find some sort of common common language in the middle of it.

Eiso: Essentially, we're, we're getting too old to be able to properly imagine the future. 

That being said what you mentioned related to the crypto space is I think another thing that we will [00:31:00] continue to see over the next 20, 30 years, and it relates to movements. I usually don't talk about my tweets, but I actually tweeted a couple of days ago. I started in what we call digital currencies in 2009.

 And back then I spent hours and hours trying to convince people that money was just a trust agreement and all the future potential that it could have if we were able to create, you know, additional currencies that were programmable. And I remember being at like the meetups,they weren't even called meetups at the time, where, where all the crazy out there people were, were sharing some of those ideas of what the future could look like.

And funny enough, most of those ideas are the same ones today that we are now further on is it 13 years later in what we call a crypto space. But the one thing that does provide me with a lot of hope, and I think this is what you relate to movements, is that even though we haven't solved the vast majority of the problems, even some that have been identified by the let's call it the anti camp or, or even people back over [00:32:00] a decade ago, we have gotten to a, a place in the world where we've managed to make enough people enthusiastic about wanting to solve those problems.

And I think it's the same thing that we've seen with electric vehicles or with, you know, space travel and, and credit there to, to Ellen Musk, independent what you think of, of how he's built his businesses. It's inspired big chunks of generat- of a new generation and, and even some of the older ones to actually want to tackle these problems. And if there's one thing, I have a lot of confidence in, in just humanity, but I think this holds true in, in software engineering in particular is if you give us hard problems and you put enough people on enthusiasm of solving them, we will incrementally solve them over time.

And that's why actually probably I'm more bullish than you are on the, on the level five, let's say, autonomous driving, just because I believe there are enough people out there who, who have been inspired to continue to work on it. And I, and I think we'll get much further in 20, 30 years than, than we might be able to imagine today. I think it's that [00:33:00] a famous Allen K. quote that goes something along the lines of, we always underestimate what's gonna happen in, in three years or overestimate, but we underestimate where we're gonna be 10.

Jason: Interesting that I use crypto and full self-driving as one of my conversations with folks a lot when I talk about approaching the world. And, and why I do is because full self-driving is one of those that I love to talk about because crypto gets into the movement religious camp, so you, you can divorce yourself from it. Unfortunately, full self-driving is also a little bit into the Elon camp at the moment. It's like people who are anti or pro can get religious about that. But what I like to say is full self-driving encompasses pure engineering, as well as belief as well as will.

And it's interesting because my view on full self-driving is that we're not, we're not gonna get what I consider to be full self-driving level five, which is autonomous driving in every scenario where a human can be replaced, but we're gonna get close enough that it's, we're, we're, we're gonna be [00:34:00] practically speaking and saying that it is that, but it's a theoretical versus the practical.

So I said, theoretically, I don't think we're ever gonna get full self-driving level five with a theoretically. Practically speaking we are. And that is the biggest Delta difference. And this is actually what I try to coach younger people and earlier engineering managers in about their language. It's you have to be precise in one way and flexible in another. And the precision allows you to say like, "Hey, theoretically, correct, versus practically, correct."

Maybe this is a longer conversation too, but when, I remember having this conversation with someone at Microsoft and they were saying, "We're one year away from full self driving level five," and I said, "Theoretically or practically?" And you could see that they paused for a second because they were parsing in their head. "Oh, no, this is a trap." And and I actually said to them, I'm like, "No, that's not a trap. I'm trying to understand what you're saying. Are you saying theoretically, full self-driving level five? Or practically? Like in Redmond around this one little ecosystem, we could get into a car with no steering wheel and it could go." And then that moment [00:35:00] we're able to have a shared context conversation. And I think the future looks, future conversations are always similar to that in, in that same way.

Eiso: If we look at, you know, for software engineering, for space, that so loves their movements and, and their strong debates, do we today have a crypto or an FSD equivalent related to the way that we're building software? 

For instance, I'll, I'll give you examples. Like, I see radical things happening that get me really excited, like what CloudFlare is doing by bringing everything to the edge. Or like, there, there are things happening, but I don't feel that currently, and maybe- I feel pretty plugged in. There currently isn't a big movement. We had the agile movement, we had the open source movement. You could argue crypto is an engineering movement, but I would almost argue against it.

Jason: No, I don't, it's not.

 I think the closest we have is autonomous coding, Co-pilot type stuff. I think CloudFlare that you mentioned is basically just [00:36:00] moving something that currently exists to a different spot. So it's, it's not evolutionary incremental. Crypto is no, no matter what anyone in the crypto space wants the world to believe it's still incremental. It's, it's a large, it's bigger than normal incremental, but it is still incremental. And this goes to like the decentralization versus centralization topic too.

I don't think that we really have too many of those in the world right now. And I think that's, you know, cloud was one of those that we had, and mobile was not for, in my opinion. Mobile was an investor related, massive thing, but for the world in general, it was just where they consumed information, but it was the information that was important. That was about cloud and internet. 

So internet, cloud, and maybe autonomous coding right now, but that's, that's literally where I kind of think we've basically done for the last 30 years. So there needs to be something else that's coming. Maybe quantum, quantum computing might be it. You know, that might be the only thing, I'm not well versed into quantum computing, but that might be the one [00:37:00] area where we might see it next. I don't know enough about it though.

Eiso: I feel what's been interesting of today is, well, some of our thoughts might be a bit scattered. Where we're also touching upon areas where we start feeling out of our comfort zone. What a 12 year old's thinking? What's happening with quantum? Like there are parts where when we start talking about the future, we should probably just get some great guests on board and have them involved.

But I do think that what really stuck with me today is, is this notion of, you know, big movements that have fundamentally changed the way we've done things. The fact that we are expecting. And I think without a doubt, software engineering, to go from an art to an engineering discipline, even more over time, the massive explosion of people who are going to be building software, no matter if that's writing code or speaking to a system or drawing the design and having an MVP up and running. A future of autonomous coding that is now in the realm of, we can imagine it happening. I still [00:38:00] remember, five years ago, having the discussions with most people that thought was unimaginable. So we're getting into this nice space right now where we can start having some imagination, but I definitely feel we should go and bring a couple of other people on to share their thoughts with us. What do you think Jason?

Jason: Oh, I absolutely think that's a, would be a fun topic. Now that we said it too at the very end into quantum would be an awesome one and maybe some sort of like very futuristic AI person.

Eiso: Absolutely. I couldn't agree more.