48: How Staff Engineers Impact Software Projects and Programmer Productivity with Sean Goedecke

Brittany Ellich (00:01) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I’m your host, Brittany, and I’m joined by…

Bethany (00:09) Hey, I’m Bethany.

Erika (00:10) I’m Erica.

Brittany Ellich (00:11) The three of us met while working on a team at GitHub and quickly realized we were all obsessed with getting better at what we do. So we decided to start this podcast to share what we’re learning. We’ll be talking about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a community where engineers can learn and connect.

Today on Overcommitted, we are joined by Sean Goedecke a staff engineer on GitHub’s co-pilot team and one of Hacker News’ most popular bloggers in 2025, publishing 141 posts that collectively reached over a million monthly readers. He’s an Australian engineer known for his pragmatic, no-nonsense takes on software engineering. Sean writes about AI adoption, large company dynamics, and the realities of building software in an era where the good times in tech are over. His writing cuts through the hype and focuses on

focuses on what actually works, not what looks impressive on LinkedIn. Welcome, Sean.

Sean (01:04) Hi, great to be here.

Brittany Ellich (01:05) To kick us off, what is one thing that you are currently building or obsessed with learning right now?

Sean (01:11) Well, to my shame, I’m not spending that much time inside projects right now. Typically when I’m more interested in what I’m doing at work, my side projects just drop off a cliff. And then when I’m less interested, they kind of come back up. So if you’re a recruiter, you could probably find the right time to recruit me by paying attention to my like public GitHub contributions. But the thing I put down last was ⁓ I was trying to build this system to automatically generate cryptic crossword puzzles via LLMs. And it turned out to be surprisingly difficult.

to get it to actually generate good clues, even with a kind of checking loop or an agent loop. ⁓ The models are almost there, but not quite.

Brittany Ellich (01:51) that’s really interesting. I really enjoyed the New York Times crossword. Thanks to Erica, actually. She’s the one who got me into it. And that’s interesting, but that’s not a thing that LLMs can really do.

Sean (02:03) If you’re regularly doing the New York Times cryptic, you are much better at cryptics than me.

Erika (02:07) Okay, I guess I didn’t realize there was a whole subset of crossword puzzles called cryptic crossword puzzles. So now I have a whole new ⁓ rabbit hole to go down.

Sean (02:15) yeah.

Yeah, they’re

Brittany Ellich (02:22) a whole new

Sean (02:22) a lot of

Brittany Ellich (02:22) skill to learn.

Sean (02:22) fun. The clues are all like half wordplay, half actual clues.

Erika (02:27) Okay, okay, yeah, those are really fun. Like the Thursdays, basically the Thursdays.

Sean (02:28) You

Brittany Ellich (02:33) Brutal. Those are really hard for me and I only do them when Erica is also helping me with them. Cool. So you wrote 141 blog posts in 2025. That’s kind of a lot. That’s like three posts a week. What started this incredibly productive year? Have you always been writing this much or have you’re writing more than normal now?

Sean (02:57) I’ve always written a lot. I haven’t always written a lot like on the blog for a while. Before, maybe we can talk about this later. Before tech, have a dark past as a philosophy grad student. And I did a lot of writing on like philosophy forums kind of. And when I was a philosophy tutor at my university, I did a lot of writing. ⁓ But I only really started directing it to my technical blog at the end of 2024.

I published this piece called How I Ship Projects at Large Tech Companies, which arose out of a conversation I had with a colleague. And I didn’t expect it to be hugely popular. I just put it on my fairly neglected blog out of curiosity. And it had this huge kind of ⁓ audience. I got invited on the ⁓ Pragmatic Engineer podcast. I had a bunch of people emailing me. I was like, you know.

in a really meaningful sense, like my professional life kind of changed because I wrote this blog and I was like, whoa, okay, like I have a lot of other ideas, you know, I could write those up too, see if people like those. But there’s nothing that motivates certainly me to write more than having an audience. Like, you know, if nobody ever read or responded to my pieces, I would probably stop blogging. So as more people started reading and emailing me, I started blogging more and just kind of this virtuous cycle.

Brittany Ellich (04:25) That’s cool. Yeah, that makes sense that you were a philosophy major because I feel like a lot of your blog posts are very philosophical on tech.

Sean (04:33) That’s

a very kind way of putting it.

Brittany Ellich (04:36) ⁓

So you’re getting a ton of people talking to you about what you’re writing. Do you think that that has changed the way you write at all? Knowing that now you have this huge audience? Or has it changed the way you think about engineering at all?

Sean (04:51) I’ve certainly learned a lot about engineering. mean one thing I write about and think about a lot is that even in like a fairly long, fairly involved career, you only get this tiny window into the world of software engineering. Because if you work like, you can work at a lot of companies for a short amount of time and then you never work at one company long enough to really understand the long-term dynamics and consequences. Or if you work at a company long enough, you end up not working at very many companies over the course of your career. So you don’t get to see.

how lots of other people do things. yeah, I’ve been in the industry for a bit over 10 years. I’m a staff engineer at GitHub, but I have so little perspective on how other companies do things and how other parts of the industry do things. So to have people write in and tell me explicitly, here’s how it works in my company, that’s been really enlightening to me.

Brittany Ellich (05:43) That’s really cool. I feel like a lot of the posts that you have too that were really, really popular were very pragmatic. ⁓ It was very fitting that it took off, your writing career really took off with the beginning ⁓ being with that pragmatic engineer ⁓ podcast because yeah, we’re big fans ⁓ of that over here. So we endlessly show it. ⁓ That’s cool.

Sean (06:06) I got in while

the getting was good. I don’t think I could get an invite now. It was because it was early on. He was looking for guests and I came in at just the right time.

Brittany Ellich (06:11) you

Yeah, there’s some really big guests now. Like I just saw it looks like he has the creator of Claude bot or something like that’s yeah, super cool. ⁓ So it’s a but ⁓ like I said, so your writing is very like pragmatic and very realistic. Like, we just want to get the thing done. It doesn’t have to be perfect. Like, is there something within your career that sort of has pushed you towards that methodology? Or have you always thought like that while building?

Sean (06:20) yeah.

Well, the short answer, which we probably can’t go into more detail, but I imagine some of you will know what I mean, is ⁓ working on Copilot. ⁓ But ⁓ to flesh that out a little bit, maybe for people who haven’t worked on GitHub Copilot, it’s just kind of working in an area where there’s like such a big kind of product ⁓ focus and where the ARR, I don’t think I can say numbers, but has like grown so exponentially, so quickly. It’s just such a…

Brittany Ellich (06:55) Valid.

Sean (07:14) kind of necessarily political space to work in that you’re kind of forced to learn a lot about this stuff. But the other half of it is that I never really had a ⁓ standard computer science background. I came in from philosophy. So I think there are some habits of thought maybe that I don’t share. And one of them is this belief that like software engineers are kind of making the world a better place by building systems that connect people together and you know.

moving towards some grand future. I’ve always thought that software engineers are labor, right? And we’re in the service of capital like all other forms of labor and it of behooves us to act like that. But that’s kind a heterodox position in software engineering, as I’ve discovered by kind of writing about it and getting a lot of feedback.

Brittany Ellich (08:05) Yeah, none of us are in the Silicon Valley area, but I feel like a lot of people there would not jive as well with the idea that they’re not completely changing the world or, you know.

Sean (08:15) Well, it helps to be Australian.

It helps to be ⁓ separated a long way, like physically, from that Silicon Valley mindset.

Brittany Ellich (08:23) Yeah, yeah, I bet. So ⁓ you do write a lot about ⁓ AI topics as well. Is that because you’re working on GitHub Copilot or like did your interest in AI stuff happen before GitHub Copilot or what is the setup there?

Sean (08:40) Oh, like any

other kind of nerd of my type, I’ve been interested in AI long before AI was possible. You know, I played around with like chatbots like way back in the day, long before Transformers were a thing. I was following Gwen’s writing about GPT-2 when kind of that came out. I was an early user of like GPT 3.5. Like I’ve just been interested this whole time. I think like…

ethical concerns aside, like it is such a magical technology. if you told somebody in like the early 2010s, what would be possible with these systems, they would not believe you. So it’s hard to be like more interested in something else right now.

Bethany (09:23) That definitely makes sense. It has astounded me how much the landscape’s changed. And I know we have definitely a first-party view into it. But even as just a user of AI, it has been ⁓ very crazy how good it’s gotten. ⁓ And definitely important to know where the tools fit in, where they ⁓ help out. So this will kind of get into that. But before we…

Dive into that, I’m curious about the article you wrote about pure and impure engineering. for listeners, ⁓ you had this philosophy that there are fundamentally two different types of engineering work. So there’s pure engineering, that’s like art or research, and impure engineering, that’s more like plumbing or construction. ⁓ Do you have any concrete examples from your own work where you had to choose one of these approaches, or does it go back and forth between the two?

Sean (10:22) For me, it’s less about two approaches and more about like what you’re working on. So I’ll give some examples ⁓ before copilot one of the most interesting things I worked on a github was the The markdown pipeline which which is kind of how github transforms like github flavored markdown into text which happens You know 300,000 times on every single github github page So the core of it has to be this kind of like really tight really efficient system actually written in C the kind of

parses this markdown and access this harness for the business logic filters that are written in Ruby and have to transform the markdown for instance to render rich ⁓ previews of issues or to turn like at ASCAD key into my actual handle. ⁓ And I think that’s a really great example of like pure engineering that kind of core C library because it has such a defined goal. It’s really clear what it’s supposed to do. And all of the constraints are like, ⁓

performance constraints. all kind of like capital E engineering constraints. You can sit down on a whiteboard and like diagram it all out and come up with new designs and that’s how you work on that product. ⁓ When you compare that to say like some of the things I’ve done on Copilot around, I don’t know, let’s travel back in time like a year and a half and we’re talking about Copilot access and Copilot billing, like that is so dominated by product concerns and it’s changing all the time because of product concerns and

People are building things that need like co-pilot policies that need to behave in different ways. Like you’re never in this world where you can sit down in front of your whiteboard and say, what should the system look like? Because the process of engineering is finding out what the system is by talking to 1 million people and sort of keeping on top of like the tiger as it kind of roams the countryside. ⁓ So that’s sort of what I mean by like the pure, impure engineering. Like one is the kind of thing you can do without talking to people and without like…

constantly adapting to new product requirements. And the other one, impure engineering is when you’re kind of in that position when your product requirements are coming in all the time. And I think most engineers are in that impure position. But I came up with it not really to explain my own work, but to explain like the phenomenon on Twitter. I don’t know if you’ve seen it where like game devs get really mad at like SaaS software devs for saying things like 11 milliseconds is fast is one recent Twitter example, but. ⁓

You know, like why does, why does Jonathan Blow like really, really hate Ruby on Rouse developers? That was the question I was trying to get at when I was articulating this distinction. And then the answer I arrived at for myself was that, you know, game developers work, well engine developers like Jonathan Blow, for instance, work a lot on pure systems where they’re just kind of interested in the technical design and they can get it really, really right. But, you know, we don’t have that luxury most of the time at GitHub as I’m sure, as I’m sure we all know.

Bethany (13:20) That definitely makes sense. It is funny because I agree that it’s definitely the separation of work, but I have seen certain engineers treat almost every problem as a pure engineering problem rather than an impure engineering problem. And sometimes there’s conflicts that arise there, ⁓ which it sounds like you were kind of trying to figure out with that contention between game devs and who do have to almost always map their problems to pure engineering versus ⁓

more corporat-y ⁓ positions like SaaS devs, like you’re saying, that have to kind of keep up with the demand.

Sean (13:59) Yeah, for sure. ⁓ One other quick example of pure engineering. think most open source software work that’s working on a library, I would say is a really good example of pure engineering because you know what the library’s supposed to do. It has a defined API and most of the work you do is kind of internal on these details that are transparent to the user. that’s.

Bethany (14:00) ⁓ yeah.

Sean (14:19) That’s why a lot of library devs have this huge technical command over the thing that they’re building because the interface just doesn’t change that much.

Bethany (14:30) That makes sense. mean, if you were ⁓ taking it like a impure dev challenge, you would be probably overwhelmed with requests to make it fit whatever hole that other folks want it to fit. So it makes sense that most successful projects would be a pure engineering challenge. ⁓ I am curious. So

kind of bringing in that AI side. You mentioned in that post that AI is more helpful for impure engineering. And I’m just curious if we can dive in a little to that, ⁓ there’s reasoning why you think that it doesn’t have as much of a influence on pure engineering, or if it’s more that ⁓ folks working on pure engineering problems just aren’t reaching for that tool.

Sean (15:19) I think AI is worse on pure engineering just because pure engineering is a harder technical problem. And AI is like, you know, slowly climbing the hill of technical problems and it’s not quite at the point where it can do really, really hard ones yet. And a lot of pure engineering problems are really, really hard technical problems. That’s, think, the short answer for why it’s more helpful for impure engineers. I think the other answer is like impure engineers spend a lot of time working on systems that are unfamiliar to them. And…

when you’re in that situation, it’s really, really useful to be able to reach for AI to get you to an 80 % spot or to answer quick questions that you wouldn’t be able to answer. But if you’re an open source dev, and you’ve been working on the same, let’s say, graphics library for 20 years,

you’re not gonna need that at all because you know where everything is and you know how everything works and your problems are all kind of conceptual. The problems are never like, oh, where does the code live that does this thing? Or like, how does this library work in this case? You know the answers to all of those things because you’ve been working on it for 20 years. So like a lot of the things that AI is the most useful is like best out, just not things that you’re interested in at all. I think that’s part of the reason why, I don’t know if you remember the…

the Meta study, the METR study that showed the developers think they’re more productive using AI, but are in fact like a little bit slower. I think part of the reason why it got that result was because a lot of the developers or almost all the developers it kind of used for that were open source library developers who had been working on the same thing for 20 years. So yeah, I’m sure it was very relaxing for them to use AI, but it’s not gonna beat them. ⁓

Every time you use AI, it’s coming into the system for the first time. can never learn a code base over time, like a human can.

Bethany (17:03) Absolutely, that makes total sense. ⁓ I never really thought about it from that perspective of ⁓ using AI in a sense of it fits really well for these things for gathering context when you might not have it versus kind of the having that context ⁓ and being able to just act on it. ⁓ Do you think that every engineer should have experience both in this impure engineering and pure engineering? Or do you think that some folks just

thrive in one and ⁓ should be happy to stay in that.

Sean (17:36) That’s a difficult question. I think it’s good to be well-rounded, I have, you I don’t think pure engineering is like better. I don’t think impure engineering is better. I think if you prefer one, it’s totally fine to spend your career trying to do that, just as if you prefer front end, it’s fine to spend your career trying to do front end work or any other kind of subcategory of engineering. Like it can help to have a bit of experience in both domains, but like most things, you know, it’s hard to be an expert in both like.

If you think you can become like the world’s greatest pure engineer, you might just want to pick that.

Bethany (18:07) Absolutely. Okay, and kind of to round out this, this section, ⁓ you’ve written about tech hiring processes and that ⁓ companies don’t always hire the elite performance engineers because they don’t always produce the most business value. I’m curious ⁓ why a company would choose not to hire somebody that would seem very elite or very ⁓

able to ⁓ perform very well. If it’s talking more on the ⁓ interview side or just that they wouldn’t necessarily succeed in the company, just kind of your thoughts around that.

Sean (18:50) I think this is a great kind of like example of the pure impure stuff we were talking about just now that the most like elite performance engineers, i.e pure engineers, don’t necessarily have the kind of skills that you need in a big tech company. And this is where I think a lot of the kind of confusion comes in on Twitter where people are like, 11 milliseconds is fast. No, it’s slow. No, it’s fast. Like the hard part about working in a big tech company, very little of that is about

being able to do really strong, pure engineering work and being able to get something down from 11 milliseconds to one milliseconds. That can be useful. There are times when that’s huge leverage to be able to do that. But most of the hard things you do at a big tech company are more about being able to understand and navigate large systems. mean like systems with 10 interacting code bases, each of which is like five to 15 million lines, stuff like that, where it’s just the sheer volume of like,

logic and not just the volume of logic, but the volume of features that like interact with each other. So like if you have a simple app, you you build a feature, that’s great. But any kind of large company thing is like there these cross-cutting features that you have to think about every single time you build anything. So for instance, if you have 10 user types, any feature you build, you have to think, can these 10 user types interact with it? What happens if it’s a feature that one user can do to another? What happens about the user interactions?

if the entire product is deployed on cloud, but also sometimes on premise or sometimes in like EU data residency situations, like can your feature survive all of those situations? And then there’s, you could list 15 things like that and they all interact with each other. And that’s where the difficulty comes from in my experience working in large companies and very little of that, I think.

If you spend your entire professional life becoming an elite performance engineer, you don’t necessarily develop the skills that you would need to navigate problems like that. But it’s problems like that that are the precondition for doing anything at all in a large tech company. So you just won’t be able to use your elite pure engineering skills if you just don’t have the ability to kind of get something done at all.

Erika (20:59) Totally. ⁓ Another dichotomy you introduce is this idea of legible or official ⁓ communication and illegible or backchannel ways of working. ⁓ So maybe you can kind of unpack that a little bit for us, what you kind of mean by that.

and then what people need to consider when choosing one of these strategies in their work.

Sean (21:35) Yeah, sure. So these terms, legible and illegible, in the way that I’m using them, come from a James C. Scott book called Seeing Like a State that’s become kind of this sacred text for a lot of people in Silicon Valley and in tech in general. They don’t necessarily mean what you might naturally think legibility and illegibility means. It’s more about the kind of processes that are accessible to a large organization or state.

That’s what making something legible means. It means making it kind of measurable and accessible via setting policies. And something that’s illegible is more like, it’s a practice that works, but is just people talking to each other informally and doesn’t have this connection to kind of the official policies or the official regulations. It can’t easily be ⁓ accessed or modified by the people in charge. That’s what this legibility-illegibility distinction means. And James C. Scott uses this to talk about

what he calls high modernism or the ways in which governments have kind of increasingly pushed towards being able to like surveil and kind of categorize and list at the cost of like people actually, at the cost of like real efficiency, which a lot of the time comes from these illegible processes. So in my writing, I’ve kind of tried to bring that distinction to software companies and to kind of tease out the ways in which software companies have these kind of parallel systems of like,

legible work where it’s all tracked in Jira or GitHub issues. It’s all connected to OKRs. All the updates are flowing up and then the priorities are flowing back down, like just the way things are supposed to work. And then this kind of parallel illegible system where work is tracked by people remembering things in their heads. It’s assigned by people messaging each other on Slack and trading favors. It’s done in ways that are almost like…

impossible to kind of summarize and then account for to leadership. But you know, if you actually have to get stuff done, you need some amount of illegible work. And in fact, when companies really need to get stuff done, they carve out what I’ve called these kind of temporary zones of illegibility. Sometimes it’s called like a tiger team or like a skunk works project or some some like team that’s kind of given explicit permission to to break the legibility rules and to not report what they’re doing and to not follow the kind of

standard processes of ⁓ estimating and planning and assigning work. ⁓ So yeah, that’s what I mean when I talk about legibility and illegibility in software companies. Sorry, that was kind of a mouthful.

Erika (24:11) No, yeah, that’s helpful. Helpful framing and yeah, I can see how maybe in different situations, each of these can be useful. ⁓ How do you kind of think about it in your own work? Like when you reach for one versus another.

Sean (24:32) Yeah, well,

⁓ I will say like the one big difference between like operating as a staff engineer and what I did as a senior engineer is that I spend a lot more time in the illegible space and a lot less time in the legible space. And I think that’s a good lesson for people who like are looking to kind of really have impact at a large tech company is to not entirely focus on the legible space. one, let me make that concrete. ⁓

Erika (24:58) them.

Sean (25:01) If you’re like a mid-level software engineer or a senior software engineer and you’re like really ambitious, do not express that ambition by like doing more Jira tickets than anyone else. That is not the way to do it. Like don’t just go to the queue where work is assigned and do more of that work queue than anybody else. That can be a useful thing to do. I think that’s like almost a kind of a coming of age ritual, think for like early career engineers to just really flex their muscles and see how fast they can burn down the ticket queue.

but that’s not actually the way to have the most impact, even if that does kind of produce the most like legible performance metrics. It’s much better to kind of be a bit more strategic about what kind of work needs to be done and what kind of work is more important and to do like enough of the ticket queue to kind of be okay, but then use the rest of that time you have to kind of make more targeted bets.

Erika (25:56) So how do you capture that? mean, if it’s not measured by traditional metrics, like, what do you say in, you know, how you measure that impact if it’s not like officially, yeah, officially declared?

Sean (26:13) Well, that

impact isn’t measured on like a line by line work level, but it is measured in the success of projects. So if you have a team that’s good at doing this illegible work, what it might look like from the outside is that their like ticket metrics maybe aren’t as good as some of the other teams, but they sure do ship a lot of things. And they sure are like reliable at shipping things. it really, it weirdly, seems like they always seem to get the most important projects by some mechanism. ⁓

Erika (26:21) Mm.

Sean (26:42) and they always deliver them. Strange how those two things go together. That’s what it of looks like when these illegible systems are kind of working in a healthy way that you just, it doesn’t quite match the official kind of work assignment and planning process, but you do see teams kind of like punching above their weight grade.

Erika (26:46) Mm-hmm.

Yeah, yeah, I feel like I always see the trade-offs because like part of legibility is like the tracking piece and like part of that is like, okay, it’s kind of protecting me, I guess it’s like a mid to senior level engineer of like.

getting asked to do all these things that other people don’t want to do. There’s the idea of glue work, right? Like, oh, do this thing. It’ll totally be valuable for your promotion. And then nobody cares. Whatever. Or it takes all this extra time that I’m working evenings and weekends to get it done.

Yeah, so, but on the the flip side, like, I definitely hear what you’re saying as far as like, if that’s your bottleneck, like, there are times when that’s too slow. Like, it’s definitely true that like, there are times when if, like you are only ever burning down the JIRA or the, you know, GitHub issue board, like, you’re already behind, like, whatever the design or the proposal or the

the cutting edges, so like if you’re more on that end of like I’m creating this idea or like I’m proposing this new thing, ⁓ like yeah it’s almost like impossible to define it because you haven’t figured out what it is yet.

Sean (28:30) Yeah, I think that’s right. And there are people who like, it’s easy to spend like 0 % of your time even thinking about that because you’re so busy kind of burning down the Jira board. And that can be good. you know, like if you’re, if you want to be really defensive, like getting your Jira metrics up is a really good way of doing that, right? If you want to push off people pressuring you to do other work, like leaning into the legible systems is a really good way of doing that. There’s nothing wrong with legibility.

Software companies should not be entirely illegible. I don’t think they can function in an entirely illegible way. Legibility makes a lot of money, if nothing else. But I think there’s a certain type of like engineer or manager who kind of doesn’t really believe that illegible systems exist. And I think that can kind of really hurt you. You can really run into brick walls if you’re not conscious of this other stream of work.

Erika (29:12) Mm.

Yeah, for sure. like creating unnecessary overhead too. Like does this really have to be put in a, you know, a design document or something or can it be a discussion? what, you know, what sort of formality is really helpful or required here?

Sean (29:40) Yeah, and I think if like a member of the C staff or a VP comes to you and says, we need this like thing right now, this like new thing that comes in and you respond to them by saying, yeah, no worries. We’ll put it in our planning process and get a design doc and ADR written up for it. We should be able to start work in like four weeks. Like they will just kill you. They expect people to be able to kind of drop into the illegible mode.

Erika (29:59) you

Sean (30:08) as seamlessly as they do because of course at that level you’re doing as much consciously illegible work as you are illegible work. But if you can’t do that, they’ll find someone who can.

Erika (30:21) Yeah, makes sense.

Well, another thing you’ve written about that ⁓ we want to find out more about in this sort of topic of building your career, becoming ⁓ prepared for whatever might happen is the idea of system design and

like understanding system design as a precursor for engineering, whether or not you’re using AI. So sort of a broad question, but if you were to kind of suggest system design fundamentals for like engineers.

looking to level up or you know, maybe at any stage of their career, like what would be the top system design ⁓ concepts you would suggest that they focus on? ⁓ And has that changed at all in the last like, I don’t know, two years?

Sean (31:28) I don’t think it’s changed even a little bit in the last two years and I don’t think it’s going to change. I think the kind of primitives of system design, which I would consider, know, web servers, queues, requests, caches, that kind of thing, those are gonna be the same forever or almost forever. And they’re almost like more important in the last two years because like AI is a good at writing code, but even if they’re okay at the system design, like,

the system design is kind of more important and somebody needs to be able to like sanity check it and to understand it. Like if there’s a role in the next 15 years for engineers, if AIs get so good that they’re writing all the code, that role will be as people who are guardians of the system design and people who are familiar enough with the kind of broad pictures to catch the cases where like the model is suggesting something that’s completely nuts or completely out of step with like the way the system’s actually supposed to work. So yeah, I would recommend people.

get really competent with the kind of primitives of system design, know, understand the different ways you might use a cache, understand the different types of caches that exist, different ways you might use a queue, what are queues for, like why do you need queues? ⁓ I don’t know if you need to like get super deep into like the kind of algorithmic stuff. That’s kind of neither here nor there, but I do think any like good senior engineer, anyone who’s gonna be a good kind of ⁓ manager of the AIs in the future is.

is gonna have to have this really strong understanding of how the building blocks of a system fit together.

Brittany Ellich (32:59) Yeah, I think that makes a lot of sense. Something that I’ve noticed ⁓ working with lot of early and career engineers in the past few years is like there are some that just lean immediately on AI tools and it seems like it’s hard to, know, grok a lot of those concepts and like figure out like, this could be solved by a different system thing. Like we shouldn’t be reaching out to this API, you know, synchronously. We should be using a queue or something like that. ⁓

And then there’s ones that like clearly know those fundamentals and are able to like find those things. So my little contrarian take here is I think that a lot of people should probably, you know, try to build without AI in the beginning of their career instead of, you know, using that to speed themselves up immediately. Do you have any other, any similar like contrary takes when it comes to learning with AI or ⁓ how to get that system design experience in today’s world?

Sean (33:57) man, it feels like almost any take you have an AI is gonna be contrarian because people have such different positions about it. One take I have that I think is quite contrarian is that AI is pretty good actually. A lot of people really, really disagree with that. And another take is that AI is a good tool for learning things. A lot of people really, really disagree with that. ⁓ But I certainly do agree with you that if you were, if you’re a junior engineer, you should try really, really hard to be writing as much code by hand as possible.

And not to be farming it all out to AI because that’s yeah, that’s that’s how you get the ability to kind of be a good ⁓ driver of AI If you actually have enough enough kind of chops yourself to understand Like what it’s doing and then to be able to kind of second-guess it and sit on its shoulder ⁓ But yeah contrarian takes I don’t know every single blog post I write is a contrarian take or I’ve messed up like I don’t publish a blog post unless I think people are gonna disagree with it Otherwise, what’s the point? You know, just saying what everyone else agrees with so

All of the stuff we’ve talked about, the importance of illegibility, the ⁓ fact that the software industry has changed drastically for the worse since like 2021, pure ⁓ and impure engineering. I think all of that is sufficiently contrarian.

Brittany Ellich (35:09) That’s amazing. I love the idea of not posting something unless you think people are going to disagree with it. And I’m going to bring that to our…

Sean (35:14) I have like five posts and drafts that

I’m like, yeah, this is too boring. I’m not going to publish this.

Erika (35:18) I also appreciate that you started this by saying that the readers are the reason why you blog and then part of that is actually angering people or getting that push back.

Brittany Ellich (35:18) I love that.

Sean (35:35) I really like

it when I read things that I disagree with. I’m just trying to give that back to the world.

Erika (35:38) Yeah, it

was good. Spicy.

Brittany Ellich (35:40) wow. That’s

amazing. Well, that brings us, ⁓ that’s a great segue into our fun segment of the week. ⁓ So we do, pick a different one every single week. And ⁓ this week, we know that you are highly popular, apparently, on Hacker News, one of the top, I think you were like the third top ⁓ writer on Hacker News, most shared blogs, which is,

Sean (36:06) Mostly through volume,

Brittany Ellich (36:08) Congrats, yeah, that’s cool. ⁓ So, and everybody knows that Hacker News is where people go to, you know, get along and sing kumbaya and agree with everything that everybody says. ⁓ Kidding, of course, if anybody’s never actually used Hacker News before, the comment section can be really brutal. ⁓ So we rounded up a couple of maybe not the most spicy comments, but some significantly, you know.

some comments that folks are pointing out that a thing might be incorrect or something like that. And I wanted to get your take on them if you’re willing to subject yourself to reading the comment section.

Sean (36:49) Yeah, and I will say like taking a sneak peek at the ones you chose, you were super nice. Like, there are much, much, much meaner ones than this.

Brittany Ellich (36:58) I tried to go with ones that are not just straight rude, which actually, you know, can take out a significant volume of them. ⁓

Sean (37:05) I wouldn’t have minded.

You could come to me with the ones that say this man is a psychopath.

Brittany Ellich (37:09) Amazing. ⁓ So we did pick a couple in advance. So this first one about interviews. So ⁓ for any job hunters, it’s important that you forget this during interviews. I guess I should actually pull up what the which post it was. ⁓ Let’s see here.

Engineers look at complex systems with many interesting parts and think, wow, a lot of system design is happening here. In fact, a complex system usually reflects an absence of good design. ⁓ And this ⁓ responder, Alexander Wang, says, for any job hunters, it’s important you forget this during interviews. These are not the answers they’re looking for. You want to fill the whiteboard with boxes and arrows until it looks like you’ve got Kubernetes managing your Kubernetes. ⁓

Do you think that that is like a true statement that, you you should be like overly pointing out more complex things in an interview or is that something, you know, are we teaching engineers there to game the system?

Sean (38:10) I think it is so hard to talk about the way interviews work. Nobody spends enough time in interviews to have like accurate opinions on the way interviews work in tech. You would have to be interviewing as a full-time job on both sides to have enough context to be able to say, this is what you have to do in like interviews in general. I, it is, this is like a cynical take on like how interviews work. I don’t know. I will say like when I have interviewed, which has not been very often, I don’t do this.

I keep it as simple as possible and that seems to have worked pretty well for me. So like, you don’t strictly need to do this. But yeah, maybe. Like I have definitely worked with people who were upset that candidates were giving solutions that were too simple. And that made me very angry because that’s not how I, that’s not how I like to interview. But yeah, maybe I’m sure there are people interviewing for whom you have to do this. But yeah, I don’t know, like not everybody, right? Like there are definitely like…

I’m sure if any of us was on an interview call and somebody offered like a simple, elegant solution, we wouldn’t be like, no, no, no, it needs more boxes and lines. I worry that this kind of cynicism is a bit self-reinforcing.

Bethany (39:18) I think too, it depends on their interviewer and like if they’re knowledgeable they should be able to appreciate a simple system, but if they’re not maybe they would be impressed by more boxes. But to the answer of that too, are we teaching engineers to game the system? The answer is always yes. Engineers are going to, anyone’s going to game the system. Like I don’t think you could not have engineers game the system. Like that’s just a fact ⁓ of life. If there’s a system, it’s going to be gamed.

Brittany Ellich (39:18) Yeah.

Bethany (39:48) is my take there.

Brittany Ellich (39:50) I agree. It’s like having, you know, an example of, whoever the leaderboard of whoever’s pushing the most code per week or whatever, like everybody’s just going to have one line commits everywhere just to have the most lines of code over their friends. Very valid. ⁓ All right. Yes. Yeah. Lots of comments. ⁓ Excellent. So we have another comment ⁓ about resume driven development.

Erika (40:07) Change the same one over and over again.

Brittany Ellich (40:21) So not only theory crafting during interviews, but a lot of real life design is driven by what’s known as resume driven development. One time I was working in a body leasing company and our team was hired by BigCo for an internal project. Two months earlier, an internal employee was tasked to research the project and develop a prototype. When we started, all major set pieces were written in stone. Month later, said employee left. When we later checked the job listing, he likely applied to our tech stack, mirrored that to a letter.

He got free training, a resume and a new job. We were stuck with these decisions for three years. How do we fix that? ⁓ Do you think that resume driven development is really a thing? Is this a thing that like people are doing to try and, ⁓ know, are we incentivizing people to make poor decisions to buff up their resume so that, or even not even just their resume, but like their promotion packet or whatever.

within a company to say like, look at this complex thing I drove to completion. And it ends up being a batch of very poor decisions all the way down that people then have to maintain. Do you have any thoughts on that one?

Sean (41:29) have three thoughts on this one. The first, yes, obviously this is what we’re incentivizing people to do. Obviously people are gonna over complicate both for their internal promotions and for their next job. Yeah, for sure. My second thought is that the way to prevent this is to try and hire people who aren’t gonna fill whiteboards with boxes and lines and boxes during interviews. But if you try and hire people who prefer simple solutions that does kind of militate against some of this stuff. And my third thought, which is maybe the most controversial is that I think Regime-driven development is kind of dead.

I think resume driven development was a artifact of the zero interest rate period in software, which ended in like 2022. And now people are not moving jobs every six months and the market is not absolutely red hot. And I don’t think we’re seeing as much of this coming into a job building something really quickly in Kubernetes and then jumping ship because the market just does not currently support that behavior.

Brittany Ellich (42:21) That’s true. And I wonder if we’re going to end up with better engineers overall. I’ve heard the recommendation, like you should work at one company for a while to at least have to deal with the consequences of your actions. And so there’s potentially a lot more people that are going to have to deal with the consequences of their own decisions instead of being able to blame it on X person in the past who made this terrible decision that we have to live with. ⁓ Excellent. Hopefully. Yes, hopefully.

All right. And this last comment, this one also resonates with me. This is from Avernus. This one also resonates with me because I spent years of my life making MongoDB do things that would have been trivial if earlier developers had used something like SQLite instead. The reason they chose MongoDB, because the team was familiar with it. You’ve mentioned choosing whatever the team is most familiar with as a database choice in some contexts, ⁓ but then, you know, it’s

Is that always the right decision? Particularly when it comes to a completely, you know, having relational data living in a non-relational database.

Sean (43:28) Yeah, I mean, I think I’m just flat wrong on this one. Obviously there are cases where like if the team is, know, like if you’re choosing a programming language and the team is somehow really familiar with like brainfuck, you should probably not build your system in brainfuck. Like that’s not a good technical choice. So yeah, there are definitely cases where like the team’s familiarity is not a good fit. When I wrote this, I was thinking more about choices between like ⁓ Postgres and

My sequel like systems that are kind of fairly comparable ones may be a little better than the other but you should just pick the one you’re more you’re more comfortable with and you can adapt over time that was that was the sort of thing I meant but yeah for sure if you take that advice literally there are cases where it’s gonna lead to really bad decisions

Brittany Ellich (44:14) Yeah, valid, valid. ⁓ Awesome. Well, thank you for sticking with me through those. Yeah, they were not the spiciest comments. ⁓ But it’s fun to, I think it’s fun to see people that disagree with you on the internet. That’s a very healthy take. ⁓

Sean (44:31) Yeah, and I will

say in defense of Hacker News, like A, sometimes the comments are really, really good, as well as really, really angry at you. And B, Hacker News is not the worst place on the internet for comments. That would be Reddit. Every time my stuff has gotten posted to Reddit, it has been like 10 times worse than Hacker News. yeah. Reddit is the only place where like 80 % of comments are saying how bad an engineer I must be.

Brittany Ellich (44:46) Really? ⁓ that’s so interesting. ⁓

That’s such a crazy, I mean, like, that’s just a crazy assumption to make from like, you know, very limited public evidence of your actual engineering prowess. That’s funny.

Sean (45:05) It’s the consequence of having your resume up. People will say like, GitHub. I don’t know.

Brittany Ellich (45:11) Yes, all of their opinions about GitHub are squarely on your shoulders. Makes sense. Well, thank you so much, Sean, for joining us. If folks want to find you on the internet somewhere, where’s the best spot to find you?

Sean (45:15) Yep.

Best spot would be my website. I don’t really have active social media. So it’s just seangoedecke.com S-E-A-N-G-O-E-D-E-C-K-E.com. ⁓ Yeah, that’s it. If you Google Sean Engineering, I will probably come up at some point.

Brittany Ellich (45:42) Nice, excellent. Well, thank you again for joining. Seriously, that’s some good…

Bethany (45:45) What a flex. I know.

Sean (45:47) Ha!

Bethany (45:50) I would love

if I had searched Bethany Engineering and it’s like bam.

Sean (45:55) Hey, you should blog them.

Brittany Ellich (45:56) It’s a good point. Everybody should blog more. Everybody should write more. Excellent. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow or subscribe or do whatever it is you’re supposed to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye.