Marco Arment (5:27)

Yeah, and I think that's, you know, like many other accelerating tools, the fear which does happen is that when you make the good people more productive, you have a lot fewer jobs for the people who are less good or whose skills are less unique or are less necessary. Yeah, you might be cutting the team down from 20 people to 15 people or whatever. And what happens is that you don't need as many like okay or very junior programmers if the senior or good programmers can be more productive with some of the more tedious stuff. Over time, we have always developed major improvements to programmer productivity with different styles of apps, different advances in compiler technology, different programming language techniques and concepts, having more and more safety checks and dynamism and different things. These are all things that have that have improved programmer productivity. The fear is always again that you will lose the jobs for the lower tier of programmers. But what has actually happened so far mostly is that the market for programmers has not gone down, usually by making software much cheaper to make. The actual outcome is people just start demanding more software in more places to do more things and they raise the bar for what they expect software to do. And so what ends up happening is whenever we make programmers more productive, so far we have just actually increased the demand for programmers because the value of programmers has gone up. And, you know, we're kind of just moving the value chain. There are things that we will still be able to do even in a world where AI tools might be writing a huge amount of code, because, you know, as you said, like someone has to direct them with what to write. Now maybe down the road we don't even have to do that. We'll see. But someone's got to plug in the server at least at some point, the human decision is what to do. And in that ATP overtime, one of the things that John Siracusa said was defining what to do is harder than it seems. You don't just write a prompt and have a complete product come out of that. You have to define like, well, what's the behavior? What do we want this thing to do, what do we want this thing to look like, what features we want this to offer? And all of that. Like if a lot of the drudgery of the code writing gets automated away, those jobs still don't disappear. If anything, they become more important. You know, every time we have made programmer productivity better, like we still, that just becomes more tools for, for programmers above them to use in the same way. We've made art easier to create over time, but there's still huge demand for artists and designers, graphic design and all these things. These are huge fields that keep growing even as we're making things easier to make for non artists. All these giant AI tools recently, they're also doing things to create art and make that easier. Is the market for artists disappearing? No, it gives the artists greater tools for their own brainstorming and automation of drudgery. And then it gives potential customers. Here's a bunch of things to try. You can have some AI tool generate. You give me 10 different logo concepts and now give me 10 more. Now give me 10 more. Let me expand on this one and maybe tweak this a little bit. And what you get out of that is not a final product. What you get out of that is then something you can like. You can go to a designer and say, here's the direction I'm thinking, here's some concepts I tried, here's what I liked, here's what I didn't like, and then you can get a good look from a designer. So these are just. You have all these tools that they are like. If you look on the surface, you might think they are getting rid of jobs and they might get rid of some jobs. But what tends to happen mostly is expanding access as programming has gotten easier and tools like memory safety, languages and autocomplete and stuff. What has happened is programming has gotten easier. You no longer have to be an assembly language genius to be a programmer. But you do have to actually do the work. You have to actually be the programmer. You have to actually decide, I'm going to direct these tools to do this. To do what? AI tools are a huge leap in a lot of ways, but I think they still need that. They still need the person to say what to do and to take their output and know what the heck to do with it.

David Smith (10:29)

Yeah. And I think it's interesting the way you're framing that there in a weird way. It's almost like it isn't necessarily that everyone could code. It's almost like everyone can make apps now in a way that like, you're moving up the stack another level that the code itself is less. And I think increasing accessibility is an interesting aspect of that as well. I think it's like the term people have been throwing around a lot, Jevons paradox, I think, which is as efficiency increases, demand increases, and so you don't end up destroying the market in a way that you potentially could. But obviously this is one of those things that isn't like a guarantee. It isn't necessarily that if you make programming in this case more accessible, there will be more demand for programming because more people can do it. That is one outcome. The other outcome is that there will be a certain fixed amount of it that is sort of reasonably possible or does exist. And so you can't get beyond that point. And like, which of those things is the outcome? It's like, I don't know like that. And I think none of us really do. But it's definitely an interesting aspect in all of this where you can get a lot farther than you could without previous deep knowledge previously. But that isn't a guarantee that everyone will be able to do that or that there'll be more sort of demand and jobs for this. Because there are other examples you can think of which I think line up reasonably well. And specifically I was thinking recently about how in carpentry, so building a house, in some ways this is the sort of increase that you get in productivity, say between a hammer and a nail gun, that they are both ultimately just things that, you know, affix two pieces of wood together by driving a nail into it. But it dramatically changes the kind of nature and relationship of that thing where now it doesn't. You don't just have the challenge of putting the pieces of wood together that's essentially like free and instantaneous, that a nail gun is massively more efficient. But instead the challenge, and this is one of these things like, I don't know, I've fallen down the Home Building YouTube rabbit hole recently. And watching people build houses is super interesting to me. And I think the thing that was fascinating reminds me a lot of programming is how you get the impression that the actual challenge, like the amount of time people spend Sticking pieces of wood together in a day's work is relatively small. What they spend a lot of time doing is working out which piece of wood goes where and how to frame it and how to structure it and how it's going to be like. All dealing with the constraints and the rules and the code and all the stuff that goes around it. The actual part of combining the wood together into the shape you want, that's easy. And that used to be much harder if you had just nail and hammers. Now you have a nail gun. That's super quick. But the actual that is actually 20% of the job. The other 80% is the knowing which two pieces of wood to combine in which shape, in which configuration, using what fastener. Like that part doesn't change if there's an efficiency gain that happens. It's like there potentially are certain laborers in this metaphor who. Who would not be employed now, who would have been employed previously. But the fundamental knowing what to do when part that hasn't changed, and that is, I think fundamentally it's almost like in the way that we used to think of the word. Computer used to be a person who did numerical computation like it was a person who would sit there and do the math. And now a computer is the thing that does that. It makes me think in some ways how I've never really loved being called. I don't think programming is really what I do. If someone asks me a job description or I'm filing in my taxes and I have to give myself a name. Software engineering feels much more true to what I do in the sense of it is this multidisciplined thing of combining around. And one of the small parts of that is programming. And that small part of it, that programming part potentially is becoming less and less specific knowledge and much more just something that you can deal with at a much higher level. In the same way that you don't need to have a person who's actually doing the computation before now you can have a computer or a calculator do that for you. But my job is now moving up to the engineering aspect of it and knowing what's the actual structure, what are the architectural plans, how should this go together? What are the constraints that are beyond just now that I have a prompt of give me a thing that takes these fields and stores them in a database, and then a thing that takes them out of the database and displays them in a table view or whatever that might be like those parts are becoming commodities. But the actual knowing what parts to put together that is still the. It's like the instruction book of the Lego is still the part that is very difficult and challenging to build. The actual snapping the parts together has become much easier.

Marco Arment (15:27)

We are brought to you this episode by Sentry. Sentry are the people who help you avoid your mobile app being the one that gets deleted. Next. From getting deep context into crashes to seeing full insights and performance issues, Sentry is here to make sure your code doesn't suck. You can fix what's broken faster with Sentry and keep your app running smoothly with application monitoring. Built for mobile developers just like us. You know, it's so important that your app not like have weird bugs or slowdowns out in the field. And it can be really hard to know what's going on when your users are, you know, they're using your app, are they like hitting stalls? Are things breaking in weird ways? Is there weird latency? You need to have insight into that and that's what Sentry gives you. So keep your mobile users happy. The great news is Sentree is totally free to use, so there's no reason not to check it out. And even better, as an under the radar listener, you can get six months of the team plan for free. Just click the link in the show notes and use the code radar. That's six months of the team plan completely free at Sentry iO4 mobile. Or click the link in the show notes, then use the code radar. Our thanks to Sentry for the support of this show and relay. Yeah, I think the deciding what to do is underrated as a skill for any business, honestly, but especially for software, and especially for indie developers, we see in software all the time. We are not usually limited by typing speed. Like if an AI tool can type a bunch of code for us, that's usually not our limiting factor. Usually our limiting factor is, first of all, debugging tricky problems, which I don't think the AI tools are likely to be massively helpful with. They can find probably small errors like typos, syntax errors, really obvious logic errors. I'm sure they already are able to find some of that stuff. But programming, when you look at the amount of time in a day that you spend as a professional programmer, most of that time is not spent typing new code. It's usually debugging, trying stuff out, moving stuff around, thinking about what's the best way to do something, trying to keep track of all the complexity in your head. What AI code generation does is, first of all, none of those things, but then also it gives you a bunch of completed code and says here, here you go. And that's great in certain contexts, in certain sizes and certain types of code. But what you then have is a whole bunch of code you didn't write and you're integrating it into a product. Well, that has time costs to it. Sometimes that'll be worth it, sometimes it won't be, sometimes you'll actually, you won't be coming out ahead trying to integrate that kind of code rather than writing it yourself or using something that you already know. There's going to be a lot of different trade offs with that and the tools will advance, they'll get better at certain parts of that, they won't get better at other parts of is still on you to take those pieces it's giving you and figure out first of all, do they work? And you'll probably have to do a lot of testing and validation and everything around them. Then figure out, okay, well now how do I build that into a product? And more importantly, what product do I even build? Because the other major time sink of professional software development, again it's not typing, there's debugging. The problems like figuring out why things don't work and then also the other major time sync is working on the wrong things. That is possibly the biggest. I can't tell you, you look around the software bins, look around your own apps, your own life, how much time we spend doing the wrong work, building the wrong feature, building the entirely wrong product. There's so much wasted time doing that. And that's something that none of these tools are going to help you with. And as indies, the most important skill that an indie developer can have is that kind of product sensibility of like what is the right thing to build. That matters so much more than how you build it in a lot of ways, honestly, it matters so much more. That's why you can look at the app store like top charts over time you can see all these apps of mixed quality, let's say. And sometimes you look at something like why is that popular? That's a piece of crap. But it's popular because it was like the right products to the right people at the right time. And so these tools are going to help parts of our job. Yeah, they are. And they're going to put some people out of work. Yeah, probably not indie developers, but they're going to help us probably. But what we really need much more help with is debugging and product decision making. And that's something that we are not seeing a lot of help yet from these tools, and maybe we will over time, but we're not really seeing that. What we're seeing is faster typing of kind of wrote simple stuff. And that's not without its value, but that's not most of the job.

David Smith (20:44)

Yeah. And I think a lot of the things you're describing in some ways I think combine in my head as intuition. There's a sense that over the years of being a professional programmer, I have developed a sense of intuition on the technical side in terms of when I'm debugging, which you're 100% right. So I probably, like, I spend two thirds of my programming time debugging code, not writing code. The actual putting characters into a Swift file. A very small part of my day running and testing and debugging that code that I've created far more of my time. And I think that requires a sense of intuition, both to know how to fix it so when something isn't working and then perhaps even more subtly. And I think this is the fundamental part that I think is going to be much longer Horizon before AI would be able to tell you is, is it working correctly? Right. Like, and this gets into like, the halting problem of like, these deep challenges. Things in computer science of like, knowing if a program is doing the thing that it's supposed to be doing requires this, like, this paradox of knowing what it should have been been doing. And you can't know what it should have been doing until you know what it's supposed to be doing. It's this very nuanced, challenging thing. And so a lot of that as a developer is about understanding that you have to develop this intuition that be like, ooh, that doesn't look right. And then knowing that it doesn't look right is the first problem, and then knowing what it should look like is the other problem. And so that is an intuition that I think just comes with time and with taste and with aptitude and with ability. Like, I don't know why I know that something isn't right or like, ooh, when this kind of bug happens, I've developed like the sense of like, ooh, I know where I need to go to look. And very often, like, I think the speed, my speed as a programmer, my ability to do a good job at what I do, is that I'm a fast debugger much more than I'm a good programmer. Like, that is I think, something I've learned over the years that I'm not actually a particularly good programmer. I don't under, like As a, from a computer science perspective, there are huge swaths of things that I'm just not very good at and I don't really understand. I still to this day do not understand swift async concurrency stuff properly.

Marco Arment (23:00)

No one does.

David Smith (23:00)

It's okay, I know enough to write a bad, vaguely working version of it. But some of the stuff, when it gets like, when is this isolated and when is an actor and when I should use my own actors, I don't know, but I'm very good at making something and then working out, reliably working out how it isn't working the way it's supposed to and then how to fix it. And so rather than maybe measure twice, cut once, I'm like, measure once and then duct tape together four times. And that works in the sense of I end up with something that works, but it's not a different approach, but that works for me. And I'm good at debugging and that's allowed me to have a good career because I think that is the part that is ultimately the essential. And that's one of the things that I'm good at. And it's one of the things that's very difficult to automate. And that's even just to say that this is even just a small sliver of our work that you and I do. Being a successful indie developer, like, there's so many parts of it that are nothing to do with code or apps or software at all. Like dealing with App Store Connect, getting a Dun and Bradstreet number, dealing with your accountant, getting paid, filing paperwork. Like these things are the essential parts of being in indie that AI isn't going to help you with. Like, I don't think there's any AI in the world, even with AGI would be able to get a denim Brad street number. Like, I found that incredibly difficult and I'm a, you know, I was a well qualified, smart person. So like AI can't help us there.

Marco Arment (24:30)

Yeah, because like what the AI tools, like, the way they work, what they are best at is brainstorming. Like, they're so good. Because what, what these, you know what? LLMs, especially what they are, is BS generators. Sure, you can use that. Like when, when you are, when you're doing something where like there is really not like one right answer, but you're looking for like, hey, give me some ideas for whatever. Like it's really good for that. Because it can't be wrong if you say give me some ideas or draft me some, draft me some concepts for this, you know, there is like, hallucination, doesn't matter. You know, you're asking it to hallucinate you. Almost like you're asking it to generate. Like, and they're really good at that. Like, I find as, as creative brainstorming tools, they're great because I don't have that kind of creativity where I can just have a blank sheet of paper and come up with something. I need prompts, or I can riff on something someone else says, but I can't come up with the first original thing. And so it's great for stuff like that. But what you then need to do is be able to take the, to look at the BS that it's generating for you and be able to say, oh, you know what, that one, that's something. Let me build on that piece. Let me throw out these three ideas. Like, let me start with this and expand on this a little bit and keep using it. You can iterate. You can say, all right, well, give me more on this theme or cut this down. Or if you're doing a design with it, you can say, you know what, get rid of this background thing's not working. Make this bigger, throw in this style. And it's great for that kind of brainstorming generation kind of thing. But that is part of a process. If you use the output like we were for the restaurant, we were looking at, like, different logo ideas for, like, how we can, how we can put certain shapes together and any, any of the images. And this is like, with ChatGPT's brand new image generation, it's super high quality, super cutting edge, but the images are unusable that it generates. Like, there's, you know, basic geometry problems. The text is really still very messed up. There's like, conceptual things where, like, oh, that, that goes behind this in a way that wouldn't really make sense. Like, they're not usable final products, but they're great for brainstorming. And then we can go to a designer or TIFF is a designer. So, you know, we can do, you know, but we can, like, we can then use a human who's good at these skills with this, like, brainstorming input and say, we like this, but can we work with this and make this, like, into something real and you still need the human for that. Well, the same thing's true of software. Like, you can take what ChatGPT generates for you and it's okay, and it's a good starting point, but it's just that it's a starting point or maybe it's an idea or it's a brainstorm. And you have to be the one with the skill and the discipline and the product sensibility to be able to put those together into an actual product that people want to use. And then, as you were saying, to then be able to do everything else about. I would love if an AI could automate getting a John and Bradstreet number. I would love if an AI could automate negotiating with app review to get through basic problems. That'd be great. But that's still gonna be. Those are still gonna be very human problems. So at the end of the day, you still need to be the director of what's going on. Like, the tools can do a lot more of the work for you, but they still need a director who knows what they're doing and that's us.

David Smith (27:50)

Yeah. And I think maybe the positive way to end this is like, if you are someone who is starting out thinking, if you want to be an indie or trying to develop in this sort of line of work, is understand that I view these, like, view these tools as a way to develop your intuition and taste and your ability to direct them in the way that, like, I think I am good at making apps now because I've made so many apps and I've launched so many flops and failures that I've learned a lot along the way. And I think these tools, like you're saying, are great for getting you to a place that you can learn to, getting you over the kind of awkward, just rote spoiler plate code that you have to write that is not particularly helpful or interesting to the place that is interesting and useful and you can learn from. And I love the thought of someone who kind of wants to be an indie developer but doesn't have a huge programming background. Their ability to potentially get to that place much sooner now and to start failing and to start learning and then start succeeding. And like, I think that flow and that ability that these tools potentially allow, that's exciting. Like, that's cool and interesting and is far more compelling in some ways than trying to teach everyone, you know, how swift concurrency works, that it is instead about teaching people how giving them the ability to teach themselves how the app business works and what's a good app and what's not a good app and get to that place quicker. And I think that's exciting and that's fun to me.

Marco Arment (29:21)

Thanks for listening, everybody. We'll talk to you in two weeks.

David Smith (29:24)

Bye.