DO Repeat Yourself!  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: DO Repeat Yourself! - Category: #podcasts - URL: https://share.snipd.com/episode/aa6319de-ba81-4061-9536-fa29589b5681 ## Document Notes ## Highlights - **Write Opportunistically From Drafts** - Keep many short drafts and spin off full posts from interesting sentences you write in other drafts. - Capture annoyances and curiosities as raw ideas and convert the good ones into publishable posts quickly. Transcript: Jerod Santo 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. ([Time 0:04:22](https://share.snipd.com/snip/cc458462-34f9-4c5d-ba81-4248ab4bc8ac)) - **Senior Engineers Must Influence Decisions** - Senior engineers should participate actively in organizational politics about technical direction and team processes. - Represent confident technical judgments even when you feel uncertain because others rely on your position. 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. ([Time 0:12:10](https://share.snipd.com/snip/d6f91b87-498e-4f99-a152-6b7e2858565f)) - **Bank Ideas, Deploy Them At The Right Time** - Keep a backlog of 10–15 brief project ideas and wait for the right organizational moment to propose them. - Time your proposals to coincide with waves of interest so leaders can adopt and champion them. 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/d7a0cfab-3c9f-4c9b-929c-f7fac73fed21)) - **Manage Emotions To Ship Confidently** - Work on emotional regulation to avoid worry-driven development that blocks risky but necessary changes. - Practice mental fitness so fear doesn't stop you from deploying or owning important technical work. 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/8d62ff3c-d4a1-43a0-b435-2e7a7d453110)) - **Taste Is Values Fitted To Context** - Taste in engineering reflects the values you prioritize, like reliability or readability. - Good taste means matching and flexing those values to fit the project's real needs, not rigid rules. 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. And the ability to kind of be a bit flexible about your values to fit the project you're working on, I think that's the ability to have good taste in general, which is, if you'll forgive, The reference is a very Aristotelian kind of way of looking at it where the good person, for him, the good man has this ability to fit his taste to the exact situation with a nicety. ([Time 0:31:27](https://share.snipd.com/snip/b6f879bb-14f5-4fc2-bcc2-87ba0f107979)) - **AI Changes Which Engineering Values Matter** - AI agents are already reshaping which engineering tasks are valuable and which skills matter most. - Expect evolving engineering values as agents automate routine coding and change emphasis to prompts, review, and design. 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/dca235ae-656c-4305-bab7-e0c6d19c6e81)) - **Make Prompts The New Readable Artifact** - If code becomes agent-generated, shift focus to writing readable prompts and specs that guide agents. - Treat the prompt or spec as the new human-facing artifact that will need maintenance and clarity. 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/027981a6-6cdc-445f-8a19-3a5dc2f796b6)) - **Review Systems, Not Just Diffs** - Keep code review comments focused and limited; aim for about six substantive comments or fewer. - Review the system-level omissions and architecture, not just line diffs, to add the most value. 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/bdcf5479-66cb-4515-83e0-7a309bbbcbf7)) - **Avoid Blogging About Current Coworkers** - Sean avoids writing about his current company's internal issues to prevent colleagues feeling targeted. - He keeps examples generalized to avoid passive-aggressive airing of workplace disagreements. Transcript: Jerod Santo And in that time, I assume you've done code reviews. I've seen you've done political influence. Like you've done the things, like you're not, you're not just writing about the stuff. You're actually doing the stuff, right? Sean Goedecke Yeah, yeah, yeah. Just making sure. I mean, obviously, right. Jerod Santo But, you know, I want to make sure that's the case. Sometimes we just have color commentaries and they're not actually out there doing the work. So that's probably one of the reasons why you're so good at it is because you're actually living the life. Have you ever been unable to convince inside GitHub something that you want to happen or change? And you thought, I know what I'll do. I'll write a blog post about this. It'll make the front page of Hacker News. And then maybe some of my superiors will read it and I can influence change in that way. What about that, Sean? Oh, man. Sean Goedecke 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, so paranoid about writing some blog posts and then having my teammates or my manager read it and think, he's talking about me. Like, you know, why wouldn't he just come talk to me? Jerod Santo No, no, I i don't want to do anything like it's like the most passive aggressive thing you can do is like exactly you know vaguely veil it that you're blogging about one of your co-workers Or your boss or something and they do read my blog like many of my that i assume they do that was kind of my my question was facetious but i guess the real thing is there is 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 to like boomerang back into github is kind of weird even if you don't want me you can't avoid Sean Goedecke At this point yeah it's it's scary i mean because i i still you know like you've been working in the industry twice as long as me many of my colleagues have been working in the industry longer Than me plenty of people have experience i don't have i'm i'm writing from where i'm at but i i claim to have all the answers. I speak confidently because that's how I speak. But there's always the caveat of like, this is just from my experience. This is just my opinion. So it's a little bit scary to think about people reading my posts and thinking, oh, that's how things are. ([Time 0:55:14](https://share.snipd.com/snip/f898b135-36cf-4a2e-997d-17f1af32e403)) - **One Right Thing Beats Many Wrong Hours** - Doing the 'main thing' correctly outcompetes long hours spent on the wrong work. - One genuinely useful contribution can outweigh many hours of unfocused effort if it creates unique value. 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/dfde2a60-7d88-4a24-a60b-327e206b763a)) - **Write Titles That Attract The Right Amplifiers** - Craft titles that balance punch and restraint so they attract clicks without triggering flame wars. - Aim to reach intermediaries who will upvote and amplify your post to the high-quality readers you actually 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. Jerod Santo 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. Jerod Santo 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/d84c2621-f0de-4e1c-a261-8e37b66e2edc))