Featuring

Sponsors

Tiger Data – Postgres for Developers, devices, and agents The data platform trusted by hundreds of thousands from IoT to Web3 to AI and more.

Depot – 10x faster builds? Yes please. Build faster. Waste less time. Accelerate Docker image builds, and GitHub Actions workflows. Easily integrate with your existing CI provider and dev workflows to save hours of build time.

Augment Code – Developer AI that uses deep understanding of your large codebase and how you build software to deliver personalized code suggestions and insights. Augment provides relevant, contextualized code right in your IDE or Slack. It transforms scattered knowledge into code or answers, eliminating time spent searching docs or interrupting teammates.

NordLayer – Protect your business with NordLayer, the toggle-ready network security platform built for modern teams. VPN, access control, and threat protection—no hardware or complex setup required. Get 28% off NordLayer yearly plans this Black Friday with code changelog-28 at nordlayer.com/thechangelog

Notes & Links

📝 Edit Notes

Chapters

1 00:00 Welcome to The Changelog 01:14
2 01:14 Sponsor: Tiger Data 01:43
3 02:57 Start the show! 00:58
4 03:55 Sean's blogging story 01:52
5 05:47 Having something to say 04:14
6 10:01 Do repeat yourself! 02:04
7 12:04 Let's get political (in our orgs) 01:38
8 13:42 Confidence: how? 02:39
9 16:22 How to influence company politics 06:56
10 23:18 Sponsor: Depot 02:49
11 26:07 Emotional Intelligence 04:05
12 30:12 What is good taste 03:58
13 34:10 Agents rock the foundations 05:17
14 39:27 Same stuff, different pile 01:12
15 40:39 The value of code review 02:51
16 43:30 Spec-driven change 01:34
17 45:05 Tools change the game 02:41
18 47:46 Sponsor: Augment Code 01:30
19 49:16 Sponsor: NordLayer 01:39
20 50:55 Mistakes engineers make in code review 04:12
21 55:07 Outsized influence 03:14
22 58:21 Getting the main thing right 06:40
23 1:05:01 The TikTok intern 02:09
24 1:07:10 A high stakes game 01:50
25 1:09:00 How to top Hacker News 04:47
26 1:13:47 Jerod fluffs you up ;) 01:30
27 1:15:16 Everyone's a critic 02:19
28 1:17:35 Wrapping up 00:30
29 1:18:06 Closing thoughts (join ++!) 01:51

Transcript

📝 Edit Transcript

Today we’re joined by Sean Goedecke, who is over there in Melbourne, Australia, and has been blogging like a fiend, like a prolific fiend…

…and I’ve just been like slurping up his blog posts and putting them in Changelog ews. Sean, welcome.

Well, because you are where you are, and we are where we are, we’ll definitely be dealing with a little bit of lag and latency, so hang with us, everyone… I’m sure it’ll get smoothed out in post, but if Adam is telling stories over the top of Sean’s answers, that’s why.

No, I’m blaming the ocean and the speed of light. I’m not blaming you.

Well, let’s get a key and open that room, okay?

There we go. I actually went back, Sean, and checked… In the last 50 issues or so I think I’ve included posts by you in Changelog News, one, two, three, four, five different posts of yours, in like the last… That’s probably a year. At this point I should just put a redirect into your blog, you know? “Welcome to Changelog News. Here’s Sean.” You’ve been killing it, man. Where do you get all these blog posts from? Where are you pulling them out of?

Yeah, that’s a good question. I’m not quite sure myself. So I didn’t write for the longest time. I didn’t write for the first eight years of my career. And then all of a sudden, in the last two years, I find myself having a lot of things to say. I think it’s kind of self-reinforcing, in a way. It’s easy to feel like you don’t have a unique perspective to add. But if you write one thing and people like it, it makes you more likely to write other things, and it kind of just keeps going like that.

It all kicked off for me with a post I wrote about how to ship projects, maybe a year ago. And I wrote that out of frustration with people I’d worked with in the past, and people I’d seen work, engineers who were treating the shipping part as like an afterthought, and they sort of felt if they wrote all the code and they completed all the JIRA issues, then the project would be done, and that’s how projects work. And I felt and feel now pretty strongly that that’s not how projects work. So I wrote a blog post about that, and it hit the top of Hacker News, and got really popular, and it kicked off a whole bunch of stuff… And I thought “Well, okay, if people enjoyed reading about that, I have a lot of other things to say. I’m a pretty opinionated guy.” So I kind of started writing more from there, and it turned out to be, I think, a pretty good fit with the kind of people who want to read blog posts about tech… Which is mostly just luck.

I do find that having something to say is obviously the barrier to entry, right? I mean, you have to have something to say, to say something, right? That’s pretty clear for everybody. But then there’s also the exercise and the discipline to just show up and do. You mentioned in the pre-call that you’ve got a lot of drafts… We mentioned that we’re going to talk about your blog primarily, and obviously the wisdom you’ve shared in that blog… But break down kind of how you approach, the pragmatic approach to showing up and actually executing.

Yeah, sure. So I don’t see myself as a particularly disciplined guy. Like, I don’t have the kind of three blog posts a week, rain or shine, got to hit my deadlines, got to do the thing every day. I don’t have that at all. What I do have, I think, is a pretty good sense of how I like to work, and I’m pretty opportunistic about how I kind of exploit my own peculiarities about work… So I have – instead of sitting down and working on a blog post and just grinding it out, I’ll have like 13 drafts on the go, 13 kind of rough ideas… And often, most of my blog posts come not from a draft that I’ve been grinding on, but as I’m working on a draft, as I’m writing things down, I write this sentence that’s like an unrelated point, and I think “Oh, that’s actually kind of interesting.” And then I just sit down, write top to bottom a blog post about that sentence, post the blog post, and that’s it.

Some of my drafts, I think, will never see the light of day. They’re just kind of like breeding grounds for kind of other interesting ideas. And often, it’s like – you say that having ideas is the barrier… Well, I think people have more ideas than they imagine. Every time you get annoyed at like a coworker or annoyed at something you read on the internet, that’s an idea. That’s something you have that’s maybe a little bit controversial, or certainly an idea that not everybody shares. And a lot of those, I think, are kind of worth writing up. That’s how many of my blog posts start, where I read something and I think “Well, that’s silly”, or “That can’t possibly be right.” And then I go and write about it to kind of convince myself whether I’m right or wrong. And that ends up being a blog post.

The reason when I wrote about 95% of projects failing I think is a good example of that… Where I read a bunch of tweets saying “Oh, 95% of AI projects fail at large enterprise companies. This proves that AI is in a bubble.” Well, no, it doesn’t. You have to go look at the base rate of how many complicated enterprise IT projects fail. And the base rate is pretty close to 95. So that’s what I suspected, and then I went and did a bunch of reading about it and wrote it up. That’s what I think is the case.

[00:08:22.03] Yeah… Well, let me clarify, just in case that was a little off in what I said. I can’t rewind and determine exactly what I said, but… Having something to say is different than having ideas. I think that you can have ideas, but I think having something to say is like being down the road a bit, and having some version of experience or wisdom. And I kind of pull this, oddly enough, from a movie… We mentioned in the precall - listeners, you’ll get a little taste of it in the after show, potentially… But I pull this from this movie called A Star is Born. It’s the most recent iteration of it. It’s been a couple versions of it before… Barbara Streisand, I believe, was the most recent one… Well, I guess the most recent one compared to the current one. But in there, the kind of main character - I believe it was Bradley Cooper - telling Lady Gaga, who’s his co-star, he says “You’ve got to have something to say. It’s about being an artist, and in particular being a singing artist, a performing artist.” And I took that to heart, because I was like “You’re right. You can have ideas out the wazoo.” Right? Sure. We’ve all got ideas. But having something to say is different than just having ideas. And I think you have something to say.

I appreciate that, firstly. Thank you for saying that. And yeah, I do agree with you, I think, and it ties into how I didn’t write much of anything at all for the first seven, eight years of my career. And I think partly that’s because - yeah, maybe I didn’t have anything to say. And I’m still 10 years in, it’s still pretty early to a career. I’m sure my opinions will evolve. But yeah, there’s a sense in which like everything I write is the same thing. I’m always making the same points. And one thing I had to get over, I think, in my early few posts was I felt “Well, I can’t write this. That’s just saying what I’ve said before. I can’t say this, I’ve already made this point.” And I kind of had to get over that in order to keep writing, and I had to kind of convince myself that continuing to articulate my perspective is worthwhile and interesting, even if it is just continuing to articulate my perspective. Even if these points aren’t kind of new to me.

I mean, I have a hundred times where I’ve written “Engineers should be more mindful of how the organization functions, and they should see their role as more than technical.” I’ve made that point in a hundred different ways, and I’ll continue to make that point. I guess that’s part of what I’ve got to say. Maybe if you have something to say, you’ll just keep saying it forever, until people get sick of it.

And it’s well said, because we do - I’m saying ‘we’, but I do sometimes discount, or do not want to repeat the same thing over and over again, because you think “Well, I’ve already said that. It’s not interesting anymore.” You want something fresh… It’s not a fresh take, it’s the same old take. But now that we’ve been podcasting for so many years, Adam, I’m sure we say the same things over and over and over again.

And that’s really how you get a message out. I mean, there’s a reason why I call it beating the drum, is you’re just – it’s the same beat every single time. It’s just like, people aren’t listening. Different people, different mind spaces… They’re not ready to hear it…

Time changes… And eventually, the message gets out. You can’t actually say something just once, in the world that we live in, unless you already have a gigantic microphone, or it’s very bombastic, and have it resonate. Like, you do have to actually say the same things in different ways, to reach different people with those messages. And so if you do want your opinion out there, don’t feel bad about saying it more than once… He says to himself.

What are some of the other things you’ve been saying over and over again? So I liked that one: “An engineer must be aware of the politics or the…”

[00:12:10.27] Yeah, it’s broader than the technical engineers ought to be aware of the politics of the organization. And broader than that, one thing I’ve said over and over that I think is a bit more controversial is that senior engineers specifically ought to be heavily involved in the politics of their organization. It’s a dereliction of duty if you’re a senior engineer and you’re like opting out of these political decisions about how the team should function, and what the team should do. It’s your responsibility to kind of bring your technical expertise to those discussions.

And part of that, which again is a point I’ve made over and over, that a lot of people don’t like hearing, is that you want to be confident in the workplace as a senior engineer. You want to be more confident than you feel internally. A huge part of the job is being more confident than you feel internally. If you’re in a conversation and you’re best positioned to know the answer to something, even if you don’t feel confident about it, you ought to represent that answer to the organization, because nobody else is in a better position to do so.

Anybody who has to make a difficult decision is going to be kind of dealing with their own uncertainties about it… And if you’re in the best place to make that decision, it’s your responsibility to deal with your own uncertainties, and not simply to be a technical kind of “Well, it could go either way. There’s lots of risks. I wouldn’t like to say for sure.” No, no. If you’re a staff engineer, you ought to say “This is the direction we should go. This is what I believe.” Otherwise you’re not doing your job.

So to those who might say “I get it, Sean, I’m supposed to be more confident in my position… But I’m not.” How did you and when did you acquire and accrue the confidence necessary to be confident?

I don’t know if I have good advice on that front. I think I’m naturally very confident in my own ideas… So I wouldn’t like to tell people steps that they could take to do that when I didn’t follow any steps myself. That’s just kind of a fortunate a fortunate way in which my personality fits, I think, the tech industry.

But in general, I haven’t always been confident about tech, specifically; a lot of it was just time, and years working in the same industry, solving similar problems, seeing the same things crop up… Particularly if you’re fairly new to the industry and you’re not confident, I wouldn’t worry about it. I would assume that in 5 years, 10 years, you might get there.

Yeah. Confidence as well, because you kind of have to get on the road a bit, and you kind of have to make mistakes… And when you’re new, you’re like “Oh, the last thing I want to do is make a mistake, because I might get fired, or I might be seen as less valuable”, or “I really am not an engineer.” And we continue to perpetuate this imposter syndrome, which even 20 years in I still feel on the daily. I’m a little bit more confident about my awareness of it, but I still feel this level of imposter syndrome… Maybe even in this moment, I don’t even know. But to somebody new coming in, you have almost no perspective, so you can’t really blame yourself for not having strong opinions or confidence, because you have no reason to have confidence yet.

Yeah, that’s absolutely right. I think there’s a sense in which in tech it’s almost easy to gain confidence quickly, if you’re working as a software engineer… And that’s because codebases are so complicated, and are so different, and contain so much accidental detail that if you’re even a fairly junior engineer working on a codebase, as you become familiar with that codebase and able to ship changes, you will rapidly have more technical familiarity with that codebase than even very senior engineers in the organization. In your narrow domain you’ll have much more ability to kind of answer questions confidently, and say “No, this is how it currently works. Here’s where you’d want to make that change”, those kinds of assessments. So I think like there’s a sense in which kind of working as a software engineer gives you narrow domain confidence fairly early on, assuming you do stay in the same codebase for long enough to get it.

[00:16:21.23] So let’s zoom in on that post about company politics, since that’s kind of the topic that we’re on right here. You have the confidence, you’ve gotten to become senior enough that you know that you have good things to say, and good direction with regard to where the company should go, how the company should operate… Maybe it’s which features are worth developing or not, or how to go about building things… You wrote “How I influence tech company politics as a staff software engineer”. I guess, side note, Sean is a staff software engineer at GitHub, for those who don’t know… And this was back in October. Do you want to walk us through some of – maybe the bullet points, or the high points of actually how you go about effecting change inside the org that you work in?

Yeah, sure. And I want to preface this by saying that my experience has been with large orgs, whether it’s 10, or 20, or 30 engineering teams… So the advice I give is probably not as relevant to smaller companies or startups. But certainly in large orgs, kind of paradoxically, the process of influencing company politics begins with accepting that you’re never going to set the direction of the company. It’s just too big, the decisions are being made at too high of a level, with information that you straight up don’t have.

I’m a staff engineer at GitHub, I’m not going to be able to point GitHub the company in a different direction, and certainly not going to be able to point Microsoft the company in a different direction. Very, very few people are in a position to do that. But what you can do is you can influence your local politics. And I don’t mean kind of the company like strategic decisions here so much as I mean the technical decisions about what technologies get chosen, what projects get funded, that kind of thing. And the way to do it - well, there are two ways. The first way is like the hard way, the kind of traditional way, where you have an idea that you want to do, some project you want to build, some feature you want to ship, and you just kind of campaign for it like normal. You write a proposal, you talk about it at talks, you try and convince people, you talk to your manager, you talk to your skip, you’re drumming up support for this idea… And that’s very hard. It can work. I’ve seen it work. But it requires a lot of persistence, and it’s usually less sticky.

The easy way to influence company politics is to - instead of having one idea that you’re pushing, have a kind of stable of ideas that you have ready to go at any given moment. And then when it becomes time for that idea, you’ll have something you want to do in the bag already. And when I say time for that idea, companies kind of go through what I like to think of as these waves of interest in different areas. So suppose you have a couple of ideas about how to make the service you’re working on more reliable. Maybe you want to do cross-region stuff, or multi-cloud stuff, something like that. It’s going to be pretty hard when the company is interested in shipping features to push this big reliability project idea. But in the aftermath of, say, Amazon’s recent incident, or perhaps an incident affects your company, there’s usually a month or two where people really care about reliability. And it’s even coming down from on high, where your VPs, your directors, your managers are looking for reliability projects to fund. And if you’re already there with a couple of reliability projects in your back pocket, you’re in a position to very easily make those happen, because they’re no longer your projects that you’re championing; they become your directors or your VPs projects, that they’re championing. And so you can get what you want done very effectively, as long as you’re willing to wait for the right time. That’s the kind of process that I’ve used, and it’s worked very well for me… But it does require you at any given moment to have brief write-ups on 10 to 15 things that you want to see happen.

[00:20:18.09] Well, I don’t have anything to add on that one, Adam, because I’ve never been in a large organization. So I can just take Sean’s words as gospel truth, I guess, that it just works. I can’t even push back, or anything. How about you?

I can definitely resonate with the having many ideas in the bag sentiment, because I think I kind of – you know me, Jerod, I kind of do that. I kind of have this smorgasbord of things that have just been interesting to me, and I think it really is just timing. So I can resonate with that, at least, but I can’t really resonate with the large org lack of control, really fool’s errand of trying to influence change at the biggest scale without being CEO. As an IC, that kind of makes me sad that that’s the case… But I like the – you kind of have to not go into those scenarios or those kind of employment opportunities with a control freak mentality… Which I don’t think I have, but I do like controlling things. And so it would be challenging for me to be in a large org, I suppose, given that sentiment. I hadn’t considered my inability to change the future of things, because I just – I’m a future changer. It’s just – it’s my DNA, it’s how I work… And that’s kind of where I focus at. So if I can’t do that, it might be disappointing for me. Ideas, for sure, though.

That’s a really interesting point. One theme I get a lot in emails and messages from readers is that I’ve helped them feel less sad about working for large enterprise companies. I’ve helped them reconcile themselves to their roles as cogs in the machine… Which - I don’t know if I would have picked that as my mission in writing, but it certainly seems to be something that my blog posts are doing. And that definitely is another theme of what I write, which is that… I don’t know, I didn’t come to the industry from tech. I don’t have a computer science background. I have a background in academic philosophy. I did a master’s in moral epistemology, and then transitioned to an internship in tech. So I think I lack some of the high mindedness about tech that many of my colleagues have, and I do kind of fundamentally see it as labor… And it doesn’t rock me to perceive of my job as being subordinate to capital, because I kind of always imagined I was subordinate to capital, and always will be subordinate to capital in the current system.

So there’s a sense in which how I think of making technical decisions in large organizations is kind of flowing on from this kind of broader political commitment to – you know, there’s just not that much you can do about the broad structure of capitalism. You just kind of have to exist in it as best you can.

Break: [00:23:18.25]

Do you know the term emotional intelligence? And if you do, do you think that you are a relatively strong emotional intelligence person?

I do know the term emotional intelligence. If you’ll forgive a brief digression - I have two dogs, I have two greyhounds. One of them is a complete maniac, and the other is a giant baby, a big boy. Not very smart, but my mom, who’s head over heels in love with the dogs, likes to say that he has great emotional intelligence. That’s what she always says when he does something stupid. He’s like “Well, he’s very emotionally smart.” That’s kind of where he’s at. [laughs] I had to say that, I’m sorry.

About myself - no, I don’t think I have particularly great emotional intelligence. I don’t think that’s one of my strengths. But what I do have in that area, I think I’ve come to via analysis, by kind of thinking through it carefully, which I don’t think is how you’re supposed to do it, but… I don’t think it comes particularly naturally.

You’re augmenting the EQ for the IQ.

Yeah, although I don’t know if I have great IQ either. I think I just have a lot of persistence when it comes to thinking about the same problem for years.

The reason why I bring that up is because I’d actually talked to a fellow just last night, as a matter of fact… My son does ninja training; not like ninja fighting, but like ninja, American ninja warrior. I think it’s also become popular in other countries, that’s where I kind of became aware of it… But like ninja skills, parkour, this athleticism that’s just uniquely different than any other sport. And one thing that the guy that runs the place shared with me last night in regards to being an athlete - I think this is a sentiment you share in your blog posts, which is why I bring it up, is this idea of like working on your mental fitness more than just simply your athleticism. Because it seems, like you say, sure, you can have technical skills, and you can understand a programming language, and you can understand TDD, or whatever it might be that makes you a good software engineer. But then you also have to have this mental toughness, this mental clarity, maybe even emotional intelligence, this working on your mind fitness… And that’s something I’ve seen in your blog posts, where you seem to suggest being mentally fit - and I don’t mean not crazy, or being off the norm path, but mostly just the mental toughness and the mental game more so than just simply the skill game.

That’s really well put, and that’s absolutely correct. Before I even blogged like I do now, maybe eight years ago, one of the really, really early blog posts I wrote, called “Avoiding Worry-Driven Development”, and absolutely most software engineers I’ve worked with have not been primarily held back by a lack of technical skill… To the extent that they’ve been held back, it’s been by lack of emotional regulation. And there’s all kinds of ways this can happen. It can happen even really subtly, where you become afraid to work on things that you might get wrong. You become afraid to, for instance, deploy, or to make changes that could be risky.

So you might be technically very capable, but there are certain kinds of technical change that you’re just not really willing to do, that you’re like letting other people do who maybe don’t have your technical expertise, which - that can really hurt a team. But yeah, there’s more ways than I could articulate where kind of poor emotional regulation makes you a worse engineer. I think I’m going to continue writing about that for a long time.

[00:30:04.03]

Jerod here in post… Just wanted to let you know that Adam had to step out unexpectedly. So when you don’t hear from him for the rest of the show, that’s why.*

One thing I want to talk about, which is tangential to this, is taste. I think, especially with the rise of AI code gen, we are seeing now that our ability to have and to influence good taste in software engineering is becoming more valuable, and our ability to execute the technical bits by hand becoming less valuable. And so you wrote on this - this is one of my favorite pieces that you’ve written of late… “What is good taste in software engineering?” Because of course, I can just assert that we must have good taste, and we all like our own taste to a certain extent, don’t we? …and so we assume that we all have our own good taste… But how do you know if you do? How do you know what it is? What does it even mean, good taste in software engineering? And in this post, you really try to get down to the nitty-gritty of answering those questions. And the way you go about that is by really proxying taste to values. Can you start there, and explain kind of what that means? Why your taste comes from your values, and how we can actually decide what our values are.

Yeah, sure. So this approach definitely comes from my background in analytic philosophy, where if we’re not sure what something is, we often try to do what we call conceptual analysis on it, sometimes I think a little bit bombastically, called conceptual engineering… [laughs] Perhaps much like software engineers call what they do software engineering… It’s a little bit aspirational.

But the idea is to take this kind of concept that you’re not sure about, like taste, and try to explain it in terms of another concept that you have a better handle on, in this case values. So really, you’re starting from this point where people use the word taste to mean a lot of different things; perhaps they’re not sure what they mean themselves when you get down to it… But if you look at taste as an expression of your values, a lot of things become hopefully a little bit easier to understand.

And by values I don’t mean necessarily your ethical values. I mean the things you care about when you sit down to do software engineering. So for instance, you might care about reliability, you might care about performance, you might care about accessibility, you might care about having your code well factored, you might care about having your code not be spread in too many different places… You can list these kind of things forever. And I call them values because I think there aren’t definitive answers to a lot of them. Exactly how important is readability compared to reliability? Well, it depends on the situation, and it depends on you. It depends on what you value personally. So I think most software engineers, they end up with this kind of constellation of values where they really care about reliability, they care about accessibility a little bit, or perhaps the other way around… It’s sort of what they’re willing to trade off and what they’re not willing to trade off.

When somebody’s sort of set of values match your set of values, you might say they have good taste… I take it one step further, I say that your set of values can be a good or bad fit to the project you’re working on itself. And I say that when your set of values is a good fit for the project you’re working on, that’s having good taste. And the ability to kind of be a bit flexible about your values to fit the project you’re working on - I think that’s the ability to have good taste in general. Which is - if you’ll forgive the reference… It’s a very Aristotelian kind of way of looking at it, where the good person, for him, the good man, has this ability to fit his taste to the exact situation with a nicety. I think the same thing kind of applies in software engineering. It’s about being responsive to the particulars of the situation.

[00:34:10.01] Well, that’s interesting. I’m finding that my own values - and I do think that fitting them to the project is smart… I think that’s a good way to go about it, because that’s ultimately what you’re there to serve, is what you’re currently working on… Not necessarily yourself, or some sort of ethical high ground. Although there are, I think, values that people consider foundational, and they aren’t willing to budge on certain values, and I think that that’s a fair way to stand in the world… But man, I’m sure seeing certain values that I’ve held for many years - so I’ve been in the game, Sean, for two decades, writing software. And not in large organizations like yourself, so we have different perspectives from that. Always small teams. Lots of times by myself. And I find that because of the advent, specifically in the last six months even, of coding agents that have gotten to be good enough that I’d rather use them than write myself, even though I love writing software, and I still feel like I’m writing software, but I’m not just doing the writing anymore - I feel like some of the values that I’ve considered bedrock for years of myself are starting to maybe change, or like I’m ready to change them… Because maintainability - okay, in the small; not in a large, but in the small - seems like… Is it all that important? Or will it be all that important, when a rewrite is 10 seconds away, by a skilled developer? And I’m not saying it’s here today, but I’m just seeing the trajectory, and I’m just wondering if all my values are going to change. Have you had any sort of those thoughts as this stuff is starting to percolate? Because it’s getting to be pretty good at this point, and I imagine it’s not going to get 0% better from here.

Yeah, absolutely. I mean, you would have more context on this than me having been in the industry longer, but certainly for me the last three years and the last year even have been the largest, the most rapid time of change I can recall for my entire time in the industry. And not even just because of AI. I mean, since 2023 with the death of the zero interest rate regime - this is also something I write a lot about - what it means to be a software engineer has completely changed. And now with the advent of genuinely capable AI agents writing code, it’s changing again. And it’s sort of continuing to change.

And yeah, a lot of the old ways of thinking about things no longer apply. You almost want to list the things that haven’t changed, because the change has been so extreme. Although I do think it depends where you are. One thing I believe is software engineering is – there’s so many different types of work wrapped up in it. And there’s definitely people who are working on things for which AI agents are still not yet a good fit, or not yet good enough.

And I think a lot of those engineers kind of look at discussions like these and they think “What are these people talking about? AI agents are just not there yet.” But for somebody like me, who works – a lot of what I do is kind of web servers, and protobuf mangling, and fairly standard kind of forms of software engineering work… The AI agents are here, man. They’re certainly good enough to help, and in many cases they’re good enough to do the entire work. And it’s completely changed what it means to do the job.

Yeah. I’ve even experienced that in my own work where there’s certain areas of what I’m doing, specifically using - I won’t say bleeding edge, but just like modern frontend technologies, and specifically CSS technologies, SVG etc, where I find that they completely lack the ability to do what I want them to do.

[00:38:02.06] And then I’m doing something else, writing some sort of static generator in Go, and it’s like “I didn’t write any of this code.” I’ve helped it refactor along the way, but it’s totally capable of doing this with just a little bit of direction from somebody who knows what they want, and they have some taste in the way you should go about building the system, to just like guide and say “No, don’t do it that way. Do it this way.” They’re like “Okay, I’ll do it that way.” And in those areas, it’s very capable.

And so yeah, it’s just not evenly distributed, both in like technology, and like verticals, but then also across the industry and what you’re working on. Everybody’s mileage is going to vary, and I think we’re getting very small mileage right now, and I just can’t imagine that it’s going to stay right here… Because I’ve been calling the AI winter for a little while, and the plateau, and every time I think we’ve hit one… Granted, a lot of it’s been tooling around the models that’s been getting better, more than the models themselves right now… But I just know how much investment is in making this get better, and so it’s just like… It’s like percolating and pending. And so a lot of my hard-earned values and beliefs are kind of like teetering right now. Like, “Slow down to go faster” I’ve been saying for years, and it’s like, I don’t know, maybe it’s just “Go faster to go faster” now. Or at least it will be in a couple of years. I don’t know.

Yeah, your example is really interesting to me, about needing to write your own sort of CSS, and SVG code, but having the Golang stuff be automated… Because to me, it’s been almost the reverse.

Yeah, I’ve kind of used AI agents to write most of my frontend stuff, certainly for my blog… But at work, sometimes when I’m writing Golang code, I find that I have to kind of do it by hand, because the agent’s not quite there yet for what I want to do. But I think that kind of just reflects, you know, you’re going really deep in one area and I’m being very shallow. And when you’re writing your Golang static site generator, that’s a fairly well understood problem. And when you’re doing things that are less well understood, it’s just kind of like “Yeah…” It’s not so much that it’s good at one technology and bad at another, it’s just kind of hard to… You know, you can be doing very different things.

But to your broader point, I absolutely agree. I think there’s going to be a new set of engineering values that comes in when this technology stabilizes… And it’s very hard to say in advance what those values are going to be. I mean, how much engineers are going to need to manually review the work of AI agents as well, I think, for instance, is still very much up in the air.

Yeah, that’s a really big question, is how much – right now it’s made code review extremely valuable, right? Your ability to look at a written piece of code, whether it’s from a human or an agent or whatever, and judge appropriately “Is it good enough? Does it need to be rewritten? Where are all the problems with this? Is it going to pigeonhole us? Is it fine?” That, I think, is peak software engineering skill today, and maybe it will continue to be. I mean, there’s people that don’t think that the agents are going to get very much better at all from here… And if they stay right where they are, it’s absolutely a huge value. Maybe not – so readability, I should say then, is a value that’s going nowhere, right? But if we get past this threshold of what we actually have to care about is the inputs and the outputs, and we don’t ever have to read it, or very rarely… It’s like, readability is for the birds at that point. Who cares? It was a means to an end. So just so much as just weighing in the balances right now is kind of unnerving.

[00:41:45.23] I do think readability is never going to go away. I think it may go away for like Python and Golang and JavaScript, but I think if it does go away there, it’s going to kind of recede back into the prompt, in a sense. So for instance, writing readable, coherent assembly code used to be part of the skill of any programmer. When compilers got good enough, that kind of stopped becoming part of the skill set, and instead you just had to write readable C code that would compile into assembly, and you didn’t care what the assembly looked like, or whether it was readable. We might be heading towards a world where you don’t care whether your Python or JavaScript code is readable. But I think in that world, you’ll still care a lot about whether your prompt is readable, or whether the instructions you give to the agent is readable.

Some people are saying - and I don’t know if I believe it, but some people are saying that English is kind of the new programming language, that your expression of the spec is sort of your programmer work product. And whatever it is that the programmer or whoever is giving to these AI agents, I think it’s always going to be important that that’s readable. It’s always going to be important that that’s understandable by humans, because humans are going to have to update that when they want changes to be made to the product.

Yeah, 100%. And we definitely see that being formalized in things like spec-driven development at this point… Although we’re not at the point where you write the spec and that’s all you write. You’re still going beyond the spec, but maybe we get to a place where all we’re reading are specs and user stories, and stuff like this. I think that’s kind of a bland, boring world myself, because… Gosh, I mean, I don’t like writing documentation today. A spec is a necessary evil, to a certain degree… Whereas for some reason - and maybe it’s just because I’ve been writing code for so long - I’d much rather read and write code than read or write specs. But I guess we do have to change with the times, don’t we, Sean?

Well, we’ll see. I mean, the ideal specs for AI agents might end up looking a little bit like code. They might end up being kind of technically specific enough to… But I think it’s hard to look at the future and say it’s getting less interesting to be a software engineer. I mean, the last three years have been a period of such intense change… Whatever you might say about it, it’s very interesting to be a software engineer now. There’s a lot of things going on.

It’s very interesting right now.

For good or ill. So yeah, maybe we’re headed towards a world where it’s much more boring to be a software engineer, but certainly, if it continues like it has been, that’s not what’s happening.

Yeah. Well, it’s a bit ironic that what these things seem to be best at are the most artistic aspects of white-collar work… Whereas we were hoping that they would do the dishes and the laundry, instead they’re doing the art and the videos and the code. We’re writing the docs and they’re writing the code. I’d prefer if they wrote the docs and I got to write the code. But you know, I guess take what you can get.

It’s the great paradox of working with large language models, that they’re terrible at the things that ordinary computer programs are really good at, and they’re really good at things that ordinary computer programs are terrible at. It’s a different way of doing it.

Yeah. Well, that’s where the advent of the tool has been so amazing. Again, when I talk about the software around the models getting so much better, the fact that GPT-5 can’t do – they can’t count how many R’s are in strawberry, or whatever, famously… But it doesn’t have to now. It knows that when a certain set of things it’s not good at, it’s going to actually shell out effectively to a Python program or whatever it is, or Perl in the case of maybe counting the number of R’s in a string… Which is going to get it right quickly and every single time, and then it’s going to use that response. That was such a sea change, I think, where it’s like, they don’t have to be good at everything. In fact, we can limit the domain that we use the models into this very narrow corridor, and then just equip it with all the tools it needs to get the answers. And that’s where I think we’ve gotten in the last year or so where it’s like “Okay, this is really good now.”

[00:45:58.29] Yeah. I mean, this is something that – this was anticipated, for sure. I think in 2020 Leopold Aschenbrenner wrote “Situational Awareness.” Maybe not 2020. Check that. But years and years ago, long before AI was the thing that it is today. And one of the things he wrote about in that was what he called unhobbling, which is the idea that even if – once you have a really strong model, you can improve the system without improving the model, because there’s so much scope for making the tool better; giving the model the ability to like do things, and then act on those things… There’s been so much engineering work in systems like Copilot Agent, Cursor, Claude Code, Codex… All of these things. And that’s why I’m kind of skeptical of an AI winter, because even if the models stop getting better, which they might, there’s so much clear low-hanging fruit to be picked in the tooling.

Yeah. That’s a good call. And had I known about the tool calling as an option back in 2020, I wouldn’t have been calling for this plateau so easily… Because I just wasn’t seeing the models get that much better and I kept thinking “Okay, we’ve hit a plateau. We have to move beyond transformers to a new paradigm.” But no, you can just keep equipping these things, and narrowing their scope, and allowing them to – what did you call it? Situational awareness? To know when to call a tool, and then just make the tools better, better, better, better, and more context etc. and you get huge wins from that without having to have any sort of transitional step change in the actual abilities of the model. So I did not see that coming, but apparently I should have, had I read that particular paper. Or I don’t know, maybe you were writing about it back then and I didn’t read your blog back then.

Yeah, okay.

Break: [00:47:47.06]

Assuming that code review stays relevant, you wrote a good post called “Mistakes I See Engineers Making in Their Code Reviews.” I think it was back in September. And I think that’s something that our audience would certainly love to hear, because code reviews right now is such a valuable skill, and doing it poorly is not good for your career. So what are mistakes that people are making, and how can we make our code reviews better?

Yeah, sure. So this was a pretty opinionated post I wrote, and I was honestly shocked that the reception was so positive. I thought people would be very negative on it. So maybe it’s less controversial than I think… [laughs] But the idea that I have here is that – well, one, you shouldn’t leave many comments. This is a thing that I think happens a lot, particularly in these big tech companies, where you’ll have code reviews that have 50 or 100 comments sometimes. And I think that’s just an order of magnitude too many. A good code review should have like six comments or fewer… Because you just can’t track more than those things. There’s no way you have more than six interesting things to say about a pull request. Past that, it just becomes kind of line item comments. And the problem with line item comments is that they suck up all the attention that should be spent on a higher level discussion.

So instead of commenting in 30 different places and saying “Oh, here you’ve used map filter where you should be using reduce… You should leave one comment saying “This is a pattern that you should adopt.” And that way the person can kind of like treat it a bit more holistically. That’s something I believe.

The other thing that people do, I think, is that when they review a pull request, they read through the diff and they review the diff. And I think that’s a big mistake. I think the most interesting and most useful comments you can give in a code review are not about the diff. They’re about the code that wasn’t written, or the areas of the codebase that haven’t been touched, that ought to have been touched.

The highest value code reviews I’ve ever seen have been comments like “You