DO repeat yourself! (Interview)

26:06Do you know the term emotional intelligence? And if you do, do you think that you are a relatively strong emotional intelligence person? I do know the term emotional intelligence. If you'll forgive a brief digression, I have two dogs. I have two greyhounds. One of them is a complete maniac and the other is a giant baby, a big boy. Not very smart, but my mom, who's head over heels in love with the dogs, likes to say that he has great emotional intelligence. That's what she always says when he does something stupid. He's like, well, he's very emotionally smart. That's kind of where he's at. I had to say that.

26:48Sorry. About myself, no, I don't think I have particularly great emotional intelligence. I don't think that's one of my strengths. But what I do have in that area, I think I've come to via analysis, by kind of thinking through it carefully, which I don't think is how you're supposed to do it. But I don't think it comes particularly - You're augmenting the EQ for the IQ. Yeah, although I don't know if I have great IQ either. I think I just have a lot of persistence when it comes to thinking about the same problem for years. The reason why I bring that up is because I'd actually talked to a fellow just last night.

27:27As a matter of fact, my son does ninja training, not like ninja fighting, but like American ninja warrior. I think it's also become popular in other countries. that's where I kind of became aware of it but like ninja skills parkour this athleticism that's you know just uniquely different than any other sport and one thing that the guy that runs the place shared with me last night in regards to being an athlete I think this is a sentiment you share in your blog posts which why 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, you know, TDD or all, whatever it might be that makes you a good software engineer.

28:18But then you also have to have this mental toughness, this mental clarity, maybe even emotional intelligence, this working on your mind fitness. And that's something I've seen in your blog post where you seem to suggest being mentally fit. And I don't mean not crazy or being off the norm path, but mostly just the mental toughness and the mental game more so than just simply the skill game. That's really well put. And that's absolutely correct. Before I even blogged like I do now, maybe eight years ago, one of the really, really early blog posts I wrote called Avoiding Worry-Driven Development.

29:03And 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, that can really hurt a team.

29:49But there's more ways than I could articulate where poor emotional regulation makes you a worse engineer. I think I'm going to continue writing about that for a long time. jared here in post just wanted to let you know that adam had to step out unexpectedly so when you don't hear from him for the rest of the show that's why one thing i want to talk about which is tangential to this is taste i think especially with the rise of ai code gen we are seeing now that our ability to have and to influence good taste in software engineering is becoming more valuable and our ability to execute, you know, the technical bits by hand becoming less valuable.

30:38And 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, 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.

31:15Can you start there and explain kind of what that means, why your taste comes from your values and how we can actually decide what our values are? Yeah, sure. So this approach definitely comes from my background in analytic philosophy, where if we're not sure what something is, we often try to do what we call conceptual analysis on it. Sometimes, I think, a little bit bombastically called conceptual engineering. Perhaps much like software engineers call what they do, software engineering. It's a little bit aspirational. But the idea is to take this kind of concept that you're not sure about, like taste, and try to explain it in terms of another concept that you have a better handle on, in this case, values.

32:04So 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.

32:37You might care about having your code not be spread in too many different places. You can list these kind of things forever. And I call them values because I think there aren't definitive answers to a lot of them. you know exactly how important is readability compared to reliability well it it depends on the situation and it depends on you it depends on what on what you value personally um so i think most software engineers they end up with this kind of constellation of values where they you know they really care about reliability they care about accessibility a little bit or perhaps the other way around it's it's it's sort of what they're willing to trade off and what they're not willing to trade off.

33:19And 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.

34:04And I think the same thing kind of applies in software engineering. It's about being responsive to the particulars of the situation. Well, that's interesting. I'm finding that my own values, and I do think that fitting them to the project is smart. I think that's a good way to go about it because that's ultimately what you're there to serve is what you're currently working on, not necessarily yourself or some sort of ethical high ground. Although there are, I think, values that people consider foundational and they aren't willing to budge on certain values. And I think that that's a fair way to stand in the world.

34:37But 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 like starting to maybe change or like I'm ready to change them because like maintainability.

35:24Okay, in the small, not in the large, but in the small seems like, is it all that important or will it be all that important when a rewrite is 10 seconds away by a skilled developer? Or, you know, like, and I'm not saying it's here today, but I'm just seeing the trajectory. And I'm just wondering if all my values are going to change. Have you had any sort of those thoughts as this stuff is starting to percolate? Because it's getting to be pretty good at this point. And I imagine it's not going to get 0 % better from here. Yeah, absolutely. I mean, you would have more context on this than me having been in the industry longer.

36:01But 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 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. It's been what it means to be a software engineer has completely changed. and now with the advent of like genuinely capable AI agents to like writing, writing code, it's changing again. And it's, it's, it's sort of continuing to change. And yeah, like a lot of, a lot of the old ways of thinking about things sort of no longer apply.

36:46You almost want to list the things that, that like haven't changed because, because the change has been kind of so, so extreme. Although I do think it depends where you are. I mean, one, one thing I believe is like, 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. I think a lot of those engineers kind of look at discussions like these and they think, what are these people talking about? Like AI agents are just not there yet. But for somebody like me who works, you know, a lot of what I do is kind of web servers and protobuf mangling and, you know, fairly standard kind of forms of software engineering work.

37:29The AI agents are here, man. Like they're certainly good enough to help. And in many cases, they're good enough to do the entire work. And it's completely changed what it means to do the job. Yeah. 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 front end technologies and specifically CSS technologies, SVG, etc. Where I find that they completely lack the ability to do what I want them to do. And then I'm doing something else like writing some sort of static generator in Go. And it's like, I didn't write any of this code.

38:08and I've, I've helped it refactor along the way, but it's like, it's totally capable of doing this with just a little bit of direction from somebody who knows what they want and what they have some taste in the way you should go about building the system to just like guide and say, no, don't do it that way. Do it this way. And they're like, okay, I'll do it that way. And in those areas, it's like, it's very capable. And so, yeah, it's just not evenly distributed both in like technology and like verticals, but then also across the industry and what you're working on. everybody's mileage is going to vary.

38:41And 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 are they even mad like slow down to go faster i've been saying for years and it's like i don't know maybe it's just go faster to go faster now or at least it will be in a couple years i don't know i 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.

39:37Because to me, it's been almost the reverse. I've kind of used AI agents to write most of my front-end stuff, certainly for my blog. But at work, sometimes when I'm writing 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. I think that kind of just reflects, you know, you're going really deep in one area and I'm being very shallow. And when you're writing your Golang's static site generator, that's a fairly well understood problem. And, you know, when you're doing things that are less well understood, it's just kind of like, yeah, it's not so much that it's good at one technology and bad at another.

40:14It's just kind of hard to, you know, you can be doing very different things. But to your broader point, I absolutely agree. I think there's going to be a new set of engineering values that comes in when this technology stabilizes. And it's very hard to say in advance what those values are going to be, how much engineers are going to need to manually review the work of AI agents as well. I think, for instance, is still very much up in the air. Yeah, that's a really big question is how much. Right now, it's made code review extremely valuable, right? Like your ability to look at a written piece of code, whether it's from a human or an agent or whatever, and judge appropriately, is it good enough?

40:58Does it need to be rewritten? You know, where are all the problems with this? Is it going to pigeonhole us? Is it fine? Like that, I think, is like peak software engineering skill today. And maybe it will continue to be. I mean, there's people that don't think that the agents are going to get very much better at all from here. and if that if they stay right where they are it's absolutely a huge value um 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 Who cares?

41:39It was a means to an end. So just so much is just weighing in the balances right now. It's kind of unnerving. I do think readability is never going to go away. I think it may go away for like Python and Golang and JavaScript. But I think if it does go away there, it's going to kind of recede back into the prompt in a sense. So for instance, you know, writing readable coherent assembly code used to be part of the skill of any programmer. when compilers got good enough, that kind of stopped becoming part of the skillset. 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.

42:22We 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. That's some people are saying, and I don't know if I believe it, but some people are saying that that's going to like English is kind of the new programming language that your, your expression of the spec is, is, is sort of your programmer work product. And whatever it is that the, the, the, the programmer or whoever is giving to these AI agents, I think that's always, it's always going to be important that that's readable.

42:57It's always going to be important that that's understandable by humans because humans are going to have to update that when they want changes to be made to the product. Yeah, 100%. And we definitely see that being formalized in things like spec-driven development at this point. Although we're not at the point where you write the spec and that's all you write. Like you're still going beyond the spec, but maybe, yeah, maybe we get back, 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.

43:32Or, you know, like a spec is a necessary evil to a certain degree. Whereas for some reason, and maybe it's just because I've been writing code for so long, like I'd much rather read and write code than read or write specs. But I guess we do have to change with the times, don't we, Sean? Well, we'll see. I mean, the ideal specs for AI agents might end up looking a little bit like code. They might end up being kind of technically specific enough to... But I think it's hard to look at the future and say, you know, it's getting less interesting to be a software engineer. I mean, the last three years have been a period of such intense change.

44:10Whatever you might say about it, it's very interesting to be a software engineer now. There's a lot of things going on. It's very interesting right now. For good or ill. So yeah, maybe we're headed towards a world where it's much more boring to be a software engineer. But certainly if it continues like it has been, that's not what's happening. Yeah. 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.

44:43We'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 I guess take what you can get. it's the it's the great paradox of working with light language models that they're they're terrible at the things that like ordinary computer programs are really good at and they're really good at things that ordinary computer programs are terrible at like it's it's a different way of way of doing that's where the advent of the tool has been so amazing like again when i talk about the software around the models getting so much better the fact that you know chats gpt or gpt5 can't do they can't count how many r's are in strawberry or whatever like famously, but it doesn't have to now.

45:21It knows that when a certain set of things it's not good at, it's going to actually shell out effectively to a Python program or whatever it is that's really good at, or 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. Like to that was such a sea change, I think, where it's like, they don't have to be good at everything. In fact, we can limit the domain that we use the models into this very narrow corridor and then just equip it with all the tools it needs to get the answers.

45:53And that's where I think we've gotten in the last year or so, where it's like, okay, this is really good now. Yeah, I mean, this is something that, this was anticipated for sure. I mean, in I think 2020, Leopold Ashenbrenner wrote Situational Awareness, maybe not 2020, check that. But years and years ago, like long before AI was like the thing that it is today. And one of the things he wrote about in that was what he called 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 do things and then act on those things.

46:32There's been so much engineering work in systems like co-pilot agent, cursor, clawed code, codex, all of these things. That's why I'm kind of skeptical of an AI winter, because even if the models stop getting better, which they might, there's so much clear low-hanging fruit to be picked in the tooling. That's a good call. And had I known about the tool calling as an option back in 2020, I wouldn't have been calling for this plateau so easily because I just wasn't seeing the models get that much better. And I kept thinking like, okay, we've hit a plateau. We're going to need – we have to move beyond transformers to a new paradigm.

47:09But no, you can just keep equipping these things and narrowing their scope and allowing them to, what do you call it, situational awareness, to know when to call a tool and then just make the tools better, better, better, better and more context, et cetera. And you get a huge wins from that without having to have any sort of transitional step change in the actual abilities of the model. So I did not see that coming, but apparently I should have had I read that particular paper. Or I don't know, maybe you were writing about it back then I didn't read your blog back then. Not in 2020. Yeah, okay.

47:46Okay, friends, Augment Code. I love it. This is one of my daily driver AI agents to use. Super awesome. CLI, VS Code, JetBrains, anywhere you want to be, Augment Code can bring better context, better agent, and of course, better code. To me, Augment Code is by far one of the most powerful AI software development platforms to use out there. It's backed by the industry-leading context engines. The way they do things is so cool. You get your agent, you get your chat, you get your next edit, your completions. It's in Slack, it's in your CLI. They literally have everything you want to drive the agent, to drive better context, to drive better code for your next big thing, for your big thing you're already working on, or whatever you have in your brain you wanna dream up.

48:30So here's a prescription. This is what I want you to do. I want you to go to augmentcode.com. Right in the center, you'll see install now. And just go right to the command line. There is a terminal CLI icon there. Click that. And it's going to take you to this page. It says install via NPM. Copy that. Pop into your terminal. Install augment code. It's called Augie. Instantiate it wherever you want to. Type in A-U-G-G-I-E and let loose. You now have all the power of augment in your terminal. Deep context. Custom slash commands. MCP servers. Multimodals. Prompt enhancers. User and repo rules. Task lists.

49:08native tools everything you want right at your fingertips again augustcode.com is one of my favorites you should check it out well friends this episode is also brought to you by our friends over at nordlair and you know what's scarier than black friday chaos yeah you guessed it leaving your business network wide open to ransomware phishing and whoever's bored enough to poke around your systems and that's a lot of people that's exactly where nordlair comes in it is a toggle ready network security platform built for modern businesses combines VPN, access control, and threat protection, and it's all in one easy-to-use setup.

49:44There's no hardware, no complex configuration, just secure connection and full control in less than 10 minutes. The cool thing is it is designed around zero trust, meaning only the right people who have access can access the right things. Here's the best part, 28 % off. Yeah, 28 % off for the yearly plan. And the next step is to go to NordLayer.com slash the changelog. Yes, NordLayer.com slash the changelog. Use our code changelog hyphen 28. Yes, the hyphen is important. Again, changelog hyphen 28. Use that code before December 10th, 2025 for that awesome 28 % discount. And the beauty is you also try it risk-free with their 14-day money-back guarantee.

50:33Keep your team secure, your network clean, and your mind at ease. Once again, that's NordLayer, your toggle-ready shield for modern internet. Go to nordlayer.com slash a changelog and use our code changelog-28. Enjoy.

50:54Assuming 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 like such a valuable skill and doing it poorly is not good for your career. So what are mistakes that people are making and how can we make our code reviews better? Yeah, sure. So this was a pretty opinionated post I wrote and I was honestly shocked that the reception was so positive. I thought people would be very negative on it.

51:27So 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, you know, 50 or 100 comments sometimes. And I think that's just an order of magnitude too many. A good code review should have like six comments or fewer because you just can't track more than those things. Like you just, there's no way you have more than six interesting things to say about, about a pull request. Like past that, it just becomes kind of line item comments.

52:05And the problem with line item comments is, is that they, they suck up all the attention that, that like should be, be spent on like a higher level discussion. So instead of kind of, you know, commenting on in 30 different places and saying, oh, here you've used, I don't know, you've used map filter where you should be using reduce. You should leave one comment saying, you know, this is a pattern that you should adopt. And that way the person can kind of treat it a bit more holistically. That's something I believe. The other thing that people do, I think, is that when they review a pull request, they read through the diff and they review the diff.

52:42And I think that's a big mistake. I think the most interesting and most useful comments you can give in a code review are not about the diff. they're about the code that wasn't written or the areas of the code base that haven't been touched that ought to have been touched the highest value code reviews i've ever seen have been uh 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 uh 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.

53:17And 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. I think those are like the main two things I would say, which is don't leave too many comments and don't just review the diff. Yeah. So that second one is I think super powerful and I've certainly am guilty of just reviewing the diff. And so I'm feeling very, very seen by this one. And I coached some basketball, Sean. I got young boys playing basketball.

53:52I'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 would review what they were doing. You know, you didn't do this right this way. You should put your foot here, et cetera. And what was way more powerful when I realized I need to be looking at it from a bigger scope and actually telling them what they could have done instead, not what they did right or wrong, but actually they're not seeing this part of the court or here's a better way where you could avoid this thing altogether.

54:35I mean, that's kind of what you're talking about here where it's like, don't look at what they're showing you. look at the entire system and let them and tell them what they're not seeing that requires some scope though man you got to really understand the system don't you yeah i mean for sure but that's that's why it's so valuable because you're bringing to bear your understanding of the entire system that's that's why code reviews with that context are so much are so much better because they're harder because they're because they incorporate kind of a broader understanding that makes tons of sense.

55:06So you've been, are you, how long have you been working at GitHub? Oh, five years, four years. Four or five years. And, um, I'm 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 this stuff. You're actually doing the stuff, right? Uh, yeah, yeah, yeah. Just making sure. I mean, obviously. Right. But, uh, 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.

55:41Have 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. 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 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 post and then having my teammates or my manager read it and think, he's talking about me.

56:29Like, you know, why wouldn't he just come talk to me? No, no, I don't want to do any of that. It's like the most passive aggressive thing you can do is like blog, you know, vaguely veil it that your blog is about one of your coworkers or your boss or something. And they do read my blog, like many of my coworkers. Well, I assume they do. That was kind of my question was facetious, but I guess the real thing is there is like at a certain point when you have a blog like yours, which has become very well read, you know, you have more influence, not just inside of your, you know, 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.

57:12It's kind of weird. Even if you don't want me, you can't avoid it at this point. Yeah, it's scary. I mean, because I still, you know, like you've been working in the industry twice as long as me. Many of my colleagues have been working in the industry longer than me. Plenty of people have experience. I don't have. I'm writing from where I'm at, but I don't claim to have all the answers. I speak confidently because that's how I speak. But, you know, there's always the caveat of like, this is just from my experience. This is just my opinion. So it's a little bit scary to think about people reading my posts and thinking, oh, that's how things are.

57:45I'm going to change the way I work based on that. And I'm like, well, I hope that works out for you. I mean, it worked out for me, but it's not a responsibility I'm entirely comfortable with. Well, you're very good at what you do. This is why, you know, guys like me who've been doing it twice as long as you have still want to read what you have to say, because not only do you have a good head on your shoulders, but you're very good at explaining it in ways that just easy to read and resonates. I find myself nodding along to what you're saying in agreement more often than disagreement. So keep up the good work.

58:21Are 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? Like what's on your mind? What do your drafts look like? 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, you know, people take it very seriously.

58:56And 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 what have you been thinking about recently that we can maybe just put out on the table and take a nibble on? I don't think I have anything like super controversial in the queue. I tend to write my controversial posts as quickly as possible and I publish them. If something's sitting in drafts, it's probably because it's insufficiently controversial. And I'm trying to think of a way to make it a bit punchier.

59:30But 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. You can be like a grinder. You can be like heads down 100 % doing what you think is good work, 12 hours a day. And you will get outcompeted by somebody who is completely half-arsing 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.

1:00:23Some days I work a lot of hours, but some days I don't. Some days I work very, very few hours. If I'm just not feeling it, I don't force myself to grind. And one thing I've sort of grappled with is like, you know, do I like deserve my job in those periods where I'm working comparatively fewer hours? You know, am I like cheating my company out of my labor? Right. And one thing I console myself with is like, well, you know, maybe I'm only doing this day, I only really got like four hours of work in, but it was all in the right direction. So that's, that's more useful than 12 hours of work in like random, random directions.

1:01:04I don't know about that. It's, it's sort of, it's sort of uncomfortable talking about how many hours you work on the internet, particularly when your boss is going to read it. That's completely fair. I would say my response to that would be, it depends on what your company is hiring you to do, right? Like, and so 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. They want you as a laborer to put your thoughts and your experience and your intellect towards progress.

1:01:45And certainly, they probably wouldn't be interested in you grinding in the wrong direction. I mean, this is why we make fun of the 10x developer a lot but just because it's you know it's a meme at this point and of course there's people who are tech bros who act like they are these things and i don't think that's the case but i do think software is a place where it's very easy to move in the wrong direction i mean you can become a 10xer by just being a one xer because a lot of people are just doing the wrong thing and actually you know what's the opposite of progress like moving backwards You know, like it's so easy to be off and actually be doing harm, even unbeknownst.

1:02:21I mean, most of the time unbeknownst to yourself. And so being on the right path and doing the right thing is like, that's the name of the game and grinding in the wrong direction isn't getting any value. Like sometimes, however, you don't know you're grinding in the wrong direction. And so you just got to grind until you find out this wasn't right. Other times you're like, I just can't work right now because my mind isn't right. And it's like, I got no problem with it. But of course, that's up to you and your employer. I'm comfortable in my relationship with my employer. That's great. Great to hear.

1:02:59Sounds 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 like when you wield it correctly massive gains but of course when you wield it wrong you know you're going the wrong direction so yeah sometimes i think about it like this where particularly uh the more senior you get if you do like one genuinely useful thing a week that puts you ahead of i think most engineers when i say genuinely useful I mean like a contribution that would not have happened without you.

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

1:04:28You remember this one? He's running around. I saved us a nickel. I saved us a nickel. He's like running around the office and nobody cares. We're like, dude, it's a nickel. Nobody cares. and then finally he walks past like three of the higher ups and he's saying i saved us a nickel i saved us a nickel and the right person heard it and and he's like we do that operation 17 000 times a day or something like that you know like the nickel was being saved at scale nobody realized it i can't remember what the commercial is even about but i do remember that because when i talk about leverage like there's your thing i 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 no i didn't but it doesn't surprise me yeah so like there's an opportunity there where like this person comes in for an intern of course they were assigned this task i believe and it's like this one particular endpoint of a thing where it's just like 95 percent of tiktok is written and go i believe according to that post it's a lots of go and goes relatively you know fast programming language and everything but because of the nature of this particular call they like they benchmarked it they realized you know the gc pauses or something was causing it to use way more compute than it needed to and so like they just rewrote their internship was basically rewriting this one thing in rust so they could hyper optimize it and it saved them like 300k a year in compute and like those are the kind of cool wins you can get when you do when you do the right thing like when you now it was an intern so is it a unique contribution like probably a lot of people that org could have written that particular program um 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 in a couple of months well that's way more than the pain yeah i mean it's it's easier to do that in some in some roles than others for sure like Like, yeah, one, one, I mean, I, I can't talk a lot about it, but one of the really interesting things about working for Copilot, um, working in like the Copilot area at GitHub has been just the ridiculous growth that Copilot has had like financially.

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

1:07:16Yeah. It is a high stakes game, which makes it all the scarier knowing kind of, you know, the status of the industry and the lack of sometimes resiliency, the lack of resiliency and the overwhelming desire to go faster, faster, faster, you know, and to keep up and to pass. And how much is on the line now? I mean, if you look at our lives now, how much of our lives are informed or completely driven by these digital things that operate them, you know, whether it's our paychecks, our bank account, our voter registration, our votes, our education, right? Like our, whatever it is, our scores in our school, our relationships, you name it, our medical, you know, history, as well as diagnoses.

1:08:16Like everything's on there now, everything's in there. and um we software engineers are the ones that are like you know we're twiddling those bits and twiddling the wrong way and things can go poorly but also opportunity right opportunity to help a lot of people if you do it well um what else what else um i have this this is one of those things where um what is it uh was a wh orden who said that like enjoying your own handwriting is like enjoying the smell of your own farts. Um, I think the equivalent of that for blogging is like writing posts about blogging and writing posts about like the experience.

1:08:55So I, I try to do that as, as rarely as possible, but I, I have this kind of like draft I've been working on about like how to, how to write posts that kind of like people that like blow up on the internet, um, and how to write posts that like will hit the top of hacker news and stuff. and I it's this is genuine advice or this is sarcastic advice no no genuine advice like it's well you you have the ability to do it clearly you've done it on a repeated basis so your advice you have the the uh the clout what what what are your some of your just give us the quick list like what do you what do you do 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 like click baiting but I want people to read what I write and 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.

1:09:48I think it's hard to say, but a big part of it is like finding the exact right tone to hit. You sort of want like a academic article, but a little bit more colloquial, but not too much more colloquial. You want to be like way, way, way away from the kind of default, you know, GPT-4 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 going to kind of have people make the point. Yeah. The title has to make the point for you.

1:10:29Um, but it can't like the title can't be too punchy because you, 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 i didn't call it that initially i was afraid to call it that and i i turned it down and i've since kind of punched it up a bit but um if like 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.

1:11:58And 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. 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. 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.

1:12:41And now they're the ones who are actually the high quality readers that you're trying to reach in the first place. Yeah. Although I do care about all of my readers. If you read my post, I love you. I'm just over here trying to figure out which category am I, you know, what group am I in over here? To give like a concrete example that I think might like make it seem a little bit less arrogant to say this. A lot of the people who are going to upvote your post on Hacker News aren't going to read it. They're going to maybe, they'll maybe click through and like skim the first sentence. They probably are just going to upvote based on the title.

1:13:14I don't really care about those readers because they aren't readers. They don't read my posts. But I do want them to upvote so that my post gets shown to people who are actually going to read it. That's the kind of thing I mean. Like I don't have this. You don't want to also cross 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. You know, he's just trying to get to the top of Hacker News. I'm not going to read this thing. It also doesn't work. Like super clickbaity titles are not typically that successful on Hacker News.

1:13:41Sometimes they are. But in my experience, it works better to be a little bit lower key. 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 you know we're software developers and so it's very small group of people and even among software developers there's like bigger shows or whatever but we have all the best listeners like we have our listeners are I'm and of course I'm yes I'm stroking their ego right now as they listen to this and that's part of my goal but the other part is just to be honest and tell you like they're kind they're thoughtful they send us great emails they're insightful and so i've one of the reasons why i love the changelog specifically and the audience that we have here and i'm sure there's tons of crossover with your blog sean so uh i i bet you also have these same people you got me at least is that they are all the best things that you want in a listener like they don't flame they don't hate uh we get very little when we do get critical feedback which we do and we appreciate because that helps us get better it's always well stated and you know clearly with positive intent like we have awesome listeners and so hopefully you pick up a few readers from this episode well as a serious crossover going as a change log listener myself thank you i'm gonna take all that as as praise to me specifically as well.

1:15:05But yeah, I agree. You have a great audience. And I think, yeah, I certainly like, yeah, I have, I really, really treasure the messages I get from readers, the thoughtful messages. One thing about blowing up on Hacker News is that you do get a lot of very negative feedback. You do have to have a thick skin. My initial post about shipping projects in large tech companies where I was talking about how it, the process being fundamentally political. There were a lot of comments on that and have been since basically saying, this man is clearly a psychopath. I would not want to work with him in any capacity.

1:15:44I 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 tune out. Yeah. Those, I just laugh at stuff like that. That's good stuff. We've been on Hacker News a fair bit of times and we've been, uh we've we've 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 icely of software world but i think that's reserved for the r programming subreddit where uh they'll they'll also tear you apart but with like less intellectual ways of doing it i don't know if that's a i was really surprised that that reddit was worse than hacker news i thought reddit would be better than hacker news it's not reddit is so much worse the comments are so much more negative yes and reddit has a culture of like piling on especially on jokes where like if one person disses you in a funny way like there'll be reply after reply after reply of like them one-upping each other you know in like a a downward spiral of dirtiness it's hard to put yourself out there i have people like like my resume is public on the site like any post that gets sufficiently popular there's a handful of people who go and find my resume and tear it apart and they're like oh he's a staff engineer but you know staff engineer at like zendesk and github like what does that really mean i'm like i don't know what does that i'm pretty proud of where i am i was gonna say like those are good jobs dude i think so but people on the people on the internet are always gonna always gonna criticize but i think it's it's useful having my name out there it's useful it being me and it not being anonymous i think that that adds to the value even though it's kind of 100 the only problem is i've been pronouncing your name sean gadecki in my head And now, after years of reading you, I know it's Sean Gedecky.

1:17:29And so when I say that on 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. And anything else you want to say to me or to the audience before we call the show? No, that's it. Just thanks to everyone for reading. As long as people keep reading, I'm going to keep writing. Awesome. Well, to 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. Thanks so much.

1:18:05We have a little bonus segment for our Plus Plus members. It's the pre-show, which is mostly me trying to convince Adam to watch Gattaca, which he mistakes for Battlestar Galactica, which I also liked and he didn't. But not as much as Gattaca, which is worth a watch in my sometimes humble opinion. changelog.com slash plus plus if you want access support our work delete the ads and listen to us even more than you listen to us already oh and if you're just dying for this bonus but don't want to or don't have the means to give us any of your hard-earned cash that's totally cool i also included it at the very end of this episode's youtube video so find us at youtube.com slash changelog subscribe while you're there why don't you and skip to the last chapter of the episode There you go.

1:18:51Thanks again to fly.io, to tigerdata.com, to depot.dev, to augmentcode.com, and to nordlayer.com slash the changelog. Oh, and thanks to Breakmaster Cylinder for the beats. You're the best BMC. That's all for today. But we'll talk to you again on changelog and friends on Friday.

1:19:27Thank you.

1:19:54Game on.