[{"data":1,"prerenderedAt":133},["ShallowReactive",2],{"podcast-meta":3,"podcast-theme-colors":32,"episode-do-repeat-yourself-interview":92},{"title":4,"author":5,"description":6,"artwork":7,"categories":8,"feedUrl":10,"type":11,"explicit":12,"link":13,"language":14,"copyright":15,"podcast2":16,"hasPeople":31},"The Changelog: Software Development, Open Source","Changelog Media","Software's best weekly news brief, deep technical interviews & talk show.","https://cdn.changelog.com/static/images/podcasts/podcast-original-f16d0363067166f241d080ee2e2d4a28.png",[9],"Technology","https://changelog.com/podcast/feed","episodic",false,"https://changelog.com/podcast","en-us","All rights reserved",{"persons":17,"funding":27},[18,23],{"name":19,"role":20,"img":21,"href":22},"Adam Stacoviak","host","https://cdn.changelog.com/uploads/avatars/people/Qo/avatar_large.jpg?v=63760280419","https://changelog.com/person/adamstac",{"name":24,"role":20,"img":25,"href":26},"Jerod Santo","https://cdn.changelog.com/uploads/avatars/people/z4/avatar_large.jpeg?v=63760071650","https://changelog.com/person/jerodsanto",[28],{"url":29,"text":30},"https://changelog.com/++","Support our work by joining Changelog++",true,{"palette":33,"sourceColor":54,"extractedColors":55},{"light":34,"dark":43},{"primary":35,"primary-foreground":36,"secondary":37,"secondary-foreground":35,"accent":38,"muted":39,"muted-foreground":40,"ring":35,"podcast-vibrant":41,"podcast-muted":42},"#00182f","#ffffff","#eff2f6","#e7ecf0","#f0f2f4","#6f7275","#0375c4","#e2e5e8",{"primary":44,"primary-foreground":45,"secondary":46,"secondary-foreground":47,"accent":48,"muted":49,"muted-foreground":50,"ring":51,"podcast-vibrant":52,"podcast-muted":53},"#5580a9","#09090b","#191b1d","#dcdee0","#1d2022","#1a1b1c","#8d8f91","#c1c4c8","#3694e6","#151618","#a1978d",[56,63,71,79,84],{"hex":54,"red":57,"green":58,"blue":59,"area":60,"saturation":61,"lightness":62},161,151,141,0.13136455555555557,0.09615384615384609,0.592156862745098,{"hex":64,"red":65,"green":66,"blue":67,"area":68,"saturation":69,"lightness":70},"#d2d1d4",210,209,212,0.000134,0.03370786516853954,0.8254901960784313,{"hex":72,"red":73,"green":74,"blue":75,"area":76,"saturation":77,"lightness":78},"#525153",82,81,83,0.003252888888888889,0.012195121951219556,0.32156862745098036,{"hex":36,"red":80,"green":80,"blue":80,"area":81,"saturation":82,"lightness":83},255,0.03285188888888889,0,1,{"hex":85,"red":86,"green":87,"blue":88,"area":89,"saturation":90,"lightness":91},"#101820",16,24,32,0.8323966666666667,0.3333333333333333,0.09411764705882353,{"meta":93,"episode":101,"transcript":130},{"title":4,"author":5,"description":6,"artwork":7,"categories":94,"feedUrl":10,"type":11,"explicit":12,"link":13,"language":14,"copyright":15,"podcast2":95,"hasPeople":31},[9],{"persons":96,"funding":99},[97,98],{"name":19,"role":20,"img":21,"href":22},{"name":24,"role":20,"img":25,"href":26},[100],{"url":29,"text":30},{"guid":102,"title":103,"slug":104,"description":105,"htmlContent":106,"audioUrl":107,"audioType":108,"audioLength":109,"pubDate":110,"duration":111,"artwork":112,"episodeType":113,"explicit":12,"link":114,"podcast2":115},"changelog.com/1/2782","DO repeat yourself! (Interview)","do-repeat-yourself-interview","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.","\u003Cp>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.\u003C/p>\n\u003Cp>\u003Ca href=\"https://changelog.zulipchat.com/#narrow/stream/456187-interviews\">Join the discussion\u003C/a>\u003C/p>\u003Cp>\u003Ca href=\"https://changelog.com/++\" rel=\"payment\">Changelog++\u003C/a> members get a bonus 4 minutes at the end of this episode and zero ads. Join today!\u003C/p>\u003Cp>Sponsors:\u003C/p>\u003Cp>\u003Cul>\u003Cli>\u003Ca href=\"https://www.tigerdata.com\">Tiger Data\u003C/a> – Postgres for Developers, devices, and agents The data platform trusted by hundreds of thousands from IoT to Web3 to AI and more.\n\u003C/li>\n\u003Cli>\u003Ca href=\"https://depot.dev\">Depot\u003C/a> – \u003Cstrong>10x faster builds? Yes please.\u003C/strong> 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.\n\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.augmentcode.com\">Augment Code\u003C/a> – 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.\n\u003C/li>\n\u003Cli>\u003Ca href=\"https://nordlayer.com/thechangelog\">NordLayer\u003C/a> – 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 \u003Ccode>changelog-28\u003C/code> at \u003Ca href=\"https://nordlayer.com/thechangelog\">nordlayer.com/thechangelog\u003C/a>\n\u003C/li>\n\u003C/ul>\u003C/p>\u003Cp>Featuring:\u003C/p>\u003Cul>\u003Cli>Sean Goedecke – \u003Ca href=\"https://www.seangoedecke.com\" rel=\"external ugc\">Website\u003C/a>, \u003Ca href=\"https://github.com/sgoedecke\" rel=\"external ugc\">GitHub\u003C/a>, \u003Ca href=\"https://www.linkedin.com/in/sean-goedecke-5495a7137\" rel=\"external ugc\">LinkedIn\u003C/a>, \u003Ca href=\"https://x.com/sjgoedecke\" rel=\"external ugc\">X\u003C/a>\u003C/li>\u003Cli>Adam Stacoviak – \u003Ca href=\"https://adamstacoviak.com/\" rel=\"external ugc\">Website\u003C/a>, \u003Ca href=\"https://github.com/adamstac\" rel=\"external ugc\">GitHub\u003C/a>, \u003Ca href=\"https://www.linkedin.com/in/adamstacoviak\" rel=\"external ugc\">LinkedIn\u003C/a>, \u003Ca href=\"https://changelog.social/@adam\" rel=\"external ugc\">Mastodon\u003C/a>, \u003Ca href=\"https://x.com/adamstac\" rel=\"external ugc\">X\u003C/a>\u003C/li>\u003Cli>Jerod Santo – \u003Ca href=\"https://jerodsanto.net\" rel=\"external ugc\">Website\u003C/a>, \u003Ca href=\"https://github.com/jerodsanto\" rel=\"external ugc\">GitHub\u003C/a>, \u003Ca href=\"https://www.linkedin.com/in/jerodsanto\" rel=\"external ugc\">LinkedIn\u003C/a>, \u003Ca href=\"https://changelog.social/@jerod\" rel=\"external ugc\">Mastodon\u003C/a>, \u003Ca href=\"https://x.com/jerodsanto\" rel=\"external ugc\">X\u003C/a>\u003C/li>\u003C/ul>\u003C/p>\u003Cp>Show Notes:\u003C/p>\u003Cp>\u003Cul>\n\u003Cli>\u003Ca href=\"https://www.seangoedecke.com/why-do-ai-enterprise-projects-fail/\">Is it worrying that 95% of AI enterprise projects fail?\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.seangoedecke.com/how-to-influence-politics/\">How I influence tech company politics as a staff software engineer\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.seangoedecke.com/worry-driven-development/\">Avoiding worry driven development\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.seangoedecke.com/taste/\">What is “good taste” in software engineering?\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://www.seangoedecke.com/good-code-reviews/\">Mistakes I see engineers making in their code reviews\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://situational-awareness.ai/\">Situational Awareness: the decade ahead\u003C/a>\u003C/li>\n\u003C/ul>\n\u003C/p>\u003Cp>Something missing or broken? \u003Ca href=\"https://github.com/thechangelog/show-notes/blob/master/podcast/the-changelog-666.md\">PRs welcome!\u003C/a>\u003C/p>","https://op3.dev/e/https://pscrb.fm/rss/p/https://cdn.changelog.com/uploads/podcast/666/the-changelog-666.mp3","audio/mpeg",76937446,"Wed, 12 Nov 2025 21:00:00 +0000",4798,"https://cdn.changelog.com/uploads/covers/changelog-interviews-original.png?v=63848368174","full","https://changelog.com/podcast/666",{"transcript":116,"chapters":119,"persons":122},{"url":117,"type":118},"https://changelog.com/podcast/666/transcript","text/html",{"url":120,"type":121},"https://changelog.com/podcast/666/chapters","application/json+chapters",[123,124,125],{"name":19,"role":20,"img":21,"href":22},{"name":24,"role":20,"img":25,"href":26},{"name":126,"role":127,"img":128,"href":129},"Sean Goedecke","guest","https://cdn.changelog.com/uploads/avatars/people/O3JkN/avatar_large.jpeg?v=63930184499","https://changelog.com/person/seangoedecke",{"content":131,"type":132,"url":117},"\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n  \u003Cmeta charset=\"utf-8\">\n  \u003Cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1\">\n  \u003Cmeta name=\"robots\" content=\"noindex\">\n  \u003Clink rel=\"canonical\" href=\"https://changelog.com/podcast/666\"/>\n  \u003Ctitle>Transcript for Changelog Interviews #666\u003C/title>\n\u003C/head>\n\u003Cbody>\n\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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...\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Non-stop.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>...and I've just been like slurping up his blog posts and putting them in Changelog ews. Sean, welcome.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Hey. Great to be here.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Blame me. Blame me.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>No, I'm blaming the ocean and the speed of light. I'm not blaming you.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Well, let's get a key and open that room, okay?\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nIt 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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nSome 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.\n\nThe 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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>\\[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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nI 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>For sure.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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...\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Time, even.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>...or they didn't notice...\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Time changes.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\n\nWhat 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..."\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>\\[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.\n\nAnd 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.\n\nAnybody 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Gotcha.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[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?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nI'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.\n\nThe 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[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?\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nSo 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.\n\n**Break**: \\[00:23:18.25\\]\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>Do you know the term emotional intelligence? And if you do, do you think that you are a relatively strong emotional intelligence person?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nAbout 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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>You're augmenting the EQ for the IQ.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Adam Stacoviak:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nSo 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.\n\n\\[00:30:04.03\\]\u003C/p>\n\n\n    \u003Ccite>*Jerod Santo:\u003C/cite>\n    \u003Cp>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.*\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Right.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nAnd 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.\n\nWhen 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nAnd 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Oh, for sure.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\n\n\\[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.\n\nAnd 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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Has it? \\[laughs\\]\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nBut 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>\\[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.\n\nSome 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>It's very interesting right now.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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."\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>\\[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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Not in 2020...\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Yeah, okay.\n\n**Break**: \\[00:47:47.06\\]\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\n\nSo 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.\n\nThe 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.\n\nThe 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'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 reasons." And I think if you're just kind of -- if you're doing a lot of code review and you're just skimming the diff and you're reviewing the diff like a large language model would, you're gonna miss out on those kind of interesting comments. So I think those are the main two things I would say, which is don't leave too many comments, and don't just review the diff.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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 in basketball, Sean... I've 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'd review what they were doing. "You didn't do this right this way... You should put your foot here..." etc.\n\n\\[00:54:17.20\\] 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 tell them what they're not seeing. That requires some scope though, and you've got to really understand the system, don't you?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>That makes tons of sense. So how long have you been working at GitHub?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Oh, five years... Four years.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Four or five years. And in that time I assume you've done code reviews, so you've done political influence... You've done the things -- you're not just writing about the stuff, you're actually doing the stuff, right?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah, yeah, I'd say so...\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[laughs\\] I'm just making sure. I mean, obviously, right? But 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.\n\nHave 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, Sean?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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 so, so paranoid about writing some blog posts and then having my teammates or my manager read it and think "He's talking about me. Why wouldn't he just come talk to me?" No, no, I don't want to do anything of that.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>It's like the most passive-aggressive thing you can do, is like blog vaguely, veil it, that you're blogging about one of your co-workers, or your boss, or something...\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Exactly. And they do read my blog, many of my co-workers.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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 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 like boomerang back into GitHub. It's kind of weird. Even if you don't want to, you can't avoid it at this point.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah, it's scary... I mean, because I still -- 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 all the answers. I speak confidently because that's how I speak, but there's always the caveat of "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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[00:57:57.01\\] Well, you're very good at what you do... This is why 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 are just easy to read, and it resonates. I find myself nodding along to what you're saying in agreement more often than disagreement, so... Keep up the good work.\n\nAre 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, 2025, getting towards the tail end of the year... What are you thinking about right now? 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 podcasts, Sean, is people give us the benefit of the doubt because we're just talking. Once you write it down and publish it, 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.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I don't think I have anything 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 make it a bit punchier.\n\nBut, I mean, one thing that I've been noodling on for a while is my take on the idea that getting the main thing right is so important. This is 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, 12 hours a day, and 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 I am 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.\n\nAnd one thing I've sort of grappled with is "Do I deserve my job in those periods where I'm working comparatively fewer hours? Am like cheating my company out of my labor?" And one thing I console myself with is "Well, maybe I'm only doing -- this day I only really got four hours of work in, but it was all in the right direction. So that's more useful than 12 hours of work in 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 gonna read it.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>That's completely fair. I would say -- my response to that would be it depends on what your company is hiring you to do. That is, of course, contextual to that agreement, but assuming it's a typical tech company who writes and sells or rents software as a service like GitHub does, 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, just because 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-er by just being a 1X-er, because a lot of people are just doing the wrong thing, and actually... What's the opposite of progress? ...like, moving backwards. It's so easy to be off and actually be doing harm, even unbeknownst -- I mean, most of the time unbeknownst to yourself.\n\n\\[01:02:23.26\\] 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. Sometimes, however, you don't know you're grinding in the wrong direction. And so you've just gotta 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." \\[laughs\\] And it's like "I've got no problem with it." But of course, that's up to you and your employer...\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I'm comfortable in my relationship with my employer, but...\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>That's great. Great to hear. It 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, is when you wield it correctly - massive gains. But of course, when you wield it wrong, you're going the wrong direction. So...\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah, sometimes I think about it like this, where particularly the more senior you get, if you do 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. That is in the right direction, and that actually does realize a lot of value. You can do one of those a week. 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 do that without doing a lot of different things. You have to try things to see what works. Maybe if you were the sage high up on the mountain, with perfect information, you could do three hours of work a year, and be super-impactful... But I don't think any human being can do that.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Well, it's like that old commercial where the guy saved a nickel... Do you remember this one? He's running around,\n\n"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.\n\nI 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. The nickel was being saved at a scale. Nobody realized it. I can't remember what the commercial was even about... But I do remember that, because when I talk about leverage - like, there's your thing.\n\nI don't know if you saw the post, Sean, recently, the TikTok intern who saved them 300K a year rewriting a very small part of their service from Go to Rust. Did you see that post?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>No, I didn't. But it doesn't surprise me.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Yeah. So there's an opportunity there, where this person comes in for an intern... Of course, they were assigned this task, I believe... And it's like this one particular endpoint of a thing, where it's just -- like, 95% of TikTok is written in Go, I believe, according to that post... And so lots of Go. And Go's a relatively fast programming language and everything, but because of the nature of this particular call, they benchmarked it, they realized the GC pauses or something was causing it to use way more compute than it needed to... And so 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 those are the kind of cool wins you can get when you do the right thing.\n\n\\[01:06:02.09\\] Now, it was an intern, so is it a unique contribution? Like, probably a lot of people at 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 they're paying you.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I mean, it's easier to do that in some roles than others, for sure. I can't talk a lot about it, but one of the really interesting things about working for Copilot, working in like the Copilot area at GitHub has been just the ridiculous growth that Copilot has had financially. And you're very rapidly in a position where you're making technical decisions on which hundreds of millions of dollars are kind of flowing through... And talk about leverage - your mistakes and your wins will effectively cost $10 million here or there. I have made mistakes that have cost a lot of money, I have done things that have recouped a lot of money... It's a really, really interesting position to be in, to have that amount of leverage. It's kind of scary.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Yeah. It is a high stakes game, which makes it all the scarier, knowing the status of the industry and the lack of sometimes resiliency. The lack of resiliency, and the overwhelming desire to go faster, faster, faster, 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, whether it's our paychecks, our bank account, our voter registration, our votes, our education... Whatever it is. Our scores in our school, our relationships... You name it. Our medical history, as well as diagnoses. Everything's on there now. Everything's in there. And we software engineers are the ones that are like -- 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. What else?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>What else? I have this -- this is one of those things where... What is it? Was it W.H. Auden who said that enjoying your own handwriting is like enjoying the smell of your own farts...\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[laughs\\]\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I think the equivalent of that for blogging is writing posts about blogging, and writing posts about the experience. So I try to do that as rarely as possible, but I have this draft I've been working on about how to write posts that blow up on the internet, and how to write posts that will hit the top of Hacker News, and stuff.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>This is genuine advice, or this is sarcastic advice?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>No, no, genuine advice.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Genuine. Well, you mean, you have the ability to do it clearly, you've done it on a repeated basis... So your advice -- you have the clout. What is your summary? Give us the quick list. What do you do? How do you do it? Are you trying to do it, first of all?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah, I'd say so. I wouldn't say I'm click-baiting, 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 Changelog, like Hacker News, all these other places. It's hard to say, but a big part of it is finding the exact right tone to hit. You sort of want an academic article, but a little bit more colloquial, but not too much more colloquial. You want to be like way, way, way away from the kind of default GPT-4 style of snappy sentences, but you can't make it too -- it's a fine line to walk. You want a post that people can comment on without reading the post, if you know what I mean. You want a title that's going to kind of have people --\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[01:10:26.03\\] Make the point.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah. The title has to make the point for you.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Right.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>But the title can't be too punchy, because then you end up in a situation where you have more comments than upvotes on the post... And as soon as you get more comments than upvotes, it triggers the Hacker News flame war mechanism, and your post just gets annihilated off the front page.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Okay...\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>So you have to kind of -- you've got to be really careful about 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 did write a blog post about this, which I really enjoyed writing... I think I called it "Impressing People You Don't Respect."\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[laughs\\] That's a good title.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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 up a bit. 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>I do.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>If the right 10 people read a post, I wouldn't care about the other 90,000. It's getting it to those people who are going to give you really interesting feedback, who are going to email you with their own experience... That's why I write the blog posts. But you can't do that unless those blog posts get 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 perhaps aren't going to give you that interesting signal, that useful feedback.\n\nSo there is this weird dynamic where you have to kind of be a bit clickbaity, 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... If you know what I mean.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Right. I do know what you mean.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I didn't anticipate that being a thing...\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>So 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 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. Is that what you're saying?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Yeah. Although I do care about all of my readers. And if you read my posts, I love you.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>I'm just over here trying to figure out which category am I, what group am I in over here?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>To give like a concrete example that I think might 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 like skim the first sentence, they probably are just going to upvote 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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>But you don't want to also across the line, so that the person who actually is the high quality reader, they look at your title and they think "Ah, this guy's a hack. He's just trying to get to the top of Hacker News. I'm not going to read this thing."\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>It also doesn't work. Like, super-clickbaity titles are not typically that successful on Hacker News. Sometimes they are, but in my experience, it works better to be a little bit lower key.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[01:13:46.29\\] Well, I would say we have similar aims here, and I think one of the great things about the Changelog, which we've been doing for a very long time - and we have a niche audience; we're software developers, and so it's a very small group of people... And even among software developers, there's bigger shows, or whatever... But we have all the best listeners. Our listeners are -- and of course, 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 they're kind, they're thoughtful, they send us great emails, they're insightful... And so one of the reasons why I love the Changelog specifically, and the audience that we have here - and I'm sure there's tons of crossover with your blog, Sean, so I bet you also have these same people; you've 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... 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 clearly with positive intent. We have awesome listeners, and so hopefully you pick up a few readers from this episode. But I think there's a serious crossover going on.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>As a Changelog listener myself, thank you. I'm going to take all that as praise to me specifically as well, but... \\[laughs\\] Yeah, I agree. You have a you have a great audience. And I certainly really, really treasure the messages I get from readers, the thoughtful messages.\n\nOne thing about blowing up on Hacker News is that you do get a lot of very negative feedback.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Yeah, totally.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>You do have to have a thick skin. My initial post about how 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."\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>\\[laughs\\]\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>"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 \\[unintelligible 01:15:50.05\\]\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>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 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 less intellectual ways of doing it... I don't know if that's a way of saying it --\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>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.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Yes. And Reddit has a culture of piling on, especially on jokes, where if one person disses you in a funny way, there'll be reply after reply after reply of like them one upping each other, in like a downward spiral of dirtiness.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>It's hard to put yourself out there. I have people like -- like, my resume is public on the site. 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, he's a staff engineer, but staff engineer at like Zendesk and GitHub. Like, what does that really mean?"\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>"What does that really mean...?" \\[laughs\\]\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>It's like, "I don't know, I'm pretty proud of where I am."\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>I was going to say, those are good jobs, dude...\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>I think so, but... People on the internet are always going to criticize. But I think it's useful having my name out there. It's useful it being me and it not being anonymous. I think that adds to the value, even though it's kind of hard \\[unintelligible 01:17:18.24\\]\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>A hundred percent. The only problem is I've been pronouncing your name Sean Goedecke in my head, and now, after years of reading you, I know it's Sean Goedecke. And so when I say that the next time you're on Changelog News, I will be sure to pronounce it right. Sean, keep writing, man... Keep writing software, keep writing prose about software, we'll keep reading them... Anything else you want to say to me or to the audience before we call it a show?\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>No, that's it. Just thanks to everyone for reading. As long as people keep reading, I'm going to keep writing.\u003C/p>\n\n\n    \u003Ccite>Jerod Santo:\u003C/cite>\n    \u003Cp>Awesome. We'll let you get back to your day... This is the end of my day, but the beginning of yours, so I'm sure you have some writing and some work ahead of you. I'll let you go. Thanks, Sean.\u003C/p>\n\n\n    \u003Ccite>Sean Goedecke:\u003C/cite>\n    \u003Cp>Thanks so much.\u003C/p>\n\n\u003C/body>\n\u003C/html>\n","text/html; charset=utf-8",1771793543973]