The Changelog: Software Development, Open Source - DO repeat yourself! (Interview)

Episode Date: November 12, 2025

Prolific software blogger, Sean Goedecke, joins us to discuss why he believes software engineers need to be involved in the politics of their organization, how to avoid worry driven development, what is "good taste" in software engineering, where agentic coding will take our industry, why getting the main thing right is so important, and how to get your blog to the top of Hacker News.

Hello and welcome. I'm Jared and you are listening to the change log, where each week we interview the hackers, the leaders, and the innovators of the software world to pick their brains, to learn from their failures, to get inspired by their accomplishments, and to have a lot of fun along the way. On this episode, prolific software blogger, Sean Getakie joins us to discuss why he believes software engineers need to be more involved in the politics of the organization. How to avoid worry-driven development?

What is good taste in software engineering? Where a gentic coding will take our industry? Why? Getting the main thing right is so important. And how to get your blog to the top of hacker news. But first, a big thank you to our partners. At fly.io, the public cloud built for developers who ship. We love fly.

You might too. Learn more at fly.io. Okay, Sean Get a key on the change log. Let's do it. Well, friends, agentic progress is here. And it's from our friends over at Tiger Data. This is the very first database built for agents, and it's built to let you build.

faster. You know, a fun side note is 80% of Clod was built with AI. Over a year ago, 25% of Google's code was AI generated. It's safe to say that now it's probably close to 100%. Most people I talk to, most developers I talk to you right now, almost all their code is being generated. That's a different world. Here's the deal. Agents are the new developers. They don't click. They don't scroll. They call. They retrieve. They parallelize. They plug in your infrastructure to places you need it to perform, but your database is probably still thinking about humans only, because that's kind of where Postgres is at. Tiger Data's philosophy is that when your agents need to spin up sandboxes,

run migrations, query huge volumes, a vector and text data, well, normal Postgres, it might choke. And so they fix that. Here's where we're at right now. Agentic Postgres delivers these three big leaps, native search and retrieval, instant zero copy forks, and MCP server, plus your CLI, plus a cool free tier. Now, if this is intriguing at all, head over to tigredata.com, install the CLI, just three commands, spin up an agenti postgres service, and let your agents work at the speed they expect, not the speed of the old way. The new way, agenti postgres, it's built for agents, is designed to elevate your developer experience and build the next big thing. Again, go to tigurdata.com to learn more.

Today we're joined by Sean Gedeki, 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 post and put him in Change Dog News. Sean, welcome. Hey, great to be here. 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, you know, telling stories over the top of Sean's answers, that's why. Blame me. Blame me. No, I'm blaming the, 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 Change Dog 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 Change Dog 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, oh, 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. Like it all kicked off for me with a post I wrote about like 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'd completed all the jury 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, you know, kicked off a whole bunch of stuff. And I thought, well, okay, like 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 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 like 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 like 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 right top to bottom, a blog post about that sentence, post the blog post, and that's it. So 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. Like 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. Yeah. 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 the pre-call, 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, is Bradley Cooper, and Lady Gaga, who's his co-star, he says, you got to have something to say. It's about being an artist and in particular being a singing artist, like a performing artist. And I took that to heart because I was like, you're right. You can have ideas at the wazoo, right? Sure,

we 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. Thank you for saying that. And yeah, I do agree with you, I think. And it ties into how, like, I didn't write much of anything at all for the first, you know, 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. Like, 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 like 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 like 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 like 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, you know, 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. And if you have, maybe if you have something to say, you'll just keep saying it forever until people get sick of it. It's well said because we do, or maybe I'm speaking, 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 like, 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. For sure. 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, you know, it's the same beat

every single time it's just like people aren't listening different people different mind spaces right they're not ready to hear it time changes and eventually the message gets out but 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 I 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 in Oregon? So I like that one.

An engineer must be aware of the politics or the... Yeah, as broader than the technical engineers, or to be aware of the politics of the organization. And broader than that, like one thing I've said over and over that I think is a bit more controversial is that engineer, like senior engineers specifically ought to be heavily involved in the politics of their organization. and that 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 ought 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 your best position 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. Like, 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, you know, 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.

It's just kind of a fortunate way in which my personality fits, I think, the tech industry. But in general, like, I haven't always been confident about tech specifically. a lot of it was just time and, you know, years working in the same industry, solving similar problems, seeing the same things crop up, like, particularly if you're fairly new to the industry and you're not confident. I wouldn't worry about it. I would assume that, like, you know, in five years, 10 years, like, 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, you know, 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 code base, as you become familiar with that code base and able to ship changes, you will rapidly have more technical familiarity with that code base than even very senior engineers in the organization. You'll have, 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 kind of assessments. So I think, like, there's a sense in which kind of working

as a software engineer gives you like narrow domain confidence fairly early on, assuming you do stay in the same code base for long enough to get it. zoom in on that post about company politics since that's the 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 in 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 the maybe the bullet points or the high points of actually how you go about affecting 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 where there's, you know, 10 or 20 or 30 engineering teams. So the advice I give is probably not as relevant to like 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 to 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, because it's the kind of traditional way, where you have an idea that you want to do, you know, some project you want to build, some feature,

you want to ship and you just kind of campaign for it like normal, you know, you write a proposal, you talk about it at talks, you like try and convince people, you talk to your manager, you talk to your skip, you're like 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. 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, I don't know, cross-region stuff or multi-cloud stuff, something like that. It's going to be pretty hard, like, when the company's interested in shipping features to push this, like, big reliability project idea. But in the aftermath of, say, Amazon's recent incident, or perhaps an incident affects your company, there's usually, like, a month or two where people really care about reliability. And it's even coming down from, like, on high, where, like, your VPs, your directors, your managers are looking for reliability projects to fund. And if,

if you're already there with a couple of reliability projects in your back pocket, you're you're in a position to kind of very easily make those happen because they're no longer your projects that you're championing, they become your directors or your VP's projects that they're championing. And so you can kind of like get what you want done very effectively as long as you're willing to wait for the right time. And that's that's the kind of process that I've used and it's worked very well for me. But it does it does require you at any given moment to have like brief write-ups on like 10 to 15 things that you kind of want to see happen. Well, I don't have anything to add on that one, Adam, because I've never been in a large

organization, you know, so I mean, 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, Jared, I kind of do that, you know, I kind of have this, you know, smorgas board of of things that have like just been interesting to me and I think it really is just timing. So I can, I can resonate with that at least,

but I can't really resonate with the large org lack of control. Really a fool's errand of trying to influence change at the biggest scale without being CEO. As an I see, I just, 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, I do like controlling things. And so it would be, it would be challenging for me to be in a large

org, I suppose, given that sentiment. I didn't consider like 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. 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 thing I get a lot in emails and messages from Raiders 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, as my, as my, as my,

mission in writing, but it certainly seems to be something that like 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 a 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. Well, friends, I'm here with a good friend of mine. Again, Kyle Galbraith, co-founder and CEO of Depot.dev. Kyle, we are in an era of disruption, right? I would also describe it as rethinking what we thought was true.

And I guess that's kind of the definition of disruption. But from your perspective, how are teams, reliability teams, CICD, pipeline teams? How are they all rethinking things? And where does Depot fit into that? In the conversations that I have with customers, a lot of DevOps teams, platform teams, site reliability teams, they're really looking at this new era of software engineering that we're all living in. And they're starting to question, like, the bottleneck is no longer the act of writing code. The bottleneck is shifting.

The most time-consuming part is integrating the code. It's everything that comes after. It's the build. It's the pull request review. It's the deployment. It's the getting it into production. Once it's in productions, it's scaling up support teams to support it. It's adding documentation.

All of these downstream problems. And so through the lens of Depot, what we're really starting to think about is there's a very realistic possibility that within the next two to three years, maybe even sooner, that we're going to enter a world where an engineering team of three people, could theoretically have the velocity of an engineering team of 300 people. And what's the consequences of that? What's the consequences of the code velocity spiking up to that level with such a small team? There's no way three engineers are going to be able to code review all of the code that's being created

if there's three engineers and 297 agents also grading features and fixing bugs. So that's just like from a pull request perspective. But then you think about it through a build lens too of if your builds take 20 minutes with three humans and now you're going to have three humans and 297 agents also running. Well, like, you definitely don't want your builds taking 20 minutes because now, like, the entire pinch point is the build pipeline. And so we're starting to think a lot about how do we eliminate the bottlenecks that come downstream and what can we do with Depot that streamlines that?

So obviously, friends, we are in an era of destroy. Things are changing. You know it. I know it. That's how it is. And the thing with production and what Kyle's talking about here is, how in the world do you get your bills to be faster? How do you get them to be more reliable, faster, more observability around those deployments? You need it. It's required. And Depot is there to help you. So a good first step is to go to depot.dev. Get faster. Try their trial. It's too easy. Again, depot.dev is where to go. It all begins at depot.dev. 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. boy, not very smart, but my mom, who's his 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, I had to say that. 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, 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. You're augmenting the EQ for the IQ.

Yeah, although I don't know if I have great IQ either. I think 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 is 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 you know just uniquely different than any other sport and one thing that the guy that runs the place share 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 simple 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, you know, TDD or all, 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 post where you seem to suggest being mentally fit and I don't mean not crazy or being, you know, 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 like blog like I do now, you know, 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 are like 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 is, you know, that can really hurt a team. But there's, 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. Jared 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, you know, the technical bits by hand, becoming less valuable. And so you wrote on this, this is one 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 while 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, perhaps much like software engineers called 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, in this case, values. So really, like, 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 like 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, you know, 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, you know, 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. And 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 is 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. 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 about 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'm, 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 like starting to maybe change or like I'm ready to change them because like maintainability.

Okay, in the small, not in the large, but in the small seems like, is it all that important or will it be all that important when a rewrite is so, is. is 10 seconds away by a skilled developer, you know, like, 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 zero percent better from here. Yeah, absolutely. I mean, you would have more context on this than May, having been in the industry longer,

but certainly for me, the last three years and the last year, even have been the largest, like the most rapid time of change I can recall, like for my entire time in the industry. And not even just because of AI. I mean, since, since 2023 with the death of the zero interest rate regime, this is also something I write a lot about. It's been what it means to be a software engineer has completely changed. And now with the advent of like genuinely capable AI agents to, like, writing, writing code, it's changing again, and it's, it's sort of continuing to change. And, yeah, like a lot of, a lot of the old ways of thinking about things sort of no longer apply. You almost want to list the things that, like, haven't changed

because the change has been kind of so, so extreme. Although I do think it depends where you are. I mean, one, one thing I believe is, like, software engineering is, 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. Oh, for sure. I think a lot of those engineers kind of look at discussions like these and they think, what are these people talking about? Like, AI agents are just not there yet. But for somebody like me who works, you know, a lot of what I do is kind of web servers and protobuff mangling and, you know, 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 been 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 front-end technologies, and specifically CSS technologies, SVG, et cetera, where I find that they completely lack the ability to do what I want them to do. and then I'm doing something else like writing some sort of static generator and go and it's like

I didn't write any of this code and I've helped it refactor along the way but it's like it's totally capable of doing this with just a little bit of direction from somebody who knows what they want and what 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 and they're like okay I'll do it that way and in those areas it's like 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. 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 model 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, do they even mad 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. I've kind of used AI agents to write most of my front-end stuff, certainly for my blog. But at work, sometimes

when I'm writing Go-Lang 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's static site generator, that's a fairly well-understood problem. And, you know, 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 I, to your broader point, I absolutely agree. I think we're going to,

there's going to be a new set of engineering values that, that, like, comes in when this technology stabilizes, and it's very hard to say in advance what those values are going to be, how much engineers are going to need to, like, 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? Like, 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? Is it need to be rewritten? You know, where are all the problems with this? Is it going to pigeonhole us? Is it fine? Like that, I think, is like 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 is just weighing in the balances right now. It's kind of unnerving. I do think readability is never going to go away. I think if it, 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, you know, 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, you know, 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 that's going to, like English is kind of the new programming language, that your expression of the spec is sort of your program.

a work product and whatever it is that the programmer or whoever is giving to these AI agents, I think that's always, 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. Like you're still going beyond the spec, but maybe, yeah, maybe we get back. we get to a place where all we're reading our 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. You know, like 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, like 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, you know, it's getting less interesting to be a software engineer. I mean, the last, the last like 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. like for good or for good or else 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 like

most artistic aspects of white collar work you know 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 you know we're writing the docs and they're writing the code i'd prefer if they wrote the dock 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, like, ordinary computer programs are really good at, and they're really good at things that ordinary computer programs are terrible at. Like, it's a different way of doing it.

That's where the advent of the tool has been so amazing. Like, again, when I talk about the software around the models, getting so much better, the fact that, you know, chat GPT or GPT5 can't do, they can't count how many R's are in strawberry or whatever, like 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 that's really good at or Pearl 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 like to 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, 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, or it's like, okay, this is really good now. Yeah, I mean, this is something that, this was anticipated for sure. I mean, in I think 2020, Leopold Ashenbrenner wrote situational awareness.

Maybe not 2020. Check that. But years and years ago, like long before AI was like the thing that it is today. And one of the things he wrote about in that was what he called. hobbling, 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. Like there's been so much engineering work in systems like, you know, copilot agent, cursor,

Claude Code, code, codex, like all of these things, you know, and I, 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. 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. I kept thinking like, okay, we've hit a plateau.

We've got 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 do 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, et cetera. And you get a huge wins from that without having to have any sort of transitional, you know, 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. I didn't read your blog back then.

Not in 2020. Yeah, okay. Okay, friends, Augment Code. I love it. This is one of my daily driver AI agents to use. Super awesome. CLI, VS code, JetBrains, anywhere you want to be. Augment Code can bring better context, better agent, and of course, better code.

To me, Augment Code is by far one of the most powerful AI software development platforms to use out there. It's backed by the industry-leading context engines. The way they do things is so cool. You get your agent, you get your chat, you get your next edit. completions. It's in Slack. It's in your CLI. They literally have everything you want to drive the agent, to drive better context, to drive better code for your next big thing, for your big thing you already working on, or whatever you have in your brain. You want to dream up. So here's a prescription. This is what I want you to do. I want you to go to augment code.com. Right in the

center, you'll see install now. And just go right to the command line. There is a terminal CLI icon there. Click that. And it's going to take you to this page. It says, install via NPM. Copy that, pop into your terminal, install augment code. It's called Augie, instantiate it, wherever you want to, type in AUGG-G-I-E, and let loose. You now have all the power of augment in your terminal. Deep context, custom slash commands, MCP servers, multimodels, prompt enhancers, user and repo rules, task lists, native tools, everything you want. Right at your fingertips.

Again, Ogbidcode.com is one of my favorites. You should check it out. Well, friends, this episode is also brought to you by our friends over at Nordlayer. And you know what's scarier than Black Friday chaos? Yeah, you guessed it. Leaving your business network wide open to ransomware fishing and whoever's bored enough to poke around your systems. And that's a lot of people. That's exactly where Nord layer comes in.

It is a toggle ready network security platform built for modern businesses, combines VPN, access control, and threat protection. And it's all in one easy-to-use setup. There's no hardware, no complex configuration, just secure connection and full control in less than 10 minutes. The cool thing is it is designed around zero trust, meaning only the right people who have access can access the right things. Here's the best part, 28% off. Yeah, 28% off for the yearly plan. And the next step is to go to Nordlayer.com slash the changelog, yes, nordlayer.com slash the changelog. our code change log hyphen 28 yes the hyphen is important again change log hyphen 28 use that code

before December 10th 2025 for that awesome 28% discount and the beauty is you also try at risk free with their 14 day money back guarantee keep your team secure you're never clean and your mind at ease once again that's nord layer your toggle ready shield for modern internet go to nor layer.com slash a change log and user code changelog hyphen 28 enjoy assuming that code review stays relevant you wrote a good post called mistakes I see engineers making in their code reviews it was back in September and I think that that's something that our audience would certainly love to hear because code reviews right now is like 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. But the idea, the idea that I have

here is that, well, one, you shouldn't leave many comments. This is kind of a thing that I think happens a lot, particularly in these big tech companies where you'll have code reviews that have, you know, 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, you can't track more than those things. Like you just, there's no way you have more than six interesting things to say about a pool request. Like past that, it just becomes kind of line item comments.

And the problem with line item comments is, is that they, they suck up all the attention that like should be spent on like a higher level discussion. So instead of kind of, you know, commenting on in 30 different places and saying, oh, here you've used, I don't know, you've used map filter where you should be using reduce. You should leave like one comment saying, you know, 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 they, 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 code base 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 just don't need to do this because we have this system here that you could use instead.

Or sometimes, you know, you've built this system in this place which I can see why you did that but it's much, much better to build it here for these general high level high level reasons. And I think if you're just kind of if you're doing a lot of code of you and you're just skimming the diff and you're reviewing

the diff like a large language model would, you're going to miss out on those kind of interesting comments. I think those are like the main two things I would say, which don't leave too many comments and don't just review the diff. Yeah. So that second one is I think super powerful. And I

certainly am guilty of just reviewing the diff. And so I'm feeling very seen by this one. And I coached them basketball, Sean. I got young boys playing basketball. I've been coaching for years. And so as you coach, you try to figure out how to become a better coach, obviously. Otherwise, why are you doing it? And similarly, when I first started coaching, I would just literally coach and review.

I mean, that's what a review is, right? Like you're actually watching and you're giving advice and opinion. based on what you see. And I'll review what they were doing. You know, you didn't do this right this way. You should put your foot here, et cetera. And what was way more powerful when I realized, I need to be looking at it from a bigger scope

and actually telling them what they could have done instead, not what they did right or wrong, but actually they're not seeing this part of the court or here's a better way where you could avoid this thing altogether. I mean, that's kind of what you're talking about here, where it's like, don't look at what they're showing, you look at the entire system and let them and tell them what they're not seeing. That requires some scope, though.

You've got to really understand the system, don't you? Yeah, I mean, for sure. But that's why it's so valuable because you're bringing to bear your understanding of the entire system. That's why code reviews with that context are so much better because they're harder, because they incorporate kind of a broader understanding. That makes tons of sense. So are you been, how long have you been working at GitHub? Oh, five years? Four years? Four or five years. And in that time, I assume you've done code reviews. So you've done political influence. Like, you've done the things. Like, you're not, you're not just writing about the stuff. You're actually doing the stuff, right? Yeah. Yeah. Yeah. It's not. Just making sure. I mean, obviously, right? But, you know, I want to make sure that's the case. Sometimes we just have color commentaries and they're not actually out there doing the work. So that's probably one of the reasons why you're so good at it is because you're actually.

living the life. Have you ever been unable to convince inside GitHub something that you want to happen or change? And you thought, I know what I'll do. I'll write a blog post about this. It'll make the front page of Hacker News. And then maybe some of my superiors will read it and I can influence change in that way. What about that shot? Oh, man. If I've ever done that, it's by accident. I try really, really hard to do the exact opposite of that. I do not write about things I've worked on in like the last year. I try really hard to not give examples from GitHub from the company I'm currently working at. I am I am so, so, so paranoid about about writing some blog post and then having my, my teammates or my manager read it and think,

he's talking about me. Like, you know, why wouldn't he just come talk to me? No, no, I don't want to do anything. It's like the most passive-aggressive thing you can do is like, you know, vaguely veil it that your blog about one of your coworkers or your boss or something. And they do read my blog like many of my... Well, I assume they do. That was kind of my question was facetious, but

I guess the real thing is there is like at a certain point when you have a blog like yours, which has become very well read, you know, you have more influence, not just inside of your political team there at GitHub or wherever you're working, but actually you're starting to change

the minds of your colleagues across the entire industry, which is going to boomerang back into GitHub is kind of weird. Even if you don't want me, you can't avoid it at this point. Yeah, it's, it's scary. I mean, because I still, you know, like, you've been working in the industry twice as long as me. Many of my colleagues have been working in the industry longer than me. Plenty of people have experience. I don't have. I'm writing from where I'm at, but I don't claim to have to have all the answers. I speak confidently because that's how I speak. But, you know, there's always the caveat of like, this is just from my experience. This is just my opinion. So it's a little bit scary to think about people

reading my posts and thinking, oh, that's how things are. I'm going to change the way I work based on that. I'm like, well, I hope that works out for you. I mean, it worked out for me, but it's not a responsibility I'm entirely comfortable with. Well, you're very good at what you do. This is why, you know, guys like me who've been doing it twice as long as you have still want to read what you have to say because not only do you have a good head on your shoulders, but you're very good at explaining it in ways that just easy to read and resonates. I find myself nodding along to what you're saying in agreement more often than disagreement. So keep up the good work. Are there any posts you have, and you said before the show started, or maybe it was on the show, I don't know

anymore, that you had 13 or so drafts going on. Here we are November 5th, you know, 2025, getting towards the tail end of the year. What are you thinking about right now? Like, what's on your mind? What do your drafts look like? Are there percolating thoughts that maybe you want to workshop here on the show or maybe just get out there in some sort of a non-finalized form? The thing about podcast, Sean, is people give us the benefit of the doubt because we're

just talking. Once you write it down and publish it, you know, people take it very seriously and it's kind of like encoded forever. Now, we do have transcripts, but still, there's way more bandwidth in a podcast and you have more opportunity to just talk and not feel like every word has to be the perfect word. So we've been thinking about recently that we can maybe just put out on the table and take a nibble on. I don't think I have anything like super controversial in the queue.

I tend to write my controversial posts as quickly as possible and I publish them. If something's sitting in drafts, it's probably because it's insufficiently controversial. And I'm trying to think of a way to like to make it a bit a bit punchier. But, I mean, one thing that I've been noodling on for a while is my take on the idea that, like, getting the main thing right is so important. Is this a draft I've had sitting in my drafts for a month that, like, you can be like a grinder. You can be like heads down 100% doing what you think is like good work, you know, 12 hours a day. And you will get like, you will get out competed by somebody who is completely half-assing what they're doing. but what they're half-assing is the right thing and what you're doing is the wrong thing.

And I'm still trying to kind of articulate exactly how I feel about that. But there have been times in my career where maybe this is something that I haven't really expressed in blog posts because it is a bit. I have a bit uncomfortable saying it. But there have been times in my career where I have not worked very many hours in the day. Some days I work a lot of hours, but some days I don't. Some days I work very, very few hours. If I'm just not feeling it, I don't force myself. to grind.

And one thing I've sort of grappled with is like, you know, do I like deserve my job in those periods where I'm, where I'm working comparatively fewer hours? You know, am I like cheating my company out of, out of my labor? Right. And one thing I console myself with is like, well, you know, maybe I'm only doing, this day I only really got like four hours of work in, but it was all in the right direction. So that's, that's more useful than 12 hours of work in like random, random directions. I don't know about that.

It's sort of uncomfortable talking about how many hours you work on the internet, particularly when your boss is going to read it. That's completely fair. I would say my response to that would be it depends on what your company is hiring you to do, right? And so that is, of course, contextual to that agreement. But assuming it's a typical tech company who, you know, writes and sells or rents software as a service like GitHub does like they're probably hiring you to move that organization

in the right direction right they want you as a laborer to put your thoughts and your experience and your intellect towards progress and certainly they probably wouldn't be interested in you grinding in the wrong direction i mean this is why we make fun of the 10x developer a lot but just because it's you know it's a meme at this point and of course there's people who are tech bros who act like they are these things. And I don't think that's the case. But I do think software is a place where it's very easy to move in the wrong direction. I mean, you can become a 10x by just being a one Xer because a lot of people are just doing the wrong thing. And actually, you know, what's the opposite of progress? Like moving backwards? You know, like it's so easy

to be off and actually be doing harm, even unbeknownst, I mean, most of the time, unbeknownst to yourself. And so being on the right path and doing the right thing is like, that's the name of the game and grinding in the wrong direction isn't getting any value like sometimes however you don't know you're grinding in the wrong direction and so you just got to grind until you find out this wasn't right other times you're like i just can't work right now because my mind isn't right and it's like yeah i got no problem with it but of course that's up to you and your employer um yeah i'm comfortable in my relationship with my employer that's great Great to hear.

Sounds like with good reason. I do know that when you're on the main thing, though, you can make major progress really quickly. And you can accomplish a lot in a small amount of time because it's so highly leveraged. Like what we do is highly leveraged. And so that's the point about leverage. It's like when you wield it correctly, massive gains.

But of course, when you wield it wrong, you know, you're going the wrong direction. So. Yeah. Sometimes I think about it like this. where particularly the more senior you get if you do like one genuinely useful thing a week that puts you ahead of I think most engineers when I say genuinely useful I mean like a contribution that would not have happened without you if you like that that is in the right

direction and it actually does realize a lot of value you can do one of those a week you know in some like there's a sense in which you can do one of those a year and you can still be very much in the black but of course you can't you can't do that without doing a lot of different things you know you have to you have to try things to see what works so it's not maybe if you were like you know the sage high up on the mountain with perfect information you could right do three hours of work a year and and and be like super impactful but I don't think any human being can do that. Well, it's like that old commercial where the guy saved the nickel. You remember this one? He's running around. I saved us a nickel. I saved us a nickel. He's like running around the office

and nobody cares. They're like, dude, it's a nickel. Nobody cares. And then finally he walks past like three of the higher ups. And he's saying, I saved us a nickel. I saved us a nickel. And the right person heard it. And he's like, we do that operation 17,000 times a day or something like that. You know, like the nickel was being saved at the scale. Nobody realized it. I can't remember what the commercial was even about. But I do remember that because I want to talk about leverage, like, there's your thing. I don't know if you saw the post, Sean, recently, the TikTok intern who saved him 300K a year,

rewriting a very small part of their service from Go to Rust. Did you see that post? No, I didn't, but it doesn't surprise me. Yeah. So, like, there's an opportunity there where, like, this person comes in for an intern. Of course, they were assigned this task, I believe. and it's like this one particular end point of a thing where it's just like 95% of TikTok is written and go I believe according to that post and so lots of go and goes relatively

you know fast programming language and everything but because of the nature of this particular call they like they benchmarked it they realized you know the gc pauses or something was causing it to use way more compute than it needed to and so like they just rewrote their internship was basically rewriting this one thing in Rust so they could hyper-optimize it. And it saved them like 300K a year in compute. And like that's the kind of cool wins you can get when you do when you do the right thing. Like when you now, it was an intern. So is it a unique contribution?

Like probably a lot of people that org could have written that particular program. It's just cool that an intern got to do it and write about it. But it's an example of what you're talking about where it's like if you can bring 300k a year in value in a couple of months. well that's way more than the pain yeah i mean it's it's easier to do that in some in some roles than others for sure like yeah one one i mean i can't talk a lot about it but one of the really interesting things about working for copilot um working in like the copilot area at github has been just the ridiculous growth that co-pilot has had like financially um and i you're you're

very rapidly in a position where you're making like technical decisions on which you know a hundred of millions of dollars are kind of flowing through. And you talk about leverage, right? Like your mistakes and your wins will effectively cost, you know, $10 million here or there. Like I have made mistakes that have cost a lot of money. I have done things that have recouped a lot of money. Like, it's a really, really interesting position to be in,

to have that amount of leverage. It's kind of scary. Yeah. It is a high stakes can. game, which makes it all the scarier knowing kind of, you know, the status of the industry and the lack of sometimes resiliency, the lack of resiliency and the overwhelming desire to go faster, faster, faster, you know, and to keep up and to pass. And how much is on the line now?

I mean, if you look at our lives now, how much of our lives are. informed or completely driven by these digital things that operate them, you know, whether it's our paychecks, our bank account, our voter registration, our votes, our education, right, like our whatever it is, our scores in our school, our relationships, you name it, our medical, you know, history, as well as diagnoses. like everything's on there now everything's in there and um we software engineers are the ones that are like you know we're twiddling those bits and twiddling the wrong way and things can go poorly but also opportunity right opportunity to help a lot of people if you do it well um what else

what else um i have this this is one of those things where um what is it uh was a w horden who said that like enjoying your own handwriting is like enjoying the smell of your own farts. I think the equivalent of that for blogging is like writing posts about blogging and writing posts about like the experience. So I try to do that as rarely as possible. But I have this kind of like draft I've been working on about like how to how to write posts that kind of like people that like blow up on the internet and how to write posts that like will hit the top of hack and news and stuff and I it's this is genuine advice or this is sarcastic advice no no genuine genuine well you you you have the ability to do it clearly you've done it on a repeated

basis so your advice you have the the the cloud what it what are your summary just give us the quick list like what do you what do you do it are you trying to do it first of all yeah I'd say so I wouldn't say I'm like clickbaiting but I want people to read what I write and one way to do that is to have it appear in these aggregators like the change log like like hack and news like all these all these other places I think it's hard to say but a big part of it is like finding the exact right tone to hit you sort of want like a academic article but a little bit more colloquial but not too much more colloquial you want to be like way way away from the kind of default you know GPT for style of like

snappy sentences, but you can't make it too, like, it's a fine line to walk. Like, you want, you want to post that people can, like, comment on without reading the post, if you know what I mean. Like, you want a title that's going to kind of have people like, yeah, the title has to make the point for you. Right. But it can't, like, the title can't be too punchy because then you end up in a situation where you have more comments than upvents on the post.

and as soon as you go over more comments and upvotes, it triggers the hack and use like flame war mechanism and your post just gets annihilated off the front page. So you have to kind of like, you know, you've got to be really careful about like doing things like asking questions in your title, but you also want your title to be punchy enough because most people aren't going to read the article. So it's this kind of fine line to walk. The whole process, I wrote this, I did write a blog post about this,

which I, you know, I really enjoyed writing. I think I called it impressing people you don't respect. That's a good title. Well, I didn't call it that initially. I was afraid to call it that. And I turned it down and I've since kind of punched it off a bit. But when you're trying to get your blog read, it's a really interesting thing because I don't care about volume of readers.

What I care about is quality of readers. If you know what I mean. Like I do. I want people who like, if the right text, people read a post, I wouldn't care about the other, you know, 90,000. Like, it's, it's, it's just, like, it's getting it to those people who are going to give you, like, really interesting feedback, who are going to email you with, like, their own experience. That's why I write the blog posts. But you can't, you can't do that unless those

blog posts get, like, seen by a lot of people. And in order for them to get seen by a lot of people, you have to kind of appeal to audiences that, like, perhaps aren't as, aren't going to give you, like, that interesting signal, that useful feedback. So there is this weird dynamic where you have to kind of be a bit clickbait even though the people who you're really writing to don't care about the clickbait, because otherwise it's not going to get in front of them. Right. I do know what you mean.

I didn't anticipate that being a thing. You have to attract the people that you don't actually care about them reading it because they will amplify the signal of it loud, you know, loud enough so that it will reach the people who otherwise might not have seen it. And now they're the ones who are actually the high-quality readers that you're trying to reach in the first place. Yeah, although I do care about all of my readers. And if you read my post, I love you.

I'm just over here trying to figure out which category am I, you know, what group am I in over here? To give like a concrete example that I think might like, make it seem a little bit less arrogant to say this. A lot of the people who are going to upvote your post on Hacker News aren't going to read it. They're going to maybe, they'll maybe click through and skim the first sentence. They probably are just going to up for it based on the title. I don't really care about those readers because they aren't readers.

They don't read my posts. But I do want them to upvote so that my post gets shown to people who are actually going to read it. That's the kind of thing I mean. Like I don't have this. You don't also cross the line so that the person who actually is the high quality reader, they look at your title and I think, ah, this guy's a hack, you know, he's just trying to get at the top of hacker news. I'm not going to read this thing.

It also doesn't work. Like super clickbait titles are not typically that's successful in hacker news. Sometimes they are. But in my experience, it works better to be a little bit lower key. Well, I'd say we have similar aims here. And I think one of the great things about the change log, which we've been doing for a very long time, and we have a niche audience, you know, we're software developers. And so it's very small group of people.

And even amongst software developers, there's like big. shows or whatever but we have all the best listeners like we have our listeners are i'm and i'm course i'm yes i'm stroking their ego right now as they listen to this and that's part of my goal but the other part is just to be honest and tell you like they're kind they're thoughtful they send us great emails they're insightful and so i've one of the reasons why i love the change log specifically and the audience that we have here and i'm sure there's tons of cross over with your blog sean so uh i i bet you also have these same people you got me at least is that they are all the best things that you want in a listener

like they don't flame they don't hate uh we get very little when we do get critical feedback which we do and we appreciate because that helps us get better it's always well stated and you know clearly with positive intent like we have awesome listeners and so hopefully pick up us a few readers from this episode well as a serious crossover going As a change log listener myself, thank you. I'm going to take all that as praise to me specifically as well. But yeah, I agree. You have a great audience.

And I think, yeah, I certainly like, yeah, I have, I really, really treasure the messages I get from readers, the thoughtful messages. One thing about blowing up on Hacker News is that I do get a lot of very negative feedback. You do have to have a thick skin. My initial post about how to, about shipping. projects in large tech companies where I was talking about how the process being fundamentally political, there were a lot of comments on that and have been since basically saying, this man is clearly a psychopath.

I would not want to work with him in any capacity. I feel bad for his colleagues. He will destroy any company he works at. I get a lot of comments like that too, which I have to just share. Yeah, those I just laugh at stuff like that. That's good stuff. we've been on Hacker News a fair bit of times and we've been

we've got thick skin at this point you have to or you just have to not read it now it's not quite the most icily of software world but I think that's reserved for the R programming subreddit where they'll also tear you apart

but with like less intellectual ways of doing it I don't know if that's a I was really surprised that Reddit was worse than Hacker News I thought Reddit would be better than Hacker News it's not. Reddit is so much worse. The comments are so much more negative. Yes. And Reddit has a culture of like piling on, especially on jokes where like if one person disses you in a funny way, like there'll be reply

after reply after reply of like them one up in each other, you know, in like a downward spiral of dirtiness. It's hard to put yourself out there. I have people like like my resume is public on the site. Like any post that gets sufficiently popular, there's a handful of people who go and find my resume and tear it apart. They're like, oh, well, he's a staff engineer, but, you know, staff engineer at like Zendesk and GitHub, like, what does that really mean? I'm like, I don't know. I'm pretty proud of where I am. I was to say, like, those are good jobs, dude. I think so. But people on the internet are always going to, always going to criticize. But I think it's, it's useful having my name out there. It's useful at being me and it

not being anonymous. I think that that adds to the value, even though it's kind of hard. The only problem is I've been pronouncing your name, Sean Godecki in my head. And now, after years of reading you. I know it's Sean Getakie. And so when I say that on the next time you're on ChangeLog News, we'll be sure to pronounce it right. Sean, keep writing man. Keep writing

software. Keep writing pros about software. We'll keep reading them. And anything else you want to say to me or to the audience before we call to show? No, that's it. Just thanks to everyone for reading. As long as people keep reading, I'm going to keep writing. Awesome. Will you get back to your day?

This is the end of my day, but the beginning of yours. sure you have some writing and some work ahead of you. I'll let you go. Thanks, Sean. Thanks so much. We have a little bonus segment for our Plus Plus members. It's the pre-show, which is mostly me trying to convince Adam to watch Gattaca, which he mistakes for Battlestar Galactica, which I also liked, and he didn't.

But not as much as Gattaca, which is worth a watch in my sometimes humble opinion. ChangeLaw.com slash Plus Plus. Plus, if you want to access, support our work, delete the ads, and listen to us even more than you listen to us already. Oh, and if you're just dying for this bonus but don't want to or don't have the means to give us any of your hard-earned cash, that's totally cool. I also included it at the very end of this episode's YouTube video, so find us at YouTube.com slash changelog, subscribe while you're there, why don't you?

And skip to the last chapter of the episode. There you go. Thanks again to fly.io, to tigerdata.com, to depot.dev, to augmentcode.com, and to norelayer.com slash the changelog. Oh, and thanks to breakmaster cylinder for the beats. You're the best BMC. That's all for today. But we'll talk to you again on changelog and friends on Friday. We're going to be able to be. Game on