I miss when programmers were lazy. transcript

I still vividly remember when I learned about the three virtues of great programmers: laziness, impatience, and hubris. I know that sounds crazy cuz those are all terrible traits usually, but they make great programmers because programmers are supposed to automate things and make them better. And if you're lazy and impatient and very overconfident, the likelihood that you're willing to think you can rebuild the thing, that you'll do it and you'll do it right so you never have to touch it again, goes up massively.

That's why those traits work so well for programmers. If you're impatient, you're going to want to fix things. If you have high hubris, you're going to think you can do it. And if you're lazy, you're going to do it in a way where you never have to touch it again because you don't want to keep maintaining the thing after you fix it. So, why am I talking about this now? Well, I think these traits are shifting as the way that we write code shifts.

Laziness no longer means what it used to, and laziness can be rewarded by just throwing prompts at the machine. One of my favorite developers of all time is Bryan Cantrill. The amount that this particular person has shifted and shaped the way I think about software is hard to put into words. The number of random quotes and things that I steal from him constantly is a little absurd. I love Bryan to death. This man has taught me so much without ever meeting me.

I did an episode on his podcast with him forever ago and did my best to hide how hardcore of a fanboy I was. But man, seeing he just put out this article, The Peril of Laziness Lost, I knew we were going to have to talk about this. Both the importance of laziness as a method to create great software that's reliable, and also how this eroding is kind of a different type of enshittification. It's silly to think that laziness leads to higher quality software, but it absolutely does.

And on the topic of quality software, let's take a quick break for today's sponsor. AI's made building really fast and fun, but all the things that aren't improving are really, really painful right now. Things like CI times that are super slow. Things like Docker pulls or caches that take forever to download. All of those types of things have always been annoying, but now that they're such a high portion of the time I spend building, they are more annoying than ever.

At least they were before I started using Depot, today's sponsor. These guys built way faster CI that is fully compatible with GitHub Actions, but also doesn't have to be if you want to hit their API directly. This new CI engine lets them do all sorts of crazy things from trivial CLI implementation, so your agent can run your real CI in the cloud, and to unblock itself and figure out what's broken before having to push up the changes, to actual parallel checks on things that make sense.

So, you can have a job that will install your deps and then run three things in parallel on the same box at the same time. Duh, why is that not a thing on GitHub? Are you kidding? When you combine that with the Depot CLI, which is a full replacement for Docker, you get absurdly fast builds and cache pulls from either registry that they hold for you. And actions themselves, even without all the fancy parallelism, can be up to 10 times faster, especially around the caching and downloading side of things.

The pull-through cache stuff they're doing for Docker is really, really cool as well. When you start pulling things from their registry instead of the defaults, you get way better performance, and it can go layer by layer and cache all of those pieces, so you don't have to download the whole thing every time. And that same cache works for you on your machine, your agents in the cloud, and your CI when you're doing testing.

They serve their layers through a CDN, so the difference is absurd. If this ad was longer than your Docker builds, fix it now at solid.dev.link/depot. I love the opening of this article going directly to the source of the Programming Pearl book where this quote comes from. If you look at the Wikipedia for this book, there's a whole section on the three virtues of a programmer that it was important. I I have thought about this quote since I first heard it in like the late 2000s.

It's part of why I'm a programmer to this day. If we're going to talk about good software design, we have to talk about laziness, impatience, and hubris, the basis of good software design. We've all fallen into the trap of using cut and paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mountains of higher-level abstractions when they should have used cut and paste.

Generally though, most of us need to think about using more abstractions rather than less. As originally put, these are those three virtues. Laziness, the quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer, also hence this book.

See also impatience and hubris. I love this that they cite the other two each time. Impatience, the anger you feel at the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them, or at least they pretend to. Hence, the second virtue of a programmer, see also laziness and hubris. And then hubris, excessive pride, the sort of thing Zeus zaps you for. Also, the quality that makes you write and maintain programs that other people won't want to say bad things about.

Hence, the third great virtue of a programmer, see also laziness and impatience. I love this. I I've thought about this for over 15 years now, and I hope that some of you are learning about it for the first time and will do the same, because I do firmly believe these traits are what result in some of the best software in the world. You have to be arrogant enough to think you can do it. You have to be impatient enough to do it right, and you have to be lazy enough to do it in a way where it maintains itself with no effort.

Back to the Cantrill article, cuz I'm very excited about this. Of the virtues, he's always found laziness to be the most profound. Packed within its tongue and cheek self-deprecation is a commentary on not just the need for abstraction, but the aesthetics of it. Laziness drives us to make the system as simple as possible, but no simpler. To develop the powerful abstractions that then allow us to do much more much more easily.

Of course, the implicit wink here is that it takes a lot of work to be lazy. When programmers are engaged in the seeming laziness of hammock-driven development, we are in fact turning the problem over and over in our heads. We undertake the hard intellectual work of developing these abstractions in part because we are optimizing the hypothetical time of of future selves, even if at the expense of our current self. When we get the calculus right, it is glorious, as the abstractions serve not just ourselves, but all who come after.

That is, our laziness served to make more software easier to write, and systems easier to compose, to allow more people to write more of it. This is why I loved doing Stack stuff. A lot of y'all probably remember me from a different type of content that wasn't very AI at all, create T3 app and the T3 Stack. The goal of the T3 Stack wasn't to get famous by having my tech take over the world, it was to be easier to build apps in the specific lazy way that I liked.

I wanted to have my computer tell me when mistakes happened all across the boundaries that exist in my systems. The fact that my back-end code could tell me when there was an error between two functions, but my front-end code couldn't tell that the back-end code changed, frustrated me deeply. There were parts of GraphQL that fixed this, but the weight of setting up all of that was far too big and far too abstract. You were basically paying the cost on both sides to barely get the benefit.

T3 Stack was built to rethink that, to get you the benefit with less effort in a more minimal way. It was, to put it simply, an attempt at making the simplest possible set of abstractions that give you that full-stack type safety, so that your computer will tell you when you make dumb mistakes. And the funniest thing about the T3 Stack is that I was too lazy to even make the template to use it. I just did a single live stream, which I only did because I was tired of people asking dumb questions about it and not thinking it was great.

So, it was my hubris to think everyone should use a stack like this, and my impatience to not have to explain it over and over again, and my laziness to just wanted in one place, that led to this channel existing. And then the create T3 app project was created originally by Nexile, who was a younger member of my community contributing from India, just building what he thought the T3 Stack should look like as a quick way to set it up.

I tried it, I liked it a lot, a bunch of other community people came in and now Julius, who is currently sitting directly below me working in my office, came through from Sweden working on create T3 app and is now running almost all of the code we are shipping across our surfaces. All of this happened because I was arrogant enough to think I could challenge other stacks and I was lazy enough to not feel like dealing with the errors that I was hitting in my lazy way of coding.

And then of course the impatience where I just didn't want to keep explaining it over and over and here we are. So I fully agree here. When you do get the math right when you're building these abstractions and systems, the feeling is so good to know that other people are building software more efficiently and can create more software they're excited about. Even just seeing the little T3 favicon in other people's apps.

Like I know for example that AI Code King used create T3 app to start one of his internal benchmarks because I see the little T3 emblem in half his [ __ ] videos. That's so cool to know that I made life easier for other programmers to make more cool [ __ ] by [ __ ] posting about my stack. It's the coolest feeling ever. So I fully understand what Cantrill is saying here. Ideally you would want those that benefit from abstractions to pay the virtue of the laziness forward.

To use their new found power to themselves labor on the abstractions that they make. But a consequence of the broadening of software creation over the past two decades is that it includes more and more people who are unlikely to call themselves programmers and for whom the virtue of laziness would lose its intended meaning. Okay. Oh boy. Here's where this one's going to get fun. I can already tell. Oh god, I just started scrolling more or there's a Garry Tan screenshot.

I am so scared of where this is going. Worse, the extraordinary productivity allowed by modern abstractions has given rise to an emphasis on a kind of false industriousness. I I hate these many [ __ ] pretentious words. Pejoratively, this was the rise of the programmer with the virtue of ironic laziness in hammock driven development displaced by hustle porn about crushing code. Okay, is going to be be of the line of code posts.

Onto this dry tender has struck the lightning bolt of LLM's. Whatever one's disposition is to software creation, LLM's allow that to be applied with much greater force. So, it should be of little surprise that LLM's have served as an anabolic steroid for the programmer set. Yeah, they're to translate from these words that don't really matter here. Emphasis on a kind of false industriousness. This is people caring too much about feeling productive.

Perjoratively, this was the rise of the programmer as in like is mostly understood in this way. And then here, the anabolic steroids are these people are addicted to the feeling of performance. Excited with their new found powers, they can't seem to shut up about it. Take for example, programmer of note Gary Tan, who has been particularly insufferable about his LLM use, bragging about his rate of 37,000 lines of code per day and still speeding up.

Absolutely insane week for Agentic Engineering. 37k LOC per day across five projects, still speeding up. I agree, horrible way to talk about this. Cringe, painful. There are things within G stack that are worth talking about, but none of them are being indicated here. For contrast, all of DTrace is, depending on how you count it, on the order of 60,000 lines of code. If you're not familiar, DTrace is a big project that he has built.

It is a performance analysis and troubleshooting tool that is included by default with various operating systems including Solaris, Mac OS X, and FreeBSD. They're actually working on a Linux port as well. DTrace is huge. And DTrace is roughly twice as many lines of code as Gary writes in a day. If laziness is a virtue of a programmer, thinking about software this way is clearly a vice. Woof, bars. Part of why I really like the T3 stack is that the amount of code you had to write for things went down massively.

I had an example project one of my friends built that was like 5 or 6,000 lines of code. It was a full stack TypeScript app using a lot of Firebase. And I rewrote that in under 500 lines with the T3 stack, and it blew him away. There wasn't even anything worth testing cuz the code was so much simpler and easier to maintain. So, if suddenly writing a shitload of code isn't a big deal, anti-patterns like the entire language of Go or really bad model-view-controller stuff go from this is something we should fix so that it's easier to maintain so we can be lazier into whatever the AI will do it for us.

And that is a dangerous thing that makes the way we build software become a little more of a vice. And like assessing literature by the pound, the fallacy is clear even to novice programmers. Yep. Measuring books by how much they weigh, you're doing it wrong. As for the artifact that Tan was building with such frenetic energy, I was broadly ignoring it. Polish software engineer Gregorian, however, took it apart and the results are at once predictable, hilarious, and instructive.

A single load of Tan's newsletter blog thingy included multiple test harnesses in the load of the blog, by the way. The entire Hello World Rails app, a stowaway text editor, and then eight different variants of the same logo, one of which had zero bytes. Problem isn't these issues per se, cuz they're all fixable. It isn't even the belief that what the methodology that created them represents the future of software engineering, though that is certainly annoying.

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own or anyone's future time and will happily dump more and more onto a layer cake of garbage. Left unchecked, LLMs will make systems larger, not better, appealing to a perverse vanity metric. Perhaps, but at the cost of everything else that matters. Yep. There's a very real problem.

The LLM will happily just do [ __ ] and if you hand it [ __ ] it will gladly work in the [ __ ] There's there's a real problem, and I hadn't really thought about this so deeply before, where a shitty enough codebase would kill the company because you can't hire good enough engineers to fix it. If you hire a great engineer and you put them on a [ __ ] codebase, they'll do one of three things. They'll fix it if they're allowed, they'll try, get told not to, and then leave, or they'll try, get told not to, and then idle and do jack [ __ ] until they're fired.

Those three outcomes are the only things that happen when a bad company with bad code hires a great engineer. Historically, that would result in the death of the company or the product. If they can't have any good engineers to fix the thing, then they're left with slop engineers and the product will spiral and die. Now, the LLMs can maintain it. So, that slop sticks around longer than its natural life cycle. There's almost a death of survival of the fittest in software here.

Where software that wasn't in good shape would eventually die because there was nobody there to maintain it, now LLMs will gladly maintain the [ __ ] in the sheer volume of [ __ ] is going to go up exponentially. It's a funny way of putting it, but I really like this. LLMs highlight how essential our human laziness is. Our finite time forces us to develop crisp abstractions in part because we don't want to waste our human time on the consequences of clunky ones.

The best engineering is always born out of constraints. And the constraint of our time places limits on the cognitive load of the system that we're willing to accept. This is what drives us to make the system simpler, despite its essential complexity. As he explained on his talk, the complexity of simplicity, this is a significant undertaking. And we cannot expect LLMs that do not operate under constraints of time to undertake this on their own volition.

This is not to say, of course, that LLMs won't play an important role in our future. They're an extraordinary tool for software engineering, but as outlined in his guidance for LLM usage at Oxide, which is his startup doing compute stuff, they are but a tool. We can put them to use tackling the non-ironic and non-virtuous aspects of programmer laziness, helping us take on thorny problems like technical debt, or even use them to promote our engineering rigor.

He did a whole podcast about using LLMs to make your code better instead of getting it done. It's a very good episode. But it must be in service of our own virtuous laziness to yield a simpler, more powerful system that serves not just ourselves, but the generations of software engineers who will come after us. Absolutely agree with all of this. It's silly to think of it this way, but laziness is so important in how we write software.

It's why software exists in the first place. We don't have to manually do [ __ ] But if we automate out that part, we're just going to end up in hell. And I am thankful we have people like this calling it out without just [ __ ] all over LLMs because it does feel like right now there's a gap between the people who love good clean code and hate LLMs and the people who love LLMs and ship 40K lines of slop in Ruby every day.

That gap is massive. And so thankful that we're seeing people in the middle of it now. It is nice to have old heads hopping in and giving useful perspective on these things. Even Uncle Bob has been diving into AI in a way that I love with wonderful posts like this. What we're losing with AI is syntax and good riddance. The less our brains are occupied by semicolons and braces, the better. There are much more important things for us to consider and manage.

I was so hyped about this that I posted that I'm agreeing with post AI Uncle Bob a lot. Not only did he follow me back after that, he immediately DM'd me asking for my email and I'm still a little scared what he plans to do with that. But I'm also excited to have Uncle Bob on my side now, which is crazy because I've talked a lot of [ __ ] on this man and a lot of the patterns that he has cared about in the past. I would argue that clean code in a lot of ways was the antithesis of the laziness and it fit into that rare over optimization thing that he talked about earlier in the article.

Laziness tries to make systems as simple as possible, but no simpler. That's the key. The attempts to over abstract sucks. And a lot of the patterns that Uncle Bob used to push leaned that way. But with AI, a lot of those details are washing away and that is a good thing. We have to find the balance here. If we don't care about syntax anymore, we have to make sure we still care about bloat and complexity where it is not necessary.

And building in better systems to make better solutions is where we are going. I want to end on a silly note. One of my favorite Cantrell moments ever. And for context, this is about Oracle after Sun got acquired. >> It is it it it's it's crazy um that it's so simple, but it is that simple. And and it became great And by the way, and I've already fallen into this trap here. Do not fall into the trap of anthropomorphizing Larry Ellison.

Um because if you >> [laughter] >> You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize a lawnmower. A lawnmower just does like mows the lawn. Like you stick your hand in there, it'll chop it off. The end. The You don't You don't think like, "Oh, the lawnmower HATES ME." A LAWNMOWER DOESN'T GIVE A [ __ ] ABOUT YOU. A lawnmower can't hate you. Lawnmower, you don't anthropomorphize the lawnmower.

Don't fall into that trap at Oracle. So, and in particular with OpenSolaris, "Oh, THEY WANTED TO KILL OPENSOLARIS." LIKE, "NO, the lawnmower doesn't care about OpenSolaris." The The lawnmower doesn't think about OpenSolaris. The lawnmower can't care about OpenSolaris. The lawnmower can't have empathy. >> One of the greatest quotes of all time. And to pull that back here, the LLM can't care about quality of software. It can't care about good simple abstractions.

It doesn't care. It is a token machine. It takes in a prompt and it outputs code. It does not care about the quality or how long it takes or any other thing related to it. We have to be the ones who care. We cannot expect these other things to do the caring for us. We can only expect them to do the work. And if we don't guide them to the right work to do, they will do a lot more work than they have to and the result might seem like it works, but it will slowly erode at the core.

Similar to how Oracle has eroded and everything that has touched Oracle has eroded alongside it. Except for the legal team, they seem to be doing good. I have said all I have to on this one. Give Brian a follow on Blue Sky if you want to hear more from him. Watch this talk if you're curious about it. It is phenomenal and I reference it all of the time. And as always, stay lazy, keep prompting, and try to build better software.

Until next time, peace nerds.