A conversation with Patio11

To kick things off, episode host Jamie Cuffe (Head of New Products and Self-Serve at Retool) was joined by the one-and-only Patrick McKenzie (@patio11) for a discussion of software as leverage, the evolving state of ops, the future of programming, and much more.

Watch the video and read the interview below.

Text has been lightly trimmed and edited for clarity and readability.

Patrick, welcome to the Operator's Playbook. We're so excited to have you here.

Thanks very much for having me.

Of course. I can't imagine anyone better to kick off the series from bringing over 20K businesses and probably 10 times that number of jobs into existence with [Stripe] Atlas to helping our country get vaccinated with VaccinateCA. There's so much to discuss. So let's dive in. I wanted to start at the beginning, and I was wondering if you could tell me a little bit about how you first got into software and programming.

Sure. So if you go way, way back, the thing that got me into software was the thing that got many in my generation into software: the Nintendo Entertainment System. My family couldn't actually afford one. But there was one kid in the neighborhood who was lucky enough to have one back in the day, and I couldn't go over to his house every day. So I went to the library 'cause my mother had told me librarians know all things. And I asked the librarian, "how do I make computer games? 'cause I want to play computer games, and I can't afford a computer." And she said, "Ah, here's a book, how to make computer games." And the book taught the basic programming language problem. I didn't own a computer—however, the book did not explicitly say that you could do the basic programming language only if you had a computer.

And so attempting to make some sense out of it as a six year old, I was like, well, this looks like something I can do with a sufficient amount of graph paper. And so I taught myself basic programming by writing programs on graph paper, hand simulating them, which required learning what these x and y and algebra and whatnot looked like. And then there was a game which involved a helicopter and gravity, very basic physics engine for, you know, early 1990s teaching-an-amateur-to-program book. And so I was hand simulating frames of that with graph paper for the first few years of my programming career. Some years later, the situation changed, I actually got a computer, and immediately threw myself into programming for real. Have been doing that for, goodness, I guess 30 plus years now.

That's amazing. It's interesting to hear how, you know, you talk about getting into programming from something you're just excited about as a kid, and I feel like one thing that you've talked a lot about is choosing to work on ideas and communities that you wake up in the morning excited to serve. How has that guided your career journey? And is that something that you've always believed in, or something you sort of discovered along the way?

I think this is definitely one of the things that I've discovered by making all the mistakes in the world. So the brief version of the advice is that when you're trying to orient yourself around finding a new startup or deciding what to do from a next job rather than "oh, it seems like there is a market opportunity here, which is unsatisfied, and therefore, if I go in there, there will be less competition, I will make all the money in the world"... Realize that when you're committing to starting a new business, you are dedicating an expectation for the success case [for] at least five, 10 years of your life and career. [A] large portion of your waking hours. If you're doing a career, let's say, you probably get like, "pause-and-reevaluate" points along your career journey, every like, three to six years or so.

Three to six years doesn't seem like a lot of time when you're say, young and in your twenties, but you get a finite number of like three-to-six year windows in your life. I always tell people, plan a 45-year working career, and then, you know, you don't have to worry about spending a three-year window exploring, finding yourself, et cetera, et cetera. You start to have to worry when you do that like five or six times in a row anyhow. So the thing that I kept drawing back to after, you know, making the traditional decisions, like find the holes in the economy and fill them, was that the people I ended up serving, the communities I ended up embedded in, ended up determining my day-to-day happiness and my sort of ability to summon my best efforts to work, my ability to create value in the world, much more than the economic returns, the size of the opportunity, whether it looked good on paper, whether other people liked it, et cetera, et cetera.

And so you know, let me put it this way. I thought I loved teachers until I was supporting teachers' you know, day-to-day computer issues for about eight years in a row [...] And teachers are very important in the world, et cetera, et cetera. But you will have a different relationship with them after eight years of reading their questions about bingo card creation software. And you know, by the end of those eight years, I was very burned out on speaking to teachers about their issues. I have not found a level of speaking to software people which is, I think I'm stealing that word from Jeff Lawson. But engineers, entrepreneurs, et cetera, et cetera, the people who care deeply about how the machine works. I have not found a point at which I get tired of speaking to software people, at which I dread, like, waking up to the inbox, et cetera, et cetera. And this is after, goodness, almost 20 years in the game at this point. And so I'll probably be continuing to work on their behalf for most of the rest of my career.

That's amazing. Obviously, I feel very similarly. I feel like developers are one of the most fun groups of people to work for. So I wanted to actually hear, maybe—are there any particular teams or you know, individuals that come to mind when you're talking about, you know, working with those groups that really give you energy?

Well, let's see. I just came off of six years of the Stripe experience—and wave hi-de-ho, a number of the folks who currently work at Retool also had their own experiences along the way there. The exceptional caliber of people, combination of humble and very, very intellectual. You've probably heard it said on the internet, it is there, there's always a narrative about things, and the narrative is never exactly like history as it happened, but that narrative and history as it happened overlap more than narratives often do. The Atlas team that I worked on was one of the highest-caliber teams I've ever had the pleasure of working on in my career. Just a number of people most very early in their career, most sort of like new to the problem space of Atlas.

For those of you who don't know, [Atlas] helped companies incorporate in the state of Delaware from worldwide and sort of get their legal infrastructure up and running in the same way that like AWS would help get one's technical infrastructure up and running very, very quickly. And we—you know, dashed through all sorts of somewhat crazy problems there, had great fun doing it, and knock on wood made some difference for, I guess tens of thousands of entrepreneurs now.

Yeah. So maybe let's talk a little bit more about building Atlas and Stripe more broadly. I imagine there was a lot to build in the product but also a lot of operations software behind the scenes. And I'm curious in your mind, what is the difference between building SaaS versus building operational tools?

Sure. So one of the big overarching beliefs I have about the world, and it seems like every time I have a professional experience, it causes me to believe this even stronger... It's unfortunate that there's no good quick word that the entire world uses for "operations professionals," so I just have to say "operations professionals" a lot, but let's call them "ops." Ops is due for a major status upgrade both in the sense due for, and the sense of they deserve it. The world runs on ops. And also I say like, prediction of where the market will move—I think the market will move in this direction. If you look at historical examples— it is possible that many of you are at a point in your career where you don't realize that there was a point in history where the following was true.

The people who used to keep servers running were, back in the day, called sysadmins. And sysadmins were caricatured as a disgusting person, probably with a beard out to here, sitting in the basement. And they were, like, formally denied recognition as engineers. Back in the day engineers were not quite as valued by the market as they are currently. But even then there was like a massive caste system divide between people who would type into a computer to get the programs to do the things and people who would type in a computer to make the programs. And that was fundamentally irrational. Sysadmins had always been doing engineering work. They had been programming, scripting languages, et cetera, et cetera. And then a couple things happened.

Google most notably created the position of SRE, software reliability engineer, had a great deal of success, and scaling to serving the entire world using that model sort of popularized it, and this DevOps movement came up. And so people don't talk about sysadmins that much anymore. They talk about DevOps engineers. A DevOps engineer is a sysadmin—like flat out—but they earn much more money. They are listened to in companies. They have much more internal status, there's an actual career path for them, et cetera, et cetera, et cetera. And now you look at operations professionals—ops—they are low status in almost every industry you can think of. They're caricatured as the back office in finance where all the important people live in the front office and generate revenue et cetera, et cetera.

They are... I read an arresting line in "Recoding America," which is an excellent book about making software for governments. And the arresting line is that status in the government increases in proportion to one's distance from actually doing operational work. And one: true to my experience, two: absolutely terrifying. And so I think we should recognize how much of the modern world utterly depends on ops teams coming in and doing the work every day. And intentionally raise the status of ops to get smart people into it, to get the existing smart people in the field the recognition they deserve. And to also help organizations stop shooting their feet off by, like, devaluing this thing that clearly keeps their businesses, nonprofit organizations, governmental organizations, et cetera, the infrastructure that runs the world running.

And now I can answer the actual question! By the way, PR tip, if you ever get asked a question and don't wanna answer it, just answer the question you wanted to get asked. I cosplayed as a PR professional for a few years. Anyhow—the the question I was asked.

So there is a model in many software—people said that software is a thing that you are selling, that a SaaS company is sort of this vending machine on the internet where a customer comes in, swipes credit card (probably powered by Stripe), they get the software, they use the software, and that's fine. But the AAS—the "as a service" of software as a service—is extremely important. It often involves taking crystallized knowledge of how a business process should work and sort of productionizing that on behalf of your client base. And sometimes you can do that entirely with, you know, for loops and cron jobs. Frequently what you end up doing is employing the people your clients would employ if they had more budget and more sort of verve with respect to a topic than they factually do. And using your software to make those people much more impactful over more organizations than they would be able to impact if they were on each individual ops team sequentially.

And so the concrete examples of this for Atlas. There exists a tax agency in the world. I won't name them but I'm subject to two. And this tax agency really, really likes its fax machines. And so the tax agency issues a consequential number to businesses worldwide. And if you ask them to issue this consequential number, the actual physical process that issuing the consequential number will terminate in involves a human taking a piece of paper, putting it on their desk, writing a number physically down on that piece of paper, and faxing it to a counterpart.

This is not exactly the way that software companies expect to work. And we would expect like, oh, okay, if you have just incorporated a company, you should probably be able to like, pull up your consequential number via an API call, and the API cannot naturally read handwritten numbers on faxes. And so there was an ops layer which would like catch things like, okay, we need to somehow receive faxes and then type numbers into a database, and then deal with all the sort of weird crufty edge cases that happen when, you know, what happens if they write a number and we can't read it? What happens if they write a number and leave several digits off? What happens if they write a number and it is obviously the wrong number? What happens if you know, two numbers are assigned to different organizations, they happen to be the same, et cetera, et cetera, et cetera.

All that basically gets shuttled behind the scenes to the ops team. And most customers don't realize that it actually exists, because most customers fundamentally don't care that in the course of incorporating a company, they need to like proxy out or request several levels deep, through multiple different organizations, to someone who's actually physically sitting at a desk and like handwriting a number on a piece of paper. But the entire economy relies on that person coming into work every day, <laugh> and indeed we saw it during the Covid experience when that person, that team of people could factually not come into work every day, a process that the entire economy is downstream of ground to an absolute halt. And so part of our job was, you know, dealing with customers who are understandably less than happy about this.

Part was like: what kind of creative cheats around the constraints of this problem can we do where, you know, a large portion of the federal government is out, like they are just not coming in anymore. But we need these numbers anyhow, or we need some substitute for these numbers. What can we do to work through this problem? And so those are sort of like the epic phenomenon of Atlas the product, the thing that you could actually click on and sort of drive in your browser. And they were extremely important to Atlas the product as it was actually received by users. And so I would say that the "ops" side of Atlas is co-equal with the software in terms of the importance to our users and to clueful people on the team, et cetera, et cetera. And I was very happy that we had a culture of recognizing that early.

The micro tip both for Retool and anyone you talk to for the rest of your careers: Seat ops with engineering. Just naturally the way humans work, when you have our tribe over here and then a different tribe over there, they become the other, you have less ability to communicate in a high-bandwidth fashion. You sort of have this natural tendency to kind of like throw problems over the wall, and when problems come back over the wall, you say, oh, "they're your guys' problems," rather than, "there our problems together because we are mutually engaged and work to help our customers create value in the world." And so the discipline of being very physically and spiritually close to your colleagues across departments is an enormously positive one. And one I would tell probably all companies, but certainly early-stage companies to start early and keep for as long as you possibly can.

Absolutely. Yeah, I think that here in our New York office of Retool, actually, we're all on the exact same floor, and we sit, you know, a lot of operations, our support team, our developer relations team, right next to the engineering team. I couldn't agree more that it's just had a massive effect on collaboration. I love the story of moving sysadmins to DevOps. I feel like we're also seeing a lot of, you know, renaissance in terms of how engineers are focusing more on maybe business value than just, you know, programming as a means to end.

Mm-hmm.

And I'm curious, you know, were there cases at Stripe where you were deploying engineers against these operations problems that weren't necessarily traditional software problems? And how do you think about, you know, putting engineers on that highest leverage work, with any frameworks that you use to do that?

Patrick:

I think you would probably hear different answers here from people who, you know, viewed the problem kind of differently. One of the interesting things that happens at a company as it scales is that the experience of individuals and teams tends to be fairly consistent early in the life of the company, and then increasingly diverges as you go along.

And so with the obligatory disclaimer that I cannot speak for every person in the engineering department, as someone who was never actually in the engineering department, and that you know, different people had different experiences over the course of the last couple of years, one thing we were willing to do was to sort of... we're handling people's money. And so the caricatured version of "move fast and break things"—not going to fly. But in the case where things wandered into becoming broken, which happens not infrequently in the financial system, we were willing to have engineers roll up their sleeves and do remediation work on a sort of record-by-record, row-by-row basis rather than you know, "oh a particular financial party somewhere in capitalism went down for 30 minutes, 4,600 transactions were affected. We will spend two weeks building and testing a script to remediate those 4,600 transactions," et cetera, et cetera. Another way to remediate the same thing is to say, "okay, we're gonna get 20 of us in a room. We will sit around a table, 4,600 divided by 20 is 230 a piece, we can probably type out one a minute or so. We'll be here for four hours, but this will be done in four hours."

Successfully having a culture where that was not, like, "below the pay grade" of engineering to be a data entry operator for a few hours was frequently useful during the Stripe experience, and I suspect probably is currently.

Now granted, as numbers tend to scale over time and you cannot become sort of overly dependent on that because, oh, imagine like a three second outage of like Gmail or something. People who worked at Google, I presume you have some folks in the building that have some knowledge of what number of messages that must be, my quick finger-to-the-wings guess is it's ginormous. And you don't want to have someone be in charge of like, "okay, I'm going to individually drag all the messages to the right inbox for those three seconds." That would probably crush souls. But I think that's an interesting way to deploy engineers that I’ve not heard celebrated at many other companies.

Yeah, I love that culture of, you know, the best engineers are just getting stuff done for the business. You know, that's what makes you a 10X engineer—it's not the code that you write, it's the value that you produce to the customers.And I think we often talk about that internally as like a "pragmatic engineer" persona that we're looking to work with. So maybe going back, you were talking a little bit about how Covid affected this massive, you know, tax operation in terms of who was coming into work and how it was working. I'd love to just talk, outside of Stripe, about the incredible act of service that you were able to pull off with VaccinateCA. It really is the most amazing story. And so I was wondering if you could just give listeners a quick overview of what VaccinateCA was.

Sure. So early in 2021, I was reading news updates from California, as I often do. I have many friends, family, and coworkers in California, as you might imagine. And the [Covid] vaccine had arrived in America, wonderful. One of the best triumphs of science and capitalism in history was the speed at which we managed to roll out the Covid vaccine. And nobody in California could find it. And there were news reports of people calling sequentially 20 to 30 hospitals in a row trying to find anyone who had a vaccine that at that time, elderly people were immediately eligible for.

I became enormously frustrated because, as many of you are aware, there is a tech industry in California, and they are capable of building this technology called "websites" where you go to the website and everybody can access information without needing to sequentially call 30 people for the information. And everything about this problem screamed to me: this information is the same for everybody. It's like: the location, does it have the vaccine, or not? Like a search box, a map, come on, solve problem. Why?

So I went to Twitter to say okay, somebody, some civic-minded technologist should just build the website that California clearly needs, and solve this problem. And then I thought, who, you know, realistically speaking, is that person going to be? I had this image in my head of, okay, they're probably young, with relatively few life commitments at this point, because this is going to be a hard slog for a couple of months. I know that. And if they're young, they might not have great resources, and they might not understand quite how the world works or like how fundraising works, et cetera, et cetera. And I bet they'll be worried about like, "oh, well if there is great success here, won't I have the same problem that the official efforts have, where a million people are gonna try to access the server at once? My AWS bill will go through the roof and I'll be bankrupt."

So I responded to the tweet with, "Actually, amendment to that: So like, if you do this and it is successful, and the costs are too bad, tell me, I will make the costs go away." And was mentally sketching out ways that I could do that. I was like, there's an asymmetric bet here. If you try to do it and nobody uses it, then the costs round to zero because websites are almost free. If everybody uses it, then there's infinite money available for having solved this problem. So I was like, okay, deal with that later.

So this is me, you know, posting in the middle of the afternoon in Tokyo, and somebody who I didn't realize at the time is based in Indonesia, Karl Yang, saw it, and he said, absolutely, there needs to be a civ tech project here. And he took the first and crucial step, which was opening up Discord, which most of you probably know, but for those of you who don't, it's like Slack except people usually use it to play video games, or at least did at the time. I think they've, they've broadened a little bit. But he opened up discord and invited like 10 people he knew from the tech industry and said, like, get in guys, we're gonna solve the pandemic vaccine findability issue in California. And each of those 10 people texted a bunch of people—this is late in the night California time—and said, "Hey, I'm working on the pandemic. Are you down for helping for a few minutes?"

And somewhere about 70 or so volunteers worked from, call it like 9 or 10PM California time to 9ish AM the next morning when healthcare establishments in California started to work to, you know, build a spreadsheet, build the backend of this, talk about how it would eventually be scaled.

And then we started banging the phones. I think I made the very first phone call because there was a question of can you, as someone who does not have a privileged point of access into the healthcare industry, get, like, medicine stock inventory levels from an arbitrary location in the US healthcare industry, using nothing but the phone and telling no lies? And I was like I actually don't know this, and I haven't lived in America for 20 years and have minimal involvement with the US healthcare industry. Let me try calling the Walgreens that I know is right next to the Caltrain station in San Francisco, and here is a transcript of that call.

"Hi, could a 65 year old person get a Covid vaccine from you?"

"No, we don't have it yet, but call back in two weeks."

"Thank you!"

And I'm like, "Good news, guys—they'll tell vaccine inventory information to literally anybody calling you, don't even have to give 'em a reason!"

And so the next several months was basically scaling that insight up. We went from, you know, sequentially calling—I think we called about a hundred locations on our first day. By the end of the effort, we had 75,000 pins or so in the map for places across America.We had talked to the vast majority of them that week.

We ended up partnering with the state of California, [and] the blessed U.S. national effort. We were responsible for getting these results onto Google because, for better or worse, the people that were organizing the world's information in the fields of vaccines were us. It was very much a team effort. We had hundreds of volunteers about, depending on the point in the effort, and between like 10 and 20 people who were basically full-time on the project, about 10 full-time employees by the end of it, et cetera, et cetera. And [we] ran like crazy for about seven months from January through late July. And then sunset as the supply situation started to ease throughout the nation and you could access the vaccine about as easily as accessing healthcare generally, which is not a ringing endorsement, but it meant that we were not adding much marginal value like we were back in say, February [2021].

So that's the brief VaccinateCA story in a nutshell. If you want to Google the VaccinateCA story, there's a "Works in Progress" magazine article that I wrote about it, which goes into a lot of the operational depth.

It's excellent. I actually read it in preparation for this, and I would highly recommend it. Believe it or not, I'm almost a hundred percent sure that I got my parents vaccinated because of VaccinateCA and was able to help them find where they were going.

Awesome.

Thank you very much.

You wrote a line in that article that really stuck with me, which is: good software improves the lives of people, even people who don't directly interact with the software. In your view, what role did software play here versus sheer people power? How did those two things come together?

So if I have the social space to say something that is a little bit spicy, a thing that was mentioned by the government, nonprofit organizations, et cetera, et cetera, with regards to the tech industry's involvement in the pandemic, was that "you folks don't understand that there are poor people in the world who don't have smartphones, and that your ability to impact the world through painting pixels on smartphones doesn't reach them."

And I'm like, one, I question the notion that the tech industry does not understand the demographics of the world because we're the operating system of large portions of it. Two, it is the case that many people who will be helping folks who are not in a position of advantage will be using advantages that they possess, that the beneficiary does not, including the ability to operate websites, and a major way that people who might have had linguistic issues, cognitive issues, lack of access to the internet, et cetera, et cetera, would access the vaccine was that they would ask someone they trusted, either a friend, a family member, a local community organization, a government employee, and that person would Google it and then they would read them Google results over the phone.

The phone gateway to Google is a major source of value in the world even if you discount the value of the pixel-based gateway into Google. A major source of our value was putting those search results on Google. So the person who was Googling on behalf of someone who could not Google for themselves would actually get responsive, accurate, timely information. That is my sort of motivation here. And also a brief bit of a peek about how people misperceive how important software is in the world.

Similarly, it's like a lot of the software and infrastructure that runs our lives is invisible every day. You don't see the power grid, you don't see the water, but by goodness, would you notice if it was off.

And so I think approaching infrastructure with both the humility that we all depend on it, and also the sense of awe of like—what a human accomplishment that it exists and works very well almost all of the time is one of the kind of through lines of my experience.

Anyhow towards the larger issues… I dunno if it's the larger issue, towards the other issue... To what extent does software create value through providing it directly to a user, and to what extent does it create value to enabling that user to sort of exert their will upon the world and to create value in it, thereby I think that it is probably more through the second than the first. And I think that is likely surprising to people. Maybe it's less surprising to you folks that Retool, 'cause you sort of understand that everything in capitalism runs on software, sometimes in informal software, but software nonetheless.

But the vast majority of all software in the world runs in businesses. It is siloed. There's a very small number of users. Sometimes there's only one for a particular application. But that person, you know, their job is—coextensive is not quite the right word. Their job's not coextensive with interacting with the software, 'cause their job, you know, creates value in the real, atom-based world, not the bits-based world. But a large portion of their every day is spent, you know, doing IO into the software and making decisions and then having the software help you execute those decisions in the real world, et cetera, et cetera. So I would sort of carry this always in your minds as you, as you work on things.

Yeah, the theme that I keep coming back to over the course of this conversation is sort of "the tip of the iceberg." With Atlas, you know, so much of the software you didn't see, but also [there was] so much impact. The many employees that are at these companies that have been started [through] Atlas, [but] you don't even know about Atlas. The same thing with VaccinateCA, you know, hundreds of thousands of people that were vaccinated, [but you] probably didn't even know you know, about all the effort under underlying it. And I think those are some of the amazing stories we can cover a little bit.

Knock on wood our best estimate was probably single digit millions in California and single digit millions elsewhere in the US. I asked Google if they would give me their search numbers, and they were like, "Oh, we don't do that." So I don't know how many people actually saw it, but [it’s] certainly the thing I'm proudest of doing in my career.

Wow. Easier to get the numbers from your local Walgreens than from your Google search.

It is a little bit crazy. One of the interesting things in the in the VaccinateCA experience, which I'll just throw out as aside as a pitch to read the writeup—many people who were coming at this from government, et cetera wanted there to be a magical bullet software solution of you know, "if you can just like figure out a protocol that will talk to all the pharmacies and like stitch their disparate IT systems together, and like bring in the stuff from the Veterans Administration and also from the separate states." And there were over 60 separate supply chains in California delivering the vaccine. "So if you just like, figure out the software and the data interchange, put it all in a database, that'll be great."

And the software people were saying, no, we should do the thing that actually works. There is a standardized protocol in the United States for getting information out of the healthcare system. It is the English language spoken over a telephone. We should embrace it, and just execute really, really vigorously on deploying that at scale as soon as possible.

So okay. Pitch over. But interestingly,sometimes the most important things that software people do aren't really software as it's traditionally conceived.

I'm very glad that you picked up the phone and made the call. Because otherwise we would probably still be trying to build that protocol.

Yeah, in one sense, fixing the problem is somewhat inevitable. A great thing about the United States is that it is a rich nation and wealth is, you know, a proxy for being able to get what you want. And so we would eventually get what we want. And then in another sense, the drum I banged early and often was every day matters, every dose matters. It’s like accelerating the eventual victory. But by, you know, a day with respect to—oh, here, let me give you the number. To first approximation, 10,000 dose days equals one life saved. And so if you have like 500 doses that are stranded in the freezer for three weeks because nobody knows about them—that happened a lot—like basically one person has just died, an expectation as a result of some operational issue. The operational issue does not scream to the people involved like: "this killed somebody."

And so having an appropriate level of urgency with regards to, okay we know there will be a solution eventually, but how much of that solution can we pull forward earlier in time? Can we make the thing that arrives Friday versus the thing that arrives Monday? Can we make that thing have like a couple thousand more people than it would've had by default, et cetera, et cetera. Just that like acceleration would sort of minimize the human impact of the Covid disaster.

And yeah—the words "urgency and focus" were said around Stripe lots. And trying to sort of like snip out plasmid style that bit of DNA and inject it into our operations. I can't say enough good things about urgency and focus in many domains, including ones that don't explicitly have lives on the line, but definitely the ones that do.

Okay.

Well I'd be remiss not to take the opportunity to talk to you a little bit about the future of programming. So maybe in our last few moments, I wanted to ask you one question around that. You're probably the most cited person in the world around startup salary negotiation for engineers. And in today's world, much of the focus is centering around AI. I'm curious: do you think this will shift the skills that engineers should develop to be valuable to their businesses?

I think that one, I, as someone who had an undergrad concentration in AI back when the dinosaurs walked the earth, I'm enormously impressed at what is coming out and spending a bit of my sabbatical playing with things. So I think the impact of AI is probably underrated to correctly rated right now. [But] I think the impact on programming careers is grossly overrated. And I think that comes from people's misunderstanding that they think programmers are—a line that I used in one of my early essays, possibly salary negotiation essays, was that people have this mental schema of like, programmers are anomalously, highly paid peons who speak mystic languages into a computer, and then the computer goes off and does the thing.

Programmers aren't paid for understanding syntax. It is the thing that you must do to be able to program well. But engineering work is not coextensive with memorizing magic syntax and making it go. I joke that the first AI program to put programmers out of work by making it superfluous for them to understand arcane syntax, was called a compiler, which would, you know, take high-level languages like C—such a high-level language!—and compile it down to byte code for the CPU to execute without assembly code to eventually get compiled into byte code… sorry, engineering team, accept this brief simplification for the purpose of argument.

But you know, [it] obviated a lot of the human labor involved in telling computers to go. Did that cause programmers to go away? No, it caused programming to absolutely explode because it would give programmers more ability to create tools that would allow their organizations to affect their will upon the world.

So I am extremely bearish on the notion that AI will cause programming jobs to go away. The world post LLMs is a lot like the world pre LLMs, and I would advise most engineers to focus on creating business value, understanding who uses your software, what they're attempting to do with it, how your software creates more revenue or reduces costs in business or otherwise creates value inside the world. And treat the technologies that you use, the syntaxes that you master, the beautifully aesthetically appealing Rube Goldberg machines that we can sometimes create as —that isn't the end goal. That is a thing that you do in the service of ultimately delivering those business outcomes and positive impact in the lives of your users. And if you do that, no matter what happens technology-wise over the course of the next 20 years, you'll be fine.

Everyone who's saying that programmers will go away as a result of LLMs—the implicit claim is that no human will have to understand in detail how the world works when the rubber hits the road on a nuts-and-bolts level. I'm as short that claim as anyone should ever be, like—what will we be doing if not understanding how the world works? And every time we sort of greatly increase our capabilities to understand how the world works with more granularity and to be able to affect larger portions of it within one individual span of control, we find an amazing multitude of more problems... The more things we want to do once we have those increased powers.

And so, increasing the leverage available to engineers doesn't result in there being less engineers. It probably just results in them being able to do vastly more in the world. So that is my brief point of view on the matter. And now, granted, potentially there's a world in two years where ChatGPT can talk me out of that view. But we're not there yet.

And that's a wrap!

Who would you like to hear from in the future? What topics would you like to see the series explore? Drop us a line at operatorsplaybook@retool.com and follow us on LinkedIn and the platform formerly known as Twitter to keep up with future conversations.