DO Repeat Yourself!  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: DO Repeat Yourself! - Category: #podcasts - URL: https://share.snipd.com/episode/8df20a2e-ff09-478f-af27-1af37ab309ab ## Document Notes ## Highlights - **Write Opportunistically With Many Drafts** - Keep many rough drafts and ideas active so new posts can spring from small sparks. - Use fleeting sentences from one draft to trigger a full new post rather than grinding one piece to completion. Transcript: Jared Where are you pulling them out of? Sean Goedecke Yeah, that's a, that's a good question. I'm not quite sure myself. So I didn't, I didn't write for the longest time. I didn't write for the first, oh, eight years of my, of my career. And then all of a sudden in the last two years, I, I find myself having a lot of things to say. I think it's kind of self-reinforcing in a way. It's easy to feel like you don't have a unique perspective to add, but if you write one thing and people like it, it makes you more likely to write other things. And it kind of just keeps going like that. It all kicked off for me with a post I wrote about how to ship projects maybe a year ago. And I wrote that out of frustration with people I'd worked with in the past and people I'd seen work, engineers who were treating the shipping part as like an afterthought. And they sort of felt if they wrote all the code and they completed all the JIRA issues, then the project would be done. And that's how projects work. And I felt and feel now pretty strongly that that's not how projects work. So I wrote a blog post about that and it hit the top of Hacker News and got really popular and 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. ([Time 0:04:22](https://share.snipd.com/snip/2466281e-cda2-4409-8dc9-b7c085796084)) - **Hacker News Launch Kickstarted His Blog** - A post Sean wrote about shipping projects hit the top of Hacker News and sparked his writing momentum. - That early success convinced him he had more to say and led to prolific blogging. Transcript: Sean Goedecke 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. ([Time 0:05:28](https://share.snipd.com/snip/c4e235ee-4399-4ece-97f8-a958232329ef)) - **Senior Engineers Should Shape Local Politics** - Senior engineers must engage in organizational politics because technical choices are political and consequential. - If you're best positioned to know an answer, represent it confidently instead of deferring and leaving decisions to others. Transcript: Sean Goedecke Or the. Yeah. As, as, as broader than the, broader than the technical engineers ought to be aware of the, of the politics of the organization. And, and broader than that, like 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. And that it's a dereliction of duty if you're a senior engineer and you're 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 ought to be more confident than you feel internally. A huge part of the job is being more confident than you feel internally. If you're in a conversation and you're best positioned to know the answer to something, even if you don't feel confident about it, you ought to represent that answer to the organization Because nobody else is in a better position to do so. Anybody who has to make a difficult decision is going to be 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. ([Time 0:12:10](https://share.snipd.com/snip/f173bb34-e810-4a37-b502-96539a8cc2c7)) - **Carry A Ready List Of Timely Ideas** - Maintain a back catalog of 10–15 brief project ideas so you can pitch when timing favors them. - Wait for organizational waves of interest (incidents, budget cycles) to attach your idea to leadership priorities. Transcript: Sean Goedecke The first way is like the hard way, 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 campaign for it like normal. You write a proposal, you talk about it at talks, you try and convince people, you talk to your manager, you talk to your skip, you're drumming up support for this idea. And that's very hard. It can work. I've seen it work, but it requires a lot of persistence and it's usually less sticky. The easy way to influence company politics is to, instead of having one idea that you're pushing, have a kind of stable of ideas that you have ready to go at any given moment. And then when it becomes time for that idea, you'll have something you want to do in the bag already. And when I say time for that idea, companies kind of go through what I like to think of as these waves of interest in different areas. So suppose you have a couple of ideas about how to make the service you're working on more reliable. Maybe you want to do, I don't know, cross-region stuff or multi-cloud stuff, something like that. It's going to be pretty hard when the company's 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 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 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 like brief write-ups on like 10 to 15 things that you kind of want to see happen. ([Time 0:18:09](https://share.snipd.com/snip/7ea936c0-8f45-4183-ac64-7ece4745298f)) - **Mind Fitness Matters More Than Raw Skill** - Emotional regulation and mental fitness often limit engineers more than raw technical skill. - Fear of mistakes or deployment paralysis reduces valuable contributions and leadership readiness. Transcript: Sean Goedecke Really well put. And I, that's absolutely correct. Before I even blogged like I do now, maybe eight years ago, one of the really, really early blog posts I wrote called Avoiding Worry-Driven Development. And absolutely most software engineers I've worked with have not been primarily held back by a lack of technical skill. To the extent that they've been held back, it's been by lack of emotional regulation. And there's all kinds of ways this can happen. It can happen even really subtly where you become afraid to work on things that you might get wrong. You become afraid to, for instance, deploy or to make changes that could be risky. So you might be technically very capable, but there are certain kinds of technical change that you're just not really willing to do that you're letting other people do who maybe don't Have your technical expertise, which is, you know, 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. ([Time 0:28:47](https://share.snipd.com/snip/0d10caad-c26d-4711-91bf-284b3f08af38)) - **Taste Reflects Values And Fit** - Taste in engineering maps to your operational values (reliability, performance, readability, etc.). - Good taste is when your values fit the project's needs and you flex values to suit context. Transcript: Sean Goedecke 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, values. So really, you're starting from this point where people use the word taste to mean a lot of different things. Perhaps they're not sure what they mean themselves when you get down to it. But if you look at taste as an expression of your values, a lot of things become hopefully a little bit easier to understand. And by values, I don't mean necessarily your ethical values. I mean the things you care about when you sit down to do software engineering. So for instance, you might care about reliability, you might care about performance, you might care about accessibility, you might care about having your code well factored, you Might care about having your code not be spread in too many different places. You can list these kinds 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. 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. ([Time 0:31:27](https://share.snipd.com/snip/e9ce7941-daba-4bc3-b69b-e171f58a3fdc)) - **AI Is Reshaping Roles, Unevenly** - AI agents are already reshaping what software engineers do, but effects vary by domain and depth. - Some engineering work will be automated sooner; other specialized areas remain human-led for now. Transcript: Sean Goedecke 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, like the most rapid time of change I can recall for my entire time in the industry. And not, not even just for, because of AI. I mean, since, since 2023 with the, with the death of the zero interest rate regime, this is also something I write a lot about. It's, it's been, what it means to be a software engineer has, has, has completely changed. And now with the advent of genuinely capable AI agents to writing code, it's changing again. And it's continuing to change. And yeah, a lot of the old ways of thinking about things no longer apply. You almost want to list the things that haven't changed because the has been kind of so extreme. Although I do think it depends where you are. I mean, one thing I believe is like 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. Oh, for sure. 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 protobuf mangling and, you know, fairly standard kind of forms of software engineering work. The AI agents are here, man, like they're, they're certainly good enough to help. And in many cases, they're good enough to do the entire work. ([Time 0:35:55](https://share.snipd.com/snip/13e54fa3-67ac-44d8-a49a-2a5c32ad3ed1)) - **Prioritize Readable Prompts Over Code** - Expect readability to shift from code to prompts and specs as tooling improves. - Invest in clear, maintainable prompts/specs because humans will still need to understand and update them. Transcript: Sean Goedecke Go away for Python and Golang and JavaScript, but I think if it does go away there, it's going to 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. ([Time 0:41:50](https://share.snipd.com/snip/70e08824-3dc3-4548-87f2-51ef89ac3196)) - **Make Fewer, Higher-Value Code Review Comments** - Keep code review comments focused and minimal; aim for six or fewer high-value comments. - Look beyond diffs and highlight missing design choices or existing systems that should be reused. Transcript: Sean Goedecke 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 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 50 or 100 comments sometimes. And I think that's just an order of magnitude too many. A good code review should have like six comments or fewer because you just can't track more than those things. There's no way you have more than six interesting things to say about a pull request. Past that, it just becomes kind of line item comments. And the problem with line item comments is that they suck up all the attention that should be spent on a higher level discussion. So instead of commenting in 30 different places and saying, oh, here you've used, I don't know, 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, that's, 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, 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 like general high level, 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 going To miss out on those kinds of interesting, interesting comments. ([Time 0:51:19](https://share.snipd.com/snip/0e040e17-1831-461e-b558-ef51b9e4944a)) - **Leverage Beats Hours** - Doing the 'main thing' correctly beats long hours spent on the wrong work. - One high-impact contribution can outweigh many low-leverage grind hours. Transcript: Sean Goedecke 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, it's, it's probably because it's insufficiently controversial. And I'm trying to, 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 is my take on on the idea that like getting the main thing right is so is so important this is a draft i've had sitting in my drafts For a month that um 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, do I like deserve my job in those periods where I'm working comparatively fewer hours? Am I like cheating my company out of my labor? 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. ([Time 0:59:14](https://share.snipd.com/snip/1f330d3f-9ad9-4d1a-9d53-7993122de229)) - **Copilot Work Brings Massive Financial Leverage** - Working on Copilot exposed Sean to decisions that move hundreds of millions of dollars. - He acknowledges both costly mistakes and high-impact wins from that leverage. Transcript: Sean Goedecke 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 you talk about leverage, right? Like 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, uh, to have, to have that amount of leverage. Jared It's, it's kind of scary. Sean Goedecke Yeah. Jared It is a high stakes game, ([Time 1:06:40](https://share.snipd.com/snip/34d63a2a-6754-45c4-b1ec-5c57a7820966)) - **Balance Title Punch With Reader Quality** - Craft titles that make the point but avoid extreme clickbait to attract both skim and deep readers. - Aim to reach amplifiers (who upvote) so your post shows to the high-quality readers you really want. Transcript: Sean Goedecke List. Like what do you, what do you How do you do it? Are you trying to do it, first of all? Yeah, I'd say so. I wouldn't say I'm 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 changelog, like Hacker News, like all these other places. I think it's hard to say, but a big part of it is 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, 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 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 gonna kind of have people make the point 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 upvotes on the post. And as soon as you go over more comments than 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 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, 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 up 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, I do, I want people who like, I, if the right 10 people read a post, I wouldn't care about the other, you know, 90, 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, uh, you have to kind of appeal to, uh, audiences that like perhaps aren't as, um, 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 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. Right. I do know what you mean. I didn't anticipate that. Jared 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. Sean Goedecke Although I do care about all of my readers. If you read my post, I love you. Jared I'm just over here trying to figure out which category am I, you know, what group am I in over here? Sean Goedecke 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 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. ([Time 1:09:30](https://share.snipd.com/snip/8929315f-0b7e-4f93-81ab-160d6c8ab072))