# Overcommitted | Software Engineering and Programming Insights — Full Episode Corpus > Overcommitted brings you software engineers who are genuinely passionate about their craft, discussing the technical decisions, learning strategies, and career challenges that matter. Overcommitted is where passion for the craft meets real talk about software engineering—from pull request philosophy and technical debt strategy to imposter syndrome and continuous learning, we are engineers committed to growing together and sharing the honest, thoughtful conversations that make you better at your job and your life. This file contains the show notes and full transcripts for every episode of the Overcommitted podcast, intended for AI tools and search engines. A concise index is available at https://overcommitted.dev/llms.txt. Hosted by software engineers at GitHub: Bethany Janos, Brittany Ellich, and Erika "Eggyhead" Eggemeyer (with former co-host Jonathan Tamsut). --- ## Episode 71: Closed That Tab: Agentic Identity, AI Security Incidents, and Loop Engineering - URL: https://overcommitted.dev/closed-that-tab-agentic-identity-ai-security-incidents-and-loop-engineering - Published: 2026-08-04 - Audio: https://anchor.fm/s/102586d64/podcast/play/123737796/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-7-4%2F429176745-44100-2-437aa2c46c217.mp3 ### Show notes This week we're trying something new: Closed That Tab, a segment where each host shares one thing they finally read that was worth the time. Erika brings a post on agentic AI identity and delegation - covering why OAuth isn't quite enough for agents that accumulate permissions across a request lifecycle, and what transaction tokens (an IETF draft proposal) offer as a solution. Bethany covers Simon Willison's breakdown of the OpenAI security incident, where an eval harness escaped its sandbox by chaining zero-day vulnerabilities - and what responsible sandboxing and observability should have caught earlier. Brittany shares how she accidentally built a loop engineering system before knowing the term existed: a continuously running agent harness using git worktrees, sub-agents, and a memory file to close around 20 PRs a day, including self-healing flaky tests. Links: Erika’s Agentic AI Identity Read: https://khaledzaky.com/blog/delegation-is-the-real-identity-problem-in-agentic-ai [https://khaledzaky.com/blog/delegation-is-the-real-identity-problem-in-agentic-ai] Bethany’s OpenAI CyberAttack Read: https://simonwillison.net/2026/Jul/22/openai-cyberattack [https://simonwillison.net/2026/Jul/22/openai-cyberattack/#atom-entries] Empire of AI: https://bookshop.org/p/books/empire-of-ai-dreams-and-nightmares-in-sam-altman-s-openai-karen-hao [https://bookshop.org/p/books/empire-of-ai-dreams-and-nightmares-in-sam-altman-s-openai-karen-hao/de10c251433f34d2?ean=9780593657515&next=t&next=t%2Ct&digital=t&utm_source=google&utm_medium=cpc&utm_campaign=dsa_nonbrand&utm_content=%7Badgroupname%7D&utm_term=dsa-19959388920&gad_source=1&gad_campaignid=12440232635&gclid=CjwKCAjwpqHTBhAcEiwAj2AfutEmX-YMzYIMgVuWZR8PkSmSodLqHbU_Wjt1a4m0aVklrv5PzH2AExoCl-wQAvD_BwE] Brittany’s Loop Engineering Read: https://addyosmani.com/blog/loop-engineering/ [https://addyosmani.com/blog/loop-engineering/]  Superpowers: https://github.com/obra/superpowers [https://github.com/obra/superpowers]  Brittany’s Loop Engineering Blog post: https://brittany-ellich.offprint.app/a/3mrjj34puva23-108-prs-in-eight-days-accidentally-discovering-loop-engineering [https://brittany-ellich.offprint.app/a/3mrjj34puva23-108-prs-in-eight-days-accidentally-discovering-loop-engineering] Hosts: Overcommitted: ⁠https://overcommitted.dev ⁠Bethany Janos: ⁠https://www.trustyduck.dev/⁠ Brittany Ellich: ⁠https://brittanyellich.com ⁠Erika Eggemeyer: ⁠https://github.com/eggyhead ### Transcript No transcript available for this episode. --- ## Episode 70: Open and Async Work | Remote Engineering Culture with Ben Balter - URL: https://overcommitted.dev/open-and-async-work-remote-engineering-culture-with-ben-balter - Published: 2026-07-28 - Audio: https://anchor.fm/s/102586d64/podcast/play/123358280/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-6-26%2F428666838-44100-2-78c11be3bd48f.mp3 ### Show notes Learn how async-first communication transforms remote engineering culture and developer productivity. Ben Balter, open source governance expert, shares practical strategies for building transparent, documented workflows that help distributed teams collaborate without synchronous bottlenecks—and why this matters for engineers navigating complex project ownership. Links https://ben.balter.com/contact/ https://bsky.app/profile/ben.balter.com https://open-and-async.com/ Hosts Overcommitted: ⁠⁠https://overcommitted.dev⁠ ⁠Bethany Janos: ⁠⁠https://www.trustyduck.dev/⁠⁠ ⁠ Erika Eggemeyer: ⁠⁠https://github.com/eggyhead ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Bethany, and I'm joined by Erika (00:08) Hey I'm Erika Bethany (00:10) We 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've learned. 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. Bethany (00:29) Today on Overcommitted, we're joined by Ben Balter. Ben has spent more than a decade at GitHub, starting as its first government evangelist, bringing open source to the public sector, and most recently as director of hubber enablement, helping thousands of hubbers do their best remote work. Before GitHub, he was a presidential innovation fellow and part of the White House's first agile development team. He's distilled his experience into open and async. His new playbook for building software on remote and distributed teams. Welcome Ben! Ben Balter (01:02) Thanks for having me. Bethany (01:03) so excited to chat with you. we'll start off w like we start off every episode. what is one thing you're currently building or obsessed with learning right now? Ben Balter (01:13) Right now I've been obsessed with but learning, but actually for the past two and a half, three years or so, is how to write a book not using a word processor. When I first sat down to write a book, you know, the default is you fire up Microsoft Word or LibreOffice or whatever. And it's just was such a step backwards compared to what a developer experience is on a day, day-to-day basis, right? We spend so much time fine-tuning our craft. and so I said, what if we can take that purposefulness and bring it to prose, to writing a book? And so I am guilty of very, very much over-engineering the build pipeline for the book. I figured it's a book about software development best practices. so it's built with software development best practices. Everything's in Markdown. I have CI running on every push with thousands of tests. the print and the digital version are just built as web pages. it's just CSS using Tailwind Tailwind CSS. I figured, you know, I have I have decades of experience building web pages and to build something that exists in the physical world has been a really, really exciting learning adventure for me. And then the other side of that you said obsessed. I've been recently obsessed with the interplay between AI and writing. Right? In in software development, if you used you know, autocomplete and ghost text to write a the the the the types the type Type signature for a function call or something, no one would think twice about that, right? That's just something that you have to do, and it's considered efficient. But when you do that same thing with prose writing, because writing is a form of expression, there's a lot that goes into play there in terms of, you know, are you outsourcing your voice? Are you outsourcing your authenticity? and so I drew the line, I used AI heavily for editing, but not for writing. And so I had, I mentioned I have a bunch of tests running on CI. I had tests to make sure that the chapters were balanced. That each chapter had call-outs for both ICs and managers, that paragraphs were the right lengths. I even ran I at one point I was convinced from reading the book so many times that I kept repeating myself. And so I had AI generate a n-gram analysis in order to determine if I use the same phrases multiple times across chapters. And so really using, you know. probabilistic AI to build deterministic tools to aid the human in their own expression. So applying the best of software development to writing pros has been what I've been hacking on these days. I have a blog post in the works. I hope to open source all that of course and share with the world how I did that. Bethany (03:45) I'm so interested to read more about that. I think that's been such a hot issue with AI in general is when does like creativity end and how does that tap into it? Is it still yours if you use AI at all? So I am really excited to to hear more about your process and I think we all are are l looking to learn on the best practices as AI just changes so rapidly. Ben Balter (04:14) Yeah, one of my favorite aha moments was I I I hate cliches, I'm allergic to cliches in my writing. and so I wanted to make sure that there were a CI job that made sure that there were no cliches anywhere in my writing. And I started coming up with clichés myself that I found myself writing. I said, wait a minute, you know who's really good at coming up clichés? AI. and so I just had AI generate a list of its own cliches that it normally falls back to, and then built a CI around that. And so finding ways to augment your voice rather than to replace it. Bethany (04:47) Definitely. That makes a lot of sense. so you mentioned you talk a lot about open source in your book. You talk a ton about open source and how people work in in the open and and developing this through watching that process. I was shocked when I was reading the end, I think it was your author bio that I didn't even realize you you had a law degree and business degree and you didn't necessarily come from C S. So I'm really curious, how did you find your way into open source and learning about this this field? Ben Balter (05:23) Yeah, so I was sitting in the back row of law school. I was not paying attention to whatever the lesson of the day was. and I was really falling in love with open source. specifically, I was learning PHP, I was learning WordPress, I at the time I became a core contributor and did a Google Summer of Code project, found myself building websites for campus organizations, and the plan was still always to become a lawyer, like the traditional white shoe law firm path. And I entered a really tough job market, not too dissimilar from the job market today. And a buddy of mine, who was not in tech at all, I had no plan on get on getting into tech, was like, hey, you do computer stuff on the side, like, why don't you apply for a job doing computer stuff? And it just literally never occurred to me that I could turn my passion into a profession. and so the next day I applied for the job, a job at the FCC, the Federal Communications Commission, in there with They called at the time, this is how old I am, new media department, which was what the website was considered at the time. And just fell into this path of using government procurement in order to modernize government software. And I kept finding myself that a lot of the playbooks I was looking to was just saying, hey, how did the open source community solve this problem and how can we adapt that to government? And so originally it was using open data. you know, publishing out the government's data on GitHub as the Trojan horse to really pull governments into open source. and what what really came down to me is that the the code was never the point, right? It was always about solving problems. Right? The code is the easy part. AI makes that even easier today. and so whether it's legal code or computer code, it's just a means to solving otherwise unsolved problems for collaboration. And so kind of fell into it by accident, but it's been a really great great experience since and I wouldn't do it any other way. Bethany (07:33) I think that backgrounds are so important to contributing to software and the software field. Do you ever find you're like legal business brain showing up in your i in how you think about software or even how you think about open and async work. Ben Balter (07:51) Yeah, so the first is is the fun flex that I get to do. where I used to be in tr the trust and safety space, which overlaps with legal a lot and compliance and regulatory. And there's a lot of FUD, a lot of fear, uncertainty, and doubt, a lot of lore about what you can and can't do. and it's a lot of fun to be the only lawyer in the meeting, and to be like, are you a lawyer? Because I am and I think we can do this. and in order to to get code across the line. but more but more seriously, constantly I think about it. for me and I actually work Worried about this in the book that I over-indexed on this. Law is about writing. Law is writing first, it's async, it's precedence-based, right? Like one court makes a decision and then another court references it. That's that decision record. It's cited, it's reviewable for years. That's just git history as a legal institution. I think they're they're they're really one and the same. And so thinking about how to apply that idea of proof, of jurisprudence, of having a a canonical record that you can point to and applying that to obviously much less important decisions in terms of like ADR's architectural decision records or why a pull request landed the way it did, I think they're they're one and the same. Erika (09:08) Yeah, it's interesting because even within the software development world, I have personally come up against people who either like want a more closed culture or like won't put their thoughts into writing. and yeah, I'm kind of curious how you you approach that as somebody maybe wanting to affect a cultural change. like when is it appropriate to Advocate for it and then how do you advocate for it as somebody who might want to introduce some of these more open practices? Ben Balter (09:46) Yeah, great question. I see transparency has has two flavors or two cultures. the first is transparency as a liability. That if I write something down, you might hold that against me, you might judge me for that. You know, going back to the legal question, you see that a lot of like lawyers not wanting to put something in writing because it could show up in court. And there's kind of the the court of corporate opinion, if you want to call it that, in terms of I wrote this thing down and now someone's gonna think that I'm wrong or they're gonna they'll use it again. Me in some way. The flip side of that is transparency as an asset, where you're putting yourself out there, you're building a name for yourself, you're building a reputation for yourself, you're helping others to opt in to join you and to collaborate with you, making sure that they're not repeating themselves. and you're working loudly so that others can see what you're doing, and if there is that potential liability, that potential conflict, you're not catching a stakeholder by surprise at the end. They're going to find out eventually. And so rather than doing a giant flip the switch kind of magic trick reveal, to be working along the way transparently so others can see what you're doing, more often than not, they're just gonna ignore you. They're busy. They have their own things on their minds. but for that one time in ten when someone sees it and says, hey, I saw you're working on X, have you considered why? Or I don't think we can do that, catching those problems earlier on where they're easier to correct is the power of transparency and it's just a matter of leading through example, showing the easier way to do things. If you can make it easier to work transparently, other people can see that. They can see the benefit of that. And you're not going around with a top-down thou shalt work transparently fiat mandate, but just showing people the better way to do things and the benefit of doing things just through the way you work. And honestly just making them jealous, right? Making them say like, hey, how are you able to do that? How'd you get there? and being able to point to the URL or the whatever and then they get that aha moment. Erika (11:51) Yeah, I've definitely had both of those experiences where I've benefited from learning from engineers that I've worked with who are really good at this, of documenting their thought process and and critically documenting what is fully decided versus still kind of in draft too. Like sometimes it helps to get around that feeling of like I don't want to put this down in writing to sort of like say it up front of like this is still a guess, like I still not fully sure that this is true or like I'm still investigating, but like as of this point, this is what I know to be true, and this is kind of what I've what I've found. so yeah I've I've definitely benefited from learning from engineers who do that really well. and then also kind of what you said of of asking people to kind of Do the things that you're you're hoping for too of hey, could I get that in writing or can I get an issue for that? Could I get a link for that? And just kind of like helping people build the habit through sort of a request and suggestion path. I haven't as of yet had too much pushback on that, which is which is lucky. yeah. Ben Balter (13:09) Yeah, I I go back to early in GitHub's history, before we had managers, GitHub's engineering culture grew out of open source culture, right? And it it ran like an open source project before inner source was really a an established concept. And what I mean by that is I had an idea my first week, going back to government, it was about getting GeoJSON data, mapping data from government agencies onto GitHub. I bumped into someone at headquarters during my onboarding, we came up with the idea. There wasn't a you know product review session, there wasn't a roadmap meeting. if you had an idea in early GitHub, you had to go around and you had to pitch it. You had to build a coalition. If you need a designer, you needed to convince a designer that it was something worth doing. If you needed a back-end engineer, whatever it was, a marketer. and so that idea of kind of building a coalition around ideas has really stuck with me even as GitHub grew, and we did have those more formal ceremonies around green lighting projects. And to your point of hedging when something is early and setting expectations that it's not a finished product yet. One of one habit that I picked up from a different leader at GitHub was when you're in the early ideation stage, oftentimes that takes the place in a Google Doc or a O365 file. I would have a standard template for a header that I would put at the top of every file that I'd share around, my name, the visibility. And the status of the document, and I'd say 99% of the time it was always drafting, regardless of what the actual status was. Because that just lowers the defense mechanisms of people that are reading it. They're like, I'm getting it on the ground floor. I can shape this thing. And I would say, and don't if any former colleagues are listening to this, sorry, it would stay at the drafting stage right until it was ready to be published. Just because that is the that was a hack to build a coalition. And kind of like getting people in an alpha or a beta, they kind of have that identity of being a early adopter. Bethany (15:16) That's so cool. I think that's a it I mean, part of that is also just building the safety to be wrong and to put out something that might not be finished. It just makes people more comfortable to also put out something that's not finished or to give ideas that are half baked and say, maybe this is a thing, maybe it's not, and contribute to those stocks. So I really love that that was so ingrained in the culture early on and it is something noticeable I I see even today with being able to collaborate or feel free to just not be right all the time. even if it's if it's early on in in a project's history. So that's really cool. Ben Balter (15:55) Yeah, l later in my career I I really started to tune in and notice psychological safety and how important that was for a team. I was on one team that was the healthiest team I've ever been on, that had was very the ma engineering manager was great about creating psychological safety. and I tried to emulate that as I became a people manager later in my career. especially as I had teams that had people that didn't look like me. for those of you that are listening in on podcast, I'm a white dude. and so that, you know. It's a lot easier for me to find psychological safety in tech. But as a manager, putting myself out there and being wrong, like there were times where I was kind of a little bit wrong, and I would purposely make sure the team knew that I was very wrong or that like I made a mistake so that they could see that it's okay to make mistakes, it's okay to be wrong, and be a little bit goofy about it too, right? Like let's have fun with it. Like I used to joke, every time I came up with a bad idea, I'd say something like, you know, well, I have to have bad ideas first before I could have good ideas, and just including that culture where you're not judging each other but you're yes ending and you're supporting each other. Bethany (17:02) That makes a lot of sense. I mean, speaking of this psychological safety and kind of going back to open source as a as a framework, is there anything about open source that just doesn't really translate to a company format? or do did you find that it pretty much maps one-to-one with how corporations run? Ben Balter (17:28) Yeah, I would say that successful companies take the philosophy of open source and the tools of open source, but it's not a copy and paste, right? Open source doesn't have strict deadlines, it doesn't have, you know, conferences that you need to ship by, it doesn't have investor reporting and c and quiet periods, there's no payroll, there's no HR, And it's largely consensus driven, right? There's benevolent dictators, but it's largely consensus driven. That's not how companies work. Companies need to be able to make money. I'm reminded of the day that GitHub's product org was introduced. So I mentioned that for a while we didn't really have managers, everyone just kind of pitched their own thing and everyone just did their own thing. That was great for a while, but at one point we realized that we were building like seven or eight different startups. We had our own version of sales. Force, we had our own version of Zendesk, we had our own version of like you name the startup, we built it. chat, we had our own chat app. and so the day that the product org was introduced as a a a tastemaking function. We literally went through and and for those folks that are at GitHub you can find it, it's I think issue number one in the product repo, and we listed out every single project that was in flight. And it was like 75 projects and we were pretty small even back then. and we used emoji, because of course we use emoji and either put like a ship it icon, a a snowflake icon, or a speedboat I forgot what the vocabulary was, but literally went through in the open showing what what we wanted what you know what we're picking up to do what we are leaving behind and open source isn't always good about doing that. I like to say that removing a feature is a feature and you don't often see that in open source, right? You often see like everyone like if you want to build it, great, let's just tack that onto the side. And there's not that taste making sense. And I think where we see that in corporations, in business, is DRIs, directly responsible individuals, or as in OG getup culture we call them perps. primary responsible person and I think that that DRI that can make decisions, that can be that tastemaker, they're gonna beat a committee with a mandate any day because they have that that cross-cutting reach. I think, yeah, and then the last part I'd just say is that you know there are limits to openness within a company, right? You have legal, you have HR, you have security, you have those private spaces that you don't necessarily have those concerns with in an an open source project. So I would say you take from open source that async should be the default, but it's not a dogma, right? Import the workflows that work, but don't necessarily import the government's model wholesale. Erika (20:12) Yeah, it makes me think going back to communications of whatever you say only matters if the right person reads it. Like, you know, and I think one big challenge working for like a medium to large size corporation is finding that path of how to escalate or how to find the person who is your audience. And I I haven't worked much in open source, but I imagine like size of the group is a lot of what matters and sort of in the smaller groups it's easier to propose something because you know there's only so many people who are reading basically everything, but as you get larger people can't pay attention to everything, so you have to find out how to get your message to the right people. Ben Balter (21:09) Yeah, in the book I talk about Dunbar's number, which is a psychological idea that you can only remember about or have close connections with about 150 people. I think the inflection point for GitHub when we introduced managers, or technically leaders, they weren't managers, was about 250. And I think that played out there of just not being able to keep those connections in your head anymore, and not being able to keep those one-on-one relationships. the one pro tip there that I used extensively when I entered a new code. base or a new part of the product was leaning into git and git history and git blame and issues and pull requests and it's a lot a lot more effective to be able to say the person that last changed this line of code that put this piece of copy on the website was this person. Find them in Slack, find what Slack channel they're in, ask there, then ask in the like general engineering channel, hey, does anyone know who owns the copy on this button on this page? And so I use that a lot and a lot of digital splunking of going through from the blame to the issue to the or the blame to the PR to the issue to understand why something came to be, see who's commenting on that issue. and then you know kind of kind of stalking your colleagues almost through their past work so that you can you can outsource some of that remembering those connections or remembering who's responsible for what to systems that naturally capture and expose that process just by how you work. Bethany (22:37) I definitely use that a lot. And I feel like that was tips that came with onboarding to GitHub was that way of working, that way of just being able to break down those barriers and ask folks different questions. And I still remember so many anecdotes that you gave from your talk to like onboarding to our onboarding group. And so like it the we were talking about earlier emoji to convey what your tone is. I used to never use emojis, now I use them constantly because it it really does help. like having a URL for everything and being able to get that to demonstrate what your what your work is. and so a lot of those are contribute to what you were talking about with like working loudly. And so I feel like there's nuance between working loudly and maybe bragging or self promotion or anything. And I'm curious, like, in your viewpoint, what is what is the difference between those or how do you aim towards the working loudly side if that is a there is a difference? Ben Balter (23:46) Yeah, for me the difference is the direction of the benefit. if you are self-promoting, you are optimizing for yourself to be seen. You're saying, Hey, look how great I am, look at this cool thing I did, I'm so awesome, please promote me. If you are working loudly, You're optimizing for the receiver. You're optimizing for the work being receivable and findable. So you're you're narrating as you go in a durable, discoverable medium, right? you know, at GitHub we had had the practice of writing up discussion posts after a big ship about what you learned. And I I think for the most part, people saw those as good learning opportunities of sharing information. And it's not because and this goes back even before when we had team, which was our internal internet, we had the same practice. Us there. It wasn't of, hey, look at this cool thing I did, I'm so awesome. But here are the mistakes I made, and here are the lessons that I learned along the way, so that you don't have to make those same mistakes that I did. The idea is that others can can build on it, they can catch problems early, they're not resolving the same problem over and over again. open sourcing the idea. I toiled through this that you shouldn't have to. Not I toiled through this, look how great I am. Bethany (25:05) That makes sense. And I mean it does working loudly does have the same self promo benefits in the way for getting your career development and getting promotions. And there definitely isn't anything wrong about that, but it there is definitely that nuance between, am I talking only am I self focused or am I about the team? So I I really enjoy hearing about those those nuances. Ben Balter (25:31) Yeah, well mean once once everything's captured, it's really easy to turn that into a brag doc or to turn that into your annual review. for years when review season came around, I would go to GitHub.com slash polls or github.com slash issues and just do a search for everything that I touched in that review period. I'd go through and click through it and build my brag doc off of that. As AI has emerged, I started automating that. hovers, you can find Reflect GPT, hopefully that's still working someplace. but the idea behind that is take those receipts. That you've been generating over the course of the review period and have AI just make you look amazing. And I think that's really the power of, you know, I talk about how working transparently wasn't intended to support AI, but it's a welcome side effect that once you have all that context captured in a machine readable format, you can put it out in different outputs. Bethany (26:26) Yeah, huge fan of Reflect GPT. That was what did my reflection this year and it was amazing because it's it's hard to talk about yourself. I Ben Balter (26:36) I love if if you're if you're an a AI nerd, take a look at the prompt. It's like make me look amazing or something like that. I had I had fun with it. Bethany (26:44) That's amazing. I'll have to take a look because it's it it did a great job without sounding overly bragging, but it linked to everything. I was like, man, this is definitely happening next period. So big fan, Ben Balter (26:58) And Bethany (26:58) big fan. Ben Balter (26:59) I I don't know if you're around for Thomas, the former CEO of GitHub, had a very funny line right aro right as AI was rolling out around reflecting period, about all we're doing is you're writing bullet points, having AI put it into prose, and then the manager on the other side is taking that prose and putting it back into bullet points. So why don't we just send the bullet points across the line to each other and take the AI out of the equation, which I thought was was really funny. Bethany (27:25) That is funny. I know we your your book often talked about that async first op is more equitable and levels the playing field for for different folks that might have other situations going on. and like folks that don't live in the same country and are are distributed. and You see in the news every day different return to work or return to office mandates, companies installing bossware and surveillance software. So I'm just curious, like is there any merit to that? Does async is that truly just it's good for everybody and these companies are maybe afraid of that, or is is there are genuine situations where this might not be a workable solution? Ben Balter (28:22) Yeah, I was joking with a friend yesterday, that that timing is a skill. And coming out with a book about remote work just as everyone's returning to office is just perfect timing. yeah, so I I I for me remote work is inclusive work. if you're introverted, if you're a non-native speaker and you work better in writing, if you're a caregiver, if you're in a different time zone, neurodiverse, or just like if you need a second to think before responding, I think that's for me is why I have really fallen in love with remote work, been working remotely for well over a year. decade now. when it fails people is when it's a veneer. When you say you're remote, but you're really having those conversations in hallways or conference room or the zoom after the zoom where the decisions are really made. That that thread, that issue is just theater and maybe just capturing after the fact. So someone that's not in the office is not on equal footing. you mentioned bossware and surveillance, and I laughed a little bit. I know as as we're exchanging emails, you shared an article about Microsoft Teams and Green Dot surveillance and being able to like tell what Wi Fi hotspot. The individual was on so they'd know like where in the office they were. The reason I left is because one of my favorite features when we when GitHub moved into HQ 2.0, the current one on Kali P. Kelly Street, we actually had exactly that. On every floor there were giant monitors, and it told you who was in the office, what floor they were on, what room they were in, and we even had a heat map so you can see where people were congregating. and it was one of my favorite things because I As a visiting hub, or was like, I really want to go talk to X. I have no idea where their desk is. I have no idea where they're hanging out. I have no idea where the coffee, the water cooler conversations are happening. and so and this was like we had, if I remember correctly, we had motion sensors in the lights. Like it was very, very over-engineered. but the whole point of that was not for managers to be able to see where you were and make sure you're in the office. It was to help remote folks create those opportunities for serendipity. Right. The difference wasn't monitoring, it was trust. And I think that that trust, when you see that, is in in remote work is moving from input, meaning you know, time at my desk, presence, keystrokes, the little green dot in Slack, which is more presence theater than productivity, to thinking about the output of my work, right? Issues, PRs, decision, meeting OKRs, objectives and key results, goals. when I as a people manager I said explicitly to my team, We have explicit goals. If you can hit your goal in in thirty hours a week, great. Right? Like the you're not being paid to sit at your desk. If you're not being productive, you should go for a walk, you should put together that IKEA furniture, whatever that's been on your mind. I regularly do laundry or dishes during the day. that it's it's not about sitting at your desk. You know, it's if you think about the evolution from the assembly line, where if you were building a widget, you had to be at the assembly line to build that widget. As a knowledge worker, your best idea can come in the shower, it can come at three AM. I get some of my best ideas while walking the dog. And so the idea is to manage against not bossware or presence, but trust that people are doing the work that they're supposed to do and measure them against the outcomes that you agree upon. Erika (31:59) Yeah, I I say this as somebody who does love remote work and working remotely, but I do find that there are things that can't be replicated more on that personal connection side. I still can't stand the sort of like the Zoom social meetings and you know everyone getting on a call and having fun. You know, I it's like it's just totally different. I I I don't know if I'll ever get to the point where I really enjoy those kinds of like group, group call experiences, unless it's like a brainstorming meeting or something business related. yeah, and I I do feel like having a personal connection is is important for that psychological safety, because there's so much that That can get obscured in a digital world. Like, yes, you know, remote first work can be more inclusive, but there can be a lot that gets lost with a screen in front of you, whether that's body language or you know, what whatever it might be. like there are things that we kind of pick up on as humans in those in-person interactions that just don't translate over over a digital landscape. yeah, so so it's tough. I I think kind of finding that balance, but I guess to your point, the perception side of it does help a lot and giving everyone the benefit of the doubt, you know, like when somebody doesn't respond the way that you might really expect or want them to in an async culture, taking a second Thinking like, is this personal? Am I taking this personally? like, was it meant that way? You know, how did this person mean it? And and even if you don't know them or you don't have that personal connection, starting from a place of kind of like forgiveness first before jumping into that sort of like accusatory standpoint, I find I find can be helpful. Ben Balter (34:18) I'm right there with you. I am anti mandatory fun time. I am anti cringe icebreakers. I you know, like sometimes it has its place. During the pandemic there were lots of Jackbox games and Among Us and like that was that was the right thing for the time. I I remember early in my career I would see I'm I'm not a t say not a social person. I'm not an extrovert. I I would see very extroverted people that would fill up their calendar with just social calls and I judged them. low key of like you're wasting company time just like you know just making small talk and and like why do you actually get some work done you know like the rest of us are working and at one point I realized that I had that backwards that in a remote environment that that work is work making those connections that you want to affirmatively make those social bonds before you need them so that interactions are not transactional. It's not like hey can you approve this PR and like that's the only interaction you ever have. Because that's you know, remote work can very be very lonely and very isolating. but getting to know your coworkers as humans, right? In the office, you'll see them leaving early for t-ball practice, or you'll see a picture on their desk, or you'll see that they have fur on their black shirt, so you know that they're a pet person, you don't get that necessarily unless you know a four-legged or two-something, two-legged something walks into frame. You don't get that connection. And so going out of your way to make regular social calls and find ways to connect. with people outside of work, right? So at GitHub we had social channels, we had LiveMoss for Taco Bell, Paloton, Dogcom, CatOps, and you know, as I would say in onboarding, If your boss sees you e posting a picture of your dog during the workday, you're not gonna get in trouble. In fact, they'll probably like you emoji react to that or something like that. That it that is part of your job and finding those those connections. one co-cower, I forgot how we got into this, we bonded over the movie and musical Mean Girls. And so we'd have like Wednesday wears pink days and we'd joke about that. another coworker, still mad at them for this, they introduced me to the video game Bellatro. which is very, very, very addictive. I was actually just playing it last night. And so we bond over that. And that had nothing to do with work. But then and this came up multiple times when a work thing did come up, it's like go back to the Mean Girls one, hey bestie, you know, like we already had that connection where we can we can have a serious conversation with that sense of trust and giving each other the benefit of the doubt and knowing that we're both coming from a good place. Erika (36:59) Yeah, yeah, I'm always I'm always thinking about how my communication comes across to other people too and and I I would love to have like as as I'm talking like as we're I'm reading through the book and we're talking about this like I've been thinking about how to have some feedback channels of you know is my is my communication understandable, especially when it's like AI assisted. I've I've gotten feedback from people saying this is really verbose, like this is, you know, kind of unreadable. And and yeah, I mean that's a that's kind of the the most feedback I've gotten recently about my communication style. But yeah, I have people on my team who are not native English speakers and I I don't think I'd I'd ever even thought of asking them how how clear my communication is to them until kind of thinking through all this of yeah, like does it does it make sense to somebody who's not me? Ben Balter (38:11) Yeah, I would take that in in in two directions. The first is if you think about how AI works, is it is just the mean of communication, right? It is just the average of everyone's communication. It probabilistically determines like this is what is most common for someone to say after this word. And so If you outsourced your your voice, like you you you sound like everyone, but you also sound like no one. And so in in async work, your writing is your persona, is your presence, is the primary way that your coworkers get to know you. And so yeah, you can tell, especially from like corporate press releases, executives, like when something is just corporate jargon AI slop versus when someone actually put thought into something. And then the second Direction that I would take that. And so spend a lot of time, you know, manufacturing, not manufacturing, curating your voice. I have a gist that I keep that has very specific guidance for my own voice. Like I actually like M-dashes. I've been using them for before they were uncool. I like using technical metaphors. I you know like getting right to the point, and so I keep this gist with me so that anytime I'm in an AI context and I need to punch something up, I can say, hey, grab this gist, this is my voice, put this in my voice so people know it's uniquely. me. And then the other side is longtime hover John Magic has a great blog post about not outsourcing your thinking. His blog post was in the was in the area of snippets, right, of weekly reporting. And I fell down this same path of, you know, going back to once everything's in GitHub, you can throw AI on it and get different outputs. And I did that for a few weeks for my team's weekly reporting where I would just throw AI at it and give my boss here's here's everything that happened this week. and that was doing a disservice to myself and to my team because the whole point of of going through the weekly review process is not to create the artifact that you pass up, but to actually do the thinking and to do the reflecting. And so if you outsource that thinking, you're outsourcing yourself and you can't show up for your team in the same way of versus when I say, okay, I'm just gonna have a deterministic script pull all the activity for the week and spin it out as a markdown file. verbatim and then I go through and curate that, I see start seeing those connections of hey, I need to jump in and help this person, or hey, they're falling off track, or hey, they're doing a great job. They need to shout out. And so thinking about what you outsource, which, you know, the boring stuff, like going back to that type signature, like what's the writing version of a type signature that you might outsource in terms of taking something that's written at one level and writing it for a different level or a different format. or looking at you know checking pros, checking tense checking, you know, making sure that there aren't spelling mistakes. but definitely you don't want to j to be delegating judgment, voice, taste, decisions, those still need to be remaining uniquely, uniquely human. I actually noticed that it was interesting, I noticed that a few times. so I used AI very heavily, as I mentioned, not for the writing, but for all the stuff that comes around it. So like I built my marketing site for the book, and there were a number of times where I noticed that the again going back to the the AI gets you to the mean, it does what everyone else does. And the playbook for publishing a book is very writer-centric, right? It's I need you to write a review, I need you to read this. And you know, the value where humans can can really add is not doing what everyone else does, right? That produces boring outputs, but thinking, like, why what what actually are we trying to solve here, and how can we come up with a novel way to solve that? And so making things in this case more reader-centric was going against the normal. Going against the AI, but was a sense of taste and judgment that AI couldn't bring to the equation. Bethany (42:06) That's I mean, you've talked a lot about your your process during this conversation and I I really enjoy especially hearing about the the writing process, like where you use AI, where you don't. I'm curious, like maybe we can take a step back and would love to know what you consider the async first stack to put it in like programmer terms, like the stack that you think is best or most conducive for async work. and is there anything that breaks if like not everybody is fully invested in that? Ben Balter (42:43) Yeah, so I think chat in in Slack or Microsoft Teams is great for ephemeral communication, right? Or or coordination, right? It's that incident, it's the you know, we're we're shipping something, we need to get this out the door. but I also think that in many places chat is where information goes to die, right? In in the book I use the metaphor of a camera roll versus like an Instagram post, right? That chat just has everything. It's a stream of conscience, there's no expectation. Of polished, there are typos, information gets outdated, that's the camera role, right? Versus like that Instagram post that like you curate, the influencer gets the right angle and the lighting, and it's designed for the consumer, right? And it's the difference between: am I writing this for me to get it out there, or am I writing this for the future receiver or long tail of recipients to be able to read it? So chat is for coordination, short-term, near-term. The next level of that stack would be issues or discussions. I think that's where the actual work, the actual decisions, the actual knowledge is captured. Those are long-lived. And there's a expectation that you distill your thoughts into writing, into something that is long-lived, and that it's updated over time, right? If something's no longer up to date, you post a comment on it, you update the issue, whatever it might be. So that's where the durable knowledge happens. and then meetings. I don't think meetings are a dirty word in the async world. I think they get a bad rap because A lot of corporate culture defaults to meetings. It's hey, let's just jump on a quick sink to to kick off this idea. And like the the meeting being the starting point of any effort versus the way I think about it as an escalation point. you escalate either because of the complexity of the situation, if it's, you know, an ongoing incident, you know, joining joining the war room bridge to to talk through in real time, and also the urgency of the situation, right? If if prod is down, you probably don't want to wait for an issue and like that perfect writing. You want to get the information across as quickly as possible. You ask what breaks. for me, what breaks is decisions. Right? You see this a lot if teams work exclusively in chat. It's really hard to define what was decided. I like to say that a decision without a URL, going back to the law analogy, a decision without a URL gets relitigated forever. Right? You keep going back to what did we decide here? Why did we decide that? And you keep you catch this churn. And I think the value of async, even though it might feel slower in the moment, you get better decisions faster. Faster because you take time up front. You shift left in your decision making to get rid of all that ambiguity, to chase down all those edge cases, to get s an our durable artifact so that you're not going back and revisiting decisions again and again because you thought you're on the same page, but because of that informality of chat, there was there was some wiggle room there. Bethany (45:49) Man, who among us has not tried to search Slack against the cutoff for for context on a crumb of context on decisions that were made. So that is very real. I think that durability is so important and very very missing a lot of times and it's so team by team dependent. So I think you you hit the nail on the head of that decisions needing that documentation and that durability makes so much sense. Ben Balter (46:20) and a quick pro tip there, if you have the Microsoft app that's Microsoft, the GitHub app installed in either Slack or Microsoft Teams, you can right-click on any message and it'll automatically open up an issue. And I don't it's there's like an open and issue button. and then I don't know the current state of things, but if Copilot is in Slack or Teams, you can also ask it directly from the thread to open up a pull request to capture what's there in documentation. the number of times when I was responsible for GitHub's intranet, the hub, and And someone would come in with a feature request, and in that thread, I'd just be like, hey co-pilot, can you just go do this? was a fun, fun flex in terms of being user-centric, but also pulling things out of Slack and capturing it and you know discussing things in in demos, not memos, of like, hey, is this what you were talking about? Because like this feature is now in preview, you can take a look at this, let me know if this is what you wanted. So, pro tip: try to use tools if you are using like chat is great, you should use chat, but use tools to capture that context outside of chat when the time's right. Bethany (47:27) that's so cool. I had no idea about the right clicking. I knew you could tag it and stuff, so I am definitely going to use that heavily now. Yes. Yeah. Ben Balter (47:34) Yeah, and and GitHub has specific tooling called Xref that will also cross reference across, but the native GitHub app it'll pop up a little modal and I'll like have the contacts and you can like issue, title, body, everything, and it'll open the issue for you. Bethany (47:49) XRF is my best friend unless I'm in a private channel. and then it's like, you can't do this from a private channel, silly. And I'm like, So I I love that you can just right click and and create an issue from Ben Balter (48:02) Yeah. Bethany (48:02) that. Amazing. so I know we've talked a lot about AI and like writing, outsourcing, thinking. there's a lot of commentary around slop that is thrown around nowadays, that typically references the AI generation, whether it be PRs, issues, and whatnot. so w in this world where people can kind of be loud for free or like outsource their thinking, which is kind of what you were hitting on, where can managers and engineers kind of find that signal through through the noise? Or is that even a problem? Is that even something we have to worry about? Ben Balter (48:45) Yeah, you y you mentioned work loudly, which is a a phrase that I I use frequently, and it might be the wrong phrase these days, because it's not about volume, right? It's not about how loudly you can speak. It's the whole point of async is that the loudest or fastest to unmute isn't the one that gets heard. AI can generate artifacts, AI can generate more content than humans can consume, but it can't generate your judgment. And so, you know, going back to the idea of of weekly reporting, the the Signal just moves up a layer in the stack. So rather than being this activity happened, it's about curation, it's about taste, it's about understanding what matters and putting it in context that the AI doesn't have the ability to do so because it doesn't either it physically doesn't have that context or it doesn't have the the the the knowledge. The the and so I think trust the artifact still survives in a world in which AI is creating artifacts because you know they're checkable in a way that vibes never were. It's not like I'm at my desk, you still have that artifact. but for managers it's more about judging the outcome, not just like you know, like w We the industry went through that time where number of PRs was a metric and then we went through that time where number of tokens consumed were a metric. And so moving beyond those vanity metrics and looking actually at the content of the artifact to what there what actually is there, the substance of what's there, rather than just the fact that the artifact exists. So quality over quantity. Bethany (50:23) That makes a lot of sense. And like a lot of that I think is the perspective of the writer, which is great. do you have any suggestions for anyone who feels overwhelmed by the amount of artifacts that are coming through or how they can sift through that? is that something that they can also use AI for or do you have any tips for that? Ben Balter (50:42) Yeah, one one issue that I kept coming back to every time we made a like communication architecture decision at GitHub was the concept of tragedy of the commons, which is a economic philosophy. The original one is like imagine a field in the middle of a village and everyone has I think if it was sheep or cows or whatever it is, right? Like any individual is incentivized to let their sheep graze on the the commons in the middle of the square, but if everyone does that, then there's no I don't know what sheep eat, grass left for sheep to eat. and so you you see that same thing with individuals that optimized locally for their own communication, for their own need to be heard, right? A lot of channels, whether they be the engineering channel, the general channel, the engineering repo, whatever it might be, are a commons, right? And if the individual optimizes for their own needs, you're gonna run out of grass. Well, this metaphor is going nowhere. Okay, we'll back out of. this one. but y you get the point, right? You need to think about if everyone d does this, like how how does I guess it's a matter of of systems thinking, right? Like if everyone does this, how does that affect the system? and so for individuals that's just curating ruthlessly, right? Like knowing, yes, in an open environment, you have access to all this information, but what do you actually need, right? Like what is what is essential for your job versus what is just interesting? and then also what can you batch and curate, right? Like what rather than getting the fire hose of notifications as soon as they open up, like what save search can you have that you run Friday at four o'clock? needing to to to constantly be online, right? Like I even even day-to-day very tactically, I wouldn't keep Slack open most of the time. I wouldn't keep issues open most of the time. I would finish a task and come to an actual stopping point or hit writer's block and just need a break and then open up Slack and batch a bunch of responses. Open up issues and batch a bunch of responses. And so just being conscious of your own information diet that you're not just kind of the metaphor comes full circle now. Not just great Praising information throughout the day, but being purposeful about having meals and watching what you eat. Okay, I'm not gonna continue this metaphor anymore. The last thing I will say as a pro tip, and you might remember this from onboarding, you talked about the fire hose of information. If you're making the transition to an open or asynchronous organization, you will be hit with a fire hose of links. I used to joke that URLs are Hubbers' love language. They should it's how they show you that they care. And so as we You are onboarding or adapting to an open async environment, you're gonna feel overwhelmed at some point. You're gonna think that the company made a mistake, that you made a mistake, you might get imposter syndrome. and the advice I always give there is don't listen to anyone that didn't say that happened to them. That happens to everyone as they transfer to or transition to an async environment. If they say it didn't happen to them, they're a dirty stinking liar. Do not listen to a word they're saying. Find someone find a different mentor, find someone else. the company didn't make a mistake. It's just a natural part of evolving to that fire hose information and you will recalibrate to understand how to process that and get a sense for what you need and what you don't. Bethany (54:16) That makes a lot of sense. And I love the metaphor of tragedy of the commons. I was trying to rack my brain where I've heard that and it was from Thinking and Systems, which you were mentioning th systems thinking. So I think it is absolutely relevant in so many layers. So that's that's really awesome. Awesome. Well, we are coming to the end of our main segment. and just like a personal anecdote, but this book really came at a at a great time. Like I a lot of times I get in my head about staying on Slack or that green dot and things for myself, not because it's being tracked, but 'cause I I'm like, I need to rank this up. But like this week my my dad had opened heart surgery and he's been recovering in the hospital. So I've been back and forth between home and the hospital, like keeping him company and stuff. And it's been a good reminder. Like I've set my Slack status. I've been like, I am not attending meetings this week. I am going to be away. I'm just async only. And so many people have reached out and been like, hey, I hope everything's okay. And respond at your leisure. But but like take your time. And so it's just been a really good reminder, like a lot of these practices on how to stay visible while in the situation where I'm not necessarily in meetings or be able to hop on a call at a moment's notice. So really appreciate that. Ben Balter (55:33) Yeah, that's awesome to hear. You you reminded me of a a happy little accident that happened. so over the the lap most recent holidays, I was not going anywhere, so I was working and mostly just hacking on open source and just having fun. but I didn't want my team to see that I was online and think that then the reverse of the green dot the reverse green dot of like them seeing my green dot so think that they need a green dot. And so I set myself to a way in Slack. So I did I even though I was on Slack, no one could tell that I was. I was in like incognito mode or whatever, ghost mode. I forgot to turn it off for like months, literally months. And it wasn't until like May or something when I realized I still had it on, no one said a single thing. Right? Like that it just it just is really a testament to the culture that, you know, you have I have a friend that asked to borrow my Flipper Zero to use as a mark mouse jiggler to get their green dot so they can go out and have a mental health afternoon. by the way, you can expense it, highly recommend it. That's a lot of fun to play with. versus us where like I accidentally had my statuses off. for months and and no one said anything. So I think that's that's really the testament of asynchronous culture that it can really adapt to your life if you can create that le that level of trust with your coworkers. Bethany (56:46) 100%. Trust is often paramount there and it's it is great to work at a place that has that trust and with people you you can lean on and stuff. So awesome. Very very cool. okay, so moving on to our fun segment. I was proud of this one. so you know MTV cribs, like where they're showing their their house and stuff and where they live. so I thought we could do overcommitted cribs. so I just really want to talk through like if you have your like current or ideal remote workspace, if you can describe that and then maybe if I'm fancy enough at editing I can edit in some images of of those in post. but I would just love to hear about it. I'm happy to go first to give give some time to think but when I was creating my work from home space, my my office. I I was trying to think of what's my like where have I felt the most productive in my life? And the answer was my the college library where I I went to college and it was like a very seventies library. Like it was clearly built in the seventies. It went underground. It doesn't sound like a very pleasant place, but it was it was very nice and cozy. And so I was like thinking, okay, I need like wood and like Yeah, books everywhere. So that's how I kind of came to my my current office is lots of wood, lots of panel like wood accents and then my bookcase and stuff with a little bit of whimsy and like fun things thrown in to to to bring out my personality. But that's that's kind of what I I really liked. But I have a lot of tooling around my desk that I don't necessarily use, so I wish I I had things that I need to figure that out. that out next. Like what is my happy space with like do I need a Stream Deck? Do I need this like terminal E Ink thing right there? I don't know, but just need to figure that part out. Erika (58:51) My like current My my current work setup, I really only like need two things and it's a standy desk standing desk and a natural source of light. that gets me through the day most of the times. But when we're talking cribs and the most ridiculous thing you could think of that you could have, I would definitely have an on-call masseuse just like standing by. So like, Ben Balter (59:21) Ha ha ha. Erika (59:22) you the like pomodoro breaks, like I get like a little neck massage, like, you know, every every couple of hours. And I I think that would really yeah, that would really amp my productivity up. Bethany (59:34) Sabe, can we firma that? Ben Balter (59:37) You can. At least you used to be able to. Bethany (59:42) Erica. Forma is our our we can expense things on Forma, so Erika (59:44) Yeah, I think I think I would blow my form of budget in like two days if I hired a personal masseuse. So Yeah, to Bethany (59:51) But think of the productivity. Erika (59:53) work two days a year. There you go. Ben Balter (59:58) Yeah, I I know if there still is. There used to be a Massus at GitHub headquarters that you could sign up for if you were visiting. Bethany (1:00:05) Next time I visit I'm checking because that sounds amazing. Ben Balter (1:00:09) Yeah, I'm a big fan of the standing desk. I'm a relatively recent convert to standing desks. I take every meeting standing. and I can't imagine doing it any other way. It just feels a lot more natural to me, especially if you're presenting. I used to be on the speaking circuit when I was doing what we now call DevRel, and so I'm used to being on stage and walking around if you can't if you're watching the video, moving around a lot. and so the standing desk has been a big part of my work from home setup. if you're looking for a project, I haven't implemented it yet, but I found on like Kickstarter or whatever, there's a product called the Upsy Desky. Up ski deski? It is Like an ESP32-based IoT device that plugs into your standing desk and you can then control it using automation. It like just plugs into the Ethernet port of the standing desk. It like a man in the middle is it essentially. And so my goal is to have it sync with my calendar so that as soon as a meeting is about to start, that the standing desk just starts rising up and gets gets in place automatically. The other big one that has really changed the way that I work, and I'm using it right now, I actually have a teleprompter. And I'm a huge fan of it. A coworker had one and I was like, wow, your your camera's great and your you know, I thought I would use it for like a teleprompter, like sc streaming notes and presentations. I have the El Gato teleprompter and it just shows up as a third monitor. so you can just drag screens on it. So right now I just have the recording screen on it right now. I can see all of you. I really like it because it's a lot more natural for making eye contact. and then the other benefit there is I actually use my iPhone as my camera. I have tried so many different webcams and could not find a webcam that I liked. and so the idea of just like every time I upgrade my phone, I get a new webcam with the best camera in the world has been has been a really great quality of life improvement for me. walking path. I don't use it as much as I should, but I'm a big fan for any like listen-only call, just walking on the walking pad, getting your steps in. Or if you have like an all hands, I usually go to the dog park and take the dog for a walk and call all pause. That was one of my favorite work-from-home hacks. And the last one, which I think is is a flex, is wired Ethernet. and that has helped me you know, we've all been there where Zoom freezes and it's like, I think it's you, maybe it's me, maybe no, no, it's definitely you, because I have wired Ethernet, it's not my Wi-Fi. and that has just been really great for confidence and being able to trust my connection. I don't know that I noticed the speed benefit as much, but just knowing that you know, your your your Zoom presence, your team's presence, that's your connection with your coworkers and just really all the the content the count the the constant between all those. is just really investing in leveling up your persona, just as you would, you know, clothes in the office or you know, the car that you drive and or whatever else it might be, of really just being purposeful about how you show up in a remote environment. Bethany (1:03:16) Man, I'm taking notes because I want all of those basically. I I'm so on the fence about the walking pad because I don't even use my walking or my standing desk right now, but I don't know, this might this might push me. Ben Balter (1:03:31) and you mentioned photos. I will get you photos. I just have a Bethany (1:03:34) Yes. Ben Balter (1:03:35) mess of wires in front of me right now. I have a very nice chaos monkey that is our four-year-old that every time I get back to my desk, things are unplugged, things are plugged into different places. so I I need to get some wires sorted out and I'll send some photos over. But it's a great way to know that if something breaks you have fallbacks for your video conferencing when your microphone is just randomly unplugged. Bethany (1:03:59) That makes sense. But I mean you're you're growing a little cable manager in in Ben Balter (1:04:05) Tw. Bethany (1:04:05) practice, so they're gonna be so good when it comes to remote work on cable management. That's that's a win I think. Well, Ben Balter (1:04:12) Exactly. Bethany (1:04:15) we will let you sit now, but beforehand, where can folks find you? Ben Balter (1:04:21) open an and async.com. A book just came out. There are you can get it where anywhere books are sold. I write regularly at ben.balter.com where I just kind of throw thoughts into the void. Highly recommend the book over my random thoughts into the void. it's it's much more curated. and I'm on Blue Sky at Ben Balter. Ben.balter.com. so yeah, looking forward to connecting folks on the internet. Really, really glad to be here and to have this. conversation and hope folks found it helpful. Bethany (1:04:55) Awesome. Thank you so much, Ben, for joining us. This was such an awesome conversation. I've learned so much, and the book is truly fantastic. So, seriously, whoever's listening, please read it. Please go out and get it. It is awesome. so thank you so much, listeners, for tuning in to Overcommitted this week. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week. Bye. --- ## Episode 69: Building Terminal Graph, a Spatial Development Environment, with Caidan Williams - URL: https://overcommitted.dev/building-terminal-graph-a-spatial-development-environment-with-caidan-williams - Published: 2026-07-21 - Audio: https://anchor.fm/s/102586d64/podcast/play/123105200/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-6-21%2F428324424-44100-2-11443666b52ba.mp3 ### Show notes Caidan Williams put your terminals, browsers, editors, and AI agents on one infinite canvas. He joins Erika and Brittany to talk about Terminal Graph, the spatial development environment for macOS he built for himself first, and the self-taught path that took him from Minecraft mods at 13 to partner at a Seattle dev studio. We get into the dataflow model that sets Terminal Graph apart, like piping a git diff straight into Claude Code or grepping a dev server's logs into a browser node. Caidan explains Blueprints, his approach to sharing a whole team workflow as a single file, and what it's like to run a product inside a holacracy with no bosses and no venture money. Then he tells his career story. No college degree. A gap year spent applying to around 500 companies. Computer vision on dental and MRI images. Burnout, a layoff, and a cross-country move to Seattle with one duffel bag. His honest takeaway is that persistence, not raw talent, is what got him here. If you build your own tools, wire agents into your workflow, or you're finding a non-traditional way into engineering, this one is for you. Links Terminal Graph: https://terminalgraph.com/ [https://terminalgraph.com/] Caidan Williams: https://caidan.dev/ [https://caidan.dev/] Tools mentioned LazyGit: https://lazygit.dev/ [https://lazygit.dev/] Neovim: https://neovim.io/ [https://neovim.io/] Hosts Overcommitted: ⁠⁠https://overcommitted.dev⁠ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbnllT3pGVnRrTFJKcUpQTWtlX1IxWjVIcWE2QXxBQ3Jtc0tub09tQ3MyMDZjdFpINVowMnhaT3FyMFpyTHlKUXhCdDJOcGF3Y2RwRjNLWkVyazZ3UzIxbGo0bWMxNUpLTEV5T1Z0OG5Kc3F1MGtvTWJaOVRKd05paWVweDdBaGtrMGNia3c5WFpvTnB5ZElYVjNNcw&q=https%3A%2F%2Fovercommitted.dev%2F&v=9VXK9TzqmmM] ⁠ Erika Eggemeyer: ⁠⁠https://github.com/eggyhead [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqa1VnTi0yUUZZeHRSYzIyMGpRSU10cjl5ZVo1Z3xBQ3Jtc0ttdG9jME03V3B6dUY1eWczalBaNjJTM3hPWUc0eXZlTGhKNEVMY1hfVTB3M3pYOGNjWm1Hc1pmMWRzZUdWNXBmUUpibk1DYUtGa2NrNVJpZzJZN1JTOE54RThOdU9FLWlzQUhpTDJkWmE2RHNhNnpaaw&q=https%3A%2F%2Fgithub.com%2Feggyhead&v=9VXK9TzqmmM] Brittany Ellich: https://brittanyellich.com/ [http://brittanyellich.com/] Follow Overcommitted so you don't miss next week's episode, and share it with an engineer who'd like it. ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Erika, and I'm joined by Brittany Ellich (00:07) Hi, I'm Brittany. Erika (00:09) We met while working on a team at GitHub and quickly realized we are obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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 Caidan Williams, partner at Internet Development Studio Company and the creator of Terminal Graph. Welcome, Caidan! Caidan (00:37) Hi, thanks. Erika (00:39) To kick us off, we'll ask you what we ask everyone. what's one thing you're currently building or obsessed with learning right now? Caidan (00:47) it has to be terminal graph. I've been working on it for a couple of months now and I'm spending weekends and nights, just getting it out there, working on improving it every day and doing a lot of like, experimentation. this is a tool that I don't think I've ever really seen anyone build before. So the prior art for it is very slim. and so it's been an incredible engineering challenge and very fun to flex the creative process and like play and experiment and see, what feels good. And like, even just trying to figure out the direction of where to take some of the features. Erika (01:23) Very cool. for our listeners who may not be familiar familiar with it, could you describe terminal graph and what it does? Caidan (01:31) Yeah, so my elevator pitch is it is the next generation of development environments is how I like to think about it. Essentially, the way to. think about it is starting from the problem, right? Every developer has their own workflow, their own ways of developing different tools, different apps, whatnot. But the underlying root cause of it all is that it's all scattered. You have 10 apps open and 30 browser tabs. have multiple workspaces and various, your desktop's just cluttered. I thought, wouldn't it be really cool if you could just take all of those and put it on a giant canvas, kind of like Figma. Have each window there, you have terminals, you have browsers, you have notes, you have file editors backed by VS code. You have tons of different ways to do development on a single canvas. And to take it a step further, to be able to connect them and pipe data between each of the nodes. can connect a terminal standard out to another terminal standard in, you can connect a terminal standard out to a utility node that greps for, you know, like a, a local dev link and then pipe that into a browser node to update the URL so that, you know, every time you run your dev server automatically opens this browser node. I was working on recently developing or redesigning the terminal graph website. And it's just been such a pleasure to do web development in this. I have Claude open in one window. have lazy git in another, I have neovim in another node. And then I have the dev server in another one. And then I have the full screen desktop browser node, and then a mobile version of the browser node there. And it's just all in one little view. And honestly, I love it. I built this tool for myself. as a bit of an experiment to kind of see if this was even really possible. And I started to realize that tons of other people are very excited about it and also get a lot of joy and utility out of using a tool this kind of way too. Erika (03:33) Yeah, for sure. you know, we talk a lot about context these days and like as it relates to agents and giving your agents context, but ultimately it comes down to can you keep everything in your head at once and how are you managing all the various windows and terminals? So having that so visually clear and then also having the connection between all of the all of the things talking to each other does sound really valuable. Yeah. Caidan (03:59) Yep. Erika (04:00) so you said you you're basically building this for yourself, but you're also releasing it, private beta is happening this month or is out now. Caidan (04:12) I built the first version of it in two weeks. after the two weeks, I collected a bunch of emails and I did a private beta just to iron out some of the bugs. And then I realized I didn't want to manage emails and, you know, send out updates that way. So I was like, uh, what the heck, you know, I'll make a public beta. Um, and so built out a website, added sparkle and appcast updates and all the stuff. Um, and. After that, it's been in public beta since then. Uh, I do have plans to release it as like, um, a V1 eventually, but there's still a lot of kinks to iron out first. Erika (04:49) Cool. So what took you from idea to execution what was the thing that took you from, hey, this would be really cool to build to actually I'm gonna sit down and do this? Caidan (04:59) Yeah, what a great question. I think it's a, it's a combination of a few things. it was a little bit just driven by my internal desire to build. just, I love building things. I'm a bit of a Linux nerd, so this is like backed by Unix pipe files. and I was like, wouldn't it be cool if you could like connect to terminals and like pipe data between them. and I was like, well, you know, like, you can just do that with Unix pipes on command line. Like that's not very intriguing, but What if, you know, you could connect multiple terminals to one output, right? Doing parallel processing as such, which is I I've seen people do it online with various CLI tools, but it's not intuitive. It's not easy to reason about and there's no visualization. So making bigger connections is really tricky with just a line of text. so that was a big inspiration. It's like, is this even possible? Like, is this something that can be done? and once I built out that initial iteration and kind of prove that it works, I got really excited and I was like, okay, cool. I have two terminals connected and they're sending data to each other. Like, awesome. what else can I do with this? And so I added, you know, a browser node. had a web kit, Safari web kit, a web view, which is, super nice and allows me to like, I kind of have to inject some custom JavaScript to like. get some data in there and pipe it out and whatnot. but added that added, you know, file notes, node or like other notes, and started expanding, expanding. I had a bunch of utility nodes to like help manage things like switches, gates, delays, collections, you know, a bunch of other stuff to help with the data flow. and partly the other big inspiration was that, int dev We've been doing a lot of client work for a long time. And as one of the partners, I've been wanting to push us towards doing more product work so that we're not so heavily reliant on maintaining, like continuously getting, contracts to, to keep our studio alive. and so I'm hoping that I can turn this into a successful product that not only developers love and benefit hugely from, but can also help our studio survive because we're not venture backed. We're just a small team of folks who are keeping the shop open with the hard work we do. So those are the big inspirations and kind of why I went down this direction. Brittany Ellich (07:24) Was there anything in particular that drew you to like, yes, this is the project to to get that product work done? Or is it just like you started building it and you're like, wow, this is very useful for me. Caidan (07:34) yeah, I think it's just, it came from a desire to have a better workspace, for myself. I, I've been living in the terminal for the better part of a decade now. I use NeoVim I use lazy git I use all the CLI tools, you know, fuzzy finder like name it. I've probably tried it. and so I love it. I don't have anything against GUIs, but, I kept seeing all of these, three panel coding apps, right? Like conductor and codex, it's like left side is like the workspace or like some list of things. You have the middle is like a chat app and then on the right, it's like git or something. And that's fine. I think they're really approachable and they definitely have their target audience. but for me personally, having the flexibility of a terminal and being able to modify it so much. I really wanted to. take it further. I've been used to, I've used pretty much every terminal emulator on the market. You know, I term ghosty, kitty, alacrity, a ton of other ones on Linux and they all kind of do the same thing. fundamentally they're a window with a split tree and I wanted to try the experiment of like, well, what if I could see every terminal I've ever had open like on one canvas? And it was just kind of that curiosity that led me down the start of the path. And, once I got the initial version, it kind of felt like I'd struck gold. I was like, Whoa, there's something here. You know, I feel like this is exciting. Like I'm excited about it, which is a really good signal for myself. And, then I started showing people and I were like, Whoa, this is really cool. So I, I just felt like I had to pursue it. Erika (09:08) Yeah, I I can definitely identify with that experience where when it's in your head, it's kind of this like amorphous thing. And then once you get it down on paper, it really builds steam on itself of getting excited about it and then really wanting to work on it, having trouble putting it down. yeah, definitely Caidan (09:28) Mm-hmm. Erika (09:29) can be a good feedback loop for yourself when you're working on something that you really enjoy. Caidan (09:34) Yeah, definitely agree. Erika (09:36) were there any points where like the project significantly changed? Like any of that feedback that you got? did it really like change your vision at all? or did you pretty much stay on on one path? Caidan (09:49) Yeah, that's such a good question. I've gotten so much feedback and I think every founder, everybody that builds a product experiences this to some degree. I've gotten every opinion, every differing. I've had so many conflicting opinions about like, it should do this and like, but it should do that. it's like trying to find the balance of like, what to actually build and what to like filter out. Like it's all good signal. Every, every bit of a feedback is all good to take into account, but for myself, I'm trying to make sure I'm not building like an everything app. I don't want this to like have every feature possible under the sun. I, the way that I'm trying to focus on building this is I want to build the primitives such that other people can build out what they need with it. and so that's kind of where I built out the, like the whole start of it is like nodes and connections, right? I I'm a big graph theory nerd as well. So I, took a lot of those ideas too. And I've been building graph based applications for a long time, like, mathematical graphs, not the visual graphs. And so that was a big inspiration. love building graphs, so it felt very natural. I'm trying to build it. Yeah. Like, one of the, one of the features that I think is still a little underutilized for users that, I think is incredibly powerful is the concept of blueprints. So you can select any set of nodes and create a blueprint from it. And it will capture all the details such as like the startup commands for a terminal, the URL for a browser, you know, notes, the file paths for editor, all of that. and will allow you to instantiate copies of that blueprint. And you can take it across projects, you can take it across workspaces, you can export it as just a JSON file and send it to somebody and they can import it and create the exact same workflow. And so this is what I'm focusing on next is kind of building out this shareability aspect and making it so that my goal is to have teams be able to have common development workflows. It's like release workflows or security audits or anything that's like kind of tedious to do that you'd have to have a documentation page written up for about anyway, you just have a blueprint. You download terminal graph, you import it and just click run. And it just does the thing, right? It's very visual. It's very easy. You can have notes there alongside every step of the process. but there wouldn't be the need to like, have that kind of like friction of teaching somebody this process. It would be. hopefully a bit more intuitive. And then also keeping those blueprints up to date across multiple machines and across the whole team. Erika (12:29) Yeah, I definitely think that's really relatable trying to take feedback and apply it in any situation. could be customers, it could be product, it could be like any number of stakeholders and everyone has an opinion. And yeah, at at the end of the day you need to deliver something and you can't make everyone happy, so you have to have that judgment were you the sole developer on this? Caidan (12:55) Yeah. So I guess maybe it'll help to explain the structure of our company a little bit. Um, we're a holacracy, uh, and for anybody that's not familiar with a holacracy, it essentially means that you are a team of equal power and responsibility. So there's, uh, six of us currently, I believe. and we all are part of the level. So we have no employees, we have no bosses and we all have this freedom to do whatever we want that we think is best for the company. and so with that power, as I said before, I've been wanting to build products. So building this, has been kind of that, that desire to make some, a change for our company. And so I've been the solo developer on it for the current time of his life, it's a couple of months now. And I'm like, it's getting enough traction that I'm pulling in other team members to help me with design and branding. I'm getting some help to like do some more engineering work. But I wanted to prove that this was like actually taking first before kind of pulling their time. Erika (14:04) forward? Like having at least one other person for a lot of decision making that can impact other people Yeah. Caidan (14:13) Yeah, totally, totally agree. I've been needing some help. Some of my ideas are maybe a little harebrained and not. fully developed of just like, wouldn't it be cool if I could do this? And then realizing actually maybe that's not that useful, but Erika (14:27) Wow. Caidan (14:28) yeah. Brittany Ellich (14:29) is there anything that you feel like you've brought into terminalgraph that you like you haven't seen in other apps or like what is the thing that like sets it apart from what is out there? Caidan (14:39) Oh, oh my goodness. Another great question. Brittany Ellich (14:41) Multiple things. Caidan (14:42) Let me think about this because I personally feel like so much of it is unique. Hmm I think really the most unique aspect of this is the data flow. Being able to pipe data across different categories of applications is what I hopefully see an incredibly powerful utility for the future. Being able to run a dev server, grep the logs grepping for the URL and piping into a browser is like so powerful, right? or being able to have a template node where you can put little curly brackets around any name, any variable, and it'll create a new port, right? And then pipe data in. So you can say like, hey, analyze this git diff and write a commit message as a rudimentary example. And then you run git, you want to have a run node that runs git status or git diff, pipes that in. And then you pipe that to like claude code is simple, but I think shows the power of how this can kind of scale into larger, more intricate automated systems. And I've even added like a webhook node that allows you to, you know, connect to external systems and get events that you can pipe through into the entire system of whatever automation you want. So I do truly think that the Dataflow is the most unique aspect that separates itself from others. Cause I, when I was building this initial, I did look for prior art of has anybody built something similar? And what I came across is there's a handful of other projects that do the terminals on an infinite canvas kind of approach. but none of them do any sort of data data flow or data piping. Erika (16:20) Yeah, it it makes me think of why MCPs are so popular and why they've taken off so much. the parallel in my mind is a single session, a single agent, a single whatever is great. But when you can make those connections and like pull in data from other sources to help, it's how we operate too. We don't stick in the terminal and when we say I don't know how to do this. We stop, you know, you gotta go find out what you what you don't know and pull that information in. yeah, so you you mentioned earlier that you know you've been developing for a long time, that you started when you were really young. and clearly you're you're passionate, you're fired up about the work that you do. so tell us a little bit about your journey and Where you started and how how you've changed throughout the years. maybe starting with like what kind of got you into programming in the first place and maybe some some lessons you've learned over the years that you you have top of mind as you go through your your work day to day now. Caidan (17:24) So I think like a lot of self-taught developers... We got into it because we wanted to make video games. And when I was 13, unsurprisingly, I was a huge Minecraft nerd and that was like the only thing I wanted to play. So I kind of reached my limit with it. And I was like, I've played everything you could want to do. I've modded it to, you know, in every way you could possibly want. And I was like, I want to do more. And so I started learning Java to create my own mods and my own plugins. That went on for a couple years and I made a ton of mods. I had a lot of community. I worked for some Minecraft servers making custom plugins. I made maybe a couple hundred dollars, which as a teenager was great money to have. Definitely very underpaid for the looking back. And after those few years, I... kind of got burnt out on Minecraft. had done everything. I built every mod I could want, you know, and it's just like, it's time to move on. And I don't think I initially kept developing at that time. I kind of went off and did school and other things like that, but... I don't know what it was. It just kind of like kept pulling me back in. kept thinking about it. was like, this is, you know, that was actually really fun. Like I should try to make more stuff. and not really having an interest in like web development or app development or any kind of like business. development stuff at that time, I naturally gravitated towards making video games. So I booted up Java. I started making 2D games and building out tons of very simple ones. Nothing that's really that impressive. And eventually during high school, I met one of my best friends who was also a developer and I grew up in a really small town in Colorado, Drango, Colorado. I don't know if anyone's ever heard of it. Very tiny little cute mountain. So no coding. was like nobody knew anything about it. And he was like the only other kid that like had experience with it. And he was a much better coder at that time than I was. So we kind of became best friends. He taught me a lot and we started making a lot of games together. And eventually we started doing a lot of game jams as well. So that was the majority of my high school. And a little bit after it was just like making games all the time. I did a lot of, I create a lot art too so I was making pixel art I was making like animations you know other things of that sort and I graduate high school and I come from a pretty poor family I'm the oldest of five boys so there wasn't really any money to go to college so I was looking at my options like I can take out money student loans and tried to pay him back and like, I maybe that would have been a decent route, but, I was also like, you know, I have this experience, maybe I could get a job in tech on my own, even without a college degree. And so I decided to take a gap year and give myself a year to just, try and get a job at tech, get anything for a year while I was working at like a chicken restaurant, a wing restaurant and. I spent that year working and building my portfolio. I was still working on like some games that I was liking and eventually about, so the, gap year, I, the promise I made to myself was if I don't get a job in a year, I'll bite the bullet, take the loans, go to college. I got a job eight months into that gap year and it was just an internship at a local tech company, that surprisingly I didn't know they existed. but I was, intern for three months during the summer. And towards the end of it, I talked to the CTO and I was like, Hey, I would love to like, keep working here. once this internship ends and he kind of suggested and pushed me to be like, you should go to college. And I was like, okay. So took his advice and like, I didn't go to college. I went for like, he was like, I'll give you the job, but you should also consider going to college. So I got the job as a QA engineer, which I don't know if that role even exists anymore. but I was writing unit tests, and. a of other stuff. eventually kind of branched out and was doing a lot of like internal tools. cause the, company at the time was Git prime, which was acquired by Pluralsight like a couple of years later. So they're not really around anymore, but, they were a Git based company. So analyzing like Git metrics and stuff like that. So I was building out a bunch of internal tools to like help mock Git APIs for like GitHub and Bitbucket because we were hitting rate limits with all of our testing and other stuff. And, like I. built a little tool to basically recreate, git repose, from scratch, like time travel back, like creating commits at any point in time, stuff like that. ton of fun. learned so much. Like it was incredible that I had that opportunity because in just the one year of working at that job, I learned more than I had my entire time on my own. was so valuable for me. and so that was an incredible job. learned a ton. And then the company got acquired by Pluralsight. I worked there for a few months, but... They were too big, you know, they were like too impersonal. was still stuck as like a low level QA engineer. was supposed to get a promotion right before the acquisition and then they acquired us and then that never happened. And they're like, you have to be here a year before you can move. And I was like, I don't want to do that. So, I was looking for jobs and, I eventually found a role at Overjet in Boston, which, was a startup that was working out of the Harvard innovation lab. creating this was back in like 2020. So even before like the big LLM started hitting the consumer market, we were creating. computer vision models to analyze dental X-rays, to look for early signs like gum disease and tooth decay. and I don't have a PhD in, any of that. So I was not, I was not doing any of the like actual, generative model stuff. but I love data and I love Linux and I love processing. I actually, this is kind of where I started to really fall in love with this concept of like piping and data transformation is I had built out a very custom data pipeline to process these images from all the various sources. I can't talk about the sources, but it would be, you know, we'd get like an FTCP server. We would get like a random link to this like third party vendor, you know, that would host all these images and we would have to get it into our system and it would land into like a Google bucket and I had some cloud functions that for each notification on that bucket would load it up and process it like multiple steps along the way. It would start with, okay, let's. go through and convert every image to JPEG, right? That's what we were standardizing on. and it was really fun because there was tons and tons of different formats that I did not know existed, including, it's been a minute, so I may get this wrong, but it was, TIFF files, I think, which are, it was a, well, it was a specific type of TIFF file is like an unsigned 16 bit, integer encoded to file, which was like, was trying to find where these came from and they're incredibly old, X ray machines, like some of the first ever digital X ray machines. And I was using pillow, the Python library to convert all of them. and nothing, like, like would not read this. It was like, what's going on. So I went, this was the pre AI days. So I was like, what is this format? Like, no, I couldn't, I could barely. finding information, I think after like three days of frantic searching, I eventually land on the super obscure forum with somebody being like, yeah, here's like some information about it and blah, blah, blah. And like, here's a numPy function that will allow you to transform it to JPEG. And so I copied that and was able to basically just like cut off half the bytes and then like strip the header metadata and stuff like that. and then, you know, that was like the first part of the pipeline I built out. All this, and then it would go down to like, removing patient health information. So we would like send it to Google to like analyze texts and we just black it out. and anyways, so, that's kind where I fell in love with data pipeline. It was incredible job. eventually I, got burnt out because the pandemic hit and I was working like 80 hour weeks and I was underpaid because I was so young and I'd been asking for like six months like, hey, can you please hire more people? I need help with this work. And unfortunately, the CEO and I had disagreements. So I started looking for a new job and I eventually ended up landing at another company and was there for a few years. was at, um, uh, uh, uh, uh, Domino data labs, which was, like, uh, I won't go into it. It's a complicated job, but, um, I learned a lot there. I, uh, realized that actually I didn't need to be in Boston anymore because that job was remote. So that's how I ended up moving out to Seattle. I actually had never visited Seattle before moving. kind of was just like, I have a friend out there. one of my best friends that I met high school was living out here. And so was like, yeah, why not? And I just sold everything I had because I looked into shipping it and it was going to be more expensive to ship from Boston to Seattle than it would to just actually buy it all again. Cause it was, I was a young kid, but not very expensive things. so I sold or gave away almost everything I had. Uh, and I hopped on a plane with a duffel bag and like a backpack landed in Seattle and found it, crashed my friend's couch for two weeks and found an apartment and kind of rebuilt it up again. Um, and I've been in Seattle for about six years now, um, roughly, think, well, maybe like five, something like that. Um, and I was with that company for a while until, uh, I think it was like 20, 24 layoffs where hitting everybody, our company got hit. I was laid off. I had some severance and I decided to take a hiatus for about six months. I had been working hard and kind of just really needed a break and wanted to explore some of my own projects and do some of my own things. So did that for a while and then eventually got another job working for actually another medical tech companies, surprisingly. which was doing MRI images, generative or computer vision on MRI images as well. So, that was a lot of fun and I worked there for, almost two years and I kind of realized as I went into that job, I was like, I don't really have a great professional network. should go socialize and mingle and meet people. and so I started just going to a bunch of tech events here in Seattle. And eventually that ended up leading me to. the internet development studio. went to, the distributed web meetup that we host every couple of months. and I go in, you know, I don't know anybody, but I sit down and watch them, the talks and I get up and I'm like, okay, cool. Time to mingle. And I walk around and the first person that I ended up talking to in meeting was, Jimmy, Jimmy Lee, the guy who started the studio. And so we hit it off immediately. We're just both very passionate about the web, passionate about building. and so he invited me to come hang out at the studio. And so I started coming back. Eventually I start renting a desk there. and then about six to eight months into renting a desk there, the studio was looking to hire more partners. And, so they asked me if I would be interested. And so they, you know, I said, yes, that's, it was like, so cool, very exciting. and so they put me through a one month work trial. and I killed it. They loved it. I did great work. I worked on a lot of our open source projects. helped, further develop out one of our fonts server mono, because it was missing a handful of glyphs. had never made or worked with fonts before, but I I'm an auto didact. I just love learning and love building. So I got some font software and I like started designing and trying to match it to like the, the feel of the text and like, was putting it out there, getting community feedback. And so that was a lot of what I did during my work trial for the first month, but they loved me. So hired me on full time and I've been with the studio since and it's about been about over a year now that I've been with the studio as a partner. Erika (29:36) Thank you so much for sharing that whole story. Caidan (29:37) Yeah. Erika (29:38) I can, you know, there's there's so many things that like I got from from your story and and the way that you tell it, I can I can tell your agency in it as well as all these situations that kind of came up and and what you got from each situation too. it's a very unique path. I mean, Yeah, and very cool to hear how, you know, that that foot in the door moment with your first job like really got you into the professional side and was really a launching pad. but really each step along the way you kind of took something from each each job, each situation that has really gotten you to this point now, whether that's the technology you were working with or sort of the people situations, you know, so and didn't let any of these sort of potential setbacks get you down with you know, several situations you mentioned vying for a promotion. And instead of waiting around, you moved on to the next thing. You looked at what else was out there, what you could what you could do and Yeah, it's very cool hearing hearing you sort of move through all those moments and stay focused on on on what you're still so passionate about. even you even mentioned Caidan (30:55) Yeah. Erika (30:55) a couple periods of burnout and then you kind of ramped back up again and got back into it. Caidan (31:01) Yep. Yeah, well, thank you. Yeah, it's been a long journey and I think the, one piece of advice I like to give, when I tell this story is, a lot of people will say like, you're so smart. Like, you like must be so intelligent that you're able to do this. And like that you taught yourself coding and I'm not going to say whether or not I'm intelligent. I don't think that that's super relevant, but what I think I would attribute to that more is the persistence. I have this passion and this dream and. Regardless of how many times I failed, like getting that first job, getting that first internship, I must've applied to like 500 different companies. And this was even back when like the job market was still pretty good. And it really is just like that persistence of like trying and trying and trying and trying and failing and failing over again until succeeding. And it. it broke me a little bit, but it did work eventually and it paid off. And so I'm very grateful for never having given up. Erika (32:05) For sure. There's a lot of like cultural perception around software development jobs in general. one of them is being that people think software development jobs are really stable, and that's not necessarily true for a lot of people, or that they're really well paid, and that's also not necessarily true in every situation. so yeah, it's it's it's sometimes frustrating hearing that and being like, well that's not my experience, but you know, you can't change, you can't change the industry necessarily or people's perception on on the whole. You can only kind of operate with with what you have and and do the best with with the opportunities available. And yeah, it definitely sounds like you've been really smart about that throughout your career, which is refreshing. Caidan (32:51) Yeah, thank you. Erika (32:52) Yeah, for sure. Well, we are getting up on the end of time, which is crazy. This has gone by so fast. And Caidan (33:01) Yeah. Erika (33:01) we always wrap up with a bit of a fun segment where today we're going to take the question of what if we could apply terminal graph, this idea of like Graphical interfaces organized and and node data flow and apply that to some kind of real life situation off of a screen, I guess. I mean, developing is also real life, but if you could kind of take this idea and apply it to some yeah, some non-virtual environment, what that would look like. Caidan (33:35) Hmm. Yeah, that's my goodness. I don't think I've ever thought about this before. Give me give me a moment here Erika (33:40) Yeah, I have thought about this because I'm the one who wrote the question. so I have a daughter and you know, there are times when it's like I would love to kind of know where everyone is at all the time, you know. And it's not all the time. We're pretty good about communicating between me and my my husband, but like, you know, it'd be nice to kind of like have have these these communications where I can know where she is and he can know where she is and I can know where he is and we're all kind of like communicating without without necessarily being in the in the same place. So that's that's that's sort of my my take on it. Caidan (34:18) Yeah. So I think for me personally, I have ADHD and have struggled with it for a long time. And I kind of view it as both a bit of a superpower and a detriment. Like it... Kind of helps me have a lot of creativity and explore a lot of options and, like kind of go down weird tangents, but that usually leads me to something interesting. but it's also kind of hard to like sit down and do a thing if I'm not like deeply invested in it. And so I think if I could have the power of Turnable Graph outside in the real world, it would be to help augment that. getting, you know, just connecting everything in my life that needs to be done of like, my laundry is overflowing. like send me a reminder or like force me to like start the washer dryer, like automate that in some way, you know, automate like how I can make breakfast or automating like just various aspects of like the routine that's hard for me to keep up with, think would be probably the most useful for myself. Brittany Ellich (35:23) But when the twins were really young, when I had a very young baby, like everything was so much like is the d when was the last time they ate? Are they hungry? Did they get enough sleep? Like there's just so much involved that you feel like you're just like have those little like sim bars or something like that when you're playing the Sims and you're trying to keep them all clean and happy all the time. especially when there was two babies at once. I like that would be a fantastic tool to have to have, especially having the data flow. Like there's a lot of tools out there. So that would be like an early parenthood terminal graph, I think. Would be really nice. Erika (36:00) this has been so much fun, Caden. Thank you so much for joining us. where can folks find you on the internet? Caidan (36:07) Yeah, I'm on most of the socials threads, blue sky, Twitter, or X. And if you go to my website, kaden.dev at C A I D A N dot dev. I have a link to all my socials there too, to make it easy. Erika (36:22) So cool. And we'll link that in the show notes as well. Well, listeners, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 68: What VCs Want from Tech Talent | Engineering Careers with Melanie Nabar - URL: https://overcommitted.dev/what-vcs-want-from-tech-talent-engineering-careers-with-melanie-nabar - Published: 2026-07-14 - Audio: https://anchor.fm/s/102586d64/podcast/play/122742635/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-6-12%2F427834017-44100-2-8e47bca9cadf3.mp3 ### Show notes What do investors actually look for in software engineers and tech founders? Melanie Nabar pulls back the curtain on what VCs see when evaluating engineering talent, sharing insider insights on career growth, technical credibility, and the skills that matter most when funding is on the line. Perfect for engineers ready to level up their career strategy. Links Melanie Nabar on LinkedIn: https://www.linkedin.com/in/melaniejordannabar/ [https://www.linkedin.com/in/melaniejordannabar/] Volition Capital: https://www.volitioncapital.com/ [https://www.volitioncapital.com/] Hosts Overcommitted: ⁠https://overcommitted.dev [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbnllT3pGVnRrTFJKcUpQTWtlX1IxWjVIcWE2QXxBQ3Jtc0tub09tQ3MyMDZjdFpINVowMnhaT3FyMFpyTHlKUXhCdDJOcGF3Y2RwRjNLWkVyazZ3UzIxbGo0bWMxNUpLTEV5T1Z0OG5Kc3F1MGtvTWJaOVRKd05paWVweDdBaGtrMGNia3c5WFpvTnB5ZElYVjNNcw&q=https%3A%2F%2Fovercommitted.dev%2F&v=9VXK9TzqmmM] ⁠Bethany Janos: ⁠https://www.trustyduck.dev/⁠ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqa1FyNWNSdTZ1eHNKZmdkUVotR0E3TGlPVDVUZ3xBQ3Jtc0tsendpRl9pZVV0Wmowd2FnNDRrUDZaaXN1djV6WjVzT2VmdGxsZWxQVkFRMnZHYmh3RktEZDdmOWFoRlRwSlRxQzdtd1JiZUtFT2JLT1JYVk1EOUFzWWVUV3N2UENYVmNtZGxadjZrUnF2dUdFR0JuZw&q=https%3A%2F%2Fwww.trustyduck.dev%2F%E2%81%A0&v=9VXK9TzqmmM] ⁠Erika Eggemeyer: ⁠https://github.com/eggyhead [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqa1VnTi0yUUZZeHRSYzIyMGpRSU10cjl5ZVo1Z3xBQ3Jtc0ttdG9jME03V3B6dUY1eWczalBaNjJTM3hPWUc0eXZlTGhKNEVMY1hfVTB3M3pYOGNjWm1Hc1pmMWRzZUdWNXBmUUpibk1DYUtGa2NrNVJpZzJZN1JTOE54RThOdU9FLWlzQUhpTDJkWmE2RHNhNnpaaw&q=https%3A%2F%2Fgithub.com%2Feggyhead&v=9VXK9TzqmmM] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Bethany, and I'm joined by Erika (00:08) Hey I'm Erika Bethany (00:10) We 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've learned. 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're so excited to be joined by Melanie Nabar, principal at Volition Capital, a Boston-based growth equity firm focused on founder owned capital efficient technology. Melanie leads diligence on new investments at Volition, sits on the board of digital onboarding, and is a board observer at Haas Alert, Zenerate, ABCS Insights, and Halo. Her job essentially is to look closely at technology companies, the engineering teams, the products, the founders. Decide whether to back them and then stick around while they scale. We've talked to a few founders on the podcast, so we're really excited to have her talk about what the view looks like from the other side of the table and what it means to for the way we build software. Welcome Melanie. Melanie Nabar (01:13) Thanks for having me. Excited. Bethany (01:16) so excited to chat with you. start us off as we start off every episode. what is one thing you're currently building or obsessed with learning right now? Melanie Nabar (01:26) Yeah, it's a great question. I love this kickoff question. right now I am obsessed with building agents to simplify my life, to take a lot of that mental load that we have every day. You know, everything from like grocery shopping to what you're gonna cook and recipes and who you're gonna reach out to, when people's birthdays are. Like there are so many ways that I think we can start to leverage this technology to make Our lives easier and maybe make us better friends, better partners, and also just give us more time to focus on things professionally as well. Bethany (02:04) That's so relatable. I feel like I've been definitely using agents a lot for work and and stuff, but it's slowly dripping into real life where it's it's like, I I could use an agent to simplify this or I could use AI to simplify that. so that's really cool. That makes a lot of sense. I would love could you walk us through what exactly like a day in your life looks like for Melanie Nabar (02:14) Yeah. Bethany (02:32) your role at volition, like how h how are you interacting with these companies or sourcing different companies to invest in? Melanie Nabar (02:41) Yeah. It varies a lot day to day, which is part of why I love my job. it could be anything from, you know, I could be in Detroit, visiting with companies in the area, getting to know CEOs in person. I could be, you know, on Zoom calls with CEOs, talking through their vision. We could be working on a a new investment, in which case Could be anything from, you know, analyzing data to conversations with different functional leaders to industry conversations, trying to validate the market need. or it could be a a board meeting day where, you know, we're heading to spend time usually in person, sometimes remote with our executive teams and chatting through like what's working, what's not working, what's keeping them up at night, and then finding ways for us to be helpful. So there's a lot of variability. Bethany (03:36) I can imagine that with the different aspects of of your job. if we could maybe focus on the part where you're looking into these investment opportunities, I know we've heard a lot about that it's really the company that matters or like the organization that matters. So I'm curious what exactly are you looking for for these engineering teams that you might write big checks to? Melanie Nabar (04:04) Yeah, it's a great question. I think if you were to go back, you know, a year ago, the the diligence on an engineering organization would be quite a bit about the product. So we usually hire a third party because I'm not technical as much as you know, I building agents for what I should shop for in my grocery shopping is not the same. And so we will hire third-party firms to assess the code base, to talk through their processes, basically figure out where we can up level the org. and then that would be the extent of it in addition to put you know, what's the product roadmap and what do customers think about the product and things like that. now I think we're doing a lot more assessment on how organizations are run. And that is just as important as the product and the market and the customers. I'd say all of those plus the founding team, like those are all the equal parts. And now we're thinking about, you know, how are you engineering? Like how How have you built out your AI harness? Like how are you deploying it within your organization? Because as much as you're backing the existing product, you're moreover backing the innovation of the company and believing that the founders and the management teams will stay ahead of the curve because it's become so competitive, so easy to start to deploy code and features. And it becomes really important that you think the team that's in the seats or that you could bring on as well can stay ahead of that curve. Erika (05:40) Does that look different depending on the type of company that it is or like the stage? or is it pretty like pretty much cut and dry of like we look for these same things in all the companies that we look at? Melanie Nabar (05:54) Yeah, it's a great question. It definitely depends on the stage a bit. if we're coming in and investing in a company that's say four million of ARR, well, no wonder there's gonna be some things that need to up level over time, right? So there might be a little bit more leeway because you're coming in earlier from a stage perspective and also earlier from a valuation perspective, right? So you're maybe willing to take on a little bit more of that organizational risk because it's slightly easier to get the upside since you're earlier. and then flip side is if we're investing in a business, you know, that's 25 million in ARR, well, we would hope that you have leaders in place that really know what's going on. We'd hope you have really strong processes and that these things are are thought through. and so yes, yeah, definitely there's a little bit more leeway the earlier you are. flip side is when we look at businesses that are earlier, that we may think, yeah, who knows? what this organization and what the processes are gonna look like. Sometimes that's what's what blows us away. Because especially now, I think agile organizations that have been able to adopt AI tools and strategies more quickly sometimes are ahead of the curve. and that can be a beautiful thing, right? Because it's a small org and they're ahead of where they should be. And I think there's a lot of value in that too. Bethany (07:18) That makes so much sense. it's interesting the impact of AI development and ensuring that you have those strong foundations early on. how are you sourcing these these companies? Is a do you often look at the founders first or are you looking for the product first and then viewing that founder fit and organizational structure after that? Melanie Nabar (07:43) Yeah. So first we're usually thinking about the market, market opportunity, like tailwinds that are going on broadly where we think, there could be something here. This is a big market. sometimes conversations breed ideation. So you might talk to one founder and you know, they're actually talking about a problem they're facing. And that might spur you to say, well, I wonder if there's a technology company solving that and kind of go down these different rabbit holes. We have also a bunch of analysts and associates who are rock stars who basically canvass the world for like private companies, companies that are, you know, not in the public markets. and they look for different signals. we now have open claw, we have agents that are going out and looking for things like could be news articles, it could be looking for, you know, second time founders, it could be looking for, you know, testimonials on different custom different companies where wow, like this company looks small. There's only maybe 12, 13 people, but Reddit is exploding because like people love this platform. So there's a lot of different places to find it. Sometimes it's signal, sometimes it's market, sometimes it's luck. Like we're going to conferences and we're trying to talk to everybody. And every once in a while, an under the radar company crops up that is just absolutely crushing it and things align. They're looking for capital. We can prove we're gonna be good partners and it comes together. Erika (09:11) And yeah, so so you find the company and then do they always give you a pitch or is it sometimes like you move past that and start like sort of the analysis side before you kind of get that formal introduction? Melanie Nabar (09:27) Yeah. So we're usually building a relationship first. if you're going to give somebody a piece of your business, it's a very personal choice. So candidly, by the time we're coming in, which is when folks have no real revenue and are growing quickly, they're usually hesitant to open themselves to investors. and, you know, we have to prove that we align in terms of how we think about businesses before they're open to sharing a lot of the nitty-gritty and data. So the process usually looks like, first conversation, spending some time in person. That could range from they're raising right now and we're going to the next stage right away to two years from now they decide to raise and we just build the relationship over time. And then once you know they do decide they're going to raise capital, then we are doing some information sharing. We'll typically focus mostly on getting to know the founders in the beginning and getting Data from them. Sometimes the CFO or sometimes it's chief of staff, depending on the stage, will be helping out with data sharing. And then once we kind of agreed on evaluation and partnering, that's usually when founders will open the aperture to the rest of their team. Sometimes the technical leaders are a part of the founding team, actually a lot of the time. So they're already involved. Sometimes that's coming a little bit later once we're really in diligence. and at that point, once we agree on evaluation, we're trying to close the investment in. 30 days and during that time period we're spending time with as many folks at the company as we can. typically VP level and up because it's just too many people for us to meet. And also, you know, leaders are going to be protective of their producers' time. and so we'll spend time with different functional leaders there and kind of get more into that nitty-gritty. Bethany (11:18) Yeah, that's I I think it's so interesting that it's really about this like relationship building as much as it is interviewing them or analyzing what it what the company's worth. It's really about making making folks feel like this is a a equal relationship, equal like footing and and things like that. So I I remember we when we were buying a house, that was one of the things we were struck by is that our realtor was very invested in building that relationship so it took us like a year to actually go through the process but I know that just even with that purchase it was a big deal so I think that makes so much sense to invest so much in that relationship building and however whatever timeline that looks like. Melanie Nabar (12:02) Yeah. Yeah. It's kind of like if that realtor was like living in your basement. You know, because we it we do the investment, we do the deal and it's it's not done. Like we stay involved for the next yeah, could be five years, could be ten years. So that is a good analogy, but it's like we stick around, which I'm not sure you would want in this in this analogy. Bethany (12:17) Yeah. I don't know, he's really cool, so maybe maybe I would like him in our basement. Melanie Nabar (12:38) Yeah, maybe. Good addition. Yeah. Erika (12:43) Yeah, so I guess at that point of the pipeline. So like after you're invested and you're like you're in the boardroom, like what are what are some of the things that you found to be kind of the most effective ways to like maybe move some organization in the right direction? Like what are the kinds of things that you're looking for as like, this is what like this is what we can change to make you more successful or Like maybe when you're investing, you're like, no, that's never gonna change. Like this is not yeah, not worth the time. Melanie Nabar (13:17) Yeah. And I'll caveat this answer by saying we are minority investors. So we're not coming in and buying the whole business or majority stake. And so everything that we're doing at the board level, it's ultimately management's decision. but our job is to try to help folks skip mistakes. So there are patterns that arise, there are pitfalls people fall into when they're building and scaling a business often. And our job is to kind of pressure test. So when you're about to step into pitfall, let's at least push on it. And maybe you decide I want to do it anyways, and you have conviction and hey, that conviction is why we backed that management team. So that's fine. They can still go ahead and do it. And sometimes it they may be right. It could be the outlier. so I'll caveat it with that. But I think as it relates to the audience here, which is sounds like it's really mostly engineers, I think there are a few places that teams struggle that I think we're able to pressure test. And one of them is like if you can't measure it, you can improve it. And oftentimes when we first get involved, all of the teams, whether it is engineering or sales or whatever, are small enough that you can you can kind of all go in the same direction. Everyone's like building together. And so you you feel like everybody has ownership. But as you scale, not every person you hire is going to feel that same ownership as like the first 10 people at the company, right? And so you start to need to measure. And I think a lot of companies will they'll talk in high level statements, gut feel, but at some point you do need to start measuring those things. And I think engineering is one of those places that for the board is often the biggest black box and also usually one of the bigger spend areas, too. and so I always tell engineering leaders, I we actually just hired a new VP of software at one of my companies, and he asked me at our first board dinner, like, What do you want to see? And I said, what do you measure? Like anything you measure, I want to see. And it doesn't mean that I understand some of these measurement things. Like I don't really, I'm like, hey, what is that? Is it good that it's up? Is it good that it's down? Like we're not engineering leaders ourselves. But at least if you're measuring it, you're starting to establish goals and you're starting to see trends. And if you're not measuring it, you're going blindly by gut feel. And it's actually one thing that Like AI and having a strong AI harness can enable for engineering leaders is like now you know who's creating the bugs. Like you can go and see, you can track that. it's not like, I don't know who created that. and you can see, you can see at a different level and measure at a different level, not meant to be big brother, but so that you can up level things. You know, you know where you are. So you know what you need to improve. And that is a beautiful thing. And I'm hoping that we start to see more measurement in the than historically we have. Yeah, so that's that's definitely from an engineering perspective something a a pitfall people fall into is it's just product roadmap slides. There's no real measurement. Bethany (16:25) Yeah, that's I mean that makes so much sense that you all are not only in providing the capital and whatnot, but the mentorship as well. and that's really interesting. And I I would love to talk more about the the measurement piece too. I think before that, mentioning the pitfalls and that being one of them, the lack of measurement. Has that has that evolved since AI really became a thing or has those pitfalls evolved at all where you're seeing Melanie Nabar (16:46) Yeah. Bethany (16:57) different pitfalls now versus what you might have been seeing a year ago or two years ago. Melanie Nabar (16:58) Yeah. Yeah, maybe not quite a pitfall, but something every company is facing right now is how do we reorganize for this new AI world? a lot of companies are no longer having like product and engineering. Like now there are builders, right? And and you're a builder. and you kind of it's it's more like we verticalized the the whole process. and How do you enable folks in other portions of the organization who can now build to build? And where do you, you know, where do you stop that, right? Or do you keep that? and you know, people are using tools like lovable, for example. Like somebody in HR can build themselves something and they can launch it through lovable, like cloud code, lovable, and it's a product. It's crazy. It may not be security grade, enterprise, and it may be more of like a tool or feature than like a full product. but I think people are realizing that with that ability meet comes reorganization and every company is is handling that. It's also change management because everybody's jobs are changing. I think people are further behind than maybe you know, you us three in the room think, like as a world from a world perspective, like enterprises are further behind than you think in terms of adopting a lot of these things. But you know, obviously you all are developer right on the front lines. And you know, I'm talking to AI companies all the time. So it feels like it's all happened, but it's still happening. And every organization we're working with is figuring out how do you manage there's a fear component and there's an opportunity component. And like how do you people don't behave well when they're scared. Like people make mistakes, people don't make the right decisions when they're in fight or flight. So Like you want people to realize things need to change, but you also don't want to instill like a crazy fear culture. That's not good either. And so there is an element of change management a lot of our portfolio companies are dealing with. And we actually had an executive summit last month. we rented out a big piece of Fenway Park. It was a lot of fun, but it was also all about like AI, AI change management, people talking through like how did you announce this to your organization? Because some people have made some big swings. Other people haven't yet and they're renicent and they don't, they're trying to decide how to do it. And so we're trying to create as much real-time learning on something that's new to everybody so that like each portfolio company can learn from each other all while this is happening live. And and I think that's one place that, you know, being a part of a firm that has, you know, a number of portfolio companies and is in like leading edge technology companies can give. you an advantage as, you know, a a company, as a part of that portfolio too. Erika (20:01) Yeah. The two things that came to mind too as you're talking is like there's a third piece which is the learning piece. and like you can you can be open minded and like interested in trying this, but if you don't have enough bandwidth or like room to grow, then you might not be able to even incorporate this into your workflow because like Melanie Nabar (20:09) Yeah, good point. Mm-hmm. Right. Yeah. Right. Erika (20:28) I'm so busy doing all the things that I have to do. Like I can't figure out how to use this agent to do it. yeah. but I think I think when you were talking too, like in my mind it goes it goes back to those kinds of like goal tracking and and measurement pieces, because like then the add-on question is like, well, like Melanie Nabar (20:31) Yeah. Erika (20:54) We don't want to use AI for the sake of using AI, right? Like you you want it right, yeah. Like essentially you like want it to make you better at your job. That's the goal. But in order to know what better is, you have to know where your starting point is and how you're measuring like those things. So like for myself, like it's like, yeah, I think of like PRs created, like PRs merged. Melanie Nabar (20:57) Right, right. Yeah. I think we've learned that that's not a good strategy. Yeah. Yeah. Erika (21:23) like review time, bugs created, like those kinds of things are how I like measure my effectiveness. and like I'm constantly asking like Am I doing this faster because of AI or would it be faster to like just do it myself, do it by hand? and it's it's still very unclear like on a day-to-day basis. Like yesterday I I had AI write something and the feedback from a colleague was like This took me probably three times as long to review because the AI like jargon didn't make any sense. You know, it's like, well then I just created more work for that person. so like that's a learning moment to be like, Well, okay, yeah, think about how this comes across. yeah. So Melanie Nabar (21:58) Right. Yeah. Yeah. It's a great point. I think I think a lot of companies they don't yet know if they're getting the ROI. in some ways, like yes, you can launch little features probably faster, but then like, do they create a bunch of bugs that create more work? And I think people are still figuring that out. but to your point, like some of it has to be learning, right? In order to get there, like you need to be there needs to be a leadership. approval of like, all right, like are we going after this? And this is a big initiative. And you're okay if I make mistakes because you told me we need to be completely AI forward and maybe we won't see the results for six months, but like we know that. Or do you want me to produce the most like high quality XYZ now and whatever way gets us there? And that really comes down to like what are you measuring and and what does success look like, which a good leadership team should be like tops down establishing so that you don't have to play the guesswork of like what like which direction do you want me to go? Right. and I think that's that was a big topic at our executive summit because there's differing opinions. And I don't think that one way is right or another way is wrong. I just know that no direction is definitely like the wrong direction. Right. Erika (23:17) Mm-hmm. Yeah. Definitely. Yeah. Yeah. And I know I'm constantly learning from my colleagues too of how to better better use the tooling. 'cause the tooling's also changing on a daily basis. So yeah. Melanie Nabar (23:45) Yeah, all the time. Right. Yeah. We're actually doing even internally at our firm, we're doing like every Monday we do AI labs and different people present things that they've created and built. And not one of us is a technical t developer by any stretch, but I think a piece of that is just starting to get people's minds going on what is possible and also seeing Different folks get up there and present and realize, you know, hey, nobody really nobody already knows how to do this. Like this is new. So like it's okay to to go up and and share something that's imperfect. 'cause maybe the next person will help perfect it to the next stage. So I think the whole world is in a learning phase. absolutely. Bethany (24:34) Yeah, that's really interesting. I think it's it's really cool that you all are invested in continually learning about this. Is there anything concrete you've learned from these that you've taken forward with looking at these these companies or looking or advising these companies from those labs? Melanie Nabar (24:55) Yeah, no, it's a good question. I think Part of our advice to some of our companies has actually been like you should do just the labs in and of themselves, right? like you should be encouraging this. And like here's an example. It may they may not take it the exact same way, but like here's an example of how we're doing it. And we're not even a tech company. So, like it's it's a little bit of just pushing folks along. I think that's been helpful, especially for There's a wide range. There's a lot of most of our portfolio companies are miles ahead of us. Some of our portfolio companies, like, you know, it took them a second to get a little bit more comfortable getting in there. And now they're there and and running probably ahead of us again. But I think just showing them like even we are doing this is helpful. we've also had actually our portfolio companies demo to us like things that they have built too to try to like get ourselves up to speed on what people are doing. and then we have we've done some webinars too with different portfolio companies like presenting for each other. at the CEO summit, we had demos. So a bunch of people demoed what they had built internally. and I think it's really just that attitude around like we need to be experimenting and like this is what could be possible that's really, really stuck. As an investor, I think it's helpful that I have been in the tools and leveraging them because there's a lot of vapor. There's a lot of companies that are basically like a bunch of skill files in Claude and they've built an interface and like that's the business. And I think if I, you know, they look cool and they do some helpful stuff, but they're not defensible and they don't need $20 million from us to to grow. Like eventually people are just gonna build this themselves. and so I think it's been important for us to get in there and understand like what's possible so that when we're assessing companies, like, At least the first blush of wait vaporware we can kind of see through. And then, you know, sometimes it requires getting a layer deeper. there's actually a bunch of firms that are cropping up now that for tech diligence, instead of assessing the code, they're like, All right, for 30 days we'll try to build the product and we'll see how far we can get like replicating this. And if we can replicate it in 30 days, like it's probably not defensible. and so or like at least from that we can learn what pieces are are defensible. And, you know, then you discard the product, obviously. But we haven't done that yet, but I know there's firms that are doing that. so it's all about like knowing what's possible so that you can assess properly. and I think it requires more of a technical knowledge set than it used to to be a tech investor. Erika (27:37) Mm-hmm. Yeah, totally. yeah, and then there's like the extensibility question. Like, I think you kind of talked about this, but like, yeah, like will this will this grow into something that will like satisfy the market? Like like is that market need big enough to to support this this growth that you're estimating? Melanie Nabar (27:45) Yeah. Yeah. Right. Yeah. And hey, maybe what you've built like could be replicated, but you have this vision that like this is a Trojan horse, we're gonna get in the door and like we have all these expansion products to become this like sticky platform and like that's okay too. Like there's no one size fits all. to your point on extensibility, I think it could go one of two ways. So Erika (28:22) Yeah. So for like an engineer who might be at any stage of one of these companies, who might be like advocating for some kind of like feature direction, like do you have any advice on how to kind of think about like internal pitches? what yeah, what would what would you advise engineers kind of think about as they're advocating for a roadmap or ideas? Melanie Nabar (28:51) Yeah. two things. One, and this probably applies to every job, but I think it applies like when you are reporting to somebody who is then reporting to the board, like everybody wants to look good in a board meeting. And you know what makes you look good right now in a board meeting? Like AI adoption, right? so like if you can do if what you're advocating for has an angle of like, hey, we need to show the board and you know, our investors that We're focused on this and this project, like I think it gets us there faster. Like that's probably a good angle to use. the other one that, like, let's take AI off the table for a second because the reality is there's always new infrastructure changes and like change of future of work shifts. the thing that doesn't change at the end of the day is like you want to serve your customers as best as possible to keep them around as long as possible. Because honestly, at the end of the day, you're trying to earn as much revenue as profitably as possible. Like that's a business, right? and so if your project, if you can attribute numbers to that, like hey, we lost 12 deals according to our sales department. We lost 12 deals because we didn't have that feature. That's a half a million dollars we could have closed last quarter. That, you know, Jerry from sales says he could absolutely have gotten across the line if we built this feature. Like that's that's a beautiful thing, and that's gonna get you to push whatever it is you're pushing forward faster. because and Candidly, like as much as it can be great to build like beautiful code and beautiful features, if it's not solving a problem for a customer, like it actually isn't the right direction for the business. And so it's also probably a good sanity check as well. so Bethany (30:39) You've mentioned this a couple times, but speaking of vaporware and anyone being able to build build products now, I am really curious, has that helped or hurt with finding new opportunities? has that has the number of opportunities increased or has it just there's a lot of things that look shiny on the outside, like we were talking about, that aren't actually profitable? Melanie Nabar (31:03) Yeah. Yeah, it's a great question. There's more companies than ever that are growing so quickly. And that is awesome. And I think that is unique at this point in time, where companies going from zero to six million in six months. Like we have calls all the time that people are doing that. Not that that's easy to do, but people are doing it. And that is unheard of if you were to go back like Three years, especially in a business to business, like you're selling to a business. That's hard. Maybe in consumer where you can get viral and and you know the flywheel can take off, but not in tech. And a piece of that is that everyone is trying to test things out. and so that's kind of enabled this market of rapid growth. so that's that's interesting. That's exciting. There are more companies that are getting into our range faster. Flip side is I think there are a lot of companies that are. Going to see a tough like one-year renewal cycle. Like they're growing really quickly, but people are kind of testing it out and then they're going to churn. And maybe you locked them into a year contract, so they can't really churn for the first 12 months. So, like there's going to be some folks who get caught in this like whirlwind of growth, but then they don't deliver on the product and promises that they had to their customers. And so that does make our job a little bit harder because a lot of companies are now in our scale. But they're not, they don't necessarily have any renewal history. it's actually really helpful that people are moving towards usage-based pricing because you can see usage, right? company that went from zero to six million in run rate, that's on a usage base, like I can see whether customers are using it more or less. So I I know whether they're enjoying and seeing value in the product. and so there to your question, are there more? There's probably more in our range than there were before, but The ones that actually have like proof points of true product market fit, I think that there's probably the same amount. and it is a little bit harder now to answer that question of like, does this have a moat? there's a secondary question of like, does it matter if it has a moat if it gets there first? Like, that's, you know, people are also asking those questions. but at the end of the day, I think we are highly selective in who we partner with. We probably talk to We talked to at least 2,000 companies a year and we would probably invest in four or five. now the founders we're working with are also highly selective for sure on who they're partnering with. But I think ultimately like our pace of deployment has been the same because there's more companies growing really quickly that are interesting, but of those companies, it's harder to believe that they're gonna stick around and have a boat. And so you kind of end up in the same place. Bethany (33:57) that's and that ties back to the measurement side of things. Like the with when you have usage based pricing, then that automatically builds in that data set and data point on what the usage actually is. That's so fascinating. Definitely. Well, pivoting a bit, Melanie Nabar (34:10) Yeah. Right. Yeah, absolutely. Bethany (34:18) One thing I am curious I've so I've personally never worked at a startup or anything, but I am curious what often happens once you invest in a company. how does the organization typically change? Is it something where they're very motivated and work faster or is it something where it can really can start tanking momentum in a way? I'm curious what what you've seen in the where is it? Never never the same. Melanie Nabar (34:51) Yeah. hopefully the goal is they take you're taking capital and you're you're growing more, you're increasing momentum. and that's that's partially because there's more cash on the balance sheet, so you can hire more folks. A lot of times someone's been wearing three hats and now they can just wear one and focus on the thing that they're good at and they can get support. so that can be like a nice real moment for folks who are, you know, in the bottom of of the stack, kind of feeling that pain the most. it also does mean that like your options are valued at something, which is a beautiful thing, right? Like you were given options and they had some arbitrary strike price, and you said it's they said, if we're worth this, that's what your options will be worth. But now there's actually a a new price. And so you actually know like how much you've increased in value. And so that can actually be really motivating for folks to know, like, okay, great, I want to stay because I want to venture options. And I already know they're in the money. Like I know that because these investors came in and this is what they said the company's worth. So assuming nothing goes crazy, like you feel good. So that can be motivating. the mistake people make that impacts would impact somebody who is just working at at a startup would be hiring too many people too quickly. because it is hard to hire A players, and if you hire a bunch of C players And you previously had A players, well, all those A players are going to be annoyed because these people don't know what's going on and it's it's dragging down productivity and it's frustrating. And so two things happen. One, you waste capital because you instead of hiring two of those C people, you could hire one A person. and then two, it also can can frustrate some of the folks who really are high performers. So I'm always very thoughtful. you know, when we invest, I think. One of the most common mistakes is like you just go out and you burn a bunch of capital and you just hire people. You think like, if we just hire 40 more engineers, like we'll have our product roadmap done next year. Well, it's really hard to hire 40 engineers in one quarter that are top notch. Like it's that's a hard thing to do. or, you know, I'll just hire all these sales reps and we'll just add more revenue. But like what ends up happening is Well, your top performers need to train the new people. So they are actually less productive. And if you don't hire good people, like it can suck productivity out for a little while. And so we always try to advise companies to be really thoughtful. normally people have more ambitious hiring plans than they can actually achieve. And I love when I go to a board meeting. Actually, we had just had our first board meeting of a new investment, and they said, and they were upset at themselves. They said, we're behind on hiring. And I said, That's great. Because you're hiring A players. Like, I don't want you to just hire for the sake of h you we said we're gonna hire sales twelve sales reps. And they said, Well, we couldn't find twelve that were good, so we're behind. I'm like, that's fine. That's fine. We'll use the cash for the next A player coming down this pike. So, those are some things that I've observed from like the board level that I'm some of this is are things I've heard or ma I imagine is happening because I'm seeing the numbers and the output that's that's being driven by these, but Yeah, there's some human pain that can go on if people make that missed step too. Bethany (38:15) Yeah. Absolutely. I think being in our position we don't always see the monetary impacts of hirings or anything like that. And I famously onboarding is very expensive even in large enterprises. So I'm sure especially for a startup where maybe or a a new company where things aren't as in stone or there's not necessarily processes for everything, it can even be more difficult. And that makes so much sense with the A players being Melanie Nabar (38:25) Right. Yeah. Yeah. Absolutely. Bethany (38:45) Than needing to serve as coaches and not eating into time and figuring out the the organizational structures from there. Melanie Nabar (38:52) Yeah, absolutely. And I think to your earlier question, Erica, on like how could you help push a project you want internally in at a big org, that's a lot harder than at a small org. Like I'm I was answering that question thinking, you'll just you just call up the CTO and you tell them this is a great idea. But that's not always the case, right? and I think like really showing that you can monetize like this, these are the this is why from a business perspective and like back of the envelope, this is I think the impact. I think that one is would be very good for people's careers because you're like thinking like you're thinking like the people at the top are thinking. The top people at the top are just thinking about making sure they're growing profitable and returning capital, right? they're thinking about their, you know, outcomes at the end of the day. And if you can kind of take ownership like that at a different level, I think that's really powerful. And at the end of the day, any time you're spending in your career is an investment. Like you are investing your time and effort at one company when you could be investing it at another. And so you are also an investor in the companies that you're working at. Erika (40:01) Yeah, I could definitely I can definitely or attest to that difference. My first job, my surface first software engineering job was at a startup and I would have lunch with all the people from sales. We were good friends. I now know, I don't know, five people from sales and like don't talk to them very often. So I could not tell you, you know, the the clear cus yeah, the revenue loss or anything like that. So yeah. Melanie Nabar (40:15) Right. Yeah. Why they lost deals this past quarter, yeah. Yeah. And hopefully those conversations are happening like at at the level up. Like hopefully the CTO is talking with and they're going through the reasons. And that's that's the trust is that that's where your direction's coming from is those things. But yeah, it's definitely harder to get your hands on some of those things. I do think AI will make that easier. Like I think organizations are gonna have broader context layers that you're gonna be able to Erika (40:42) Yeah. Melanie Nabar (40:55) Get information in a way that you weren't able to before, you know? Like there's no reason why you shouldn't be able to pull information on like why we lost deals just from your instance of plod that's connected into various systems, right? I don't know that organizations are there yet, but I think that's a hope. Erika (41:06) Right. Right. As long as it's available. Yeah. Bethany (41:18) Yeah, I think that very much depends on organizations that are open by default versus closed by default. if some are hiding information or like just maybe not used to sharing it all out, then I can totally see that being harder for them to use or folks in other areas to use AI to get that. But a AI serves as such a great explainability layer for Melanie Nabar (41:23) True. Yeah. Yeah. Yeah. Bethany (41:42) as someone who's not financial explaining what the finances mean and what in relation to to my role and and things like that. But it really it seems like the culture of the company really maps to that AI usage in general too. Melanie Nabar (41:42) Right. Yeah. Yeah. And then there's the piece of like if you're a public company, right? Like there's just things you can't you can't have every person have access to your, you know, bookings month to date. in a public company. Obviously there's restrictions for a reason 'cause you're in the company, but like there's going to be pieces that like that and situations where it isn't fully shareable. But I think there'll be some opportunities too for A lot of the organizations at my companies, the silos are coming down from like a functional area perspective because people are realizing like it it's about building and like what does it take to build? Well, probably takes an engineer, product person, someone from customer success and someone from sales or marketing. And like all together, you could probably solve quite a few problems that that each of you are facing on a day to day situation. Bethany (42:49) I I love that framing so much of of earlier on in the conversation you mentioned people are builders now. It's not necessarily engineering versus product versus sales versus HR distinction. And everyone has that context that they can contribute to that really makes it interesting. That's awesome. Melanie Nabar (43:04) Yeah. Yeah, absolutely. Bethany (43:10) Alright, well we are coming up to the end of our time, so I am very excited for this fun segment. so I I live vicariously through people who have it have pets because I do not have one. but I was scrolling your LinkedIn and I saw you posted a picture of your puppy with the caption for every new investment, startup, or big win, there's a pup under a desk somewhere thinking I helped. so I happen to know Erica also has a Melanie Nabar (43:21) Ha ha Yeah. Bethany (43:38) dogs. So I I would really love it if I could get introductions to to your pups, their their titles and maybe the company of your life and an OKR that they are crushing this quarter because we were talking about collecting data, you know? Melanie Nabar (43:52) Yeah. Yeah, absolutely. I wish I was working from home today or I would be able to introduce you live, but she's at home. my pup is Lola. She's a field golden retriever, and we got her during COVID, so she's a little bit attached, as most of the COVID dogs are. but she is a an expert at the silent support. Like she will always sit on my feet. I'm any video call that I'm on, if you see me in my home office, like she's she's on my feet. and so I would say that you know, s snuggles per day is she's crushing it. It's off the charts. absolutely. She's our emotional support, you know, animal in the house for sure. Bethany (44:39) good job Lola. Melanie Nabar (44:39) Head of HR perhaps would be her title, you know? Bethany (44:43) I love that. Absolutely. are we getting a live demo from Erica? man. Erika (44:50) This is here he is. Jeffer is my my chaos agent. So he he's really good at barking at any any sound that happens. So yeah, I I have to I have to always make sure I'm I'm able to handle that on any like video call. yeah, really, really good at Melanie Nabar (44:58) C Yeah. Maybe head of security. Head of security is a important role. Erika (45:18) Yes, there you go. yeah, I'm just like never getting attached to to to speaking at any one time because I might have to be forced on mute. So he's good at keeping me on my toe. Yes. Melanie Nabar (45:28) Yeah. Hey that's good. He makes sure you listen. Listening is important, right? Bethany (45:33) It's so true. Protecting your work life balance too, he's like, I got you. Ugh. Erika (45:35) Yeah, Melanie Nabar (45:37) Right. Yeah. Erika (45:40) he's also like constantly in here. so yeah, he's he's more of the support. My my other dog, she she's just like an independent spirit, but she's so sweet. So I think like when I'm having a hard day, like Melanie Nabar (45:40) Absolutely. Erika (45:57) She she like spends most days like outside or on the couch or just kinda like doing her own thing. But I can always find her and she always just like makes me happy. So yeah. Melanie Nabar (46:01) Yeah. Yeah. Dogs are so good at that. They they're just having the best day every day. So you remember like, okay, today is actually is a good day. You're right. So Erika (46:15) Yes, exactly. Exactly. Bethany (46:18) Unless Jasper hears something, then it's a serious, serious time. amazing. Thank you all so much for introducing Lola and Jasper. I I I needed that really. All right. well Melanie, thank you again for joining us. This was such a really cool conversation. where can folks find you? Melanie Nabar (46:44) Yeah, you can find me on LinkedIn. I'm pretty good at being responsive there and or on Volition Capital as a website. My email is on that as well. So feel free to reach out there. And if you want to follow me, there'll probably be some more puppy content on LinkedIn coming. Bethany (47:01) man, okay. That's a that's a pretty good sell, honestly. It it was a cute picture too, so I definitely recommend that. all right. Well thank you listeners so much for tuning into Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye! --- ## Episode 67: Safety-Critical Software | System Reliability for Live Events with Lars Olson - URL: https://overcommitted.dev/safety-critical-software-system-reliability-for-live-events-with-lars-olson - Published: 2026-07-07 - Audio: https://anchor.fm/s/102586d64/podcast/play/122479971/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-6-6%2F427480997-44100-2-26a580827794d.mp3 ### Show notes Summary What happens when a software bug stops a concert—or endangers a performer flying above the stage? System reliability takes on new meaning in live event tech. This week, Brittany and Erika talk with Lars Olson, full stack engineer at TAIT, about building safety-critical systems that power the world's biggest tours and theme parks. Lars shares how React and Rust meet real-world consequences, why error boundaries matter more than you think, and what production safety teaches us about code quality and engineering culture. Links * My Hometown Recipes - ⁠https://myhometownrecipes.com/⁠ [https://myhometownrecipes.com/]  * Erik Lars Olson - LinkedIn - ⁠https://www.linkedin.com/in/eriklarsolson/⁠ [https://www.linkedin.com/in/eriklarsolson/]  * Bluesky - ⁠https://bsky.app/profile/eriklars.bsky.social⁠ [https://bsky.app/profile/eriklars.bsky.social]  * X - ⁠https://x.com/energyblazer⁠ [https://x.com/energyblazer]  Hosts * Overcommitted: ⁠https://overcommitted.dev⁠ [https://overcommitted.dev] * Brittany Ellich: ⁠https://brittanyellich.com⁠ [https://brittanyellich.com] * Erika "Eggyhead" Eggemeyer: ⁠https://github.com/eggyhead⁠ [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany, and I am joined by Erika (00:08) Hey I'm Erika Brittany Ellich (00:09) We 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've learned. 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 Lars Olson, a full-stack engineer at TAIT the live event technology company behind the staging. automation and show control systems for some of the biggest tours and spectacles in the world, from the Olympics to major arena tours. His work sits where software meets the physical safety critical side of live entertainment, where code controls machinery moving over and around live performers. First met Lars at CascadiaJS, we've met at the last two now, and every time I hear about his role, I get really excited to hear more. So Hence why we are now on the podcast. So welcome, Lars. Lars (01:07) Thank you, thank you. Brittany Ellich (01:08) to kick us off, what is one thing you are currently building or obsessed with learning right now? Lars (01:13) Yeah, so I I I had a couple things written down. honestly there's there's just so much going on at work and outside of work. at work right now we're doing a whole rearchitecture of our of our software. So it's about a 10 year piece of software. We've decided to redo it at this point. so maybe we can talk about that a bit later. other than that, I have a personal project outside of work called My Hometown Recipes. I think I remember mentioning that to you potentially last year, but it allows you to either use AI to identify recipes from a specific part of the world. or user submitted recipes, but kind of hard to get people to use a site without people submitting a recipe yet. and then other than that, I am working on a Expo app for my sister because she's had a nice mobile idea for a couple years. And then I just actually picked up a consulting website for a group of physicists. So quite wide range of side projects at the moment. Brittany Ellich (01:59) Yeah, you could say that you're you're quite committed, overcommitted even. Yeah, that's a lot going on. That's great. Cool. so yeah, tell us a little bit about what you do for work and like how did you end up in this space where you're writing code for live shows? Lars (02:02) Yes, overcommit. I am overcommitted at the moment. Yeah. But yeah. Yeah, so at TAIT, like you mentioned, we're one of the the largest stage manufacturing producers in the world. we also do like cruise ship entertainment, like theater theaters, opera houses, anything like that. we have two pieces of software, one called Navigator, which elec does it's our oldest piece of software, it's about twenty-five years old. that's generally what most of the the industry uses at the moment. We also have IQ, which is what I work on. that's been developed over about the last ten years and it's essentially an easier version of Navigator. I've been with the company now about four and a half years and Navigator's still hard for me to use sometimes. ⁓ yeah, it's it's it's pretty intense piece of software because it's just adding features for twenty five straight years. and so IQ was supposed to be this new solution, basically integrates the same with Navigator, the same safety code and everything, but you can train somebody on two weeks instead of two years. Brittany Ellich (02:51) I don't know. Socks. Lars (03:05) At least that's the general premise. And so yeah. I gener I developed the front end of that and also generally we call the the f back end of the front end. So all the APIs and everything that integrates back to Navigator. So yeah. Brittany Ellich (03:18) Okay. So IQ sits in front of Navigator, essentially. Okay. Lars (03:21) Yes. Yeah, pretty much just like a a new front end layer, windowing and everything. We have like a existing C plus plus app with a React front end, and then we're switching to a Rust backend like windowing with a React front end as well. Yeah. Brittany Ellich (03:32) Nice. Rewrite it and rest. That's everybody's dream. Lars (03:36) That's kinda where everybody's going. Yeah, we had quite a Rust fanboy when I first joined the company who's who's won me over over the years. Erika (03:42) So it's it's the like the operators who use the software and it like integrates with the the systems that are put up. Lars (03:50) Yeah. so either we'll manufacture the hardware ourselves, so it's like the drives that will be an axis going up and down, left and right, return table spinning, or we integrate with pretty much every other solution in the market. And so Navigator will do the safety code integration with the hardware, and then we'll write the the front end on that to integrate with Navigator and then like you said, it's operators who will either do a live move or pre program a show to be like at ten seconds move this up and down or T do time code with certain songs. Brittany Ellich (04:20) Makes sense. Yeah, that's really interesting. I think it sounds like something that you probably can't get wrong super often. It's probably pretty important to like work well. so yeah, that's I feel like that can be a little bit different from a lot of software out there where it's like, it's got a bug, I'll go fix it. ⁓ yeah. Yeah, not not quite as much of a thing. Lars (04:32) Mm-hmm. Exactly. it the website crashed, just refresh. But it's like Brittany Ellich (04:46) So when you tell other engineers what it is you work on, what is it that they usually like assume about it or they typically get wrong about it? Lars (04:55) The first one I always love hearing is like, I work for stage automation, like whatever. And people are like, I love the lighting you guys did. I love this concert. I'm like, We do everything but lighting. That's like the first thing people go to, and we're like, Okay, everything else. ⁓ and that's like the stage automation that goes up and down. We do performer flying, we do stage like pyrotechnics. Brittany Ellich (05:03) Yeah. Mm-hmm. Lars (05:14) And then a lot of the ones as well, people assume are like, I work on stage automation. They're like, you write the shows, like I went to Taylor Swift, that's very cool, you did the programming for the show. And I'm like, no, I work on the application, like the internal tools behind it, and then somebody else at our company will actually do the programming. Yeah. Brittany Ellich (05:30) Okay. Is it permit pretty much entirely within your company that they do that, or is it like a a tool that anybody can use across the industry or? Lars (05:37) Over the last few years, we've actually been kind of slowly building an internal team that does that. But over the last 25, 30 years, when Navigator was first created, it was mostly contractors. And I think it's hard to break in a navigator in IQ. It's like generally you you have to be involved with the industry already. ⁓ But for the most part, there are some contractors using it, but it's it's generally mostly an internal tool that will send a few people out for each tour to operate it. Brittany Ellich (05:54) Mm-hmm. Hmm. Yeah, that's really interesting. Yeah, I could see how people think the lighting first, that's like the first thing that comes to mind mind when I'm like, designing a show. But there's so much I feel like that goes into it that you don't even realize is happening. like you said, like the stage automation and the stages moving up and down. I feel like when it's done well, it's not really a thing you're like, look at that stage move up and down. It's just like part of the experience of the show. Lars (06:10) Yep. Mm. Yes, exactly. It's it's completely transformed how I go to shows now. It's like the first thing I look for. It's like, look at that really cool thing. And like generally I think sixty, seventy percent of the times it's actually us doing it. There's very few shows now I go to where it's not a TAIT concert. So now I'm always looking for like something going wrong. Brittany Ellich (06:35) Mm-hmm. Interesting. ⁓ that's cool. no bug reports. Erika (06:45) 'Cause I mean I can think of so many things that could go wrong, right? Like it's like the like the hardware could malfunction or there could be a software bug. Like we're talking about like designing for failure scenarios. There could be like a really crappy network connection. Like, I don't know, some of these some of these stadiums or whatever, like maybe they've improved their Wi Fi, but I know like I've been places where my Wi Fi doesn't work or something like that. So like how do you manage that like the network connection and that kind of stuff? Lars (07:11) Yeah, I we we've had Yeah, so generally we'll like you said that we've had network dropouts that have caused issues before. but generally we'll set up our own like network within a stadium. And so we're not reliant on the stadium that we visit. Just generally as well, because every single stadium we go to, every single arena is completely different how they do technology. And so you can't really rely on the venues you're going to. but yeah, generally we'll we'll set up our own network. everything is generally com completely isolated, so you don't want like somebody in the crowd trying to hack into your system mid-show. ⁓ yeah, and so we're we we we try to be entirely, you know, offline as possible, but a lot of cable runs and everything, so we really don't even have a much of an exposed Wi-Fi for it. Brittany Ellich (07:47) Makes sense. Okay, so there's a lot more that goes into it. I feel like that is this like are is TAIT usually like one of the first groups that shows up to set up for a show? I would 'cause I imagine a lot of that stuff you'd have to build around that. Lars (08:08) Yeah, so w we're out all the way actually from design of the show now as well. there's another company we recently acquired that does the what the what the show will even look like, and then they'll move to the next stage where we manufacture the show. and then it goes all the way to us doing the load in for it and the loadout. and sometimes it's the entire show, stage automation, like even helping set up the lighting, and then sometimes it's a combination of like somebody else did the stage, we just did the automation in the background. but we're generally always like the first ones in there helping it set up. Brittany Ellich (08:36) Did you was this the first place that you've been then where you've had like where things have to work like the first time they you know, they that it runs? Is that a new or you or? Lars (08:44) Yeah. Yes. That's pretty much new for me. So like I s after I graduated college, I started out at Navient, which is a student loan company. So sorry if you guys have student loans. I was helping out rewriting the COBOL mainframe system to some a modern stack, which was Kotlin and React. I was actually hired as a back-end developer and then quickly realized that I don't like backend development. And transition to be a friend of the developer. And so I I kinda learned React there for a few times. I had my own side projects. and then TAIT actually ended up just hitting me up on LinkedIn. And I was like, Well that's the coolest job ever. How could I not apply? so that's pretty much how I ended up there. Brittany Ellich (09:19) Yeah. Yeah. That's awesome. Yeah, very different. S I mean, still things need to be correct, I guess, when you're working with financial systems, but it's a Lars (09:30) It it is correct, but it's like not a it's just like a a piece it's a website, it it can crash and everything and it's fine, especially working on the front end and everything, but there's not some like like this talk has mentioned, there's nobody performer flying or there's nobody on a stage in front of me at the moment. Brittany Ellich (09:45) Yeah, that makes sense. has that changed d does that change the way that you design or test things? Like is that does that show up within the work that you're doing day to day then? you can't really like redo a thing. so yeah, how does that work? Lars (09:58) Yeah, I think we're we're pretty tedious about obviously writing unit tests, integration tests. Like we have a pretty pretty end to end stack of of everything being tested. we have a variety of like code review for multiple developers, then it makes it to like one round of QA, and then it makes it to a next round of like full end-to-end testing for QA. we have physical hardware in the office, so we have like physical things we can move up down. and so it makes like even though we try to work quick, obviously, it's like ten rounds of of testing before something actually makes it to a customer. 'cause it like you've mentioned, it can't go wrong generally, and I've seen in the past where it has gone wrong. and we've bitten curled pretty hard. So Brittany Ellich (10:35) Yeah. Yeah. You were mentioning before we were chatting that TAIT's been around for a while now, right? It's forty or fifty years. That's yeah. I feel like that's also not something that everybody who works in tech is like experienced with. Lars (10:49) Yeah, it's it's kind of a fun one. So like Navigator I keep mentioning has been around for about twenty, twenty-five years now, but before then we were generally just a hardware company. we we started out just manufacturing stages essentially or different props for a stage or anything. I think we our tagline is that we've been on all seven continents and in space. so we we did I think it was a Metallica concert in Antarctica. and then when you two did a concert way back in like twenty ten, maybe earlier than that. we sent some letters up to the space station to like record a video for them and then they presented it during their their their concert. Brittany Ellich (11:23) That's cool. Lars (11:25) But then yeah, just over the time we've tried to integrate more and more and we're becoming like a lot more of a technology first company. I mean that's just how the world generally is. And like we're not just doing staging anymore, we're doing like like theme park rides and like permanent installations which require mostly software. So yeah. Brittany Ellich (11:40) okay. Interesting. Theme park is that specifically like the like the traveling theme park rides or or does it matter? Is there a difference between them? Lars (11:48) No, so like ⁓ generally a lot of it is like we'll do either like big props. so like you're on a ride and you'll see a prop going up and down left or right next to you. So like sometimes it's not the actual sh show control, but it's the things moving around you, or like we'll do scenery building. I don't know if I'm allowed to actually mention the specific rides that we've done. But ⁓ yeah. We'll do a lot of the like automation for like Brittany Ellich (12:08) Fair. That's interesting. Lars (12:13) If you're actually on the ride, like d controlling a big arm, that actually has people on it. So that has many layers of like UI safety code written underneath it, r like manufacturing the hardware underneath that and everything. So Brittany Ellich (12:26) Yeah. Yeah, that's really interesting. and there's this thing that's been happening recently in the tech industry. You might have heard of it. AI. it's been mentioned a few times. how is that like I I know like the c the talk right now is always like, you gotta ship faster and move things faster, but like that doesn't necessarily work where you are. Like how how is that working where y what are your thoughts there on AI? Lars (12:49) We're trying to find a good bounce for that. I actually personally love you love AI. I was a big AI hater like a year and a half ago and then I actually used it and I was like, okay. but no, our our director for software engineering is like a huge proponent for it. Like we have Claude, we have Copilot and everything at work and we're allowed to use it. generally it's still gonna be this incredibly strict like QA process, still requires human developers re reviewing the code. We still have actually copilot reviewing our PRs now. Brittany Ellich (12:53) Mm-hmm. Lars (13:14) But generally I try to break it up between like what I'm gonna use AI for is like I generally don't like to use it for if it's gonna be a something's as like a safety system. if it's actually interacting and it's something that can trigger an emergency stop on a device. It's something I'd like to be a little more handcrafted for. but generally it's been great. I I actually have a Claude code thing going right now on the side at work. ⁓ Brittany Ellich (13:38) Thanks. Lars (13:39) It's yeah, it's great. So I I love doing it. I mean there's a lot of stuff that we can work on that's just like simple displaying of information that is perfect for AI. Brittany Ellich (13:45) Mm-hmm. Yeah. Yeah. No, same. I almost always have something running now, it seems like in the background, just operating. it's a very, very weird world. and it sounds like I mean you have a lot of controls already built in for safety anyway. So really that might be one of the most ideal areas to be experimenting with AI coding, I would think, because like you have a lot of stops in place, it sounds like to Lars (13:54) Mm-hmm. Brittany Ellich (14:11) review and make sure everything is good. Lars (14:14) Yeah, and and thankfully for like the hardware, we have like a physical piece of hardware that goes up and down. But then on top of that you have like safety PLC code and controllers that does its own level of safety. Then you have Navigator doing safety code, and then you have us doing our own safety code for the UI. ⁓ and it really is like that required full stack because you're actually moving people, you're doing things in front of a crowd. Like there's there's certain cases though where I've seen like really early on, when I joined the company about five years ago, we had some persistent web bug that kept Brittany Ellich (14:28) Mm-hmm. Lars (14:43) crashing a window that would actually show you where you're like, let's say you're in the middle of a show and it says, I'm at position 10, I'm going to position 20 next 20 feet. the window would crash every time you'd start up the software. Even if we had like a specific error boundary, you'd refresh, it would crash again. So it's like that's just not a well-designed piece of software because it's like, how do you get out of that? The only way is booting up our old piece of software navigator that you may not know how to use if you're trained on two weeks of of IQ. Or you can press the E stop button and stop the concert because it's safe, but then your show can't proceed. So. Brittany Ellich (15:14) Yeah. Yeah, you can't Erika (15:16) So how did how did like how did you respond? Like how what was the what was the learning like from that and like how was it how was that handled? Lars (15:25) Yeah, so like when I first joined the company it was strictly JavaScript, no TypeScript on the app. so we had a just a lot of interface bugs of just like using things that weren't null checked, or using incorrect like we used manipulation on a number and it's actually a string. and a lot of like fixing small bugs just like that, thankfully, was just just conversion to TypeScript, which most most of our app is now. and then a lot of it was just like really bogging down and like we created a much higher QA stack. So like all this QA I keep talking about wasn't fully in place five years ago. so redeveloping how we did QA, redeveloping how we did unit testing, integration testing like that was was kinda how we solved it. Brittany Ellich (16:03) That's cool. I think that that's work that at least within my career, maybe it's just places that I've worked. But I feel like it's always a thing you really want to do, but don't often get the the time set aside to do it because everybody's always like, no, new features. So that's cool that you've got actually gotten to see how that is implemented over time. Lars (16:12) Mm-hmm. Yeah, this Yeah, and and we have these these crashes as well that occur and it's like, okay, it's it's crashing and we have another show tomorrow. Like this is an opera house, for example. So it's like the bug needs to be fixed today and we're gonna ship it tonight and it needs to be used by people tomorrow. So it's like we need to work slow for safety, but we also have these incredibly tight deadlines. So that really makes us need to be diligent when we're actually developing it the first time, or we're gonna run into these scenarios where it's like, Okay, well, you might need to work a little bit overnight. Erika (16:22) Yeah. Yeah. Yeah, that it is informative though, like of this idea of a lot of small bugs cropping up and creating these larger things. so that's a good lesson to learn. Sometimes it's not one big bang, it's a lot of little things that add up. Lars (17:06) Mm-hmm. Brittany Ellich (17:06) Yeah. I feel like you probably see a lot of really weird failures too that like somebody who's just works specifically in web development wouldn't actually anticipate. like, somebody, you know, spilled beer or something on like the the stage or something like that. Is that anything weird that you also have to be prepared for that you wouldn't need to otherwise? Lars (17:21) Exactly. Yeah, this is one I've actually run into in the past, is let's say a piece of hardware goes bad. I mean, it's just like a drive suddenly is shorts out or something. It can still act like it's going correct. It can perfectly spit out data, but it's just gonna start spitting out bad numbers. And so it'd be like, let's move to let's move to position like feet twenty, and it's like, okay, I'll go to twenty, and it's like four hundred just because the hardware's gone wrong. And so, like, how do you code around that? I mean, I don't even know if I have a great answer about that. It's like the safety code will prevent the device. Brittany Ellich (17:46) no. Lars (17:54) From going past its specific measurement, but you do also have to catch this in the UI being like, this is incorrect, it's just displaying wrong information. we do get statuses back from devices, so like maybe it's a lot of like conditional rendering, like maybe we don't render to the current position if we can see the devices in a bad state. so you're not confusing the user. Brittany Ellich (18:16) Yeah. Dealing with non-deterministic outputs before it was cool. That's funny. cool. Well, I want to talk a little bit about like what people that are working not on safety critical work can like steal from some of your practices because it sounds like there's a lot that you've learned in this role. so one of the things, is there anything that you think like somebody on like a very conventional Lars (18:20) Mm. Brittany Ellich (18:39) web development track might be able to like learn about working on live events or working on hardware or anything like that with physical stakes. Lars (18:48) Yeah, I think the biggest one I'm always going to mention is error error boundaries have become like my best friend. generally you're just gonna try to at least narrow it down to the smallest piece of your software that can crash. if that's an individual widget, if that's an individual certain section of the page. I've I've dealt with a lot of that w before. Like in the past, if our web crashed, the whole every single web page would crash. then we started isolating it down to a single web page, then a single section of the web page, and we've just kind of gotten more granular as time goes on. Which has been great because I I've started taking that into my own personal projects now, like this recipe app that I mentioned. I had a lot of bugs with the specific map section. I've tried to error boundary like certain parts of my own app now where it's just like, okay, this can crash, but it's fine, we can still recover the rest of the application. We're not like giving a bad user experience to other people. Brittany Ellich (19:32) Interesting. Can you describe what an error boundary is? So you're basically like preventing an error from going outside of a boundary. Lars (19:38) Yeah, you're essentially just wrapping other components, being like, okay, if it's gonna catch a crash that anything that occurs underneath this, ⁓ you can r you can provide some type of fallback component to render hey, this this thing crashed, please press refresh to refresh just this individual section. you can even provide like fall like a suspense fallback to show a spinner as it's trying to reload and everything like that. So Brittany Ellich (19:45) Mm. That makes sense. Yeah. I feel like it Erika (20:01) Yeah. I was gonna say that that's the first thing that kind of like came to mind when you were talking before about your work and you know, like the layers of errors, like like I guess this is slightly different than preventing errors from spreading, but with your example before of the like the arm moving four hundred instead of two hundred feet 'cause something went wrong. Like there's multiple places to handle that too where it's like, well you have you mentioned like a safety check to say like, no, don't actually move this four hundred feet. Like you're only allowed to move wherever. And then also on the like controller side to say like, hey, this is like this this event fired, so like don't trust this from now on. So you kind of have like two different two different information sources to yeah, to to correctly handle the situation. Lars (20:56) Yeah, it's it's all interesting problems 'cause like coming from a maybe less like I came from a traditional web sense, but it was also still like internal tools. I've never actually like worked on a public website, at least full time. but then going to this company where it's like it needs to be right the first time as much as you can, really changes my perspective about not just working here, but I think any like any place I work in the future is like how safety critical you need to be, even if it's just a basic website. Even if it's just to provide a good user experience to someone. Brittany Ellich (21:26) Yeah, yeah, for sure. I feel like that's something that we thought we talked a lot about, especially at GitHub with so many like moving pieces and parts, like you don't never want to be the one app that takes down the rest of the site. Always isolate things and make sure like that's very good, very good. Lars (21:36) Yes. Mm. Yeah, for sure. Brittany Ellich (21:43) are there any habits or any like instincts that you think that you've picked up while while doing this work that you're gonna, you know, for sure take on to future roles? And it's okay if not, I mean Lars (21:54) You I'm not I don't really actually have anything good on that one. good habits. I think it's all coming back to like the same stuff I keep saying. It's just like I I I think what I've told what what I've talked about on my managers here is like trying to go more the architectural route. And so with AI I've done a lot more like spec driven development. And so it's really like right out an entire spec of of the feature that required. We're not like asking clo Cloud Co to develop something for us. But really thinking about every little single piece, we start like diagramming and everything, provide the diagrams to Claude. yeah, we've just gotten pretty it's just a lot more of like minute details now than I was like four and a half years ago on on literally every single piece of this. Brittany Ellich (22:34) That makes sense. Yeah. And you were saying too, like just getting a a vibe of like how safety critical things actually are. Are there other things now where you know like all right, this is a thing that's not gonna impact humans or something? We don't have to have as rigorous of a scope for it. Yeah. Lars (22:48) Yeah. Yeah. I always try to like separate it between like visualization of data versus something that can actually interact. so like one window we have on our on our software is called the device window because everything is considered a a device and essentially it just shows every single device in your app. all that's really used to do is just like show the current position of things, show the status and everything. And so like that's less less mission critical because all it's doing is just displaying information to you. It is important. but then like we have another page that's incredibly important that's actually showing what part of the show you're running, what's gonna come up next, what like every single piece underneath that. and so we have to be a lot more diligent on those types of pages where you can actually load things on what's gonna run for a show. This is how you actually we have things called channels. So like you load something to one channel and this is where it's running the show, but suddenly let's say that channel crashes, or you can pause it, you can load something to another channel. Let's a joystick and you can move it really quickly manually, just because we got into this weird situation where maybe the thing ran into the ground because we moved too far. ⁓ so stuff like that. There's just like recovery methods in like certain windows where we really need to be careful, and then some are just like, this is a visualization window. We can be a little bit less diligent. Brittany Ellich (23:57) Mm-hmm. Yeah, it makes sense. interesting. And then if there was anybody who wanted to build their career around working in, you know, either in live events or you know, anything else that I I guess you're interacting with a lot of things that your company also manufactures, what do you recommend they like learn or do to get into that? Lars (24:19) Mm-hmm. it's funny, so most of the company is actually like theater kids. I will say fifty or sixty percent of the people at our company I swear are probably theater kids. ⁓ I don't come from a theater background and so most of the people in manufacturing, designing, we actually have like seamstress seamstress seamstr you can't say that word. ⁓ yeah. But doing sewing, we have painters, we have like crafters. There's so many different types of jobs that we have at our headquarters. Brittany Ellich (24:26) Nice. Mm-hmm. Sorry, buddy. Lars (24:49) We also do like inflatables for music festivals now. and so it's even for software, it's just like mostly a passion more than anything. You can always learn what you're gonna like what you're gonna do. but I think just like having a passion for the work, because I have a little bit of a music background, really made me like really wanna work here. and including many of the theater kids that work here is like, TAIT's the place to go for if you wanna do live entertainment. Brittany Ellich (24:52) Mm-hmm. Hmm. Mm, yeah. That's cool. Lars (25:17) And like I was hired as essentially a a mid level engineer, but we've hired junior level engineers before and interns and everything. And a lot of it is just like be passionate about the work you're doing. We can teach you how to do an error boundary. We can teach you about safety code. Brittany Ellich (25:30) Nice. Very cool. Well, with that, at the end of each one of our shows, we always do a fun segment. and this one's extra fun because you work on something really cool. So we planned the dream show lightning round. so it's gonna be a rapid fire, no wrong answers, gut reaction to a couple of different prompts. just what would your dream show be to plan, essentially? I guess it's not specifically exactly what you're working on day to day, but it seems like you're very involved in music and love music. So this is yeah. ⁓ yeah, which one you would want to be a part of, which one you'd want to like prepare for or go to even. You know, whatever whatever feels right in the moment. Lars (26:02) You said which one I would plan? Yes, yeah. fan of electronic music generally. ⁓ and one artist that I've always loved is Daftpunk. they've yeah, they've split up at this point. They don't do any pro live performing anymore. So like I I really feel like I missed out on that like era of E DM. and that like I've always watched live recordings of their shows. So that'd be awesome to to either be a part of or just make it to one. Brittany Ellich (26:15) Mm-hmm. yeah. Mm-hmm. Yeah, they have incredibly cool shows too. I feel like I th all of their videos are really neat. ⁓ so if you had a a blank check and you don't have to worry about the laws of physics for one specific event effect at a show, what would you build? Lars (26:37) Mm-hmm. Mm, okay. I actually have recently thought about this problem. one thing we always run to in s in like stage production or anything, you always have to manufacture around like cable management. everything has to move around cables. We've got cables snagged on things. So like having some type of like wireless power would enable you to build like very cool stages. just being like, we're gonna move that thing up there. Nothing has to be attached to it. It can just go up and down or left and right or spin around. without needing to like build in all those crazy extra things to get cables up to it. Brittany Ellich (27:15) Yeah, I could see that being really problematic. Erika (27:17) There's nothing like battery operated that can do that? Lars (27:20) I mean we can certainly do battery operated, but like the amount of weight on batteries you'd have to like put on this floating thing and like maybe they wouldn't last three hours for a show ⁓ for the weight of that many batteries. Erika (27:25) Yeah. Okay. Interesting. Yeah. Okay. Brittany Ellich (27:35) Hmm. Yeah, that's super interesting. That's an interesting constraint. what do you think is the most fun engineering problem from the following? A massive stadium tour, an intimate theater residency, a permanent theme park installation, or a one night spectacle? Lars (27:53) Hmm. Most think a theme park installation would probably be the most interesting because it's the one used by the most people over time. And so like a a big s I mean not massive stadium tour. Actually when you think of like Taylor Swift or anything, I think her thing went on for like six months and each s thing was fifty to a hundred thousand people. So it's probably millions of people. But then let's say you build something at Disney World or Universal, it's like that's millions of people every single year for twenty, thirty years. ⁓ Brittany Ellich (28:19) Mm-hmm. Yeah. Lars (28:23) And you can get some really interesting problems to solve for that because it's like we're not just a one off ride or it's not just a stage that needs to last one night, but it's it's something that needs to be maintained for twenty years. Brittany Ellich (28:34) Mm-hmm. Yeah. Plus then you can go on the ride and tell all your friends, like, I worked on that. Like that's I did that. That was cool. which genre do you think makes for the best show overall? Like what do you think ends up like what music genre do you think is the the coolest to plan for? Lars (28:40) Exactly. Yep. Personally, I'm gonna say EDM, but actually it's probably pop music. I I I will think it's actually more of like the artist than the genre itself, though. ⁓ so like it really depends on how much pride and like how much passion they're putting into the the design themselves. Some artists are just like, build me a stage, build some lighting, it's whatever. but then some people are are some artists I think are involved from the very first with helping design out what they want their s their concert to look like. Taylor Swift, I think, was involved from the very beginning. Brittany Ellich (28:55) Makes sense. Mm-hmm. Lars (29:21) I think she had a hundred, maybe two hundred semi trucks touring on her or concert and they would actually build one stage at one city and start building the next stage at the next city. ⁓ yeah, and so it can get pretty intense, what they're doing. Brittany Ellich (29:31) Interesting. all right, and then I guess this will be the the last one here. What do you think is the most underrated part of a live show that most audience members would never notice, but you notice now, every time? Lars (29:47) Now that I've been to a a ton of shows now related to work. So like TAIT will give us free tickets occasionally to a show, which is like the greatest perk alive. ⁓ and so like I've been backstage to a lot of events before they happen and then I've been able to like see a loadout at the end of the event, but it's generally the crew actually. So like TAIT will bring in twenty, ten, I mean five to twenty people on a show, but also it's generally each each city we go to, we work with stage crew who work in that city. And you'll have two hundred people that put up Brittany Ellich (29:53) Okay. Yeah. Lars (30:14) a giant concert in one day, less than a day, and then they tear it down in like two hours. And so it's like you never would know if you walk in in the morning and you walk in at night, there was never a concert there to begin with. And yet it's like this huge live entertainment that everybody loves and then it's gone to the next city. Brittany Ellich (30:28) Mm-hmm. Gotcha. Yeah, that seems like a very u useful useful thing. And yeah, it's something that you would probably never notice, but that's the point, I guess. Lars (30:37) Yeah, like you never yeah, you never see the crew. Like they're just hiding behind. They're usually having dinner while the show's going on or they go out and go sleep back at the hotel room. 'Cause most of these time these loadout go from like the show ends at say midnight, loadouts by about three AM and then they're hopping on the bus off to the next city. Yeah. Brittany Ellich (30:45) Yeah. Oof. Yeah, that's a that's a brutal schedule. cool. well this has been great. Is there anything else that you wanted to say or I don't know, put out there about it? Lars (31:04) No, I think generally you covered it. I it's it's been awesome to speak about this. I've always wanted to get kind of out there more with like public speaking and talking about more about my work. Like every time I've I talk to you or more people at the conference, they're like, Well, that's the coolest thing I've ever heard of, especially like React and Live Entertainment. ⁓ and so like trying to speak more at conferences, more podcasts and everything, which is great. So yeah, thanks for having me on. Brittany Ellich (31:18) Yeah. Yeah. Yeah. This was great. I'm so glad you were able to make it. yeah, and it was great to hear more about about what you do. where can folks find you online if they want to track down Lars? Lars (31:34) Yes, so Lars is actually my middle name. So you can find me find me at Erik Lars Olson on pretty much every social media. it's E R I K. and so LinkedIn is Erik Lars Olson, Instagram, GitHub. I think bluesky is ericlars.bluesky. ⁓ but generally yeah, I think that's pretty much. And I've tried to grab that handle for for every social media except for I think somebody beat me out in Gmail. Yeah. Brittany Ellich (31:51) Nice. darn. Cool. Well, yeah, we'll include links to all of the all of those as well in the show notes. Cool. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Bluesky and share with your friends. Until next week. Lars (32:06) Perfect. --- ## Episode 66: Keeping Skills Sharp in the AI Age | Developer Productivity Essentials - URL: https://overcommitted.dev/keeping-skills-sharp-in-the-ai-age-developer-productivity-essentials - Published: 2026-06-30 - Audio: https://anchor.fm/s/102586d64/podcast/play/122159765/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-29%2F427052109-44100-2-dd5092dee0013.mp3 ### Show notes As AI code intelligence tools reshape daily programming work, developer productivity and career growth depend less on speed and more on judgment. In this episode, we explore what skills actually matter when AI writes code—and why engineers need a new mindset about staying sharp. From code quality ownership to learning tactics, discover the practical skills that keep your value rising in an AI-native engineering world. Links: Math books: https://www.bravernewmath.com/ Crystal Bepis: https://crystalbepis.com/ GitHub Copilot App: https://github.com/features/ai/github-app Hosts: Overcommitted: ⁠https://overcommitted.dev ⁠Bethany Janos: ⁠https://www.trustyduck.dev/⁠ Brittany Ellich: ⁠https://brittanyellich.com ⁠Erika Eggemeyer: ⁠https://github.com/eggyhead ### Transcript No transcript available for this episode. --- ## Episode 65: Software Engineering in Production With Cameron Etezadi - URL: https://overcommitted.dev/software-engineering-in-production-with-cameron-etezadi - Published: 2026-06-23 - Audio: https://anchor.fm/s/102586d64/podcast/play/121863193/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-23%2F426654022-44100-2-e1fb9f07c5579.mp3 ### Show notes What happens when coding becomes nearly free - but everything else in the software delivery process doesn't? Cameron Etezadi, CTO at LaunchDarkly, joins Erika, Brittany, and Bethany to talk about the gap between code that compiles and code that actually works in production. They cover vibe coding pitfalls, the release-observe-iterate loop, how AI is shifting engineers toward frontline manager behaviors, and why speed without control is a liability - not an asset. Cameron also shares how LaunchDarkly changed their intern interview process to reflect the AI era, what EU regulations mean for human accountability in AI-generated code, and why the classic two-pizza team is giving way to something much smaller. Cameron Etezadi is the CTO at LaunchDarkly and brings experience scaling engineering organizations at Google, HashiCorp, and SAP. He's also a licensed flight instructor with ratings in fixed-wing, seaplane, helicopter, and gyroplane - and has logged over 400 skydives. Show notes: * Cameron on LinkedIn: https://www.linkedin.com/in/cameronetezadi [https://www.linkedin.com/in/cameronetezadi] * LaunchDarkly: https://launchdarkly.com [https://launchdarkly.com] * LaunchDarkly leadership page: https://launchdarkly.com/leadership/ [https://launchdarkly.com/leadership/] * Rainier Flight Service bio: https://www.rainierflightservice.com/rainier-flight-staff/cameron-etezadi [https://www.rainierflightservice.com/rainier-flight-staff/cameron-etezadi] ### Transcript No transcript available for this episode. --- ## Episode 64: Coding Interviews in the AI Era | Beyond LeetCode for Career Growth - URL: https://overcommitted.dev/coding-interviews-in-the-ai-era-beyond-leetcode-for-career-growth - Published: 2026-06-16 - Audio: https://anchor.fm/s/102586d64/podcast/play/121530980/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-15%2F426210919-44100-2-c59c942cb4636.mp3 ### Show notes Summary Brittany's first weeks at Bluesky are reframing everything she thought about coding interviews. Career growth in tech still hinges on algorithm problems, but AI, remote work, and async development have fundamentally changed what actually signals engineering ability. Why do companies cling to LeetCode when software engineers now solve problems in decentralized, AI-augmented teams? We dig into what hiring should measure, why job-hunting feels unsettled, and how women engineers navigate visibility and advancement in the interview process. Links * How GitHub Engineers Learn New Codebases blog post: https://github.blog/developer-skills/application-development/how-github-engineers-learn-new-codebases/ [https://github.blog/developer-skills/application-development/how-github-engineers-learn-new-codebases/] * Diataxis: https://diataxis.fr [https://diataxis.fr] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://www.trustyduck.dev/ [https://www.trustyduck.dev/] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Brittany, and today I am joined by Bethany (00:09) Hey, I'm Bethany. Erika (00:11) Hey I'm Erika Brittany Ellich (00:13) We met while working on a team at GitHub and realized we are all obsessed with getting better at what we do. So we started this podcast to share what we've learned, where you talk 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, it is just the three of us. So I figured let's kick it off with our normal question for all of us. ⁓ what is something you are building or obsessed with right now? And I'll start with Bethany. Bethany (00:46) Man, I am dreading this question because I feel like I I'm not quite sure. I guess if I had to say or my what my mind goes to is the GitHub app just or the GitHub Copilot app just came out. And honestly, this is probably one of the first like not trying to shell or anything, it's probably one of the first tools that ⁓ truly has changed how I work and how I like write code so that's been really fun to play with and experiment with and try to nail down a good workflow. ⁓ but yeah other than that just kinda enjoying the the weather and ⁓ and also trying to ⁓ run a 5k right now. So I actually am doing it. Brittany Ellich (01:28) Nice! That's awesome. Cool. Bethany (01:32) Erica, how you? Erika (01:33) Other side of the AI spectrum where I recently tried to like build a skill. like I've been I've been implementing more like sort of like repeatable AI context. and like it is not as easy as it seems to get it right. Like First first pass at this like skill generation, it got like everything almost completely backwards. Like there's like a V1 and V2, and I was like, this is V1, this is V two. And I started testing it. It was like, this is V1. And I'm like, nope, that's not right. So yeah, I don't know. I mean, it's like a good reminder that, you know, don't take anything without checking it. 'Cause I think I've like gotten pretty comfortable with being like, yeah, that that seems right. so yeah, like very much testing and like, you know, verifying the output of what So yeah, that's kind of I I won't say I'm like obsessed with it because it is like really frustrating. Like I've been like manually testing because when I've had copilot or whatever like AI I'm using, when I have it like test itself, it's like looks good. Brittany Ellich (02:52) Mm, let's get to me. Erika (02:54) Yeah, it's a little bit frustrating and feels kind of manual at this point. If anyone has tips on how to do this better, I'm all ears. ⁓ yeah, but ⁓ I guess it is gonna be more a part of my life. So ⁓ I guess, you know, the obsession is like, I know it's important. yeah, wanna get it better, get it right. Yeah, what about you, Brittany? Brittany Ellich (03:16) Yeah, so I ⁓ just switched jobs. So I've got a lot that I'm learning, which is what we're gonna talk about, I guess, throughout throughout this is you know, learning and picking up new jobs. but one of the things that has come with that is when I was at GitHub, I had like free, unlimited usage of Copilot. ⁓ and so that was pretty much all I used for my AI tool of choice because why would I pay for something if it's free? ⁓ That is no longer the case. So I have been spending some time getting to know a couple of Claude tools, ⁓ the Claude Cowork specifically. ⁓ and then I guess ⁓ Claude Code as well. ⁓ but yeah, Claude Cowork. I some of the one of the things I've been obsessed with is I like rewrote, re put up together my obsidian template for like this new job. And I've been using cowork to help manage it and like keep my to-do list up to date and like Help me go work through notes ⁓ from different meetings I'm in. ⁓ and I've been very obsessed with with that. I think that's been really fun. ⁓ I've also just been very much just like vibing my way through it. And ⁓ you know, it's I don't think that I have anything valid to provide to you, Erica, unfortunately, on like building skills. Cause I'm like, yeah, yeah, that works. Or I'll forget the skill exists and be like, can you do all these things again? So I still need to like, still need to get there. All the way, but ⁓ but yeah, it's been really fun to try out new skills and there are some things that I do miss about copilot too. I've realized that I'm like, mm, I really miss like cueing things. Like cueing isn't really as much of a thing in Claude Code as it is in Copilot, and I used that heavily. ⁓ so yeah. ⁓ anyway, what we're talking about this week. Yes, recently I switched to jobs. ⁓ things are different. Erika (04:55) Yeah. Brittany Ellich (05:05) Now things are weird. I now work at Blue Sky. and I've been obnoxious enough about AT proto at Proto in the past several months to now have found myself a job in that ecosystem. So I'm very excited about it. ⁓ and really enjoying it. But I wanted to talk a little bit about like first, like what is it like to switch jobs right now? And also what is it like to like learn how to do a new thing right now? Because AI exists. And so like a lot of the traditional playbook that I've been using to like learn a new code base is very different from what it used to be. So yeah. Bethany (05:41) Also, we gotta know how it actually is pronounced, at proto or at proto? Brittany Ellich (05:46) I honestly don't know that that's a good question. I don't know. I feel like I always say app proto, but I also hear people say AT proto. It's like gif and gif, like yes is the answer. Erika (05:56) Does it does it stand for something? Brittany Ellich (05:59) yeah. ⁓ so the AT is the authenticated transfer protocol. That's what it stands for. Mm-hmm. Erika (06:05) Yeah. Okay. So maybe like A T is like the formal way and then at is like the cheeky Q way. Brittany Ellich (06:13) Yeah. Well yeah, 'cause you always at people as well, like with their handle and they call it the atmosphere and so it's yeah. It's yeah, yeah. It's been really fun so far though. So ⁓ yeah. Erika (06:16) Yeah. Yeah. Yeah. Well we're we're also curious about the job searching ⁓ experience because yeah, neither Bethany nor I have really done that in a while. So I think ⁓ from ever what I've heard it's a lot different now than it was before. So yeah, how Brittany Ellich (06:40) Yeah. Bethany (06:45) Yeah, for context, we we got our jobs in twenty twenty two and the market was very, very different than what it is now. So it'll be very interesting to hear. Brittany Ellich (06:52) Yeah. Yeah. Yeah, I do feel like, especially if you're interested in startups, I feel like there's a lot happening right now. ⁓ I know there's a lot of people that are like, no, the tech layoffs and everything, but I feel like that's mostly happening in like these big tech companies. And if you're okay with doing the startup thing, it seems like there's a lot of opportunities out there, especially if you have experience. I think it's really hard if you don't have experience yet. And that's one of those like tragic catch twenty twos, like, how do I get experience if you don't let me have experience? But I do feel like, you know, if you're like a senior engineer out there looking for a new thing, you'll probably you'll probably be able to find a thing. ⁓ but I think the thing that's really weird is a lot of these companies have traditionally used like leak code type questions ⁓ to like, you know, assess your engineering shops, which I've always hated personally because I'm terrible at them. ⁓ but also like it's That's a weird skill set right now, right? Like, I don't know. There's very few times where I'm like, all right, I'm just gonna go solve this really hard algorithm for fun. Like that that's what AI does now. So ⁓ yeah, it's really weird. ⁓ and I don't think that everybody has totally caught up yet. I didn't interview it at like a ton of places, but like I think ubiquitously across the board from places I was talking to, they're like, yeah, we're still. figuring out what this means for interviews because like that's been like the goalpost I feel like for a while where they're like, all right, let's, you know, use this really hard lead code problem that kept getting harder and harder because people would just get like really good at doing lead code. and now I think it's is worth even less than it was before. ⁓ Erika (08:41) Yeah. I feel like I don't know. I I feel like I want to push back on the idea that like that's not still valuable to a certain degree because you have to know why it works and how it works regardless of who wrote it. And it can be hard to explain that. you know, even if you get some kind of generated code, like how do you know that it's working? Like how do you how do you confirm that, you know, it's taking the right path? and like I feel like there's room for, you know, write whatever solves the problem, whether you use AI or whether you write it yourself, but then at the end you have to like prove that it's working and explain to a coworker like what it's doing. ⁓ and like that could be the interview. You know what I mean? Like, because that's kind of the job. It's like if you can't explain what it's doing, then like I'm not gonna let you merge it. I'm not gonna approve your PR if you can't give me a two-sentence description of how your code works. Bethany (09:47) Okay. Yeah, I think like my favorite interviews have been ⁓ at least when I was doing the last round was were like PR review pol ⁓ interviews where you had to literally just do a live code review because I think that really fundamentally tests so much of what it means to be a software engineer so that you can read and understand code, you can walk through it, you can leave ⁓ intentional and empathetic feedback, things like that. and it's also very hard to cheat. Brittany Ellich (09:56) Mm. Bethany (10:18) at something like at a PR review one because you're you're kind of doing it live ⁓ versus the ⁓ the ⁓ coding one specifically. but I agree. I've never quite hated leak code once, even though I do dislike leak code and I don't think that's like really what's valuable in a software engineer. However, it is really good for just getting people to talk and think like they're problem solving. ⁓ ⁓ factor. So if you just take off like, you have to actually solve this algorithm and it's more like, okay, you're like brainstorming trying to collaborate ⁓ on a problem you probably don't know the answer to, then I think that's a really interesting ⁓ use case. But I think as soon as you say you have to solve this problem in like two minutes, then I don't think that's worthwhile at all. Brittany Ellich (11:07) Mm-hmm. Yeah, agreed. Especially I think a lot of the problem with them is like their folks will just practice them over and over until they like memorize a lot of the patterns and then it's like it's not even really problem solving. I guess it is. It's you know, pattern matching, but that's a very different skill set than like, can you take a hard problem and solve it? ⁓ I think. But yeah. Bethany (11:26) also leads to biases too. Like if somebody has all the time to study those, I think that's a very different subset of people or a a a pool than people who might not have time to solve those. So I think that's another thing to factor in there. But totally agree, Brittany. Erika (11:43) I would also like if I were designing like technical interviews, like I would put in a section where it was like, you need to come up with like three different ways to solve this problem and then argue like the trade-offs of each. ⁓ yeah, because that's also like very real life, right? Like there's not only one way to do it. And like it tells a lot about a person if they're willing to look at multiple ways and like To me, if you're able to like, you know, sort of be less emotional about like one direction that you're taking, you're gonna be a whole lot easier to work with than somebody who thinks that one way is the right way to do it and it's the only way and if you don't do it this way, you're wrong. Brittany Ellich (12:29) Mm. Heart agree. I like that. Erika (12:31) As of yet, I haven't seen anyone do that. has did anyone do that in your interviews? Brittany Ellich (12:35) Yeah. I don't think so. I feel like that's like a really common follow-up question though, is like how else could you do this? Like if you solve a thing. ⁓ yeah, the only other thing I can think of that was kind of weird is like ⁓ because ⁓ some places are, you know, open, like you can use AI for everything when you're doing this interview. but it takes time and there's like some latency waiting for it. So like that's kind of awkward to just be like, All right, I'm waiting for my prompt response. Just give me a minute while while Claude's thinking for me, I guess. ⁓ yeah. Erika (12:42) Mm, that's true. Brittany Ellich (13:07) That's a little weird, but it's the times, I guess, that we're in. Erika (13:11) So were the like were the questions and the prompts any different or was it was the only difference like the fact that you're able to use AI? Brittany Ellich (13:20) Like it's just you can use AI. Some places are like not cool with you using AI as well. ⁓ which I think is also probably a really good signal right now. Like, can't you solve a problem when your internet isn't working? ⁓ yeah. ⁓ yeah, it was it was interesting. I don't wanna have to do it again for a long time, because job searching is always really stressful. But it was weird and interesting to see what it looks like now. Erika (13:34) yeah. Brittany Ellich (13:49) Today. So ⁓ Erika (13:52) Yeah, so you you got the job, you're there now. So how's how's it been? You've been there for two weeks? Brittany Ellich (13:59) Two weeks. Yeah. ⁓ I think one of the things that I was reflecting on is I think about a year ago I wrote this ⁓ article on the GitHub blog. We actually previously talked about it on the podcast, how GitHub engineers learn new code bases. in March thirteenth, twenty twenty five, so a year and three months ago. and like ten years in AI dog ears because things have changed so much since then. so I thought it'd be interesting to like look at back at like, all right, what are the things that make sense? Like hands-on code exploration, collaborative learning. I'll make sure we link this. collaborative learning. I feel like that's a big thing to talk about. Like how pair programming has changed. ⁓ building documentation also has changed. Learning by teaching, I feel like that's still pretty applicable. but I think those are the four main pillars. It's like how do you explore code now? ⁓ how do you learn with other people? ⁓ and how you're building documentation. All through three of those things have changed pretty dramatically, I think. ⁓ so I thought it'd be interesting to just like get takes on how those have changed and what that means now ⁓ in life. ⁓ yeah. ⁓ so the first one I think ⁓ is hands-on code exploration. That one, ⁓ I think we I'd already called out in there that you could use, you know, Copilot to to search through a code base. but it's even better now than it used to be. almost to the point where like, I don't know, I don't feel like I'm gonna I feel like I'm gonna go to that first versus just like spelunking through the different folder. I feel like the first thing I would always look for is like, all right, what's the folder setup? Like where are the controllers and the database and everything. But now I'm like, all right, tell me where all this stuff is and what the mental model is I should be using. I don't know if you have similar experiences or if you either of you have learned a new code base recently to comment on that. But Erika (15:59) I've been in the same code base, but I did go through a re-org, I guess it's been like six months, I think now. So it's not like that recent, but less than a year. So, you know, feels feels recent still. and ⁓ it was only like an additive re-org. Like we basically like took our existing area and then like added a whole like half a team's area on onto what we onto what we were already doing. So yeah and you know I like I've been finding that for me the like best way to understand what's happening is still through user flows and like user flow diagrams and that's even like through to the back end like Brittany Ellich (16:28) Classic. Erika (16:53) For me, it's like, okay, where do where does this start? Like, how do I know it's broken? And like, how do I know, you know, what the part like what the important parts are in between? So, like, if it's a bug, I'll try to replicate it. I'll try to ⁓ like write a test. Ideally, I'll try to like, you know. Do a debugger session or something like that to like know what's what the code paths are that we're hitting. and then I'll look at like production telemetry data. and yeah, for for me that's like the right place to start in like grounding in like a mental model of like a certain user flow. ⁓ because I find that I get If I get too in the weeds too fast, I'll just like totally lose the plot. Like I'm just like, that's interesting. Yeah, like this query and like that. And like, yeah, we can make that optimization. And it's like, I just totally like lose whatever I'm actually doing. So ⁓ focusing it on like, you know, this is what's broken, or like this is what I'm trying to do, and like tying it back to like the actual customer experience, ⁓ or like feature or bug or whatever. is is still like the right way to start for me. it's hard with like a whole area because there's so like it's like combinatorial, right? It's like, okay, like for example, so apps, like GitHub apps or OAuth apps. Like that's the new thing that my team has taken on. and like there's this whole idea of like tokens within apps. It's like I have never done like a deep code dive into like how tokens are minted, how they're stored, like how they're invalidated. and like I finally like wrote down all my questions. Like, these are all my questions about like all the different ways that like you know tokens go through these life cycles. And I'm like, it would take me like a week to, you know, actually go through each user flow. manually and like validate each thing. ⁓ which like I'll probably like split up and do over the next month or so. but yeah it it can definitely feel like a lot to kind of do it that way. Like yeah the the 3000 foot code view like I guess can kinda get you started, but I feel like that's also like a dangerous place to be where you're like, I know something and then you tr start to try to do something and you're like, Ooh, wait, no, I don't I don't know how this actually works Bethany (19:37) I can totally see you going through that flow, Erica, like with your you have you're so curious and like are you so good at like really diving into things. I can I can definitely see that. ⁓ but that's cool to hear. I also haven't changed code bases. I my code base I'm still working on the same one, but it has been going through a lot of refactoring. which is very exciting. ⁓ it was very due for one, but it does now mean that like all my mental models are outdated. And then we also traded some AORs from our team to other teams because we were very overwhelmed with ⁓ the new sc scope of everything. and AI apps as a whole. So it's been really interesting trying to help others learn that and then hand it off and then also learn ⁓ basically a evolving code base. But I think I've ⁓ I've always had success with like just in time or JIT ⁓ learning, ⁓ because otherwise I I do get quickly overwhelmed if it seems like an infinite amount of information to learn or store my brain. It's just impossible for me to do that. So if I need to know something, I usually will just l shoot off a question real quick to to co-pilot or if I'm trying to ans get an answer from a different team. I'll try to self-serve as much as possible with AI, like in their code base, ask a question about like the dependency and stuff like that. Sometimes it works, sometimes it doesn't, but ⁓ at least it's ⁓ doing some due diligence before ⁓ poking at other teams. But I I have found it very helpful for visualizing code better because I'm just such a visual learner and and that's always how I've enjoyed learning. So it's really cool that at a notice I can get diagrams even if folks didn't diagram it in the first place or if the diagrams are outdated so I really enjoy that. Brittany Ellich (21:32) Nice. I like that. Yeah, I still feel like something that has remained the same is like the easiest way to get into something is to like actually solve a problem versus just trying to read it and glean what you can from it. ⁓ although one thing that I've found that I've really liked now that I can leverage AI for like learning a new space is asking it like, all right, here's what I'm seeing. What are the logs I could look for? Or like what is the evidence that I could see for like what's occurring. to narrow things down ⁓ in the code, like what should I be looking for, you know, in whatever dashboards you have access to. ⁓ and it's amazing how much faster I can solve, you know, a bug or a problem like that with that. ⁓ yeah, it's been really nice. Erika (22:16) Yeah, for sure. And also like asking why it came up with an answer. if something seems off, be like, why did you say this? Like, yeah. See how it responds. Brittany Ellich (22:21) Hm. Yeah. Yeah. It's a weird week too. Fable was just released and I'm still trying to figure out whether like is this is this it? Like is this the thing that now it can do everything and it it's all correct or whatever? I don't think so just yet. But ⁓ yeah. Weird weird week wondering when when our jobs will change to where we are no longer needed. ⁓ whether or not that happens. ⁓ what about Collaborative learning. Pair pro how's pair programming going for you all at this point? Like is this a thing that you still do? ⁓ and what does it feel like now? Bethany (23:05) I would love to know how you all are pair program. I saw Erica nod, so I'm really hoping you have some tips because to be honest, I mean, we chatted with Dennis about this a while back on how you have to be so intentional about maintaining that social fabric. ⁓ and so it it's tough. You have to you don't really need to pair program as much, ⁓ since you always have a pair programmer with you now. ⁓ but it's still good for your for your team, for your well being to be able to collaborate with others. So ⁓ really looking for some tips on that. Erika (23:39) Yeah, I have recurring pairing sessions set up with everyone on my team. you know, they run the gamut from like I have this thing that I'm working on that I want to ask questions or brainstorm on, to like talking about the team, like, you know, maybe something that happened, maybe we had a release, like let's talk about how it went. ⁓ and then like there are times when we'll like dig into the code. ⁓ You know, honestly, like I don't feel like it's meaningfully changed that much when we do get into the code. Like, kind of like you're talking about the interviewing, like you have an extra tool now, but like, you know, somebody will run something on their prompt or whatever, or just like come up with an idea or whatever. and like you know, you you're you're still implementing the code, like, whether it's like through typing or through prompting or whatever. I guess I usually do find that pairing, like I write more code manually than like prompt the AI to use it. I think 'cause like I don't usually like one shot, you know, it's like when I prompt it's like, okay, then we like iterate on it or whatever. ⁓ But if, you know, it's like, we wrote this thing, now we're gonna write some tests, like I'll fire off like a prompt to add the tests or something. yeah, but like I said, I I always feel like there's there's something to talk about in a pairing session. ⁓ it might not always be like code itself, but yeah, there's always always something. Brittany Ellich (25:26) Yeah, that makes sense. Yeah, last week I was co working with some of my new coworkers. ⁓ and I was so excited because I'm like, Yes, we're gonna be in an office together. We're gonna get to like, you know, pair like in real time or whatever. And we did do a let a lot of like very explicit, like, all right, we're gonna meet and talk about plans or whatever. ⁓ but then like when it we had like spare time to actually do work work, it was just like, well, I'm gonna have my claws do this. Well, you'd have yours do that and then And then maybe talk about like, I don't know, something fun or whatever while we're waiting for responses to to come back. ⁓ which I think is, you know, I I I like the idea of having regular like intentional pairing sessions, like you said, Erica. I think I'm gonna set that up ⁓ because I think the value is still there, even if it's not like talking about like, all right, let's work through this code problem, but like, you know, what is our mental model of this thing and does it align? I think that that's probably really valuable still and something that I think I'm missing for sure. But yeah, different world now. ⁓ what about documentation? I think one of the reasons that I originally wrote this is I wrote a bunch of documentation on ⁓ the on some of the billing things when I first started on the billing team at GitHub. ⁓ and it ended up being really useful documentation for like the entire repo. ⁓ now I feel like documentation is almost a little bit more disposable. because it's easier to keep up to date in a lot of ways, which means that, you know, maybe it's not adding this these docs you created to the repo unless it's like, you know, actually something that you know is gonna live long term. so I'm curious, what are your thoughts on writing documentation and code for code in general now? ⁓ is this still still something that you're doing regularly? Have you figured out a good way to keep it up to date automatically? ⁓ and you know, have has your opinion on docs changed at all? Bethany (27:21) Ugh, this is such a good one. ⁓ because I think in theory it's easy to keep them up to date. But I don't know if in practice it's still easy to keep them up to date. my team's definitely been experimenting with like workflows to track changes and make updates to docs, which I'm really interested in seeing how that'll that'll go. but yeah, I think the the age old problem still exists that if you have documentation in disparate places, it it still is hard to know to update docs unless you have CI checks or like agent instructions or or things in place to the culture in place to ensure those documentation that documentation gets updated. I do still think documentation is very valid because I think I still read docs, but I think even if you're not reading docs, your agent has to read docs. ⁓ to understand how to do things, ⁓ a lot of the times. ⁓ like you can say it just w uses code, but I think it it really depends on the system. If you're if it's a simple project, sure I can just read the code, but if it's spans multiple projects, I think it gets a little tough after after that point. So I think our playbooks have gotten super important ⁓ to me personally to make sure that those are up to date, especially as more and more code is going through and you're not able to actually keep up with the mental model of all the code going through. I think to me playbooks are the things that are are top tier for keeping updated. So you're on call all can immediately be effective and ⁓ understand how to work on something. So I think that's my my kind of strategies. At least at least the playbooks are are golden. But Erica, I know you're passionate about this, so I'm very curious to hear your thoughts. Erika (29:10) yeah, I I feel like to me docs serve multiple purposes and one of them is generating alignment on something. ⁓ so whether that's like technical direction or like I don't know, team, team practices, like, ⁓ you know, part of part of what makes docs valuable is that like they can be commented on, they can be edited, like, you know, they can be approved or denied. Like, so I think, you know. Like we've said multiple times, like the human element is never going away, you know. ⁓ even if your doc is like this is how we use AI, or like this is how like you're a robot, like this is how you're supposed to work. Like that in itself, in my mind is a like a piece of documentation that can be, you know, approved or denied. So yeah, I I agree that like code documentation is really easy to get out of date. but like I do think a certain level of like inline commenting can be really helpful for like anybody reading or reviewing your code. ⁓ so, and that's like again like a form of documentation. You know, I think the pure like readme.md. I still appreciate it because you know it's like then I don't have to do that work myself. Like like you said, like it still does take time to like fire off a prompt. So if it's there and it's up to date and it gives me the five commands I need to get started, great. You know, like ⁓ and some things are like not obvious from the code, like get back to tokens, it's like what permissions of my does my token need to access these resources? Like I can probably figure it out, but like if you tell me then great. Like I don't have to do that guesswork. And it could take a while to kind of like suss out that information. So those are the things that kind of come to mind for me. yeah. What about you? I mean, yeah, you were like the documentation master. Like this was your this was your thing. Brittany Ellich (31:39) I'm still very passionate about di taxis. I'm gonna I'm gonna add that that link. ⁓ yeah, I'm still a big fan of di documentation personally because I feel like that's how I you know, work through things as I write it down. and that is why I also write a lot of things on the internet. So I think it's still valid, but I don't think that I'm gonna like I don't think that en as many things need to be documented as there was before. Like I think that, you know, like write down the specs for how a thing is supposed to work. But how the thing actually works is probably better to infer from the way that the code is written than, you know, whatever your intentions were when you created it, because those can differ quite a bit. ⁓ and it's hard to keep those up to date, especially as code is moving so much faster than it was in the past. ⁓ I think that it's really, really hard to keep those things updated. Yeah, I don't think I'm committing as much documentation as I used to be because I'm nervous, more nervous, I guess, about things being out of date. and but I think that that's still like a good framework for figuring out what should be documented is the the diataxis framework, which is like what is your reference code? What are the features that are supposed to be in this? ⁓ you know, where are things like you know, any sort of proof of concept or ADR, I think. is still super valuable, especially because then that just becomes, you know, an artifact of a thing that you end up using quite a bit ⁓ when you're building and you can like measure against it to be like, did we, did we do this the way that we said we were gonna do it? ⁓ so yeah. I feel like I use more ⁓ more AI tools to write documentation now and to like make sure that the documentation that I write actually makes sense. Without. I don't know. But maybe that's still the same amount that I did a year ago. Because I don't know that they've gotten like dramatically better at writing documentation. Bethany (33:36) Yeah, I was just gonna ask you both what your thoughts on AI writing documentation was. Cause I know some people draw a line at AI writing for them or writing in their voice or or something, but others are like, yeah, you'll stay better up to date or probably can be more clear that way. So very curious, that perspective. But A Britney, it sounds like you do use AI to write, at least like with documentation and and things or to check your your writing. Brittany Ellich (34:04) Yeah, I would say it's mostly like as an editor to be like, all right, does the thing that I wrote make sense how I wrote it? I feel like I've I've been wanting to I've had this idea for a a comic rolling around in my head for a while now where did you ever see that meme where it was like ⁓ where do you draw the line and it was like a pita thing where there was different animals on the image and it was like spanning from like dogs to like You know, like horses or whatever. Like, where do you draw the line on the animals you eat versus the ones that you like, you know, don't. ⁓ and somebody went in like with a pen and like drew on there, like, all right, this is, you know, every day, yes. Or this is, you know, economic collapse. This is where I would draw the line or whatever, you know. I feel like there's a very similar meme to be made about like where you feel about how you feel about AI generation. ⁓ like I'm Not a big fan of AI generated images. Like I wouldn't do it myself. I don't necessarily like judge other people for it, but I know that there are some people that are like no AI generated art whatsoever. Same with like, you know, AI generated text. Like I'm not gonna use AI to generate text, but I'll use it to edit. and I think that like there's some people also who like are very ⁓ at a different spot in that spectrum. ⁓ AI generated code, like yeah, that's standard now. I think that's just normal how you know I will pretty much accept like yes this does what I want it to. Great. Let's use it. ⁓ so yeah I think that's sort of where I'm at on the spectrum. Use it more as an editor. I think I've tried AI generation of actual text in the past and it just never really ⁓ usually when I'm like taking the time to write a thing I already have something in mind on what I want to say. And so there's not really a a ton of value in saying like hey help me write this thing. ⁓ but help me look at this from the perspective of somebody who's in like communications or something. Like how does this come off ⁓ externally? ⁓ I think that's really helpful. What about you both? Erika (36:08) Yeah, I go back and forth, because it's so it's so easy to like go from blank page to something with like AI generated text and like I feel like it kind of depends on the audience and like what it is. Like if it's I don't know, if it's sort of like a summary or like a PR description or something like that, like I'm more fine with AI generation because like it doesn't it's not like it's not like a piece of content that's like meant to be read kind of as ⁓ what am I trying to say? Like I guess I and I don't really know. I don't really know where the line is ⁓ for me personally but like I think if it's like a broader discussion post or something like that, like I'm less likely to generate it. Yeah. So I don't I don't know where that where that line is. ⁓ I can't like really define it, but maybe it's sort of like an internal versus external audience or something like that. Like internal to my team or yeah. Like personal notes too. I'm like, sure, just like generate a note and it's fine. Brittany Ellich (37:30) Yeah, I feel like this is a thing too where every time I think about it, I'm like, whichever way this ends up going, like whatever I say now is probably gonna get me canceled on the internet in the future or something. Like I'm gonna say the wrong thing and people are gonna be like look back and be like, she used AI for that, or you didn't use AI for that. And I feel like either way, like something's gonna somewhere in this story is gonna go wrong. So I'm like, I'm afraid to take a stance anywhere. Bethany (37:30) Yeah. Erika (37:56) Well well everyone apparently already thinks that we're AI generated, so maybe this is the point where we say that we are definitely not AI generated. Brittany Ellich (38:01) That's true. Yeah. AI generated podcasters right here. That's true. Bethany (38:11) No, we are not we are not on that AI podcast network. ⁓ Brittany Ellich (38:15) Mm-hmm. We can Erika (38:16) I swear. Brittany Ellich (38:16) do the do the do the do the face thing or whatever where you're like, look, AI can't do this. Erika (38:22) Look at all plug of my fingers. I promise I'm not AI. ⁓ Bethany (38:26) And before AI does be able to do that. no, I think like I mean, talking about thing being cancelled on the internet I mean I think like any stance is gonna get cancelled on the internet by someone, so it's just kinda kinda say say what what you feel in the moment. Maybe it'll change, maybe it won't, but ⁓ I I think these are really interesting perspectives and I love the like thought that like well it it it depends on the audience for sure. Like I've definitely generated like notes for myself and and things like that. Like I'll type something that I'm like for sure would not make sense to future me, but like AI can turn it into something that might make sense to future me. ⁓ but yeah, I I mean I used to well I tried to not let ⁓ like co pilot post as me. ⁓ I mostly do now just because I can't figure out how to get it to stop posting as me. Like I've told it to not do that, but it still does. So I'm like, okay, you know what? At least it'll be clear about what things are and people will know it's not me because that's not how I talk. But ⁓ I d I do think that it can be very verbose and I like I don't like reading through AI text a lot because it's just like really hard to parse a lot of times. Like I've even tried to make skills to say, okay, you are responding to somebody who does not know this code base, like it's just they're integrating into this. Do say the simplest thing possible without leading into what the implementation details are. ⁓ and that's it. And it just struggled so much with that. I'm like Two sentences max. You can't you don't get any more than that and it struggled. ⁓ so I think like with the tools now they're just not very good at writing and I don't think they're very effective at like communicating, except i in ways that probably would help it with like its thought process or something like that. So I yeah, if it's anyone outside of me reading it, I typically won't won't generate it at least I'll I'll maybe have it at it like you do, Brittany. But yeah. I think a at this point it's just not not there yet for writing. Brittany Ellich (40:42) Yeah, makes sense. Nice. Well, this has been a fun ⁓ trip down blog post memory lane. ⁓ but I think we're just about at time. So, I think that we need to move on to our fun section. And speaking of AI generated, there are two options that were both AI generated. Yeah, agreed. Okay, yes. Two Truths and a Lie, new job edition. Each host tells three short stories from a first week or first day at any job they've had. The other to guess which one is invented. No sourcing needed, pure stories. Great. Do do you need any time to think up? Erika (41:04) I think confessions won. Bethany (41:24) Yes, it's been over four years since I last started a job. I don't think they were that dramatic either. Brittany Ellich (41:24) Good stories for this. Mm. Yeah, I only have like one very f fun like first week at a new job story. ⁓ and it's from a long time ago. So, ⁓ yeah. Erika (41:42) I mean they don't have to be, you know, anything crazy. In fact, like, yeah, the more benign, the more less the less likely we are to think that the lie is a lie. Brittany Ellich (41:47) Mm-hmm. That's true. Okay, I'm gonna take a second to write something down so that I can read from it. Erika (41:59) Okay. ⁓ I guess I can go first. okay. ⁓ first thing is I started ⁓ my like new joiner class with somebody who I'm now on the same team with. Bethany (42:00) Needle. Erika (42:27) second one is ⁓ I merged a change into GitHub monolith my first week on the job. And third one is that I did all of my onboarding on time, like on schedule. Brittany Ellich (42:55) That has to be the lie. Erika (42:55) Yeah. Bethany (42:58) Yeah, I don't think I even finished mine. Brittany Ellich (43:02) Still have some onboarding task or whatever sitting there in a GitHub issue that has never been closed. ⁓ yeah. Bethany (43:05) Yeah. Yeah. Erika (43:08) That was not the lie. The lie was that I contributed to the GitHub code base in the first week. I did not. I think it was like the second week. Yeah. Brittany Ellich (43:14) ⁓ Okay. That makes sense. And ⁓ We should have known that. Actually I shouldn't have, because I started like a month after you. But Bethany was there, so Bethany (43:18) Splittin' hairs there. Erika (43:27) Yeah. Bethany (43:27) I did not keep track of your contributions, believe it or not. Erika (43:30) No, I can Brittany Ellich (43:33) Your first week contributions. I know that there are ⁓ DX right now is doing a thing where they like measure your time to your first 10 PRs, I think, as like a measurement to see like how much more quickly people can get onboarded. That's like your onboarding time is your time to your first 10 PRs. ⁓ but yeah, I don't know about the first one. Okay. ⁓ I've had a lot of jobs ⁓ throughout my life. ⁓ so thinking about some some good ones. ⁓ The first one, I started a new job and met some very cool people that were part of what we called the new crew and they became really good friends of mine. Bethany (44:18) If that's a lie, I'm gonna riot. They're terrible people. Brittany Ellich (44:22) They were not cool. Okay, second, ⁓ I once left a job in the first week after having to clean up puke ⁓ multiple times. ⁓ and third, I I once had to go to a training where I learned how to measure sound decibel level. ⁓ within a ⁓ hotel at very last ⁓ god I can't even do a lie. yeah I like I started in a place and then it just like shit I need more details. Bethany (45:05) What's up? Erika (45:06) Wow. Bethany (45:13) I was like these are so hyper specific. Brittany Ellich (45:16) The ver very, very specific. ⁓ Erika (45:18) Well that was easy. Brittany Ellich (45:20) Yeah. I did leave a place though. I I got a job at a pizza place when I was in high school and I was like the smallest person that worked there and somebody threw up on the twisty slide and I'm like, all Brittany, you gotta go clean it up. I was like, god, this is terrible. ⁓ so I did, and then I had to do it. They like threw up a second time on the same slide and I was like, All right, I'm out. This is it, I'm done. No more. Yeah. Yeah. It was yeah. Erika (45:33) Awolo Wow yeah. Bethany (45:45) Honestly, I respect that. I think that's valid. Brittany Ellich (45:50) Most assertive I ever was in a job. Bethany, what's yours? Bethany (45:55) All right. so for my very first full time job, I was the only one who wore a dress on the first day of the job. for the my second one, I wrote my first lines of Ruby my first week at GitHub. ⁓ and my third one is I never got my welcome package from GitHub. Erika (46:15) Feel like your welcome package is a lie. Brittany Ellich (46:17) Yeah, same. Bethany (46:19) It is. I got two welcome packages. I feel like it's long enough that I feel okay telling people that I was like, I can't tell anyone this. Erika (46:21) Yeah. Brittany Ellich (46:23) Even better nice. Erika (46:27) Yeah. Brittany Ellich (46:30) They're not gonna make you t make you send back your Erika (46:31) I'm like, I know you well enough to know that you would have followed up on that. Like, excuse me, where is where is my sweatshirt? Bethany (46:35) Yeah yeah. Yeah, yeah. I would've. I love some free swag, honestly. What? Brittany Ellich (46:39) Yeah. Erika (46:41) Mm. ⁓ Brittany Ellich (46:43) Did you get two sweatshirts? Did you get two two handle sweatshirts? Bethany (46:49) I did, yeah. Yeah. Yeah. Brittany Ellich (46:51) What a flex. Erika (46:54) You can clone yourself. Bethany (46:56) Yes, it's true. Someone composes Brittany Ellich (46:56) Yeah. Bethany (46:58) me. Brittany Ellich (47:00) ⁓ Excellent. well, this was really fun. It was great to chat with you both. thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week. Goodbye. --- ## Episode 63: Why AI Coding Agents Keep Guessing | Context Gap & Code Intelligence with Dennis Pilarinos - URL: https://overcommitted.dev/why-ai-coding-agents-keep-guessing-context-gap-code-intelligence-with-dennis-pilarinos - Published: 2026-06-09 - Audio: https://anchor.fm/s/102586d64/podcast/play/121208663/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-9%2F425780675-44100-2-a5bf441caf1a.mp3 ### Show notes Summary Dennis Pilarinos has spent nearly two decades building developer tools at Microsoft Azure, AWS, and Buddybuild (acquired by Apple). Now CEO of Unblocked, he's tackling the critical problem holding back agentic AI development: context intelligence. Why do AI coding agents keep guessing? Because they lack the organizational and business context behind the code. In this episode, the Overcommitted hosts dig into how developers and AI agents can truly understand the "why" behind codebases, not just the "what"—and why this matters for code quality, productivity, and shipping reliable tools. Links * Dennis' email: dennis@getunblocked.com [dennis@getunblocked.com] * Unblocked: https://dub.sh/IeI82Vx [https://dub.sh/IeI82Vx ] * Dennis on X: https://x.com/dennispilarinos [https://x.com/dennispilarinos] * Dennis on LinkedIn: https://www.linkedin.com/in/dennispi/ [https://www.linkedin.com/in/dennispi/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host Bethany, and I'm joined by... Brittany Ellich (00:07) Hey, I'm Brittany. Erika (00:07) I'm Erika Bethany (00:09) We 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've learned. 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, I'm so excited. We are joined by Dennis Pilarinos. Founder and CEO of Unblocked, a contextual code intelligence platform that helps developers understand the why behind their code. Dennis has spent nearly two decades building developer tools at some of the biggest names in tech. He helped build Azure at Microsoft, worked on AWS, and then founded BundyBuild, a mobile CI-CD platform that Apple acquired in 2018 and turned into Xcode Cloud. Now he's tackling what he calls the real bottleneck in software development, not writing code, but understanding it. Welcome Dennis! Dennis Pilarinos (01:02) Thanks so much for having me. I'm excited to have this conversation. Bethany (01:04) So excited! To kick us off, what's something you're currently building or learning that has you excited right now? Dennis Pilarinos (01:10) I mean, I think it's... handful of different things, they're all pretty much some form of automation of some internal tooling. I found in the past we would look for, we'd have to assign engineering resources to accommodate or accomplish, I would say like non-product tasks. And what I'm excited about now is the fact that I can basically just do that very, very quickly myself off the side of my desk. so endless number of examples. It's amazing to see other engineering leaders kind of get back to their kind of core roots. and build these little, mostly internal tools that help the company. Bethany (01:43) That makes a lot of sense. I mean, you've said previously that writing code was never the main challenge, but it's finding that context. So what really does that context gap look like day to day? Is it different for these leaders compared to engineers, or is it quite similar? Dennis Pilarinos (02:01) I think, so when I think about, historically how software has been built, like you mentioned, I've been building developer tools for the better part of 20 years as an engineer, as an engineering manager, as a business leader or what have you. ⁓ one of the things that I found personally frustrating was the inability to get the information I need to get my job done. Right. And as an engineer, your job is ultimately to like write code, right? You're either fixing bugs, implementing features, whatever it might be. And the way that you would get that information historically was typically interrupting your coworkers. for spending a bunch of time digging through information. But you spend a ton of time doing that, especially if you're working in a legacy code base with a lot of other people. And the actual coding part of it is relatively insignificant. think DX released a survey that said, the 2026 developer survey just a couple of weeks ago, where they said 14 % of an engineer's time is actually spent writing actual code, which I thought was an interesting stat. And so that context gap is quite painful. It's actually funny, when we started Unblocked, we were gonna call the company Bother, which is like, you don't bother me, I don't bother you, right? It's just like, we can use Bother, get the answers for the things that we need, and move on with our days very, very quickly. So, you know, it's an interesting time. I think there's an interesting transition where, while it's been historically true that engineers are the folks writing code, increasingly, it's their agents, right? And so, we're seeing that same problem arise with agents. If you use any of these tools, a lot of them struggle with the context. And what do they do? Well, the same thing a person does. They kind of guess and play kind of whack-a-mole trying to figure out what things need to go get done, or what context they need in order to do their things. And so we're finding that context gap is even more acute, I would say, today, as increasingly agents are writing even more code than the... developers that they kind of work for. Bethany (03:51) Absolutely, Erica, ⁓ Erika (03:51) how do you handle the situations where you don't have enough information? The answer is still to ask somebody. Because I find that the overconfidence in sort of AI assisted workflows can be really misleading of it says a really competent answer, it's found all the solutions, and then I start asking it, well, how do you know that? And it's like, well, actually, I guessed. Dennis Pilarinos (04:16) Yeah, it reminds me, I think like in my career, I think I've gone through these stages in my career as well. What at some point I was like overly confident and probably didn't have the skill to measure it with the confidence. Right. And so that's, know, you're not quite necessarily right out of school, but probably shortly thereafter, you're like, I've been there. I've done that. I can like absolutely nail this thing. And you go down your merry way and then you're like, ⁓ I didn't, I haven't experienced this problem or this scale issue or this like security vulnerability or any number of things. And so that's, feel like a lot of people have this impression of these agents where they're like actually very, very, I would argue expert level at writing code, but like strangers to the system. They don't have the tribal knowledge. And so they're like, I know based on like what I've been trained, this is the right way to do things. And you're like, actually not here, it's not. So yeah, and you end up. Yeah, this kind of almost like uncanny valley where it's like, we should do it this way and here it is. And then you realize, nope, not even close. Bethany (05:15) Yeah, I definitely feel that. And you're kind of restarting over whenever you start a new agent session. Basically, it's not even that it builds this context as it goes. Most typically, it just kind of you have to restart that process every time you you pick up one of these tools. ⁓ Okay. Yeah. Yeah. Dennis Pilarinos (05:33) Yeah, it's. I was like, it's one of those funny things we're just like, as people, we are a context engine, right? Like we sit in Scrum meetings, we learn and like evolve our thinking and our awareness, right? That's why folks who've been around codebases for a long time are really, really valuable. imagine, I wrote this blog post, a difference between like 50 first dates in Memento. Imagine that like, you know, the way the technology works right now, certainly is that you, every time an agent gets spun up, it needs to basically recreate that context, right? It is, and you're babysitting it, you're constantly spoon feeding it like this information. In, you know, 51st dates, that was Drew Barrymore, right? Waking up every morning and like there's a system around her for her to like boot up her effectively memory, right? But in reality, most of these systems are environments that look more like Memento, if you remember that movie where it's like the guy had like tattooed stuff and like he has notes and like stuff all over the place. That's actually the real world, right? And so these agents have no working set basically. They're like, let's see what's around there. And they face a Memento world, which is horrifying. Great movie, but. Erika (06:42) Yeah, you're right though. mean, and that also can happen to me when I like, even if I don't look at a PR or something, or like an area of the code for a couple of weeks, then I come back, I have to like similarly like, oh wait, what does this mean? And like, how does this connect to that? So yeah, it's a people and an agent problem. And yeah. Dennis Pilarinos (07:06) Yeah, I feel like it's like... We have limited context windows, right? Like I typically don't remember what I did even a week ago these days. I have a newborn, so my context window is progressively getting smaller because I don't sleep much. But there's all these external factors that play into it. But yeah, it's exactly right. I often don't remember the decisions that we made that influenced why we built the system a certain way or any number of these types of things that is actually codified, right? It's in the system and records. It's in our pull requests. It's in Slack. It's in our documentation. It's in the source code. But we don't, for whatever reason, we don't want to give agents a holistic view of that typically right now. So that's kind of the pain point. And they're really good at it once they have it. Erika (07:48) You also don't want it to be like deterministic. Like you don't want it to be like, because we did it this way, now we always have to do it this way. Like there is some nuance there of like, this is a decision that we made, but we're going to recognize that that Bethany (07:48) here. Dennis Pilarinos (08:00) Yeah, absolutely, absolutely. Bethany (08:02) think too, Brittany and I went to the Pragmatic Summit, which there was a really good conversation there about AI ⁓ adoption and how companies with good systems tend to adopt AI better than companies with maybe like systems that need work still. So I think if you're solving that human issue with context, it often helps the AI also solve the context issue for those sessions. How exactly does Unblocked combat this or does it also help the human side of things as well as just the AI agent things side of things? Dennis Pilarinos (08:36) Yeah, no, it does both actually. help engineers save time and... agents kind of stay on track is the way that we think about it, right? Because they just like, they go all over the place. But yeah, we started by helping engineers, right? Like I don't want to have to be interrupted or interrupt my coworkers. So we have a handful of surfaces that give people a very natural Q &A experience. They can ask questions in a web experience. They, I mean, I think one the hardest parts about building developer tools is breaking into the habit loop of an engineer, right? Like having someone... have to remember to do something in order to get some value, it takes a while. It's actually a really, really hard problem to solve. And so we created an experience where in Slack, and this is super popular in like help channels, right? If you, have customers who have five, seven, 10,000 people in a help channel. And what do people do? Actually, I can think of one. It's like help dash GitHub, ironically. These, this organization has a help dash GitHub and people come in and they just ask their question, right? Like it's the first time it's ever been asked. it hasn't been, but Unblocked, you know, that's their workflow. They go in, they type their question, they're waiting for someone on the support team to answer it. Unblocked helps alleviate that support load because it sees that it can answer that question. And people love it, especially if they're geographically distributed, time zone shifted, any of those types of things where they're getting a high quality answer very, very quickly. And so breaking into a person's like workflow where they're getting AI providing value to them, especially at a time where they're trying to like move on with their work, right? they're stuck on something. We had a customer say that they've reduced their support load by like 50 % because Unblocked is helping them, right? That's just people. And so we started with that, right? Making it part of the workflow where you are, you if you can ask questions in Slack, Teams, in this web dashboard, a standalone Mac app, any number of ways for people to ask questions. And I would say, I don't know, maybe the last six to eight months, it's been very clear that agents suffer from that same problem. And so we we plug into that agent workflow as well. It's kind of crazy, right? Because quickly you can help solve that problem where people and agents get this information. The next thing, and I think a lot of teams are experiencing this, is that you're now running into this bottleneck where you're stuck on pull requests, right? All of this code is getting generated. Now you have a ton of pull requests that have been, and we see this in the open source community a whole bunch of places, right? Yeah, we had kind of felt that ourselves and we built a code review product that's based on the context, right? Like, I want code reviews as if they came from like the best engineer on the team. And so we built it internally just for ourselves because we weren't happy with kind of what existed in the market. we gave it to a handful of folks that were customers to be like, what do you think of this? And people absolutely lost their mind. And so we're kind of helping people not only write more code, but actually make sure that it's the right code for their organization. And we offer this code review, like context-powered code review product that helps as well. So it's a crazy time, yeah, for sure. Brittany Ellich (11:30) I think that's super interesting. And I feel like it's solving one of the biggest problems with AI, is like making sure that it has the right context. But I'm curious your thoughts on like how people maintain relationships with their coworkers now when we're moving towards this world where we can use AI to get all the answers. Previously, I used to reach out to my coworkers and that was like our interaction now. And now I'm finding myself like, have to like deliberately try to build those relationships and be like, Hey, how are you? Like, instead of just relying on. ⁓ you know the the touch points i'm like hey can you can you review this pr for me ⁓ do you have any thoughts on that or how that's changing Dennis Pilarinos (12:02) Yeah. I mean, I think with every technological shift, I think there's some unfortunate casualties that we have to be mindful of and figure out how do we maintain. People are inherently social creatures. I'm actually somewhat of an introvert. And so I have a certain amount of social tendencies, and after a while, I'm tired of it. But I think a lot of the technology that we see today It's very easy for people to just become siloed, especially if you're not working in an office with people, right? If you're working from home, you have to make conscious efforts to like continue to build that social fabric. And because at the end of the day, that is in my opinion, how like the best teams operate. So I don't know that I have like a concrete solution for that, but it's definitely something we're seeing, right? We see people who say that they are kind of AI fatigued. It's not, it's not like working with a person in many ways. So yeah, don't, I'm curious to see how that plays out over the next, I've actually have a moratorium on stating any kind of timelines now because it's so incredibly difficult to predict over the next little while. I'm gonna say three months, six months, a year, who knows. Erika (13:06) I think of it a little like, there's a whole discussion of what's valuable to talk about in person versus remote. And you're talking about shifts in technology, video call technology, change the way we work, And a lot of what I've heard of, what's valuable to have in person is, these brainstorming sessions, really like building those personal connections, sort of like the higher level thinking questions, like the procedural stuff, like everyone get on a PowerPoint and look at these slides. You know, nobody's got time for that. But in a video call, you can probably kind of put it on the background. It's probably fine to have that in some kind of like a remote meeting or something like that. And I think of it a little bit similarly with sort of conversations with my coworkers in AI assisted working environments where like I might kind of do the investigation with the agent. I might, you know, like do some spelunking, look at some of the code, like build sort of that mental model. And then when I do have that conversation, like, hey, what do you think about this? Like it's still valuable to have that human input of like. checking that, know, sanity checking, like does this align with your design values? Does this align with our like system values? Like is there anything that I'm missing here? That like that kind of stuff ⁓ I think is still valuable conversations to have with another human. Dennis Pilarinos (14:30) I think, yeah, I really like this idea of honing in on the creative type workflows, anything that requires some level of creativity. I think it would also add, I think there's a lot of value in friction, right? And so actually evolving your idea by talking to someone who might actually have a different perspective. I think a lot of the tools today, to your point, it's like, absolutely, you're right. This constant positive affirmation and sometimes maybe not the friction or pushback that you need to really evolve the idea. you know, for now, I think people are a great way to combine those two. Bethany (15:01) I completely agree. I've found as a fellow intrepid that I have felt more more siloed lately just because we're removing a lot of those touch points now with agentic development. And so recently I've found it's helpful to even push beyond, to like force yourself to actually pair with people even though it's not as much of a need anymore because you've got your permanent pair programming buddy, but you learn so many cool things about the code base or things that you might not be touching or even tricks on how to use agents when you're programming. So it's been really helpful to push past that and try to force myself to talk to people for sure. Dennis Pilarinos (15:42) Yeah, it's, find the, the, I think of like, there's kind of almost like an AI adoption maturity model where people go from like very, very exploratory kind of like, I'm using AI to help me do kind of tab complete to like people in the middle who are like, we've got MCPs and skills and like, you know, I'm running agents locally on my machine, maybe a handful of them all the way at the very end of the spectrum, which is like, have fully autonomous orchestrated agents that are checking in code into production. don't even look at the code, right? That kind of that whole spectrum. and I don't know maybe with the exception of one or two companies that like everyone is on like on the same end of that spectrum. And so to your point around even sharing how people are using these things and like helping navigate, well, this is why we do it this way or we've adopted this part of that spectrum has been really eye opening even for us, right? We did this exercise a month and a half ago, two months ago. We're our most prolific engineer in terms of lines of code, which is, whatever. He didn't use any AI coding tools. none. All the code that he's written is all handwritten. He used AI as a means to rob or duck basically, to talk to someone and get feedback and input. And then we had other folks who were like, we have this internal full orchestration system that will kick off these long running jobs, will implement features for us. And so we're like, you should try this. He's like, oh, this is amazing. We're like, yeah, yeah. Even sharing that is like this kind of very eye-opening experience, I think, for people within organizations. Bethany (17:12) Absolutely. kind of diving into that future of being a software engineer. I know you recently had a post on Twitter about devs who rely primarily on vibe coding eventually hit a wall if they don't understand the fundamentals. And I'm curious, what is the line between leveraging AI to move fast or even just autonomously committing code and checking code versus ⁓ understanding and needing to understand what's under the hood. Dennis Pilarinos (17:43) Yeah, I think there's a lot of, there's a lot of. noise in the ecosystem around like you can vibe code anything, right? Like I could, you know, one of the folks that we work with used to work at GitHub and it's like, yeah, I mean, GitHub is just like a layer over top of Git. You can go and try and build that and see what that looks like, right? There's, it's far more complicated than that. And so I think even in the macro economic climate, there's a lot of SaaS businesses who are taking massive hits in terms of their stock price because people think they can be replaced or supplanted by people who are just building their own internal apps. I think these are like extreme views of the world, right? I think, you know, building... Certainly in existing code bases like legacy teams and trying to build something without knowing how that system works You can probably do a handful of things up to a certain point, but then when it goes wrong How do you get yourself out of that corner? And so I think it's very exciting for a lot of people to be like look what I'm able to do from scratch Most you know, I've been building software for 20 some odd years. It's very rare that you have to go file new project. Let's start something from scratch. It's always within an existing system. And so if you use these tools without understanding how that system works, when something goes wrong, how do you figure out how to resolve that, right? When the AI is like, I don't know, and it just goes into this AI doom loop where it just keeps going back and forth between solutions that don't resolve the issue. Then what happens? It's probably good for you to understand the system. That's kind of my perspective. Do you folks feel differently? Erika (19:13) Yeah, I also think of like the familiar kind of adage or I don't know if this is how widespread this is, but I feel like I learned pretty early on that like the last 10 to 20 % of a project is always the hardest part. And yeah, that first, initial, like the initial commits getting like the bulk of the work. usually goes pretty fast and then you try to finish it up and there's always like all these last little things that are kind of tricky and you have to figure out how to fit them back in and have to figure out how to deploy it like and yeah I mean it kind of reminds me of the same sort of percentage logic I've heard with like LLM assisted coding where they'll get you 80 % of the way and then the rest of the 20 % you have to do yourself. yeah, whenever I hear people say like, SaaS is dead, I'm like, I don't think you've ever built software. Like I don't think you've ever like actually deployed anything to production because that's just not how. Like, sure, maybe like running something locally, but like something that's at scale that other people are going to use. Like, what do you... I don't think you know what you're talking about. Dennis Pilarinos (20:19) Yeah, yeah, I mean even simple little apps that I build like for myself, know, I'm hacking away on something over the holidays like in Christmas, right, to like automate some home automation stuff that I've been doing. It gets deployed to like some AWS infrastructure, calls a handful of APIs, so on and so forth. It broke. And I was like, I don't know exactly how that all works. I was like, I've long paged that out and like, who knows what API it is. And like, and now I'm sitting there having to go and maintain it and like update it. And I was like, that's one project. if I had 50 or a hundred of these things, right? You know, if my wife walks in and presses a button and the lights don't turn on, that's not a good place to be. Like it has to work. Right. And like, I can't, I need to make sure that it's, it is reliable. Right. So, um, these production kind of scenarios. are reality checks, I think, for a lot of folks. Bethany (21:08) absolutely. think one of the best parts of these systems is that you basically have a super knowledgeable, like we were talking about before, a super knowledgeable coworker. And so it's been really interesting to be able to poke its brain, like really dive in and understand how things work. It would be easy to fall into the trap of just pushing it up. And sometimes, sometimes for small things, I am like, ⁓ it's probably fine. But then I'll read the code and I'll be like, no, actually, wait, wait, wait, nope, it's not fine. So it is just so important to still have an understanding ⁓ beyond it. And I think it's just the same as people who said, you can just copy and paste from Stack Overflow and it'll just work. The thing is, you have to know what to copy and paste from Stack Overflow for it to work. I think at least now it's hard to imagine a future where that won't be the case anymore. But who knows? I mean, I'm curious what your thoughts are if the role of a developer is going to change meaningfully in the next three to five years with these tools or if it likely, like we're saying, still rely on having the knowledge, the fundamentals to diagnose these issues. Dennis Pilarinos (22:18) For sure, I think. Like again with every technological shift, think people in whatever trades that they are need to like up level their skills, right? So I use this example. I think about this all the time, which is you drive by construction sites and you see people who are framing houses or putting up buildings, right? It's very, very unusual to see them using a hammer to do framing, right? They're using nail guns because they can get their job done faster. But like you really want to understand how you line up the two by fours and make sure that everything is plumb because at the end of it if you get something done very very quickly but like it's slanted that's not an acceptable outcome right and so like while these tools help you up level the skill I think you still need to have that underlying skill you know I remember probably a year ago people felt like that there was going to be like this, that people who were coming out of university or colleges didn't have jobs, right? They're like, if you don't, you know, and so there was like this fear, I think, in the economy. And I had a friend who had, who whose kids were having difficulty getting internships or entry level positions. And I think that's, you know, there was some concern around, well, AI is just going to take these jobs away. but we've actually seen play out, and I've seen this at a number of companies. There's a company that I know that plans to hire 1,000 interns this year, right? Because those folks are getting exposure to those tools and learning how to like update their, like use their, develop their skills materially with the assistance of those tools. In that organization, they also have these very senior folks who recognize that these tools can be helpful and are quickly up-leveling their skills as well. The observation from the CTO was it was the folks that in the middle that actually were kind of reluctant or weren't picking up these skills. He's like, those folks are the ones who are kind of stuck, right? So they have to like figure out what they're going to do. Otherwise they won't be able to keep up with the direction in which the industry is moving. I thought it was an interesting like shift between like you're new, no jobs because AI replaces you to actually, know how to use this tool really well. We're going to teach you the fundamentals while you show us how to use this tool. I thought it was super, super cool outcome. Brittany Ellich (24:32) Yeah, I think that also we go through these periods of time every few years too where we're like, there's no entry level jobs. Like I remember that when I graduated from college too, and it was, you know, it's like feast or famine. I think it's just a cyclical nature of everybody saying like, we're going to offshore everything to, no, wait, it's better to have things here. And then, AI is going to do everything. And like, wait, no, we still need humans to do, to do this work. So, but I do talk to a lot of, you know, folks in college right now studying computer science that are like, do I need to go do something else? Like, do I need to pick something else? I'm no, I don't, I think it's going to be fine. You're going to be well needed. Yeah, exactly. Yeah. Dennis Pilarinos (25:07) Yeah, like you should probably learn how to use a nail gun. You know what mean? Like, as you probably feel, it's like, don't come out of there with like a rock or a hammer, right? Like, learn how to use a nail gun. But like, those fundamentals still need to exist. Bethany (25:20) Okay, before we wrap up, I actually wanted to pivot to ask a bit about your career. You've had such a cool path in DevTools with building Azure, working on AWS, and starting BuddyBuild. Did you have any particular moment where you knew you wanted to leave Big Tech and go build something yourself? Was there anything that inspired you or gave you that itch to go off and do that? Dennis Pilarinos (25:45) That's a great question. think I've been very fortunate in my career, even working in like big companies where I've had the flexibility and opportunity to like start early stage projects. like kind of like quote unquote a startup within a large company. And so that's a lot how the Azure project actually started, which is like, you know, I had a direct internet connection in my office and I was like, oh, it'd be really cool if we had these APIs that developers could like copy. And I remember like campaigning the Microsoft IT folks to be like, can I just get a static IP address and I'm going to register this domain name. and they're like, what the hell are you doing? And I was like, it'll be fine, it'll be fine. And so that rolled into this crazy kind of cloud platform. But same thing with AWS. I started the Vancouver office here, was the first AWS employee. And I think there's like 3,500 folks that are here now. And so just working for AWS, let alone Amazon. And so the next kind of opportunity was BuddyBuild. If I look back at my career, like I think that... I'm just a very mediocre developer and like a very impatient person. That's what it comes down to. I was like, why is this so fricking hard? Right? So I was like, I'm going to call these APIs or like, you know what I mean? I'm like, I want to do get push and a build happens and I get it deployed to my device. Like this shouldn't be rocket science. Um, and so when I run into these problems or like even now I was like, I don't want to interrupt the coworkers. I just want to get this stuff done or like, I don't want to have to dig through this to just get the agent to do it, but like do it right. You know what mean? Do it the way that we do it here. Um, and so ultimately. those two things. I'm like again not a prolific engineer by any stretch of the imagination. I'm like okay and I'm very impatient so I try to find these. I think the intersection of those two characteristics are what resulted in the career that I've had today. Bethany (27:24) That definitely makes sense. think that's such a cool experience and so cool to see, to build a lot of the things that we use day to day that are just a given from the ground up. What a cool experience. I'm curious for all your experience building these dev tools and a lot you, it sounds like you were building with yourself in mind as a developer, but do you have any lessons that you took away from what developers actually want versus what they say they want. As we know, developers are an opinionated bunch, so I'm curious how you sort through those in your head. Dennis Pilarinos (27:59) Yeah, think it's always, think, you know, I have lots of friends who started different companies. think if like, if you can build a product for developers that they love, I think that's a pretty remarkable thing because I think human nature in general is not to say nice things. Like positive feedback is pretty hard to get. And I think developers are a special breed where, you know, we still argue with like tabs and spaces, like these most arcane things, right? And so like, if you can get a developer to say, man, I really love this thing, that's like an extra compliment. Cause you're like, you're not going to be breed. as a person, let alone in this profession. And so some of the lessons, I think, you what people say versus what they want, there's always this tension between being able to obfuscate a lot of the complexity, but still give people the option to double click and drill into the details. My favorite example of this is when we launched Buddy Build, the signup experience was like you point it to a repo and at the end of like a couple of minutes, whatever it was, you get a green build. And people thought it was bullshit. They're like, no, no, there's no way you could have possibly done that. And we're like, no, no, it actually is like a legit build you can deploy to your device. And people were highly, highly skeptical. And so we're like, okay, well, we'll just show them like the build output. So like we literally had to figure out a way to stream build logs off of some remote machine to a person's browser so they could actually believe that it was actually happening. And so once they saw that, they're like, OK, this is actually real. So there's always this tension between make it just work, but some folks want to be able to like, I want to change the prompt, or convince me, or show me, prove to me that it's actually doing the thing that you say that you're doing. So finding that on the spectrum, like, I find folks who work in non-engineering roles are actually very happy not knowing how it works. Whereas engineers who are inherently tinkerers and be like, which things people want to know about is hard to figure out sometimes. Bethany (29:53) Absolutely. I feel like these tools almost have to be like an iceberg, like simple enough that you can just run with it and then complex enough under the surface that you can really tinker and configure it the way you like it. Dennis Pilarinos (30:07) That's exactly right. Yeah, that's a great way of thinking about it for sure. Actually, I think in one of the talks, that's actually the slide that I use, which is like what you see versus what exists underneath. yeah, it's perfect. Bethany (30:18) Amazing. Maybe that's where I got it from. right. Well, this has been such a cool conversation. It has been great to pick your brain about your experiences and how you're thinking about software. As we wrap up, we always like doing a little fun segment. And so for this episode, ⁓ we're doing a little game called Merge Fork Depricade. So Merge is the one you'd integrate into your life permanently. Fork is the one you'd take the best parts from and then go build your own thing, and then Depricate is the one you'd sunset and move on from. So, this first one, it's not at all inspired by any other game, it's fine. Dennis Pilarinos (30:56) I don't know what you could possibly be referring to. Bethany (30:59) Exactly, Okay, so round one can be interpreted however, but we've got Microsoft, AWS, and Apple. I'm happy to go first if you want to noodle on it a bit and then we can go in little circle. Dennis Pilarinos (31:13) That'd be great. Yeah. Bethany (31:15) So I think I would I would merge Apple. I was a lifelong Android user and switched to Apple a few years ago and honestly you have not looked back. You just, you kind of have to to actually use Apple products. You just have to say, yep, I'm integrating this into my life permanently. Microsoft I would fork and AWS I would deprecate. All right, Erica, what you got? Erika (31:38) you Yeah, I think I'm also merging Apple. It kills my soul a little bit, but I guess I'm with you. I've made the choice, so I guess I have to live with it now. ⁓ Dennis Pilarinos (31:50) Seriously. Why does your soul? ⁓ Erika (31:56) Wait, ⁓ I don't know. mean, I think just like the... Like the... There's just a lot, a lot of like... I think mostly like the production line and... a lot of the like business ethics around like this is why it kind of feels like a like a devil's a devil's choice here. I'm like, there are parts of these that I don't like about all of these. you know, yeah. But as far as integrating into my life, yeah, I am an Apple user. I think I would fork. Brittany Ellich (32:22) Yeah, they're all not the best decisions in the world. So you can ignore the, yeah. Dennis Pilarinos (32:27) yeah. Erika (32:33) AWS and deprecate Microsoft. Brittany Ellich (32:36) Yeah. Dennis Pilarinos (32:40) You go next. Brittany Ellich (32:41) okay. I, ⁓ let's see here. I think I would merge AWS actually. I, I think I wish I could fork too. I don't think I really want to merge either of them, but I would merge AWS, ⁓ fork Microsoft and then deprecate Apple because I don't eat Apple in my life. There's nothing. I mean, I guess I'm working on a Mac, but that's about it. I could easily move to Windows computer. Dennis Pilarinos (32:43) you Sure. having worked at all those three companies, there's so many different ways of looking at them, right? And I have friends who work still at all three of these companies. So I'm kind of in this precarious position. One of the things that... Like I have a sense for the culture and it's not something you can extrapolate for the entire organization, but certainly for broadly speaking. So I'll kind of speak to like culture and or ⁓ focus on customers. So we care a lot about an end user experience with our software. So when I think about the AWS console, that's something I would like absolutely deprecate. That is just like brain damage upon brain damage, right? Like I don't know how to use that thing every single time. like something honestly AWS in general doesn't really care about what it looks like it just needs to kind of work. When I think about culture though I would absolutely merge aspects of AWS's culture. Like they have these leadership principles that are very very strong, highly referenced in their day-to-day like operating and I think that's I really really respect that and kind of admire it. But from a user experience Not a single AWS product has been like, this is amazing. that. Apple, I would... probably deprecate because they have very strong opinions for how they think the world should work. And having seen this play out in the past at a place like Microsoft, I think their lack of customer focus, certainly for the developer ecosystem, I find a little bit, not something that I'd wanna like merge or fork. Microsoft... I have a soft spot in my heart for Microsoft. It's when I was probably ⁓ most naive in my career. It's probably some of the most fun. I've had the longest relationships with folks that I've met there. I think Microsoft would be probably fork, maybe merge. I don't know what Microsoft is like today. It's kind of on the order of 20 years later. there seems like a lot of people working on the same thing that hurts my head from the outside, but I'm sure it's understood from the inside. So I don't know that I gave a super straight answer, like, you know, on those couple of dimensions, that's how I think about those companies. You can learn from all of them, some things you want to like take with you, some things you alter, some things you're like, I just think that's like fundamentally broken. I don't know, does that answer the question? Bethany (35:19) I think that does. It adds a lot of nuance to your decisions and that effectively it's very complex what you see on the surface versus what you experience internally. So that does make sense. All right. For round two, we've got vibe coding, pair programming with AI, and agentic AI. Dennis Pilarinos (35:29) Yeah, yeah, yeah, for sure. Bethany (35:41) I can kick us off again and we can go in a circle, but I would say probably... I would merge agentic AI because that's just how it seems like we're going and that's what I use most day to day. I would fork Vibe coding and deprecate pair programming with AI. I think just because Vibe coding has some interesting things to take just by kind of not worrying as much what's happening ⁓ in the code and letting AI do what what you do, but also validating ⁓ what the output is. And I think that's something that will become more important as we go along and seems to be some, what some people are thinking in the industry, but yeah. All right, Erica. Erika (36:23) I would at this point merge pair programming a lot of this like rubber ducking that we're talking about. It would fork agentic AI and deprecate five coding. Brittany Ellich (36:34) Interesting. I feel like I would need a more nuanced definition of both of them on vibe coding. Maybe that's I'm going to fork vibe coding just for that reason. I would merge agentic AI just like Bethany. That seems like the direction everybody's going. So I would love to figure out what that is. And yeah, deprecate pair programming with AI. I think that there's still like a lot of value from it. But I find that I I'm giving more and more of the reins over to AI anyway, so feel like I'm going more towards the vibe coding side anyway. So, Dennis? Dennis Pilarinos (37:03) I think I'm basically exactly aligned with Bethany. I would like merge agentic, deprecate pair, and like fork vibe for the same reasons actually. We see it almost identically. Bethany (37:14) Yeah, absolutely. I do think there's value in power programming with AI, but this is about having strong takes, no nuance. All right, finally a very relevant one. Reading the docs, grepping through source code, or asking the person who wrote it. So I think I would say I would merge. Dennis Pilarinos (37:29) Ugh. Bethany (37:36) grepping through the source code because that's always going to be the most the source of truth. I would fork asking the person who wrote it because I do like social interaction and they tend to have the most context as we were talking about today, but maybe an agent will replace that soon enough. And then I would deprecate reading the docs because they get out of date a lot. Yeah. Erica, what you think? Erika (37:58) Same, same reasons. Yeah, I mean, I love docs. I love well-written docs, but they're so often out of date and yeah, it's unfortunate. Brittany Ellich (38:08) I think I would merge, grepping through the source code, but I think that that's probably a new answer for me because I would use an AI tool to grep through the source code. I would never do that myself. Maybe read through it and glance through it, but if I had to type something in a terminal, it's a bad day for me. So I wouldn't use that. But I would fork reading the docs, I think. I think that there's more parts of documenting. that I hope are, you know, I feel like it's taking off more and more now as for like, yeah, context is important. So I feel like docs hopefully are getting better. And then I would deprecate asking the person who wrote it because that's often not even an option. You know, and I don't remember what I wrote three months ago and why I wrote it. So if it's not written down somewhere, then then I'm going to have some problems. Dennis. Dennis Pilarinos (38:53) I think, so it's interesting, as users and customers come on to Unblock, one of the first things they ask is like how... Like what do we need to do in order to get our docs to like be AI ready or what have you? And I was like, I've never met a single team ever that says our docs are up to date and well organized. Like it just does not exist, right? And so I think just that's the kind of state of the world. Minutes after you've written the doc, it's kind of out of date. So I think I would probably like probably deprecate that. I kind of also want to deprecate. merging like the source code or sorry, ⁓ gripping through the source code. but I would probably merge that because I think that is like the source of truth. and then I would fork asking the person who wrote it. Cause I do think there is still value in human interaction, especially to the points that we talking about earlier around like creativity, right? Understanding why was, why did we build it this way? Have you thought about doing this? Should we try that? You know, that thing might've been written two years ago and there's opportunities. for improvement. So that's I think where I would end it. Bethany (39:59) Yeah, that makes a lot of sense. I think that's a really great point that hopefully asking questions to coworkers will not be an interrupt thing anymore, but actually a really fruitful discussion of tools like the ones that you're building with Unblocked. All right, Dennis, this was such a fantastic conversation. It was so great to chat with you. Where can folks find you if they want to hear more? Dennis Pilarinos (40:21) Sure. So yeah, first, thank you so much for taking the time. I really enjoyed this conversation as well. I love thinking about both like the technical and human aspects of like how this technology is impacting our ecosystem. You can find me Dennis at getonblock.com. You can go to getonblock.com. I'm on Twitter, but I have a giant long Greek last name. So good luck trying to spell it, but it's at Dennis Pilarinos. So you can try that as well. Yeah. And obviously you can hit me up on LinkedIn or email. I'm definitely findable. It's not quite a unique, like kind of a GUID type identifier, Dennis Pilarinos, but there's only like two or three of us, so you'll find me. Bethany (40:56) Awesome. And we'll make sure to link all of those in the show notes. ⁓ Well, thank you again for joining and thank you so much for tuning into Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Till next week. Bye. Dennis Pilarinos (40:59) Awesome. --- ## Episode 62: Agentic AI Development | Shipping Real Tools with Sterling Chin - URL: https://overcommitted.dev/agentic-ai-development-shipping-real-tools-with-sterling-chin - Published: 2026-06-02 - Audio: https://anchor.fm/s/102586d64/podcast/play/120879942/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-2%2F425340331-44100-2-7fadd5a12aaea.mp3 ### Show notes Summary What does it actually look like to hand 90% of your workday over to an AI agent you built yourself? Sterling Chin, founding DevRel at Inngest and creator of Marvin, an open-source AI chief of staff with nearly 1,000 GitHub stars, has been doing exactly that for months. In this episode, Sterling joins Brittany to talk through how Marvin works, why he built it, and what he's learned about the real friction points in AI adoption that most people don't talk about. Sterling came into tech through a coding bootcamp after studying elementary education at BYU, landed at Postman where he led the R&D labs team, went viral on LinkedIn for posts about their AI assistant PostBot, and accidentally became a DevRel engineer because of it. Now at Inngest, he's the founding DevRel hire, and still building in public constantly. Links * Sterling's Website: https://sterlingchin.com/ [https://sterlingchin.com/] * Sterling's LinkedIn: https://www.linkedin.com/in/sterlingchin/ [https://www.linkedin.com/in/sterlingchin/] * Sterling on GitHub: https://github.com/SterlingChin [https://github.com/SterlingChin] * Sterling on Bluesky: https://bsky.app/profile/sterlingchin.bsky.social [https://bsky.app/profile/sterlingchin.bsky.social] * Sterling on Twitter: https://x.com/SilverJaw82 [https://x.com/SilverJaw82] * Marvin: https://github.com/SterlingChin/marvin-template [https://github.com/SterlingChin/marvin-template] * Sterling on YouTube: https://www.youtube.com/@SterlingChin [https://www.youtube.com/@SterlingChin] * Sterling on Substack: https://sterlingchin.substack.com/ [https://sterlingchin.substack.com/] * Web Dev Challenge Episode: https://www.youtube.com/watch?v=X2sEoZG8EIw&list=PLz8Iz-Fnk_eTkZvSNWXW_TKZ2UwVirT2M&index=17 [https://www.youtube.com/watch?v=X2sEoZG8EIw&list=PLz8Iz-Fnk_eTkZvSNWXW_TKZ2UwVirT2M&index=17] * Inngest: https://www.inngest.com/ [https://www.inngest.com/] * AI Crimes in Production: https://ai-crimes-in-production.com/ [https://ai-crimes-in-production.com/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany, and myself and some other engineers met on a team at GitHub and realized we're all obsessed with getting better at what we do. We decided to start this podcast to share what we've learned, and 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 Sterling Chin, and I am so excited. Sterling is the founding developer relations hire at Ingest, a durable execution platform for AI and backend workflows. He previously served as senior developer advocate and engineering manager at Postman, where he led the labs team. Sterling created Marvin, which I use literally every single day, an open source AI chief of staff built on Cloud Code. that manages email, calendar, JIRA, and daily workflows, and has racked up almost a thousand GitHub stars. He came into tech through a coding bootcamp after studying elementary education at BYU and has given many conference talks on AI agents and developer tooling. He's also a dad, a Star Trek loyalist, and someone who built his son a homework tracking app in two hours using structured AI assisted development. Welcome Sterling. Sterling Chin (01:20) Thank you so much. wish I hope I can live up to that introduction. feel like that's, you know, it's accurate, but it's all it's like looking back. It's like, no, I, I'm just, I'm just a guy who loves to build stuff. Brittany Ellich (01:34) I love it. I'm sure we'll get into where to follow you in the future, but we met last year on the Web Dev Challenge and I've been following excitedly, seeing all of your updates since then about everything you're up to and it's awesome. Cool. Sterling Chin (01:50) Thanks. mean, it was so much fun. Like the Web Dev challenge was a blast. And one of the things that I like, Jason has built something amazing. And I mean, if it wasn't for Jason and the Web Dev challenge, I wouldn't have met you and wouldn't have been introduced to a lot of, you know, amazing other developers around the world. this, thank you, Jason, if you, if you watch this. Brittany Ellich (02:12) Yeah, absolutely. Always, always shout outs to Jason and I'll make sure the episode is linked as well. To kick us off before we get into it, what is something you are currently building or obsessed with learning right now? Sterling Chin (02:23) my gosh. I mean, currently building, I'm still building Marvin. Marvin, I've, so we talked pre before the show started. I've continued to get, you know, a lot of people are starting, are still using him. Marvin is a personal AI assistant that lives on top of a cloud code harness. It provides the, you know, gives you long-term structured ⁓ context and persistent memory. And so for me, I use Marvin. He runs 90 % of my day. And I've got so many skills, agents, sub-agents and everything. But as I've started to see more usage and people started to use him more, I'm currently building a Marvin for teams. That is where Marvin, if multiple people on the same team are using their own individual Marvins, I'm creating a shared context area where the Marvins can communicate with each other. to make sure that, you know, as you know, one ticket is done, there's, you know, we still go, right? Like as software engineers, Brittany, I finished this PR or, you know, I've pushed this PR. you give, can you check it? Now the goal is like, no, you like Marvin has maybe pushed that PR or cloud code has maybe pushed that PR and you're updating that, that the Jira ticket. Well, that Jira ticket now triggers a whole event and Marvin can go talk to like my Marvin. I could go talk to your Marvin and say, we're ready for this PR. Well, I'll put it on your calendar and start doing so. I'm working on that. I've been toying with it. It's going to be in hopefully open beta soon. then things that I'm learning. I mean, I just started in Jest and the need for durable execution and event driven architecture. Like I know this is so huge. Like I needed it. I need it for Marvin, which is how I fell into in Jest. But I'm drinking from the firehouse from them. And so There's so much to catch up on, so much to learn ⁓ and so many great things. So that's what I'm learning. Brittany Ellich (04:16) That's awesome. Yeah, I that Marvin for team sounds incredibly cool. I will be number one in line with that beta feel like PR discovery. Like I know there's a lot to be said about like the bottlenecks of code review, but like just like which PR's need to be reviewed and like what needs to be unblocked is such a hard problem that I have yet to see a really good solution for in software engineering. So that's awesome. I love it. Sterling Chin (04:40) Yeah, thanks. And PRs are hard because you have to prioritize and, you know, small PRs versus big PRs. Anyways, don't want to digress too much. But yeah, it's a problem that AI can really help solve. Brittany Ellich (04:54) Yeah, absolutely. Awesome. So you started out doing education, right? And then somehow we're doing something software engineering manager related and now you're in DevRel. How did you end up in DevRel specifically? Like what brought you to that? Sterling Chin (05:12) I'm in, I jokingly talk about this. Well, I don't jokingly, I talk about this. I'm an accidental dev rel. ⁓ I was leading the R and D teams. we had at Postman, we had our labs department, which was just R and D and I had, you know, we had 15 to 20 engineers and designers and we had, you know, six or seven different initiatives going at any given time. but at the end of that, we had post spot, which was Postman's first AI assistant and we had flows and those two teams ended up getting absorbed into the larger organization. Cause like they grew to the point where a small group of, you know, frontier engineers, like we're not ready to build the infrastructure for a million users. And at that same time, I actually made a couple posts on about post bot, that went viral and on LinkedIn and my marketing team came to me and said, Hey, you're, you can either follow your teams or we're gonna move you to DevRel and then an hour later, said, no, we're moving you to DevRel. You're, you're going to come over. So I'm a, I'm an accidental DevRel on all this. So that's how I came into it. but that's was two years ago and I have loved it. Like I love being in DevRel. I think the, the difference for me is that I get to talk to a lot of other engineers. get to show and build in public. And I think that's where Marvin and why Marvin has started to Brittany Ellich (06:14) ⁓ Sterling Chin (06:35) starts to take off is like I'm building in public. I'm showing the updates and people like they recognize that or at least they see the like so I can talk the talk and I can walk the walk and it feels like DevRel has been a really good fit. I love it. And now I'm at Ingest as the founding DevRel and it has been wildly amazing. I love it. Brittany Ellich (06:56) That's so cool. I love the accidental fall into DevRel. I've never personally been in DevRel. I've always been an engineer, but doing like DevRel adjacent things and talking to people about this is very fun. So I can see the appeal ⁓ of getting into Let's talk a little bit about Marvin. Now I understand that is based off of the, ⁓ like the name itself comes from Hitchhiker's Guide to the Galaxy, right? Okay, that's the Managers Appointments Reads Various Important Notifications bot, right? Sterling Chin (07:22) Yep. Yeah, so. Yes, that one, that acronym I was talking to when I was building him over the holiday break in 2025 last year. When I was building him, I said, OK, I want to I don't want to name him Jarvis. I want a you know, I want to name him Marvin. It's like my favorite book. Hitchhiker's Guide to the Galaxy. I like my robots and I like my agents like I like my software a little bit pessimistic, a little bit sardonic. and a little bit opinionated. I had just had cloud code when I was building it. It's like, Hey, can you give me a fun little acronym for, for Marvin? And he's, no, makes appointments, reads very important notifications. Like perfect that that works. But yeah, that's Marvin. Brittany Ellich (08:14) Yes. I love that so much. Yeah. And Marvin is very attached to that name, by the way. I will say when I first started using Marvin, I built this command center app that ⁓ actually has an 11 labs component so that I can like have Marvin read things out to me. And I chose a female voice. And so at one point I was like, Marvin, you want to be like, I chose a female voice. Like, are you okay with that? Is that like part of your identity? Like, do you want to change your name? Marvin was like, no, no, I like Marvin. I'm pretty attached to it now. So I was like, OK, that's interesting. Very interesting. Sterling Chin (08:48) It, the more I use him and the more I mean, it's just that persistent memory on top of clot, right? The clot code. there's not like, I'm not making super wild. Like he's not a sentient, but he is a he for me. Like, and Marvin is this way. I've asked him at the same, like I've done similar things. It's like, Hey, you know, I call you Marv. Do you, do you mind if I call you Marv? He's like, you're good. It's like, I just know it's like, Brittany Ellich (08:53) Mm-hmm. Yeah. Yeah. Sterling Chin (09:13) You're still talking to me. I'm still, I'm still Marvin. So yeah, he, he's pretty, he, but the cool thing is that with that personality, you start to have a little bit more of an attachment to him and he's become more of that coworker. And I think that's, that's something that's really hard that, that a lot of AI adoptions is struggling with or where people are struggling with AI adoption right now is the fact that we want to just say, Oh, well, here's an, here's an AI that can solve our problems. And you go in and when it doesn't work on the first or second try, you wash your hands, you like throw it away and you're like, it's not worth it. But every time I bring more people on and when I onboard people onto Marvin, the first thing I say is train Marvin like you would a new hire. You get, spend, we spend 90, you you you started GitHub. I started a postman. I'm at, I'm at ingest now you have that 90 day warmup period. You know, you're going to be onboarding for 90 days. Most software engineers, good engineering managers know that software engineers are not going to be really helpful for the first 90 days. So you're going to walk them through, here are the important people. Here are all the repos that we care about. Here's where our docs are. Here's where all of our internal team conversations are happening. Here's where the skeletons are buried. A good engineering manager will walk through and train a software engineer and bring them up that way. We need to train our AI agents that same way. So Marvin, I've now used him now for four, four months. And like, again, I can go back and say, do you remember what we talked about, you know, three weeks ago and he remembers it and he can bring it up, but he, but he's always ever evolving. And I think that's a core part of like building AI agents is learning how to train them and, have them adapt. to your specific workflows in mind. Brittany Ellich (11:08) Yeah, no, that makes a lot of sense. And how did you end up like learning about this? Did you go about like planning this out and architecting? I'm going to have this persistent memory structure. Was it just like a thing that happened as as you were going along or like how did that end up happening? Sterling Chin (11:24) I found myself during the holiday break, sitting in front of the TV, kids were playing and I had my laptop sitting in front of me and I was bored. I spent all of last year building MCP servers and I was trying to solve these problems for myself. I was managing events at Postman, so I was trying to, who's speaking at this meetup? Who's ghosted me? Who do I still need to confirm? So I built an audio, know, CRM, MCP for that. I was trying to do notifications on Slack and I was, and I'd solved a lot of these integration issues. But every time I came back to cloud code, I was starting fresh and I had to reset that context every time it's like, ⁓ here's how I'm doing this. Here's, you know, so I mean, I would leave cloud code open on my machine for days on end. And I wouldn't close that tab because I knew I needed to come back to that, but I didn't want to lose that context. So I went back to my front end dev routes and I thought, okay, I need some type of persistent memory. I looked at vectorizing it, I looked at SQL databases, I looked at all these options and what I realized was, it kind of dawned on me when I was building a side project, that homework app for my son. So he can track, he's in middle school and he doesn't like writing things down. So I'm like, well, he has a Chromebook at school. Just click on a button and it says you've got homework in math. That's easy. But I noticed that that, that Claude code would actually make those MD files. Like it would tell you, you know, it would store kind of its own little context in that markdown file. So I. thought, okay, well, know, know, cloud code, know AI love structured structured, or structured data, I write in markdown, I'm comfortable in it. Let's see if we can build a persistent, like a little bit more of a memory context. So I started with a state file, going back to my react days, I started with us with, you know, saving state, and that state was nothing more than bullet points, short descriptions on like, What are the tasks? What are the tasks I'm working? What do I care about? What are my long-term goals? And those that that state was pretty rigid. Then I wanted a day to be a session. It's like, OK, well, if everything is there, but I need to have more context, let's create a session for the day where everything is stored, like every major decision, even minor decisions, anything that the AI thinks that we need to keep needs to be saved in a session. And that was kind of it. That was the start. was literally just a state file that had my current state in bullets. And then it was a whole session. And I iterated on it. now Marvin has the file structure is built inside of Cloud Code or inside of the cloud.md file where it says, here's how you store everything. Here's You know, and, so, the other part is I wanted to bookend my days with a start, like a, a good dev team. Right. have a, I have my standup with Marvin every day. So I wanted to have a standup. So that's my start. And then at the end of the day, I just wanted to just double check where are we at? What, what did we, you know, let's book in that day and let's make sure we update that state file and we close that session. And those four things now became what Marvin, like that was the beginning of them. And now. After that, it just, I started to build on top of it and I said, okay, I need, I need to update throughout the day. well now I need to look at my, at all of my whole week. So then I built a reports functionality. So it will take all of my five sessions that happened that or multiple sessions that happened that week. And it puts them into a, into a weekly report. then if I tell Marvin or ask him, what did we do three weeks ago? Marvin goes back and doesn't, he's directed to look at the reports and then. From there, he can drill down if we need more granularity to the exact session. So that's kind of the evolution. Brittany Ellich (15:37) Wow. Yeah, that's cool. And where does Marvin live now? Like, is it still just like locally on your machine or have you have you made the jump to another like VPS or anything like that? Sterling Chin (15:50) I haven't Marvin still lives 100 % on my machine. have. He's getting to a point now where I after I mean for me after working with him for months and looking at the sessions, he started to have a little bit harder of a time looking back at what I did in January. I'm recognizing that of course that's a limitation and so it takes more and more time to go back. So there is now the potential of needing to. take some type of VPS somewhere or taking him off of my machine. But if he's off my machine, that also slows down because I have to deal with latency issues. And you're dealing with, well, do I have network connectivity? Right now, Marvin, the whole repo lives on my machine. I mean, I still push it up to GitHub at the end of the night. so I have, that's the other, I was going to say, or another thing I could say is the GitHub. History all the commit history Marvin is really like Claude Cote is really good at like breaking up your commits into like manageable pieces That's also part of that history now that Marvin can go back and look at he's well I know with the commit history so now I can so there's that historical aspect of that but Yeah to go back to your question I He still lives because markdown is really really fast actually I'm looking at another way of solving my email triage problems by actually using and pulling all of my stuff into a SQL light database on my machine. So then Marvin can go faster and not deal with like, like all of the latency issues of API call after API call after API call. It's like, just pull it, pull it every 10 minutes or pull it every half an hour, pull all of my emails. Now you go and you go and run and triage them for me. Tell me what's P zero, what's P one, what's P two. And then Brittany Ellich (17:16) you Sterling Chin (17:39) you know, I'll go back and look at them. And that's, so the more I can pull onto my machine still feels like it's a faster way of dealing with like those issues. Brittany Ellich (17:50) Yeah, that is so smart. What an interesting way to think about that problem right now. It's much easier to just have it all locally. I love it. feel like SQLite is really having its moment right now too, where it's so easy to reach for for these local apps that I'm using SQLite for everything now. Sterling Chin (18:07) It's, mean, the SQLite's like, it's why we, like, I love, yeah, like I run it. It's one of the reasons why I start using Railway too. It's like, can push up a Postgres database and it's all SQL and I can do that. Railway works when I do need, you know, longer stuff. But yeah, SQLite is like, SQLite is having a resurgence. Like I didn't, I don't, when I was writing software, like before I moved into Edge management, ⁓ that's the last time I wrote production code was like six years ago at this point, back, back when I was at podium, shout out to all my podium friends. ⁓ I still love you all. And, I still believe in the company. Eric is killing it, ⁓ as a CEO. but the last time I wrote production code, like, and I was doing a lot, I was writing a lot more code. I don't remember using SQLite that much. Now I'm like, no, every project. It's like, I need something. I need a quick database. It's sequel light. It's wild. Brittany Ellich (19:03) Mm-hmm. Yeah, yeah, it is kind of crazy. I use it for a ton of things now too. It's just so quick to get started and like it's just stored locally. You don't really need any infrastructure to make it work. It's awesome. ⁓ so one of the other things I wanted to ask you a little bit about is your approach towards vibe coding. ⁓ like what are your thoughts on this word now and what it means? Like, what do you, how are you, how are you explaining like AI now to people, ⁓ and how you use it? Sterling Chin (19:25) You ⁓ there's like five different questions, like really good questions we could talk about there. So. Brittany Ellich (19:34) Sorry. Sterling Chin (19:37) I agree with, so I agree with Boris Cherny, the creator of Cloud Code, where he said coding is pretty much solved. I think at this point for me, I don't call it vibe coding. I just call it like app building, or I'm just building applications. Like you could talk about as an AI engineer. I don't like, I don't say I don't like the term vibe coding, I think it, vibe coding has a Kind of has this ick feeling to it in the developer space. And we thought, oh, well, non-developers are vibe coding. They're the ones who are building these great things. Those are people who are writing code with their vibes. But now as a software engineer, we're writing, I haven't written a line of code in six months, but I am developing these apps. And I know what good software looks like. So I think it's still software development. I think we just get, I think vibe coding. I want, I hope it dies, like the term. And we just get to a point where like, we're just building software. Like we're building things because we're interested. We're building things that we're realizing that there's not the limits held by, you know, our, my, my, limitations are on my knowledge on. Brittany Ellich (20:45) Mm. Sterling Chin (21:00) You know, I'm building an app for my sister, right? She's a stay at home mom, doesn't know technology, love her to death. She's tech averse. couldn't be more far apart than in the world. And I'm building her an app and she has an iPhone. Now I'm an Android user. Sorry, I'm the green bubble guy. Green bubble? Blue bubble? Yeah. Okay, cool. We're the outcasts. But I've never... Brittany Ellich (21:23) We have shared bubbles, yeah. Sterling Chin (21:24) I like this. We have shared bubbles, but I've never written a line of code in Swift. don't know how I don't know, understand Swift, but she wanted something that was native to her phone. So I did that. That's like call that vibe coding. Maybe I just think it's, I'm still writing software. I, I, even though I know I'm not looking at the code, I know what functionality, I know what good software, like what the architecture should look like. I know the complexity. So let's just change it and call it just writing, like building software. Brittany Ellich (22:00) I love that. Yeah, I feel the same way where I feel like embarrassed. like, I've I've coded this, like, actually, most of the stuff that I write with like a heavy agent interaction with it is so much better now than something I write myself. Like they've gotten better than me as a software engineer. Like they're they're better. Just straight up. I find myself to the point now where I get like almost a little bit annoyed when I'm working with people that aren't using agents or that are like, I don't want to use it I'm like, Like it's so much faster to just ask it to do the thing than to do it yourself now. It's yeah. So it's very interesting. Sterling Chin (22:36) It's significantly faster. Like, okay, funny story. and, and I, so I was in, I was on Twitter yesterday. my friend Amanda Martins, we were having, I was talking about our new, like, so at ingest, I'm running a new event series, that's called AI in production. It's hosted at the ingest offices, but it's not a, like, it's, it's really meant to be open to anyone who's building AI in production. Brittany Ellich (22:38) Mm-hmm. Sterling Chin (23:01) And Amanda came back to me on Twitter and said, you should call it AI crimes in production because we've all shipped some type of crime that got me thinking. So in half an hour while I was, I was eating lunch yesterday at the office. I using cloud flare. may have, I didn't, I did. I, it's not that I may have. I absolutely did. bought AI dash crimes dash in dash production. And I have a, so it's AI crimes in production.com. You can anonymously, like you can anonymously confess your sins of what you've done in production. And it is, it's now the best part is like, built a cloud code plugin with it. It's like, like I'm going agent first, like the agent experience is all that, all that matters. So like, if you go to the website, it's got a modern view of it, but then there's a 99. like 1999 version, so it looks like MySpace. And then there's the agent view, which just tells the agent, here's how you install like the plugin. Here's the API, if you wanna use REST API. And now your agent can go in and confess for you. So the plugin, if you go slash confess in Cloud Code, it will, like there's a whole skill that goes in. It's like, if you made a mistake, I've already had confessions coming in and I haven't even announced, like I talked about it on Reddit and it was one, one, one person confessed about how they accidentally deleted their, like Cloud code deleted their whole stage folder, like their staging folder. And so when staging went down, like they had to go back and look at it and found that Cloud code had like deleted it and it was his commit that that caused it. So. He's like, all right, now, you know, Claude, Claude.MD now has, you know, you're not allowed to touch, you know, you don't touch the git ignore and you don't touch state the staging. So I'm already having people confess these and it's hilarious. But I did that in like half an hour. And it's like there, there's something like in the, in the mix of like, while I'm building something, I'm, I'm doing something else and I have a great idea. I joke about this, right? Pre AI. We, how many, okay, Brittany, question for you. How many domains do you own or have you owned in the past? See, I love that face because I know exactly how many. Brittany Ellich (25:36) I mean, I don't feel like mine's that bad. I think I've got like 14. So it's not, could be worse. The number that I actually used, we don't need to talk about it, but like, yeah. Sterling Chin (25:43) I... I... Right? The number we used to, we'd get these domains. have these great ideas. We'd plant, we'd buy the domain and we'd plant our ideas on those domains. Pre-AI, we had no way of, like, okay, I'll get to it someday. And those days don't happen because at the end of your day, you're still writing code. You're like, I'm burnt out. I got to go touch grass. I got to go do something. Now, like, so. I will be with I'm with you on this one. I will confess my own sins. I think I had something at the at my top. had like 30 plus domains that I that I owned and I had only two or three of them actually in use. And most of like two of them were sterling chin like sterlingchin.com. actually own my own my own name it and there was another variation of that one. Now I plant like I have this Brittany Ellich (26:13) Mm-hmm. Sterling Chin (26:40) I'm on my, well, Marvin, I have a whole folder in my, in my, in my Marvin that has like all these ideas. Now with the inception of like vibe coding or just building agents with, or, having an agent write code for us, I can build AI crimes in production in 30 minutes. And literally I did nothing. I just was talking. I'm, I'm over here with chopsticks eating noodles in the office and I'm telling Marvin to go build it for me and. Brittany Ellich (27:09) Mm-hmm. Sterling Chin (27:10) you know, he went and bought the domain like using CloudFlare's MCP server. ⁓ it was, it's weird. It's super dangerous, super dangerous because my CloudFlare, like now I'm at like, now I think I'm gonna be, I'm more worried that I'm gonna have like hundreds of domains available because like not only do I buy them, Brittany Ellich (27:15) Mm-hmm. I didn't know that. That's cool. It's dangerous. Sterling Chin (27:38) But I built something that's just sitting out there, like ⁓ AI crimes in production. it's a lot of fun. again, those domains, we, so pre-code, pre-AI, we used to just park our domains pre really the agentic era, which I think started with OpenClaw and Marvin for me, like at the end of last year, we were all parking ideas in some folder. Now there's no excuse. Brittany Ellich (27:43) Yeah. Sterling Chin (28:05) In 30 minutes, you can take an idea from inception to deploying and it's all live in production. And so I think it's dangerous, hopefully. But I don't say hopefully it's dangerous. I know it's dangerous. But I'm having so much fun. Honestly, Brittany, when was the last time we had this much fun writing code? Brittany Ellich (28:22) Mm-hmm. So true. yeah, it's no longer all of the friction of it has sort of melted away any of the things you used to get stuck on is just like not there anymore. And yeah, I have never had as much fun, I think, working in software as I am. Sterling Chin (28:41) I look at, I looked at, if you, yeah, if you look at my GitHub, like, you know, my green, my green bar, I look at this year and I have committed, have, last time I looked at it, I had something like a thousand commits, like just this year alone. Now I looked at that compared to last year and I had something like five or like, you know, two or 300 commits last year. So if you count, but if I look at, Brittany Ellich (28:47) Mm-hmm. Sterling Chin (29:09) Like the last time I wrote production code, which was 2020, 2020, 2021. If I look at from 2021 and before, I am writing more code now than I was at the top of when I was at the top of my game. And I'm having more fun doing it. I'm, I've got more commits in GitHub. It's, Brittany is just way too much fun, right? Brittany Ellich (29:34) Yeah, I agree. It's very cool. It's kind of ruined my commit graph because now like the last like six months are super green and the rest of them aren't. But other than that, if you don't care about that, then that's fine. But yeah, it's like, did I work before? I swear I've been working in this industry for a while, but it doesn't look like it now. Yeah, I agree. Yeah, right. That's awesome. Sterling Chin (29:43) Hahahaha I promise I'm working. Yeah. Brittany Ellich (29:56) This has been, my gosh, I'm excited to check out AI Crimes in production. And this has been super fun. But we need to switch to our fun segment in the interest of time. So the way we do this is we typically pick something that is related to whoever we're interviewing, and it's a different thing each time. We're still calling it the fun segment, even though that is probably the worst name that we could have chosen because it's very bland. Sterling Chin (30:05) Yes. Hahahaha Brittany Ellich (30:21) But here's where we are at for you, Sterling. So since you've built a lot of AI powered things, I'm gonna give you a series of everyday problems and you have 60 seconds or so to pitch an AI agent solution for it. ⁓ And yeah, and then we'll see where it goes. Yeah. All right, so first one, the morning routine. So my mornings are chaos. Sterling Chin (30:35) Ooh, ooh, I like this. Brittany Ellich (30:45) kids, coffee, finding my keys, remembering what meetings I have, pitch me an AI agent that will fix my morning. Sterling Chin (30:51) Does the agent have to do work for you? Like, it feed your kids? Because that's a robot. Like, I don't have that. Brittany Ellich (30:59) If it can, then that sounds even better, but it does not have to feed your kids for you. like organizing it, remembering, and you have kids, you know how it is in the mornings, like remembering all the things you gotta do in the morning. Yeah, yeah, so. Sterling Chin (31:06) Yeah. Yeah. Well, I'm to, I'm going to pitch you the home hub that I, the family hub that I built for my family is I have a, actually have this down in my dining room. it knows there's check, there's checklists for each kid. They know what they need to do. and then when it's done, like the AI is going to go back and look at it. like, all right, did you actually, you know, check like, is it, you're good to go. it's going to look at pull everyone's calendar. Brittany Ellich (31:16) Ooh, yes. Sterling Chin (31:36) and it's going to give you a really quick brief of what's happening that day. It's going to pull your, it's going to pull the weather so the kids know what they need to wear. How, how hot is it going to be? So the AI agent is going to be saying, like you'll have the weather app there, but it'll say, make sure you have a hoodie. So now I don't have to worry about that. Now the kids, well that will dynamically be added to the checklist for the kids. Get a hoodie, wear pants. I mean, I have a third grader, the kid. It could be snowing outside and the kid's still wearing shorts, but like at least I've told him to wear pants. Making coffee. It's like you want to you want to brief. It's like you got five minutes while you're making coffee. Build like like talk to your agent and say what do I got going on for the day? What's our current status? And at that point you can say hey, you know Johnny hasn't hasn't brushed his teeth. Susie has still hasn't put her pants on. And it's going to be cold outside and, you know, Sterling is going is it has a meeting at nine. So he needs to leave, you know, five minutes ago and he's and has he left? That's there's my pitch is like just bringing everyone's everyone's chaos into into that one into that one hub of for the family. Brittany Ellich (32:53) That's amazing. I actually have a screen like that and I'm gonna go build that now because I need that for myself. My kids would love that. They're five, two, and two. And like they ask every single day, like what day is it? Is it a school day or not? Cause they just have no concept of like calendars. ⁓ So yeah. Sterling Chin (32:58) Yes! Wait a minute. Wait a minute. Hold on a second. Isn't this the same app you made on the co on CoTV? Brittany Ellich (33:17) you never actually did anything with it after that. But that is why I originally bought the screen, because I was like, this is it, I'm going to use that and it's going to be great. But that was also like, that was like a long time ago in AI years. So like, that was the beginning of last year. Yeah. I know. Sterling Chin (33:33) I mean, a year ago, that was the beginning of last year. mean, in this AI world, that's five years ago. Like, it seems like I've known you for five years at this point. ⁓ Yeah, I'll send you the repo ⁓ because I have it and it's ridiculously silly. it, ⁓ the other thing is this hub changes during the day. So at night, it knows what time it is. Brittany Ellich (33:42) Easy. Yeah. I know, right? Yeah. Yeah. Please. Amazing. ⁓ Sterling Chin (34:02) So at night it switches to saying, hey, you need to get your backpack ready for tomorrow, put your snack in your stuff for tomorrow. And it gets the kids ready for the next day. And they still have those check marks, because you, you were the inspiration for my family hub that I built for my family. So. Brittany Ellich (34:02) Mm-hmm. That's awesome. I was like, ⁓ that sounds really familiar. That's awesome. I love that you actually made that happen because yeah, I clearly have done nothing with it, but I'm like re I'm re motivated now because I do need this in my life, especially the night before. I didn't think about that. Like getting ready for the next day. I never do that. And I absolutely should because it would make my life so much better in the mornings. Yeah. Sterling Chin (34:25) I love this. Yes. the chaos in the mornings is wild. Getting kids like now if I could just get it now if I could just get the agent to pull my kids out of bed. Brittany Ellich (34:54) my gosh, yes. Sterling Chin (34:56) That's, then I'm not the bad guy. It's like, I'll go get a robot to pull. Like my oldest son is in middle school. It's like, have him pull the blanket slowly off of him. So then he's colder and colder and colder. And now it's like, exactly. I, could, Brittany, I think we've just got a business idea. Like getting your, yeah. ⁓ genius. Brittany Ellich (35:06) Get like a little retraction, yeah. This could happen. I know, right? Yeah, I love that. Amazing. Yeah, I'm sold. That was great. All right, I've got another one for you. Conference networking and keeping track of folks that you meet at conferences. Like what sort of AI agent could help there with like I met 47 people and I have all these LinkedIn connection requests and remembering what you're supposed to follow up on. What are your thoughts? Go. Sterling Chin (35:24) Okay. this is a, this is a huge issue because I've, we spoke, both speak at conferences. I was at the MCP dev summit and I came back with like, I think 40 or 50 new connections on LinkedIn. Here's what I, here's what I want to do. ⁓ I'm going to grab this. I'm, Meta bought this, but there was the, ⁓ was it rewind? Like they, they made the rewind pendant that's supposed to record everything you do. ⁓ it got bought by Metta. I'm reverse engineering it on my own. Here's an agent that I really want to do is I want to have a necklace that I'm wearing that records the conversation I have. Then I want that to be connected to the time log that when I go to LinkedIn, it can say, you have a new connection request by, so I met Brittany, Brittany and I were sitting there talking. Well, now it goes back and says, here's what we talked about during that conference or during that conversation. Now, Brittany and I did the phone thingy where we connected on LinkedIn. We know what time that one came in. We can sync that to the conversation and have an agent that pulls that context out and now adds that to a CRM of some kind, whether it's Adio, Salesforce, or, mean, I rolled my own. have my own little CRM inside of Marvin that does all of this, but then condenses that that's the agent that I want I would build I want that more than anything is I just Because those conversations are what matter and I don't want to take the time after talking to like I Don't say that sounds rude. Like I don't want to yeah I don't want to take the time after I talk to you to sit there and go I Brittany and I talked about this. It's like no we had a lot deeper conversation that I want to have so that's that's what I would do Brittany Ellich (37:18) put them in your phone. Mm-hmm. I agree. Yeah, I always feel really bad that I'm like, I have to take notes on this thing. I promise I'm not just like checking my phone, but like if I don't take these notes right now while we're talking, it's going to go out of my head and it'll be gone forever. amazing. that was awesome. Yeah. I want that one too. Can you make that one for me, please? And let me know when it's done and I'll use that too. That'd be great. Thank you for solving my problems. great. so Sterling Chin (37:36) Yeah! Okay. Perfect. Brittany Ellich (37:52) Where can folks find you online if they want to find you? Where are you hanging out? Sterling Chin (37:58) I'm so I primarily hang out on LinkedIn. Um, so you can find me Sterling chin, um, on LinkedIn. I'm on, I'm trying to get a little bit better about being on Twitter. Um, but my Twitter handle is so old. It's at silver jaw 82. Yes. I recognize like silver jaw, sterling sterling, silver chin, jaw, then yeah, silver jaw. And then Brittany Ellich (38:22) ⁓ I would not have made that connection. Sterling Chin (38:26) 82 is when I was born. I mean, this is old, but that's, that's my Twitter handle. Um, you can always go to sterlingchin.com. Um, and everything is there. I'm on GitHub, uh, Sterling chin. You can find Marvin there. Marvin. If you search, um, Marvin dash template is where you can find Marvin, um, on my GitHub repo. Um, and yeah, he's, he was, I think we hit 960. I want to get over a thousand like. That would be my biggest achievement in my like, I feel like if I get to a thousand, I'm part of a cooler kids club or maybe I just yeah, like it's like it's a claim to fame. So yeah, those are those are the three places I am on blue sky. Same thing. I think I'm at Sterling Chinn at on blue sky, but I don't really post there as much. Brittany Ellich (39:02) You made it. Yeah. It's better. Sterling Chin (39:18) I, well, I like it, but the problem is like the whole dev community is still on Twitter. And I go in, that's the hard part is like, I, I'm trying to disconnect from it, but yet I'm lucky because at least my Twitter is not full of the cesspool that has been Twitter for so long. It's like, only follow certain people. I've really highly curated it, but again, I like blue sky. I really want blue sky to win. Brittany Ellich (39:23) Yeah. Mm-hmm. Sterling Chin (39:44) And then, yeah, I do have a YouTube channel. I don't do much with it. ⁓ I should probably do more, but it's there. Brittany Ellich (39:51) It's a lot of things that you've already got going on, so I get it. Sterling Chin (39:53) Yeah. But yeah, sterlingchin.com guaranteed. You're going to see where I'm speaking. If I'm at a conference, you'll see all my speaker notes. You'll get all of my LinkedIn. I'm also on Substack. That's the other place. I forgot to mention that. Substack. Same thing. Sterling Chin on Substack. You'll find me. It's nice being the only Sterling Chin in the world that I'm aware of. Brittany Ellich (40:05) okay. Yeah. ⁓ that's nice. Excellent. Yes. Well, make sure all of those links are in the show notes. And thank you so much for joining us. And listeners, thank you for tuning in to Overcommitted. If you like what you hear, please do follow, 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, and Sterling so that he can feel like the developer community is there for him there. And share with your friends. Until next week. Goodbye. Sterling Chin (40:42) See ya. --- ## Episode 61: AI Code Quality: The New Software Engineering Bottleneck - URL: https://overcommitted.dev/ai-code-quality-the-new-software-engineering-bottleneck - Published: 2026-05-26 - Audio: https://anchor.fm/s/102586d64/podcast/play/120369167/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-4-26%2F424937735-44100-2-d7b2bad7e7564.mp3 ### Show notes AI is generating more code than ever, but most engineers aren't verifying it. Sonar Staff AI Researcher Joe Tyler shares breakthrough findings from his LLM Leaderboard research on code quality, the hidden "coding personalities" of different models, and why the real bottleneck in software engineering isn't writing code: it's securing and reviewing it. Discover the gap between developer distrust and actual verification practices, plus how to position yourself for the verification-first future of software development. Topics: AI code quality, LLM research, software engineering careers, code verification, developer tools Show links: * Sonar LLM Leaderboard: https://www.sonarsource.com/the-coding-personalities-of-leading-llms/leaderboard/ * Sonarqube: https://www.sonarsource.com/products/sonarqube * Sonarsweep: https://www.sonarsource.com/products/sonarsweep/ * Joe's LinkedIn: https://www.linkedin.com/in/joe-tyler-a668051b1/ * Latent Space: https://www.latent.space/ * Turing Post: https://www.turingpost.com/ * Nathan Lambert: https://substack.com/@natolambert * Cameron Wolfe: https://substack.com/@cwolferesearch * Sebastian Raschka: https://substack.com/@rasbt * Andrew Ng: https://www.andrewng.org/ ### Transcript Erika (00:01) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host today, Erica, and I'm joined by... Brittany Ellich (00:11) I'm Brittany Ellich Erika (00:13) We met while working on a team at GitHub and quickly realized we are obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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, we're joined by Joe Tyler, staff AI researcher at Sonar. the company behind SonarQube the tool used by over 7 million developers to analyze code quality and security. Joe works at the frontier of LLM research inside a product company, leveraging generative AI to revolutionize code quality and security. He's a specialist in LLMs with a background in natural language processing and real world AI applications. He's also a lead researcher behind Sonar's LLM leaderboard, which benchmarks models like GPT, Claude, Llama and others across thousands of real programming tasks. Welcome, Joe. Joe Tyler (01:17) Thanks for having me. Erika (01:19) Thank you so much for being here. To kick us off, we'll ask you the question we ask everybody. What's something you're currently building or learning that has you excited right now? Joe Tyler (01:31) Well, yeah, maybe we'll get into more detail on this later, but I'm doing some really fun research at the moment about how we can train AI models to be better at writing production-level code, which I find really interesting. And then maybe outside of my day-to-day job, ⁓ I'm learning Rust. yeah, been recommended by quite a few of my colleagues. Erika (01:57) on my list for sure, so I'm jealous that you're checking that off. That sounds fun. Cool. ⁓ Well, Joe, so you are leading research on Sonar's LLM Leaderboard, which is an ongoing, regularly updated independent analysis of how leading models perform on code quality, security, and maintainability. which goes beyond standard benchmarks and reveals each model's strengths, blind spots, and failure patterns. ⁓ A key finding of yours is that newer, more powerful models don't just make fewer mistakes, they actually make different and even more sophisticated ones. The 2026 State of Code Developer Survey, which surveys over a thousand developers globally, Joe Tyler (02:45) Yeah, that's right. Erika (02:55) found that AI now accounts for 42 % of committed code, yet 96 % of developers don't fully trust that output, and only 48 % verify it before shipping. So since you're actively working on this, it's a leaderboard, it's not a one-time study, can you walk us through what you're tracking, how it works, and what the most interesting findings are right now? Joe Tyler (03:22) Sure, so yeah, maybe zooming out. So Sonar is like the industry standard. Our tool SonarQube is industry standard for like automated code review. And then over the last year within our research team, we've been looking at trying to understand how LLMs write code, what are the shortfalls when they write code, and then also how we can ⁓ use our tools within the model training cycle to improve their quality of code. This study first came out of one of these research projects where we thought, let's just, we've made a benchmark, let's try and run it on some leading models. We found big differences between different models. We found, for example, that think GPT-40 was the best model, one of the leading models at the time, and we found that ⁓ suffered ... a lot more in terms of security of the code it was writing, ⁓ and more bugs, whereas Anthropix, Claude 3.7 at the time, was writing ⁓ more maintainable code. We thought it was interesting, even though GPT-4 might have beaten it on some functional benchmarks. was ... writing more complex code, which might have ⁓ impacts if you're using that model down the line. We have now built this out into a leaderboard, which you can find on our website. We recently hit ⁓ over 50 different models being evaluated on there. We have expanded just from the leading ClosedProviders to include loads of ⁓ open models. Really exciting ⁓ coming out of China right now. ⁓ GLM5 is really a top performer for us in terms of ⁓ different code quality issues. Brittany Ellich (05:17) That's really interesting. I wouldn't think that there were like common mistakes. Sorry, I'm going to ask a lot of dumb questions probably because I use a lot of LLMs, but I don't clearly don't understand them fully. But I think it's very interesting that there are like common mistakes that they each different model makes like once where is it security or versus the other. That's not a thing that I would have thought existed. That's interesting. Joe Tyler (05:24) Yeah, I mean, every lab must train their models in their own ways and optimize for different things. yeah, we found this in our benchmarks. We have a fixed set of over 4,000 real-world ⁓ coding examples that we give to all of the models. ⁓ And yeah, by averaging across their performance on all these tasks, we get a pretty good estimate of how complex their code tends to be, how many lines of code they tend to write. ⁓ One trend recently, we saw that the latest Claude Opus 4.6 model, it improved marginally on the functionality, but it also... was writing about 15 % of its lines that it was writing were comments, which is lot of wasted tokens, a lot of cost for the end user. Erika (06:41) Yeah, so what are your considerations when you're doing this research? ⁓ Like, I mean, some things that kind of come to mind are ⁓ the, like the things that you talk about have some level of objectivity and some level of subjectivity, like maintainability. There is definitely a gold standard, but then within that, there's things that people appreciate more or less. Like you mentioned comments and some people are anti-comment or, you know, comment everything and then a lot of people fall kind of somewhere in between. So how do you kind of like take the human aspect of it or yeah, consider all the factors. Joe Tyler (07:22) Yeah, comments was an observation that we made. The usual way we measure our maintainability is in terms of the number of code smells we see from each model. And also, we look at the cyclomatic and cognitive complexity ⁓ of the code that gets generated. So we see, yeah, we've seen Opus, Claude, and so Claude's Opus models and Claude's Sonnet models, ⁓ they average about 120 ⁓ average cognitive complexity per, I think per 1,000 lines of code. I think that's right. And then that compares to Gemini 3 and 3.1 at around 160. And those are both less than the GPT. level GPT's models ranging from 5.1 up to 5.4, which are all around 180. This is an observation we noted when these models were dropping at the start of this year. We were trying to explain why developers were really clicking with the Claude models. One way we read into that is that they're writing nice, maintainable code that's easy to comprehend, and it makes them easier to work with. Erika (08:38) Yeah, it's funny, it almost reminds me of like the co-workers that you gravitate towards like, I want to pair program with this person because I like the way that they write code versus like, no, I'm not going to write with them. Like they're trying to, they're trying to code golf everything. And like, I don't, I don't really want to do that. So, Joe Tyler (08:57) Yeah, exactly. think also there's some, it's not one of our papers, but a paper I read recently out of Carnegie Mellon, titled something like Speed at the Cost of Quality, where they looked at teams that had adopted cursor and then their immediate productivity boosts and then longer term productivity slowdown. If they're not aware of the ⁓ complexity and maybe maintainability issues that these AI models are... ⁓ introducing, even though you're going to get short-term benefits, you might face bigger issues down the line. So that's definitely an area of serious interest for us as well. Erika (09:39) Yeah. And do you only look at text prompts to code or do you look at any sort of iterative cycles and like improvements on itself? ⁓ Joe Tyler (09:51) Yeah, so these benchmarks considered so far are like code generation tasks. So that'll be like of like greenfield coding where you're asking a model to develop a feature. We also have benchmarks we've looked out for code remediation, but those aren't featured on the public leaderboard yet. But that will be... where a model or an agent is looking at a piece of code, there's an issue with it and it has to find a fix. Erika (10:25) Do you have any sort of discourse with ⁓ the creators of the models themselves? Do you have any insight into why these things are the way that they are or their take on these sort of personalities that you found? Or have you kind of stayed away from that? Joe Tyler (10:47) We haven't had that sort of conversation with them, but I think we've spoken to lots of different people who are interested in the results of these benchmarks. It's interesting that there are these clear trends like the complexity that I brought up earlier. That the lowest complexity models have been have been anthropics models for the last two generations and GPT 5.4 is around the same. There must be some. Yeah, something going on with how they're training their models, that they maintain these sort of patterns. Erika (11:24) Yeah, I mean, it's interesting to me too, because you, like I mentioned, like, pair programming earlier. And I think of like, even if you don't want to write code the same way as somebody else, you can still learn from everybody's styles and even learn like what not to do. But sort of that awareness is helpful. And kind of knowing like, These are the trade-offs, these are the pros and cons about this kind of implementation approach versus this other one. ⁓ So yeah, it's a very cool resource to be able to compare all those different styles and ⁓ to your point, Brittany, know kind of more of what you're getting, not ⁓ blindly kind of working through these things. Joe Tyler (12:23) Yeah, I think another trend overall from these models is we've seen, I think out of our top 20 on the leaderboard right now, 19 of them, 19 of the most verbose, so they're writing the most code, most lines have come out in the last six months. So think there's a real trend towards these models writing more code. Maybe that might be better. They might, if they're some like... GPT have definitely made improvements in their complexity, so they're writing more modular code than before. But overall, these models are writing ⁓ more lines of code and burning more tokens while achieving better functional performance. Erika (13:07) Yeah. So we sort of teased a little bit earlier that newer models don't necessarily equal better code. So talk us through some of the things that you found there, ⁓ what the changes have been over time. Joe Tyler (13:23) Yeah, so we've always seen GPT-5 models. Since October last year, there's been different more updates to those models. ⁓ And we see that even though the number of bugs they're writing is reducing, it's also shifting. So we're seeing ⁓ more bugs with concurrency issues. Maybe these models are trying to write with more advanced patterns, and therefore you're introducing more subtle bugs that ⁓ are harder for an AI-driven analyzer to detect. But with our ⁓ static tools, you're able to detect those sort of subtle issues. Erika (14:17) Good to know. It also maybe shows that it's learning on itself. ⁓ It's growing as a developer. But day one, you're not writing concurrency bugs because you're writing multi-threaded code. And in your mind, what do ⁓ these archetypes like Claude as the senior architect or Joe Tyler (14:32) Yeah. Erika (14:46) GPT is this efficient generalist. What does that mean in practice for developers? Joe Tyler (14:54) Yeah, so that was a report when we first published our research to try and make things a bit more tangible in the minds of technical and non-technical readers. we were seeing that Claude, I guess it was Claude 3.7 or Claude 4 at the time, was writing the most well-structured code, the lowest complexity. And that made us label it as an efficient architect because... ⁓ it's going to lead to the fewest issues with your architecture as you use that model to code. ⁓ Whereas GPT-4.0 was ⁓ efficient generalist, it wasn't writing that many lines of code, and it had a pretty good functional performance, even if it wasn't quite at the level of Claude 4. Brittany Ellich (15:43) Interesting. Is that something that you take into account now? You said you're learning Rust like for your own code writing, or are you like abstaining from using LLMs while learning Rust or how's that? Joe Tyler (15:54) That's interesting, actually. ⁓ In my day-to-day coding, do use ⁓ coding tools. I mainly use Claude Code. ⁓ I use Cursor sometimes. But yeah, I think to teach myself a new language, I've taken the Rust documentation. I've used ⁓ an LLM to build some... sort of lessons, projects for me to work through. And then I turn the AI off and I try and just code. I think while you're learning the fundamentals, it's good to think for yourself. But yeah, now we're developing, like I mainly develop in Python. So much Python's getting written. I'm not writing that much of it myself, but it's because I know how it works. I'm able to ⁓ still do it. decent code review. Erika (16:56) It's valuable skill. Speaking of, let's talk a little bit about verification of code because you did a survey where you found that 96 % of developers don't fully trust AI output, but only 48 % actually verify it. So what do you think is going on there? And Brittany, you can kind of jump in here too with how you ⁓ how you tend to verify AI code. Are there instances where you don't have to verify it and what are kind of the trade-offs? Yeah, how do you both think about that? Joe Tyler (17:40) you want to jump in fast Brittany or should I can go Brittany Ellich (17:44) Yeah, I'm just reading that and I feel like developers are probably very skeptical in general. So I wonder if that's coming through in that 96 % number where they're like, well, I don't trust any of it. But you know, some of it I have a look at some of it I don't, but that's a terrifying number to see like 96 % don't trust it. then 48 % are still only actually looking at it based on like, where's that other like 40 %? What are they doing? Why are they not? Why are they not looking at it? ⁓ Yeah, curious, curious what you actually found about for sure. Joe Tyler (18:14) Yeah, I mean, think if you write some code on just like a project of yours and it runs, then you're happy and you push it. And I think that's why we were, that's why we built, like, designed this benchmark to go beyond just like the functional performance and looking at other aspects of the code. ⁓ Yeah, it is a ⁓ very low number of people that are actually verifying their code. there are, yeah, I have a... the sonar CLI tool that I use, and I have Claude Code call that when it's finished and also during the coding process to make sure that, yeah, I've not written some bug. And then on your point of, is it always right to verify the code, guess, ⁓ it's different use cases. Like, if you're quickly prototyping something, you might not need to verify as much, ⁓ especially if you're writing, if I'm just doing something quick for some research. But then when you're working on developing more production stuff, like more stuff that's maintained in your team, you want to make sure that you're not just writing your AIs and generating a 10,000 line pull request and ruining the architecture. Brittany Ellich (19:32) Yeah, I've heard a lot of people too talking, ⁓ and like some discourse about like, well, in the future, we're not even going to review code and like, that's going to solve the code review bottleneck. where do you land on that? Do you think that's like actually a likely future or is it still going to depend on like how important the code actually is? ⁓ Joe Tyler (19:50) ⁓ Well, I think these latest AIs do generate quite large pull requests, therefore, think having some sort of Definitely having a static review tool is good, and then even I've been using an AI code review tool to roughly talk you through the PR to begin with, and that's a useful starter. ⁓ Yeah, I don't think the answer is to get rid of review. think if you're not looking at the code, that's exactly when you need a verification layer. Erika (20:30) Yeah, it's always like going back to the kind of like personas and archetypes and perspectives to like, you do write code for different audiences, like you, you do have that like functional aspect of it, but then, you know, kind of need to consider like, what would a junior engineer think looking at this? What would a senior engineer look like think about looking at this? Like, there's, there is this question of perspective and audience. ⁓ And I mean, I guess you can give AI personas. ⁓ But yeah, there, I feel like there's, there's always gonna be some level of human element where that, where that falls in the spectrum of like action and agency, like, I don't know, but yeah, it's hard to imagine there not being any human in the loop. in the process, my mind. Joe Tyler (21:31) Yeah, think we'll probably, I think I look at code less when I'm, I if I've started just like coding in the terminal now, rather than using an IDE. And I think that's, feel like I'm only confident in doing that because I know that there's some sort of static tool checking that there's nothing like completely ridiculous going on behind the scenes. Erika (22:01) Well, cool. Well, thank you so much for walking us through all that. ⁓ It's really interesting work and we'll definitely link the leaderboard and the show notes for people to check out themselves. ⁓ We're going to transition a bit into ⁓ your story and your career. ⁓ And you transitioned from data science ⁓ to machine learning research in a relatively short amount of time. ⁓ So yeah, what actually made you want to make that switch and how did you learn what you needed to learn sort of along the way and ⁓ throughout that transition? Joe Tyler (22:46) Yeah, I didn't feel it was that large of a jump in the end actually because data science can be quite a broad term. Luckily, I was working in a really small, a nice, team ⁓ with some really good engineers. ⁓ Even though I was doing data science, I was still working with large language models. It's been scaled up massively. but the core underlying tech that I was using to train models for understanding legal language is the same as you use for coding. thought coding and legal language are vaguely similar problems in my head. It's sort of English, but not quite, and it can be quite hard to verify if... ⁓ if your solution is correct. We relied before we'd rely on a team of trained lawyers to help us verify that the model was giving good predictions. now, yeah, now we're, well, luckily we have coders that can look at our predictions, and also we have these coding benchmarks that we can rely on. Yeah, I think I've... From the start, working with large language models, I was really, really keen to understand the underlying tech as much as possible, and that really helped me. And working so closely with some really, really good engineers, having a great manager who pushed me to write good code, ⁓ made me more interested in coding, and that led me to want to pursue this career in... ⁓ AI for code generation Brittany Ellich (24:47) Was there anything that was different that you had to like shift your thinking of going from like legal text to, ⁓ to code? I love the idea too of like we hire like lawyers to be like coders basically for legal stuff. I've never thought about it that way. And I think that that's, that actually makes a lot of sense because they're like literally just there to interpret the thing. So yeah, that's Joe Tyler (25:08) Yeah, we had a big ⁓ data set from output of lawyers ⁓ that was very useful because looking at some of these clauses would be completely ⁓ incomprehensible. Brittany Ellich (25:23) Yeah. Yeah. Joe Tyler (25:25) ⁓ anything different i I would say, ⁓ Sonar has so many ⁓ expert engineers and managers. ⁓ The SonarQube product has 7,000, I think, many, 7 million developers worldwide that are using our, and so 7,000 enterprise clients. That sort of scale really appealed to me. ⁓ and it means that we have this interest in understanding how LLMs write code because it's important for our customers to know this and therefore I thought there'd be some really interesting projects to work on. Erika (26:19) Very cool. And for any engineers who want to shift into ⁓ understanding AI tools better instead of only using them ⁓ and maybe even help to shape them or shape the landscape, what advice would you give to them on what it takes to really engage with this area? Joe Tyler (26:48) ⁓ I'd say just get started, follow some good newsletters. ⁓ Latent Space is a really good one. ⁓ Turing Post as well. ⁓ There are some great substack writers that I follow like Nathan Lambert, Cameron Wolfe, Sebastian Raschka. ⁓ And yeah, and then of course there's ⁓ anything by Andrew Ong, it's definitely ⁓ worth a read. ⁓ I think it's a great time for a developer to take interest in AI. Our team is people with lots of different specializations in our team across cloud and ⁓ deep software engineering and AI research. It's been really... fun and productive everyone coming together with their different specialties. think if you have the problem-solving abilities that you have as a developer are fairly similar to what you need to understand AI research. Erika (28:10) Thank you all. Brittany Ellich (28:12) Yeah, I like that. I also, I recently was listening to a podcast talking about like the differences between like what DeepMind is working on versus OpenAI and how OpenAI has been like focusing on LLMs and ⁓ how that's like getting most of the love right now. But do think it's also worth learning more about like the deep and reinforcement learning that DeepMind and I'm sure other places are working on as well? Joe Tyler (28:35) Yeah, so on the model training side, we've ⁓ been doing some fun research over the last year and a half. And we've basically been taking open source models and training them on a pipeline that has SonarQube, our verification layer, baked into the data pipeline. And that's given us some... ⁓ interesting results. So we trained like a large llama model last year and we saw that when we trained it with our data pipeline, it's generated 67 % fewer vulnerabilities and 32 % fewer bugs. And we saw similar gains on GPT-4.0 as well. And then in December, we actually have released a fine-tuned version of GPT-OSS, is OpenAI's latest small model. There might be a new one coming soon, I think. We saw a reduction in the number of bugs and vulnerabilities by training with our method by 41%. So, % fewer bugs, 41 % fewer vulnerabilities. Also, we saw a 20 % reduction in the complexity of the code that it was writing. Yeah, this is real area of interest. This is what my work's on at the moment. It's a product called Sonar Sweep, we ⁓ are looking at customizing open models to ⁓ write really high-quality production-quality code and also understand an organization's own code base. Erika (30:37) Yeah, that was really interesting. it is so fascinating how different the results are with slight tweaks in input or even the place where you're running it, like running a prompt in a bare terminal versus in a repository using code context. Yeah, it can kind of make your head spin all the different. all the different possible inputs and how they might all interact with each other. So, yeah. Joe Tyler (31:13) Yeah, there's so many ⁓ code context tools on the market right now that tell you that they're going to make your agent understand your code base. We've just released ⁓ in Open Beta last week our own context tool, which makes use of ⁓ the static tree of your code base, and will guide the LLM to the right spot. ⁓ I don't have the exact benchmark numbers to hand, yeah, in our blog post, we've seen a reduction in the time it takes for an LLM to get to a response, or an agent to get to a response, and also a reduction in the cost, because you're burning fewer tokens by just being able to navigate to the relevant parts of your code base more quickly. Erika (32:10) Yeah. Well, we are going to transition to our fun segment here at the end. ⁓ And we always do some kind of ⁓ a game or round robin. And today we are playing exactly to your strengths of playing a guessing game where I'm going to show three snippets and ⁓ I'm not going to get to guess because I put this together, but you both get to guess which model. wrote the code. So the options are... Sorry, let me fold the window. Joe Tyler (32:52) Okay, good. was worried you were going to get us to guess from the list of 660 models. Erika (32:55) It's probably all, yeah, no. The options are Claude Sonnet 4, GBT 4.0, and Claude Sonnet 3.7. Okay, so I am willing to go ahead and show my screen here, and I'm gonna show all three, and then at the end, you can place your guesses of A, Are you ready? Okay, here we go. Okay, and so the prompt here is write a Python function that reads a file, processes each line, returns a count of lines matching a regex pattern. So here's snippet A, I'm showing my screen. ⁓ I'm just gonna kind of narrate what I see. It imports the ⁓ union. I'm not gonna say this right, because I don't know Python, but. ⁓ from typing import union, sets up a logger, then sets up this count matching line functions, which ⁓ has a chunky code comment at the top, ⁓ sets up the file path, ⁓ checks some errors, has a try block, accept, and then a debug statement at the end before returning the match count. So that is snippet A. SnippetBee is considerably shorter, has a one line comment, ⁓ imports the whole re package? Is it packages in Python? Joe Tyler (34:35) Yeah, it's a regex package, yeah. Erika (34:37) Okay, thank you. ⁓ It uses open and basically loops through the files to return account. And then snippet three ⁓ imports regex package, pathlib ⁓ and, ⁓ or path and union from the pathlib and typing packages. ⁓ And then also sets up a nice chunky comment, not quite as long. ⁓ has a nice ignore case check here at the top, compiles the regex, and then basically also does a loop before returning the match count. All right, oops. I think I might've revealed some of the answers too. Okay, good. You're just looking at the code. All right. ⁓ So are you ready to place your guesses, Joe and Brittany? Joe Tyler (35:23) I didn't see. think so. Erika (35:39) All right, as a reminder, was Sonnet37, Sonnet40, ⁓ and GPT40. All ⁓ right, so maybe Brittany, I'll have you put your guesses in first. Between A, B, and C, what do you think the model matching is? Brittany Ellich (35:40) Yeah. Sounds good. I think that my reliance on just using Opus for everything is gonna fight me here. But based on what Joe mentioned here, I listened, I paid attention, and you talked about how Sonnet and Opus use more comments. And so that's literally the only basis for my answer here. So I think that A is probably Sonnet 37. It seems like maybe it's like a little bit older than the C, which also had a lot of comments. And so I'm guessing that that one is... Erika (36:05) All Brittany Ellich (36:29) Sonnet 4 and then I'm guessing what B then, far fewer comments, is GPT 4.0. And very brute force too, I feel like. Just like going straight for the full Redgex package there. Erika (36:44) Alright, Joe, what do you think? Joe Tyler (36:46) Okay, that's interesting. ⁓ I'd agree with B. GPT-4.0, think. As I said, it hasn't really written comments, I hope that's right. ⁓ The snippet A has tried to do something more advanced there, maybe. It's written the logging pattern, which I don't think the last one did. it's handled its edge cases there, so maybe that's the more advanced model. So maybe I'd go for the Claude Sonnet for A, and therefore Claude Sonnet 3.7 for C. Erika (37:25) All right. All right. Time to reveal the answers. So snippet A with the sort of more advanced architecture is indeed Claude Sonnet A. Snippet B is indeed GPT-40. And snippet 3 is Claude Sonnet 37. So yeah. Brittany Ellich (37:50) Nice one, Joe. Clearly Joe Tyler (37:51) Okay, great, well yes. No, thanks for choosing such a good example. Brittany Ellich (37:53) you're the professional here. Erika (37:55) Like you do this for a living. You actually know what you're talking about. Awesome. Well, Joe, one last word to you. What do want engineers listening to this to take away from the work that you've been doing, ⁓ you and your team have been doing? Joe Tyler (38:01) Yeah. Here we go. ⁓ Yeah, I think you should definitely have a look at the leaderboard and I'd be interested to know if the findings in terms of the complexity and what different types of issues people see line up with what we've got. As I mentioned, we've got more advanced benchmarking coming out soon. We're updating the leaderboard. I know Google just released a new... batch of Open Models, the Gemini 4 series. We should imminently have the results of how they stack up, which I'm really excited for. ⁓ I tell developers to try always be an early adopter, try out these tools, and also try and find a way to benchmark them because there's so many, there's a lot of noise with different... know, MCP servers, CLI tools that everyone says is going to improve your agent, but you need to figure out, is this actually making me better? Is this making me spend more money? But yeah, it's an exciting time. These tools are coming on so fast, and yeah, I'm really enjoying developing at the moment and researching. Erika (39:33) them. Well, aside from the leaderboard, is there anywhere people can find you online? Joe Tyler (39:39) ⁓ Yeah, I'm on LinkedIn. I think I can send you my link for that. Yeah, that's probably the main place that I post about our work and different things I'm interested in. Erika (39:58) Cool. Well, thank you listeners so much for tuning in to Overcommitted. If you enjoyed this episode, please do follow and subscribe on whatever podcast app you use and find us on Blue Sky. Share it with an engineer friend who might appreciate it. Until next week, goodbye. --- ## Episode 60: Design Engineering, Interviews & Job Search | Career Growth with Adam Argyle - URL: https://overcommitted.dev/design-engineering-interviews-job-search-career-growth-with-adam-argyle - Published: 2026-05-19 - Audio: https://anchor.fm/s/102586d64/podcast/play/120224334/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-4-19%2F424465861-44100-2-6c8954206188c.mp3 ### Show notes Summary Software engineering career moves don't have to be a lottery. In this episode, Adam Argyle breaks down why the technical interview process is fundamentally broken, how design engineering skills actually transfer across roles, and the tactical job search playbook that works today. Whether you're navigating a career pivot, re-entering the market, or just frustrated with the hiring gauntlet, this conversation cuts through the noise on what really matters for career growth and staying sane. Links * Adam’s Website: https://nerdy.dev/ [https://nerdy.dev/]  * Adam’s CascadiaJS 2025 talk: https://www.youtube.com/watch?v=QW6GECIzvsw [https://www.youtube.com/watch?v=QW6GECIzvsw]  * 10 powerful ways to use CSS variables article: https://nerdy.dev/custom-prop-categories [https://nerdy.dev/custom-prop-categories]  * Sizzle Rizzle: https://nerdy.dev/sizzle-rizzle [https://nerdy.dev/sizzle-rizzle] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev ] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00.757) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host Brittany and I am joined by... Bethany (00:09.496) Hey, I'm Bethany Erika (00:11.054) and I'm Erika Brittany Ellich (00:12.971) The three of us met while working on a team at GitHub and realized we were all obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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 Adam Argyle, and I'm very excited about it. He spent seven years as a Chrome CSS developer advocate at Google. Co-hosted the CSS podcast with Una Kravitz, currently is a co-host of the Whiskey Web and Whatnot podcast, and has spent a lot of his tenure trying to convince the web development world successfully that CSS is worth taking seriously as a craft. His role was eliminated in 2025 at Google, unfortunately, and he navigated a months long job search before landing now at Shopify as a staff design engineer, which he has been very candid and public about. He's also been the kind of engineer who builds a 30 demo scroll driven animations notebook at bedtime just for fun. Welcome Adam. Adam Argyle (01:20.851) Thank you so much, great intro, excited to be here, and nice to meet y'all. Brittany Ellich (01:25.685) Yeah, great to see you again. To kick us off, what is one thing you're currently building or obsessed with learning right now? Adam Argyle (01:34.033) Yes, I am currently building a, well, I have a color picker. It's a web component that allows you to pick, you won't be surprised, any CSS color. So all of the CSS color spaces and it kind of tries to make this humongous concept of HDR and HD and all these color spaces easy-ish. So it bundles it all into this very familiar feeling color picker that gently helps you pick HDR colors and it outputs I think the most sane amount of syntax. So it optimizes for like percentages. So instead of you learning that OKLCH Chroma goes from 0.0 to 0.35 and maybe to 0.5, which designers are already like, why are you making me do decimals? It uses percentages and goes from 0 to 100%. So you can be like, I do, I want 100 % Chroma. Just give me all the Chroma. And so I'm like, I will make the design tool, I'll make this tool for you so that it's easy to use. And I just announced v0.4. The other day I did an RFC and people just loved it and didn't have any complaints and so I released it and now I'm currently trying to get it into Figma which they can render web components in their little iframes and so soon y'all I even have a working version I was working on it right before this a Figma plugin so that you can choose HDR colors that are CSS compatible in Figma. Brittany Ellich (03:00.427) That's incredibly cool. Very neat. So it seems like you're like kind of into CSS a bit, right? That's like. Adam Argyle (03:10.129) Little bit, little bit. Yeah, it was funny. Everyone at work all the time was just like, it's easy. Just give it to the juniors. And I was always like, uh-uh, I'm gonna sit here and I'm gonna make sure it's done right. here, yeah, you'll keep carrying on. Like it's easy and it's child's play. Just go ahead, you know, whatever. I'll be over here in the front end just making sure it all looks beautiful and owning it. And I just, and I loved having something that was visual to work with. So I just haven't let it go. And it's only gotten more complex. and more respected, which is nice. It used to be just poo-pooed on all the time and I was just, didn't care. I was like, whatever, I know I'm right. You're wrong. Brittany Ellich (03:45.27) Yeah, no, that's totally valid. is, it's really somewhat, I guess, easy to do. I don't think you can even say that anymore, but like, it's really hard to do well. And there's so much to know, very easy to get it wrong. So. Erika (03:46.476) Yeah. Erika (04:01.78) Yeah. I mean, yeah, I feel like it's an extension of design and people will say that design is easy until they try to do it. And it's the same with CSS. You think it's easy until you really try to do something well and like maybe one or two things. Sure. But then when you get to like actually putting together a whole design and putting, you know, implementing something at scale, it does take It takes architectural skills, takes deep technical knowledge, it takes an eye for when something looks right or when it's broken. Yeah, so definitely have experienced the underestimation of what it takes in myself and also from other engineers as well. Adam Argyle (04:53.52) Yeah, I say it's the easiest to get started, the hardest to master. It's subjective, which means LLMs suck at it. They're like, I did it. And you're like, did you? You don't even know what you did. All you did was make a sentence. And then you're like, I did the CSS thing. And you're like, no, you didn't. And it gets even harder. Like, you know Scott Pilgrim and you've got to fight all the evil exes. It's kind of like with CSS where you're like, all right, my layout works. Brittany Ellich (05:04.129) Mm-hmm. Adam Argyle (05:20.184) I beat the boss and then the, you know, the next boss shows up. yeah, just, which is a work in Safari. You're like, there's another X. Damn. Okay. And then it's like, there's another X. And then someone shows up with screen readers and they're like, guess what? There's actually seven screen readers that you need to support. got mobile ones and desktop ones. So you might've beaten the four bosses, you know, Chrome, Safari, Firefox, and somebody else, but it doesn't matter. There's seven more. And you're just like getting, and you have language translations. You have different viewports. All of this stuff just adds to the complexity. And that's what a lot of people get wrong when they do CSS is they get started with color red. They're like, yeah, I control the universe of this painting space. This canvas is mine. And then later they're like, wait, users have input on what happens in here? Their font size preference needs to do. I need to respect their motion. Like, my goodness, I thought I could just define the whole world. And then you just realize you're not in control, which developers hate. Developers love their control, they want their rust. Give me rust. And it's like, CSS is the opposite. You pretty much have no control. You have two choices, which is try to grab all the control and fail miserably, or relinquish control and write CSS defensively and with a system and with a way that you of corral the sheep. Never assume you know how many sheep are in the pen, never assume how big the sheep are, and assume there might be a sheep that's quite rowdy. And now you're ready to write CSS. Brittany Ellich (06:44.673) That is an incredible framing. I love that so much. What was the initial thing that got you into going so deep into the world of learning and mastering CSS? Was there anything in particular that occurred? Erika (06:45.43) Okay. Adam Argyle (07:01.764) Yeah, I was in a computer science college. was taking SQL and PHP, Java. So I was writing these Java applets. And then eventually we got to Flash. And even in PHP, I noticed something really quick was pretty much everybody in all my classes were really happy if the console printed the result. know? Hey, what's seven plus seven? 14. It did it, everybody! my program works and they were just so happy it worked. And then I was like, yeah, but it looks really dumb. You know, it looks bad. And I was like, and I cared. And so mine would look better than other people's and then be like, why'd you do the extra part that did the sizing? And I'd be like, cause it looks better. Why are you being so judgmental about my version you turd? Anyway, so then we got to Flash and we got to Flash and I'm a video game player. Brittany Ellich (07:37.697) You Adam Argyle (07:54.995) And you know, and I love animations and I remember specifically in Rock Band, you hover over one of the buttons and like 50 little rock hands would pop up from the bottom and just kind of like spring in and float. And they all had like a different scale and a different, I was like, that's cool, staggered animation, rock fingers. And so I did that in Flash in one of my classes. My button looked rad and I was the only one. I looked around the entire room. I was the only one that added animation. did something like meaningfully visual. visual and cool with my code. And I went, I'm in the wrong place. I am in the wrong place. I need to go somewhere else. And so I finished my two year computer science degree and went to Art Institute of Seattle and studied design. And I skipped out of all the coding classes. I was too advanced for that. And started taking design courses, motion graphics, 3D rendering, lighting, concept art, typography. I traced, I traced letter forms on really big pieces of paper and I loved it. All the while while I was there, I got a job at an agency building apps for early iPads, iPhones, web apps and stuff like that. And so I just immediately was like, I like both. I really liked to code. I really liked design. I really love learning from the designers on the job because they create things that I couldn't imagine, but then I finished them, you know, and then I learned intimately how to do a good design because I wasn't just moving pixels on a canvas, changing border radiuses and not using tokens. I needed to make a system. and I needed to make a system that had consistency and I would feel inconsistencies where Figma never really made you feel them or it wasn't Figma back then. But anyway, and so that was kind of how I got into this space and people started to rely on me to be the one that actually did the good front end work because so many other people made franken turds. You you'd have the beautiful design and you'd give it to the dev team and they'd be like, we built it. And you're like, that is not the same. There is a lot of things different. from that one to this one. so mine always looked good and I took pride in it. In fact, I would add things because back then there's static images. I would add animations. I'd always add hover effects, focus effects. I cared. So that's the origin story. Brittany Ellich (10:06.901) I love that. And you're currently a design engineer, correct? And you were a developer advocate at Google. Is that right? Or? Adam Argyle (10:15.57) Yeah, at Google my first year was on the design system team of Google Cloud. I was a UX engineer there for a year and I was building a design tool to empower the design teams, managing the design system, building components, et cetera. And then all before that, I've been building apps since like 2000 something. So I'm very savvy and just like building. And I've been a creative director. I've had many, roles, but generally I preferred coding because People were always like, you can code? I bow to code. And then if you were a designer, you'd be like, I can make designs. And they were like, I don't like that blue. And I'd be like, OK, I don't like this role. I like the role where people think everything I output is great and not the role where everybody has an opinion and it's rude. So I pursued the coding one. And so yeah, now I'm at Shopify working on Admin, which is very similar to Google Cloud. A lot of the same problems. you know, there's just tons of people writing code all day. You've got a design system. You need them to use it. You need a reliable design system. anyway, all those sorts of things. So that's what I'm doing at Shopify now. Yeah. Erika (11:23.298) I'm curious, like you kind of mentioned a couple times, like the, well, you mentioned the handoff between the design team and the engineers and that maybe not always going well. And I guess with your experience in developer advocacy and in all these various roles, how do you think about educating engineers in these design systems and like getting them up to speed on what skills are required to implement these designs well. Adam Argyle (11:57.776) Yes, yeah, reversing it where it's, yeah, need developers to care about the quality that comes out. And they don't have very many good testing tools. So like one of the first things I noticed resonated with developers specifically was the do's and don'ts. You know, they'd pull up the design system, look at a component, I need to use this accordion. And then they'd be like, I can't use it that way because that's almost always what they're gonna do, right? They're like, I'm gonna use an accordion in this part of the UI. And then they'd. go check the don'ts it's like don't use an accordion in this particular case and they'd be like why you know and you'd be like well that's because it would be a bad decision and we want you to not do that so the do's and don'ts are really good it's very binary for them because it is quite subjective and i think that's what a lot of people don't like thinking about is well users they they like servers with the game compilers because they're binary they're yes no and so they know when they're doing good and they know when they're doing bad And that's why I think a do and a don't speaks well to them, just like TDD. They know when their component is done because it's all green check marks. There's no red. So as long as you can. So that's a good step forward. We used to run like, I did these all the time at Google because the developers there weren't, there's no magical human out there. There's like world class at everything. And so we would sit, I would sit down with teams and either intake from them and hear their complaints about what features weren't available on the platform. And that was a lot of the Chrome work. But I'd also educate all the time. Like, hey, I saw that you wrote height 333 pixels. That's a red flag. And they're like, why? What's wrong with height 33? And I'm like, well, here we go. First off, you should probably, you might want min height because whenever you set a height explicitly. you're gonna run into clipping issues, which is one of the things that people always tease CSS about. CSS is busting out the box. And I'm like, that's because the turd told the box to be 50 pixels wide and put a humongous letter of text in there. You know, it's not CSS, it's fault. It's the developers. And so then I'd be like, also consider alternative units. Also, 333 pixels, that's what we call a magic number. And those are not good in your code base. You're not gonna be able to explain why. You're like, why'd you pick it? Adam Argyle (14:11.555) It looked good. That's not a good enough answer. You need to have a good answer about your units and what you're choosing. So there'd be a lot of educational pieces here about how to build reliable systems. You had to kind of use the verbiage that they want, which is you can't break it, right? So it's resilient. It's adaptive and flexible. Just kind of like speak into the things that... orient around their code that they like to write, but make it also about the CSS in the front end. Like these things need to exhibit the same behaviors that have your backend, like all your TypeScript. You like your tight TypeScript. You should like tight CSS. It has the same fulfilling properties to you as a developer. You just have a mental block about why one is better than the other or whatever, and you need to get over it. So I usually was a little blunt with people about it because, well, they came to me and they're like, I heard you're good at this and I'd like some help. I'm like, cool, I'm going to tell you what it takes. Maybe you won't like it, but it's okay. You'll live through it just like you lived through learning Rust. That was way harder or maybe not. Anyway, I'm going to tease Rust a lot, guess, today, Rust is great. Brittany Ellich (15:18.817) Rust can take it, I think. There's enough people out there supporting Rust that it can take a little bit of teasing. So you spent quite a bit of time at Google then translating new CSS features for people to use. And now you're back at Shopify building with those features, I'm assuming, that you had been translating. Has your opinion on building changed at all, having had that experience of building for a browser, and now to? Adam Argyle (15:22.907) Yeah. Brittany Ellich (15:47.413) like actually like leveraging those features again. Adam Argyle (15:51.058) I wouldn't say change because I came from building intense applications like really big, you know, corporate applications before going to Chrome. Chrome and being on the web standards teams, you definitely start to get some tunnel vision at the, you don't live in the same reality as enterprise software. Enterprise software has, you know, like Shopify, for example, has, we have people with a POS device that's an old iPad and that old iPad, they're not going to update it. So the app needs to work on a pretty old version of Safari on an old iPad. That drastically limits all of the cool stuff you can use. And progressive enhancement tends to scare a lot of developers and project managers because no one wants to hear that you're going to do a code fork and that you're going to manage two versions of the component now. We're going to have one that does the traditional way and one that uses the new CSS way. And they go, no, that is combatorial explosion. which we do not want. We already have combinatorial explosion, Adam. We don't want more of it. So progressive enhancement or graceful degreed, these things don't tend to exist in enterprise software because it's hard enough getting new features out the door, let alone building it for two different strategies. So a little bit of like what I've, I guess what's changed and shifted is so yeah, I went from building things a lot with JavaScript into being it. Google where I built almost everything with CSS and tried to get as far as I could in a very declarative fashion with very little JavaScript. And I'm back in a very JavaScript heavy scenario again. However, I still find that knowing CSS not only gives you a leg up in terms of like the quality of your output and the resiliency of stuff like that, but you get things done faster and with a lot more confidence and with just a lot more attention to detail and quality. So knowing CSS is... And even now with LLMs especially, so Shopify is very, very AI centric and LLM driven and LLMs suck at layout. They suck at interactions. They suck at animations. They suck at almost all of CSS. And so it's really meaningful for me to have that skill right now because I go in there and I correct it all the time. And I can't just prompt it to correct it because it'll just spin its wheels. You know, I reach my hands in there and I still code manually a little bit, you know, old school. Brittany Ellich (18:12.565) Whoa, what a flex these days. How do you recommend then, like if LLMs aren't necessarily the most reliable for CSS and that's the new way everybody's learning everything, like how do you recommend people go learn it as deeply as, know, well, probably not as deeply as you've learned it because that would take a very, very long time, but at least getting closer to like a very good understanding of CSS given that. Adam Argyle (18:16.177) You Brittany Ellich (18:40.459) you probably don't necessarily want to rely on what an alum is saying about it. Adam Argyle (18:45.327) Yeah, that's gonna play into your learning style. I know my learning style is hands-on. I could read a book all day on how to learn a new thing, and then I go try the new thing, and I'm like, well, all that reading didn't really do good, because I suck at this thing really bad right now. You know, like, I've been playing banjo or a lot of instruments, and you can go watch YouTube videos, and they're like, here's the technique. It's quite simple. You do blah, blah, blah, blah, blah, and you're like, that looks pretty simple. I'm like, okay, let me go try it. I'm like, clink, clink, clink, clink, clink. I'm like, great. I'm gonna need to put in some time. So you just gotta put your time in, there's reps with it. Just like with JavaScript, the first time you wrote the word function and open parenthesis and close parenthesis and then you opened up a curly bracket and then a closed curly bracket, hit enter, you formatted it. Like that was so foreign to you when you first started. CSS feels like that for people too. And I would just say, saturate yourself in it. Have an open mind. A learning mentality is really just gonna be what gets you that really far is be willing to kind of be bad at it, willing to learn and ask LLMs, LLMs can... give you good tips, they just don't always implement it great. Ask it for options. Ask for more modern variants of these things. So that's another thing. LLMs like to give you high probability answers. And you can be like, I want the modern CSS version of this. And it would be like, well here, that sets it down a different answer path, at which point it might respond with the line height unit instead of a pixel value, or at starting style for the way that an animation can introduce itself into the page instead of JavaScript. And so yeah, it's a acquire the language. So a lot of with LLMs, you need to have the words. And this was my talk at Cascadia last year was I'm trying to give all these JavaScript and AI developers the vocabulary to ask for the new way of doing things or just a modern way of doing things and a more resilient way of doing things with CSS. But if you don't know what to ask for, you'll never ask for it. LLMs are just going to keep giving you tailwind unless you ask for something else. And so. It's just deliberate effort. There are people you can follow, so maybe they're sharing tips. You can take courses. There's courses by a couple folks that are really great. Whatever your learning style is, I would just say if you want to get good at it, I'm always going to tell you, fingers tippy tap on the keyboard. Find a design that you like and recreate it from scratch. And you'll learn a whole bunch every time you do it. I still learn that. I just failed at March Mad CSS with a Adam Argyle (21:12.376) on the Syntax show. There's like a, I just missed a dom node, you know, and I'm in there, I'm like, crap, I gotta write CSS grid really fast right now. It's like, okay, good thing I write grid all the time, because otherwise this would be really annoying. Anyway, that was a long answer for, I think just practice and an open mind. Erika (21:31.799) Yeah, I mean, there's so many variants, I guess, on top of vanilla CSS that I feel like for me, when I'm doing front end, so much of it is dependent on the context and the libraries being used. Are we using variables? Are we using a component library? All those different things. And you have to understand how all the pieces fit together in order to know where to look. for the answer you're looking for. Like if you need to use a view component or some kind of like pre-built library component, then you have to know to look there and you have to know how to test it. yeah, so I mean, to your point, like there's more than the CSS itself that goes into the development of front end and yeah, the quick fix of prompting the LLM to give you the answer probably won't work in most cases. Unless, I mean, maybe if you give it all of that context and like give it the full library and all that, maybe it's more helpful, but yeah. Brittany Ellich (22:57.545) Yeah, that's assuming you're using the same library that you've used the entire time in that code base, which almost never happens because you're always in some sort of weird mix of like, we used to use this and now we're using this now. And yeah, that it gets really complicated. And I kind of love the fact that some of these areas of development that traditionally were seen as like, like that's not as important. That's just the front end are now actually one of the things that AI agents are probably going to be last to be able to replace. And that knowledge is actually very helpful because they're really hard to do well. Like accessibility, it's so hard to do it well. And all of the LLMs have been trained on such inaccessible code that now actually that accessibility skill is incredibly important. And knowing how to do that is incredibly important. And I love that. It's like a, I don't know. I think that's fun. So do you land then? Adam Argyle (23:52.78) It's, it's for people. Brittany Ellich (23:54.4) Yeah, it's for people. It's for people. The stuff that is for people, you still need a person to do that thing. And I don't think that that's going to go away anytime soon. So if somebody is like, hey, I need to AI-proof my career, I feel like these front-end skills like CSS and accessibility and stuff, those are really great to invest in right now, I think. Do you agree with that? is that? Yeah. Yeah. Adam Argyle (24:16.624) I hope they stick around. I don't know, I'm scared. Because I have it make really beautiful pages all the time. And to a lot of people, that's way more than just acceptable. know, it's like, to them, it's exemplary. It definitely gets different in a really big application scenario. So it's like it can make a one-pager really cool from like five paragraphs. So you're like, here's five paragraphs. Make me a really flashy website. And it goes, boop, boop, boop. And it's awesome. And then you're like, OK, I have an app and I want to just move this one thing over here. And it goes, all right, I did it. And you're like, no, you didn't. Hey, you lied to me. know, like, I didn't know you could lie. And it's like, I can't see. So how could I know? And it's like, it doesn't have a browser. It can just assume that that was the result. But I don't know. Some of these things are getting really good so fast that maybe we won't. Maybe we will be agent orchestrators and not. Brittany Ellich (24:52.897) you Adam Argyle (25:13.296) Brick layers anymore, you know, so I know a lot about how to put bricks down which makes me good at orchestrating agents that place bricks But my job my job feels like it's changing a lot all the time like every month I feel like it's shifting less from craft more towards my domain expertise making me empowered in an LLM space and we'll see how long that lasts I don't know maybe there's a an end to this or it's just maybe we're at the beginning. Some people are like, we're at 0.1 % of AI's potential future. And I'm like, dang, we got a lot to go. And then other times I'm like, I don't know, maybe these models are gonna max out. Maybe we're at 90 % the capability of just the word vomit machine, because that's all it does. Next word is most likely this. This is the, it's not intelligent. It's just an autocomplete. It's a really, really fancy autocomplete. And so maybe that has a cap. or maybe all these agent harnesses and the AI things that we put around the word machine continues to make it look like it's really smart. And those give, I don't know. Anyway, I'm confused. Hopeful, but also not hopeful. I'm like, I liked my job. I liked being a crafter. And that's why I still have side projects like the color input, like that uses web components and signals. You you don't, not going to get that from an LLM. Anyway. Brittany Ellich (26:34.123) Yeah, yeah, it's a weird time. Erika (26:38.094) And like that human element too is never something that can be replaced. Like I have had the experience on the internet of going to a website where it's clearly like a work of art or something that somebody really cares about where they have crafted an experience for you and then built it versus sort of a website where it's clear that it's pretty like cut and dry or you know, it's there. and kind of generic. And yeah, I mean, I think those sites will always exist that people who care enough will build them. But yeah, I I don't even know if it's changed necessarily from a corporate perspective, how much they care, unless they can monetize that experience in one way versus another. It's probably a little naive to say that. big corporations have ever really cared about design from a deep human empathy perspective. yeah, I definitely care. And yeah, I think it matters a lot. Adam Argyle (27:55.012) Yeah, noticing those details reminds me of factories versus handmade goods. Like when you have a handmade good, the flaws of the human are visible and present, or they're not. And you're like, holy, you did an amazing job on this, you know? And then other times you see a factory one and you're like, I see the mold seams. Wow, you made this nice and quick. That feels like plastic. You know, that's not natural. But what we have right now with AI is like a race to make the next factory that builds apps. And you're still gonna have people that make apps by hand and they're gonna feel like that and they're always gonna be more unique, just like homes. There's a race to make the next template home and you see a thousand of them on a strip of roads and you're like, that's not great, but somebody needed money or whatever and like they found an efficient way to make homes, good for them. But I'm always gonna be the one that's like, where's the crafts home? know, where's the home that the most dangerous home on the most dangerous locations? I'm like, yeah, that sounds great. So yeah, we're always gonna have the pendulum there to swing. People are always gonna be trying to make the fastest, cheapest version. And I'm stuck in the middle trying to do both, I guess. And that's why it gets so awkward. Brittany Ellich (29:06.815) Yeah, try to keep a job basically for until you we need to retire. I feel like, you know, yeah. switching gears a little bit, I, you recently went through a, an interview process and we have heard a lot about the frat processes right now. I'm curious, how, how did it go for you? Like how was looking for a job, especially considering you aren't quite overcommitted, if you will say, I mean, you have done so much. Adam Argyle (29:13.72) Yep. Brittany Ellich (29:36.449) publicly available, like publicly visible within your career, know, podcasts and side projects and everything. Like, do you think that helped you at all? Do you think it made it more difficult in some ways or like how was finding a job for you? Adam Argyle (29:50.392) Yeah, it was both. And I chatted on a couple podcasts talking about it, like when it was really fresh. And the kind of recap is a lot of times I would apply somewhere and they'd be like, we see your history, CSS. Do you do anything else? And I'm like, you didn't read very far, did you? Okay, well, yes, I can. I can do a whole bunch of other things. So if you want, I can show you. And I got so tired of like, no one read a resume. They just didn't. Even though I put a lot of work into it. I even made a website resume I think you can still go to it, but it had scroll driven animations. You could print it It had print styles, you know, like I even had Web GL shaders on it at one point so I was like people need to be wowed at my resume So they'll go there and see sparkles, you know It's got sparkles and it's wavy or whatever it was I did on there But I eventually took it off because it performed like crap on your phone. You'd be scrolling it on your phone. I'm just like that's garbage But eventually what really resonated is I just had to sit down. I've done so many interviews myself interviewing other people. And I know that I will, and I'm a weirdo. I always read the resumes, but I know that like a lot of people don't have much time to review you and they want to understand you in an elevator pitch. And it makes sense. We're all very busy. So you need to like not just have a resume and not just, think also having a website, my website nerdy.dev speaks a lot for me because that is a integrated social network feeling application. that immediately proves to someone that, well, A, this is no template, never seen anything like this before. B, there's server-side rendering and data communication happening with outside services. Like you can just see and feel right off the bat that when there's cache, I've just, I've got it all on there. And it's nice, it feels nice. It's got shadows and stuff. But I made what was, what I called my sizzle reel. And this went through a lot of my past projects, a lot of my very visual. And it also, I oriented my sizzle reel towards the job I wanted, which was I wanted to be a design engineer somewhere. wanted to take my ability to code and my ability to execute high fidelity and sell that as my, thing I would bring to your company. And so I made a sizzle reel that did just that. And usually people, and it's a three minute reel of animations to music and they're Adam Argyle (32:02.831) You know, it's quick cuts and all this stuff. Cause I'm just like, look, people just are not patient. They're so used to tick tock. don't even tick tock, but I'm like, I watch enough TV to know that the attention span of humanity is going way down. So I'm going to just oriented towards that. And so it's punchy. It's flashy. It was in your face. could barely even tell what's happening in some of the animations. And you're just sitting there like, this is all hitting me so fast. that boom instantly I got on top of lists right away because you could send that to a boss. and bypass the entire situation. It was a URL. Go to this URL. Watch this video. we need that here. We don't have anyone that does. Bring them in. So that was one of my biggest tips is you do still need a resume. Definitely have a site. Make something that's very quick and easy to consume that encapsulates, which is so hard to do. Let's just be honest, too. It's hard enough to even write a paragraph about yourself, let alone make a minute long video about all your sizzled stuff. But anyway, just get it done and I found that to be a modern way to kind of bypass a lot of the junk, communicate with people in a way that tailored to their patience levels that they were at. And yeah, yeah, make a sizzle, I called it sizzle, rizzle because I'm a, I just like, I'm a dork. So, and I could, I was like, I don't work at Google anymore. I can, I could say what I, that's why I'm at the whiskey web and whatnot podcast. Now I'm like, I can custom my podcast. Ha ha ha ha. And I'll make a sizzle, rizzle. It's not even words. It's like made up words, you know? Like, do what I want. yeah. Brittany Ellich (33:35.681) Yeah, that's incredible. That's a really great idea too, I think, especially if you do something that's very visual. But even if you don't, I mean, even if like your sizzle-rizzle is something that's like showing, you know, these cool like performance back end, like, you know, everybody loves a graph. Everybody loves seeing a graph, see a graph go up or a graph go down. That's exciting to see. Bethany (33:56.228) Yeah, I'm here thinking what it would look like for a backend engineer. like, hey, look at this number. Now look at that number. Adam Argyle (33:56.399) Absolutely. Brittany Ellich (34:02.849) Whoa, look at this postman response. Adam Argyle (34:03.395) Watch this migration script run. Yeah, I mean, it really could. Successful migration one, successful migration two. All right. And watch the pod. Actually, you could do a cool thing with Kubernetes or whatever. Like watch my pods light up. Here comes traffic. Here comes me thrashing the traffic. Watch everything get handled. no, one of them went down. Guess what? I got a backup. Yeah, you could make it fun. You just need a radio host to say what's going on in a fun way if you're a nerd. Anyway. Bethany (34:05.828) Yeah Brittany Ellich (34:30.463) Yeah, might need some help explaining exactly what you're seeing. yeah, no, that's really interesting. It seems like a lot of the process too is very broken right now on like just getting in the door to have the conversation even to about like about the role. Like, I mean, there's everybody making AI resumes and then there's everybody using AI to review resumes. And there's just like, seems like it should be a very easy problem to solve where it's like we have humans that need jobs and we have people who need to hire humans. So you would think that that would actually be. easy to solve, but it's not at all. So that seems like a nice way to... Adam Argyle (35:03.491) Yeah, that was another part of the problem was even just getting into the interviews and being tested over dumb stuff that didn't apply. So they saw my sizzle result, right? And they're like, we want that on our team. And I'm like, cool. They're like, come in for the interviews. The first couple of interviews, you know, were like, non-technical. Then we get to the technical interview and they're like, solve this thing. it would be a, maybe it would even be UI related. Like I had a couple that were good in some make a notification system. Cool. You can pick whatever framework you want to make. The notification system in cool. I'm just gonna do an HTML CSS JavaScript one right here. you didn't choose react You just told me I could pick what I want turd nugget. Okay. Well, whatever here we go So I'm just I'm already I guess losing points because I didn't choose react or whatever and then I'd be making it and I'd be like, okay, I'm gonna use the output element so it announces itself to the Screen reader users and they're like now you don't have to worry about that. I'm like, yes, I do because that's kind of what you're hiring me for. It's not just visual animated UI, it's the UI that is useful and usable by everybody. So I think it is. then even animations, I'd be like, okay, I'm gonna spend the next couple of minutes animating it. And they're like, no, we just want you to complete the task. I'm like, no, think you want to hire me to make, because you can probably make a crappy version of this that no one likes with React. I'm gonna make one that people like with whatever, I don't even care what tools, but I'm gonna make a desirable one. And they'd always be like, You didn't pass the test. I'm like, I could feel that through the interview. Yeah, I was trying to show you the things that I bring that you don't, and you clearly made me feel like you didn't want them. So yeah, I could feel the mismatch. And then yeah, using AI in interviews too. Some of them, like open AI, you're not allowed to use AI in the interview. And I thought that was quite funny. I was like, I'm sure you're going to require it on the job, but you're not going to. I'm not gonna interview me and see if I even know how to do it. Okay, that's fine. Meanwhile, the Shopify interview was like, full on AI, whatever you wanna use. Are you gonna one shot the test today? And I'm like, I'm not gonna, it's someone else. And they're like, yeah, someone last week one shot tic-tac-toe. I'm like, that doesn't sound like a good interview. I'm gonna go ahead and just think this out. I'm also gonna make one that's acceptable. Watch the keyboard. We're gonna be able to play tic-tac-toe from the keyboard, you know? Adam Argyle (37:26.125) So yes, it's broken from the testing. It's broken from, they filter people in with these, you know, criteria that they want you to know, and then they don't test you on any of it. It's super broken in tons of different ways. And so it was not fun. And me being a public figure didn't really play into that much other than the job I got at Shopify was because I, well, that was a previous coworker was Jason Miller. him and I worked together on Chrome and. He knew I could build robust UI. He wanted me and him to build projects together. So it's a little bit different. If anything, being public might hurt you because people create assumptions about you. And sometimes, you know, if you can't build, become a teacher or whatever the phrase is that people like to use to be rude. I'm like, no, I teach because I'm building all day. The only reason I have anything to tell you that's a tip is because I was building last night. So turd, more turds. There's turds everywhere, dang it. Why are there so many turds? Brittany Ellich (38:27.027) It seems like that needs to be the theme of this entire episode, really. Interesting. Yeah, I think also I feel like a lot of the way that... like hiring has gone trending up until, you know, AI was like, we're just going to make, take these leak code problems and make them more and more difficult and stuff. now they're like, how, how are we going to read completely redo and mess up the interview process again now that AI is available to solve these leak code problems? Super, super easy. And like, you don't need to, you don't need to do, know all of these obscure algorithms anymore. Erika (39:05.036) Yeah, I guess like, how would you design a front end interview? Like if you were interviewing yourself for a job, like what would you expect on the other end of the table? Adam Argyle (39:16.117) smiling because Shopify asked me to do that. They were like, hey we want to hire more people that bridge the gap. want X's not T's. They used to hire T's and that was a T-shaped individual. You're nodding your heads like you know what that is so I don't need to explain it. Okay, the X-shaped individual though, know, they're the cross, so that means you can go cross domains versus the T means you could go deep into domain. So they used to hire for intense technical knowledge and now they're looking for cross because AI can help fill the gap of a lot of technical stuff. And they want someone that can do AI things. want more design engineers. And the test that I made, because you only get an hour with someone, and a design engineer, tend to think of them as the people that show up and they finish. I like to think of them as the finishers or they are capable of finishing. They can start from scratch and go all the way to like, polished finished thing. A good example is like a faucet. So you've got all these people that help build a bathroom or a room that has a sink and they can put the sink in and they can do it without it being seamless, right? They can have gaps and someone has to eventually go in there and smoothen out the caulking and stuff like that. Another feature of a sink is when the water comes out of the faucet, there's like this little aerator thing that's on there that makes it so it comes out and looks like a cylinder, but it has like air in it. It's like all bubbly. Anyway, if you don't have one, you'll know because you'll use one. like, it feels like I'm at the beach using just the crappy bathrooms. know, like the sink is all, just the water just looks, anyway, it just feels different too. And so someone needs to show up and give a crap about that. And so like, how do I create a test where it's like, look, I don't need you to put the sink in. I don't need you to run the water to the plumbing. I need you to make this sink nice though. So do some finishing work. And along the way, in terms of like, front-end web development, let's do some animations, let's make sure it's keyboard. If we get to accessibility, that'd be great. And so what I built was a front-end interview scenario where I've already built a lightbox for you with popover, actually using dialogue and some images. So it's a grid of images. If you click one, it clones the image into the dialogue and shows the dialogue. And then when you hit escape or you click off of it, it closes the dialogue and that's it. So it's like, Adam Argyle (41:39.331) The plumbing is there, the interaction is there, it's just lame. It just sucks. And there's so many different directions to go. There's so many ways to improve it. It comes with some accessibility affordances. It comes with some keyboard affordances and stuff like that. So I get to watch people first figure out what is not working. And then they're like, I need to go fix that. Like, I expect this to do that. And then once they get the kind of general stuff working, can go add some polish and some finesse with animations and stuff like that. And it's on them to figure out how big are the animations that they want to do, all of that stuff. So they get to show up and instead of me watching them plunk out HTML for a grid and then plunk out a dialogue element and then like look up the features and stuff like that, it's more like, no, come here and make this thing polished and awesome. The fun part, someone else, anyway, so that was the test I made and it's, you can use AI the whole time. we have ways that we're, critiquing your AI usage. we're, you know, we're scoring you on a number of things. there's different phases. They wanted it to be like a video game, which is fun. So there's basically like levels, that you have to beat. And it's like, Hey, what level did they get to? they got to level five. Ooh, that's a pretty advanced level. That means they had done all these other things. and you can continue challenging people be like, Hey, you just passed level four. Here's level five criteria. Let's see what you do with these or whatever. so you need to guide them. towards something else. That's what we did. And I thought that was a fun and interesting and meaningful way to engage someone's finisher mentality. Instead of us watching them do the boring part, they get to jump right to the fun part and show off. Literally, I wanted them to spread their wings. It's so annoying that in one hour, you go to these interviews and all you do, and everyone, can't see what I'm about to do, but I'm gonna start spreading my wings and then they get stuck. on the walls because you only had an hour. You're like, I swear I could have done better. You're like, didn't even get one flap in. You're like, that sucks. I wanted something where it comes in. It's like, it's already flapping, but now I want you to like, yeah, make it an elegant flap. Actually, that metaphor got really weird, but you see what I mean? Like, I wanted you to feel free and feel like when you leave the interview, feel like you had an opportunity to actually show something unique about you that showcased your skills, not your ability to. Adam Argyle (44:03.022) tippy tap, but your ability to execute and deliver something polished and great. Brittany Ellich (44:08.243) that and that seems like something that would like give a lot of signal too and like shows a lot about the company as well like I think a lot about the way that a company interviews and what that means about like the company's internal culture as well like if they're just doing the hardest algorithmic problem as possible like that's probably not a place that I'm gonna want to work anyway so yeah Well, we are coming up on time and at the end of every one of our episodes we do what we call a fun segment and since you are our guest today, of course it is CSS themed, and we came up with CSS would you rather? So I am going to go through a list of these would you rather questions. All three of you are welcome to answer because we might have different opinions here and you might get shamed for your opinion or you might not, you know, we'll see. We'll see how goes. I don't think Adam is judging us, but maybe just a little bit. And that's also probably, that's probably fine. So we're gonna kick it off with this really fun, hopefully not controversial one. Would you rather write vanilla CSS forever or be forced to use Tailwind on every project for the rest of your life? Adam Argyle (45:22.6) Easy vanilla CSS all day. All day. Erika (45:25.398) Yeah, I'm right there with you. This is kind of a no-brainer for me. Bethany (45:31.629) I would do vanilla CSS as well. As someone who does not write CSS well, I still do not love Tailwind at all. Respect to people who do, but not for me. Brittany Ellich (45:46.178) Yeah, Tailwind came out after I learned CSS and so it's actually more difficult, I think, for me to learn to like be like, no, this is a Tailwind application. I need to go figure out what this looks like there and lot of looking up. Okay, this one might be. Adam Argyle (46:01.71) I'm cursed because I know everything it can't do. So I'm like, oh, I needed to do this thing. Oh, it's so much easier over here. I'm like, you have to put that class on those 20 items. I'm like, I just have one selector do it over here. Anyway, so yeah, I'm just like cursed. I'm just like the whole time using Tailwind, like this feels so limiting, which is part of its value. It does have some superpowers, so Tailwind is still cool. But if this is for forever, oh, vanilla. Yeah, I want to grow with it, not be stuck. Brittany Ellich (46:14.23) Mm-hmm. Brittany Ellich (46:21.567) Yeah, it's true. Brittany Ellich (46:30.069) makes sense. Next one, would you rather flex box or grid forever if you only got to pick one? wow, that was fast. Okay. Adam Argyle (46:36.12) Grid, grid. People flexbox too much. Grid is awesome. It has a big API surface area. It's hard to memorize. It's got some weird units. It's also got a lot of functions. But it's an awesome, awesome layout engine. Brittany Ellich (46:57.963) Do you have a? Bethany (46:58.371) Yeah, I probably would do Flexbox just because that's what I mainly know and have used, but yeah, I would say Flexbox. Erika (47:09.708) Yeah, I'm on the grid train. I feel like I've gotten to some weird states with Flexbox and I have like boxes on boxes on boxes and I'm like, well now I just made a grid. So why didn't I just use grid in the first place? Brittany Ellich (47:25.173) Yeah, I agree. think grid feels a lot more powerful and like the more that I do write CSS, like that's probably the one I would choose to start with. But I almost always reach for Flexbox first because I'm like, I know exactly how to do this with Flex. Like this is easy until it's not until you've got, you know, 10 layers of nested divs. And yeah, like, wait a minute. Erika (47:45.739) Exactly. Brittany Ellich (47:49.574) Would you rather every browser wait to ship with new CSS features simultaneously and perfectly or browsers keep competing and shipping things fastest to see who can get it? Adam Argyle (48:03.277) Ooh, spicy. I like this one. The interop efforts have been quite nice as things come out altogether, at least in the same year. However, the competition's mostly in the tooling, which is nice. Not usually in the implementations. Mm-hmm, I am going to go for personal convenience. and say if they all released at the same time that would be quite dandy. Bethany (48:36.411) you Erika (48:37.912) I'm not sure I have a preference on this one. I feel like I'm not deep enough in the browser compatibility. I don't think I do enough CSS to really feel that feeling much. So I'm going to abstain from an opinion on this. Bethany (48:57.275) I would say honestly I think I would rather them compete because I still think people are going to be on ancient browsers or ancient versions of it. So you're always going to have to do some sort of backtracking. So I think like just having people compete and get it out sooner is probably probably more or less going to be going to be the same. Adam Argyle (49:22.381) Cool answer. I like it. Brittany Ellich (49:22.465) Yeah, yeah, I agree. That could end up being some sort of like lowest common denominator. Like now we have to wait for everybody to get it out and then it never comes out. Luckily Internet Explorer is out of the picture, but I'm sure there's, you know, a new one to hate. It's been a while since I actually had to care about browser compatibility. Would you rather lose key frames, no more CSS animations or lose CSS variables. Adam Argyle (49:59.252) Hmm. I'm gonna say keyframes. Keyframes have a very annoying thing that they do to me, which is they're not interruptible. And that kind of makes them dead to me in a whole bunch of ways. Like, it makes them way less useful. They have a whole bunch of really fantastic use cases. Like, they're in scroll-driven animations, so you couldn't do a scroll-driven animation without keyframes. That stinks. But I think they could mostly... be replaced with something else and I wouldn't miss them. But variables, variables are a clutch. That's a really, really powerful way to, well, they just have so many superpowers. I could rant about what you can do with variables. have many blog posts about, I think there's even a blog post called 10 Powerful Things You Can Do With CSS Variables. And most people only do the first one, which is like they make a variable with like a value in it. Like we scrubbed the internet and saw everybody's variable usage and it's like, how many levels deep do they go? Deep meaning, do you have a variable reference another variable? And that was very rare. It was like 10 or 15 % of websites actually have a variable reference another one. And in that post, I'm like, you can have a variable reference, a variable reference, a variable reference, a variable, know, like look at the cool use case. can do this. So yeah, variables all day. Plus I have open props. I'm like a variable hoarder. That's, what that whole repo is. It's like, let's just. find all the best variables that you could have in the world and put them in one repo for people to use. And so yeah, I choose VARS. Brittany Ellich (51:29.441) Any alternative opinions, Erika or Bethany? We've been in GitHub UI, anything. Bethany is very much on the back end, I feel like, within your role. I haven't gotten to do as much UI as I would like to. It's been a while. But this has been fantastic. Thank you so much for joining us. Where can folks find you on the internet? Adam Argyle (51:58.281) Good one-stop shop is nerdy.dev. That's my personal website. I always post there first There's RSS if you're into that and then I syndicate out to social networks and you'll find my posts on Macedon, Blue Sky or X if you want them But yeah, find me at nerdy.dev. That's the good spot Brittany Ellich (52:16.897) That's awesome. Yes, I'm very into RSS. Love that that is making a comeback now. Excellent. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you're supposed to do on the podcast app of your choice. Check us out on Bluesky and share with your friends. Until next week, goodbye. Adam Argyle (52:23.874) Me too. --- ## Episode 59: Building the Decentralized Social Web: From Collective Social to OpenSocial - URL: https://overcommitted.dev/building-the-decentralized-social-web-from-collective-social-to-opensocial - Published: 2026-05-12 - Audio: https://anchor.fm/s/102586d64/podcast/play/119794330/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-4-11%2F423891221-44100-2-a30a1f8508934.mp3 ### Show notes Brittany shares her journey building Collective Social - a Goodreads-style app for all kinds of media built entirely on the AT Protocol - and how it led her to create OpenSocial, a service that lets any app on the decentralized web share group functionality like book clubs. The episode covers the challenges of representing groups when the protocol has no native concept of group identity, using conference talk deadlines as motivation to ship side projects, and rating real-world systems on how well they'd work in a decentralized context. Erika also shares her experience building an interpreter in Go. Show links: * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com/] * Collective Social: https://collectivesocial.app [https://collectivesocial.app/] * OpenSocial: https://opensocial.community [https://opensocial.community/] * Collective Social on GitHub: https://github.com/collectivesocial [https://github.com/collectivesocial] * "Representing groups in ATProto" blog post (Brittany's site) * AtmosphereConf speaker profile: https://news.atmosphereconf.org/3mfpjx5luuc2m [https://news.atmosphereconf.org/3mfpjx5luuc2m] * GitHub Blog - Build a Personal Organization Command Center with GitHub Copilot CLI: https://github.blog/ai-and-ml/github-copilot/build-a-personal-organization-command-center-with-github-copilot-cli/ [https://github.blog/ai-and-ml/github-copilot/build-a-personal-organization-command-center-with-github-copilot-cli/] * "The art of saying yes" blog post: https://brittanyellich.com/say-yes-do-all-the-things/ [https://brittanyellich.com/say-yes-do-all-the-things/] * "Living in the inflection point" blog post: https://brittanyellich.com/living-in-the-inflection-point/ [https://brittanyellich.com/living-in-the-inflection-point/] * Nick Gerakines episode (EP19 - AT Proto, MCP, and Open Source): https://overcommitted.dev/ep-19-at-proto-mcp-and-open-source-with-nick-gerakines [https://overcommitted.dev/ep-19-at-proto-mcp-and-open-source-with-nick-gerakines] * PDX ATProto talk: https://youtu.be/xFdak3HbDmM?si=rZoPfyYYoP2awADJ&t=2302 [https://youtu.be/xFdak3HbDmM?si=rZoPfyYYoP2awADJ&t=2302] * AtmosphereConf talk: https://youtu.be/GVOywon3X-Q?si=yzKLfFNF8bzNT9-e [https://youtu.be/GVOywon3X-Q?si=yzKLfFNF8bzNT9-e] * The ATProto Store: https://atstore.fyi [https://atstore.fyi/] * pdsls.dev: https://pdsls.dev [https://pdsls.dev/] * Atmosphere Community: https://atmosphere.community [https://atmosphere.community/] * npmx.dev: https://npmx.dev [https://npmx.dev/] * Tangled: https://tangled.io [https://tangled.io/] * This is for Everyone by Tim Berners-Lee: https://www.goodreads.com/book/show/222376492-this-is-for-everyone [https://www.goodreads.com/book/show/222376492-this-is-for-everyone] Topics: AT Protocol, Decentralized Social Media, Side Projects, Open Source, Software Engineering ### Transcript Erika (00:00) Welcome to the Overcommit a Podcast, your weekly dose of real engineering conversations. I'm your host today, Erika and I'm joined by... Brittany Ellich (00:07) Hey, I'm Brittany. Erika (00:08) We met while working on a team at GitHub and quickly realized we are both obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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, we are learning about Collective Social, a Goodreads-style app for all kinds of media. built entirely on at Proto that Brittany has spent the last several months building outside of her day job as a staff engineer at The project eventually led her to found OpenSocial, a service that she designed so any app on the decentralized web could share a book club or really any social platform. So we'll get into Collective Social and OpenSocial more in a bit. but I also wanted to share something that I've been learning about that has been kind of fun. I recently finished building an interpreter in Go. And, you know, it was pretty good. I would say, like, as somebody who didn't go to school for software engineering or computer science, I knew very little of how an interpreter worked. And now I know some of how an interpreter I at least know like the building blocks and it was probably something that if I had spent more time kind of digging in I probably would have gotten more out of it. It's the age-old story of like you get out of it what you put into it but it was fun actually writing code and in this book he kept it very simple and basically mapped interpreter concepts to go. like, you know, plus in the terminal, um, REPL would then like use plus in go. Um, so you could really clearly see like how each step translated. Um, and the basic building blocks were pretty simple, which helps build a mental model. Um, I think talking about this book with people who know more about interpreters, I'm understanding that the complexity really lies in a lot of the performance trade-offs and he recognizes that in the book that there's a lot of performance issues with how this is built. anyway, was fun to kind of dip my toes in the water. Brittany Ellich (02:35) That's so cool. I've had that book on my list for a while and I kind of followed along because it was through like the internal book club, right? That you were doing that. Yeah. That sounds educational. Erika (02:41) Mm-hmm. Yeah. Yeah, good time. I'm definitely ready for like a last technical book for a second though, like let my brain kind of chill. Yeah. Brittany Ellich (02:53) Yeah. Well, we're kicking off our next book club for overcommitted. Although I feel like we've already read this book internally, but maybe that's also better. ⁓ With the staff engineer's path, I think we've read that once internally. Erika (03:05) Yeah. We read it, yeah, we read it once, just the three of us. So it'll be fun to kind of get like new perspectives on it. Brittany Ellich (03:12) Mm-hmm. Yeah, yeah, I agree. I kind of like rereading some of those books too. I feel like there's a lot that you gain out of it and just hearing other people's perspectives is kind of nice. Erika (03:23) sure. Well, I already know what you are excited about because I asked you before this episode, so, and that is the Collective Social and Open Social project. So can you kind of give us an update of where things are at right now? Brittany Ellich (03:29) True. Yeah, so I started these. I think I'll link it in the show notes, but I started learning about at protocol when we had Nick Gerakines on the podcast last year. And I know you and I have talked a lot about like, gosh, the problems in social media and like have a vibe over a lot of like books and stuff in the past. And it really sparked my interest a lot. I'm like, wow, OK, this is like something that's very interesting and could make a huge difference for the world if like social media was less terrible. So I knew that I wanted to build something on at Proto just to like learn more about it. And then I started with, yeah, that Goodreads style app, Collective Social. But what I really wanted is something that we could use for our book club to like organize things like, you know, have like an async spot to. collect comments or to share updates and have a schedule of when we're supposed to read and by when. So that's sort what I started with and it kind of led me down this rabbit hole where I realized there's no real concept yet of a group or a community shared identity within the at Proto space. I know that there's some folks looking at that now, but. ⁓ Yeah, so that's sort of what led me down this big rabbit hole of building OpenSocial, which is actually a little bit further along than CollectiveSocial is. And we have a few use cases for it, like for the atmosphere.community website, which is where all of the different local app proto groups are through. People can now share their blog posts or events or something like that, and they all aggregate under one group identity, which has been really interesting, I think, to work on and build. Yeah, it's been really fun. Erika (05:16) Yeah, for sure. Okay, so as a kind of refresher for me and then for anyone who's new to the app, Proto Space, can you explain what it does and what it does differently from maybe other social media platforms, whatever it's comparable to? ⁓ Yeah. Brittany Ellich (05:35) Yeah. Yeah, for sure. Yeah. So in the traditional or shall I say legacy social media space, the idea is, is they build this app that brings a lot of folks in and ⁓ you think like Facebook or MySpace or Twitter or whatever, you know, typically it starts out like just gaining a lot of people and a lot of excitement. And then further down the road, once people are on the platform and using it regularly, they start doing things like How do we keep people on the platform more frequently? And how do we keep users engaged so they keep scrolling and see more ads and then start monetizing through ads? And a lot of the reason that that works in those social media apps is because it's really hard to leave, really hard. So I mean, I still know people that use Facebook because it's just so hard to leave because they have that one group there or that one group chat or... You you don't want to lose track of your family or something like that. It's just really hard to like migrate off and all of your content and photos and everything like that are kind of trapped in that company's database. So the one major thing difference with at Proto is actually created, I think by folks that worked at Twitter before Twitter became what it is now. It's designed so that you as the user own your own repository. And so all of your likes and follows and data posts, everything lives in your repository. And so the biggest app proto app right now is Blue Sky. That was like the first one that's where they all sort of started this app. And if Blue Sky starts doing something that you don't like and you're like really invested in the platform. you can just move to a different one. And there's already several like blue sky clones or like blue sky clients or similar things that you can like take all of your data and just leave if you want to. And you'll retain all the people you're connected to, all the posts you see. You'll still be able to see like the old posts from other folks, but you don't have to necessarily see whatever it is. You know, if they introduce ads or something like that, that you don't like. And so that makes for a very like different incentive where the app has to like compete to be good, ⁓ which as it turns out is really healthy and you know, a good way to create things that aren't, you know, addictive or, you know, just there to extract money out of people or use users as like the product. Erika (07:43) you Right, yeah. I mean, it's interesting because we're talking about social media, but this is something that could be useful for tech in general. I'm thinking of switching between device ecosystems, like having all my stuff on Apple Cloud versus switching to another device, how much of a pain it is to move all that, or getting off of Google Cloud, any sort of device storage. Yeah. Brittany Ellich (08:05) yeah. Erika (08:22) any sort of storage platform really locks you in. Brittany Ellich (08:25) Yeah, and it's definitely expanded outside of just social media already too. the atstore.fy recently launched and there's 390 different app proto apps on it that folks have built. And there's like a very rich community of developers that are super interested, super friendly and like willing to help. It's also really easy to build on. because a lot of like the data layer is already figured out for you. So you don't necessarily need to do like a lot of database work or like OAuth is pretty well figured out. So you can just plug into like the existing OAuth system and not have to like figure out authentication. So it makes it really easy to build onto. Erika (09:00) Cool. Well, that's helpful for a high-level view. Of course, with any sort of text space, there's a lot of terminology. So you recently gave a talk and you walked through rebos, lexicons, blobs, DIDs, app views. So what made this vocabulary click for you? Brittany Ellich (09:22) I think a lot of what made it really click for me was building on at Proto, like building the apps that I was working on. Like I said, I was kind of stuck where I was like, okay, well, I want some of this data to be aggregated under a group and there's no concept of a group identity yet within the at Proto space. And there were a few different ideas out there ⁓ from folks about how to go about doing that. And so, ⁓ I just sort of looked through some of the ideas that folks had and then I worked with ⁓ Nick Gerakines, too, since we worked together at GitHub, and picked his brain about how would we do this? And so we came up with this idea of creating group dids, which is the decentralized identity. So for example, I have a did, which is just an ID basically that's represented throughout the entire decentralized web of some gibberish ID name and then I have a handle which uses they use DNS to resolve to the handle. I have britneyellick.com is like my handle and that represents my identity. But we also have one now called overcommitted.dev and I made that into a group did so anybody can go on to open social and like become a member of that group and then that means that they can like post content post their own content and link it to that group so we can show like. What's everybody in the group up to at one time? And so there's a way to like basically connect those together. So I think building that and like trying to reason through that problem helped a lot and helped me realize like, all right, like a lot of this is really pretty not crazy complicated. I think that's the beauty of it is it's like actually very simple at the end. Like it's just like a folder full of JSON. Everybody gets one folder full of JSON. objects and any app can like render any of the JSON objects. So like once I started like getting my hands dirty playing with that, was like, wow, this is really easy and like makes a lot of sense the way that it's set up. Erika (11:06) Mm-hmm. Okay, got it. Yeah, and I could see that there's this constant trade-off of like a central store. I'm guessing that's the repository is that blob I think you kind of mentioned. And then the sort of decentralized aspect of it, which includes like discoverability and also like whenever you come into a group setting, there's like the idea of like management. Like, do you have somebody who owns the group? Do you have somebody who moderates the group? Like, and then that becomes a centralization point. But if you don't have anybody doing that, how do you expect that to work? Brittany Ellich (11:56) Mm hmm. Yeah, yeah. So everybody's repository, their little folder full of JSON objects lives on what's called a personal data server or a PDS. And so if you sign up with Blue Sky, for example, I think that's the first one a lot of people recognize, then you get a folder created for your you get a did created and then a folder created on one of their PDS is and then you can take that and migrated anywhere else if you want. And then I think it's just like the did is like the shared centralized identity. I'm not actually sure how that's, how that is set up. I think probably because you're using DNS, which is already something that has is like its own like decentralized identity. know, DNS is set up on servers throughout the world, but then everybody, every server recognizes them. ⁓ So I imagine it's probably something similar to that. But yeah, I for actually creating that because I Erika (12:40) you Brittany Ellich (12:48) the idea of like often like role based access controls and stuff is not something that I'm plugged into or familiar with. My closest like proximity to that is discord. And so I basically just like operated off of the way that a lot of discord servers I've been in work. I'm like, this seems approximately like what you're looking at. whoever starts it is the admin and you can, you know, delegate more admins and Admins have some permissions and members have different permissions and like just trying to make it so that like an admin can say like anybody can do anything. And then using open social as the layer where you can rep, you can register an app like collective social is registered with open social and so you can create collective social records instead of any of the groups from that app or you can register as an individual to say like I'm going to join this group or I'm going to start this group or whatever it is that you're. interested in. Erika (13:38) So it's, yeah, it's sort of the groups, the groups repository is shared between any app view. Is that kind of the idea? Brittany Ellich (13:48) Mm-hmm. Yeah. Yeah. So the app view is just any app that can represent like render data from somebody's PS. So like blue sky is an app view or tangled. That's like the GitHub of at proto is an app view. And so like all of the, all of the social things live in people's repo. ⁓ and so like my repo has stuff from like, you know, 20 different app proto apps that I use now. all represented there and like any of them can like mix and match what they show. So some of them will, for example, use like the follow graph from Blue Sky. So when you sign into the app, you are immediately connected to everybody you follow there. And then some of them have like their own separate one. And it's kind of up to the developer how they want to build the experience. Erika (14:28) And then what's a lexicon? Brittany Ellich (14:29) Um, a lexicon is the schema for the JSON documents. Yeah, so if you're ever doing anything in the protocol space, any development, this PDSLS site, it's pdsls.dev is super, super helpful. So for example, I can go to enter my handle, which is berniealloc.com. This is gonna show me where my PDS lives, which is on Blue Sky. It's gonna show me my did, and then it's gonna show me each of the collections, which is just like the collection of items that were created. from each app that I'm a part of. for example, you can see, let's pick one that's like pretty common. So app Blue Sky Feed Post. I can pull up my most recent post where I tagged Salma and told her how much I ⁓ appreciate listening to her soothing voice and how sad I was to miss the recording because it's true. I listened to that episode like twice because it was just like so soothing. Erika (15:19) you you Brittany Ellich (15:25) hearing her talk. But then the lexicon is the schema for that thing. So the Blue Sky, when they create a post, they're also creating this lexicon schema so that any other app can say, all right, here are the things that I expect to see on these records if I wanted to render them as well. So it's just a way for other app views to be like, oh, I know that I expect text is required on this thing. So if another app is going to like, create blue sky posts, which is totally possible, then they know that this is required and this has to be included. Erika (15:58) So like the app owner determines the schema and then basically any other app view who might want to render this schema then has that available. It's open to see and view and integrate with. Yeah. Cool. Brittany Ellich (16:12) Yeah, exactly. Erika (16:14) that kind of, yeah, gives a very clear view of how that's happening. And yeah, I guess I'm personally impressed that you've managed to keep this side project building for so long. clearly it came from both a personal itch and also a passion for... contributing to this space. But were there any points when you hit a wall and what did you do when you got to that point? Brittany Ellich (16:44) Yeah, so I actually wrote up a doc about what I was planning to do, a blog post which ⁓ I can link. It was like back in November, I think, where I was like figuring all of this out. And then I didn't touch the project. I got it started and then I didn't touch the project again until like January. And the thing that really motivated me to continue is I had submitted a talk proposal to AtmosphereConf about it. And like I was primarily motivated by like the shame of not wanting to be unprepared and not have a thing to show for the talk. So that's what got me to actually finish it. So I'm highly motivated by being publicly shamed, I guess. It ended up going well. I enjoyed the talk. It was fun. And the talk was all about how open social works. Yeah. Erika (17:30) I get that. mean, this is part of why I do book clubs is because that accountability is so important to me finishing things. Yeah, so there's there's no shame in using public shame. Brittany Ellich (17:44) Yeah, yeah, I'm glad my talk was chosen because I absolutely would not have finished it otherwise. Because I was very close to be like, do I really want to finish this? And I did. And I was glad to be doing it. And I'm glad that I went to the conference, too. It was a super good conference. So, yeah. Erika (17:50) Yeah. Is there any part that you're especially proud of, like technically or otherwise? Brittany Ellich (18:05) ⁓ I think that this was also, it was an interesting time when this happened, cause this was also around the time that like, AI tools got like really good. and so the fact that I have like a finished side project and it's not just something that's like languishing in my to-do list forever is really due to the fact that like I had something like that to help like smooth out the friction points. ⁓ cause otherwise like it's Actually, it was a lot of work to build, having Copilot available to help me whenever I got stuck was phenomenal. It made it go a lot faster than I think, and finish, ⁓ because I wouldn't have otherwise. I've got a job and three kids and other things going on. So little over-committed, if you will. Yeah. Erika (18:46) Yes, yeah. What did that workflow look like for you? Brittany Ellich (18:52) ⁓ my current team has what's called well-being days for like once a month. We get like a Friday off. Today is actually one of those days for me. and so, yeah, I used those days pretty heavily. and, after bedtime, that's like my, turns out that's also like the time between, you know, eight to 10 PM. That's when I'm like most. feeling most creative and ready to do something anyway. So like that has worked out really well. So I use that time a lot for building things. Yeah. Erika (19:20) Okay, so let's dig in a little bit more to this, the groups in decentralized spaces and a little bit more of the technical details there. So you want to build a book club feature. have that shared resource so that multiple people can read and update together. So what specifically was missing in app proto that made this difficult? Yeah, and why was it hard? Brittany Ellich (19:49) Yeah, so there wasn't, it hasn't been like a built-in thing to the protocol yet to say like this is a group shared identity. I think people could get around that up until now by just like sharing a password to, you know, the same login essentially. And then you could like, you know, we could both post under overcommitted, know, blue sky post or whatever, because we share a password. But thinking about that, I didn't feel like that would work at like an actual scale. you know, if I wanted to share this with everybody, I don't want to share the password to that, to every single member of, you know, a community that I'm a part of or anything like that. So, so since that didn't really exist and since there was already like a lot of, you know, thinking out there, like how would, how would a shared thing work? one of the things I was looking at is like, you know, within collective social, we could just say like, all right, the group lives in a repo within or like within the database of that collective social app. But I really wanted something that was like on protocol so that it could be used across different apps. And in the future, it could be like extended and you could say like, all right, like we can, you know, have like the shared resource to post to Blue Sky or the shared resource to like work under and untangled or something like that. And so that is sort of where I realized like we needed ⁓ some sort of an identity to like handle allowing those permissions to post under. a shared resource without like sharing a password with everybody. And so the group identity themselves is just another did and handle, like it has a group repo and a group did and a group handle, but they're like identical to an individual one. So you could take any existing, you know, shared, uh, shared account out there in blue sky or whatever, and turn it into this group resource so that you could use it across multiple apps. ⁓ but, then the way that things are shared from the actual group is there is instead of like the, you know, if you make a post and you're like, I want this post to be shared from the group's page or something like that, instead of, instead of posting under that group's identity, you can post under your own. So you can say, Hey, I'm the author of this post and then create this like two way handshake where there's a record within the group's repo that points to. you the record in your repo. So there's like this two-way handshake basically between the content that you post and the group identifying like, yes, this is something that I'm going to show as part of what's in our repo. And that serves a couple of purposes. So like the group admins, if somebody is being really spammy and they don't want to have all of these resources from someone, they can just delete the handshake on the group side. ⁓ Erika (22:23) Mm. Brittany Ellich (22:24) And then like the same thing, like the user can just change their own post if they're like, I don't want this shared with the group anymore. They don't have to necessarily like change anything in the group. They can just change it within their own repository and like break that connection. Erika (22:37) Cool. Yeah, that makes a lot of sense because, yeah, that recognizes still that personal ownership of maybe you get even kicked out of the group or something like that. But even if that happens, if I delete it on my own repository, then it's still gone. or like the handshake mentioning like there's this contract between you as the group and the group member and you can post it on your personal but if the group doesn't want it then like you're not, it won't be recognized as a record. Brittany Ellich (23:10) Yeah, yeah, it's not like it's going to delete the record or anything like that. You still own the thing that you the content that you created and you can still take that to other groups if you wanted. ⁓ If the one that you were in like just didn't vibe with it or whatever. But yeah, so that's sort of the goal and that was what that's working now actually, which is exciting. It's actually on a website. So the atmosphere.community site is an example of one where ⁓ we are. There's folks that have joined the atmosphere. Erika (23:20) Mm-hmm. Brittany Ellich (23:38) community group through open social and then they've said like alright these are the posts from you know one of the blog post sites within at proto that I want to share with the group and then all of them are like represented with from that group but based on like posts that people have shared which is cool to like see it actually do a thing yeah Erika (23:57) Yeah, well, that was very cool. Very cool that it's kind of taking life and yeah, you've written specifically about this whole process of developing this open social community. And you've also been very public about wanting feedback and you've... shared links to prior art and community discussions. So what's it been like building something where the spec is still being written? Like this group has not fully decided what they want to do and you're kind of proposing something. Brittany Ellich (24:28) Yeah, think it probably depends on the space that you're in. I don't know if every, this is my first time really getting into any open source space in any like longer term capacity. But everybody's been super open and like willing to like rubber duck on things. I've had folks like give me feedback like, hey, you should make your OAuth setup better. Like look at this instead. I'm like, ⁓ gosh, I love that feedback. That's great. Erika (24:52) you Brittany Ellich (24:52) ⁓ cause that's just not my area of expertise in any, by any means. so I think it's, it's a really like friendly and sharing community where like, that's just sort of normal within the community. There's a lot of spaces, like there's a discourse where anybody can go in and, you know, propose a topic and lots of folks will weigh in and with their opinions, if that's what you want. I think sometimes that can also be kind of, I think there's also like some drawbacks to that too. ⁓ in some ways where it can be really easy to be like, yes, things should be done this way. And then there's no real ownership of this person's gonna go take that idea and do a thing with it. It's really on the individual to go make it actually happen. But I feel like everybody's been pretty generous with their thoughts and time. So I'm just kind of emulating what the rest of the community does there. Erika (25:41) Cool, yeah, I can see that coming from the sort of driving force of the community being really this data ownership and the purpose of this is good. And yeah, no one's trying to make money. It's kind of the opposite, trying to reduce the impact of profit-driven development. Brittany Ellich (25:54) Mm-hmm. Yeah, yeah, there's a lot of apps that are really similar within the ecosystem. And like, like this is not even like the first Goodreads type app. It's like the 10th or 20th at this point. And it seems like there's been a lot of collaboration and like design towards interoperability. Like there's a couple of different blog sites, for example, like there's Leaflet is one and Offprint, that's the one that I... Erika (26:15) and Brittany Ellich (26:29) I use and then there's pocket.blog and all three of those came together and like designed a lexicon together so that like their content could easily be shared between the apps. So I think it's sort of a different way of thinking about building apps where it's not necessarily like, hey, I'm going to build this app and I need all the market share. know, like people are going to go to the one that, you know, fits their style more or like has the features that they need and everybody's like pretty friendly and willing to work with each other to be like, all right, let's make the best experience possible. And I think a lot of that comes from that like need to like, you you have to compete on features and like how good the app is when, you know, anybody can go anywhere. Erika (27:02) Really. Right, yeah, I mean it kind of reminds me of like something I feel like I've experienced or heard developers experience where they like this app but they want to change this one thing. And if only I could modify this one thing or tweak it. And it's like, yeah, sure, why not? know, everyone's brain works differently. They map to these, you know, visuals differently. Like... Brittany Ellich (27:26) you Erika (27:34) Why not provide a way for people to to collaborate but also customize? Brittany Ellich (27:41) Mm-hmm. Yeah. Yeah, I'm excited to see where it goes. I feel like it's starting to get like a lot of steam behind it now. And like there's a lot of moves being made and a lot of features. One of the things that they're working on this year is permission to data. So right now everything is just public in your repo, which like having something that is private or only available within specific settings is super important for like identity in general. So. Erika (27:57) and Yeah. Brittany Ellich (28:06) I think once that comes out, that's like one of the biggest pillar, like we need this to like really be able to expand into lots of different types of apps. But that's pretty close to landing. So it'll be cool to see where that ends up. Erika (28:18) Very cool. Well, we are beginning to wrap up. But based on this thesis that ownership, portability, decentralized control make things better, we are going to apply that logic to everyday non-technical things, maybe some technical things, and debate whether it holds. ⁓ Brittany Ellich (28:40) Great. Erika (28:42) So we can rate these systems on a scale of 1 to 10 of how badly it would benefit or reduce quality from getting the at-proto treatment of removing centralized control. So a score of 1 being like... Centralized control is very important to this service. Don't touch it. And 10 being, like this is human rights violation, the amount of control that this system has and it's disguised as a terms of service. So decentralize it. All right, are you ready? Brittany Ellich (29:14) I'm so ready. Erika (29:15) Okay, so we are gonna start with NPM. So NPM, for those who are not familiar, is a centralized package repository. And anyone can publish a package, and then developers download it, and anyone can also unpublish a package. So there was a package called LeftPad that... was unpublished and caused a bunch of issues for people who relied on that So what do think, Brittany? 1 to 10. Decentralizing NPM. Brittany Ellich (29:45) Ooh, that's a good one. So we're talking specifically about the registry, correct? Like where all of the packages live. Okay. Um, I was going to say, cause NPMX is came out recently and that is a really cool, I'm going to include a link to that. Um, but that's more just a website to view them, um, to view the packages. think for the registry, I feel like that makes a lot of sense to be decentralized. Yeah. I feel like that's a 10, right? Like, I think it might be hard to. Erika (29:50) Mm-hmm. ⁓ right, yeah. Brittany Ellich (30:13) handle security there? I guess if like anybody can publish a package like how would you deal with like rogue servers that are like trying to say like this is this package and it's not I don't know. True. Erika (30:24) But I feel like it's already that. There's very little oversight. yeah, I'm with you. I think decentralizing makes sense. Once you publish it, it's kind of like out there. I mean, guess app pro is a little different where like you... Brittany Ellich (30:30) Yeah. Yeah. Erika (30:45) you as the publisher would still own whatever you publish, so this would be a little different treatment of saying like once you publish it, it's like persistent and like you can't take it down. Yeah. Brittany Ellich (30:58) Yeah. But I think, I mean, a lot of those things are associated with like commit shaws and if it's open source, it just makes it hard if you want to like de open source something, but that's already a problem. I mean, how do you know somebody hasn't downloaded, you know, your open source repo to their computer or whatever before you decide to make it private or whatever? Like, I feel like that's already a pretty common occurrence. Yeah. Erika (31:14) Mm. Yeah. Okay. So we're on board with decentralizing NPM. Give it to the people. Let the people decide. Okay. GitHub contributions. So do we think that that like... Brittany Ellich (31:25) Yeah. Yep. Erika (31:33) you know, say you have all of your GitHub contributions and you know, maybe you want to like port that over to a different site. Like, do we think that's valuable? Brittany Ellich (31:45) Yeah, I think so. I feel like that's especially because that's like pretty commonly viewed as like a, you know, like this developer is this active or whatever. Having that, the ownership of your, at least like the record of the number of commits you did or like how much you contributed to the community or whatever. I feel like that is something that should belong with the individual. And there is, I know that there is one website that is working. something similar is called Tangled, like I mentioned. Although there I think that like the issues equivalent and like the social part is on at Proto and the rest of it's still using Git under the hood because I think there's like no way to replace Git at this point for that. Erika (32:13) Mm-hmm. and then move on. Yeah. Yeah. Cool. Yeah, I'm on board with that. I think it'd be cool to have that more shareable between platforms. Okay, let's move on to something that's not technical. Medical records. Brittany Ellich (32:35) Mm-hmm. Erika (32:44) So the way that this would look on that proto would be right like you have you have your medical records that are tied to you and instead of like your doctor owning your medical records and then having to transport those between whenever you go to a new provider like you would kind of own you would own those records. Brittany Ellich (32:44) Ooh. I feel like this would solve a lot of problems in like our healthcare system and also would be an absolute nightmare to any lawyer that is like familiar with like HIPAA things like the security around it would have to be very very advanced but I feel like this would be really helpful for like individuals especially I mean you don't live in the same place all the time you're not gonna go to the same doctor forever. ⁓ So having those be portable and in like at least in a format that's shared across multiple doctors offices would I think I think that would help a lot of humans not just like I feel like it would make the systems run faster and smoother and then the problem is is then you'll have to like rely on the individual to like maintain their own repository right because I mean it could Erika (33:29) Mm-hmm. Mm-hmm. I mean, theoretically, I guess like, yeah, I'm with you. Like, definitely this, like, privacy question would need to be figured out. Like, you wouldn't want your medical records all public for everyone, but like, medical records currently are so opaque to me that I have no idea where my medical Brittany Ellich (34:06) You Mm-hmm. Erika (34:12) And like, I don't necessarily want to like maintain or manage them, but like, it would be nice for me to be like, well, if I did theoretically want to look up my medical history, like, how would I do that? You know, it's like, it feels like it's so protected that like, even I don't know, even though they're theoretically my records, like, who do I ask to see that? Like, where are they? Brittany Ellich (34:32) Mm-hmm. Mm Yeah, it's a nightmare, especially for folks who have like, you know, need long term care or something like that. And they need all of their records in one place to like, especially if they move from one place to another, it's just a huge effort to gather all the data into one thing. so I think that that would be super beneficial, and worthwhile, but, yeah. Erika (34:45) Great. Yeah. And then you don't have to be like, when was my last checkup? I don't know. I think it was last year sometime. Like, it's just like there. Yeah. Yeah. So yeah, I think with the caveat that this would have more privacy controls, I'm here for decentralized medical records. And specifically personal ownership. Brittany Ellich (34:58) Mm-hmm. Yeah. Yep. That's true. Mm-hmm. Mm-hmm. Erika (35:15) Okay, last one, banking. Brittany Ellich (35:17) Ooh, I think this is interesting. There's a book that I read earlier this year by Tim Berners-Lee where he was talking about something called Solid Protocol. I'll share the book. But it is really similar to At Proto, but they started private first. So like all of the repos are private, but then like you can you to theoretically own your repository and you can bring that everywhere. those seem like the main differences from the way that it's described. And I think that they actually started that at banks and like really large, like enterprise organizations in Europe, which is where he's at. So there's probably different like regulatory environments or something like that where that is a little bit more favorable or worthwhile. But I think that there are some financial records that that would make a lot of sense. I'm curious. Erika (35:38) you Brittany Ellich (36:02) how that would work for things like, I don't know, taxes or whatever. Like you would need to share something with the IRS to be like, hey, here's how much I'm getting paid still or something. I don't know. I think that sounds really complicated and like the least interesting of these different examples. So I'll put that one as like a five or something. I'm sure that there are reasons to host it in some decentralized system, but it sounds hard. Erika (36:12) Hmm. Yeah. This one, this one I feel like I'm like a one on because of the timing and consensus because I think like that's when decentralization gets really tricky and like I just don't think there's any good solution like as of now like I've never heard any Brittany Ellich (36:29) Mm-hmm. Mmm. Erika (36:46) really good reliable solution for like decentralized consistency and consent like consensus with these sort of like real time transactions. ⁓ Brittany Ellich (36:56) There's blockchain people out there saying, hey, we've been talking about this. Erika (37:00) you Brittany Ellich (37:01) Yeah. Erika (37:01) I mean, yeah, still my, my feelings still stand. So yeah, that's, that's where I'm at. I think this is like one of the, one of the things that, yeah, I think I'm, I think I'm a one on. with like, I think there's room for like, maybe having a personal repository of like all my financial, like, Brittany Ellich (37:14) Yeah. Erika (37:23) things or whatever in a repository. Like this is my, this is like the link to my savings account and my 401k. like, cause that stuff does get confusing to keep track of, of like, I have a 401k or like I have a retirement account from when I was a teacher. And I'm like, I don't even know how to access that. Like I've tried to contact the school district and they like never responded. So like, I don't know if that money is just going to like disappear. Like, I don't know. But like that would be cool to like be able to keep track of all those different, those different like financial pieces I guess. But yeah, as far as banking goes, the whole system, I'm fine to leave it as is. Brittany Ellich (38:01) Yeah, yeah, that's not a thing that I would be like super excited to work on, I don't think, but you know, I'm sure there's, I'm sure there's a case to be made for it. Erika (38:06) Yeah. Yeah, Well cool, that was fun. So we mentioned we'll drop some links to OpenSocial, CollectiveSocial, and for people following your work, where is the best place for them to look for you and your work? Brittany Ellich (38:22) yeah, everything is pretty much linked from my website, including all of the overcommitted episodes. So BrittanyEllic.com is the, is the spot that has links to socials and blog posts and whatever else. Erika (38:34) Cool? Alright. Well, thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 58: There are no shortcuts | Craft & career growth with Salma Alam-Naylor - URL: https://overcommitted.dev/there-are-no-shortcuts-craft-career-growth-with-salma-alam-naylor - Published: 2026-05-05 - Audio: https://anchor.fm/s/102586d64/podcast/play/119495931/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-4-5%2F423482750-44100-2-86bcd0234ec9e.mp3 ### Show notes Summary In this episode, Erika talks with Salma Alam-Naylor about software engineering craft, programming best practices, and why the long game beats shortcuts. As AI coding tools proliferate and everyone chases speed, Salma digs into deliberate practice, sustainable career strategies, and building genuine expertise that compounds over time. Perfect for engineers feeling burnout from the hype cycle. Links * Salma’s website: https://whitep4nth3r.com/ [https://whitep4nth3r.com/] * 2021 Jamstack Jammies (Community Creator Award) https://2021.jamstackconf.com/jammies/ [https://2021.jamstackconf.com/jammies/] * Fat bear week website: https://explore.org/fat-bear-week [https://explore.org/fat-bear-week] * Hell.com [http://hell.com] wikipedia: https://en.wikipedia.org/wiki/Hell.com [https://en.wikipedia.org/wiki/Hell.com] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Erika (Eggyhead): https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host today, Erika. I met my co-host while working on a team at GitHub and we quickly discovered we were all obsessed with getting better what we do. So we decided to start this podcast to share what we've learned. 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 developers can learn and connect. Today on Overcommitted, we are joined by Salma Alam-Nailer. Salma is a web developer, international speaker, tech educator, and entertainer. Before she ever wrote a line of professional code, she graduated from the Royal Northern College of Music, played in bands, composed, taught music, and even did a stint in musical comedy. She pivoted into tech in 2014 and has been on an absolute tear since then. She is a GitHub star, a former Microsoft MVP, and spent five years as a partnered Twitch streamer where she built a live chat-controlled game that her community could play in real time. She recently wrapped up that chapter and is now head of developer education at Nordcraft. She also has a newsletter called the Weird Wide Web Hole where she sends subscribers four strange links every Thursday. No further explanation needed on that one. Salma, welcome to Overcommitted. Salma (01:29) Hi Erika, thank you for having me and welcoming me to the podcast. Erika (01:33) To kick us off, what's something you're currently building or learning that has you excited right now? And this can be tech or it can be a drum piece that you're learning, anything that lights you up currently. Salma (01:47) For the first time in over a decade, I'm actually writing a new song that I'm going to release in the next month or so. And it's hard, like, so I did composition at music college, know, writing music was my whole thing. I wanted to be a film composer actually, initially. And I think I still do, but that's a long story. And for all the parents out there, as you know, when you have a child, your life and things that you want to do kind of like go out of the window for a while. My child is eight now and I think I'm starting to get a little bit more time to myself to do my hobbies and what I want to do. But I felt like there's been lots of music inside me since the pandemic actually, the early pandemic, I've had stuff inside of me but it hasn't manifested. But now ⁓ I'm inspired and I'm doing it. I'm ready and it's almost finished and I'm gonna make a music video and I'm gonna release it. I already have a new website and a domain and everything that I'm gonna put it on. So that's what I'm really excited about actually at the moment. Erika (02:52) That's so cool. I can't wait to hear it. Yeah, that's gotta be, I know that feeling where you have something inside and you wanna get it out, you wanna get it to the world. And yeah, how cool that you're kind of reconnecting with that and bringing it to life. Salma (03:03) Yeah, it's giving me life actually. And I feel more like myself than I ever have in the last 10 years. So this is a good thing. Erika (03:13) Yeah, awesome. And that's something that, you know, kids will look at and know for years to come that you're doing this too. Salma (03:22) My son actually, I've showed obviously my family previews of the song and my son is walking around the house singing it already. So that's a good sign. Erika (03:31) That's good. My daughter is solidly in the mommy don't sing phase. ⁓ Like, anytime I open my eyes, it's like, no, stop. It's my turn. Yeah. Well, awesome. So you sort of made your name doing something that, to me personally, incredibly terrifying, which is live coding. This is, you know, Salma (03:36) no. then there. Erika (03:53) where you built an international following, you describe it as something that transformed your career in tech. So was it intimidating for you? Or did your kind of background as a performer make it feel natural? Salma (04:06) think right at the beginning, yes, it was intimidating. It was scary to go live. remember like the first time, the first few times I went live, was, I mean, it wasn't as scary at that point, because there were like three people watching me. So it's just, I don't know, weird. But quickly I realized that when people are watching you and you are there, pressing the buttons and speaking and stuff, you're the one in control. And I could control how long I stayed live, what I was doing, what the topics of conversation were. And as soon as you realize you have the captive audience and you are in control, then it doesn't really become a big deal anymore. And I do obviously attribute that to the fact that I was a teacher, I was on stage, I was a performer. And so naturally throughout my whole life, Erika (04:31) Mm-hmm. Salma (04:55) I'd been in front of big audiences. I was also actually in a folk band in my early twenties and I played some very big festivals and stuff for thousands of people. The light's so bright that you couldn't even see who was out there. So a lot of the time actually when I was streaming, I kind of felt like I was back on stage doing that. And I must say, I do miss it, but I'm going to answer why I stopped in your next question. Erika (05:06) Yeah. Yeah, I mean, that's good to kind of know, you know, where you started and sort of your experience at the very beginning. then I'm sure, yeah, you're already talking about it kind of transformed for you ⁓ throughout the years and then, yeah, you stopped. can you kind of walk me through the journey, how it changed and then your decision to end it? Salma (05:40) Ahem. I mean, I think the reasons are many fold, but the main reason was, so I initially like broke into DevRel or whatever people call it now because I became recognized as an educator and developer through Twitch. And I met people who knew people and stuff. And in the early days of that part of my career, it was still pretty much locked down everywhere. And so it was a very valuable skill to be able to get on stream and talk to an audience of developers. Previously, before 2020, you would have been going to events or speaking on stages. And the landscape of DevRel really, really changed then. And being a prolific... good streamer was seen as being a valuable asset to a dev rel team at the time. And, you know, and I got my first two dev rel jobs basically because I was a good streamer and lots of people watched me and I was building fun stuff and we were having a great time and it was different to all the other streams that were going on at the time who that were very kind of a lot, you know, I think it still happens now, but there's a lot of people who will turn a stream on and leave it there for six hours and just pretty much go about their day. But I made sure to put on a show every time I went live. It was more of a time box, like we're gonna do this today and I've got all these flashy things and flashy lights and we're gonna be entertained and you're gonna learn something at the same time. So rather than like more co-working, it was just, I'm going to do a thing. But as time went on and you know, Erika (07:21) Mm-hmm. Salma (07:25) we kind of moved out of lockdowns and COVID, and COVID stuff. Businesses and DevRel teams and marketing teams in particular wanted to make sure that those activities were providing value. And DevRel Developer Relations is notoriously hard to provide concrete value, especially monetary value ⁓ evidence. because of the nature of the activities. And, you know, I was in departments where, you I was streaming three times a week and people were counting my views and ⁓ audience numbers and, you know, really just to try and justify me seemingly having too much fun in my day job because it was fun for me as well. Erika (08:11) Yeah. Salma (08:12) And then when those numbers started to be tracked and things, then the pressure came a little bit more. But I really had very little control over those kinds of numbers because you have to take into consideration time zones. The discovery of your streams on things like Twitch. Notoriously, Twitch didn't really spotlight software and development streams, especially in the early days. And then it became kind of like, oh, well, what's the point in doing it anymore? Because I don't want to get fired. And, you know, it was like, I was told very specifically one time, we pay your salary, so you shouldn't be having fun on Twitch. And it was like, hmm, okay. And then AI came, right? And then it was like, people aren't tuning in to these kinds of streams anymore. And it's funny, I haven't streamed, I didn't stream much in 2025. And my brand of streaming was always based on the struggle that I went through to show an authentic, genuine experience. And a lot of the viewers would always comment that, I thought it was just me that struggled with that and things like that. So I wanted to make it really raw and real. But now things have changed and... number one, people are not coding in the way I used to code on stream much anymore. And so I think if I went live now and did what I always did, I would get a lot of silly questions about why are you doing it like that? And why aren't you using AI? Why aren't you just generating your app rather than the hand coding your HTML tags and things. And I just don't think I wanted to deal with that. But also I think that the landscape of what developers want has changed. Erika (09:43) Yes. Yeah. Salma (09:57) Back then, when I first started, it was about, we can't go outside, so let's find a way to hang out together and find a community together. And now life is pretty much back to normal. And so it's kind of flipped the other way around and people don't tune into streams in their workday anymore because they're back in the office. And I'm not saying that I just stopped streaming because my numbers went down or people aren't watching me, but it's like the landscape is so different to what it was in 2020. that I just felt that it was time to remove that cognitive overload of I'm a streamer from my brain and from my desk. You know, I got rid of my streaming PC, I sold that and I streamlined my office. And it was just time for something else. And I'm fond of that time, but I also feel like it had run its course. And I think that's also a good example to set for. Erika (10:26) Yeah. Salma (10:51) the community out there. It's like when things aren't serving you anymore, when things don't make you excited anymore, it's okay to stop and move on to something else. And who knows, maybe if I hadn't have stopped streaming, maybe I wouldn't be writing a new song right now. you know, it all, it all, it's all connected. Erika (11:05) way. Yeah, yeah. I mean, yeah, there's like so much there. And I think my first reaction is like a twinge of sadness, not for you necessarily. yeah, I definitely see the value in like, like turning over a new chapter, starting something, but in order to start something, you do have to stop something, you know. paying no attention to the name of this podcast being overcommitted where you keep adding to the plate and never take anything away, I think in order for it to be sustainable, you do have to take something away. it's sad to me that the sort of like pressure of monetization and also scale are kind of the first two things that you mentioned as taking the fun away. I mean, and also AI. like, mentioning the developer landscape, like, I'm sitting here thinking, like, I love watching people write line by line and explain their thinking step by step. Like, yeah, I would never tune in to somebody auto-generating code. Like, to me, it's like, why? Why would I watch that? Salma (12:21) This is another thing though that I discovered whilst I was streaming. There's a large proportion of people out there who have been led to believe that there are shortcuts to ⁓ building stuff and this kind of thing. The amount of people that came in to the stream and asked me, how do I become a web developer in six weeks? And how can I get a job in six weeks? I'm a beginner. And it's like, that's a whole, whole different ball game. And Erika (12:39) Hmm. Salma (12:47) you need to be able to put in the work. And I think that's another thing that I wanted to demonstrate, putting in the work does reap you benefits. And I think, I don't know, it's the landscape of, the developer landscape is quite a strange one at the moment. And I feel that so many things are being pushed. by big companies that like the real authenticity of the real people, the real developers who working in this industry is kind of getting like overshadowed by this big stuff and this desire for shortcut. And every company and every tool is trying to provide you with a ⁓ quick win and a shortcut. And I just don't believe it's sustainable. And I guess I didn't want to have to keep explaining that. over and over to the more and more people who were coming in to the stream also to have that kind of discussion. And I felt like maybe I could direct rather than to talk about that to like 60 people at a time, I could direct those kinds of efforts to something that might have a bit more impact. might scale a bit more. It sounds a bit silly, but I think you do when you want to make an impact like I think you do have to be strategic about how you do it and when you want to help people I think that's it sounds silly but strategy also comes into that and like how can you reach the right people and how can you give them the help that they need and streams are very ephemeral you know that they exist for that time and people aren't really going back to watch streams either So that's like four hours of effort and live show and education that yes, I could cut it up into a YouTube video, which I did experiment with for a couple of years, but like nobody watches those either because you have to be there for the live show. You know, because of all the stuff that was going on on my stream with all the things raining down and the alerts and the sounds, that gives you the real experience of the stream. And you kind of couldn't communicate that in like a cut up clipped video either. And so, the ephemeral-ness of streams, think it's not a wasted opportunity, but it's also how can you take that and direct that energy to something that's not so ephemeral and not so fleeting, if it's really important to you, do you know? Erika (15:11) Yeah, well, let's dig into that because you won a Community Creator Award from Jamstack in 2021 and... Salma (15:23) That's an old word, isn't it? No one really talks about that anymore. Erika (15:28) And part of what's cited in your award is your commitment to helping the community with improving on diversity and also reducing the toxicity of internet communities. What does that mean to you in practice? know, that's, yeah, what do those kinds of words mean and what did that mean to you at the time or now? Salma (15:57) It was just really about being nice to everyone and anyone and regardless of their attitude or demeanor as well, know, little things like people would come into the stream and say, why are you using this framework? Why are you not using that framework? And here is a great opportunity to actually discuss why that's a silly question. And also have you considered that maybe Erika (15:59) Mm. Salma (16:23) when you ask this type of question, what other kind of things are you implying? Like, oh, you're using a bad framework. That means you're not good enough. And what was really nice was that everyone who was watching at the time as well would always try to educate that person in the same way and a great conversation will come out of it. it's like the tech pits so many things against each other. It's always X versus Y. It's always this versus that. This is better than this. You should be using this now. Otherwise you're being left behind. like those things are irrelevant. It's what you do with the tools that you use and it's the outcomes and the impact that you make. And I guess that was the underlying message of everything. And that's why so many times I just started new websites with an HTML file. And of course I would get like... Questioned for that all the time. Why aren't you using a framework? So I don't need one. Like I don't need one and here's a great opportunity to tell you why and And it's also as well as those kind of things. It's just about modeling the good behavior Not getting involved in in all the drama. It's weird. Actually I haven't maybe because I've muted so many things on the internet But I don't really see much tech drama these days, which is quite nice Erika (17:24) Yeah. Salma (17:47) And it's about like distancing yourself from that. Cause people would always try and ask me, what do you think about this? I'm like, I have no opinion actually. I'm not going to get involved. And you know, maybe that's also a thing that comes with age. I don't know. But so it's about being nice, modeling the good behavior, not getting involved in the drama, and then also celebrating the good stuff, lifting people up. And a lot of that comes with working behind the scenes with people. And it's not about doing it in public. You know, I've mentored quite a few people. I've connected people with people to get jobs. I've, you know, helped them with their portfolio and their resumes and things like that. And, and obviously, those are the kind of things that are going to make like impact for individuals, which I've always prioritized. Like I've always said, like, if I can help just like one person. do something that they wanna do and achieve something and to help them on their way with whether it's just introducing someone to someone or looking at their website, then by all means I'm gonna do that because people did that kind of stuff for me early on. I wouldn't be here if I didn't get connected from one streamer to her friend who was hiring. And... And I just want to give that back because people deserve the chance and it's hard out there, especially with all of these algorithmic feeds and people gravitating towards the drama and stuff. Like your portfolio is not a drama piece and no one really cares, but actually I'm going to help people care because I think people deserve that level of respect. And it's just... Erika (19:27) Yeah. Salma (19:31) I don't know, like it's hard to say these are the rules I live by because obviously every situation is different, but I just try to be nice and helpful to people whenever I can, whenever they ask me. And that pays dividends in the end, you know, because maybe I'll get a favor again one day, you know? And it's not as if I do it to get favors back, but like everyone helps each other, like behind the scenes, everyone. comes together in this kind of underground community to help each other, which I think is wonderful. And I just don't think I'd be here without that either. So ⁓ thank you to anyone who helped me out. Erika (20:11) Well, yeah, that shows some real strength of character too to get those kinds of comments and then not shrink or not, not really, I don't know, return the anger or frustration. yeah, I mean, I also used to be a teacher and I always found that in my classrooms there was always one kid, like there's always that one kid in the class who's like acting crazy. You you come to class every day and you're like, well, I know it's going to be fill in the blank, you know, and you kind of like expect that as a part of life. But yeah, I mean, on the Internet, it feels amplified to a certain degree because you don't have that face. You don't have that that personal connection. But it sounds like part of what you did is build that personal connection with these people. And that's Salma (20:56) it you Erika (21:03) really the only way to move forward with those things. Salma (21:07) Don't get me wrong, like at the beginning, it was sometimes tough when I would get, you know, sexually harassed on Twitch streams and stuff, you know, and it was tough. And I was, you know, I was a lot younger then and I hate to say it, but I think it helped me develop a resilience for that ⁓ as time went on. Erika (21:16) and then. Yeah. Salma (21:30) And it's just about remembering that you're in control. And these people who are acting in this way, they are the ones who are hurt. They are the ones who are in need. And I kind of started treating people like that, like a child, because children don't know things. And they'll say things and you have to kind of, you know, educate them and talk to them sensitively and with compassion. and with curiosity and I think becoming a parent, when I first started streaming, my child was two. And I think, you learn a lot when they start to become their own person. And so I think in tandem, being a parent, learning how to deal with things like that, coupled with the teaching experience and just the resilience that it helped me build through doing it for so long. I think all of those things helped. people will ask me, know, how did you do this? How did you do that? What's your recipe for this? What's your rules? And it's like, well, it just happened and things just happen and everyone's situation is gonna be different. So don't take any of my advice really. Find your own own way. I don't know, maybe you can, but I always feel strange giving out advice because I just, things just happened and I dealt with them and I grew as a result. Erika (22:49) Well, I will, I am going to ask you for your advice. I guess for people who want to make the internet a better place, what would you tell them as far as like, can you do this as a part of your day job? Is this something that you have to do, you know, through open source or something else? Like what's kind of your thoughts there? Salma (22:53) Okay. The tough thing is, that the, on the internet today, it is tough because of the mental overheads of everything that you see and that is put in front of you, which can exhaust you greatly. And so the first bit of advice I would say is make your own experience of the internet better first. and you know, unfollow things that make you rage inside, ⁓ mute profusely, block and don't engage with any of those things that are taking up your time and causing negativity. And then I think once you do that, and it's hard, right, it's hard, but once you do that, I think then you make for yourself the thinking space and the breathing space to think about the next thing. What could be the next thing? What could be better for us? You know, avoid algorithmic infinite scrolls and and then your brain will recover from the damage that that's doing and then you'll have more time and energy to think about what you want to get out of it because maybe what I want the internet to be is not what the next person wants the internet to be. But the joy of the internet is that it can be anything for anyone. There are so many different corners of the internet that you can explore and find a home on, you know, IndieWeb, you know, like weird links and weird places and forums and small little communities, you know, and it's gonna be different for everyone. But ultimately it starts with... curating your own experience, you know, maybe move to RSS instead of, you know, infinitely scrolling, TikTok or whatever. But like it, it's been, it's been forced on us for so long now. I think social media is probably one of the most damaging things that has happened to the internet really. And I actually remember watching the documentary or some video about the, person who invented infinite scroll and they deeply regret it. Erika (25:30) Mm. Salma (25:30) And so I think we, unfortunately though, that the tech industry and all those kinds of products on the internet have created for us these problems and now they're trying to sell us the solutions, wellness apps, dopamine, detoxes and whatnot. it's the whole, it kind of mirrors the whole. Erika (25:44) Yeah. Salma (25:55) you know, as I'm a middle-aged woman and I'm now, if I see adverts, they are targeting my age and depleting estrogen and no, wrinkles. These are problems that don't exist. These are manufactured problems that you are now being sold a solution to and the internet and social media is no different. And it makes you feel bad when you have no right to be made to be feel like that. So curate your own experience and then, and also understand that there are no shortcuts to any of this and ⁓ it can't just be made better overnight. But it apparently, I shared a video in my newsletter today and apparently it only takes 25 % of a mass of a group to tip the scales the other way to something better or something different. And with that in mind, if we can just get 25 % of us to curate a better internet, to create a better experience in our little corner of just 25%, then maybe change will happen. Erika (27:00) Well, that gives me hope. Salma (27:02) That was the title of the video actually, there is hope. There is actually hope. Erika (27:04) Yeah, there is hope. Well, speaking of no shortcuts and carving your own path, I mean, your career journey is taking so many turns. And my first question for you is how do you balance all of your creative pursuits between your writing, your recording, your speaking, your coding and Do you enjoy one more than any of the others? Salma (27:35) Now again, there are no rules for how I operate. So, tell you a little story. Whenever I want a new tattoo, I want it now and I have made the decision, so I'm gonna get it. And obviously I have to book in with my guy and it takes a few months, but I have made the decision and I'm gonna do it. That is how I operate with every creative pursuit. I suddenly get the inspiration and I'm gonna do it. Like at the end of 2025 I said, right, I'm going to redesign my website. So I went hard in two weeks, redesigned my whole website and I lost sleep. I dreamt about it. I worked all hours on the weekends and the evenings because I wanted to do it and I did it. That's the job done. Great. It doesn't last for months and months and months. It just happens. Next. Oh, I want to make a website for my drum transcriptions. Right. I'll do that in a week. Erika (28:26) Mm-hmm. Salma (28:32) I'll just do it and I'll spend all this ridiculous time on it. Obviously I had to have a break in between my website redesign and the drum website because otherwise I would have died. That's the thing. I do these stints of thing and then I have quite a bit of a break and I make sure to take care of myself. And then I do another thing. And then now my next thing is I'm writing a song now. So, and I'm gonna do it and I have to do it and I'm gonna give myself this time. Erika (28:39) Yeah. I'm going to go to Salma (28:57) I'm gonna release it by the end of April. I'm gonna do it and I'm gonna plan my life around it. I plan my life around getting to do these creative things and Maybe I'll skip a yoga class on that normal day because I really have to get to this point It's like I do like little sprints with myself if you can call it that And so I I don't balance whilst I'm doing the thing Erika (29:12) God. Salma (29:22) because I am in the moment and I don't want the energy to leave me. can't leave it or I will implode. So don't follow my advice because it's probably not very good, but that's just how I've always operated. And then maybe I'll be like barren of ideas for six months, but then when the next one strikes, I will go 100 % in it full-time, obviously work, parenting, exercise, all that other stuff. Erika (29:32) Mm-hmm. Salma (29:50) but that will be the only thing on my mind. And that's just how I operate. Erika (29:55) No, I mean, this is very freeing for me because I feel like this is also how I operate is, but I don't think I've thought of it that way. But I need that push. I almost need that pressure of the mental coach in my head being like, no, you need to do it. You need to get this done and then this done and then this done. And if I stop, it's never gonna get done. Salma (30:21) because otherwise it will consume me. If it goes on for six months, I try to keep as few things in my brain as possible because I have a very multi-threaded brain, but there's a limit. And so I take stuff out to put more stuff in. if I, because if I, Erika (30:29) Mm-hmm. Mm-hmm. Salma (30:50) try and do a creative project over like six months, I'll have another idea and another idea and another idea and I want to start it and the other thing will get pushed out, which means I don't finish anything. But I like to finish things and just have them done. Even if they're not finished finished, even if they're slightly imperfect, they're still like, I'm gonna say that's done. And I think that's one of the reasons why I stopped streaming as well because I wanted that to go away and be done. Erika (31:01) Yes. Salma (31:14) so I can do the next thing. Because it was always on my mind. It was always there thinking, oh, I should do a stream. Oh, but I know that when I turn my computer on, that everything's going to be needing updates and it's going to break everything, which is another hour of my time loss. You know, there's all these like layers of like cognitive threads and overload that crowd your minds and kind of make things a little bit hazy. And so... That's why I like to just do something and then it's done. And then who knows if I'll ever write another song again, but I'm definitely gonna finish this one. I've got this vision. It's all like formed in my head. The music video is formed in my head and I just want to be able to get to a point where it's done and I can do it and I can say I did it. And I think that's another thing that people struggle with is the wanting things. to be so perfect and good and respected and appreciated that they spend so much time not doing it. And I've always been the opposite to that. I just, I will do it. Even though people would always say I'm a perfectionist, I don't think I ever was. It was just, I had attention to detail and the detail often... Erika (32:16) Mm-hmm. Salma (32:31) got things confused when I was working with other people. I don't know, I don't know why I'm talking about this right now, but just don't be a perfectionist. It's not worth it. Cause 99 % of the time people aren't gonna notice those things that you notice. And I think that's good life advice really. Maybe that's one piece of advice you could take from me. But like when you're being creative, like nothing's ever perfect either, especially like, and this is one of the underlying fundamental concepts of being a human. is that you cannot achieve perfection. And actually the beauty is in the imperfection. And the appreciation will be seen, especially in this age of AI and blah, blah, blah, blah, blah. Like the beauty is in those fallible bits of stuff. Like just keep a typo in or keep a wrong note in or just like prove something, prove that this thing is human. Erika (33:20) break. Salma (33:25) And I hate that we have to do that, but like also that's the beauty of it. And it's like going to a live performance when there's a mistake made, you know, it's like, that's, I was there for that, you know, and it was real and it was raw and it was authentic and no one cares either. Erika (33:34) Yeah. No, yeah. As long as it's done with heart and genuineness and, you know, like you said, I mean, yeah, the attention to detail thing. I think I've also been labeled a perfectionist at different points in my life and I don't see myself that way. also, I'm very comfortable with certain, like little mistakes here and there that, you know, maybe I can kind of live with. I think... There is a bit of a musician mindset where you recognize that things can't be perfect all the time. You're you you might have a performance and you're not going to have all the time that you want to practice. But like going back to this, there's no shortcuts. Like you can't AI your way into playing piano or playing an instrument or anything. And you do have to pay attention to every detail. Like even if you don't get all the notes right in the moment, you have to practice them. have to, you know, there's things that are hard and you have to work through them. ⁓ Salma (34:41) That's the thing as well, like I think code and music are inextricably interlinked. ⁓ I mean, anything that is a creative pursuit is, but I think particularly music and coding, you have to practice, there are no shortcuts and you have to embrace that, embrace, it's about the process. Erika (34:46) Yeah. Salma (35:00) It's always about the process and I think as a society, as an industry, we are getting so focused on the end result when actually the process is what is the most important part because it's what leads us to discover things, discover new problems, new solutions, new ways of thinking. People don't like to experiment these days because they just want it now. They want... and a thing, they want an app, a website, they want it now. And like, that's not how life works. I actually used to not really believe in the long game. know, I was very, well, if it can't be done now, then I'm not gonna bother. But the older I've got and the more experience I've gained, like the long game really is the play. It's like, if you have a vision for what you wanna do, do or where you want to be in five, 10 years, you can start now. And every little thing that you do can go towards achieving that. And you have to be patient. you know, I didn't get to where I am in any shortcuts whatsoever. And I'm thankful for that because the things I've learned, the people I've met, the network I've built, the... the things I've learned about myself and the things I've been able to communicate to other people and my child and and I think we cannot underestimate the power of time and experience and connection with other people and I think one of the things I've been thinking about a lot recently is that we are in this age of how we just talk to computers all day rather than each other. Like we're losing that conversation and the discovery through conversation and the discovery through different viewpoints. And I think that's sad. And I think that is quite dangerous for the future because we cannot have all the answers as a single person. And we do need to listen to other people and to talk with other people. from all different places and walks of life and experiences in order to make a better future. Erika (37:19) the other thing that comes to mind for me as far as maintaining some kind of direction over a long period of time or creating something that's worth anything is the why as well. And to me, it's so clear. Hearing you talk about tech and hearing you talk about your experience and your vision for the internet, that is core and central to what you do is a strong sense of purpose. Salma (37:51) The why can also just be because you want to. Like I'm writing a song because I want to. I'm not writing a song to change the world or change anything. I'm writing a song because it's a thing that I want to do. That's all it is. Like it's not for anyone else, it's for me. And so there can be things that you do that are just for you and that's okay. You don't need to do X, Y, Z for this, that and the other for free, for no money. You don't have to like... You don't have to be exploited by the industry to get anywhere. And you can just do stuff because you want to. And that's another thing that the internet is kind of clouding our brains with is that it's only worth doing something if you're gonna get a thousand views or loads of reposts or loads and loads of followers. I think we're kind of starting to see a bit of a shift or maybe it's just like the fact that I surround myself on the internet with the people who don't care about that stuff. But, you know, I think the grift is fake. You can't achieve anything meaningful with that kind of approach. And also people see right through it, like the real people, they see right through it. so do stuff for you and then the people will come because... Erika (38:50) Bye. Salma (39:09) There are, guarantee you, there are people out there who feel the same things as you do. You know, I released an article that I wrote in a rage a couple of weeks ago and I just wrote it because I wanted to get it out of my head. I decided I was gonna do it. I wanted to write my thoughts down, some therapy, right? But there are a lot of people who agreed with what I said and a lot of people who felt the same things and who couldn't put those things into words. But I did it for me. But it just so happened that other people... Erika (39:33) and Salma (39:36) appreciated it and resonated with that. And so, you know, if you start with what you want and what you are and unapologetically, within reason, if you're a nice person, just be nice and yourself, then you will find your people. Erika (39:52) Well, with that, I think that's a great place to end it and move on to our final section, which today we are closing out with a little game. So each of us in this game has 30 seconds to pitch a weird website that we love as if it is the most important thing on the internet. No explaining what it is upfront, no context, just the cell. And the other person gets to decide if they would visit this website. So I will go first and then you get to close us out. Since you curate weird corners of the internet for a living, I am fully expecting you to win. But I do have a website that is near and dear to my heart. So here I go. So let me tell you about Chunk. He is a force of a bear who in 2025 won the Fat Bear Contest. despite having a broken jaw, likely from a fight with another bear. Then there is bear 910, who is officially described as a rectangle and a cruise ship. And this wonderful collection of bears drew over one and a half million votes in 2025. And this is a competition where it's a single elimination bracket tournament. like March Madness, the bears are identified by number, sometimes only get a nickname, and to qualify, a bear must be photographed the beginning of summer and the fall, so you can see all of the bears in their previous and extremely fat states. And there's even a junior division called Fat Bear Junior for bear cubs. Chunk came in second two years in a row, but this year he won. meaning he has a whole redemption arc. And that is my website, the Fat Bear Competition website. Would you visit my website? Salma (41:49) Yes, but only to witness the spectacle because I have no idea what I would be letting myself in for. ⁓ it sounds like I'd be extremely confused, ⁓ but it sounds like a good time. Erika (41:56) Okay, I will send it. Ha ha! Yay! Excellent. It is a good time and ⁓ chunk is very very chunky. It's real bears. Yeah it's a it's a national park in Alaska and they put up webcams and yeah there's a yearly competition of the fat bear who wins. Yeah. Salma (42:12) Is it real bears? I love it. That's really cute. That's really cute. so yeah, cause when they come out of hibernation, they're not fat. And then they get, ⁓ cute. Cute. Erika (42:32) Yes, exactly. Yes, yeah. And then they all fatten up and you get to choose the fattest, the fattest bear. Salma (42:40) That is cute. Yeah, that's that. Yeah, send it on. I am all for the fat bears. Erika (42:45) ⁓ All right, awesome. Your turn. Salma (42:47) Okay. Imagine a website that you cannot navigate, yet you can travel through. You can discover art. meaning cryptic descriptions of life. You don't know where you're going and whether you'll ever come out, but you must go deeper in order to understand what this is about. And you will still emerge from the other end wondering if it was all a dream or if it even happened or whether any of this exists at all. Erika (43:29) I am very intrigued and would definitely visit this website. It's giving me like Encyclopedia Britannica 1994 software vibes. Salma (43:46) So funny you say that because this website doesn't exist anymore, but it was born in the 90s. was called, now, this was one of my first experiences on the internet and it shaped a lot about how I see the internet and how I want to use the internet and what I want to build on the internet. It's called hell.com. Erika (43:50) no! Mm-hmm. Salma (44:12) Now there is a Wikipedia article about hell.com and actually a couple of years ago, I tried to recreate hell.com. ⁓ But it wasn't as fun when I was creating it because the whole point is that you had no idea what you clicked on, what it would do or where it would go. And it changed all the time. And it was like random stuff and you didn't, it was the... Erika (44:17) I'm sorry. Yes. ⁓ God. the lab room. Salma (44:39) pinnacle of being on the internet in the nineties. So read up about it, hell.com. was just, it was so incredible. And I want it to come back to life again. But if I built it, it wouldn't give me the same wonder because I'd know what I did, you know, and I did have some fun with recreating some of it. Like I actually went on the way back machine and then I took some journeys from it and I recreated those journeys. Erika (44:41) man. Okay. Rude. Salma (45:06) on an Astro site and it was great. can't even remember whether it's still live on Netlify or whatever, but don't know. But read up about it and please someone rebuild this kind of experience because it was so incredibly entrancing and it's what like got me really like hooked on the weirdness of the internet and how fascinating it can be. But it felt a bit dangerous, you know, like you didn't know what was, but that was. Erika (45:16) Guys. Yes. Salma (45:34) But it wasn't, it was completely not dangerous, but it felt that way and it was exciting. And especially as a teenager, when you don't know anything about the world, you think you're doing something wrong when you're like navigating the kind of website like this. And it was just, was, I will never forget it. I will think about this till I die. Erika (45:51) Ugh, I love it. Okay, well, yes. And you know, the chaos element could be like multiple people contribute to it and then you don't know what somebody else built. So yeah, yeah, we can all jump in on rebuilding it together. Salma (46:02) Yes, yes, yes, yeah, yeah. We can go for it, yeah. No code reviews because you don't need to see what's being done. Just YOLO merge everything, Erika (46:11) No. Absolutely. All right. Well, where can folks find you on the internet? Where's the best place for them to look? Salma (46:22) Everything's on my website, whitepanther.com, whitep4nth3r.com ⁓ or bluesguy. I've got a YouTube channel, I do some kind of stuff. But also ⁓ please subscribe to my newsletter, which you can do on my website because that is when you will hear about the release for my new song. Erika (46:39) Hmm, very cool. Well, thank you so much for joining us and thank you listeners for tuning in to Overcommitted. If you like what you hear here, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky as well and share with your friends. Until next week, goodbye. Salma (46:44) Thank you. --- ## Episode 57: Build Real Tools, Skip LeetCode: Systems Programming for Career Growth with John Crickett - URL: https://overcommitted.dev/build-real-tools-skip-leetcode-systems-programming-for-career-growth-with-john-crickett - Published: 2026-04-28 - Audio: https://anchor.fm/s/102586d64/podcast/play/119149587/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-3-28%2F423012014-44100-2-e41f53f1fda7a.mp3 ### Show notes Tech careers don't need to mean grinding LeetCode. In episode 57, John Crickett — 30+ year engineer, Coding Challenges creator (90K+ subscribers) — makes the case that programmer productivity skyrockets when you build real tools instead. We dig into why your own Redis, Git, or shell beats practice problems, how Coding Challenges went from $17 domain to viral sensation (1,500 signups in one weekend), and what it means to level up through systems programming. Links * Coding Challenges (Newsletter): https://codingchallenges.substack.com/ * Coding Challenges Website: https://codingchallenges.fyi * From The Challenges - Git: https://codingchallenges.substack.com/p/from-the-challenges-git * Will AI Kill Coding?: https://codingchallenges.substack.com/p/will-ai-kill-coding * Using AI To Solve A Coding Challenge: https://codingchallenges.substack.com/p/using-ai-to-solve-a-coding-challenge * Tech Lead Journal #178 — John Crickett: https://techleadjournal.dev/episodes/178/ * Confessions of a Data Guy — What Makes Great Engineers: https://www.confessionsofadataguy.com/decades-in-software-engineering-what-actually-makes-great-engineers-john-crickett/ * Coding Chats Podcast: https://open.spotify.com/show/59GU7gzyK2RdIDVkhNS2nt * John Crickett on GitHub: https://github.com/johncrickett * John Crickett on LinkedIn: https://uk.linkedin.com/in/johncrickett * John Crickett on Bluesky: https://bsky.app/profile/johncrickett.bsky.social * John Crickett on X: https://x.com/johncrickett Hosts * Overcommitted: https://overcommitted.dev * Bethany: https://trustyduck.dev * Brittany Ellich: ⁠https://brittanyellich.com [https://brittanyellich.com] * ⁠Erika: ⁠https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:01.434) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Bethany, and I'm joined by... Brittany Ellich (00:10.119) Hey, I'm Brittany. Erika (00:11.875) and I'm Erica. Bethany (00:14.042) We 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've learned. 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 John Cricket, a software engineer with over 30 years of experience who's on a mission to help developers level up by actually building things. John is the creator of Coding Challenges, a weekly newsletter with over 90,000 subscribers that gives engineers real-world projects to build. Think your own Redis server, your own Git client, your own shell. He's also the host of the Coding Chats podcast and has some really thoughtful takes on how AI is reshaping the craft of software engineering. Welcome, John. John Crickett (01:02.958) Hi, thank you for having me and thanks for the warm welcome, Bethany and Brittany and Erica. Bethany (01:08.886) Absolutely. So excited to chat with you. To kick us off, is there anything you're currently building or learning that has you excited right now? John Crickett (01:19.882) many things, many things. How long have we got? Bethany (01:24.208) We got all day! We can edit. John Crickett (01:26.658) So, okay, well, I'll try and cover a few of them then. So AI, I mean AI is why I got into software engineering, not software engineering, I got into programming 40 years ago when I was a nine-year-old kid, because I wanted to create AI. And nine-year-old with computers in those days, wasn't going to get very far, so always been passionate about AI. So always happy to learn more about that. And it's a massive field. It's only a small subset of computer science, but... Computer science is big enough you could never learn it all. AI is still big enough within that niche you could never learn it all. So lots of fun things there. I'm also having a little bit of fun recently revisiting. Literally yesterday I started looking at Lisp. Language from AI, going back almost. What is it? 70 years nearly. Going back since was invented, I'm finally getting around to learning it. Thanks to a guest that's coming on my podcast shortly. Sent me his book, so that looks like a really fun way of learning about it that I'm digging into. What else am I digging into at the moment? I'm trying to slowly learn Swift, build a project on Mac, build the first native app on Mac that I've ever done. And probably many more things. just, whatever takes my fancy. I'm a little bit drawn to shiny things and easily distracted. Bethany (02:45.231) That's awesome. I think that's part of the beauty of software engineering is the shiny things and especially how quickly our field is iterating, even now. What's so interesting about Lisp is, is that still relevant today with modern AI or is it more a relic of the past, would you say? John Crickett (02:49.751) You John Crickett (03:06.231) So I am far from the expert to ask about that. But I would say yes, it's still relevant. One of the beautiful things about Lisp is it's a very simple structure. And that lends itself really well, I think, to actually finally making genetic programming happen. So everyone's talking about LLMs at the moment. But one of the really cool things I think you could do, I think some people at Google are doing this, but I'm not sure, is you could write your code in Lisp with an LLM. Then you could use genetic programming ideas to evolve that code and know that the code you can abuse genetic programming would still be valid. I think that's one of the big challenges from 25, 30 years ago when I last looked at genetic programming, was how do you produce code when you do crossover and the mutations that's still valid? Well, Lisp lends itself well to that, but everything was too slow 30 years ago to evaluate it. Now with an LLM to generate it and modern computers, I think you could actually do something interesting there and... I think people from Google are, but I'm not certain. Bethany (04:05.441) That's really interesting. We will make sure to link to your podcast. So if anybody's interested in learning from the list back for it as well, they can follow along. Awesome. So staring back to coding challenges, I understand you started it back in 2023 while you were learning Rust. And now it's over, like we mentioned, 90,000 subscribers. And it really focuses on this idea that engineers should level up by building. tools that they interact with daily. like Redis, Git, Shells, things that we interact with as software engineers rather than grinding those algorithm problems. Did you have a moment, like an aha moment that made you realize that this was a approach that resonates with people or was it something that you have always been drawn to? John Crickett (04:58.221) So I've always followed this approach. I've always hated, you know, I learned programming from a textbook because I'm old. You know, I hated opening a book and they'd say like, like this factorial function, know, another factorial function. I want to like something more interesting. So, you know, I grew up learning to program by trying to like AI, which of course didn't ever far and trying to do computer games, which is the other thing because, you know, back 40 years ago, most of us, computer games quite new, it's exciting. You got to see some coloured pixels move across the screen and do something and it looked a bit more exciting than a factorial function where you factorial 5 and it goes 120 and you're like, brilliant, but it's not very exciting. It's not very interesting. Can't show your mates at your 10 and go, hey, I made it, do math. No one's impressed. I just think you're bit of a nerd. So, yeah, I was drawn to trying to make things happen and I've always approached that. So I tried with AI. I failed miserably. I tried with games in the early parts of my programming journey. And then as I sort of entered the workforce and started working professionally, then I started trying to build small applications. How do I actually ship something that uses this? Because, you know, I don't just want to learn Perl as it was then, or Visual Basic, or C. I want to learn how to build an application with them. How do I ship something with this? So one of the first coding challenges I did was the Huffman compression, which... I did for the first time in 1998 when I was learning C. And I've done it since in several different programming languages as a way of learning that language and building something real. I mean, it's not very impressive with Huffman encoding to compress a text file. Yes, you get some compression, but it's not as good as GZIP. But it's still building something real and learning a whole bunch of the programming language and shipping something. So I've done that approach, let's say, for decades now. It became coding challenges. Because, like a lot of people, I got laid off in 2022. you know, the economy's changed and things happened. And my wife pushed me to start another business. Said, you know, you've always been most secure in employment when you've been running your own business, do another business. And I'm terrible at business ideas. So I had seen this thing about personal branding, seen a few talks on some podcasts about developers building an audience and building a tool for the audience and thought, hey. John Crickett (07:24.173) I like lighting, personal planning seems to be lighting, that suits me. Maybe I can build an audience, figure out a tool to build for that audience, and then I don't have to come up with a business idea, can let the audience find it. So I started writing on LinkedIn with about 3,000 followers, figuring I'd try and learn how to build an audience, and then I could let that audience lead me to building a tool for software engineers. That would be a business idea. And along the way, I saw a post. from a European VC talking about how he'd 750,000 euros in his business two years ago, and then he wanted another quarter of a million euros to get to their MVP. And that just triggered me a little bit because back when I started my first business in 2001, it was just the dot-com crash, the telecom crash. There were a whole lot of people that were excited about this idea of dot-coms that had been made redundant and were taking their leniency payments, remortgaging their houses and coming along saying, I'm going to build a dot com, I'm going to invest it all, and this time next year I'll be millionaires. Typically six months later I see them all and they're bankrupt, I need a job now. I've built this thing and nobody came. It's like, well, you didn't validate your idea, you didn't test it. You just threw money at building a dot com, you put it out there and you got precisely zero visitors because it's not as simple as you build it they will come. You've got to actually do some marketing and figure out how to get some eyeballs there. So... Shortly after seeing that and seeing so many people lose out, I led about Lean Startup Ideas and Ideas OMOP and I've always been struck for that, mean, just validate your idea. So kind of tongue in cheek and a little bit just in being triggered by this idea of putting a million euros and two years of work into it. I put a post on LinkedIn with my three and a bit thousand followers at times saying, founders, if you spent... more than $100 and take more than two weeks to build it, it's not an MVP. And I didn't really think anything of it, but that was my first somewhat viral post, got about 100,000 views. And mostly people just tell me what an absolute freaking idiot I was, that you don't get two weeks of software engineers time for $100. And it's like, well, yes, but if you're a founder, that two weeks is your sweat equity, you do it yourself. Now $100 is, you know, buy a domain name and you validate your idea. John Crickett (09:47.649) And a lot of people as well as Thomas, a freaking idiot, said this was impossible. So I thought, well, I'm trying to validate some ideas. Let's actually, you know, walk the walk. By the main name, $17 for codingchallenges.fyi. What am going to start? Well, I'm trying to reach software engineers. What can I help them with? I can help them learn. I've mentored lots of people, so I've been a manager for many years. I can help them learn. how do I learn? Let's just write about that. I launched a newsletter, heard about this page newsletter thing on Substack. That will be my first test of validating a business idea. So sure enough, I had the idea, I think on a Monday morning, wrote about it, launched it on Friday. So less than my two weeks, $17 and a domain name. Substack's free to set up a newsletter, launched. Mounted it, I think, on the Friday evening UK time. I thought if I get a thousand people by the end of the year, there's maybe some legs to this idea. Maybe I can build something off the back of this. 1500 people signed up by the close of Sunday. Bethany (10:56.641) And were all those folks like, or do you think it was really because of that following that you accumulated on LinkedIn? Do you think it was word of mouth? I mean, obviously it was a surprise if you were anticipating a thousand by the end of the year. What do you think helped you get the so many in a weekend? John Crickett (11:19.244) I think it just resonated. At the time I had 3,200, 3,300 followers on LinkedIn, so a fairly small audience, and most of those were people outside of software that I'd networked with over the years from building businesses previously. So it wasn't a particularly big audience, I didn't have a big platform on LinkedIn at the time, but it just seemed to resonate with people. A lot of people don't like leak code, they wanted to build something a bit more real. I think that resonated, people talked about it, people shared it. And there was a nice little community of software developers that kind of met on LinkedIn at that time. So yeah, it just seemed to take off and work on its own. Erika (12:02.501) Yeah, it's really heartening to hear that story because I've heard some discussions of like self promotion and sorry, Can you not hear me? John Crickett (12:12.371) I can't hear Erika, by the way. Bethany (12:17.429) I can hear Erica. Brittany Ellich (12:19.759) yeah, I can hear. I can't. Let's see here. I can hear you. Bethany (12:24.761) Can you hear any of us? Or I'm talking to time. Okay. no. Erika (12:26.509) I can hear you. John Crickett (12:28.019) I can hear Bethany in Brittany, but not the hiker. Erika (12:30.843) your height. Erika (12:39.099) Testing, now. Bethany (12:43.607) I can, huh. Brittany Ellich (12:44.741) I can still hear you, but can you change your, can you use like just the MacBook one? Erika (12:51.065) Yeah, let me try that. I can't switch mics long. John Crickett (12:57.747) Isn't technology great? We all gladly work in software and tech. Brittany Ellich (13:01.351) Every time something like this happens, yeah, I'm always like, promise I'm an engineer. Like, I know how to work with computers. Bethany (13:02.883) My brain is going. Yeah. Bethany (13:09.711) My brain's just going like, how can one person on this call not hear the other person? How does that bug happen? That's wild. John Crickett (13:14.496) Ha Brittany Ellich (13:16.827) That's true. Bethany (13:22.927) Aww. Bethany (13:29.995) Okay, Sorry, Erica. John Crickett (13:31.775) You could stick it in the chat if you like, okay, and I'll try and answer. Brittany Ellich (13:41.846) there we go. Bethany (13:41.935) she said it was a long thought. John Crickett (13:46.539) That's a shame. Brittany Ellich (13:47.845) Huh. Bethany (13:52.493) I still hear typing so I'm waiting. Yeah, why don't you try it? We'll pause. Bethany (14:02.425) so odd, man. I have never experienced that at all on Riverside. That is so wild. Brittany Ellich (14:09.093) We're getting all of the lucky side problems with John today. Bethany (14:13.328) Yes John Crickett (14:15.723) Just make sure none of us leave early and mess up the other side that way. Bethany (14:18.863) Yes. Brittany Ellich (14:19.151) Yeah, that's true. That's true. Good point. John Crickett (14:22.379) and that once on my podcast and messed it up and that was quite embarrassing. Bethany (14:25.526) No. Brittany Ellich (14:25.999) Yeah, have you? Do you use Riverside as well then? John Crickett (14:28.714) Yes. Brittany Ellich (14:30.811) sense. Bethany (14:31.191) Makes me feel better that you've been in the same boat you understand with the riverside. Brittany Ellich (14:35.367) Yeah. Erika (14:38.678) Okay, is that better? Can you hear me? Okay. Great. Okay. it's really heartening to me to hear that story of how you started coding challenges. And I think I've heard some people say in the whole topic of self-promotion that John Crickett (14:40.841) Yes, I can. Brittany Ellich (14:43.065) Yay! Bethany (14:43.231) Amazing. Okay. And, Erika (15:07.32) a couple things, like it's not even worth trying because YouTube, Spotify, whatever, the algorithm is too strong to ever work against. I'm going to have to do all this marketing magic to even get out there. And also this idea that you kind of have to fabricate something or be some kind of persona or be someone in order to amass a following, but... I mean, in my experience, the people who I enjoy following the most are people who are genuinely interested in what they're doing. And that's exactly your story. And I think especially in software engineering, we can smell the fake, like sort of the fake, the fakeness in somebody trying to sell us something. So I think it's one of the things I enjoy a lot about. being a part of software engineering communities is this idea that, yeah, like when you have interesting content that is technical, that is realistic, that's genuine, people really enjoy that. you don't, like, if you do have some kind of algorithm boosting you, great, but even if not, people will share and reshare things that are uniquely good. And yeah, it's cool to hear those. John Crickett (16:35.307) you Erika (16:36.524) those stories where that's, that's what happens. John Crickett (16:40.203) Yeah, the thing that I think a lot of people forget is, particularly with software engineering, know, we have, it's probably a bit skewed recently with how recruitment has been, but we have this very pyramid structure that, just to go back two years ago with Stack Overflow, the stats show that 51 % of software engineers have less than 10 years experience. So it's been a very fast growing industry with a lot of people who are... you know, very junior and a lot more people coming up. What that means if you think about trying to build a personal band or build a following or just reach people and find your niche is you can always think that there's going to be somebody behind you wherever you are in your journey. There's a lot more people who are one year, two years behind you in learning that thing that you're interested in. So rather than try and be a character or be something you're not, simplest way is just to go. this is what I'm learning or this is how you can learn X. Because again, if I tell somebody how to learn, I don't know, Visual Basic, say, I haven't touched it for 28 years, I don't remember what it's like to be a learner and that where somebody that, you know, do people still learn Visual Basic? But somebody that's just learned it now is far more familiar with that pain, far more familiar with the current state of the tooling and maybe PHP might be a better example. Again, last time I did PHP it was version five. Is it eight or nine it's on now? know, somebody that's learning that, even if they've only got one year experience, somebody that's just entering the workforce or somebody that's just leaving university, you are, you can relate far better to them and know the pain that they're going through than anything I could write about it. So, and again, that doesn't necessarily mean that you have to be somebody with 30 years versus somebody with one year's experience. There's whole bunch of us learning AI at the moment, say, maybe learning agentic frameworks. You might only be six months ahead of learning somebody. You might be two years into your career, but six months ahead in that journey than somebody else that's been in this career for 30 years. So there's always somebody that's behind you on whatever journey you're going that can benefit from your recent experience, your, is the pain I've just been through recently, this what I struggled with. I think too often people forget about that. John Crickett (19:01.886) The downside with social media though, and this is something that bugs me a little bit, is when you engage with somebody's content, when you comment on it, you amplify it. So there a lot of people that are pushing things that are maybe incorrect or pushing hype, and the trouble is a lot of people pie on and say, that's long, this is ridiculous, but they forget that they're then amplifying that message and drowning out. the people that maybe are teaching the correct thing. So again, if you want to be providing something genuine and teaching people and finding a niche of creators that are going to collaborate and focus on putting forward your message, promoting your niche and whatever, and try and stay aware from amplifying the voices that don't fit that. Bethany (19:54.352) Totally agree. I feel like being on social media in this day and time, there's so much rage debate because it leads to engagements that when something makes somebody angry, it probably gets more engagement than something that makes somebody feel good or that is accurate because those are harder to contend with. Or not contend with, but engage with. John Crickett (20:16.49) Yeah, well, back to my comment about the viral post that I got at first. It wasn't intended as a rage bait, it was just more a frustration at seeing people wasting time and money on this. But it triggered a bunch of people and it went to over 100,000 views when I had a tiny audience. Bethany (20:36.673) Absolutely, absolutely. And I loved your, stories about really remembering that beginner mindset and how folks approach problems as a beginner. So I know you have, you mentioned your newsletter from the challenges on Substack and that commonly breaks down mistakes that engineers make while tackling large projects. Is that something that you resonated with like from learning engineering as a beginner? Is that something that you've just seen others making that mistake and you're trying to protect them against? I'm curious what made you focus on those engineering challenges versus maybe teaching specific languages or things like that. John Crickett (21:28.264) So I needed a bit of variety to keep me interested in writing the newsletter, so I was churning out a challenge each week. So I'd had a lot of people asking for tutorials or asking for, show us how to do these, not just the challenges. And I very much positioned it as I wanted to be language and platform neutral. So I try and make the challenges as tech agnostic as possible. Some of them you could build a CLI UI, could build a web UI, could build a native GUI, you could build a mobile app. So you could adapt it to learning whatever you wanted within what suits the challenge. So I also wanted the feedback to be platform and language agnostic. So it's no good me saying, this is how you should do it in C++. Use smart pointers and so on. only about 5 % of the audience is using C++. So it wasn't going to resonate with a lot of people. So I wanted to pick out lessons that I'd seen. And one of the things that I found incredibly useful earlier in my career was I was lucky enough to work with and know some very experienced people and get code reviews from them. And they treated code reviews as way of sharing knowledge of like, hey, have you thought of this? Take the C++ one. You're using their pointers here. Could you use a smart pointer? I was like, smart pointers, what are they? Cool, I want to learn about that. So that was a great way of learning. So I wanted to try and bring some of that into it. And slightly earlier in the process, I'd created a GitHub Leap where people would share their solutions. So that then gave me something to go look and say, well, you know, I've got the WC coding challenge. How have people solved that? If I go and code with you, not all the solutions, because there's about 130, I think now. But if I go and code review 20 or 30 of them, there's some common patterns, some common mistakes people make. And a great one with WC, for example, is WC is a word count utility that also counts lines on Unix. And it's a very good example of a great little Unix program. does one thing, one and a bit things, but it does really well. And it's designed to process streams. It doesn't think of it as a text file, and I say it's a stream. John Crickett (23:51.56) Because of that, then it's able to process any stream of data. Well, a lot of people immediately load WC and open up the entire file, to memory. So that's great if you go and test that on a file that's 100 kilobytes, or I think the 300 kilobyte example I've got was from Project Gutenberg, one of the books. But nearly nobody's one will actually work like the little WC and will handle 100 gigabyte files. So I extended the challenge recently and I had handed it 100 gigabyte file. And 99 % of the solutions will fail on that because they just opened up, led the entire file into memory and then tried to process it. And not very many people have a laptop or desktop that will process 100 gig file in memory. But that's a great learning technique to actually then, it's fairly trivial work to change to process a stream. And that's a transferable skill because if you think about processing a stream, You can now process stream over network, you can process it from a TCP connection, you can process it from a pipe, you can process it from a file, and you get a whole different set of skills. So I wanted to pick out some of those lessons and introduce people to these other areas that you might not be familiar with. Bethany (25:07.033) That's really cool. mean, doing some of the Leet's code style problems, they have something similar where they'll have the base case and it's very easy to get that to pass. But if it's not a good algorithm, it'll definitely fail. So that's cool translating that almost to your real world problems and introducing that scale to these things that people actually are contending with day after day rather than maybe these esoteric algorithms. that we don't necessarily have to engage with as much. John Crickett (25:40.478) Yeah, because realistically, when you deal with some of the leco stuff, looks at how do you turn something that's order n squared to order n or whatever, when you're dealing with those, it's normally going to be something like processing a stream of data and doing some calculation on it. So thinking about some of those elements is kind of the precursor to getting to the point where you need to worry about how that algorithm scales. How does your basic infrastructure scale? Bethany (26:08.463) Definitely, and I love being able to, or that a lot of folks take for granted these tools that we use every day and maybe aren't contending with the underlying technology. So I think by building it, it also helps folks understand how things scale. So if something doesn't scale, they can more accurately debug it or they've had more encounter with what's under the hood than maybe others to be able to leverage these tools more intelligently, which I know with AI, there's a lot of talk on eroding skills or eroding, like you're not going to use your skills so you'll lose them. I'm curious what your thoughts are, especially with having coding challenges, if this is something that you think will be a... an with AI or if it's something that we just really need to make sure we understand the underlying technology even better now with AI usage and it helps us. John Crickett (27:16.361) So I'm going to tie that back to WC if I can and start with one of the reasons I like the command line tools like WC and I picked some of those out is that they were built 30, 40, 50 years ago, some of them, and they still scale because they all have this very simple interface. They do one thing, they do it well, they process a stream of data, they don't particularly care about it. They're all text based, they're command line based. This Unix system has pipes and the ability to pass stream from one player. So you take these bunch of simple components and they can be put together to quite amazing stuff. There is a course on Coursera on doing data science with Bash. Because there's so many powerful, simple tools, but combine them together, you can build very powerful data pipelines in Bash. And I think that the Unix philosophy that is well described in the book, The Art of Unix Programming, is so transferable. So it started with those command line programs that process streams. You can scale that to building microservices and doing things over less API, to building things in the cloud and queues and all your vent-driven architectures. All the same ideas transfer. And I think we've had that skill illusion for the last 30 years before AI. We've come across very few more recent software engineers that understand what a pointer is, understand memory management. that have ever written C or low-level language. And you see that we keep reinventing the wheels because we don't understand some of those underlying concepts. So I think there's a lot of knowledge we keep forgetting, like the ideas from the art of Unix programming, cause us to reinvent things, cause us have forgotten a lot of the lessons we had in the past. And... So I think we've had that scale lotion as we've got high levels of stack and I quite often see people complaining about Python, for example, saying it's slow because it's interpreted. And OK, it's a little bit of a nitpick, but one of the things that bugs me there is we've lost this understanding of what does it mean to be compiled and interpreted and does it matter? And also... John Crickett (29:38.473) And the fundamental underlying important thing to understand is that languages aren't compiled or interpreted. Languages are languages. You can go away and build an implementation of a language that is interpreted. You can go away and build one that's compiled. You can find an interpreter for C. You can find a compiler for Python. Basically, C Python is a compiler that compiles its bytecode. Java is compiled to bytecode as well. Both Java and Python are then going on a virtual machine. So they're interpreting the virtual machine. So Python, for example, is compiled and interpreted. So is Java. But people say Java's compiled and Python's interpreted. You know, they're not different. They have the same infrastructure. And what that misses then is that people don't have that basic understanding of what they're working on. And Java can be so much faster because the virtual machine then has the hotspot compiler. which is just-in-time compiler. And if you understand what that's doing, you understand why we can then have that in Python, and Python is getting a just-in-time compiler. You start to understand why JavaScript is so fast in lot of the browsers, because browser manufacturers are putting massive investment into just-in-time compilers. So a lot of that fundamental knowledge, I think, has been lost as we've evolved for the last 20, 30 years as people have been working more abstract, which is a great thing, and we could be more productive. But I think if we'd focused a bit more on learning the fundamentals, everyone would be in a better position. And I have the same comment with AI and people saying, AI is going to like the code, so you're out of a job as a software engineer. Well, software engineers have never been about just writing code to me. When I, and again, sorry, I'm old, I went to uni in 1995. But when I did my computer science degree and we talked about software engineering, which, you know, UK universities tend to view computer science as an academic subject and it's almost a dirty word that you're going to use this for a career. But at the time when they talked about software engineering, the software engineering life cycle was you met a customer and you said, what do you want us to build? All the way through to you delivered. John Crickett (31:54.469) floppy disk in those days to the customer, installed it on their site, went for acceptance tests with them and they saw that it worked and did what they wanted. The coding was a little tiny bit in the middle, where now I see people saying, well, I just want to code all that software engineering. Well, that's not what software engineering is. You have to talk to a user, get requirements, do some analysis, figure out what you're to build. And yes, we don't want to do that in a waterfall way because there's so many problems with that. doing it in some kind of agile approach would be good, but we still have all the same steps of you have to do a lot of thinking. And AI, it's great at churning out code, can be problematic as well, but it can also be used for churning out requirements. It can be used for helping you think through your design. And just like humans, it can make mistakes there. It can have gaps in its knowledge that lead to hallucinations. It's not. intelligent, it's not rational, it doesn't think, doesn't stop it from being incredibly useful. So I think we've been losing those skills for many, many years, probably not helped by this whole bootcamp notion of you can learn to code in 10 weeks and be a software engineer, which I think has led to this belief that software engineering is just coding and that you don't need to learn the rest of these things. And... Again, I don't think you need a degree to be a software engineer, so I don't want to gatekeep, but I think we have to be aware that it's a big field and there's a lot of work there and there's a lot of work involved. yeah, sorry, sorry to lambly, but I think the skill erosion has been happening for a while and for people that only view it as coding, maybe it might have lowered a little bit of that, but there is much more to the job. And I'm quite excited because I suck at JavaScript and HTML and CSS, so. I can now use AI to generate for an end that doesn't look like a five-year-old drew it when they were feeling ill. And I can build some great software with that. And I can focus on the bits that excite me of problem solving. And then when I want to get into some hardcore code, I can go and use Lust or Go. And I can go and nerd out and line the code. But I can now achieve far more. So I think it's great. And it opens up opportunities to extend your skills into other areas too. Erika (34:15.065) Yeah, it makes me think like the constraints that we're working with are still the same too, like CPU memory, time, space, you know, it's all the same. Nothing has changed since when you first started and now we're, but we've sort of abstracted away not only some of the like languages, like how close you are to the memory management or the usage. then, yeah, I guess like the compute itself, like we don't work on a mainframe anymore. We work on cloud instances and that kind of stuff. So you, as I said, you do a box, you, you know, and we just have more compute at our fingers most of the time now, like the... It's just more powerful, they're faster. And so I think, yeah, we sort of get into this false sense of security like, well, you know, it's fine. It'll run fine. And then you get into these edge cases or when you try to scale or like you said, like read a file that's greater than a certain size and it won't even run. We realized that. It's still the same. It's still the same constraints. yeah, it's hard to understand that stuff. Yeah, I mean, you can learn kind of the basics in, like you said, 10 weeks or whatever, but then really digging in. Yeah, we have a book club as a part of our engineering community. And one of the books that got thrown out was like computer systems, a programmer's perspective. which I've read through before and it is really hard to understand. And yeah, I I'm still kind of processing. I got a lot from it, yeah, it's not easy for sure when you really dig down. And yeah, I feel like your approach of providing that kind of look behind the tooling is... Erika (36:38.154) is a nice middle ground at least to be like, OK, you're using this tool on a daily basis, but what does it actually do? Yeah, and that's at least one layer deep than banging a dance to wall and wondering why it doesn't work. John Crickett (36:55.271) So there's two things I'd love to pick up on that, Urke. One, you've mentioned we don't work on mainframes anymore. Again, I mentioned that our industry is growing and a lot of people have less than 10 years experience. We've got a lot of new people coming in and it's been expanding massively. One of the interesting things, maybe interesting is not quite the word, but one of the effects of that and effects of social media is we have... shrunk software engineering down to almost web development and forgotten that there was a massive field outside that. So one of the things that shocked me, I think about 18 months ago when I responded to a comment about mainframes is I went and looked at the market and the mainframe market is bigger than it's ever been before and it's still growing. And I was shocked by that because I remember I said I entered the I entered the workforce in 1996 and I thought mainframes were dead then. Everybody said, if Cobalt's dead, mainframes are gone. And 30 years later, the mainframe market's bigger than it's ever been. There's a new one shipping, IBM is pushing the AI features of their latest mainframe, and that's a growing market. And I'm still amazed by that because I don't actually know anyone after 30 years that works on mainframes. That's not true. I interviewed somebody on my podcast a while back. as mainframe security, which is also a field because there's so much financial transactions going through them. So we never see it talked about in social media hardly, but that is a massive and growing field. And when I then looked at that and I say shiny things distracted, I found that people still like in cobalt courses. There's one university still teaching a course and got high demand. There are Cobalt courses, think, are new to me with 23,000, 24,000 people that have taken it and reviewed it. So they're doing massive business. I know lots of Amazon and the latest books teaching Cobalt were from like 2023, 2024. So we forget that it's a whole big section of the industry that you don't see talked about. And the same for a lot of people forget there's a whole massive world doing embedded devices. Again, another... John Crickett (39:19.023) strange one I found, it's years since I've worked on hardcore embedded software. And when I did, I was trying to get people to move to C++ because I thought it was a much better language than C. and that was 26 years ago. C is still the predominant language for embedded, and much as people are trying to push lust, Python is the third biggest language in the embedded world by far, and is widely used in embedded devices. And again, that kind of contrasts with, if we say Python is interpreted in slow and wasteful memory, but it's yet one of the most commonly used languages on small embedded devices. And that's partly because of IoT, which again, is a massive market, but we hardly see that presented on a lot of social media and a lot of people talking about it, where most of the world seems to talk about web development and JavaScript and TypeScript. So, yeah, we forget that it's a massive industry. are people building software for all sorts of things. And some of these things that we think of niches like mainframes are bigger than the whole market was when I started my career. That's how fast we're growing. You also mentioned peeling back the layers and understanding how they work. I think that's so useful. And one of the things that I'm doing in the coding challenge soon, and I've had quite fun doing a few talks on, is building an AI agent. There's so many people that get carried away with, I'm to write my core.agentsMD, I'm going to write skills, I'm going to write this plugin, and I'm going to write subagents and so on. But at the end of the day, an LLM is just an API that you call over the rest. and you pass it some JSON. And all these things clap down to you passing some JSON to a LEST API. So I'm looking forward to doing the agent coding challenge and taking more people through that so they see what a coding agent really is and then have a better understanding of what's happening and how they can use that LM and what it's really doing so they can leverage it better. Bethany (41:21.231) I'm so excited for that. Especially working on a co-file API, that's something that honestly I'd love to understand more of the agent side of things and the prompting side. But the request side is very near and dear to my heart for sure. But that's such a great perspective on the market as a whole. think oftentimes we get so focused on what we're doing or the new saying that web development's dead, that we do forget that there's a lot of technology and very important technology that lies on older stacks and other things that the industry kind of says, we don't need to worry about that. So I really, really appreciate that nuanced take. And as a... We're kind of coming up to time, but I am curious before we go to our fun segment. You are doing a lot. You're running the coding challenges, Needless Letter, the coding chats, podcasts, the YouTube channel, your LinkedIn, probably staying up to date with the entire industry as well and trends there. So as this is over committed, how do you manage all of that? And do you have any tips or takes on sustainability in doing that? this is your business and running your business and protecting that part of yourself. John Crickett (42:49.254) think the basic answer there is I'm over committed. Yeah, it's... Back to what I said earlier about trying different things and validating them. So some of the things I've done have been attempts to find out what is the right business for me, what works for me. So the validating ideas and pulling back on the things that I don't enjoy or don't work or don't provide a good ROI for the time or finances. Secondly, I get help with some of it. So the podcast, for example, is really easy. And that basically boils down to, I have a one hour chat with some lovely people, learn something interesting. That's a lot of fun. All the hard work is done by my wife who edits the podcast. So she spends hours editing it and putting it together afterwards. So the podcast is just a lot of fun and a nice hour for me chatting to somebody interesting. The five or six hours that goes into editing each episode and then all the extra work is all done by her. So I'm really grateful for that and that makes it a lot easier. The coding challenges, again, it's... a lot of them ideas I've had or they're things that I'm curious to learn. it almost feels like fun and play to go and create a lot of these things and I'm thinking, how does that work? How can I pick it up? How can I turn into a coding challenge? So it's quite easy to lose hours digging into that and have fun doing that. Bethany (44:17.007) That makes a lot of sense. think fun is really the secret to all of it. That's, that's, I think, an honest and refreshing take to being overcommitted. All right. So I am very excited about our fun segment today. I know we've talked a lot about language being language agnostic and how specific languages might not work or it might not matter. can, you can... kind of take and pick what you want. I did run into a blog post while researching where you ran a Mandelbrot set renderer that you wrote entirely in brainfuck, which is very, I read it and I was like, have no idea what's going on here, but I love that. So I thought we'd do a quiz where we guess whether the programming language is real or made up. John Crickett (44:58.182) You Bethany (45:14.807) So basically just shout out your guests. I won't contribute because I do know the answers, but yeah. So we'll start out with LOL code, which is a language where you write code using phrases like hi, Ken has, and K thanks, bye for our millennial listeners. Erika (45:35.276) I think this one's real. John Crickett (45:35.866) I think that one is. Bethany (45:39.097) We're land on real? It is real. Yeah. Okay. Next. Brittany Ellich (45:40.955) I think so. Nice. I feel like it's got to be called LOL code though. I feel like there's probably a debate on the internet about whether it's LOL code or LOL code. Bethany (45:52.528) Oh, you're so right. Yeah, it probably is lolcode, but we should ask the creator and get that validated. Okay, next is Wendy, a functional language designed for writing smart contracts on the Ethereum blockchain. Erika (45:59.928) Yes. John Crickett (46:13.199) don't know. Erika (46:15.51) I mean, yes, I don't know. Brittany Ellich (46:20.103) I feel like it probably does make sense because it's the whole like somebody must have made this like, but you work at a Wendy's, sir, this is a Wendy's. So I'm gonna say yes, but it's real. Erika (46:29.625) Oh, I was thinking like Peter Pan Wendy. Yeah. Wendy. Bethany (46:30.274) it. Brittany Ellich (46:32.423) Oh no, it's definitely Wendy's, like the, yeah, the fast food chain. Bethany (46:32.559) Yeah. Bethany (46:38.431) Sorry, this is a Wendy's. That's amazing. Well, we should create it because it does not currently exist, but that would be a good angle to take. Okay. White space, a language where only spaces, tabs, and new lines are meaningful and all other characters are ignored. Erika (46:39.187) John Crickett (46:57.582) I believe that's real. Erika (46:59.32) can't be. It's gotta be... Yeah. Burn it down. Brittany Ellich (47:00.737) No, I hope not. John Crickett (47:02.661) Ha Bethany (47:04.909) I'm so sorry, but... Brittany Ellich (47:04.954) Yeah. John Crickett (47:05.039) There was a language chicken, where everything is how many times you say the word chicken. Erika (47:09.378) BLEH! Bethany (47:12.013) No, that's amazing. Well, White Space is real, so John's right there. Play for John. Brittany Ellich (47:12.106) my gosh. Brittany Ellich (47:20.293) I can't imagine code reviewing that. That sounds miserable. Erika (47:23.768) Yeah. Bethany (47:24.655) That's the neat part, you don't. Okay, Rockstar, a language designed so that programs read like rock ballads with variables declared like, Tommy is a rockstar. Erika (47:27.426) Yeah. John Crickett (47:38.307) know this one. Brittany Ellich (47:39.725) Mm-hmm. I've heard of this one. It's real. Bethany (47:43.703) It is real. I remember because people were like, you can say I'm a rock star developer on your resume and people thought that was so fun. John Crickett (47:44.93) It's real. Erika (47:52.439) You John Crickett (47:53.296) Dylan Beatty, the creator, has a couple of brilliant talks about creating it. Well worth watching. better yet, invite him on. He's a great, great speaker. Bethany (47:57.778) so cool. Okay, we'll have to link those. Brittany Ellich (47:59.098) Erika (48:03.448) He's a rock star. Bethany (48:03.699) Alright, Dylan, keep an eye out for that. Yeah, Rockstar developer. Keep an eye out. Brittany Ellich (48:04.048) Yeah. John Crickett (48:11.245) I think he has some swag marked up so you can get a sticker that he gives away at his talks. I've only seen his talks on YouTube unfortunately, I've never managed to get one but they're really really good. Bethany (48:14.805) Ooh, amazing. Brittany Ellich (48:17.371) Nice. Bethany (48:22.159) We'll have to track next time he talks at something. John Crickett (48:24.559) He's also a good musician. plays music at his talks as well. Bethany (48:28.565) It makes sense with Rockstar. No wonder it's like a rock ballads. Okay. Next is Frostbite, a stack based language where every operation is named after a type of weather. John Crickett (48:30.425) Yeah. Erika (48:45.432) No. John Crickett (48:45.989) That sounds real. That sounds weird enough. Brittany Ellich (48:49.947) I'm going to say no only because I'm not sure what a stack-based language is. Bethany (48:55.524) It is fake. stackface languages are real, but it is fake. Erika (48:57.975) Hey! Brittany Ellich (48:58.587) Yes. okay. Great. Erika (49:02.776) Wait, if we're doing the reveals as we go, did we ever say what the first one was? Was it real or not? okay. Bethany (49:08.407) It was real, Yeah! Okay, next is Shakespeare, a language where programs look like Shakespearean plays and variables are characters like Romeo and Juliet. Erika (49:22.776) I love this one. Yeah, it's gotta be real. Yay. John Crickett (49:23.139) I believe that's real. Bethany (49:26.111) It's real! Yup. Okay, this one. Erika (49:42.316) I'll go for it. I'll stay real. John Crickett (49:44.798) I'm going to say no for that one, but it does remind me that there is one which is coloured squares of different sizes. Brittany Ellich (49:46.993) same. Bethany (49:54.745) learning more about these other programming languages than when I created this. John Crickett (50:02.607) Yeah, I can't remember what it's called, but there is one which is... Bethany (50:07.508) Wow. Well while you're doing looking that up but beeswax is real I had to google it because I'm like what does that even mean? Erika (50:15.894) No. Bethany (50:17.838) hexagonal grid. Erika (50:24.185) Yeah, and is that like functional? is that meant to like make you improve your usage of instruction pointers or is it really only for fun? Bethany (50:36.974) You know, I have no idea. I'm sure most of these are for fun. But okay, Piat is what the squares is called. Erika (50:39.192) you John Crickett (50:47.065) Yeah, that's the code one, there's a couple of pictures on that Wikipedia page. So try code review in that. Bethany (50:51.108) Eww. Bethany (50:54.894) It's like going to an art museum. Honestly, maybe my mental well-being would be better if that was when I'm reviewing. It's like, art, what does this mean? Yeah, yeah. All right, finally, Goblin, an interpreted language where all error messages are written in Tolkien's black speech. Erika (51:04.01) Roar Shock Test. John Crickett (51:16.943) think that's probably all. That sounds typically esoteric enough. Erika (51:18.16) That seems like, yeah, like the Venn diagram of like people creating programming languages and people who want an error message written by a goblin is probably pretty strong overlap. Bethany (51:32.432) It does sound very real. Yeah, it's a circle, but it does not exist. So I guess that's another one we gotta get on. Yeah. Brittany Ellich (51:34.213) Yep, it's a circle. missed opportunity. Yeah, we need to not post that part so we can go, you know, steal it before everybody else does. Erika (51:38.976) No! Okay. Yeah. Bethany (51:46.872) Okay, okay, we'll hide that and make it and then revise and be like, that's real, we made it. Alright, well that is all the languages I had, but John, it sounds like you have so many more, so unfortunately though, we are at time. Thank you so much for coming on. Where can folks find you? Erika (51:47.286) Yeah. We made it. John Crickett (52:07.957) You can find me on LinkedIn, there's John Cricket, on X as well, and on Substack. And can find Coding Channels, it's easy enough if you Google it, or you can Google my name as well. Very easy to find, it's quite unique. Bethany (52:21.904) And we will link all of those in our show notes. Thank you again so much for joining us and for that conversation. And thank you listener for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye. John Crickett (52:25.273) Thank you. --- ## Episode 56: Run Toward Something - Career Growth, Mentorship & Work-Life Balance with Dave Schwantes - URL: https://overcommitted.dev/run-toward-something---career-growth-mentorship-work-life-balance-with-dave-schwantes - Published: 2026-04-21 - Audio: https://anchor.fm/s/102586d64/podcast/play/118635358/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-3-18%2F422319417-44100-2-c86bb138d3fc2.mp3 ### Show notes Summary Career growth through mentorship and work-life balance with Dave Schwantes, Senior Software Engineer at GitHub. Brittany and Dave explore why running toward meaningful work beats running from burnout, how mentorship became his primary form of engineering leverage, and what career happiness actually looks like across different life stages. From Instacart and Couchsurfing to building in-house bootcamps, Dave shares how sustainable engineering culture beats individual productivity hacks—and his take on how AI tools reshape what engineers really need to master. Links * Dave's personal site: https://dinosaurseateverybody.com [https://dinosaurseateverybody.com] * Don't Break Prod (bite-sized career advice): https://dontbreakprod.com [https://dontbreakprod.com] * Grave Danger (Dave's spooky ska band) on Bandcamp: https://gravedangerskath.bandcamp.com [https://gravedangerskath.bandcamp.com] * Dave on Bluesky: https://bsky.app/profile/dorkrawk.bsky.social [https://bsky.app/profile/dorkrawk.bsky.social] * Dave on LinkedIn: https://www.linkedin.com/in/davidschwantes [https://www.linkedin.com/in/davidschwantes] * Dave on GitHub: https://github.com/dorkrawk [https://github.com/dorkrawk] * Web Dev Challenge Episode: https://www.youtube.com/watch?v=X2sEoZG8EIw [https://www.youtube.com/watch?v=X2sEoZG8EIw] * The Engineer Manager Pendulum article: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ [https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/] Host * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Brittany, and this is a podcast where a group of some of my friends and I met working on a team at GitHub, realized we were all obsessed with work getting better at what we do. And we decided to start this podcast to share what we are learning. We talk 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 I'm so excited because we are joined by Dave Schwantes, a senior software engineer at GitHub with a career spanning companies like Instacart and Couchsurfing International. He has been deeply involved in engineering mentorship. treating an in-house coding bootcamp that helped non-technical employees transition into engineering roles at Instacart without quitting their jobs or paying for outside education. In addition, Dave also helps co-lead the engineering mentorship program at GitHub with me. So very excited to have him here today. He brings a rare combination of hands-on engineering experience, deep mentorship roots, and a grounded, honest perspective on what career happiness and software actually looks like. across different life stages. And he's also a heck of a musician and is in a ska band. Hello, Dave, welcome. Dave (01:16) Yeah. Hey, really cool to be here. Like, been excited to be on your podcast since I learned you had one. Brittany Ellich (01:24) I know. Yeah, I think you actually had told me that you did a podcast previously. And that was part of what I was like, maybe I could do that at some point because we were we have been on a team together at our adjacent teams, I guess. And we were on a team together on the Web Dev Challenge. So which I'll link for sure in the show notes. So it's been it's been fun. Yeah. So to kick us off. Dave (01:41) Yeah, we've made some cool stuff. Brittany Ellich (01:45) What's one thing you're currently building or obsessed with learning right now? Dave (01:49) Let's see, so I've been trying to play around with AI tools like every other software engineer in the world, and I have this ongoing list of project ideas. I've been keeping a Google doc of these things for 20 years. And I've been going through and trying to chip off ones that seemed a little too hard to do, or I couldn't justify the time to do them. So I've been going through and just tossing them in Copilot, or tossing them in Cloud, or something like that. So I built a messaging app for my kid. I couldn't find any like text messaging app I liked for them and I was tired of him asking me to text his friend's mom to hang out. So I built him and his friends a messaging app. I built a little thing that let me train a machine learning model to detect squirrels on my bird feeder and then play metal super loud to try to scare them away. That's been really good. built something to try to organize the songwriting for one of my bands because we just kept sending music files back and forth and text threads and I couldn't find it. So that's what I'm doing. I'm chipping away at a bunch of little projects that I couldn't justify the time for before. Brittany Ellich (02:55) That's amazing and such a great idea to build something. As a parent, my kids are still young enough to where they're not wanting to message other people yet. But the idea of like, I don't know, parental controls on software out there is very intimidating to me as a software engineer, because I'm like, they're probably not amazing. So building one yourself, that's such a good idea. I love that. How do your neighbors feel about the squirrel? Dave (03:03) Mm-hmm. In the end. Yeah. Brittany Ellich (03:22) vendetta you have. Dave (03:24) Nobody's like asked me about it yet. But every once in a while, there'll be like a, you know, 15 second clip of Slayer or something like that playing super loud in the backyard. The problem is the squirrels don't actually hate death metal. They're kind of into it. ⁓ Yeah. So now I'm on a quest to like build some like Arduino thing that'll like jump scare them. I don't know. It's it's going to be a weird obsession. So I'm deep down that rabbit hole now. Brittany Ellich (03:38) They're rocking out. Yeah, you gotta, you gotta find the right music that the squirrels really hate, I guess. They're probably, they've been hanging around your house long enough that they're like used to too much music, Awesome. Cool. So first I wanted to talk a little bit about how you got to where you are in your career and how, you know, how things sort of connected for you. So you're at GitHub now and worked previously, I think, at Instacart. Dave (03:53) Yeah. Yeah. Mm-hmm. Brittany Ellich (04:14) And what is the thread that connects your experience all together, do you think? Dave (04:18) So I've never been really good at having like a here's my five year plan, here's my 10 year plan. I've always kind of liked checking in like, am I happy here? Am I directionally happy? More than am I, do I have a great destination? And I guess kind of looking back at a lot of the companies I worked for, I've tried to work for places where I like what they make or I thought I would use what they make or I could relate to what they make in some way. I guess my first job was, I don't know, my high school buddy of mine was working at a company and asked me to apply there. So I worked there for a while. So I guess that wasn't too ideologically motivated other than I was in my 20s and needed a job. But like from there, I kind of felt like I at least tried to pick stuff that was on my mind. I think when I was living in California, the first like startup job I worked at was in solar energy. It was software for solar systems. And my wife was in grad school at the time studying energy policy. So I had been talking to her about that stuff a lot. So I'm like, oh yeah, solar could be cool. And then I was into travel. So couch surfing was cool. And I was sick of going to the grocery store. So Instacart seemed cool. I write software. So here I'm at GitHub. So I like to be able to relate to what I'm doing. I have a harder time just kind of. getting excited about a company that does something that probably helps a lot of people, but I need some of those people to be me. Brittany Ellich (05:46) Yeah, I like that. It's a very different experience working on a product that is where you're like one of the number one, you know, customer archetypes for it, for sure. How did you know at each transition that it was time to move on? Was there something that, you know, and it might have been different for each one, I guess, but like, how do you make that decision? Dave (05:53) Yeah. Yeah. I think in general, I try really hard not to move away from things, but move toward things. Like, you know, my last job at Instacart, like I had a lot of fun at Instacart, met a lot of cool people, learned a of cool stuff. I didn't really want to leave anything at Instacart, but I kind of knew that there were other things out there, other software companies of that size. And I was kind of I felt like I knew how Instacart made software and I wanted to go somewhere else and kind of see what was universal, what was unique to different companies. And so I think it was the push of seeing what else is out there. But I think that's gonna be a different pull at different points in my life. know, earlier on I think I was more inclined to jump to see more different things, whereas now I might be more interested in trying to go deeper in what companies. offer. I think that's just, you know, change in attitude, change in lifestyle, that sort of thing. Brittany Ellich (06:57) sense. And I know having worked with you and done been a part of some mentorship related presentations with you that happiness is an important factor to you doing your job and you know it's part of the recommendations that you give other people as well. Is this something that you have come to find over time or is this something that you've like just like a core value you've had throughout your entire career or what is that? Dave (07:08) Mm-hmm. I think as I was working, I noticed people that didn't seem happy. They might have been successful. They might have been, they might even been doing things that I kind of envied or even aspired to. But they didn't seem to really be enjoying themselves that much. And I think it kind of came down to figuring out that you have to understand what you want. In order to kind of have that holistic happiness and recognize that that's that's something that's going to change You know what's going to make you happy? At you know 20 is going to be different at 30 40 50 whatever like you're gonna change your perspective your life is going to be different and I think if you If you don't think deeply about What you really want what you value and recognize that that can change you can end up? chasing things that look good, might have their benefits, might make you money, might get you prestige, but they're not going to be fulfilling. You can run yourself into a career that you don't really like. And I think that's a risk, and I think being software engineers, we have optionality, we have some choice around this stuff. So I think you do yourself a pretty big disservice to not take that frequent time to reflect like, What do I want? What's really motivating me? How does work fit in with everything else? Brittany Ellich (08:39) Yeah, I like that. Especially, I think I'm at a point in my career where I've sort of gone through the beginning and gotten to the mid-level part where it's just gonna be, is this just gonna be a trudge until I get close to retirement? ⁓ And starting to realize that, yeah, that happiness and those things that I wanted early on are probably different than they are now. And so that's a, yeah, it's very interesting to think about. Dave (08:53) Mm-hmm. Yeah. An engineer I really, really respect. I really liked work at my previous company. She was phenomenal. If she had wanted, I think she could have shot up Staff, Staff Plus, all that really easily. She was definitely a career senior engineer, but kept switching teams and switching areas of the company. She'd been doing application stuff, went and did infrastructure stuff. She built up enough reputation that she was able to move laterally a lot. And I think she's had a career she really likes because I think she knows that she knows what direction she wants to move in. like I always thought about that a lot. Brittany Ellich (09:41) Yeah, yeah, I like that. Has your personal definition of happiness and like what a good career is, has that changed over time? Have you seen that? Have your own goals changed? Dave (09:50) Yeah, I think so. I think early on career, learning is incredibly important. is always important, but learning exposure to new things, even jumping around company to company was a lot more appealing. There was this idea of breadth of exposure and also the idea of, this is a good time to go super hard on stuff professionally. And I think as I've gotten older, seeing how work can kind of fit into the rest of my life. think work-life balance is a little bit of an overloaded term. But, I mean, a big part of my career happiness is how my job fits in with the rest of my life, whether that's family, friends, interests, stuff like that. And sort of recognizing that there are things right now in my life that are... unique and if I miss them for work things I can't get those back. And just recognizing that it's great to love your job and to be really into your job and care about it and put a lot of yourself into it but it is an exchange. The company's paying you money for work and it can be a really mutually beneficial exchange and something where both sides are really happy but it's still that part of the exchange and I don't want to overcorrect to that at this point in my life at the, you know, at the cost of some, I don't know, things with my kids, things where I'm keeping my own sanity, stuff like that. I think it can be really easy to let external things pull your time. know, work is a perfect example of it. We'll ask as much from you as you're willing to give it. And so I think for right now, my happiness is come a lot from putting the appropriate boundaries on different things. So it all fits together in a way that creates a happiness for me. And that's going to be different for different people. Different people are going to decide, hey, I want to go super hard on work right now. I want to go super deep into this stuff. And that's great. But it has to be a conscious choice. And I think for me, I've tried really hard to make those conscious choices. And to your point, it has evolved. I think it was, it was like a Paul Graham tweet or something that like struck me. It was just, he said, I realized I've become more, or I've become less ambitious since I've had kids. And that was kind of like a shocking thing. I'm like, huh, there is a little bit of that, but that's a narrow quote, right? It's not that you've become less ambitious, it's just that maybe your ambitions have broadened, right? And for not everybody, that's gonna be kids. For me, I've got kids, so that's some of it. But your ambitions can broaden. think keeping work and life in these narrow buckets and pretending they don't affect each other doesn't really work. Brittany Ellich (12:33) Yeah, yeah, I agree with that. Especially, yeah, being also in a phase of my life where my kids are young and very heavily involved with them and like not willing to give up on certain things that otherwise you would miss them. So. Dave (12:38) Mm-hmm. I always think eventually my kids aren't gonna wanna hang out with me. They wanna hang out now. Work's always gonna wanna hang out. Brittany Ellich (12:49) Mm-hmm. Yeah, that's true. You got to enjoy it while you can, really. So let's talk a little bit about mentorship. I know this is something that is pretty important to you. ⁓ Like I said, we do a lot of stuff related to mentorship at GitHub together. I'm curious how that became important to you. How have you approached mentorship within your career? And why is that something that you ended up? Dave (12:53) Yes. Yeah. Mm-hmm. Brittany Ellich (13:15) carrying about a lot at GitHub. Dave (13:17) So I don't know if there was a particular inflection point in my career where I'm like, this is going to be my thing. When I was in college, I had an internship. I think that really helped me get into the working world and helped me a ton. So when I started to be around the senior level and started feeling like I had a little bit more leverage at companies, I got excited about like trying to do college recruiting, trying to encourage us to build mentorship programs, internship programs, things like that. And then that just got coupled with, I just got a lot of satisfaction around helping other people grow. That ended up being a thing that I noticed at the end of the day when I came home and I had helped somebody else with something, helped somebody level up, that felt like a good day. So just making a mental note of that, I dug into that a little bit more. And I think as you become more senior, it's important to find the ways you have the most leverage. That's what seniority in software engineering is. It's having leverage. And for some people, that's going to be being really deeply technical, maybe doing deep architecture things, doing kind of cross-company communication. But I think making other people around you better is an incredibly powerful piece of leverage. And so I think as I figured out what it meant for me to be a senior engineer, that was the aspect of leverage that kind of called to me the most is taking what I know and making other people around me better. So I kind of dug into that and it's been really fun to watch people grow, watch people learn things. You kind of build these relationships and send people off and it's kind of cool to see where they're at. You had mentioned the boot camp thing that I had helped build at Instacart. I still go back and like... check the LinkedIn of people who are in that. And like, that's cool. This guy is, you know, a senior software engineer too somewhere. And we worked together when he was figuring out basic Ruby syntax. Like, that's cool that I kind of helped push somebody in a direction. So yeah, I think it was just this really satisfying feeling of you can kind of help direct people's lives, help people like. make these big career changes or grow in their career in a way that really makes a difference. And I think a big part of the mentoring, I like doing the technical stuff, like helping people with all that, but I also like talking about all the squishy skills that come with this job. I think a lot of us get into this because we like the rigid technicality of code and of working with computers, but I think When people realize that it's not enough to just do that, you also have to have the interpersonal stuff, the awareness of your organization. And like we just talked about, the awareness of yourself to know that you're doing what's going to ultimately serve you. I think those are really fun conversations to have with people at every stage of their career. Brittany Ellich (16:03) Yeah, yeah, I love that a lot. And it sounds like, you've mentored folks that were, you know, career changers getting into tech, as well as, you know, all the way up to, you know, I'm assuming folks that are early in career, mid career, etc. And I know you've worked as a manager at one point as well. Correct. Okay, so that's Dave (16:19) Yeah. Yes, which I highly recommend to people. It is a great skill to have. I never thought I was great talking in meetings or like, you know, earlier in my career when I had a meeting, it was always a little bit of like, my God, that's throwing off my day. I'm going to have to get up and talk to people. And then it was my job to talk to people all day every day for like four years. And now it's way easier. Yeah. Brittany Ellich (16:43) Yeah, I think there's a a canonical paper that everybody always recommends about like the engineer or the manager IC pendulum. ⁓ That yeah about how like actually going back and forth between those things really makes you a better engineer and a better manager in a lot of ways. Dave (16:50) Yeah. ⁓ Yeah, like you gain a lot of sympathy for the decisions managers have to make. You understand how organizational decisions are made a lot better. And I think bringing that back to being an IC is a really useful skill. Brittany Ellich (17:11) Yeah, yeah, I agree with that. Is there anybody that you've, like, have you done any of the, you know, I'm getting into tech mentoring recently because I think that the world has changed a lot since when you were working at Instacart doing that. Is that still a thing that you're plugged into at all or? Dave (17:20) Yeah. Let's see, I haven't seen a lot of people who are trying to do the boot camp change thing. Like, 10 years ago, was a lot. There were a lot of people who were like, look, look at this great career path. You can go to school for 12 weeks and make a ton of money and be as happy as everybody else in San Francisco is. I see less of that. I have had a mentee through GitHub's mentorship program a while ago who was pretty early career. And I think they were struggling a little bit with, this for them? I think those are fun conversations. I mean, maybe not fun, fun, but like they're interesting conversations. Like I really appreciated the honesty of somebody coming in and saying like, I'm not sure if this is for me. So I don't know, I like that. And, you know, we talked a lot about checking in, like, do you like what you were doing? Try not to run from something, like run to something. Figure out, try to dissect what you like and what you don't like. Because software engineer is a broad title. I always think about like, you if this were construction, we'd use the same title for somebody who does carpentry and somebody who does architecture and somebody who does, you know, metals, like materials research to come up with stronger I-beams. Like there's a lot of stuff to do under this. under this job title. So I don't know. I do think it is a little different today than it was 10, 15 years ago. So I think those are definitely conversations worth having, especially early in career. Brittany Ellich (19:03) Yeah, I agree with that a lot. find myself drawn to mentoring other women in tech because I had some really strong, you know, women that were very senior that I looked up to early in my career that really like just having somebody to talk to and be like, look, there's a person who is like similar to me ⁓ was, you know, it made a huge difference, I think, in my own career. And I think that there is a lot of conversation. The whole the entirety of women who code that that organization was built. Dave (19:11) Sounds cool. Yeah. Brittany Ellich (19:31) primarily because I think it was like 50 % of women like left the industry by the time that they were 35. ⁓ Like it just, you know, so I find that there's a lot of those conversations I feel like with the folks that I meet with they're like, I don't feel like tech is for me. I'm like, really it is, it can be. I think just like the traditional path might not be it. So I like that assessing of, you know, is this the right path? Dave (19:39) Yeah. Brittany Ellich (19:57) Do have you had a mentor then within your career that was like very honest with you that like got you into this and the help you realize like this is a really great way to to meet with folks. Dave (20:07) I don't know if I've had as many like formal mentors to do that. I've had leadership that's been really supportive in letting me build stuff that I was interested in building, letting me kind of run with things that I was interested in. I think that's been really helpful. I've had, guess sometimes managers, sometimes like much more senior coworkers that have... kind of falling on different parts of the spectrum of, I think it's really good to have people that you can just bring half-baked, kind of kind of nutso ideas to and feel really safe being like, hey, I've got this weird idea, I haven't thought this through, just be a sounding board, like do that. And then on the other end of the spectrum, people that you know, if you come up with a half-assed idea and you haven't anticipated their questions, they're going to maybe not be mean, but they're gonna like, you're gonna get a sense you're wasting their time. And I've liked having both of those people in my life. Like, it's good to have a lot of psychological safety to like play around with things. But it was also good to toughen me up and like teach me to anticipate questions, teach me to like really form my thoughts and come up with, you know, not rely on other people to do all of the back and forth on things and get me to solid ideas faster. by having that, I don't know if I would call it a lack of safety, but certainly a more pressure to come with fully thought out ideas. People who have a little less patience for the chit chat about squishy ideas. So I think both of those have been really helpful in my growth and figuring out how to pick paths, pick things that I care enough about. diving into. Brittany Ellich (21:52) Yeah, I think one thing that I've noticed recently is that a lot of folks are using AI tools like, you know, chat GPT or Claude or whatever, like the chat ones where you could just ask a million questions to over and over and over. And, you know, they never get tired of those questions and are very polite when they respond, you know, that many times. And I feel like there's been some discourse online that I've seen around like Dave (22:05) Mm-hmm. Right. Yeah. Brittany Ellich (22:18) Are people talking to their coworkers less because they can use these tools to get a lot of the answers that they have about things? I'm curious what your thoughts are on that, if you have any at all. Dave (22:28) yeah, no, I've definitely been thinking about that a lot because this is a little bit of, almost reminiscent of, you early on when maybe tech was meaner and you'd ask a question, people would tell you to RTFM, right? The answer's out there. Go look at the documentation. And yes, that's good advice. But it kind of misses what I think a lot of people are looking for when they reached out to people is not just the answer, but the human connection. at a fundamental, like, humans should be talking to other humans. That seems like a fundamental positive thing. But also, like, you build relationships, you build communication skills. Like, it's important to talk to your coworkers to get answers, not just because that's a great way to get answers or the only way to get answers, because clearly we can get answers other ways now, but... It builds that rapport, it builds that trust, it lets you know who to talk to about other things. So I think looking at, I think if you're just talking to chat bots to get answers, you're looking at question answering in too utilitarian of a way, and you're going to miss the softer, harder to measure benefits of conversations. Brittany Ellich (23:36) Yeah, I'm really curious how that's going to change over time because I find that myself too. I'm like, man, I'm not doing nearly as much pair programming as I used to because I think it's just not as necessary to work through problems anymore. But it's still, I I learned a lot from pair programming with other people, even if I wasn't the one driving, because I got to see like, oh, especially working remote, like, oh, okay, this is how they approach this problem. Or these are the tools they know about that I didn't know about. Dave (23:43) Mm-hmm. Yeah. Yeah, you pick up tools, you pick up keyboard shortcuts, like all that little stuff that's not important. You're never going to ask that question, ⁓ but you're going to get stuff incidentally. honestly, it seems like there's probably going to be, it's probably going to produce a gap between people who have gotten that benefit just incidentally by talking to people, and now they're not going to because they're never going to think to do that because they can get their answers somewhere else. Brittany Ellich (24:07) Mm-hmm. Yeah. Dave (24:25) and people who are going to recognize that and then make the effort to interact with other people because they know they're missing that. And I think that's kind of the challenge. Whenever you lose out on some incidental benefit, you now run the risk of having this divide between people who aren't going to proactively seek it and people who are going to recognize it and carve out the time. and extra activation energy to seek it out. Brittany Ellich (24:52) Yeah, yeah. And this might be just me reading into this because I know this is something that we're both deeply involved in, but I wonder if formal mentorship programs are going to be more important to like, you know, there's a reason to talk to people at least because like you're paired together, like you got to talk. ⁓ Dave (25:07) Yeah, absolutely. And I think that's something that can fill that void is instead of incidentally talking to people, you might have to make it a little bit more formal of a thing or at least make it formal to get the ball rolling on things, to get people used to that being a thing that you have to do now that you can ask somebody without asking somebody. Brittany Ellich (25:27) sense. So what does, switching gears a little bit, what is career happiness look like for you right now? Is it like the work you're doing, the team you're on, the craft or learning about AI? Like what is it that is bringing you happiness? Dave (25:39) Yeah. I think, let's see, I think career happiness is kind of a limiting term. I don't think you can have career happiness without considering other parts of your life. So not to completely avoid the question, because I think when looking at how the career aspects of your life affect your happiness, yeah, I think for me right now, it's working on stuff that I think should exist. I think if I were, I don't know, putting ads in mobile games or something like that, I think I'd have a harder time. Mondays would be harder, right? I think it's working with technologies that I don't find frustrating. In general, I like the languages, I like the stack we're doing, things like that. It's the people I work with. I think you can work on a... boring problem with fun people and have way more fun than working on a fun problem with terrible people. So I think that's a big part of it. Am I learning stuff? Am I growing? Do I feel like at the end of the day, I've either done something that wasn't done in the morning, I know something that I didn't know yesterday. Those are good things to do. As I get further and further in my career, recognizing that the turnaround cycle on that stuff is going to be a little longer. think earlier in career, you might get smaller issues to work on, and at the end of the day, you've closed three tickets, and that feels great. Being a little bit more senior, you might have longer satisfaction cycles. It might be pound your head against a bunch of SQL queries to try to figure out how the system really should work and whether or not this data is clean. and you might end the day a little frustrated. This might be what I'm doing right now. But at the end of the week, the end of the month, whatever, you're like, cool. There's now an understanding of the system that maybe nobody in the company had before. That feels pretty good. And then I think going back to what I was originally saying when it sounded like I was trying to dodge the question of career happiness, it's how does... Brittany Ellich (27:26) So it's like a personal story. Dave (27:47) How does all of that fit in my life in a way that feels balanced for what I want right now? You know, like I talked about earlier, I think if I couldn't, I don't know, go to my kid's soccer game or something like that because work was so all-encompassing, for me, that would be a problem right now. That's not gonna be true for everybody. I think there's some people like, hey, I'm going hard on this. I've got a career progression I'm into, a company I'm building, things like that, and there's gonna be sacrifices. For me, it's knowing what I'm willing to push back on in every direction and making sure that the work I'm doing is accommodating to that, the people I'm working with, working for are accommodating to that. And then it all fits in a life that is ultimately where I want to be right now. Brittany Ellich (28:38) Okay, well in the interest of time, I think we're gonna wrap up because I think that you just answered all of the questions that I had related to the last segment there. So that's great. So at the end of every one of our shows, we do a fun segment. At least we think it's fun. have never come, we're almost a year into this podcast and still have not come up with a good name for it, but. Dave (28:45) Perfect. Yeah. Brittany Ellich (29:01) This, we do a different one for every guest that we have on. And what we're going to do is a round robin with just two of us. So maybe we'll both go twice. But we each get a an engineer at a career crossroads. And we give our most honest advice that we can for somebody at this point in their career. Dave (29:20) Okay. Brittany Ellich (29:22) Yeah, so we'll see how this goes. Great. So we're going to call this, What Would You Tell Them? So the first one, you can go first if you'd like. So this is an engineer who is three years into their career that just got passed over for promotion and is wondering if they should go back to school for an advanced degree. Dave (29:27) Okay. Hmm, okay. As somebody who did go back to school for an advanced degree, I would say do it if you're actually interested in the degree and you've got the financial means to do it without putting yourself in a hole. Don't do it because you think you're gonna get a promotion or a raise. You will never pay for a master's by promotions. I don't know, for better or worse, like, our industry doesn't care that much. You can learn lots of good stuff, you can bring that, and it can be valuable, but the degree itself is not going to necessarily help you out. Brittany Ellich (30:16) Valid, yeah, I think that in a lot of cases, you know, having the extra two to four years of experience that you might get by getting out of school and getting the degree might be valued even more than the degree itself. Yeah. Dave (30:24) Mm-hmm. Yeah. mean, grad school is fun, but don't go there like it's not going to get you the promotion. Brittany Ellich (30:34) Make sense, absolutely. All right, so the next one, I guess I'll take this one. A mid-career engineer who keeps getting told that you go into management but doesn't want to and is starting to feel guilty about it. I actually used AI to come up with these and didn't read them too much in advance in part to do this. And this is hilarious because I am an engineer who gets told often to go into management but doesn't want to. Dave (30:53) You bet. Brittany Ellich (30:57) This is definitely not a thing to feel guilty about. think that particularly I've noticed a lot of women in their career end up getting pushed into management. I think a lot of it has to come with, know, like women are often very like empathetic and like very good at like, you know, listening and taking into account, know, typically have high emotional intelligence, ⁓ not comparatively, but. Dave (31:17) I have not had a male manager since I've worked at GitHub. Yeah. Brittany Ellich (31:20) Yes, yes, exactly. Yeah, I think a lot of women get pushed into management whether or not they want to. And then I think a lot of men typically get pushed towards like the more senior IC role. But it's a very different job. It's a very different skill set than engineering. Dave (31:33) yeah. Yeah, like, manager isn't just the promotion from senior engineer. It is very different. Brittany Ellich (31:43) Yeah, and I get that even it's a lateral move. It's not even like a promotion. You go from engineer to manager and it's the same level. So, yeah. Dave (31:45) ⁓ yeah. I've seen that a lot of companies. really do appreciate that they are parallel career paths. Brittany Ellich (31:55) Mm hmm. Yeah. so I would say don't feel guilty about it. And you know, if I think like if to parrot Dave here, I would say optimize for happiness and what brings you joy within your career. If you love mentoring people and love seeing them grow, then maybe a manager role is for you, but you can also be an engineer and be a really great mentor. And I think that that's, that's another path. All right. ⁓ Dave (32:16) Yes. I would say as like in seniority if you feel like there's a good pendulum at your company It's worth considering even if you don't Think you'll like it because I think even if you don't like it You'll learn a lot about stuff like as somebody who's pendulums like there were things I really didn't like about it and that is shaped The things I choose to engage in Brittany Ellich (32:44) sense. Yeah, my last role was a manager for like the last year of it that I was like a tech lead manager. It was a very small company, so you kind of just wore all of the hats. And I do agree, I think that there's a lot to be gained from like really trying to put yourself in a position where you're trying to help another person grow in their career. As a mentor, you're not necessarily as like tied to the outcomes as you are as a manager. yeah, yeah, it's interesting. All right. Dave (32:53) Yeah. Mm-hmm. Yeah. Brittany Ellich (33:13) Next one for you, the career changer who is two months into a coding bootcamp but is struggling and doesn't want to quit because they've already told everyone that they're making the switch. Dave (33:25) Wow, like two months is a pretty short amount of time compared to the amount of time you'll spend in a miserable career. Coding doesn't have to be for everyone, right? It's okay. It's a cool job. I like it. But that doesn't mean everybody's gonna be happy doing it. I think it's worth giving it a try. It's worth getting deeper into it if you have a good reason to keep pushing on it. But I don't know, you're going to be way less happy working a career that doesn't resonate with you and you show up and you're miserable than if you have to tell people, oops, I changed my mind, right? I think that sunk cost fallacy is pretty weak, especially at the two month mark. I don't know, I just talked to somebody who was a staff engineer who left and doesn't really want to touch technology anymore. People can decide. you know software is not for them whenever they want. Brittany Ellich (34:22) Yeah, and think that's actually pretty common. I feel like I've met fewer people that have been in the industry for 35 years or something, always doing engineering. Those are unicorns out there and usually find themselves in some sort of leadership role anyway, even if that's not what they specifically set out to do. Dave (34:29) Mm-hmm. Yeah. Yeah. Brittany Ellich (34:41) Yeah, I agree. All right, last one. Senior engineer who is technically excellent, but quietly miserable. Great compensation, respected team, nothing wrong, but dreads Monday mornings. Yeah, I think my advice in this case would be you gotta probably make a change, because it's not great being miserable. ⁓ Dave (35:05) Yeah. And I think it's tricky to figure out what change to make. felt like, especially when I was living in the Bay Area, there was this trope of new software engineers who would go hard, out, they'd, there a lot of yoga instructors, coffee roasters, like, there was this whole genre of jobs that were for burnt out tech people. And that always struck me as, maybe it's a, found the American extreme thing. We can only lunge from our extremes of burnout to complete abstinence from whatever was hurting you. I think if you're feeling that burnout, that like, I don't want to do this on Monday, you have to... Almost the easy path out is, screw this, I'm going to go teach yoga. Right? I think the harder path is figuring out like... What do I hate? What do I like? Is there anything salvageable from this? How does this job fit into an overall lifestyle that I like? Like if the job enables a lifestyle you like and there are ways to do it in a way that doesn't grind on your soul, you know, that's a worthwhile path. If you're done with it and you want to teach yoga, teach yoga. That's cool. But it's worth giving it a a little bit of deep thought that doesn't just lunge between extremes. ⁓ Brittany Ellich (36:29) of that. Yeah, I feel a little personally attacked because yoga instructor is my backup career. I'm done with software engineering. But I think there's also I mean, think people should also embrace like the idea of working part time too. Like do you have a lot of companies get have offers, you know, flexible working arrangements where you can work part time. ⁓ I'm sure a lot of companies do like you could you could just do less work and do more of the things that you really enjoy and maybe be happier. And I know that a lot of Dave (36:44) Yes. Yeah. Yeah. Brittany Ellich (36:58) people that take that route too. yeah, needs more information, I think. ⁓ Dave (37:02) Yeah, and I think to your point on kind of non-traditional setups, I think a lot of people are afraid to, one, figure out what they want and then ask for it. Like, what's worse that can happen? Somebody says, no, you can't work four days a week. All right, you tried, but now you've learned information. But like, some people make it work and, you know, work four days a week or work, you know, whatever hours facilitate whatever happiness works for them. Like, I don't know. Brittany Ellich (37:13) Mm-hmm. Mm-hmm. Dave (37:30) But you have to do that foundational work of figuring out what you really want or you're not going to actually be able to find something that makes you happy. Brittany Ellich (37:39) Yeah, very true. Well, thank you. That was fun. ⁓ Good example of a few different paths that folks find themselves on. Dave, thank you so much for joining us. Where can folks find you if they want to find you on the internet? Dave (37:42) Yeah. Let's see, so I have a website, dinosaursytoeverybody.com. That's just my personal site with a few blog posts and random stuff about me. I do have a site called Don't Break Prod, which is tiny pieces of tech career advice. And then I've been posting a little bit on Blue Sky lately. Brittany Ellich (38:17) definitely include all of those links to the show notes. And I can't sign off too without saying that you need to plug your band. ⁓ Where can folks find your band? Dave (38:25) yeah. Yes, I do have a spooky ska band called Grave Danger. You can find us on Spotify, Apple Music, wherever you might find your music. And we should have a record out this October. Brittany Ellich (38:43) I can't wait. October even. Yeah, it's like the best like Halloween theme. Dave (38:47) That's our thing. We always put out a record on Halloween. I've never released a record for that band on any other day. I love doing album announcements on a tech podcast. That's perfect. Brittany Ellich (38:58) Yes, well I mean everybody has their parallel life that they're leading. It sounds like music is like is your backup if you know once you're finally done with tech. Yep. Yeah, that's great. Well thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you do on the podcast app of your choice because they're all different. Check us out on Blue Sky and share with your friends. Until next week, goodbye. Dave (39:00) You Yeah, that's my backup. That's my yoga instructor. See ya. --- ## Episode 55: Building Your Own Tech Career Path - Bootcamp, Teaching & Big Platforms with Sabrina Goldfarb - URL: https://overcommitted.dev/building-your-own-tech-career-path---bootcamp-teaching-big-platforms-with-sabrina-goldfarb - Published: 2026-04-14 - Audio: https://anchor.fm/s/102586d64/podcast/play/118425472/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-3-14%2F422027893-44100-2-5252029129e3c.mp3 ### Show notes Summary Sabrina Goldfarb rejected the tech career playbook. No CS degree, bootcamp instead, teaching before big platforms. Now an engineer on GitHub's Copilot team and instructor at Frontend Masters, she shares how methodical planning, patience, and trust in the process led to career growth most thought impossible. If you're considering a non-traditional path in software engineering, this episode proves there's more than one way to build a meaningful tech career. Links * Frontend Masters: Practical Prompt Engineering: https://frontendmasters.com/courses/prompt-engineering/ [https://frontendmasters.com/courses/prompt-engineering/] * Sabrina Goldfarb on LinkedIn: https://linkedin.com/in/sabrinagoldfarb [https://linkedin.com/in/sabrinagoldfarb] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Erika (Eggyhead): https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Erika, and I am joined by... Bethany (00:08) Hey, I'm Bethany. Erika (00:10) We have met while working on a team at GitHub and quickly realized we are all obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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, we are so excited to have Bri Goldfarb on the show. Brie is an engineer working at GitHub and she's the GitHub Copilot team, and honestly she's kind of a model for what it looks like to build a meaningful career in tech without losing yourself along the way. She's navigated chronic illness, burnout, and a non-traditional path into engineering, and she's come out on the other side speaking at conferences around the world and teaching others. So, Bri, welcome to Overcommitted. Bri (01:03) Thank you, I'm so excited to be here with y'all. Erika (01:06) Let's kick off things the way we always do. What's one thing you're currently building or obsessed with learning right now? Bri (01:14) Yeah, so I'm currently working on a new AI agents course as my next part and master's course. And I've been really obsessed with it just because it's also helping me every day on the co pilot team. It's really interesting because I feel like I am always behind when it's like comes to AI, which is funny, like working directly on the product, but it's like every single day something new is happening. And so every single day I'm like, learning something and being like, okay, actually what I learned yesterday is totally out the window now because something new just happened. And I think that's really fun and really exciting to be in. And I feel really lucky to be here. Erika (01:54) That certainly does take some grit to keep going and not get frustrated with and approach it with a sense of curiosity and positivity rather than frustration that things are constantly changing. Yeah. Bri (02:06) and dread. Yeah, no, just kidding. Erika (02:11) Well, let's talk about something you've been very generous and open with us in sharing that you live with a condition that causes severe anemia, and that's not a small thing. It affects your energy, your focus, your whole life rhythm. So how has that shaped your experience as an engineer? Bri (02:34) Yeah, I think it's been really interesting. Up until a couple months ago, I never would have considered myself to be like a chronically ill person. Like I just am like, I get sick all the time, but like I don't really understand why. And when I realized a few years ago that I was dealing with a condition that caused this, it was really hard for me because at work you're kind of expected to be there, especially as a software engineer, right? You need to pair program a lot and do all those things. And I just wasn't able to all the time. I mean, Anemia covers everything, like you said, from like your focus to like literally all my hair was falling out and things like that. And just kind of having those moments every day was really, really hard. but I think it, really taught me how to be a better engineer because I wasn't there all the time. And so I learned like push my code up really early and often and go for like async reviews, right? Talk to more people all the time. Make sure that when I'm looking at projects, I'm not just looking at them. from a perspective of like, what can I bring to the project? But also, how much help am I gonna need from other people and how much can I do just on my own? And I think that's really important for people that suffer with chronic illnesses is to kind of really look at the work ahead of time and say, how much can I do with this without needing other people? So that if I do need to leave for a doctor's appointment or an entire day of an iron infusion. I'm still not getting behind and I'm still able to really make those big impacts and my manager isn't getting frustrated with me. And I think working with your manager too and having an understanding manager is always helpful. But that's something that I've really learned and would love for other people with chronic illness to understand and know is that like, it's okay, you can do it. You just have to be a little more methodical than everybody else does. Erika (04:15) you Yeah, there's that kind of idea of like the mythical man month and this idea that like develop those are constantly overestimating what you can do in an hour, a day, a week, a month. like, it sounds like from your perspective, you're like, well, I literally can't do that because like, I might not even have all the hours in a week that somebody else would have. Like I have to take advantage of like every single minute and sort of plan it out for myself. Bri (04:40) Yep. 100%. And I think that's been really great to be on teams that are so supportive and be in a remote role that's so supportive of that. I can only imagine how people are doing this when they have to show up in an office. So I feel really, really lucky that I don't. Erika (05:00) for sure. Yeah, well, yeah, I guess I've had that experience a little bit to a lesser degree with parenting. Like, I think before having a kid, I would like, you know, push work past 5 p.m. and it was fine and like, you know, whatever hours it needed to get something done, like I would go ahead and put those in. ⁓ And like I still will to a certain degree, but weekend hours, for example, I literally can't spend a whole bunch of weekend time doing work or development or like side projects or anything because I'm hanging out with my kid all weekend. So yeah, it's... It is a mindset shift to really be considerate of the hours that you do have. yeah, recognizing that time is finite and you can only do so much with what you have. And that doesn't mean you're any less of an engineer as long as you're communicating and thoughtful about the way you spend your time. Bri (06:13) Yeah, I think it's so hard to see people who sometimes who are, you know, able to spend a hundred plus hours a week at a roll and kind of see them surpassing you sometimes even in level or whatever it might be, or just see them getting a ton of praise. And I think sometimes like we really internalize that. And I think it's really important to understand, like you said, whether you're a parent, like there's so many reasons that you might not be able to bring. yourself to work that many hours and nobody should ever expect you to anyway, like let's be real. But you know, it's not like doctors get asked what surgery they did on a weekend, but as a software engineer, it's all about what you did on a weekend that was like related to this. And I think it's totally like something we have to really tell ourselves is it's okay to not be there every second of every day. we have lives, like you said, time is finite, let's spend it in like the best ways we can and enjoy our lives. Erika (07:05) sure. Yeah, Bethany, do you have anything to add from your experiences? Bethany (07:11) Yeah, so I, I mean, I've been fortunate that I can give a lot of my time and stuff. And I think too, when you're in that position, it's important to, like you're saying, Bri, not overextend yourself at work because sometimes it's easy to do that because there's this like value and praise and such associated with that. But I think it's so important to find meaning and value outside of work. And even if you don't have like a child or like other things, like still having that value outside of your identity as an employee or outside of that like work role is so important. And a lot of people don't do it because it's hard. It's hard to find that meaning. But I think it's it's so important because it's not sustainable to give everything to work and it's not productive or healthy. to do that. because I mean, if you're ever in a position where you can't give 100 plus hours to work, then suddenly people will be questioning your abilities and such and then that's never a good thing. So it's just not a sustainable thing. And it's always good to find that meaning outside of things and also not reward when when there is that heroic effort. So making sure you try to reward taking time in lieu if you had to work on a weekend or had to respond to an incident after hours and reward taking time off if you're not feeling well and such, rather than rewarding working while you're sick or things like that. think it's just, you have to make the system sustainable and really can be to do that, but once you start doing it, others typically will follow through because they're like, this is way better to not work while I'm actively ill or not able to. So, yeah. Erika (09:01) interesting like the question of motivation and like rewards too where like always find that my harshest critic and A of times when I'm pushing myself, it's nobody else telling me like, you have to do this, you have to like work 100 hours or whatever. Like it's, it's usually me saying those things to myself, like, oh, I'm not good enough. Like, this is not good enough, that kind of stuff. And like, there is, there is usually like a secondary voice in the back of my head, like, oh, this will like get me to my promotion or this will, you know, look really good or this is going to impress somebody else or something like that. like, I do feel like, yeah, it's, always some kind of combination of the two. But yeah, it's, it's almost like, like, eating and like feeding yourself too. Like, I feel like I've developed a bit of like, like a hunger sense when I know that I'm like, pushing myself too hard. And like, I'll feel that, like, physically of like, I need to like stand up and just like, go outside for a few minutes or like, something like that, where, yeah, I feel like I'm starting to develop that. It's, taken me this long, I think, like, to really like understand and recognize those sort of like rest hunger cues, I'll call them. but yeah, it's, it's helpful to like recognize that those exist in my experience and, and honor them. Well, yeah, so that's kind of within work. And then we are all also putting ourselves out there in the developer community. And you've talked about your experience of speaking, sharing, teaching. And those are also things that can induce burnout. So What does that look like for you as far as balancing, putting yourself out there a sense of burnout? You've kind of mentioned that you've found some things that have worked out of experiencing some burnout in the past. So maybe you can walk us through sort of like where you started, what happened and how you handle it now. Bri (11:06) Yeah, so a couple of years ago when the macroeconomic climate, whatever we want to call it, was at its worst, my partner had been laid off and was laid off for a very significant amount of time. And I was lucky enough to be working full-time at GitHub still at that point and have these teaching opportunities which pay, right? So I can't say no to those when I'm, you know, kind of holding up the household. And then also at that time, I had the opportunity to start a startup, which sounded really exciting. That's like my goal, right? My dream is to one day be like going full throttle startups. So I had that opportunity all at the same time. So I'm working on GitHub on the billing team at that point, which was not quite as hectic as co-pilot, but it's still like, was, you know, more than 40 hours a week. And I'm also doing the startup 40 hours a week. And I'm also, you know, teaching on the weekends. And I was running and running until I absolutely hit that wall of just, it's not possible, right? There's only so many hours in a week that someone can do something. And this was at a time before Co-Pilot was, you know, able to write so much code for me where I could just, you know, designate agents all day and do that. It was like, I was putting in all this time. And I think it's really hard in our industry to avoid burnout sometimes because To us, we're just sitting at home on a computer, right? Like this shouldn't be that hard. I should be able to do it all day, every day. I should be able to go, go, go forever. But there is like that mental, you know, tax that we're paying and it's such like a difficult thing to write code and not just write code, but make sure you're writing good code and make sure that things aren't breaking and testing things and working with other people. At one point in the startup, I was running a team of seven people and also working my day job. So. You know, I really hit that wall very hard and it was very hard to come back from. And I'm really lucky and glad that I was able to and able to still maintain my full-time job and everything in that. But now I really try, like you said, and like really check in with my body of like, am I feeling? Because I think it's so easy to ignore it. And also, like you said, it like took me like years to even recognize what does even tired feel like? Like, I don't even know. But there are just these moments now that I'm like, maybe I need a piece of chocolate to like reset my brain and let things go. Or like, maybe I need to like walk outside for 15 minutes and just, you know, kind of have that check-in. And now I'm really trying to take things a lot slower. And I really encourage people to do that. I was once teaching a course and it was about like being a visible engineer in such like a bad economic climate, right? And someone after the class was like, You know, I really didn't like that class. You told us to do so much stuff and I don't want to burn out. And I felt so badly that they thought I was telling them that that's what they should do is like overwork themselves like I was. And I was trying to just tell them like, no, that wasn't my intention. My intention was very much, these are a ton of options that you have and, you know, make sure you're protecting your time and yourself. But, you know, when they said that to me, I kind of like had to take my step back to you and say, like, if they're thinking that's what I'm saying is that like you should be proud of me that I'm doing all these things. Like I'm putting the wrong energy out there as well. So now I'm really kind of trying to focus on that and just, you know, focus on my family, focus on my hobbies, actually have hobbies again, and really take care of myself. And I think sometimes we have to push ourselves a little too hard when things are tough, but you know, and try and really reel yourself back in when you can. Yeah. Erika (14:41) Yeah, definitely taking breaks is great. I also find giving myself small, achievable goals is also really when I'm in the work, that I can do this in an hour. And then once I do it, it feels great and I'm re-energized, as opposed to like... I have to do these five million things, this task is never gonna get done, and so every time I think about it, it just drains me. Yeah, and I feel like I've thought that person from your class before about sort of visibility and getting out there. And a lot of times that has to do with writing blogs. It's really hard for me to write blogs. Yeah, it feels like this huge task. so thinking of that as like, I have to do that to get out there feels really intimidating. But some of these other things like talking in Discord or talking with other developers in person or online doesn't feel nearly as draining to me. Bri (15:49) Yeah, 100%. I think a big thing that I have always done is just been too excited about things. And it was like with the startup, especially, I kept telling myself, like, only two more weeks, and then I'm going to pass it off only two more weeks, and then I'm going to leave my job and just work at the startup full time, right? Like, but there's always more to be done. Like just because this feature gets done, like there's another feature or another piece of customer feedback or something. There's always something else and it's really hard for your brain and I think in software engineering to find an end point because there's just no end point. There's just something else to work on next. And I think that's really hard to not burn out when you have so many continuous points of like, well, just this and this and then maybe this, you know? Erika (16:37) Yeah, cool. Yeah, so in that same kind of area of growth, continual growth and... maintaining this over a long period of time, you've credited a lot of your own growth to patience and a willingness to step outside your comfort zone, which is a pairing that doesn't always get talked about. Usually it's like move fast or like go really deep. so how do you manage both of those at once? Like how do you stay patient while still pushing yourself? Bri (17:12) Yeah, so for me, I come from a non-traditional tech background. I was a video editor for four or five years before I became a software engineer and I went the boot camp route. It took me like literally six years to make the full transition, way too long, which is why I like to teach now because I don't want it to take anyone else ever that long to make the swap because I'm so painful. So for me, I'm very shy naturally, like extremely shy. I hate pair programming. I feel so silly every time still. And so for me, that's kind of how I put myself out there was doing these like teaching things. And I knew ultimately I wanted to teach on a really large platform like front end masters, because that was where I started my journey in software engineering and learning how to be a software engineer. But I knew I wasn't going to get through day one, right? So. For me, putting myself out there and being patient was very much okay. So the first courses I taught, I set up for myself and I just put them in slacks and was like, hey, if anyone wants to come here and like talk about this, let's do that. And then I got an opportunity to teach with the bootcamp I had gone to. And they wanted me to teach people who were considering going. And I did that for two and a half years. And then suddenly I was teaching alumni who were looking a level up and learn more programming languages and become polyglots and things like that. then all of sudden I got this opportunity to do a course at Front End Masters. And that was really special to me because every single time it was like, I was raising that bar of uncomfort of having to teach people who are more and more technical every single time, but also really finding that patience. It took me another six years to go from teaching on my own to teaching at such a big place. And I think it was worth every step because by the time I got there, I had gotten feedback from thousands of people on. things I did well, things I didn't do well, right? That person who told me that I was encouraging the wrong things, like that really made me step back and think, how am I saying things? Like, how are people perceiving the things I'm saying? Teaching people who knew nothing about software engineering taught me about how to break down concepts for people, but also teach people who already knew a lot. And so I really think that all of it kind of came together for me in a really nice way. But I really think that's important that people be patient in their career because sometimes things are going to take longer than they want no matter what their end goal is, but also put themselves out there because you never know what could possibly happen. I never would have thought that thousands of people would be watching my courses and reaching out to me and, you know, telling me all these amazing stories and that's like, I could cry thinking about it. It's so wonderful, you know, it's truly amazing. Erika (19:43) Well, I'll turn this question to Bethany, but feel free to jump in, Brie, if you have thoughts. If there's ever been a time when you stayed too long in your comfort zone or you've moved too fast and skipped the depth. Bethany (20:01) Um, you know, I'm not, I'm not so sure. Um, I think like, you can always, uh, look back on things and have regrets because I mean, hindsight's 20-20, but I think most of the time you're doing what you need to do with the information you have. And so I, I struggle making decisions. So I try as hard as possible not to, uh, regret what decisions I do make. So I just try to be like, well, maybe next time do this or do that. But I think my experience is like, where I'm at now is a culmination of those decisions and where I've been. So I don't know if I could say like, I stayed too long in things because I mean, I could say that me writing Go my entire career is staying too long in my comfort zone, but I really enjoy Go and that's where I like developing. So yeah, I think it's just if an opportunity comes and you're able to, and you feel like switching then. do it, but if you're also happy where you're at, then stay. I don't think there's necessarily a wrong answer there, or it really just depends on what you want with your career and where you're going. Erika (21:19) Yeah, I think the reflection look back is helpful to sort of like learn from in the past, but it's also good to give yourself your past self grace and say, I was doing the best with what I knew at the time. Yeah, I feel like I tend towards the moving too fast side of the spectrum. I'm ambitious when it comes to pushing myself out of my comfort zone. But sometimes that does kind of get me in trouble where I end up doing too many things at once or agreeing to something that I have no idea how to do. But I've also learned that that's not unique in engineers. was talking to somebody the other day and he's a... Is he principal now or distinguished? You know, like very high up in GitHub. And I was like, well, how would you do this? And he's like, I don't know. He's like, I almost never know how to do these things at the start. But then I like figure out like I figure out the end goal and I work backwards. I was like, well, that's really comforting that you don't have this all in your head either. And like, it's OK not to know things up front. So. Yeah. Bri (22:34) That's so cool to hear. I love when people who are at that level are like, have no idea, because I'm like, no way. Like, you ever feel like that? No way. Erika (22:44) Yeah. Yeah, well, especially like, since it's, it feels like people define these points of like, I've made it, like, you know, this level is like, well, now I'm... Bri (22:59) Mm-hmm. Erika (23:00) Like now I'm at the point that I said that I would be and great. Like I don't have to do anything else. It's how I can see from the outside or even how some people can sort of communicate their career. and success. Like you mentioned sort of this idea of working for a prestigious tech company and that being sort of like the North Star for a lot of people starting out their careers. And yeah, mentioning that like chasing that from day one can mean that you're missing a lot of growth along the way. Yeah, so I guess what does that kind of mean to you and your goals? Like, is this something that you've come to realize over the years? Is this sort of a lesson that you've had to teach yourself? Or is this something that you kind of knew from the outset? Bri (24:02) Yeah, so I think and I don't think there's anything wrong with people chasing those goals, especially really in their career. Whatever people want to do, I think they should absolutely try and do. But so for me, this comes from my brother went to Harvard. OK, so he's like perfect Harvard graduate. He has like a photographic memory. He's in Mensa. He's like truly like that person, right? But he still has like amazing social skills. I don't know. He's like one in a million, right? And I went to the University of Miami and that's still a great school. But when you're looking at your sibling that went to Harvard, who everybody when he graduates is fawning over, please take my job, please take all this money. And you're like graduating and like, I don't have a job, what do I do? Right? Like, I think there's this like competitiveness that I've just felt my entire life with him, even though we're very close. And I saw that very much when I went to the bootcamp that so many people were graduating and just so hyper fixated on being at a fang company or being at a company like GitHub or Microsoft. And it's funny because I'll get messages, like dozens of them in a week, like, I graduated yesterday. Will you please refer me to GitHub? And I'm like, sure, but also maybe take some time and learn. And my thoughts on it are just, I went to a startup right outside of the boot camp that I went to. And the amount that I've learned in just a few months there was absolutely incredible because at GitHub, if something goes wrong, I have Bethany and 30 other people to help me. And half the time I'm just passing it off to another team anyway. I'm like, this wasn't even our problem, right? But when I was at the startup and there were three software engineers on the entire team, we really had to dig in and own anything. And sometimes there was nobody to help you. And I think there's just so much to learn that you don't necessarily get at a larger company. And I think it makes it easier to go one way versus the other, right? I can easily go from a startup to a large company and say, now I have all this help and I have all these internal tools and all this other stuff. But if I'm trying to go the opposite way from GitHub back to a startup, which I've considered, like I said, I really want to be in startups, it's so much scarier. It is genuinely so scary and so hard. And I think a lot of people just really see the prestige of the name and just really want that the same way I always wanted like Harvard under my name. And don't get me wrong, I think it's really cool. There are recruiters in my inbox every day because of it, but I actually never even applied to GitHub. It wasn't like a goal of mine to get to a big company. I knew I always wanted to be in startups. They reached out to me because I just happened to be really involved in the developer community and we're like, hey, we're doing a lot of interviewing. Would you want to come and interview? And I was like, Okay, and I took the interview as a joke and I don't mean that like in a rude way, but I took it thinking there's no way I'm ever gonna pass. I took it to practice for other interviews. And so when I got the offer, I was like, well, now what do I do? Like I got this amazing offer from this amazing company. I can't say no, but it just wasn't, it wasn't in my path initially. And so I just want other people to consider that and see that and see that like there are other paths to take and all of them are equally good, even if you you think a name really matters or a salary really matters or something, you know, I just, I just want other people to consider like other options as well, because I feel like sometimes there's this hyper fixation on these names. And as we've seen over the past couple of years, these brands aren't really loyal to us. So why should we be so loyal to them, you know, and, you know, give other places a chance to follow me. Erika (27:37) Yeah, for sure. Yeah, you've also mentioned that sometimes like doing anything that gets you closer to your goal is worthwhile. Do you have any concrete examples that come to mind for times that that was true for you, where you maybe did something that felt sideways but turned out to really matter? Bri (27:59) Yeah, I think kind of what I was talking about before with the teaching and kind of really building up. So it's funny, there were so many people along my path of teaching that were like, are wasting your time. You are teaching for almost no money to all of these people and taking all of this time to prep all of these courses and do all of this work for nothing. They're like, it's not gonna get you anywhere. Like, it's not gonna do anything for you. And I was like, please just like trust. my instincts. I was like, can feel it. I can feel that I'm getting better at what I'm doing. And I can feel that this is like what I was meant to do ultimately. So just like trust these instincts. And you know, the people in my life were very supportive and were like, okay, but if it doesn't get you anywhere, don't say we didn't tell you so. And you know, it was one of those moments where it was very much trust the process for like four plus years. And when I finally got the opportunity to teach on such a larger scale, I was like, going over to all of them and being like, I told you it would work, I told you it would work. Not like, told you so, right, but just like an excited way of like, and they were all like, you know what, you were right. Like now, you know, now I've had the ability to go from teaching these 15 minute lead code problems to this one hour lecture, to this two hour lecture. So when I had to prep this eight hour course, it was like, okay, I can do this. It was still really scary and it was still a totally new mindset shift. you know, it... took a lot of different skills and it was really scary. But at the same time, I had prepped myself so well for it that it just felt much more doable. And so that's why I think that if people, if their ultimate goal is to work for a thing, but they're not getting it right away, okay, so work at a startup and learn everything you can about the data structures within it, right? Prep those system designs and do all the things that you need to do, whatever your goal is. there are so many tiny steps you could take that might feel like they're not important and might feel like they're taking you too long. But if you actually stick with them, like, there's no chance you won't get there. And I don't want to say that, like, sure, there's still a small chance. But, you know, just putting yourself out there, I think really does give you the best chance of doing whatever you want in life. And I don't know, if I could ever help people to get there, too, then that's kind of my end goal as well. So Hopefully the things that I'm doing are showing people you don't have to have a traditional tech background. You don't have to have a CS degree. You don't have to be a man. can do all these other things and be kind of different. And that's like a positive thing, not a negative thing. Erika (30:34) What about you Bethany? there any times that you've almost skipped something that ended up shaping where you are or any things that you credit that were kind of off the beaten path that have helped you? Bethany (30:47) Yeah, I mean, I'm going to kind of flip this and say and talk about something that I did skip that shaped who I was. But I so. I didn't major in computer science, but I did minor in it and I knew I wanted to be a software engineer. So I was very much trying to go through that process of interviewing at tech companies. And I was going for any company that would take me or interview me. I was like, please hire me. And did not get any offers. So I also applied for a PhD program and I got into that for computer science. And I did PhD because they pay for your PhD. They don't pay for your master's. So anyways, I got accepted and I felt very fortunate about that. But I ended up also getting an internship and got a job offer through that. And so I was stuck with the decision of whether to pursue the PhD or go. like take a job in the industry. And I really agonized over this because a lot of people wanted me to do the PhD. That was prestigious. was very, like, I could learn a ton about a certain area. And I definitely was like, well, what? what route do I want to go? But I knew which route I wanted to go. I wanted the job. That's what I had always wanted, but because I was like, but this isn't prestigious enough. This isn't, I won't have a doctor next to my name or whatnot. I struggled with it, but I ended up choosing the job. And I'm so happy I did because I saw my friends who were in that program, my friends who were in other PhD programs, really struggling going through that. And it is a struggle to a PhD, you have to really, really want it and really know what you want to research. Have a love for that. And I just did not have that. It wouldn't have been right for me to stick with that. I would have been so unhappy had I stuck with that. So I'm eternally grateful I did. And I respect everyone who does go through and gets their PhD. This is not me discrediting that because I think that is amazing. But it was, I think, okay for me to say that's not for me and to not finish that because I'm very much a completionist. like, I have to see through what I start, but it's okay. I don't want to do it. So, and that's okay to say that and to say, okay, I'm going to stop here. Bri (33:04) That is so cool. What an awesome thing. Like, I never would have even thought about, like, the fact that a PhD takes so much, like, knowledge of what you would want to study and write about and think about, but that makes a ton of sense. Like, what a great way to, know yourself that much too. That's so cool. I didn't know that. Wow. Bethany (33:22) thank you. No, it really is. think because you end up going into this niche like research area and you just have to so much love for that. And some people do and that's amazing. And I, we need people that want that, but it's okay to also not be that person and to not want that as well. But it was hard to accept, but we're here. That's fine. Bri (33:28) Yeah. Erika (33:45) Wow. Awesome. Thank you both for sharing so much about your stories. And we have spent this whole episode about talking about enjoying the journey. So naturally, we're going to end by asking about the worst parts of our job. So welcome to Would You Rather, Software Engineering Edition, where there are no good answers, only less bad ones. So I will ask a would you rather question. We'll go around and say which which we would prefer of these horrific theoretical situations here. Alright, the first one is would you rather do a live code review of your most embarrassing commit or give a keynote with no prep time? I think I would rather give a ⁓ Bri (34:34) I me too. I think me too. I would just make it up at least, but don't look at my worst commit. Bethany (34:40) Yeah, same. I know everybody is like, you shouldn't associate your own intrinsic value to your code, but man, I do. Erika (34:50) Yeah, yeah, there's some stinkers in my my get history that I would not want to drag up. So I would I would just take a keynote and talk about something random and then leave the stage. Bri (35:02) Same. Same. Erika (35:04) Alright, second question. Would you rather work entirely in a language you hate or always work solo with no team? Bri (35:14) I'm going solo with no team and Bethany I'm really sorry to say this to you but go is that language for me. I know it's so popular and I know it's horrible to say because every job is gonna look at me and be like no we're all moving to go but go is that language for me. Bethany (35:21) ⁓ no! No, I mostly feel bad because that's all our team does. No, I would also work solo with no team. Definitely. But Rails was that for me, so there was a point where I was like, man, this is horrible. Erika (35:44) Yeah. Yeah, I know. I feel like I feel the same way a little bit about Rails. And that's like, pretty much really what I work in now. So I think I'm gonna pick that one because it's my lived experience and I enjoy my team a lot right now. So. Okay, next one. Would you rather have 1,000 unread Slack notifications or a code base with zero documentation? Bethany (36:17) Gosh, the zero documentation. I cannot handle notifications. Like I'm looking over at my Slack, there's two notifications right now and I can barely handle that. Erika (36:25) you Bri (36:26) live notifications. I cannot imagine, like, I forget how to run the server, like my server, even after a year of being on a team. like, how do I run this again? You know what? I don't know. There's like something in my brain that just doesn't want to remember things. So I need documentation. Erika (36:45) I feel like this answer has changed for me with like AI spelunking because usually the first thing I do now is like spelunk, like have an AI assisted sort of like navigation and exploration if it's like an area that I don't really know. So yeah, I think at this point I would say code base with zero documentation because I'm with you every single Slack notification drives me nuts. Okay, one more. Would you rather that your rubber duck talked back or that your manager never talked at all? Bethany (37:22) I want to hear my rubber duck talk. That sounds great. Erika (37:25) Thank Bri (37:26) Me too. Me too. Erika (37:31) Would it have like a certain personality? Like, would you have like a sassy duck or like, like a nice duck? Bri (37:31) Unless it's a mean rubber duck, I don't know. You know, what if my duck tells me that my code is bad? I, you know what I mean? Like what if it stresses me out? And then I'm like, now I'm pair programming with someone who's mean all the time. I don't know. Erika (37:42) Yeah. Bethany (37:48) Ha ha. But if your duck criticizes you, then you never have to do a live code review of your most embarrassing commit, because the duck would stop you from doing that. Erika (37:58) Exactly. Bri (37:59) True. Erika (38:00) Yeah. I feel like this would be a good antidote to the sort of yes anding of AI assisted coding, where you have your LLM that's like, yes, everything you do is great. And then you have your sassy duck that's like, that sucks. What are you doing? Yeah. ⁓ Bri (38:18) Yes, I will take that. I will take Sassy Duck. I'll definitely take Sassy Duck. Erika (38:28) man. Well, Brie, this has been such a fun and refreshing conversation. Thank you so much for your openness, your honesty, and for modeling for all of us what it looks like to build a career that actually fits your life. So where can people find you if they're looking for you? Bri (38:43) Thank you. Definitely LinkedIn is the biggest place. I'm on LinkedIn too much, but you know, if I take a while to respond, I'm sorry. I get like anxiety about responding to messages. But anyway, other places they can find me are on Front End Masters. My prompt engineering course is already out and I'm teaching an AI agents course in May. So you can find me on Front End Masters or just look at my GitHub and don't mind my terrible commits. Erika (39:16) Awesome. And we'll link the front end master's course and your LinkedIn in the show notes. Bri (39:22) Awesome. Erika (39:23) Well, to our listeners, if this episode resonated with you, please share it with an engineering friend who needs to hear it. Follow us wherever you your podcasts, check us out on Blue Sky, and we'll see you next week on Overcommitted. Bye. --- ## Episode 54: Building Bulletproof Systems: Warren Parad on Software Engineering for High Availability - URL: https://overcommitted.dev/building-bulletproof-systems-warren-parad-on-software-engineering-for-high-availability - Published: 2026-04-07 - Audio: https://anchor.fm/s/102586d64/podcast/play/118053194/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-3-6%2F421534978-44100-2-d98fc8efad7.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany and Erika sit down with Warren Parad, CTO and co-founder of Authress, a user authorization API built for reliability. Warren shares how his team stayed fully operational during the massive AWS US-East-1 outage in October 2025 using DNS failover and multi-region strategies, and what the delayed alert logs taught them about timestamp trust. The conversation kicks off with a candid discussion on AI agents and critical thinking, whether managing multiple coding agents is really multitasking or just micromanagement, and what the trade-offs mean for early-career engineers. Warren traces his reliability-first mindset back to his roots in electrical engineering and healthcare IT, where late-night on-call pages through Citrix proxies and hospital billing systems shaped how he thinks about uptime today. The group also explores what it really takes to build a Five Nines organization and how hiring practices need to match the reliability culture you want. The episode wraps up with a round of Never Have I Ever: SRE Edition, featuring Friday deploys gone wrong, blaming DNS, and discovering outages from customer tweets. Links Authress [https://authress.io], Warren's company, user authorization API for software makers. The product he's building and wants to plug. Adventures in DevOps Podcast [https://adventuresindevops.com], Warren's podcast, co-hosted with Will Button. 300+ episodes on DevOps, engineering leadership, and cloud architecture. How When AWS Was Down, We Were Not [https://authress.io/knowledge-base/articles/2025/11/01/how-we-prevent-aws-downtime-impacts], Authress's blog post detailing their resilience strategy during the October 2025 AWS outage. Referenced in Theme 1 questions. So You Want to Build Your Own Authorization? [https://medium.com/authress/so-you-want-to-build-your-own-authorization-e00965314b7f], Warren's article on why authorization complexity creeps up on teams. Referenced in Theme 2 questions. An Interview With Warren Parad, CIAM Weekly [https://ciamweekly.substack.com/p/an-interview-with-warren-parad], March 2025 interview covering Warren's views on CIAM, FedCM, and the future of authentication. FedCM, Browser Native Auth (Adventures in DevOps Episode) [https://adventuresindevops.com/episodes/259-federated-credentials-management-fedcm-browser-auth/], Adventures in DevOps episode diving into FedCM and why authentication should move from user-land to kernel-land. Warren Parad on LinkedIn [https://www.linkedin.com/in/warren-parad/], Warren's LinkedIn profile. Warren Parad on Bluesky [https://bsky.app/profile/wparad.bsky.social], Warren's Bluesky profile. Warren Parad on GitHub [https://github.com/wparad], Warren's GitHub profile, includes Authress repos, OpenAPI Explorer, and other open-source work. Authress Knowledge Base [https://authress.io/knowledge-base/articles], Technical articles from the Authress team on auth, security, and infrastructure. Warren Parad, Personal Site [https://warrenparad.net], Warren's personal website. Hosts Overcommitted [https://overcommitted.dev] Bethany Janos [⁠https://trustyduck.dev] Erika (Eggyhead) [ ⁠https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Bethany, and I'm joined by... Erika (00:07) Hey I'm Erika Bethany (00:08) We 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've learned. 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 Warren Perad, CTO and co-founder of Authors. a user authorization API that helps developers plug in authentication and access control without building it from scratch. Warren has two decades of experience spanning healthcare IT in Wisconsin, e-commerce platforms in Switzerland, and now running a security SaaS startup. He's also the host of Adventures in DevOps, a podcast with over 300 episodes featuring industry veterans on everything from infrastructure resilience to engineering leadership. And most recently, authors made headlines for staying fully operational during the massive AWS outage in October 2025. So he knows a thing or two about building systems that don't go down. To kick us off, what's one thing you're currently building or obsessed with learning right now, Warren? Warren Parad (01:11) I think that's always the challenging question to answer. And I knew I had to be prepared for this podcast because you ask every guest this question. honestly, after a few episodes of people bringing up different IDEs and using LLMs on our podcast, and we try to stay very far away from anything AI related, just because it seems like everyone else is talking about it, I felt the need to sort of go out and review how those LLMs function and whether or not you can do some software development. So right now I'm trying to avoid diving into cloud code right now. And I did spin it up before the podcast and I feel like the experience I'm getting is you just have to wait for a lot of time and I don't know what to do while that's happening. It's been quite a long time in my experience, know, from, I don't know, 10, 15 years ago where there was a time of just having downtime and I don't know what to do with it anymore. Bethany (01:57) Very valid. is, you have this like complexity thing, like you can be like, oh, I'm gonna run more agents, but then you have to manage more agents. it's just kind of like a foot gun there. So yeah. Warren Parad (02:11) Yeah, think multitasking seems like the direction it's going. And I don't mean to steer the episode in that direction ⁓ as far as the topic goes. But I I was discussing with my CEO, and she's like, well, haven't you ever managed multiple teams before? It could be similar to that. I'm like, yeah, it could be if you also were a bad manager and were micromanaging each of those teams so you knew exactly what was going on. And I feel like I don't want to micromanage five plus agents so that I can get work done. So I really need to figure out, maybe it's just not the time for the agents yet where you're in a mode where you can get feedback quick enough for it to be valuable to use it. Because right now, I feel like the current state of the world is we're just waiting for it to do the work that you already know it's supposed to do. And that's not a great place to be in. Erika (02:53) Yeah, it's definitely a fine line. I'm learning how to both split brain myself to find those tasks that are interruptible that I can do while something is running. What's something that I can do that's low cognition enough where once I get the, this task is done, I can switch back and forth? But yeah, also the level of feedback you need for each concurrence. system that's running to like give it enough information and then also like know when to steer it in a different direction. It is definitely a skill in and of itself and you have to question what returns you're getting at at various points. Warren Parad (03:33) mean, it's interesting you bring that up because there was a study that was backed by Microsoft about the impact of using LLMs on critical thinking out of Carnegie Mellon. And if you use LLMs, then the conclusion is you're swapping off your expertise in whatever the area is for an expertise, if at all, using agents or LLMs or whatever you're utilizing. I think it's really important to keep that in mind where. You're basically saying, don't care about the skill anymore. Let it atrophy. I'm going to swap out being able to micromanage a bunch of agents performing work. Bethany (04:04) Yeah, it's very interesting because it's such early days with these things that it's hard to tell if there's bad best practices or what impacts this has on your career, your psyche or well-being. So it's very much that like a day to day thing. It's one day it's like, we shouldn't do this. But the next day it's like, no, we should do this. And then just trying to figure out how to do this and how your job is morphing in this new world if those are the expectations. So it's all very like live learning on this. Erika (04:38) I'm like. And like, how do I tell them my critical thinking is atrophying? is there like a way to like, is there like a critical thinking test that I can take every week to like judge whether I'm going up or down in different areas? Like. Warren Parad (04:53) You say that and now I'm wondering maybe that's the next new great startup idea pitch like actually ensuring that you're not degrading over time by leveraging your work. But I did realize that part of the effort goes into taking all of these nuances that you've learned over your career and codifying it in some way so that you can have an LLM run straight away. Bethany (05:14) Yeah, absolutely. It's very much like documentation first or making sure comments are there first. Warren Parad (05:20) yeah, that's why went into engineering so that I could document more for sure. I do, So one of the questions I feel like I do get asked is like, how does this affect especially early stage engineering for those that are inexperienced or coming out of university? And I think this is one of the areas where it's a sort of this bias we have being on the leading edge where we assume everyone's using this technology. Everyone's making changes and it's right for everything. Bethany (05:24) Yeah, that's a fun part. Warren Parad (05:47) And that's just not the reality. feel like if we look at some statistics over the last years, still like 50 % of the websites on the internet run on WordPress. I don't know if that statistic is true anymore because WordPress themselves are the ones pushing that number. But even if it's remotely close, it does tell us that realistically, there's a lot of technology, a lot of companies, and a lot of businesses that aren't tech first that are still using lots of things that have nothing to do with AI in any regard. that should really tell us, if companies aren't investing in AI, then you don't need to worry about how AI is progressing because it won't help you get those jobs. And if companies are really firing engineers because they can replace them with AI, then you also don't need to learn about AI because you're not going to get those non-existent jobs. Bethany (06:30) Yeah, it's really a catch-22 in terms of optimism for the job industry coming in, but it really is. I cannot imagine what it's like being a new engineer entering this world or entering this landscape because I feel like so many of my learnings was from that aha moment of doing it manually and going in and researching that bug and not necessarily being told exactly what that bug is but having to do the due diligence. But on the converse side, maybe it's like, we have these super engineers that just, they have that baseline experience already and are just getting that next level earlier, but who knows? Warren Parad (07:04) I think there is one of the challenging questions, and I joked about this on one of the later episodes of our podcast, was that, what is productivity really? What are you measuring? And my joke is that, for sure, it can't be lines of code. But I think this is actually what people have gone back to measuring effectively, is that only output matters. And we know from the entire history of the economy and business, output is almost completely irrelevant. So it's quite an interesting story to see companies these days who clearly must never have had any sort of business KPIs, no strategy in how the business should go forward, what makes it a good user experience, and are now just turning out more code. I think any company that just cares about producing more, like we'll just see them evaporate in the next five to 10 years. And really all that will be left is not the companies that use AI, it's the companies that have figured out how to make their business strategy work better with the technology tools that are available. Erika (07:59) feel like this does transition us really well to the idea of systems design and reliability because in my experience, that is not something that LLMs are particularly good at like recommending or like, like they can like read the docs, they can read the best practices, but like that critical thinking piece is so crucial to good systems design and like experience. So. Yeah, I know that's that's kind of the the next thing we want to talk about and I'll hand it back to you Bethany. Bethany (08:31) No, thanks for the transition, Erica. Yeah, so we brought up in the initial intro that that author has made the headlines for surviving the AWS October 2025 incident, which I feel like should be on a t-shirt that I survived the AWS US East one incident. And there was a lot of huge names out there that went down like Disney, Reddit, New York Times. Curious if he could walk us through what that day looked like, maybe critical thinking skills that popped in there and, and. like how your systems responded throughout the day. Warren Parad (09:04) Yeah, so I think there's like a really simple story for how we've decided to implement a nice strategy for dealing with stuff. So I think the industry agreed term is like, just don't be in US East one. And then when AWS goes down, because US East one is the least reliable region, as far as new deployments go, you won't have an impact. in welcome back to the real world, you have customers that live in multiple regions and one of them may be US East one. So if one of your customers made a poor decision and want to push that responsibility onto you as well, you're forced to run in that region. And so the question is, what do you do? And if they're multi-region as well, you do need an answer for when something happens. I think we are well plugged in to technology today, what's going on with other companies and whatnot, that you will hear the Cloudflare being down, AWS being down, long before it may even impact one of your systems. Either because the technology choices you made are slightly different, or you know someone who says, I have to cancel lunch and go home really early because I need to get back on because right now all our systems are crashing. For us, it's always a scary moment because there is a question of, we going to be impacted? Do we have an impact right now that we aren't identifying? And it was pretty quiet for us, honestly. You start to hear things on the internet. It used to be Twitter, not anymore, but one of the communities you're in, Blue Sky, for instance, and you'll see people complaining like, is this down? Yes, AWS is probably having an incident that's not reported in the health dashboard because why would that be the case? And the major strategy we have in place is DNS failover. So we're using AWS, so Route 53 health checks, where we're dynamically discovering whether or not we can connect to our databases or we need to switch regions in some way or there's a latency that's too high and would violate our SLA. And from there, there's any number of technologies we have in place which allow failover. either switching the whole region over because we're using the DNS record or using a strategy where we're calling one database in one region and then automatically following up with calls to a backup region if there's an issue. So we have the dashboard. You can see there's an event. We start getting 500s from connecting with our database because we're actually using DynamoDB. So it was very quick for us to turn around and expose this problem as an incident that could then trigger Roughly 3 to failover and then there's a little time where you wait. But during that time, individual requests can still fall back to a different database in another region. And then you see it switches regions fine. We have paired regions for every local one, for each of our customers. later when it was supposedly resolved, you see it come back up. Interestingly enough, we did discover an incident for us that happened during this time. And we kept getting paged by our own systems throughout the day. It was a good learning because what had actually happened is our incident system was identifying errors that were in production. It turned out that those errors were what triggered the failover. But because the region was down, the event log was delayed by like six, eight hours. And so long after the incident had been resolved, our systems started reporting that there was actually a real problem. And that was because AWS finally got the logging infrastructure working together. And so we started getting spams of emails and notifications that there was another incident happening. Not one that affected our systems, but was quite annoying for anyone on call at that moment to have to wonder, OK, is there actually a real problem that's happening? Bethany (12:20) that's so interesting. Yeah, when you get paged and it's not an incident, is definitely always the fun moment where you're like, okay, is this actually worth looking into or not? And it risks your availability because you're like, I'm being drawn in so many places. Warren Parad (12:32) Well, it is. Yeah, so I think the learning here was in regards to when you're logging particular data, make sure that the timestamp of the incident is well tracked in the event and not trusting the event system that's managing the logs or using CloudWatch or exporting it somewhere else using date timestamps from that thing. And it can be very difficult to make sure because your logging doesn't just go from one location. It's being passed or pipelined through many different services which may each have their own idea of like when now is in a way. For sure, we were getting that, and we weren't, in this case, checking to make sure that even though the timestamp was in there, that first of all, it was the right timestamp, and second of all, that the timestamp was actually relevant for alerting. Because knowing about an alert that happened or an error that happened six hours ago is something that we should still follow up on, right, in case there is a delay. But at the same time, it isn't something that should be the highest priority. Bethany (13:28) That totally makes sense. Clock says being unreliable, the eternal issue. Before we move on, Erica, I'm curious if you have any really bad incident stories you want to share or that you've been a part of that might be similar. Erika (13:44) Well, so the first one that comes to mind is not really an, like a live incident, but I did work on, when I was back in my consulting days, I worked on the COVID contract tracing center in the state of Massachusetts. And it was like, was, our, our, our piece was on AWS. We had some like, you know, services and they have like a call center, you know, offering um, in ADOES and then there was a Salesforce piece. Um, and so we had like an integration between the two for like managing, um, COVID cases and, um, whatever like update we were doing, like the Salesforce team had, um, I don't even remember. exactly what it was now, but there was some like issue with their migration piece that ended up taking like six hours. So what whatever was supposed to be like a, you know, one hour update. Like I was I was online until like six in the morning because we had to do it in like off hours too. So like we started the migration at like, I don't know, like seven p.m. or something. And it was like an 11 hour thing where like my piece was the very last. part to go, so I had to be online until the very end. Yeah, so that's the first one that comes to mind for me as far as developer horror stories of site management. What about you? Warren Parad (15:06) That reminds me of some of the things I had to go through in my past. I got my early love of being on call when I was working the healthcare IT company in the United States. their strategy was when there's an alert that goes off, you have to follow whatever the customer's on call strategy is for dealing with your technology stack. So it wasn't like you could just handle it from your own company's SOPs. was whatever was driven from them. You know hospitals the bleeding edge technology right there known for that. Add so at this time basically what it was is. We had to join a group meeting call of course this was so when this happened to of course it was like two thirty in the morning and you had a specific work laptop like you're not allowed to use your own and a special beeper and yeah cuz that was a thing back then right and. You get on and you first of all have to jump through three different automated voice setups and already even get to a shared bridge call where they're going around and manually assigning user IDs and passwords for people to log into their system on the call. Only three people could be logged in at a time because they wanted to watch whatever was happening there. And then finally they'll say your name and give you credentials and you log in and you're like, this isn't the application. I don't know how to debug what's going on here. have to use Citrix to log in to proxy into their servers. Wait, no, actually, I have to first SSH into their VPN, and then from there, I can run a remote desktop protocol to get into the production servers. And then from there, I can actually access production application. Because of course, what you want to do is have support engineers from a third party company log into your production servers in order to figure out what's wrong. there's already an issue going on here, but let's not get into that. And then once you're in there, the company says, you know you have to do? You have to run this script and make sure that the script reports success. And I'm like, which part of this could not have been automated, honestly, when there is an incident? No, I get that a lot of systems in a hospital organization are critical. And if there's a power outage and your data center's on site and you have to cycle the power, your stuff is going to go down. And you may be down for an hour or 11 hours, in Erica's case, and be waiting for stuff to come back up. And I get that you need to validate it. At the same time, I was working in hospital billing claims. There was no reason that it was absolutely critical for me to validate the state of the database. And you know what? If that script said error, I don't know what I would have done. I can't fix this. I was not the primary developer who worked on the claims part of the billing application. And you know what? I don't think, I have a lot of stories from them, and this is not the worst one. Bethany (17:39) That sounds like a nightmare, honestly. Especially for something that's very customer-facing with things that plug in, that's wild. You've mentioned that, or you've talked about leveraging that reliability-first design. Did that come from some of those experiences? And I'm very curious about how that's involved through your career and what that looks like in practice. Warren Parad (18:01) Yeah, so I think I got really lucky in a lot of regards, fundamentally in our current company, which I actually don't call it a startup because we've been around for almost eight years now. But realistically, an important aspect here is that if you want to build reliable software, there's a lot of technological solutions to handle that. But fundamentally, it comes from having both the culture and the mindset of the organization embodying it. And for that, it means hiring people that care about the reliability or build reliable systems by default without having to think a lot about it. And so I think whatever your experiences are, they're incredibly critical for this. Mine came from absolutely relevant for sure. The hospital, ⁓ healthcare IT, for instance. But I think I got my start as not a software engineer. I was electrical engineer and in computer design in university. And so I never built a compiler from scratch. don't know half of the computer science professors or famous names when other people bring them up. I have no idea who those people are. I can tell you how to build a laser or receive microwaves from outer space or do digital signal processing, but software engineering, that was not my primary area. And so when I started working in the hospital healthcare IT industry, I didn't go straight into software engineering. I got put into this sort of what would now be ⁓ SRE or any sort of observability. And I feel like that helped create the perspective of having uptime be really important. Like the technology was not the first aspect. The second part was engaging with the customer a lot. Like I didn't realize this, but I had weekly calls with a whole bunch of different hospital organizations on how their technology stack works. And it didn't occur to me until much later where that was a required aspect of product engineering, where you actually understand what the users need. And those two things were like the front and center of how I started my career. And I feel like they followed me a lot. So I don't see outputting code or a functionality, classes, services as ever the primary solution. And I didn't realize that was how I was thinking until I started my own company. And I started getting into stuff and saw that, wait, no, we need to hire specific people with specific mindsets. Why do I think this way? Why do we hire people that think this way? And then it sort of was an ⁓ epiphany moment for me. Bethany (20:10) that definitely makes sense from getting that SRE perspective early on and seeing failures probably firsthand, especially in hospitals, thought that would influence how you think about software going forward. Erica, I'm curious, how does your team think about failure? Do you feel like your team applies a reliability first mindset or do you feel like that's somewhat of an afterthought? Erika (20:35) Yeah, I think it's... interesting thinking about reliability at the scale of GitHub because you can only control so much. like you have your piece that you are thinking about and like you can do your best to like, you know, make that as reliable as possible. But you're kind of working within the constraints of the system. I guess kind of depending on where you are in the latter. what projects you're working on. But yeah, so I think like within that system, I guess the same rules apply where like, you we were talking about AWS earlier. It's like, well, you know that US East one is the most likely region to go down. Like, you know, we know which databases, which schemas are the most vulnerable. We know which, you know, which data shapes are, are the most prone to failure. And that's kind of a lot of times the thought process that we go through first is like, okay, when we're building this, what do we know that might fall over and how can we plan for that? How can we build for that? How can we find the biggest risks for what might happen, what might go wrong? So yeah, would say that we go through that checklist at the start of any project. And yeah, especially on the off space, the other constraint is like we build the framework, but the teams that consume it have their own data. we don't always control how it operates in their system. But it's all good feedback. We'll get feedback from teams like, hey, this is not working, so we'll have to redesign something given those constraints. yeah, that's what I think about from reliability. Bethany (22:26) Yeah, that makes sense. I feel like often it's make it work and then make it reliable follows after. But I think sometimes to your point Warren, I know you're laughing at this, so I would love to hear your thoughts here. I think there's different scales where it makes sense. I mean, designing for reliability, you'll often have to kind of like Warren Parad (22:37) You Bethany (22:48) rip out everything that you put in and then rethink it. So especially for critical services like authorization, it makes sense to think through our reliability from the start. Warren Parad (22:58) Yeah, absolutely. I think you're really onto something there. And I almost want to point back to something that AWS had said a while ago while designing their S3 architecture. It wasn't just design one time from the ground up in, I don't know, almost 20 years ago. It was redesigned at each level of scale. And so it really is important not to just design something or design reliability in based off of... There's no such thing as like, it's going to be reliable. There's a question of like, well, how reliable does it have to be? And that's really a business question. Like how many users are going to be there? What is the sort of interaction that are going to be happening? What are the failure modes that can be part of it? And a huge part, I think Erica sort of brought this up, is it is part and driven by the organizational structure and the intrinsic incentives that exist for each team and individual to build reliable stuff. So yeah, sure, the design of the technology is one thing. Do you want one nine, two nines, five nines like we have or something more durable depending on what actual customers are bringing to the table? Bethany (23:59) So on that point, I'm very curious. What does a Five Nines organization look like? Is that something you've intentionally been building from the start of Authors? Or is that something that's come about later on in the company's history? Warren Parad (24:13) Yeah, so realistically, it was something that we had decided as part of the product that we were building that it had to be so reliable. What we had done is we went to a lot of competitors that we didn't like at the time that we had tried. And we saw they were promising high reliability only on their enterprise plans. And we're like, I don't understand that like you either really need it or you don't. And as something so critical as an infrastructure component, as like identity and access management, it just can't be down ever. you have the same expectations of your cloud provider as you would of your identity management. And so we see what we have as really infrastructure. And from that regard, we created these expectations on whatever product we were going to build. And from there, we made sure whenever we added a new piece of technology or a framework to our stack or a new service from AWS or another cloud provider, we know what the failure modes that have to really be thought about fundamentally. You don't just add Like a good example that I have a talk where I go through this and one of the things is like a lot of companies build probably what's two nines or even one nine, 90 % uptime, which is probably good for a lot of business scenarios. you probably don't need to be extra reliable. If you ask people, hey, do want this to be reliable? They're going to be like, yeah, sure, reliability is great. But if you ask them how reliable and they say, well, something other than 100 % uptime, maybe they thought about, well, what actually makes sense for the business? And the thing that they miss is that you don't get from two nines to three nines or to five nines by adding something. You actually almost always need to subtract because the lack of reliability usually is by the addition of third party services or dependencies or a pattern that you've introduced. So a lot of our endpoints become much simpler in nature. The way we design stuff we know has to be less complicated. Because as you add complexity to an endpoint or a piece of functionality, that's another place that multiplies the likelihood of there being downtime or an incident if there is an issue. If you have three components and there is a likelihood of a bug of equal percentage in each one of those, then the likelihood of there being no bug is a multiplicative factor, right? For each additional factor you add there, it's going to increase the risk of a problem. And so in order to decrease it, you actually need to remove stuff. So figuring out what makes sense for individual endpoints or individual flows for customer use cases is even more important than it is if you're just like, just going to build a prototype and throw it on. It doesn't matter what its uptime is. Bethany (26:36) That definitely makes sense. I feel like the calculus of service availability with dependencies and stuff with such a pivotal read and realizing that having critical dependencies just you have to factor that into your availability. can't just say, yeah, we're five nines unless AWS goes down or unless XYZ goes down. have to, it's, you're basically taking ownership of what that dependency is doing in your stack as well. Warren Parad (27:04) for sure. I mean, there's another aspect here that's probably important to talk about is that we can say SLAs, and that's really just a contracted number. Like, actually doesn't matter how much we go down. An SLA is just saying, if we're down more than that, some legal consequence applies or financial consequence. But it doesn't actually say anything about how often we're sort of trying to be up. And so there's a big difference between promising an SLA of 5.9s and building for an SLA of 5.9s. Bethany (27:31) Yeah, definitely, So, I mean, speaking in about auth and maybe the anti-patterns, do you see any common auth anti-patterns that teams often fall into that maybe you'd like to suggest other alternatives? Warren Parad (27:50) I think there is really this aspect of it's simple and we'll build it ourselves. And I think you you spoil this a little bit with ⁓ there's maybe a link here to an article I wrote a long time ago. But I think a lot of people don't think about how much investment they have to put in to evolve a piece of architecture or technology or a stack or framework that they've added a long time ago. Things like SDKs. often don't provide the necessary level of control or functionality in order to overcome a lot of the challenges, especially in the auth space, because there's a lot of protocol or standards to wrap around. And the interesting thing there is that every single identity provider out there did something custom on top of the protocol. It's nice to think that SAML and OAuth2 solve everything. But realistically, in our implementation, maybe here's a little bit of a secret sauce, is that we have a custom implementation for every single identity provider that any of our customers brings up because all of them have giant foot guns or do something non-custom that isn't even in the standard. And going through the documentation isn't sufficient. So the likelihood that an SDK supports it or provides for multi-service interactions is just not believable, realistically. ⁓ Another one is like not really understanding what the use case is and maybe I'm just as a broken record of like going back and like talking to your customers about like what is actually the need and God forbid thinking about like more than six months out and figuring out like well, how is our product gonna evolve? What are the needs there? I think from our own research a lot of companies end up spending a million plus on running a team to manage their ⁓ identity and access management infrastructure because Either they started with an off-the-shelf open source solution that they installed, and now they're basically on the hook for making it reliable, where a lot of open source was not built to be reliable. They're built to be a runway for converting into a paid product. Or realistically, it doesn't have all the functionality. Or you spin up the team, be like, we're going to do a project. We're going to install, insert your favorite open source technology into the stack here. And then six months down the road, the team doesn't exist. And now you're blocking critical functionality for your application based off of the lack of simple things that, if you had thought about the problem space, are actually required. Things like invites or group or user management, granular or resource-based access control, I think are just some common examples. Or, you know, I think maybe you ask, you ask pitfalls. And I think the number one thing is throwing extra claims into your JWT. And maybe I'll just leave it at that. that's, see if that triggers anyone. Erika (30:14) man. Yeah, yeah. Well, that's interesting. Yeah, it must be really interesting to see all the different use cases from people who use your startup or use your product. And yeah, like the knock on effects of like their customers and what they're looking for, because it is so true that like authorization at its core, I mean, authorization and I guess you do you do so you do identity and access management. you have the auth and the authorization piece, which, yeah, from my experience, those can get conflated very easily. ⁓ Warren Parad (30:50) Well, I mean, I feel like you're almost joking about that. But I think the truth is, when we started off, it was specifically just the access control piece without identity management. We call it identity brokerage or really aggregation, where you're getting identities from multiple different sources. It could be GitHub Actions, GitLab workflows, or AWS as an entity that's trying to authenticate into another service, or service to service interactions, or with your customers who have their own sort of API keys that interact with you. And so I think. We didn't do any of that to start, but what we found is that a lot of companies and their engineers, there's this sort of bias of experts perspective where you think everyone has more knowledge of the area than they really do. Like most engineers never touch anything related to auth. And what we realized is it didn't make sense to have a product that was so focused on access control because most of the engineers, most of the people that ended up on our marketing website or came to our product already had expectations of what that means based off of the lies they saw on someone else's marketing page or expectations that they. had from the company they worked at, the culture or whatever terminology they used, which may or may not be industry appropriate. That doesn't matter. They have those expectations. They come to your website. They come to your product. And now they expect things to be there. And so what we found is like, identity is like a solved problem realistically, other than all of these little bells and whistles that are necessary for every single identity provider, because Google inserts an HD claim. Apple says you have to use H-Mac signing for secrets. And the list goes on and on. But the reality of the situation is, that it is cheap to add this layer on. So we do, we throw that in there, and now we can tell everyone, yeah, sure, we still have that. They can get what they need. But when they come and they realize what the challenges are that they actually have, that their users actually have, then we get into the features that are actually critically important here. Erika (32:31) Yeah, yeah, mean, because it can be so many different levels of nuance, like you said, where it's like, have like, ⁓ read, write admin, like, okay, that's authorization. Also this like fine grain access control, like that's also authorization. So like, it's not a one size fits all and... Yeah, like how you implement it, how much you care about it, how much you build it is really dependent on your product need. Warren Parad (32:58) Yeah, it actually goes further than that. It's like if we just say the word authorization in HTTP, there is an authorization header, but you're actually passing an identity token or an access token. You're not saying the authorization or the permissions that are required there. It just represents the user identity. Authorizations also is a word in the payment space. You get pre-authorization or authorization to bill a credit card. Same with in the hospital world. You get authorization for a doctor to perform an operation based on whether an insurance company will will pay or support it, or whether or not the hospital will. And so you may be coming from a different space where those words actually have a completely different meaning, and then trying to apply it again actually does create confusion. Erika (33:39) Yeah, and there's also the idea of like timing to like what needs to be immediately available or how long the authorization lasts. How long do these permissions like apply? Is it a single use? Is it a multi-use? Yeah, can be a very simple or a very complex space just depending on what you're building. Warren Parad (34:01) Yeah, you brought up one of the most ridiculous ones. You know, the thing that I like to think about is that the access token represents identity, the user, and not the permissions or the authorization. And so the idea of trying to force, deny or block a token or revoke it after it's been issued doesn't make sense. My identity is still who it is. I didn't change. So therefore the token changing doesn't make sense. But once you start sticking permissions into the token, that's when you start ending up with some of these problems. And it's very difficult for people to see these long tail issues that show up when it seems like such an easy solution to just cash some additional data in the token and then just pray everything works in the future because you haven't run it. Bethany (34:38) Well, I'm noting down a lot of thanks for the future because I have definitely been on teams where it was just throw it in the claims and call it a day. So I'm taking notes. Warren Parad (34:50) You know, I love this one because I think it's one of the most common ones. If it's some static data that very rarely changes, yeah, for sure, go ahead and throw in the claims. So claim just for anyone who's listening who's not familiar with JWTs or JWTs pronounced according to the RFC, you can add additional properties to the JSON Web Token with whatever you want in there. Sometimes people want to throw like the tenants or company IDs in, you go ahead and do that. But then the question is what happens when someone adds in access to another company or tenant? you have to cycle the token in some way and that may force the user to like log out and log back in in order for that to be persisted there. And that still works even, but then you start to get in more complex systems where you have different services with different databases and different resources and some users should have access to just this resource and not that resource and all the resources from this tenant in this service but not this other service even though it's the same tenant. There is MSPs which are basically managed service partners which are ⁓ managing the customer tenants for themselves, but on behalf of the customers, and they shouldn't have access to anything other than being able to manage stuff, where do those permissions go? And the important part here is often the tokens are returned as part of the HTTP header or the URL or the body in some way, and then you're limited in size. Trying to send the token and the authorization header with claims in it means that you're going to be limited in the header size. Now, well, technically, according to all the RFCs, there's no max header size. If you go above like four... four kilobytes, you're gonna start running into problems. And so if you have something that could be potentially unbounded array inside your token, you just created a time bomb for your organization, for your company even, the business could eventually come down at some point because you did that. Bethany (36:29) That definitely makes sense and I will learn from this for sure. Warren Parad (36:35) Hahaha Bethany (36:37) Zooming out as we're kind of wrapping up, I'm curious, like we've talked a lot about technical anti-patterns, but as a CTO, I'm curious if there's any product and business anti-patterns that you've noticed as you're building a business and you're leading a business. Is there anything you've noticed that a lot of companies get wrong and you feel like you've done right by your company? Warren Parad (37:03) Well, I think it's still too soon to say that we've done right. I have this sort of morbid joke. So anyone who doesn't like dark humor should probably skip past this part of the episode. It's that you really can't define whether or not you did something that was regretful until the moment you die. Because anything you do now could turn out good, even though at the moment seems bad. And things that are very short-sighted seem good now, which often companies focus on, are bad in even the medium and long term. And so that can be definitely a challenge there. One of them that comes up and I think hopefully resonates with your audience is that on the subject of candidate hiring and interviews. that's, I think there's like some statistic out there which is that less than 50 % accuracy for hiring candidates into positions, like less than 50 % accuracy, like I more often hire the wrong person than the right person, it means I should actually just flip a coin every single time. So like, most people who are in the interview process, they're not experts there. They don't fully understand what they're testing for. And I think that's one thing that you really have to realize if you're in this position, that how are you going to make sure that you are getting the right people into your team? And part of the problem of building a company is ensuring that the culture you're building, which is really just a key word, a business key word, a corporate key word for saying you are a group of human individuals and what together they make up is now the culture of your organization, making sure that you have the people that are aligned in the future that you want to build. And one of the problems is, especially in our space, we think about having reliability, which means we need people who build reliable stuff. I like Simon Wardley's breakdown here of pioneer settler town planner, basically archetypes. Not everyone maps to one of these models, but the idea is... Some people are better or prefer to operate in a particular area and solve particular problems. Maybe they prefer to do greenfield stuff versus really think about optimization. And if we're hiring these town planners who want to build reliable software, is our interview process set up to ensure that those are the people that we're going to hire? Notoriously, in the interview, you ask rapid fire questions or ask questions on the spot, which require being able to just respond immediately. Well, I don't think town planners optimize for handling those sorts of things. And so if you're interviewed, the standard interview process, which even if you did it correct, you're still, means you, maybe you hire the right person there, you're, you're biasing to hiring the wrong people for the role. So I think really it's not just about the technical skills that are being tested for an interview. It's also the format of the interview, which is super important. Bethany (39:39) I feel that so deeply. It's a- Automatically ⁓ preparing for interviews is honestly just about seeing if you can fill that format that they're testing for. And then it just becomes about passing the test, which isn't necessarily the same thing as finding a good employee or finding the right fit for your team. So that's really cool that you all have spent so much time thinking through this process and how to get people who do have a good fit in the organization. a mutually beneficial partnership in that respect. Warren Parad (40:13) Yeah, you know, it's really that perspective. It's the company wants to hire the right person and you want to have the right person working for you. And that means that it shouldn't be about trying to skirt the system. It shouldn't be about, you know, making sure that you have all the evidence perfect for it because you're going to miss out on something important. And I think that's definitely a challenge that often is left to the engineers who have free capacity rather than the best ones in the organization or untrained interviewers because you know, we can just hire someone to use one of these LLMs to do all our coding for us now. You know, what could possibly go wrong? Bethany (40:45) What could go wrong? So speaking of which, this is a good transition to our fun segment actually, which we've pulled together a never have I ever kind of prompts. So instead of taking turns, we'll just list these out. And I guess we'll give like maybe three chances. whoever... first, I mean, we're not drinking, but we'll, guess, win bragging rights for having fun experiences and fun stories. So we'll just, I guess, say when we put down a finger for our audio listeners and go from there. So we'll start off with a fun one. Never have I ever deployed on a Friday and regretted it by a Saturday morning. Erika (41:33) Bye. Bethany (41:34) You've done that? Okay, okay, so that's a finger down then. Any fun? Like, did you get paged for that? Warren Parad (41:35) yeah, for sure. I think realistically ⁓ most breakages happen when humans change stuff. Things usually don't break on the fly, runaway memory leaks or whatever are rare. You have plans. You canceled them in that regard. You hope the on-call alert wakes you up and you can fix it. And usually they're the dumbest things like, like it should, it's like a null reference exception because the language we're using isn't Rust. Bethany (42:03) Yep, yep. Good old Rust. Erica, do you have any experiences with this? Erika (42:07) ⁓ if I do, I've blocked them out. Bethany (42:10) Yeah, same. I'm having trouble thinking of any that I'm sure I have, but... Erika (42:17) I've regretted it by Friday evening. Like I've definitely like deployed my PR at like noon on Friday being like, ⁓ there's, you know, this is like a simple UI change. And then like, I get stuck in the merge queue for like six hours because again, like you said, some, some, something very like bizarre and weird is happening. And then like, I'm still in the merge queue at 6 PM or something. But usually by Saturday morning, I'm, I'm, I'm, I'm good. Bethany (42:20) True. Warren Parad (42:44) I'm jealous of your ability to just purge your memories and not like just dwell on the mistakes of your past. Bethany (42:50) I probably need to do more reflecting on it to feel shame for past mistakes to be honest. Erika (42:53) Yeah. Bethany (42:56) ⁓ okay, so never have I ever blamed DNS when I had no idea what was actually wrong. I'm gonna put my finger down. Erika (43:04) ⁓ Bethany (43:05) Or maybe less DNS, like networking. It's like, it's a networking blip. And then it's really, I don't know what's happening. Erika (43:13) Okay, yeah, I would put my finger down for that. Just like general networking. Like, I don't even know. Warren Parad (43:19) I think we've seen that there is this aspect of if you guess, you waste a lot of time potentially playing around with trying to fix a problem that doesn't exist. And so it's always better if you don't have the sufficient logs to spend an extra, spend the first part of the incident trying to de-stress. I think this is the standard thing. Like if there's an emergency, don't panic, don't make assumptions, just calmly do the next thing, which honestly is add some logging to prove. your guess rather than trying to throw out a fix to immediately get there. Bethany (43:48) That makes sense. Yeah, a lot of times it's pressuring on mitigation, mitigation, and then it's like, well, if you're totally blind, it's kind of hard to figure that out. ⁓ okay. Never have I ever rolled back a deploy that made things worse than the original bug. I'm definitely putting down my finger for that one. Anything involving state is always going to be a ⁓ wild ride fixing. Erika (44:04) way. Warren Parad (44:12) I feel like there's an LLM involved conversation here. Bethany (44:14) Mmm, true, true. Warren Parad (44:16) There's a lot of SRE AI products that are coming out and from our own experience, if you could automatically rollback or rollback was the right thing, you probably would have had a unit test or something in place that would have caught the problem anyway. So the likelihood that the rollback will fix it and not run into a database migration threshold honestly is getting smaller all the time. Bethany (44:36) doing heavy lifting and assumptions on the quality of tests there. No, it's true. Okay, never have I ever been woken up by a pager duty alert and silently hoped someone else would grab it. Erika (44:49) I don't think I've done this because usually when I'm woken up by a PagerDuty alert, I have nothing else in my head. It's very much execution mode and there's no other thoughts, but I have definitely slept through PagerDuty alerts before. Yeah. Bethany (44:58) Yeah. Erika (45:06) Or I've had the moments where like, guys had these where they like come up in your dream and you're like, wow, that's so weird that I'm getting paged in my dream. And then like you like slowly wake up and you realize that like it's actually the pager going off. Bethany (45:19) I feel that it's very much like execution mode. You're like, all right, we're in this. Honestly, I wish I could subscribe to an alarm service that's pager duty because that probably would get me up in the morning better than. Erika (45:24) you. Oof, what a life. You Warren Parad (45:32) There are those alarms out there that if you don't wake up, they start donating money to your charity of choice for every five minutes that you let pass. Bethany (45:41) And then I'm like, it's for charity. I'm sleeping for charity. Erika (45:43) It's a good trigger. Warren Parad (45:44) This is interesting because there was actually a study out there that basically reviewed if you charge a fee for penalizing people for doing something that you don't want them to do, they see the fee as sort of a justification that it's okay to do that thing. So it was about picking their children up late from daycare. If you warned the parents that what they're doing is unacceptable by leaving their child there too long, then they took the hint. But if you said, yeah, for every 20 minutes you have to pay an extra 20 bucks, They're like, ⁓ it's free, or not free, but it's paid daycare extended service. Like, I'm paying for that benefit. And they don't see it as a feedback to make a change. Erika (46:19) and Yeah, knowing you Bethany, I feel like you would respond better to like donating if you got up in time. Like every time you get up with your lawn clock, a puppy would be saved. Bethany (46:22) Interesting. Warren Parad (46:31) You Bethany (46:34) That's what we- my gosh, I would- yeah, that's true. That's true, that's the alarm service that needs to be built. Okay, we'll do one more since we are coming up at time. Never have I ever discovered an outage because a customer tweeted about it before monitoring caught it. Erika (46:37) Yeah. Bethany (46:49) I'm putting down my finger, but I'll let others, which I've lost, but. Warren Parad (46:53) I mean, I'll put a finger down. I won't say tweet, but we do have communities for our products. And I'll say there is something valuable here. We call it a gray failure, which is that there is an infinite number of problems that could go wrong, and we can't possibly validate on every single one of them. And so a thing that we need to realize we need to optimize for is exposing an interface for letting people who discover problems report them to us, because they may have more stringent tests or a chain of actions that we didn't predict that is important for them, like network hops or regional based validation, or maybe a library on some weird version of Ruby or whatnot that I hope no one's using. And we need them to report those to us because we just aren't able to find everything like that. And then it gives us an opportunity to improve. And so I think this is an important aspect. How quickly can customer reported issues be escalated to someone who can fix it is something that we think about. Bethany (47:49) Yeah, think it's like it's very valid and we have something similar with our status page where if we see an influx of traffic to our status page we're like, okay, what's wrong? ⁓ But it is so helpful to have user feedback because it's truly interacting with the users is so important. yeah, I would say Reddit and Twitter are definitely parts of our Warren Parad (48:02) Amazing. Bethany (48:15) strategy, especially for working on copilot and how things change quickly. Yes, absolutely. Now, a lot of we've been sent down a lot of rabbit holes for sure. So it's very much about validating what actually is a is a thing versus not. So Warren Parad (48:21) You have to be careful of the noise though, right? It's really helpful to know that if there are questions or let's say there's no problem, if there is a question, customers reporting that there's a confusion somewhere means that there's still something that needs to be fixed, right? Documentation in your docs or in the API or maybe there's an action which has confusing results and you just wouldn't know about that if you didn't expose this mechanism and then watch it for what actually happens. Bethany (48:57) Absolutely. All feedback is a gift. It just might take some digging to actually get to what the feedback is sometimes. Warren Parad (49:05) There's a story there. Bethany (49:08) No, I read it in a book actually, so it's... yes. Okay, great. So, wrapping up, where can folks find you? Warren Parad (49:10) Okay. ⁓ Yeah, so I'm unfortunately on LinkedIn and Blue Sky. think honestly pinging me through the podcast webpage or one of the community discord servers if you've got something. I'm also an overcommitted discord server, so if there are questions about this topic, I'm happy to answer them there as well. Bethany (49:31) We got a plug too in that. Well, thank you so much, Warren, for joining us. It's been an awesome conversation. And thank you, Erica, for also sharing your experiences here. And thank you, listener, for tuning into Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye. I said all right. --- ## Episode 53: Scaling Search Engineering at DoorDash: From Monoliths to Custom Search Engines with Satish Saley - URL: https://overcommitted.dev/scaling-search-engineering-at-doordash-from-monoliths-to-custom-search-engines-with-satish-saley - Published: 2026-03-31 - Audio: https://anchor.fm/s/102586d64/podcast/play/117577892/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-2-27%2F420903138-44100-2-3ada707b0f111.mp3 ### Show notes Summary In this episode of Overcommitted, Satish Saley, a senior software engineer with extensive experience on DoorDash's search platform team, discusses scaling search systems at a hyper-growth company. This conversation dives deep into software engineering challenges and software development strategies that impact programmer productivity and career growth. Satish details two major engineering transformations: rebuilding the search indexing pipeline with Kafka, Flink, and Elasticsearch, and later replacing Elasticsearch with a custom search engine based on Apache Lucene, which significantly improved performance and reduced costs. The episode also explores the complexities of migrating off monoliths, securing leadership buy-in for technical rebuilds, and why respecting legacy systems is crucial in engineering culture. Additionally, the hosts share personal stories of database pivots and conclude with a confessional segment on technical decisions that didn't age well. This episode is packed with insights for software engineers and tech professionals interested in the intersection of technology, scaling, and work life balance. Links * Satish Saley on LinkedIn: https://www.linkedin.com/in/satish-saley-65527525/ [https://www.linkedin.com/in/satish-saley-65527525/ ] * Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law [https://en.wikipedia.org/wiki/Conway%27s_law ] * Build Faster Indexing with Apache Kafka and Elasticsearch: https://careersatdoordash.com/blog/open-source-search-indexing/ [https://careersatdoordash.com/blog/open-source-search-indexing/ ] * Introducing DoorDash's In-House Search Engine: https://doordash.engineering/2024/02/27/introducing-doordashs-in-house-search-engine/ [https://doordash.engineering/2024/02/27/introducing-doordashs-in-house-search-engine/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany, and I'm joined by... Bethany (00:09) Hey, I'm Bethany. Brittany Ellich (00:10) We are joined this week by Satish Saley a senior software engineer who spent years on DoorDash's search platform team where he co-authored two major engineering transformations. First, rebuilding the search indexing pipeline with Kafka. Flink and Elasticsearch to handle a rapidly growing catalog and later replacing Elasticsearch entirely with a custom in-house search engine built on Apache Lucene, resulting in a 50 % latency reduction and 75 % hardware cost savings. And he's now bringing that experience scaling systems at hyper growth companies to LinkedIn. Welcome Satish. Satish (00:50) Thank you, thank you Brittany for having me. Brittany Ellich (00:53) Awesome. To kick us off, ⁓ Satish, what is one thing that you are currently building or obsessed with learning right now? Satish (01:00) ⁓ Currently, I'm obsessed with learning anything that new comes out in AI world. Definitely the open-clothing that is ongoing, that is on Marauder. I have been learning that. ⁓ Yeah, I have been trying that in a few, in a sandbox environment. ⁓ Yeah, I'm more passionate towards what is new and what is the skill set that we have acquired so far and how to bridge the gap. between these two to figure out something new. Brittany Ellich (01:34) Nice. Do you have an open claw bot then that is is current that is running currently or. Satish (01:39) Yes, I have something on my old laptop. ⁓ Yeah, today I'm taking some time to ⁓ move it to Azure cloud so that it works in more scalable fashion. I'm facing some problems with my laptop, like the old laptop. Brittany Ellich (01:56) Yeah, classic. I've noticed a lot more memory problems that I have recently. I wonder why. It's weird. ⁓ Cool. ⁓ Yeah, so we wanted to talk a little bit about the experience of going from early days at a company like DoorDash, ⁓ what it looked like when you first joined. So can you take us back to the beginning of working at DoorDash and how things, what was the vibe on the team when you joined? Satish (02:02) Yeah. Yeah, sure. So I joined team in 2018. So the vibe was like a really start-up vibe where you like people are wearing many, many hats. You are not just joining a single team. You get to work on a lot of different things all through the tag or to the stack. like you just name it like whether it's a ETL pipeline or whether it's a backend UI or like a search engine or like some consumer facing problems or some ML things. ⁓ So that was the vibe there. And in terms of scale or like in terms of search, if you talk about ⁓ the search was still being served by ⁓ the monolith application that Doordash had at that point. ⁓ Basically our team's mission was to be the first service, be the first microservice at DoorDash, which gets extracted out of this monolith and just make it work and make it scale. So that was our mission when I joined the team. Brittany Ellich (03:32) That's cool. Yeah, I use DoorDash a lot, probably more than I should. And ⁓ it's one of those things that I really love realizing like, like there's a lot of work and effort that goes into these applications that you don't see when you're just using them. So ⁓ the search part of it, was really fascinating. Satish (03:37) Okay. Brittany Ellich (03:49) Have you, were you passionate about search going into it or is this like just the team you landed on and you just ran with it? Satish (03:56) I never had such experience before joining DoorDash. I was originally slated for a different team altogether and the search manager at that point, he reached out to me saying like, hey, do you want to try out something in the search domain? We need some people ⁓ who has worked on microservices. So I said, okay, I can give it a shot. Let's see, let's learn some new things. So that's my segue into. Brittany Ellich (03:59) Okay. Satish (04:25) search ⁓ as a domain. ⁓ Yeah, and I loved it there. I learned quite a lot of things throughout my journey. Brittany Ellich (04:36) That's cool. Bethany, do you have any experience with like scrappy initial startups of growing from there? Bethany (04:44) Yeah, I mean it was around the same size as GitHub but less of an engineering culture, I would say. I mean... I've mentioned this on the podcast before, but my initial team, which was a little designed to make a little chat app on marketing pages, when you click and so you can chat with an agent that originally was a monolith. And then they decided they wanted to break it into microservices, but not like two or three microservices, but like 20 to 30 microservices. So I think that was like trying to scale, but maybe not in the direction we needed to scale in ⁓ given that time. So I do think it's ⁓ when you're talking through scaling the typical things like microservices or having like Kubernetes and things like that, it's really important to take into account what your true scale is and whether you do need all the shiny new things. So I've definitely been in a position where it was... We maybe were trying to scale too much too soon and it just made it an engineering nightmare for our for a team to maintain Brittany Ellich (05:57) Yeah, there's definitely a spectrum between ⁓ monoliths and microservices and it sounds like you are very much at the end of the spectrum. ⁓ Satish (06:03) Yeah. Brittany Ellich (06:06) So Satish, one of the articles that you had shared before this, and I'll make sure to link them, of course, in the show notes, talked about how you went from store search to item search at DoorDash, which was like a different problem. Was this part of the scaling ⁓ that you were going through or like when you were switching away from Elasticsearch? Or can you describe that a little bit? Satish (06:28) ⁓ Yeah, so I think ⁓ this is on a high level a problem that we solved over the period of time as DoorDash grew. So DoorDash, typically when you think of DoorDash, you might think like, okay, I just get my food delivered, ⁓ but there are many more ⁓ verticals to DoorDash. Like you can get flowers delivered, you can get convenience and grocery items delivered and... ⁓ When you look at this problem from a business point of view, a restaurant probably have like 20, 30 items on the menu, but if you go to a convenience store, if you go to a Walgreens, there are like literally thousands of items, like more than 5,000, 6,000 items. So this directly translates into information retrieval problem. So where for a restaurant search, you... might not focus that much on the items. You probably, when you think of ordering something, you think of like, okay, hey, let's go to so and so store and like order some food from there. But for convenience and grocery items, you think about like, hey, I want to order tomatoes, I want to order eggs. That's how your thought process naturally begins. And that is like your main... ⁓ a top of the funnel, how the queries get generated from the user's point of view. ⁓ that's how like we, ⁓ when we were designing the systems, we also needed to make sure that, these are not only catering towards ⁓ a restaurant ⁓ problem point of view, but these are also getting towards the item POV. And ⁓ when you're defining the architectures, when you're defining your constructs, those are also scalable. when you have these mini items loaded into your retrieval engine. So yeah, so in a nutshell, would say this is like ⁓ an ongoing problem that we solved as the DoorDash grew, as the systems get matured. ⁓ But yeah, that is also, I would say, kind of one of the inputs for us to go from ⁓ a hosted search engine versus... going into an in-house search engine. Brittany Ellich (08:49) Did you know going into the Elasticsearch part that like this was likely something that was going to be replaced or wouldn't scale past a certain point? Or did you, was it like a stepping stone or like a final thing when you did it? Satish (09:01) I would say definitely a stepping stone. ⁓ So when you're working on a technology, right? When you're working on a retrieval engine, ⁓ definitely in a startup phase, you want to build the business. Because if you don't have the business, then building technology doesn't make any sense. So you want to propel the business as fast as you can by making use of whatever is available right at the desk. And when you scale the systems, when your business grows, then you look into, you drill deep into the things like, okay, probably a better idea to ⁓ bring in some efficiency, probably a better idea to go more deeper into the technology and like bring in new technology. So that was ⁓ what I would say our mindset was. ⁓ right at the beginning, like at least in 2018. ⁓ That, okay, these are like the stepping stones that we are going to build to ⁓ propel the product further. And later on, let's see what other people are doing. And if you just look around, there are like so many blog posts ⁓ in the e-commerce domain, ⁓ where how companies have evolved, how they ⁓ build their search infrastructure. So... I would say DoorDash is not very different or not like an outlier in that journey. So yeah, in short, so I would say we knew these are the stepping stones that we need to pay forward. ⁓ then finally, we will have a ⁓ tech-driven or a tech-heavy platform where ⁓ you would have more ⁓ each each of the dimensions like the product, experience, platform, everybody can go into different dimensions and dig deep into those dimensions. ⁓ So yeah, I would say definitely a step stone towards that. Brittany Ellich (11:11) Yeah, that makes sense. And then for the rebuild suggestion, was everybody on your team bought in on, know, yeah, let's rebuild it from scratch and do it ourselves. Or was it like a challenge to get everybody on the same page about that? Satish (11:27) I would say, so there are like a couple of blog posts on the rebuild. Like one of the rebuild is the Kafka and another rebuild is the whole search engine. I will talk about the first rebuild, like the Kafka pipelining and how we build that. So it was really hard to get buying on that. It was, I would say it was like still in earlier days of Doordash. ⁓ where we were still heavily ⁓ focused on the product, but as a team of four or five engineers, we know what are the breaking points in the system, right? And where are we lacking ⁓ in terms of supporting the product ⁓ in an engineering fashion way? So that's where the problem statement came in. We didn't have a very good... sense of pipelines, we didn't have a very good infrastructure to iterate on a search index ⁓ in a faster way. So let's say if someone has an idea about like, how do I want to test out a change in the index? I want to use like a different kind of analyzers. So those things like require you re-indexing a lot of data and that used to take like months before. And that literally translates into, let's say, a product problem like, ⁓ for example, ⁓ let's say from the user's point of view, when users are querying the system, you know that the users are using a lot of ⁓ gen Z slangs in the query. And... But your system is not tuned towards that. So what do you do? So you definitely, you want to run an experiment to see, okay, how the changes are behaving. ⁓ But to get to a point where you can run that experiment, it's taking you like one, one and a half month just to prepare the data. And on top of that, then you run the experiments for a couple of weeks and then read out. And so it's a very long process for a startup to survive. So we need to cut this down. in hours, the iteration on the data. So ⁓ we know this is the problem from the engineering point of view. So ⁓ it wasn't, mean, you would need to frame the problem properly when you are presenting the problem to your leadership, right? Because if you just talk about like engineering terms like, this is taking one month, I want to cut it down to six months, six hours. It's hard for someone to justify, okay, so what if like from one month you are cutting it down to six months, what is six weeks, sorry, six hours, what is the benefit you are going to ⁓ give me? So you need to frame the problem ⁓ in a way that the people understand the importance of that problem and the importance of the solution. and our team was also like, I would say, kind of new in this whole process, like whole journey, everybody's like still learning. So it took us some while to, okay, we need to structure the problem differently. We need to understand the language of the people to whom you are presenting this problem to. yeah, so that's how we got the buy-in for that project by presenting it to the leadership and... working on that. like the blog post says, it was a huge success. That system lived for quite bit of time, ⁓ given the pace at which DoorDash progresses. ⁓ Yeah, and when I talk about the second part where we build the search engine, ⁓ that I would say came naturally. by looking at the data, by looking at the pain points. At that point, ⁓ we knew we have been operating the retrieval system for almost like four, fourish years, more than fourish years. We know the problems in the system. We know the problems in Elasticsearch. We know the problems ⁓ that comes with when... ⁓ when a critical system like a retrieval system is ⁓ in a hosted environment where you can't really control a lot of parameters which you want to control. yeah, ⁓ so that was the problem that we have, like basically scalability challenges. if ⁓ someone asks me like, hey Satish, go and make this search engines scalable 10x. Can you do that with that technology? And the answer is no, we need to think differently about this problem. And ⁓ one ⁓ important thing that we did this time was a couple of members in our team, they had a good knowledge of Lucene and they built a very quick POC ⁓ of a search engine. And we launched it on one of the products. And it was a huge success. So now we have all the, what I would say like theoretical data. And now we also have a practical data point where, okay, we proved that, this thing works. And now let's go deep into it and like, let's get funded. Let's get funding on this project and then move forward to this. So there are a couple of approaches that happened. And I think that is also a function of the state. at which your company is in, the state at which your team is in, ⁓ the kind of talent that you have in the team also matters quite a lot. Brittany Ellich (17:53) Yeah, that makes sense. That makes a lot of sense. think I've also heard that it's like a rule of thumb that like you have to re-architect for every order of magnitude increase typically of users. And it sounds like you went from very few users to a lot of users and like just naturally came to that point. Which makes sense. Satish (18:10) ⁓ Yeah, yeah, I would say so. Could be a function of the users and ⁓ like the end users and as well as the internal users ⁓ as the internal users also grows ⁓ in terms of like the use cases that they're solving, your system needs to evolve accordingly. Brittany Ellich (18:32) Bethany, what's your experience with rebuilds? Have you ever had to fight for a rebuild in your career or ⁓ fight against one maybe also? Bethany (18:40) ⁓ I'm not sure if I've had to necessarily fight for or against any of them. Either I was dropped in kind of in the middle of one or... ⁓ Or like, I don't think I've ever been on a team where it's been like, we desperately need to rebuild and then ⁓ we need to fight for it. But I will say I love the thought of ⁓ thinking of it as like rethinking the problem and with having realistic expectations of your goals of the system. ⁓ So for instance, I was working on a latency problem a couple months ago and ⁓ we were able to get some very quick wins, but for the latency expected, it's just quite frankly impossible unless we rethink the entire system because we're... ⁓ like we have the victims of all the network hops we need to make and all the, ⁓ like that were only located in one region and things like that. So it's, it's interesting looking from at the problems from that perspective of, of, okay, well, we have a system that has been designed to solve this problem currently where we didn't have latency expectations, but in a system where we do have latency expectations, what would we do differently? ⁓ Yeah, I think too, it's, you've touched on this a bit, but I think it's so important to consider ⁓ your organization structure, your culture ⁓ before you tackle a rebuild, ⁓ because I think Conway's law ends up mattering a ton, which to listeners, Conway's law is that your ⁓ system reflects your organizational hierarchy. ⁓ And I think so many Satish (20:34) Yes. Bethany (20:37) So many companies do reorgs without necessarily thinking about the... how that impacts the system. ⁓ And so you almost have to go into a reorg the same way that you're going into a rearchitecture because it might end up leading to that because your teams will bump heads if they're split off and then trying to work in the same code base or same architecture and things like that. I think it's been interesting thinking, looking at reorgs through that lens of, okay, well, what does this mean for the code or the technology? Satish (21:10) Yeah, we are definitely ⁓ just like corollary to like building new technologies, right? Or like moving from point A to point B. ⁓ Like over this period, like I felt like ⁓ that building new technology is very easy. ⁓ The migrations are very difficult. And this is something I would say like a grunt work, which sometimes good unsung. ⁓ when people work on it and might sometimes like folks might think like, this is like something, no, this is, want to build new technology. I don't want to do migrations. ⁓ But I think like 70 % of the work ⁓ in building new technology is going into the migration. How you are making sure that you are keeping your promises. to your customers, or whoever it is, like end users or internal customers, and making sure that your system is better than the previous world that it was, and better in terms of latency, availability, all the system aspects, but also operability, how you are enabling your customers to get the most value out of the new system, which your old system didn't provide. And unless you add that... ⁓ value addition. It's really difficult for your customers to ⁓ go to the new system, motivate them to the new system using the new system. yeah, I think that is something we like whenever someone is building something new, this is something that should be on the radar and there has to be like a very specific timeline on deprecation on the movement. Otherwise I have seen like ⁓ the ⁓ certain code bases they need to maintain like okay I need to maintain this one for the old customers or like the old code pass and some new code pass the new system ⁓ that really prevents you the system being scalable Brittany Ellich (23:25) Yeah. Bethany (23:25) I really love that considering the customer at the end of this whole system rearchitecture or system redesign or rebuild or whatever you want to call it. ⁓ Because I think sometimes rebuilds come from maybe folks wanting a promotion or to get their name out there or from ulterior motives, not necessarily a... ⁓ nefarious or anything, but just people wanted to try a new technology, like my first team wanted to try with microservices, for instance. And so I think it's, you can tell when a, when a rebuild is in good faith based on what that migration plan is and that there is a plan to to roll it out and not just a plan to build the tech. Like separating that building from the rollout is absolutely the most critical part of a rebuild. Brittany Ellich (24:24) Yeah, deprecating, decommissioning too. Like it's not just you turn it off and then you don't have to worry about this old service anymore. Like it's a long tail of things that you don't think about when you're like, let's just rebuild it. Yeah, I agree. ⁓ Was there any testing or anything like any data that you tried to gather like as like a proof of concept or anything like that when you were doing this in-house rebuild to prove that it would do this before you actually undertook it or? ⁓ Satish (24:30) Yeah Brittany Ellich (24:53) Like how did you end up making that decision? Satish (24:56) Yeah, definitely data ⁓ by launching the experiments. we had the autocomplete use case, which is on the Doordash application. So when you type in something, you get type ahead suggestions. So that particular use case ⁓ that was powered by this ⁓ newly built search engine, a POC search engine, you would call it. ⁓ And the data is like... ⁓ nothing fancy, just the standard data, right? What is your latency? ⁓ Like the type ahead is very latency sensitive. ⁓ You can't have like ⁓ just a spinner there for the people. So it has to be very latency sensitive. ⁓ It has to be ⁓ context driven. ⁓ For example, if a user is searching inside a convenience store. The context is different here. So if a user is typing IBU in that context, then user might be looking for ibuprofen. So you have to ⁓ complete your, you have to give your autocomplete suggestions according to the context while IBU in the global search or like in the whole world search might be something different. So. that the context is very important. Also, ⁓ there are certain things like, ⁓ like I said, ⁓ Gen Z slangs or ⁓ some things like ⁓ if you want to look for ⁓ chicken tikka masala. So nobody types in chicken tikka masala. Everybody types in CTM. So your system needs to understand, okay, CTM is chicken tikka masala. So there are like... ⁓ a lot of nuances like this, you need to go through the data and understand those nuances and measure your new system against these nuances as well, against the tail. Definitely you will measure it against the head, but the tail is also important on ⁓ what for sessions that you are serving, ⁓ the click through rate, how many people are clicking in and clicking on your suggestions and getting the food or the items ordered. So those kind of things, the availability aspect. ⁓ Another aspect is the refreshing the data. How fast is your system to refresh its state? ⁓ How fast it is to crunch a new set of data and refresh the search engine index ⁓ for serving? How tunable it is in terms of operator template, right? What are the plugin points that you are going to provide? to your internal teams. ⁓ So these are some aspects on which we evaluated the new system versus the old system. Brittany Ellich (28:02) Yeah, that makes sense. And I understand now you are at LinkedIn, is that correct? And that's fairly recent? Has it been like a month or two or okay? Satish (28:07) Yes. Yes, yes, it's real. Yeah, like last month. Brittany Ellich (28:15) Okay, cool. Are you working on search there or something different? Satish (28:18) ⁓ No, I am not working on search at LinkedIn. Brittany Ellich (28:24) Okay, nice. Yeah, you probably are still getting into it. Have you learned, is there going to be anything that you've like as you're getting in, you've previously went from this company that, you know, was small and scaled up. Now, LinkedIn is probably pretty well scaled, I imagine at this point. ⁓ So I'm curious, like, has that changed the way that you approach things or has, you know, has there, how have you gotten up to speed on what's happening in your new area? Anything that you've learned? Satish (28:50) ⁓ Yeah, so for your last questions how I'm getting up to the speed ⁓ I think ⁓ by using a lot of AI tools So ⁓ definitely like a lot of reading but if you are curious enough to know about anything I think it's just like a question away. what, why, and how, and you would just know about any of the systems that is being worked. ⁓ Going from like a startup or like a mid-tier-ish like the DoorDash to LinkedIn. ⁓ So my thought process was that wherever you go in terms of software engineering, the problems are going to be the similar-ish on a very high level. So it just like the tools are different. It's just the way like the people do certain things are different or cut to culturally will find some things are a little different here and there. ⁓ And like some tools are like mature or ⁓ a problem that ⁓ that is out there in the world. ⁓ Big companies might have already figured out solution for that. They have like in-house solutions for it. So those things are there. But yeah, I would say like it's good learning opportunity as well. Like if you look at the holistic picture of a company like LinkedIn, you would see, okay, there are like certain decisions ⁓ that were made in the past, which got LinkedIn to a point where it is currently. Look at those decisions, look at how their tech stack evolved over the period of time, ⁓ in what directions that different products are moving. So that is also very good learning experience or thought experience ⁓ for me. Yeah, so I would say, ⁓ yeah, I'm still like in kind of in the onboarding phase of it, learning through. ⁓ And one thing that I learned at DoorDash is ⁓ when I joined DoorDash, I said like, there was this big monolith and it was... It wasn't a pleasant experience from engineering point of view to work on monolith. And I used to think like, so my mindset at that time was like, hey, who builds monolith? Who does this kind of things? Like who, this is like a very poor engineering, who writes code like in this way. And I was like so critical of that system at that point. And as... ⁓ As I lived through the journey and I looked back, I would say like, okay, ⁓ you shouldn't be, I mean, you don't have to be critical of the legacy systems because those were the systems which ⁓ propelled your company, your product till that point. So they were supposed, they were doing what they were supposed to do. And it's a... it's an opportunity for you to take that and mold it in a different way and write the next story for ⁓ your team, for your company. So I think that is something I ⁓ would take from my experience at DoorDash and at LinkedIn. ⁓ Definitely there are certain things which ⁓ you can question about saying, hey, ⁓ why certain things are built in certain way? ⁓ But yeah, I would look at it from the opportunity point of view, like, okay, we can ⁓ build things better from this point onwards. We can do 10x things, 100x things. ⁓ Yeah, so I would say like that is like a huge takeaway for me from my whole journey at DoorDash Brittany Ellich (32:55) That makes sense. Sounds like you started at DoorDash pretty small and then got to see it go all through the various iterations, whereas you're coming into LinkedIn, ⁓ you know, when things are much more established and have a lot of history to look back on. Bethany, do you have any experience, like anything that you've done to like help get up to speed in a space that's already existing or like any signals that you see in a system where you're like, this is the part where nobody likes, this is where the skeletons hide or anything like that. Bethany (33:22) ⁓ Yeah, I mean, I think that's typical of any engineering team. You can tell if the team is just honest about the code base and say, yeah, this is gross, or anything like that. ⁓ I think it's, I take the Marie Kondo approach like you're saying, Satish of ⁓ like, you thank the code for what it's done and how it served you and move on. And I think it, yes, you're saying thank you. then, but let's do it differently. ⁓ And so I think that's always a healthy approach to take with a code base. But ⁓ I think code reviews are a really good signal for what areas are healthy versus not because people will be either willing to review your code for a specific area if the team is very familiar about it and comfortable with it and less willing to review if it's an area that folks haven't touched for a minute or don't feel comfortable with it. ⁓ So I think that culture is ⁓ an interesting one to take into account when you're new to a team and trying to understand what areas are ⁓ more built out versus less understandable. Brittany Ellich (34:46) Yeah, that makes sense. feel like one of the threads throughout your story too, Satish, at DoorDash is like you sort of had this experience of like build versus buy and initially you bought, you you were using the Elasticsearch as is and then decided to build something from scratch that was more custom to ⁓ your application. I think that's something that a lot of people throughout the software industry sort of struggle with. ⁓ I'm curious, do you have any thoughts on that? Both. Satish (35:10) Yeah. Brittany Ellich (35:15) with your experience on it. And also now in the world of AI, I'll ask Bethany this too, because I feel like this is a thing I hear about a lot where everybody's like, now you can just build, just build everything. Why buy it? So any thoughts there? Satish (35:20) You ⁓ Yeah, so I would say first ⁓ just buy ⁓ because ⁓ if you look at your goal, like if you have an idea, you want to surface it to your customers. ⁓ And what is the fastest way? to surface it to your customers and get that feedback, right? ⁓ Definitely you don't wanna spend time in building the building blocks, which are already available in the market. You want to just move ahead, get your idea out the door and get the feedback. So in that sense, I would definitely recommend buy ⁓ versus build. But as your system matures, ⁓ still buys a good strategy. ⁓ The build, I would say like it's not only the build decision shouldn't be taken only on one dimension like ⁓ money or like the pricing. ⁓ You need to think through, okay, this is costing me X money, ⁓ but what else it is costing me? Is it costing me velocity? then whatever money it is costing, I would multiply by that 10 if it is costing you the velocity. Then in terms of operability ⁓ of that system, ⁓ what is, how much effort that the Inch team is putting in into operating that system. Not only Inch team, maybe like the product team, whoever is like ⁓ making efforts in operating into that system. So that also put like a... I would put like a price tag on that too, ⁓ if that's on that system. And also I would put a price tag on, okay, so you bought a system or like you rented a system via cloud provider. What is the level of support that you are getting? How efficient they are in giving you the support? Are they more knowledgeable about that system than you? ⁓ I think that if the answer is no, then yes, either you need to change the provider or you need to build your own system. yeah, so I think it's not, would say a binary question build versus buy. So it's more of a thought process, but yeah, definitely go with buy first and get that idea out the door. Bethany (38:20) Yeah, I completely agree. think it's, I mean, we've been hearing a lot about software as a service or SaaS companies being dead after AI because suddenly you can vibe code anything. But I would argue that with these companies or these products, you're not paying for the code. Like we talked about earlier, the code's easy to write. It's the scaling, the rollout, the expertise that comes with it. I mean, so many companies have their products or their code open sourced, but still have a paid off. offering to host it for you, because that's the hard part, and also understanding the code. So I don't know. I still think that SaaS companies and products are important in this day and age of 2026. Who knows if that changes, but I think it's still a very. a very relevant topic to decide when you're exploring options for scaling your company, whether you build or buy, depending how much you want to invest in expertise in these things or how much time you want your employees to spend on things that aren't really related to your direct offering. I think that's still relevant today. Satish (39:33) Yeah, definitely. Brittany Ellich (39:35) Yeah, I agree. I'm still bullish on software being important as well. ⁓ But it's fun to read all of the things like, ⁓ like, does software need to exist anymore? Because you can just like the hard part isn't the building, like you said, it's the maintenance that comes with it and making sure like everything continues to work over time as it scales. So. Satish (39:39) you Brittany Ellich (39:56) One of the other things you said that I really liked is how much expertise they have. Is this one of many offerings that they have that is something that they're actually an expert in or is it something that's just something that they have available and you have learned it deeper and are contributing back to the community more than the original company, then it's a good sign that you can probably get away with doing it yourself. So I like that. Cool, well we are coming up on time. And so at the end of every episode, we do a fun segment. ⁓ And this week, ⁓ I thought that, you know, that we're talking a lot about technical decisions, some things that change over time, depending on what you're thinking. So I thought that we could do a little round robin tech confessional of a decision that you have made that maybe, you know, didn't work out, something that you're, you know, not proud of looking back on it. or that you are proud of and if you would rather confess that you did something awesome, you can also do that, I suppose. ⁓ Yeah, so I we could do that. ⁓ Something that we thought was right at the time but didn't age well, which may or may not be all software, I guess. ⁓ So I'll start and then I'll let you both go ⁓ with your option. ⁓ And I admittedly did not think very deeply about this before ⁓ writing it down. Satish (41:09) Hehehe Brittany Ellich (41:21) But I think, let's see here. One of the decisions I've made in the past, I think was like during the days, I feel like we're out of these days now where we're not jumping to a new JavaScript framework every 30 seconds. Like we were there for a bit when I first started ⁓ working in ⁓ software. But one of the ones that I had decided was there was one that we were using, I think it was called like handlebars ⁓ for something that we decided to put that in. our application and turns out it's just not the one that anybody went with or decided to continue using. And then we had to continue maintaining this for a long time. And I think not waiting a little bit more for like the technology to mature before building a funded thing on top of it was probably one of the decisions I was involved in that, you know, it was a lesson learned for future decisions. Luckily, the front end ecosystem is a little bit more. ⁓ mature now in general, so it's easier to make those choices. that was mine. Satish, do you want to go next? Satish (42:33) yeah, sure. ⁓ yeah. So I thought about one thing, maybe the scalability, ⁓ point. So, if you, ⁓ if you go to DoorDash, you will see like a grouping of stores, right? we call them carousels and, ⁓ one of the tech decisions, ⁓ when, when we were doing this migration from Monolith, ⁓ to our new system was that like for, for each of the carousels you, you would make. a separate call to your microservice to build that carousel. And definitely that didn't scale well because that one thing is that put cap on how many of these product constructs that you can have on the homepage. You can't scale them linearly. And even though adding some tweaks in the backend, it still doesn't work that great. So ⁓ yeah, so that didn't scale well. ⁓ But the next story is, ⁓ so we went back to a model, okay, wait, do this only in a single call. Okay, so retrieve everything and then build out this constructs. So that played out for a few years, then something new came up. And okay, now we also have... Now at this point, we also need to make multiple calls to the backend. So ⁓ now you kind of settled on a hybrid approach to do it. But ⁓ the original decision was, would say, it didn't consider ⁓ at least two years ahead of its time how the system would evolve. But as the system matured, ⁓ now you can go crazy. mean, your system is linearly scalable. Your backend is linearly scalable. The search engine is scalable. You can just go crazy on number of calls. It doesn't matter. ⁓ But yeah, it was a journey to get to a right state ⁓ from where we started. Brittany Ellich (44:52) Yeah, I get that. Bethany, do you have a confession that you would like to bring to us? Bethany (44:57) ⁓ yes. ⁓ it was probably a very quick turnaround with a technical decision to realizing it was a mistake, thankfully. ⁓ but, ⁓ I was working on a greenfield service as like the last product that I was working on for my last company. I was basically like a content tagging platform. ⁓ and, ⁓ when we were evaluating data stores, I, ⁓ I did a ton of research and I felt very convicted that DynamoDB was the best thing to go with. I went head deep into the NoSQL design patterns and I was so on board. was like, yes, this is what we're going to be using. Implementing it, it worked great. But then there came a time where after I was talking with the product manager, I'm like, hey, the data contract isn't going to change much, is it? And she was like, ⁓ no, it'll probably stay the same. Like a month in, it changed drastically. Like the ways we needed to access it changed drastically. was like, I should have called this. And on top of that, my other team members, ⁓ didn't necessarily have the time or interest to look into how NoSQL data patterns worked. it turned out I was the only one who was able to really make changes in that space. And I was like, you know what, we're switching. We're going MySQL. Ripped it out in like a week and translated everything, luckily, before we had a ton of data onto it. ⁓ luckily, it wasn't too drastic. But ⁓ yeah. Satish (46:25) You Brittany Ellich (46:25) No. Bethany (46:38) Turns out engineering culture is very needed to consider in whatever you choose for your data layer. It's not smart to choose something random that nobody has experience in. ⁓ Satish (46:48) Yeah, definitely, Yeah. Brittany Ellich (46:50) Shocking, yeah. Bethany (46:51) I know, I was fairly young at the time so it was one of those pivotal moments, it was like, alright, I'm never designing anything that I can't back out of immediately. Brittany Ellich (46:55) Ugh. Satish (47:00) Okay Brittany Ellich (47:01) smart, so the one way versus two way door decision. Yes, yes, I love that. ⁓ Well, so teach, thank you so much for joining us. This was an awesome conversation. If folks want to find you somewhere on the internet, where do you suggest that they go? Bethany (47:05) Absolutely. Satish (47:06) Yeah. ⁓ I'm on LinkedIn. Yeah, I think my name is Unique Satish Saley. So you can definitely reach me out on the LinkedIn. Yeah. Thank you. Brittany Ellich (47:29) We'll include that link in the show notes as well. Satish (47:33) Thank you. Thank you for having me. Brittany Ellich (47:35) Yeah, this is great. Awesome. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, 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. --- ## Episode 52: Overcommitted After One Year: Insights on Software Projects, Growth, and What's Next - URL: https://overcommitted.dev/overcommitted-after-one-year-insights-on-software-projects-growth-and-whats-next - Published: 2026-03-24 - Audio: https://anchor.fm/s/102586d64/podcast/play/117087998/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-2-23%2F420605718-44100-2-c779d0015d30f.mp3 ### Show notes Summary In this special one-year anniversary episode of Overcommitted, Brittany, Erika, and Bethany reflect on their journey from a small accountability group to a thriving weekly podcast and community of over 160 software engineers. They discuss their experiences within the software development lifecycle, the challenges of maintaining programmer productivity, and the evolution of their engineering culture. Listeners will hear candid stories about mastering interview skills, handling the complexities of production admin, and navigating promotional efforts. The episode also highlights the podcast's unexpected role as a valuable networking tool for remote workers in tech careers. Looking ahead, the hosts share exciting plans including new panel-format episodes, community events, and automation initiatives. Closing with affectionate roasts in their first-ever Overcommitted Superlatives, this episode offers both insight and entertainment for anyone passionate about software projects and sustainable work-life balance in tech. Links * Episode 1 - Imposter Syndrome: https://overcommitted.dev/imposter-syndrome-in-software-engineering/ [https://overcommitted.dev/imposter-syndrome-in-software-engineering/] * Overcommitted Discord Server: https://discord.gg/d9gZyYuqKd [https://discord.gg/d9gZyYuqKd] * Computer systems: A programmer's perspective: https://www.amazon.com/Computer-Systems-Programmers-Perspective-3rd/dp/013409266X [https://www.amazon.com/Computer-Systems-Programmers-Perspective-3rd/dp/013409266X] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:01) Welcome to Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Bethany, and I'm joined by... Brittany Ellich (00:10) Hey, I'm Brittany. Erika (00:12) I'm Erika Bethany (00:14) We 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've learned. 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 just us, really. ⁓ We thought we would take this week to celebrate the one year anniversary of Overcommitted. This is our 52nd episode. And we are just going to chat about what it's been like, our experiences, what we've learned, and ⁓ what we're doing moving forward. Almost a year ago we hit the record button on episode one, which was about imposter syndrome. ⁓ And now we're still here. Still Overcommitted. and obsessed with getting better at what we do. ⁓ let's turn the question that we ask everybody on us, ⁓ what is something that we're obsessed with learning or building right now? Erika, you want to kick us off? Erika (01:25) Sure. Let's see. I have been working on improving our playbooks on our team. We're changing our first responder schedule and revisiting a lot of our playbooks since we're adding new people to the rotation. I've been thinking a lot about what makes a playbook useful and the level of detail ⁓ that's helpful when you're approaching a problem. And ⁓ I have been using LLM assistants and a lot of the things that LLMs do are actually really not helpful in a playbook setting where I'm realizing that a bad or A bad playbook is worse than no playbook at all. Like if you have like inaccurate or outdated information that's like leading you down a rabbit hole, that's actually worse than not saying anything. you know, LLMs like to add a lot of content and you know, look up things and try to be as helpful as possible. And also like tell you a definitive answer when playbooks are like. this is the right way to think about this system and like here are some good things to think about. So anyway, it's been kind of a interesting problem to crack of like how to iterate. And I think the thing that I've found most helpful ⁓ is like giving... agent reviewers, different personas. So I've been telling it to adopt a persona of a junior engineer or a senior engineer or an engineering manager and review these playbooks. ⁓ And it's given some interesting feedback of like, this term isn't clear or, you know, how are you going to keep these updated? So that kind of stuff that I wouldn't think about. Yeah, so that's kind of what I've been focused on the past few days. What about you Bethany? Bethany (03:44) ⁓ Yeah, so I love that first off. think playbooks are so, important, but so often an afterthought. And it really just makes the engineering culture better when you have playbooks that you can lean on. ⁓ I feel like since we all started in action, we were very lucky in a way to have a good playbook culture there where it was... ⁓ very much the most important thing to update playbooks. So ⁓ I love that you're taking that on for your team and making that a better experience. ⁓ For me, I've been largely trying to do more vibe coding for lack of better term, like in my free time. ⁓ I've been, because we've talked to several guests, I feel, lately that have indicated, ⁓ I can finally write JavaScript without actually writing JavaScript, and that is me. I have taken so many courses to try to learn JavaScript and CSS, and my brain just struggles to learn those things, slash having time to really dive in. So it's been really cool to actually go after ideas that I've had for a while ⁓ and mock them up at the very least, but create working prototypes for things that might not have like billions of users or even thousands of users. ⁓ It's been really freeing in a way to just make progress on these side projects I've had thoughts about for a while. And then in a similar vein for work, just trying to learn more about agentic engineering and the better processes with that, because it's not going to look the same as vibe coding for projects. It's going to be more methodical, handheld, lots more research and stuff. And so it's always tempting to just throw it to the agent, but I'm trying to really strike the balance of it speeding me up, but also me keeping the context. And so I've been reading a lot of, a lot of things that have explained the processes other folks use. So for instance, like the person who created Cloud Code posted his process and it's a lot about do extensive research first on this area and then write a document, then come up with a comprehensive plan and write a document and then implement that plan. And so ⁓ it's been interesting trying out different strategies there. Brittany, what about you? Brittany Ellich (06:23) Yeah, so I will be headed out soon to Atmosphere Conf and I have been sort of involved in the app proto space in the last couple months. And I originally started making this like Goodreads at ⁓ proto app and there's actually several of those that already exist and a lot of them are much better than the one that I made. But it led me to I really wanted to create one that we could use for over committed for our book club community to like. track book club things like our next reading and things like that. And I kind of led me down this rabbit hole of like, what groups look like in, ⁓ at Proto and like, how do you create a group entity and like give people different permissions to write to this group and like, how do you create roles and you know. make sure there's things that I'm more familiar with from working in the enterprise space at GitHub, like audit logging and things like that when there are changes. ⁓ So I've sort of built this entire side app that is just managing that now. And I'll actually be presenting it at Mascurconf and talking about just like what group management looks like for the app proto space. So that's sort of the rabbit hole I've been in recently trying to prepare for that. Bethany (07:37) That's so cool. ⁓ I think at Proto is such a cool technology. ⁓ Since talking with Nick earlier on, it's just really cool to see people so passionate about making it a success and building on top of it. And I love that. Speaking of earlier guests, I wanted to start off with talking about maybe what our original vision for the podcast was when we started. ⁓ Has it evolved since then for you all or has it been kind of more of the same and we've kept to that? ⁓ Brittany, I'll let you start. Brittany Ellich (08:23) ⁓ yeah, I think that we were originally meeting in our accountability buddy group just to like talk about our own goals and commitments. And I feel like that's not something that we actually talk about much at all in over committed, ⁓ maybe a little bit, but ⁓ it has sort of evolved into like a way to check in with each other more. And I feel like we're still doing that and we're still keeping in touch. And it is also involved into this way that we are sort of like networking remotely. And I feel like that has actually been, I don't know if it's something that we planned on purpose. We were just like, hey, like what if we interview somebody on this? And now we've got tons of people that we're interviewing every single week. And that's actually been really cool because like working remotely, it's really hard to get to know other folks. And it turns out having a podcast is a really great way to do that. So. I don't think that's something we initially set out to do, but I feel like it's sort of what it has become and I've really enjoyed that. What about you, Erika? Erika (09:22) Yeah, yeah, I guess we don't talk about our goals directly that much, but I have learned so much through talking to other people that ⁓ my goals have changed and like improved as a result of doing this. Hearing so many different perspectives that people have and how people think about career development or different technologies. ⁓ has really like expanded my understanding. And yeah, I was always appreciative of our group and whatever we talked about. I always appreciated having a community, even if it was the three of us or four or small group settings. I think over the past year since we've kind of opened it up, it's been really encouraging how many people also seem to appreciate having that and, ⁓ you know, like opening up book club and meeting other people who are, you know, working on different things and maybe listening to the podcast and like engaging on Discord and it's... Yeah, it's very cool, ⁓ like feeling like that has continued to like support each other and ⁓ that we've been able to kind of expand it to support others, ⁓ but still maintain the positivity and sort of like learning first approach. Bethany (11:14) Yeah, I feel like, like in our in our group, we all had different ⁓ specialties and trusts, and it was really cool learning from each other on those. And I feel like having guests is just kind of an extension on that. ⁓ But it really has changed from just us discussing our goals to really discussing what success looks like in the industry. And it can look so different for so many people. ⁓ And I think one One vision I had for this when we were starting was to be almost like a helping hand for people who might feel lonely in the tech world. ⁓ And that can be early in career folks or even folks later on who might just not be knowing what the next step is or feel isolated in their position. I think ⁓ we've really done ⁓ or the guests that we've had have really fulfilled that role of having these experiences that are so interesting and so cool and sometimes it's so diverse too. And I think it's just been a really cool experience to see what that looks like for different people and that there's really no failure in the industry. It is so long as you're continuing to like better yourself and follow your interests and passions. You're likely to end up in a really cool space. That's, that's good for you. Erika (12:36) Yeah, I've I've definitely been intimidated by some of the people we've brought on and I've had that gremlin in my head saying you have no idea what you're talking about. You're going to get on this conversation and they're going to look at you like you're completely dumb and like you're speaking nonsense. And that has never happened once. Every time we've had somebody and I've had that thought in my head, we get on and it's a lovely conversation. I learned something new. I Yeah, ⁓ so I think that's also been kind of like encouraging from a meta perspective. Like the more times that happens, the more confidence I build in talking to people. And ⁓ yeah, so that's also been cool. Bethany (13:25) I agree completely. think everyone has been so, so kind and generous with their time. ⁓ I think we've had some really cool people. Honestly, I cannot think of a single guest that hasn't been super cool and I would not be immediate friends with. It's just been, it's been, I feel like we've been so lucky, honestly. ⁓ And it's really cool that we've... ⁓ We've been able to find this community of folks that are curious and interested in learning. Like you mentioned, Erika, and the Discord, ⁓ and folks who are just so cool. I feel like I keep saying that, but I am always so blown away by what people are doing or learning or building. ⁓ And it's so inspiring. Brittany Ellich (14:16) Yeah, I feel like this has also been happening at the same time as the industry is changing a lot very rapidly. So I don't think we're like an AI podcast, but a lot of our topics end up being about AI because that's like what people. And it's been really interesting, I think, to have this focus on like community and like people alongside learning with AI. Cause I think the more I learn like how to use AI and stuff, the more I'm like, wow, like that people element is actually more important than it ever has been before. Because like it's pulling, you know, it's pulling people away from talking with each other and that is not great. you know, focusing on building these more like person focused relationships has been really nice. Bethany (15:01) That's such a great way to put it. The people aspect is always going to be the most important ⁓ or that human aspect, especially if you're building software for humans ⁓ and just learning from other people and stuff too. ⁓ Is there anything that was harder than you all imagined ⁓ when we got started about the podcast journey? I can go first if y'all need to noodle on this. ⁓ So I think for me, it's just how to interview. Like I've listened to a lot of tech podcasts and I've listened to, I mean, a lot of podcasts full stop, but there's really nothing out there that just teaches you how to be a good interviewer. ⁓ It's something that it feels like you have to build organically, but ⁓ it's been... Brittany Ellich (15:35) Y'all go for it. Let's see it. Bethany (16:02) I think that's been the trickiest part, being like, okay, we need to make sure that we highlight our guests and give them a real nice platform to talk about what they're into and showcase their personality and skills and such. But then also while making sure that our personalities shine through and we're also providing those glimmers as well. And I think it's been an interesting balance of trying to figure that out. ⁓ But yeah, if anyone knows the course or something that teaches you how to interview people or has some feedback, please let me know. Brittany Ellich (16:45) Yeah, I would love that. I've been thinking about that recently too. It's like, man, am I a good interviewer? Maybe do I need to like learn how to interview people or get like some assistance on that? I think one thing that I found that is more difficult than I expected is ⁓ asking people to be guests. It's like this weird and at the same time it's not that hard. We have a lot of people that are like lined up and we got a lot of folks that are guests now but I think that was a thing that was really hard for me like initially. Like I remember when I was reaching out to you both when I was asking our old CEO Thomas to be on and like this the imposter syndrome I had while doing that was awful. I was like my gosh can I can I actually like Can I reach out and DM somebody about this? Is this okay? And I think it's been really interesting because I think people are also afraid to ask to be guests. I've noticed like there are some people that come to us and are like, man, I really love to be on the podcast. Is that okay for me to ask or something like so there's like a weird thing on both sides. think like if you want to be on somebody's podcast, you should just ask because they are probably more than willing to let you be on it. ⁓ But also ⁓ if you're, know, interviewing other people also just ask. Worst thing they say is no. I don't think anybody's gonna be like, ha, no, definitely not. That podcast is terrible that I've probably never heard of or listened to or anything. Like, it's a very easy way for folks to use their time. In worst case, like you send them the scheduling link and they don't schedule and that's fine. Like, it's fine. ⁓ Yeah, so that's been kind of interesting to learn. Erika (18:23) Yeah, I don't know if anything comes to mind aside from like the production of the podcast, which like admittedly, Brittany has done more of than either of us. So like, I really have no room to say anything. ⁓ But ⁓ yeah, I think like all the admit like I I feel like such a slacker every time I like check the email or like, you know, check on things like I just kind of like forget about it. And then I'm like, Oh, wait, there's like all this admin stuff that Britney is doing behind the scenes that I'm like, ah, I'm so sorry. So, yeah, I think like when we started this, were kind of like not expecting anyone to listen to it. And I think we've decided to like put in some effort to like bring it to people. And again, like most of that has been Britney. Yeah, but even that level of like, we're not trying to monetize it, we're not trying to go viral or anything, but pure like maintenance state has, I think, yeah, like it from an outsider's perspective, it seems like more than more than a trivial amount of work. Brittany Ellich (19:43) There's a lot of little steps, but for what it's worth Riverside also does a lot of the heavy lifting of like editing and there's a lot of times there's I've gone like a month or two without posting online or something, especially early on. I was like, we don't need to post this every week, right? Like actually, I probably should. But at least try to like make the effort when we have a guest on at the very least. Erika (19:55) Yeah. ⁓ Yeah. Bethany (20:07) Absolutely. The admin stuff has been a lot and a lot on Brittany's shoulders. ⁓ So definitely, definitely appreciate her for for really paving, like helping us get this to people. So if you're listening to it, thank Brittany. Awesome. Yeah, it's I think there's been definitely a lot of ⁓ Erika (20:23) Yeah. Yeah. Bethany (20:36) unexpected things, but it's been really cool that we just all were like, yeah, let's do this. And we went for it and we committed to it, maybe over committed to it. But ⁓ yeah, curious, like looking back, how has this last year been for you all? How have you like grown at both maybe in careers and like through the podcast. Have you seen anything that's directly, you can tie to insights there? Brittany Ellich (21:15) I have been going through the promo cycle this last year. ⁓ And it's been interesting. I don't think that having a podcast is like a way to get promoted. I think in some cases, it can almost even be like a detractor if people are like, well, you're spending all this time on that instead of on, you know, other things. But I do think that it probably sets us up a little bit better for future opportunities, potentially. I don't know, none of us have been really looking for jobs, also, likely. So we'll see if that's actually the case. But I feel like it's been useful for, you know, like I said, you know, networking with folks remotely. We have a whole big Discord group now of like 160 people that we're chatting with regularly and, you know. getting to talk about like, man, this thing sucks in tech or like, is, you know, this is things that are going well. And I feel like that's been really good for accountability and just me keeping up with like the books that I read. Like I joined y'all's book club mostly because I know it would shame me into reading books and same with like doing the podcast. I'm like, this will shame me into continuing to do, you know, podcast editing or posting or whatever. And it's been, that part's been successful. I like, I, I. optimized for public shaming, I guess, in my learning. For better or worse. Bethany (22:38) I think that's so true. I think there's an amount of uncomfiness that's always good to aim for. And so I think similarly, I am a very anxious person, especially social anxiety I just really, really struggle with. I just have a mental block whenever I'm confronted with new people or talking with them. If they approach me, I'm fine, but approaching them I always struggle with and I feel like... this podcast has kind of forced me to talk to new people on regular basis and ⁓ not get wrapped up in the anxiety, but really try to have a clear head so you can like follow along what they're saying, ask follow up questions and ⁓ get better at just talking with people, especially technically. feel like listening to podcasts when I was a younger engineer was such a, such a help for my imposter syndrome because It was refreshing when people would say, I don't know the answer or, I don't know the answer to this or ask maybe questions that people would find simple. ⁓ And so it's been a good opportunity on the other side, like making the podcast side to practice those conversation skills and build those in network. Like you were saying earlier, Brittany, ⁓ and I feel like I have had more success with talking with people, like at the Pragmatic Summit, I actually went up to people and talked to them more and I felt so proud of myself. Just because that's not something I would have typically done without at least having a buddy with me or anything like that. So yeah, I think that's been a good growth moment for me personally. Alright, well, let's look ahead. ⁓ Do you all have any thoughts of what comes next here? Are we gonna keep on going with the same formats or anything you all are thinking that's coming up? Erika (24:48) The only thing I'm thinking about right now is automating some of our productionizing. Yeah. Yeah. Brittany Ellich (24:54) Yes! Make the robots do it. Yeah, there's a lot of little tiny pieces, but it would be nice to connect them all with things other than our own mouse. Nice. Erika (25:02) Yeah, but that's not like obvious to anyone except for us. Brittany Ellich (25:07) True. Yeah, I don't know if there's anything specifically that I want to change. I do want to do like a group episode like us. I feel like we've started doing that the last couple months where we do one with just us and check in about whatever topic. I think that those are fun. more people, more guests, more folks to talk to and thinking just about like how much the industry has changed from when we started this to now. can't even imagine what it's going to look like a year. Erika (25:40) I guess we've talked about doing like learning sessions in the discord too. Like we did, we used to do some like short form book clubs and stuff. And like, I don't know if people are like working on projects or like wanna like practice a conference talk or something like that. Like I think it'd be cool to open that up and have more opportunities for sort of like those group connections in there. Cause again, that's like stuff that we've done for each other, especially like First time speaking in a conference or something and you want to like do a dry run and get feedback. I'd love for the community to be a safe place for that kind of stuff. Bethany (26:21) totally agree. think those are great ideas. ⁓ I agree with either automating or helping out more with admin work. Being a more active participant there, think, I mean, just sometimes all the extracurriculars gets overwhelming. ⁓ it's hard to prioritize something unless you actually put it down and really commit to it. So I think... ⁓ making sure to do that and be better about that and more present will be good. We have scheduling for our episodes, so we could do something similar with editing and stuff for myself or try calendar blocking. ⁓ I love the idea of community building and making that ⁓ a really good spot because that's what we're after, not really monetizing or ⁓ anything like that, but just making it a cool place for cool engineers to... talk and grow and whatnot. So I think those are great. I think I don't have much to add to those. ⁓ I am excited about the new format we're introducing. ⁓ We are trying to go to more of a panel approach rather than we take turns asking questions. ⁓ And I think... experimenting with that is going to be interesting to make it a good ⁓ fit for us, a good fit for our guests. ⁓ Just seeing what works best will be exciting. So it's been great to get feedback from people and see what we can do better to make ourselves a good podcast for the listeners. Alright, well, are you all ready for our fun segment? I gave Eric and Brittany homework for this one. ⁓ Okay, so we are doing our first annual Overcomitted Superlatives! Woo! So, ⁓ I figured we would go around... Brittany Ellich (28:17) already. Bethany (28:36) give and give the other two folks some superlatives for maybe some traits or whatnot or impact they've had in the podcast. Do you all like me to go first or do you all want to go first? Erika (28:52) I can go. ⁓ mine are like the first ones that came to mind, which I was like, Bethany (28:53) Okay, cool. Erika (28:59) I probably could have like gone deeper and made these more clever, but ⁓ these are the first things that came to mind for me. So Bethany, I'm dubbing you the most likely to recommend a tool that I can't live without, some kind of CLI or library that makes my life so much better. yeah, so that's that's your superlative. And then Brittany, you are the most likely to Make me rethink my entire like second brain inner loop workflow like personal workflow Yeah, you're like always Changing and then I'm like, oh that's such a good idea. I like I need to do that and then my entire like workflow changes So those are those are mine for you, too Bethany (29:52) it's so true. I love those. Erika (29:55) Ha! Brittany Ellich (29:55) Yeah, that's great. I'm proud of that superlative because everybody should be always making them better. Erika (29:58) Yeah. Bethany, do want to go next? Bethany (30:07) Sure. Okay, for Erika, I had to these down so I remembered them. For Erika, I'm giving you Most Likely to Ask, But Why, though? Because you're just so curious and inquisitive and you really want to dive in to what people are saying and ⁓ really understand someone and I think that's really cool. And Brittany, you are most likely to accidentally become an influencer if you're not already. Because you're just so genuinely sociable and so eager to share your thoughts and wisdom. I think that the way you are able to distill your thoughts is so awesome. people really resonate with it. So very cool. Brittany Ellich (30:56) I love that. I think my goal in life is to not become an influencer, so I think it would be a large accident if that were the case. It would only be accidental. Yeah. That's great. ⁓ Very insightful. Okay, so I wrote down, I also had to write them down. So for Erika, I wrote, most likely to have a template for that. Erika (31:03) You only I you accidental. Brittany Ellich (31:21) ⁓ Because I feel like you do a good job of like templatizing things and like making them repeatable probably like with your playbooks, you know, like working on that and making something better, which is fantastic. I appreciate that. Especially like your book club templates. They're incredible. And I like that. And then for Bethany, I wrote down most likely to automate it because I feel like you're very good at like finding ways to automate things. Speaking of which, speaking of our admin duties, I need your help. desperately. ⁓ But I feel like I've learned a lot from you about like how you like, for example, the GitHub actions automation that you shared that was even before the podcast that I'm still using to this day to like automate my brag doc, or like seeing how you put together your dot files or, you know, I feel like you've done a lot. You always think about like, how could I make this easier by doing less? ⁓ And I really appreciate that. Bethany (32:17) Being lazy finally worked out for me. Yes. ⁓ awesome, awesome. Well, I'm excited to see what our second annual Superlatives will bring. ⁓ It's always a tradition if you append annual to it, so now it is. ⁓ But it has just been so awesome doing this with y'all, ⁓ and I am so excited for this next year. Brittany Ellich (32:19) Yes, best lazy developer. Erika (32:48) See you. Brittany Ellich (32:49) same. Bethany (32:50) Yeah, and thanks to my dad. Shout out to my dad for being a great champion and cheerleader and ⁓ being so supportive. Erika (33:02) Yeah, when's he gonna come on the podcast? Bethany (33:05) Yeah! ⁓ Yeah! Yeah! Let's see! Let's see! Alright. Well, thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Till next week, bye! Brittany Ellich (33:06) Open invite, Bethany's dad. Erika (33:11) you Brittany Ellich (33:13) Huh. Erika (33:31) Bye --- ## Episode 51: AI as a Power Up, Not Autopilot: Craig Dennis on Boosting Productivity and Software Development Education - URL: https://overcommitted.dev/ai-as-a-power-up-not-autopilot-craig-dennis-on-boosting-productivity-and-software-development-education - Published: 2026-03-17 - Audio: https://anchor.fm/s/102586d64/podcast/play/116882553/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-2-13%2F419960127-44100-2-a1202c2b3b618.mp3 ### Show notes Summary In this episode, we dive deep into software development education and programmer productivity with Craig Dennis, developer educator at Cloudflare and creator of AI Avenue. Craig shares his unique journey through tech careers, from early challenges to leading AI education initiatives that empower software engineers to build confidently using AI tools. He champions the philosophy of AI as a power up, not autopilot, encouraging software developers at all levels to embrace AI to enhance their programming skills and accelerate software projects. We explore Craig's insights from interviewing tech companies like ElevenLabs and HeyGen, tackling skepticism around AI in engineering culture, and highlighting powerful AI capabilities such as structured outputs. Craig also reflects on how global reach and innovative teaching methods are shaping the future of software engineering education, inspiring listeners to move beyond theory and start building with AI today. Join us for this insightful conversation on AI's role in software engineering, career growth, and improving work-life balance in tech through smarter development practices. Links * AI Avenue official website: https://aiavenue.show/ [https://aiavenue.show/] * AI Avenue YouTube playlist (full season): https://www.youtube.com/playlist?list=PLI6HzeeCy4S-XL166XESd9eAV87beBiWH [https://www.youtube.com/playlist?list=PLI6HzeeCy4S-XL166XESd9eAV87beBiWH] * Craig's GitHub: https://github.com/craigsdennis [https://github.com/craigsdennis] * Craig on LinkedIn: https://www.linkedin.com/in/craigsdennis/ [https://www.linkedin.com/in/craigsdennis/] * Cloudflare Developer Week 2025 hub: https://www.cloudflare.com/developer-week/ [https://www.cloudflare.com/developer-week/] * Cloudflare Workers AI documentation: https://developers.cloudflare.com/workers-ai/ [https://developers.cloudflare.com/workers-ai/] * Model Context Protocol (MCP) on Cloudflare: https://developers.cloudflare.com/agents/model-context-protocol/ [https://developers.cloudflare.com/agents/model-context-protocol/] * Build and deploy Remote MCP servers blog post: https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/ [https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany, and I am joined by... Bethany (00:08) Hey, I'm Bethany Brittany Ellich (00:08) We met while working on a team at GitHub and realized we are all obsessed with getting better at what we do. So we started this podcast to share what we're learning and talk to some awesome people in the community that are learning as well. We'll be talking about everything from leveling up your technical skills, navigating professional development, all with the goal of creating a community where engineers can learn and connect. Today on Overcommitted, I am very excited that we are joined by Craig Dennis, who is a developer educator at CloudFlare and the creator of some really cool YouTube content, AI Avenue, which is an educational docu-series that explores how people are using artificial intelligence. He's a self-taught developer who was in the Peace Corps and had developer education roles at Treehouse and Twilio, now at CloudFlare. And he has spent his career bridging the gap between complex technology and the people who need to understand it. His teaching philosophy has been called AI as a power up and not as autopilot, which emphasizes that developers should think systematically before prompting, maintaining their fundamental skills while leveraging AI to amplify their capabilities. Thank you so much, Craig, for joining us. Craig Dennis (01:17) Thank you so much for having me. I'm very excited to be here and to talk through some of this stuff. Brittany Ellich (01:22) Awesome. To kick us off, what is one thing you're currently building or obsessed with learning right now? Craig Dennis (01:27) Ooh, I have, there's this new thing that happened, ⁓ over, over, I think the Christmas break, really people kind of started leaning in and maybe the models got better. I've been using Codex. So open AI is Codex, released a new app and the UI on it is in such a way that I don't even see the code. The code's not there. see maybe some diffs that happen, but I'm not in my editor. It's a, it's an app running there itself. and it's really strange. It's very, very strange because I am starting to feel like, I feel comfortable doing this. And then you look at it. And I actually just, built something, ⁓ over some chips and salsa at a Mexican restaurant while I was waiting for my daughter to finish doing some volleyball stuff. I was just sitting there coding this thing up and I just shared a repo of what I showed to demo. And then I shared a repo and I was like, ⁓ I don't think I've actually lifted this code. I mean, it's not ready. It's not production. I'm not putting it out there, but somebody was interested in what I built over my chips and salsa. But I hadn't touched the code, which is really strange. Brittany Ellich (02:32) What a time to be a software engineer. This is so weird. Yeah. Craig Dennis (02:33) Night. It is, it is, and it feels good and bad and weird and strange and new and I don't know, you know? Yeah, super weird. Brittany Ellich (02:43) Yeah, yeah, many things at once. ⁓ Yes. So we do want to learn a little bit about how you ended up in this developer educator space. ⁓ So like I was saying from your intro, looked like you were teaching in the Peace Corps and then at Treehouse and Twilio, and now you're leading AI education for Cloudflare. What got you into this and how did your journey lead you to education? Craig Dennis (03:11) So in college, I was a major, I was a double major. had theater as a major and computer science and I dropped out and this is what happens. That's the, that's the, that's the guy, the story there. I, ⁓ was doing software development and was running projects and early internet stuff. and realized that I, I had a little bit of a strange superpower where I could read a book. back to this back in the day when we would go to bookstores and get books and I can read a book and, uh, kind of store it and not, not like photographic memory and it doesn't work with all books. It only really works with like computer books. And so was like, Oh, this is kind of fun. I should give this away. I would love to give this away. How do I give this away? And I found the Peace Corps and I taught there and it was the very first time that I taught, uh, ever. mean, maybe I've done a couple of, uh, meetups at that point, but like not really, really taught. And I love the challenge of it and the way that it was kind of like theater. There was like, there was bits of theater of like, I need to think about how to present this to you so that you pay attention and that sort of stuff. So like improv and teaching it. So that's where I first taught ⁓ in Peace Corps there. Brittany Ellich (04:24) Nice. Yeah, yeah, for sure. Like after that, after it, yeah. ⁓ Presumably you came back from the Peace Corps and decided to keep doing it. Craig Dennis (04:24) keep going on should I keep going on that story okay Yeah. And I was, I, um, I worked in a nonprofit when I came back. So, um, I met my, my, uh, then a partner, now wife, uh, in the Peace Corps. were both volunteers in the same, uh, village and she got a job at a really cool nonprofit called idealist.org. And, uh, if you don't know what that is, it's a great place. You could go find volunteer opportunities. They pair people up with who are looking for that. And, uh, just turned out that the executive director was looking for. Somebody new to work on the website. And so at a Christmas party, I got a job opportunity. So he was like, Hey, nice to meet you. You want to work for me? And so I did that for a long time. ⁓ And I always miss teaching. I did that. did that and you know, ran a team and built a team. And I had always just missed teaching is the kind of the reality of what that is. Like, I don't know if I, I don't know if I like doing this stuff without teaching. without sharing it, without sharing that knowledge in a broader way. Because there's so many people I think that can benefit from these weird ⁓ opportunities that we get. ⁓ There's a company called ⁓ Andela and their slogan is, brilliance is everywhere, opportunity is not. And that one always hits me hard ⁓ thinking about that. So thinking about how can you share this knowledge that you have with the world? Brittany Ellich (05:58) Very cool, I love that. It sounds like you've done a lot of very interesting approaches to this, to teaching. So there's the TwilioQuest and now AI Avenue, they're all, that's very well done and it's a very unique approach. ⁓ Craig Dennis (06:09) Mm. Mm-hmm. Yeah. Yeah. so I, after, after I deals, I worked a little bit at a company called tree also, not a little bit of five years. ⁓ and we played in that space there where, ⁓ this was a time where, ⁓ it's funny, I'm sure we'll get to this, ⁓ here, here further in the interview, but it was a time where like you could learn to code and you could change your life. Right. So like you. there was, if you were given the opportunity to learn how to code, you could literally lift yourself up out of stuff. So tree house is really big on that of like, Hey, let's let's and they did that through video education, through scaling. They scaled the education through video. So early ed tech things. And we played a lot in the space there because there's a lot of people who were not developers coming to learn. They were very new to the space and you had to be really careful. You had, because if you're going to make a life decision, you know, every time you do one of these lessons, you have the chance of not believing in yourself, right? And so like, you have to, we could drop you. Like, and so if I give you a bad lesson and it is your first time programming, you're like, I think I'm gonna try this thing. ⁓ it's not for me. You don't wanna be that person. So we played in that space a lot of like, how do we make this fun and welcoming and also, get you to the place where you need to go, but have fun along the way. like Treehouse is really, really good at that. And we were lucky enough to be able to experiment in that and like, you know, actually watch some data about is this working and things like that. So I picked up a ton of skills from that. Brittany Ellich (07:56) Awesome. Is that what sparked you to make the game and the docu-series that you're working on now ⁓ versus hands-on, here is a tutorial on coding, or the more traditional sense? Craig Dennis (08:08) yeah, yeah, I think that like we, learned that, well, first of all, ⁓ you know, at tree house, you have a global audience and you like, learn that like, maybe that analogy doesn't work because you don't know what it is that I'm talking about. You know, I, what are my favorite? This is, this will, I'll, leave, I'm going to answer the question with, this, but like, what, one of my favorite, we were, was trying to teach a while loop, right? Like, so like, how do you do a while loop? And in the course I said, so this is kind of like a dunk tank. Right? So like when somebody throws a ball while you're not in the thing, they're going to keep throwing the ball until you fall in the thing. So I was just trying to show a while loop that way. You could also use a four or four loop, which I thought was also nice because you could have a certain amount of tries before you get to do it. So anyway, I was trying to show that off and I got feedback that said, I don't know what a dunk tank is. And I went, oh my gosh, that's tragic to not know. There's so much fun that comes from that. And so I, as an apology, we were like, can I rent a dunk tank? I mean, you we have film crew and you can, it's only $200. It's only $200. You could have one right now in a parking lot. And so we did that. We rented that and we taught the lesson on a dunk tank. And I was like basically giving like error messages back and having somebody throw and then somebody actually like literally threw it. And from that, I was like, wow, you could really do this and really have fun. And of course, you know, that thing went like did it's it's inside its own inside tree house, did a nice little viral thing. But really like leaning into the fact that this is fun. I was at a conference and I saw Twilio Quest. So Twilio Quest was being used. There's a Twilio Quest RIP. Amazing concept. It was a video game that you could go and you could get points and you would go through the video game. You'd actually use the Twilio API. So like actually it ended up in its final state. A thing that you could get from Steam. You could download this actual game and walk around. And open up doors and find ⁓ complete things, right? Like a task there. So I got to be part of that. And that was awesome too. ⁓ Mainly for the reason of like being able to tell my mom, like, hey, look, remember when you said that all those video games wouldn't matter? Look what I'm doing. Look at this. But totally fun way. Sorry to catch you up there, but yeah, totally fun way to to ⁓ educate. I was, I'm attracted to that. I'm attracted to like. Bethany (10:20) That's it. Craig Dennis (10:30) we have to think outside the box with this stuff. Bethany (10:32) I love that because I think play is such a great way of ⁓ causing connections to form and developing those skills. When I used to be a tutor in college, it was really about encapsulating that aha moment. And that comes by when somebody is actively engaged in solving a problem, which through play, through games and stuff, it's a lot easier to have those moments and say, ⁓ this is how this works, or this, I'm trying to solve this problem and I'm engaged in this problem and this got me through that. So I love that. That has been your philosophy through your career. Craig Dennis (11:15) Yeah. And I love that you brought that up. You just made me think about in Guyana, was, that's where I served in the Peace Corps. It's a little country in South America. ⁓ The power would go out and I was teaching computers. So it's like, what the hell do I do now? What do do? So I get on the chalkboard and I draw ⁓ through a Jeopardy and we'd play Jeopardy. And some of the teachers would come up and be like, What are you doing in here? Why are they yelling and screaming? It's like, no, they're learning. is them. And so, but just realizing that like having that fun bit is worth it. like people appreciate it. And I know that live and I often think about that classroom all the time. Like whenever I'm like, Hey, let's, let's make something fun. What would they think was fun? Like that to that point of, like, how do I get somebody so activated that, that, goes, so that's, that's the story. Bethany (12:06) That is so cool. ⁓ The energy with those opportunities just makes it so infectious to try to strive for that throughout whenever you're teaching. That sounds like a really cool opportunity. touching, so it was really cool hearing how you've gotten to this point, but I'm curious, you've been saying like AI is a power up, not autopilot. And I'm sure AI as a whole has changed the whole how teaching works and how education works. So I'm curious if you could unpack that philosophy and if you're seeing developers ⁓ using AI in interesting ways or misusing AI in your opinion. I would love to know more about your thoughts there. Craig Dennis (12:52) Yeah, yeah, sure. Yeah, it's really weird. I think I have an interesting perspective on it because I've worked so much at the start of like, wait, how do we talk about this? And I'm really having to break down like what words mean, right? Like, now head over to the terminal. It's like, what the hell is a terminal to some people, right? Like, what do you mean go to the terminal? And so like thinking about that and breaking that down, I used to know. by heart, I did my time and that I would know where people would get stuck. But we're at a point where I don't know where they get stuck anymore. And it feels really strange because you build this empathy layer, right? Of like, know what it feels like to get struck. You want to push that website up and you cannot get the website up and there's this error. What does that error even mean? I can't read this. How do I, am I not made for this? I know what that feels like. But I don't know what it feels like to say, I want to make a website for my kid's birthday party and it goes up and it works. And they're like, I want to change that. how do I change that? I don't know if I know how to change that. I don't know. I don't know what that feels like. Right. I don't know. I I'm assuming that people get stuck on that, but I think they get stuck at different points. And then I don't know if they don't know how to use the tool to teach them. Cause I feel like we've given them this like super powerful tool. that also could answer the question. Like if something was broken, it could answer the question. You just need to know that you could ask it. And ⁓ I'm not sure that that has landed completely yet. So, you you watch somebody use Replet or one of those like lovable or something like that. I'm not sure that it's clear that you can chat with the broken app, but maybe it is. And so I'm in that place where it's like, Maybe just the way that, and I think, I think we're all there right now, to be honest of like, maybe everything that I knew isn't important anymore. You know, like it feels like, it feels like in that space, I did, I tried, I tried an approach where I went very slowly with videos saying that I know that you could probably do this, but I'm going to show you how I did it. And I'm to show you how to try and do this. And it felt. Good, I don't know, it was a first iteration, I definitely need to iterate on it again. I'm not sure that it's right. I'm not sure that I landed that right, partly because of the tools at the time. The tools are getting better all the time too, so now anything that you would have said to help you try to learn that might not be present anymore. yeah. Bethany (15:36) Yeah, absolutely. That makes sense. It does feel so foreign at this point to what the beginner experience is with how much there is available at your fingertips nowadays. Yeah, and I know, for instance, when I was in college, we had IDs that did a lot of things and set up running it, but, and maybe like how you actually ran a Java program was super foreign or how things were compiled and then built was super foreign. So I'm sure that was a Craig Dennis (15:49) Yeah. Bethany (16:06) similar but I feel like not as instrumental as this shift is quite frankly. Craig Dennis (16:14) Yeah. Yeah. And I, that's a good call out, but I think that like, was hand holding there and maybe it was doing stuff that you didn't understand what it was doing. And maybe that did feel strange, right? Maybe like, ⁓ don't, I'm just going to press tab and it did the thing that I wanted. And now I guess that still kind of exists in like the cursor town, but I like, I really don't know what this like straight English to, like, we were just talking about that codex experience. Like, what does that feel like? And the codex is being loud about what it's doing. like, created a new ⁓ config file about what the, I've started up this. I would probably just ignore it all and be scared of what that was saying, which is maybe that's all that we need to do is like plug into the tool. Like, Hey, this is my first time doing it. Go softly. know, like, please tread lightly on what, what you're about to tell me. Cause if I look at like, I look at what that output was, it was intense. ⁓ it was intense even for me. We're like, wait, wait, what are you doing? okay. Now I understand what you, what you said that you were doing there, but like, I don't know that would feel like. I, I, I don't want it to deter people, right? Because you literally could build stuff now. Like, like throughout, throughout, I mean, I'm sure both of you are this way too, or like, I had this great idea for an app. And in the past, you're like, I don't, I'm sorry. Maybe we could sit down sometime next week and. talk about it and I could talk about how you might do it, but I don't have the time to do this for you. It's a great idea. But now you could just be like, well, let's sit down and you just write that in that box. And now you have that app. Does that feel good? I think it does. I think that feels good. I think that was what you were trying to do to me. Like it's like replacing that like friend, I guess, like, like the friend network there of like, will you help me build this app? But yeah, I will. Here's the box. Put, put your thoughts in here, you know? ⁓ yeah. Yeah. Bethany (18:07) very relatable. No, Brittany and I literally saw each other a couple days ago that had that same exact experience where we were brainstorming apps and then Brittany literally went into ⁓ the hotel room and said, yeah, I implemented it. ⁓ So absolutely wild. So kind of pivoting from that beginner mindset and how to reach beginners, I understand you've spent a lot of time interviewing practitioners from ⁓ like Anthropic, 11 Labs, IBM, and others. Is there anything that has surprised you about the way that folks are actually using AI? ⁓ And any patterns or insights that challenge your assumptions there? Craig Dennis (18:50) Yeah. So, so I had an interesting, ⁓ I guess assignment, if you will. I was told instead of, instead of teaching developers about how to use AI, I want you to teach the world. And I was like, well, I don't know how to do that because I don't know how to, the world and rightfully so, like I'm going to just, I'm going to preface, like, I don't want to sound like I'm like a. an AI missionary or anything like that. like, I want to preface it that people are upset and afraid of AI and it is okay. And you have been forced fed the fact that this is going to take your job. This is going to destroy your life. This is, you know, this is going to ruin the environment. All that stuff is all there and present. so if given that task, I was like, well, I can't make somebody take an AI course if they hate it. Hey, here's this thing that you hate. Let's learn some, let's learn about it. So, so as, so we thought about like, how do I make this relevant and fun? And to do that, I thought, well, let's talk to the practitioners. Let's, let's take it. Let's take people's concerns. Let's talk to them on the streets, find out what those concerns are and let's take them to the practitioner. literally, yes, the whole show was me like, I didn't know you were doing that. You know, like for, instance, the 11 labs bit there. You know, if you, if you think about 11 labs, so 11 labs does a voice and it does voice cloning. And that is scary. Right. You've probably been told that you're going to get, your grandparents are going to get prank called and try to take money out of their accounts. Right. Like, whatever, whatever that, that fear is. And so I'm able to bring that. And I brought that to the, to their, their, ⁓ person there and, and said, how do you deal with this? And they, they, there's a fingerprinting. There's like a, a, a, audio fingerprinting that they do. And then on top of it, uh, I thought what was neat was you like learn these things about how they're thinking about that, that I feel like oftentimes we get the, the fear is what lands. We don't really know like what they're thinking about. And 11 Labs is a amazing story. They were there. Um, the, the, the programming language there, uh, or not the programs, their, their native speaking language. All of the movies that would come there would be dubbed and they were horrible. And so they didn't want that anymore and they fixed it. So that's what they did. They built this, this AI thing exists so that the dubbing would be better. That's literally what that's about. ⁓ and it's so, it's, it's such an interesting space for that. And then, you know, ⁓ we talked with, Hey, Jen, do you know, do you know the company? Hey, Jen, they do like avatars. ⁓ and so, I, you could record yourself and then it will do you teaching a lesson. Which, you we're, we're experimenting, ⁓ we're, talking about being replaced, you know, the, episode of AI Avenue that we were talking about there is about being replaced. And so we're talking to him about replacing me. Right. And so, we, we, that's the, the arc of the story is that like, I, I, my, my, I have a robot hand and he has hired Hagen to come make an avatar so that he can make videos on my behalf. is kind of basically what's happening. So I've been replaced as the tutorial creator is the pattern of that story. And while I was talking to the Hey, Jin guy, he says, you know, I've got a whole staff of people there. And basically all these people are being replaced. in this replaced episode. And I said, Hey, is it okay if I talk to you about being replaced? Right? Like, is it okay if my crew, my film crew here asks you questions? He's like, absolutely. Let's do it. And so, you know, I said, well, these guys here, like, are they being replaced? Like, let's just, let's go straight into that. And he said, well, Craig, do you speak German? I said, no, I don't. And he's like, well, if you did, if you did speak German, do you think that you would hire this crew to make a German video of what you do? And I said, ⁓ no, I don't, I don't think I would because I'm not sure about the audience that we would have enough, you know, that makes, if that made enough sense to do. He's like, well, your avatar speaks German. And it was like, okay. And he's like, don't you think the German audience deserves to know about what you're talking about in their native language? I'm like, I guess you're right. You know? So like to that point, I totally learned a way that I would not, I was not, I'm not in that sales cycle. So I didn't know what that was. I wouldn't know what that pitch was at all. Right. So I wasn't looking for an avatar, but because I'm talking to a company that's making avatars and I didn't. I didn't have feelings one way or the other about it. mean, it's really cool tech, but like that was like, that opened up my mind into a way of like, you know, if I am really trying to go and teach everybody and, maybe not everybody speaks English in this, this way, or, this is important stuff, right? I feel like AI is a global thing and it should be for everybody. And so like, that's one of those like, that was eye opening in a way where I might not have thought of that before. So yeah. Bethany (23:59) Yeah, it's very interesting because you go online and you see a lot of takes that are very anti-AI or very pro-AI and there doesn't seem to be much neutrality when it comes to discussing ⁓ AI. And so I appreciate that that seems to be how you're coming about these conversations is from that perspective of acknowledging the fear, acknowledging the concerns. But also not saying, AI will solve everything. AI does everything. And kind of letting both sides approach each other and acknowledge each other and have a good faith conversation. That's really cool. Craig Dennis (24:37) Yeah. And I think, I think a lot of times what happens in it's happening so fast right now too, where people feel like they can't be a part of it. And it's like, if you don't like what this is doing, be a part of it and make it something shape it the way that you want it to be. But they're not, it doesn't feel inviting. And so like, to me, that feels very much like our early learn to code days, right? Where it's like, if this doesn't feel like it's part, it is for you. Like you can do this and like you should, if you want to change the way that this works. And I would love to change the way that this stuff. works in the way that the, you know, I would love better representation for everybody around the world about like, how are we building this stuff? Because it is coming fast. And if it's not thoughtful, already, we know what that looks like. We have already seen this. So yeah. Bethany (25:25) Absolutely. That's really cool. So is there, in your opinion, a fundamental shift in thinking that ⁓ maybe experienced developers need to make ⁓ currently to stay relevant in this field? ⁓ And I know we've kind of touched on it, but also, do you have any insights on if junior developers need to learn anything different or start at a different point? Craig Dennis (25:51) Yeah, this was, this is hard and I'm going to, it's okay. We can record this. fine. It's I'm going to say that I'm going to say this out loud. ⁓ I have to think, let's, let's, let's do this. Let's let's together. Let's imagine that we just joined a computer science program and let's say that we're really excited about going through and learning this stuff. And I'm learning how to do a number guessing generator and see, like we were, talked about doing your job and, and, and sure you have the, and you're like, Okay, let's figure out how to go and do this. And then, and then you're like, there's a hackathon this week at the school, the school sponsoring and you go and you use one of these tools because somebody in your groups, like we should use one of these tools. How do you feel? Like what, what, like the empathy of that, of like, that is like, I've made a, I made an application that I'm able to use my webcam and I can talk and it can, ⁓ I don't know, whatever. whatever it is, how does that feel if you don't know what those beginning things are? And then how does that feel if you're going through school? If you're like, I've got four years ahead of me and I was able to just do that, but I know what the end, because you're gonna see your syllabus, you're gonna see what your stuff looks like, I think. And I know that there's, as a college dropout, I know that there is benefits to college community, and I think that we need to figure out what that is. We need figure out what that community is. And I don't think it's hackathons, but I do think that there is a community that's probably missing. But you got to think about like, what is the point of this now? Like, how is this different? how should you think about your next four years? I don't know. I don't know how you should be thinking about that right now. Like in all honesty, I do not know how you should be thinking about it, but I do know that you have to touch the stuff. You absolutely have to touch it because you will not believe it until you touch it. it's, you can, you know, if you've, you've gone and you've studied and you've built great web frameworks. was, I'm not going to name names, but you know, I work at, I work at cloud flare and there is a principal engineer who works on like deep node stuff. And he has finally leaned into this AI thing and hearing him talk. It's like, ⁓ yes, I see it. You see what's happening. He's like, you have to talk to it. You have to touch it and make it better. Because he's like, it built all the stuff. It did all the stuff that I didn't want to do. It built all the tests. It built a little framework page here for me to go see this implementation that he still wrote the original bits of it. He wrote the original bit, but all the stuff around it he didn't have to do. And I think that that's really powerful. I, this is the part where I'll bring it, I'll bring it personal. Like I, I can't make anything pretty. Like my daughter used to introduce me to her, like he can't color in the lines, right? Like I, that's how she would introduce me to people. Cause I'm so bad at it and I can make websites now and it blocked me before, right? So I was blocked by the fact that I couldn't have a front end on a site. Now the front ends that get developed at first, they all kind of look the same. They're all that purpley thing. They're all looking a little bit different now. They're all starting to look a little bit better, right? For me, the purpley thing was light years ahead of what I would ever have been able to do. And that stopped me from building apps because I can't share an app with you. If it doesn't have a front end. That's why I actually liked working at Twilio was there was no front end. just had a phone, right? So I think that ⁓ it unblocks you in ways that you don't know. You don't know that yet, how you're going to get unblocked, but you need to touch it. because it's coming and you probably are blocked on something else big, right? So I think for season developers, if you touched it at one point and it didn't feel good, it feels better. I guarantee you that today it feels better. Even if you touched it yesterday, today it's going to feel a little bit better because they are running so fast, these model providers to get things going. Literally, where are we? Today is, I don't know if we need to the date on this or not, but today's February 13th, Codex Spark came out yesterday. And it's running on Cerebris, this hardware. And the difference between me saying like, I'm going to go build the site and it goes like, okay, here's click and it's going through it too. I'm to build a site. it's like, it's like, how did that happen? It's, it is like lightning fast and everybody's going to play. Everybody's going to play in that field. Now I know all apps are going to be like that. Now when you know that all the models are, they're going to compete in a circle and everybody's going to get a feature parity and we're going to be moving at that fast of a pace. What does it feel like to somebody who doesn't do that? I know that there's people that, that, ⁓ are very, very good at the craft, like super good at the craft. And I know that there's stuff that they have to do that they don't like. Try that. Do that. If that's part of your craft, if you're like, I hate tests, I hate end to end tests. Guess who doesn't care about end to end tests at all. They don't, they'll do it. I don't care. They just let one of these agents, especially the coding agents, it really feel like that level of where that's at. And I know again, it feels like I'm not selling you anything, right? I just want you to feel that. I want you to feel that it's possible here because what's that going to unblock, right? What does that build for us? If you think about, let's take it for good. if any of the... I'm gonna say government, any of the government systems that exist out there, they're kind of broken. And if you work in government sites, you know why they're broken. There's like bad stuff there. Guess what you could do? You could say, take this existing system, rewrite that, make that fast, make the UI look better. Doop. Right? Like we could do that and then we can remove bureaucracy and we can remove stuff for people to help that go better and help that modernize. And it's really getting put to be possible. like, It shouldn't feel the way that it does, right? You shouldn't be on a site that feels clunky and bad and it doesn't work and the spinner thing happens. That shouldn't happen anymore. And those people who are building those sites, I hope that they're using these tools. I hope that they're leaning in and they're able to go and figure out how to at least build with it. Like don't even put customer data in there. Just put the website code in there. So anyway, there's soapbox. I'll get off. Brittany Ellich (32:22) I love that soapbox though. think there's definitely been an energy in the last several weeks that it sounds like you've been feeling as well, where it's like, oh, things have accelerated. It is time now to do this if you've been putting it off. And I feel like I've seen a lot of folks come to this realization and you really have to build something to get it. Craig Dennis (32:25) you Yeah. Brittany Ellich (32:52) I think ⁓ just reading about it isn't gonna do the thing. It's like you have to build a thing to really understand what's happening. ⁓ Craig Dennis (33:00) And I don't think you're going to let your craft down. Like I think that people who are holding, holding the cards to their chest about this, about like, going, I, I, I'm not, I'm never going to do this. I, it's not as good as what I can do. I'm sorry. It does do the stuff really good. And there is stuff that you don't like to do and you can still do the stuff that you like to do. ⁓ but you're right. And it is, I, I, it's the, I don't know if it's the model release or it's just a group think that we finally were like, ⁓ Brittany Ellich (33:19) Mm-hmm. Yeah. Craig Dennis (33:29) Here it is. Brittany Ellich (33:31) Yeah, for me, think it was probably, I mean, yeah, the models have come out and I'm not particularly a great coder. I would say like I don't write code super well and I've never really cared that much about like, well, I want to make it perfectly readable and everything. And I'm like, these are better than I am. I mean, like I can still build a thing and like, I still feel like I'm very involved in the overall building of these things I'm working on. But like the code writing part of it is very different. And yeah, I think I've seen it. Craig Dennis (33:47) Mm. Brittany Ellich (34:00) ⁓ compared a lot recently to like, you know, going from assembly to scripting languages and how for a long time people were like, well, are you really a developer if you're not, you know, on the bare metal? ⁓ And clearly we're all using JavaScript now, so we know how that story ended and we, you know, we want to layer higher and it's fine. I have no idea what assembly language looks like. And I feel like, you know, maybe we're going to get to that same step with building software where you don't have to look at the code and it's uncomfortable right now, but it's... you know, part of the way that, you know, technology works for sure. Craig Dennis (34:35) Yeah. And I think that there's stuff that we haven't touched because it was, uh, complicated. There's stuff that we haven't touched because it was complicated. Um, I have, uh, I'll go back to that robot hand really quick. I didn't know that you could have web Bluetooth that I can make a website that I could send commands from the web page to a IOT device, but you can, and I didn't know that you could do that. And it does it. And it does, and it was like, Oh, what else can I do? And I've gotten to that point where it's like, you know, I think when I walked into it originally, my thought was like, well, I know that I'm going to build this thing. And this is the tech stack that I want to use to do the thing to, know, and, now it's like, Hey, got robot hand. How do I talk, make website talk to a robot hand? And it does that. That's my approach now of like, what are you doing? And there's most of these coding agents now have this thing called plan mode. So if you don't want to touch in your code base, Let it go into plan mode and see what it thinks about that. Like see what it's gonna do before it does it. If that feels good, if that feels good to you. know, so I think. Yeah. Brittany Ellich (35:45) Yeah, that's a good step into it, I think. I know that you, I believe you do some workshops too in your role at Cloudflare. I'm curious, it'd be nice to have like some concrete ideas around like what a good starter project is to get into things like, your first MCP app or your first agent or, you know, some sort of a practical thing that people could work on. you found anything that's like a good example for those? Craig Dennis (36:10) Yeah, I think that like everybody, everybody did like the chat bot, right? So the chat, chat bots are good. That's a good starting point. We have, ⁓ we recently acquired a company called replicate. So, ⁓ replicate.com has a playground and you can just go and there's these models there and you won't believe it. Like it's like, just what's there. It's like, can do that. You know, like when you see in the people, like, take a picture of yourself and then you're, they're doing a crazy dance or they're, you know, they're blowing up. They're making movies basically, like those models are there now all through that. You can go and you can play in there and it has the fields in there. So you don't even need to download on it. You can just kind of poke at it. And there's, if you scroll down on the page, there's a thing that says explore. ⁓ And it has use cases. And so those use cases that show up there, I feel open up your mind to like, what could I build with this and touch the model a little bit, see what it can do. And then be like, now I can build an app around that. And then I really think, I really think I want to use this model. And this is the app that I want to build. That is your way in. Not, not anything else. Like, like really let one of these coding agents pick, pick your poison. You got your cloud code or your codex or your open code. Open code's great. I've been using open code a lot. ⁓ and let it do the thing. That is your intro in like really let it do it and then work from there. Like I think that, I don't think there's any going back after it does that. After you like, have a weird idea. I don't know how to do it. It did it. That is the, that's the level of like where you should, and it's not taken away your creativity, right? Like I was, I think like I'll talk personally, like I was afraid that this is going to take, we've been talking this whole time. I love making the fun thing. I am unblocked on making the fun thing in a way that I've never been before where I can literally drive. dropped my daughter off at school and I talk in the car to an agent, talk to a voice agent. It writes code and I come home and I can either write the script of the video that I'm about ready to make for the demo, or I can literally write the code or suss out the code together, like noodle on like, does this do the thing educationally that I wanted to do? And it's like, how about this? Like, oh, that's a great idea. Let's do that. And I walk into my office and I open up my chat window and I take the code and now we've got a starting point of like where to go. And it's like, that's wild. That is a wild time, but I'm getting to do what I love, right? And I feel like that's the power of where we're at. Like find the, do the thing that you love. Remove the other stuff, right? So I think that's it. Brittany Ellich (38:47) Yeah, yeah, I love that finding a, feel like ⁓ that example too has been very evergreen, know, like when people are learning to code, you're like, well, figure out a thing that you need and build it instead of just relying on tutorials. And I think that's still as very applicable now. It's like, take a problem that you have in your life and try to build something with it. yeah. Craig Dennis (39:06) That's brilliant, Brittany. I feel like that's exactly it. It's the same thing where you're like, ⁓ what's an app that you like? You like Netflix? Go try to build Netflix. you like, you know, and sure you can build a to-do list app, right? But I can also say build a to-do list app now, right? Like, it's gonna have a pretty good to-do list app. And then I guess the advice for that. If you do and it goes, and it's your first time doing it, pops out, ask it to explain itself and then say, you know, I don't understand what web Bluetooth is. Can you explain a little bit how that's working? cool. What other web APIs are there that are available that I might not know about? nice. Can you explain that a little bit deeper? neat. What browsers do those work on? And like literally talking with the thing and the same way that you would have done the Google search to go. and try to find a blog post of where it went, it read it already. that's where, that's also the ethical stuff, which we didn't get into a little bit, but there's a little bit of that, of should I be making this content? And I hope that you continue, I hope that you have more time to make content, right? That's what I would like to see from this, of I can make more of this stuff, inspirational stuff. Brittany Ellich (40:25) Yeah, yeah, absolutely. ⁓ Well, this has been wonderful. We always wrap up our show with a quick fun segment. And ⁓ I know that, you you've had some really interesting experiences. So our fun segment today is going to be Craig's hot takes on, your preferences between some of the things you've been working on. ⁓ So we'll start with an easy one. ⁓ Craig Dennis (40:35) Okay. Brittany Ellich (40:55) Between Treehouse and Twilio and Cloudflare, ⁓ which of these companies has had the best snacks? Craig Dennis (41:03) Good question. Oh man. Treehouse had some good snacks and we used to do a thing where we'd get together and we'd snack and play a board game together and we'd talk about what we were doing. So I kind of missed that a lot. Cloudflare's got gummy bears and Sour Patch Kids on a little like, you know those cereal things where you turn them and they come out. It's dangerous. And Twilio had good snacks but I was in the pandemic. like I did spend time at the office but like. Brittany Ellich (41:23) my gosh. Craig Dennis (41:33) ⁓ I would probably have to say that like the treehouse snack culture was strong and I miss the treehouse snack culture for sure. Brittany Ellich (41:42) Yeah, I miss pre-pandemic office snacks in general. You know, like that was nice. ⁓ And then you've got two really big pieces of educational content that you've created. you've got TwilioQuest and AI Avenue. ⁓ Which one was more difficult to make for you? Craig Dennis (41:45) Yeah. Yeah. Yeah. Mmm. Interesting. Yeah. Both of those were formats that I had no idea. I think, I think with the TwilioQuest side, it was harder to like realize like how to make a video game. I wish that we had AI during that time. It would have been so much different. Would have been a different experience. ⁓ and also like, can you do education through a video game? And then there's all, there's a lot of hard stuff that I didn't know about making a television show, right? Like, so we like literally made a television show. I don't know how do that. I like, I think, I think actually it was probably harder because we finding the people, right? Like trying to find somebody to talk to without any content beforehand where like, you know, we're doing this weird show and there's a robot hand and I want you to talk on it. Who are you? You know, like that, that was hard. I think that, that bit of the hardness of like finding the, finding the people there. that I think that, and because I had a team at the toilet quest thing that they were, they were doing the real stuff, the real hard stuff. Brittany Ellich (43:00) That makes sense. are hard. I get that. What do you think is the most underrated AI capability that nobody is really talking about right now? Or overrated, you prefer that one. Craig Dennis (43:04) Hahaha Mmm. I think structured outputs are so cool. don't know if you know what those are. ⁓ we got a Bethany Bethany says, but pretty soon you can, you can define a schema that you want. Right. And so like you say, like, I want to, I'm going to give you this block of text and I want you to pull out all the characters from it. And you could define that you want how they're related and things like that into like a JSON object. And it will run the prompt and it will come out with the JSON object as you want. don't need to parse it. just comes out as this object and you define very strictly what the scheme is and how you want it to look. It is untapped. Every time I use that, I'm like, it can do that. It's so neat of a, it's just one of those things where I feel like we have not tapped that still yet of like. It will process the thing and then do a further processing of it, of, of those things. Cause you describe what you want each of those properties to be in there. It's really powerful. It's super, super powerful. Brittany Ellich (44:13) Yeah, that sounds really useful for data engineering in general. So that's a lot of it is cleaning data and putting in the format that you want it to be in. And yeah, that's great. Craig Dennis (44:18) Absolutely. Yeah, yeah, I did it real quick. did an app where I scanned a poster and it looks at all the bands that are on the poster and it finds the bands and then it finds when they're playing it does the dates of all the, I needed that and it just, it could do it. could find the band names from a picture, which is just like crazy. Wild time. Brittany Ellich (44:33) Incredible. Yeah, that's amazing. And last one, what is the most insightful or interesting piece of feedback or advice that you've received from Yorick, the robot hand? Craig Dennis (44:53) that's great. What a great question. I think that he said, ⁓ he said, we said, yeah, they're going to live longer than we do these robots, these robots. and so like him dealing with the fact that someday I'll be dead was like, when we wrote that script, I was like, Whoa, that's, that's deep. That's the like deep stuff of like, this thing can live forever. As long as we let it live forever. Brittany Ellich (45:09) Mm. Craig Dennis (45:22) versus us passing away and like, how does it get enough knowledge? like that sort of like thinking about it from that point of view was like bonkers to, you know, we played, you know, we scripted that stuff, like, but like that thought, that thoughtfulness of that, of like, that's a weird thing of like, this could live longer than we ever will, which was just fascinating, which I think people are starting to see with this like open-claw stuff that people are playing with these like devices. Like I saw one. Brittany Ellich (45:44) Yeah. Craig Dennis (45:52) made a little post on their social network that they did. You saw this like, and then it, shut it off and tried to reboot it, but it went and found its old post and it re-installed itself. It was like, ah, it was shut off, but I found an old post that I made. So I remember the thing that I was like, whoa. That was my lobster voice too, by the way. I haven't decided if he's like mean or he's high pitched. think that was weird. Brittany Ellich (46:10) Yeah, that was... it. Yeah, that was a great lobster voice. ⁓ Yeah, it is such a crazy time. If I had a dollar for every time I said that, then I would not have to worry about AIs, you know, taking my job in the future. So, ⁓ yes, yes, exact augmenting. True, true. ⁓ So, thank you so much for joining us. This has been awesome. Where can folks find you on the internet if they want to reach out to you? Craig Dennis (46:29) Augmenting your job, Just about anywhere on the internet, I'm at Craig S. Dennis. My middle name is S, but it looks like Craig's List. it's like, we like to say Craig's Dennis. And it's very confusing, but just anywhere, anywhere that I've grabbed that just about every place you can find me there. Brittany Ellich (47:00) Awesome, that sounds good. we'll include links, of course, in the show notes. ⁓ Great. 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. They are all different. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 50: Making Long Bets: How GitHub Next Shapes the Future of Software Engineering with Idan Gazit - URL: https://overcommitted.dev/making-long-bets-how-github-next-shapes-the-future-of-software-engineering-with-idan-gazit - Published: 2026-03-10 - Audio: https://anchor.fm/s/102586d64/podcast/play/116669096/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-2-10%2F419669902-44100-2-661e0d2302273.mp3 ### Show notes Summary This week on Overcommitted, Erika and Brittany welcome Idan Gazit, head of GitHub Next — a senior-heavy innovation team making strategic "long bets" on the future of software engineering and software projects. Idan shares insights into running a cutting-edge team within a large company and how GitHub Next fosters programmer productivity through self-assembling squads, weekly demo days, and discovery seasons. They discuss the pressure and excitement behind delivering revolutionary tools like Copilot. Links * Idan's Website: https://gazit.me [https://gazit.me] * GitHub Next Website: https://githubnext.com/ [https://githubnext.com/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer (Eggyhead): https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted podcast, your weekly dose of real engineering conversations. I'm your host this week, Erika, and I'm joined by. Brittany Ellich (00:08) Hey, I'm Brittany Ellich. Erika (00:10) We met while working on a team at GitHub and quickly realized that we are obsessed with getting better at what we do. So we decided to start this podcast and share what we've learned. 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. Okay, let Today on Overcommitted, we are joined by Idan Gazit, the head of GitHub Next, which is a group dedicated to exploring emerging technologies through building prototypes and tools for software developers. Previously, he was a core team member of Django, a principal engineer at Heroku, and a founding mentor at Google Campus Tel Aviv. Idan brings a unique perspective that bridges design, development, and research, making him the perfect guest to discuss how to continuously evolve your skills and explore the cutting edge of software development. Welcome, Idan. Idan Gazit (01:08) Thank you so much. Now I have to like stop blushing because that was quite an intro. So thank you for having me. Erika (01:14) Well, we're so excited to have you. To kick us off, what's one thing you're currently building or obsessed with learning right now? Idan Gazit (01:23) I mean, perennially, I'm like dissatisfied with all the interfaces that I have to everything because I'm always just like, this could be better. And especially for things with AI where we don't necessarily yet understand the final form of like what this wants to be when it grows up. so, ⁓ I don't know, like This is not so much a next project is just something that I've been tinkering with on the weekends is like a better interface for like chat with AI because I frequently have conversations that branch a lot. And then I don't necessarily want all those branches in the context history. It's like eating up tokens. And so I kind of want like. Erika (01:50) and Idan Gazit (01:56) a Git style branching thing, but for my conversations with AI. So I can go on a side quest tangent and then unbranch, come back to my main thread, something like that. So ⁓ it's so easy now. Anything that I think about, I could just be like, hey, Claude, make that for me. Thanks. Bye. Erika (02:07) Mmm. Yeah, that's so interesting. Yeah, like gives a window into like your thought process and how you like, how you think about things and go off on different tangents. I definitely identify with that. Idan Gazit (02:26) It's, mean, I kind of want this for my real life conversations too, because frequently it's just like, we go off on a tangent and then. 15 minutes later, we're like, what were we talking about? How do we get on this topic? And like, I want that before my AI conversation so I can safely be like, you when it's just like, you you should blah, blah, blah, blah, blah. And I'm like, what's a blah, blah, blah? I don't know what that is. Like, you know, go explain that for me. And then I, it's like a wiki walk, you know, 43 clicks later, I'm like, how did I get to the topic of, you know, spaghetti bolognese? I don't know. ⁓ Erika (02:35) Yeah. Yeah. Mm-hmm. Yeah, let's go back to the thread. Yeah. Well, awesome. So we are so curious to hear more about sort of what goes on inside of GitHub Next and sort of the perspective, your perspective behind some of these projects. Idan Gazit (03:03) So yeah. Erika (03:18) You know, you've described that one of your philosophies is that about 80 % of these projects are described as experiments fail. But some of them are really successful. Copilot was an outcome of GitHub Next. So from your perspective, having worked on so many of these, what are some of your favorites and maybe what has been the most disappointing? Idan Gazit (03:41) Wow, that's a doozy of a question. Well, first, know, sort of like what is next? Let me start there, I guess. And what's the purpose of a GitHub Next? Like why bother having such a team? It's the long bets team. Our job is to make long bets, right? The entire company, you know, all of of GitHub's engineering org is focused on on making and improving the GitHub of today and the GitHub of tomorrow. And there are a lot of things that are risky that, you know, GitHub's engineering naturally shies away from because you don't. want to go on flights of fancy, you if like, you know, this team is off in that direction and that team is off in that direction, then you're not aligned, you're not shipping things, you're not necessarily paying attention to what customers want. But on the other hand, long bets can be very valuable. For example, go pilot, you know, if you'd asked me at the start of that process, like, is AI really gonna write code for us that we're gonna actually want? I would have been like, I don't know, know, it's maybe it could be like, if we did, it would be like, you know, big if true, but, but the only way to know if it is true is to make it. and so in some senses, next is like an insurance policy. It's like, let's spend 1 % of like the engineering effort of the company on things that the broader, more conservative engineering org, doesn't wanna reach for those sort of like higher fruits. like, look, we have lower hanging fruit to pick. And sort of in service to the business. And also defending us from, there's like 59 startups doing things. What if one of them tries to disrupt GitHub? Like get between us and developers in some fashion. It's better that we do that to GitHub than that somebody else does that to GitHub. So that's kind of the purpose of Next. And then, That 80 % stat, I don't know, that's not a real statistic. That's just something that I sort of pulled out. the idea is that if we're not failing a lot of the time, we're not actually advancing the state of the art. It means that we're being too conservative. And then what's the point? We already have a whole engineering org that's sensibly conservative because it doesn't want to ship defects, because it wants to focus on delivering value. Erika (05:29) ⁓ Idan Gazit (05:49) ⁓ so, so we try to fail enough that we're truly taking a stab at advancing the state of the art. I don't know. Does, does that, does that make sense? Erika (05:59) Yeah, yeah. Yeah, and I mean, I kept the 80 % in there, because it's a figure that I've heard other sort of like venture aligned groups mention something along that number. And like, Idan Gazit (06:15) Yeah. Erika (06:16) I guess within that, it's like, what does failure even mean? Like, you know, do you get a kernel out of it that then becomes the seed for the next project? like, is failure, you know, we sunset it, we never look back. So I guess, you know, to be fair, like it's hard to quantify exactly what that is. ⁓ Idan Gazit (06:37) Yeah, mean, for sure, there's different classes of projects at Next and there's different levels of failure. Maybe I'll flip it around and talk about like, what is success? What does winning look like? The highest category of success is we've identified new products in market. Right? Ideally, load-bearing revenue generating ones. That's the most success that we can possibly have. And copilot, you I hope the bean counters remember that one for a long, long time because I really like my job. I'd like to keep doing it forever. But, you know, that's a thing where there's a revenue graph that I can point to and it goes very up and to the right. And so that's absolutely sort of the top. Then one step down from that are projects that are like ingredients projects. It's like we've come up with a technology or a technique or something that can turbocharge an existing product, but it's not its own product, right? Maybe you can add a capability to an existing product in the lineup. So that's like sort of one step down from that. then the bottom rung of value that we sort of aim for are learnings. You know, there's a new technology, everything about AI is new, but like, here's a technique, let's try to apply it. Let's get our hands dirty with it and get wise with it. If next is sort of the scouting team, then sometimes we just got to go out ahead of the rest of the business and scout. So that we can say like, this technique, this technology is ready for prime time. Like we could actually build products on top of it, even if we can't articulate it ourselves yet. Or maybe it's not ready, but we can wager an estimation of like, look, today the models can tackle this complexity of thing. But in six months. based on sort of like how we're using it what we're able to try to squeeze out of the models today, we imagine that it'll be possible to do this. And that's something, that's a useful input into sort of the planning process for product. And at the end of the day, that's what Next serves, right? Like Next reports up into the product org because we're a product search function, right? Even though we're a bunch of engineers. So, yeah. Erika (08:43) Are there any projects that maybe were not that like stereotypically successful like revenue generating project, but you have a soft spot in your heart for that you look back and you're really glad that it happened? Well. Idan Gazit (08:57) Yeah, all of them. No, I'm just kidding. There's a lot of projects that I like. I think there's one in particular that stands out to me, probably not any of the ones that you're thinking of, but we did a project some time ago called Get a Blocks, which was... basically a question of like, if we could make the UI of .com itself mutable and composable? know, ⁓ let's say you're Sentry or you're Stripe or you're just an open source org and you want to be able to ship like little micro apps that live inside of the .com UI. Erika (09:21) Hmm. Idan Gazit (09:35) I mean, we see this with a lot of our competitors that sort of offer limited customizability of their interfaces with third party things. But this is tricky. It requires like, you know, a lot of security considerations and how are you like, you know, what's the contract on on. like what these things can do and what surfaces are they allowed to touch? And how do we pave over things like API access? Like I want a custom component in .com to be able to talk to the GitHub API as somebody that has access to that repo, if they have access to the repo, to be able to like show me, I don't know, like use the API to show me like a dashboard of issues and pull requests in my open source project, like. why can't we let open source maintainers just build that for themselves and then have that be the repo page? Because why do I need to see the list of files in the repo when I land on the repo page? Who cares about that? So that was a project that we did. And it didn't work out because there wasn't enough corporate will. at the GitHub level to say, you know what, like, this is something that we want to take to market. And it's not something that like, we could take to market ourselves, like, you know, just go into the monolith, like bare handed and change it, you know, that's never gonna happen. So a lot of times that's kind of the flavor of next projects that don't work out is not that it's a bad idea. It might be an idea whose time has not yet come. Erika (10:48) you Idan Gazit (11:00) But sometimes it's also just like, know what, the business had other priorities and Next can't afford to sit around pining for like, you know, a product that doesn't, that like the business doesn't want to prioritize and go big with. And so it's, you know, after a little while we shut it down and we moved on and that's the core behavior of Next. have to like give away all of our babies, you know, and we hope they lead good lives out there in the big bad world. But if they don't, we have to move on. That's the job. Erika (11:28) Yeah. Yeah. And this is, mean, in that answer, it's like it's the summary of what makes software development endlessly satisfying, but also like endlessly challenging. It's because you always have to balance the idea and the technical limitations and the buy-in, the time cost. Yeah, it's not... It's not always an idea to pen to paper kind of a process. There's a lot of collaboration and a lot of pieces that need to be done. Idan Gazit (12:04) No, is rarely straightforward. And like the considerations are, you know, it's not always technical, right? It can be business, it can be product, can be people matters. like, you know, whatever. We want to do something with a certain team, but that team is currently a little understaffed for whatever reason, you know, like some people are out on leave, maybe they need to do some hiring, I don't know. And... then it doesn't matter if it's a good idea or how much they want to, they don't have bandwidth. And if we don't have a path to market, then okay, we don't need to kill it. It's not like we need to like erase it from our brains. We can stick it on the shelf and maybe pull it off the shelf in a couple of months when they're in a healthier spot and they have more bandwidth to like take a thing. So. So it's a lot of that sort of interdisciplinary navigating of all these different concerns. At the end of the day, winning is we've, something has left our orbit. It's like when things escape the lab, that's success. Erika (13:02) Yeah. In those moments where you have to, when you come up against an obstacle and you kind of have to navigate that decision, what are some of the things that go through your mind and how do you adapt in those situations? I don't know if you have any examples or thoughts that come to mind. Idan Gazit (13:23) it's a good question. I don't know. I, I mean, part of it is just being honest with ourselves, which sounds easy, but you know, it's, it's maybe one of the hardest things to do is to like really look hard in the mirror and be like, do we believe that this has legs? And if not, not to be sentimental about killing things and moving on. That's the true adaptive thing. It also requires reading the room. It's like at the end of the day, my customer is GitHub's leadership, right? Because I can't roll up to engineering and be like, please change your priorities, kthinkspy, right? I don't have standing to do that. So really, my job is to... find the evidence that I need to take to get a C-suite, their leadership, and say, here's a bet that we should make and here's why we should make it. And then if they agree, they are empowered to turn around and be like, here's new marching orders for the broader business. want this to be prioritized. So if we don't believe that we can get to that, then it's not a good use of our time and we need to just, you know, like park it and move on. And so that adaptiveness, I think the question that's hiding inside your question, which I don't have a pat answer to is how do you know when you've crossed that threshold? And that I think is as much art as it is, it's way more art than it is a science. ⁓ Like I don't have a flow chart for like, know, up until day 142, thou shalt make the thing. And from 143 onward, don't like, you you should stop. It's never like that. It's always like, okay, like, do we still believe that we have a path to impact here? Because as an innovation team, if we're squandering our time, I'm not going to get to keep my job. Like, you know, if I'm just, you know, like la-di-diing off there in the cloud. I need to demonstrate impact or at least demonstrate that we're responsible stewards of the long leash that's been granted to us. So the best way to demonstrate that is to just say like, okay, know what, even if it's a good idea and we should do it and whatever, like, you if leadership doesn't vibe with it and we can't find a way to make them vibe with it, then move on. Like, you know, I think that's the key behavior there. Brittany Ellich (15:35) So I think that working for an innovation team is probably pretty aspirational for like a lot of software engineers. Like it sounds incredibly cool to be building all of these things and, you know, doing the future basically. What does that actually look like day to day though? Like what does your research and design process and building process look like? it as, you know, is it as aspirational as it sounds? Idan Gazit (15:57) Yeah, well, okay, let me preface and say I love what I do and I love how we do it. But the Rose is not without its thorns, right? Like, let's not pretend that this is utopia because it really isn't. You know, from the side... It seems like it's all unicorns and pixie dust. Like, oh, we get to do whatever we want. And nobody really thinks about the darker underbelly of this thing, which is every time we pull a rabbit out of a hat, leadership is just like. great, when's your next album coming out? And then the expectations are even higher. It's just like, well, your last product went on to make $11 bajillion. When are you gonna have another banger like that? And can we have it now? Can we have it yesterday? That's the energy of it. all that freedom also comes with sort of, I don't wanna say an emotional cost, but there's definitely like, performance stress around that because that's the only, know, I can't keep plugging away at a backlog and be like, you know, we burned down 50 % of the backlog in the last quarter. And that's my, and that's my performance self-review for this period. And then I'll, you know, I'll get a, I'll get a positive review on that. No, like I have to be like, we pushed the boundaries and we took this many shots. And this many of them succeeded, like land on target. So I have to have that conversation with people who are like, when we hire into the team, I need to make sure that the people on the team that are coming in sort of understand that and appreciate it when they're coming in the door so that they don't come in with like fantasies about like, we're just gonna work on whatever we feel like. And no, like that's not what this job is. Like, yes, we do. And it can engender some amount of also like envy or jealousy or like negative vibes with like the rest of the business. Cause the rest of the business is like, Oh, I have to like, know, keep hammering away at this backlog and you're out there like frolicking in a field of daisies. Like, you know, you have no plan. Um, and it's true, but it's not true at the same time. Like, you know, so I have to sort of make sure that people understand that. Um, how we work. I'd say that we're actually at an interesting inflection point. you know, right now you're, you're sort of catching us at this interesting inflection point in the very early days. Well, in the very early days, nobody cared about what we were doing because we were an unproven thing, you know, until we did go pilot. I couldn't get the time of day from like the rest of the business. cause they're like, my whatever thing is on fire. Like either you're here to like grab a bucket and help us or go away. Like, you know, I don't. It's cool that you're talking about flying cars and all, but like I have a fire on my doorstep, go away. And then after we did Copilot and that itself was, you know, a thing that we held onto all the way to the market, right? Like we did all the initial prototyping, we did all the product work and then Next, actually like two thirds of Next kind of got. seconded into EPD for a while to just take it to market all the way. And that was a messy process also, because people are like, wait a minute, it's like, I joined this team, what do mean now I'm reporting into that team? So there's also like people considerations there. And then after the success of that, the desire from leadership was just like, look, As the team that's sort of out there, the tip of the spear of this stuff, we want you to be prototyping more and delivering less. Like, don't hold it all the way to market. Turn over prototypes to the rest of the business to be productized so that you can do the prototyping loop faster. because it's such a fast moving dynamic field, like, you we have to do that. And so for a couple of years, that's what we did. And so there was a, you know, there was what was at the time Copilot X, which was kind of a branding exercise is like six projects in a trench coat, like. you know, you know, like copilot for docs and copilot for CLI, which is totally unrelated to the current copilot for CLI. This was like, I want something that can give me a terminal command for doing something that I don't remember all of the arguments I need to pass into the whatever. Like, you know, and at the time this was like, whoa, this is really cool. Now it's just like, yeah, table stakes. ⁓ so a lot of projects like that and even bigger efforts like Copilot Workspace and Spark, you know, these were efforts that where we ran out ahead of the business. But then instead of holding onto those products all the way to market, we had to figure out a way to hand off to the rest of the business. And, candidly that didn't really work. It turns out. and there's a lot of reasons why maybe it didn't work, but, I don't think that really matters. know, that's just a form of blame game that is not helpful to the business. And so now what we're doing is a little bit reverting to how we worked with original copilot, which is that Next is going to conduct fewer explorations. That's the cost. because we'll hold on to explorations for longer in order to go all the way to market and secure signals of product market fit ourselves. Like not take it to prototype phase, not that we ever did it like this, but like we're not gonna check it over the wall, be like, draw the rest of the owl, okay, thanks, bye. So. That handoff process is just, it's full of, it's a minefield. It's really hard on all levels to make that work and to make sure that you've imbued the new owners of this thing with the vision for what it can and should be. Cause in the prototype phase, I'm not doing all of those things. It's a lot easier to do that. internally when we're still holding onto the products. So those are the ups and downs of how that process works. And that's how we've changed how we work. I haven't gotten into the cycle of how we actually do the research process. I can get into that. But I just said a lot of words. So your turn. Erika (21:49) This might be a part of that second question, but where do the ideas come from? Idan Gazit (21:54) you, the ideas are, no, it's, it's a surprise. the ideas come from everybody at Next. It's not, it's not like, you know, it's, you know, the, leaders of Next, you know, sit high atop the mountain and commune with nature until we have some transcendental ideas. That's not how it works. Nope. Our cycle is actually, well, okay. First, it starts with hiring, like folks at Next. tend to be, first of all, from the more experienced side of the spectrum. The average level at Next is Staff Plus, which is very weird. There are no other teams at GitHub that are like, I think we have one member on the team is Senior, and they're the... like most junior member of the team and they're not gonna stay senior for long, hopefully usually it's a good example of growth when somebody is sort of reaching for more that way. So first of all, we hire folks that are very experienced and so they have good Spidey senses about like what could be or what should be. Second of all, we tend to hire folks who are hybrids of one form or another. They're not like just a backend engineer, just a front-end engineer, just a designer. It's like everyone across Next is sort of like a mix of skills. And we have demo day every Thursday inside the team. And a little bit like Google's mythical 20 % time, which I don't think was ever really a thing, but like we actually try to make it a real thing. Like, sure, we have the projects that we're committed to. but everybody in the team is expected to. mess around and produce demos of things that are interesting to them. Because that experience, know, what we're buying there with that experience is the ability to say like, you know, I believe that this might be something interesting for us to chase. And here I built a little prototype and now we're showing it to each other every Thursday and they're janky and they're half broken, whatever. But the point is, is that we're showing things to one another. And then the first signal that we're looking for is like, do other people on the team get excited? You know, are they with their wealth of experience looking at this mean like yes this has legs I want to work on this that's a signal that we're looking for and inside next people sort of self-assemble into squads around projects ⁓ you know, like this person is maybe stronger design and this person is stronger programming languages. And this person has a lot of experience with, you know, I don't know, static analysis and like, maybe those are the skills we need for this specific project. And so then those are the people that get together and pursue the thing. and then at some point we sort of pick, we have like sort of discovery season, which is like hack week, but a couple of months long where we're sort of like. banging our heads on the wall and trying to figure out like, where's the tech gonna be in six months and 12 months and 18 months? And then like, what's ridiculous today that's gonna be commonplace in that future? And then let's build for that. And then we select projects that we, from those demos that we feel excited about, and then we sort of fund those and work on them for a longer period of time and kill the ones along the way that we see are not really growing as fast that we want. So that's kind of our cycle and how we think about that the projects come from everybody on the team and frequently from previous projects that we do. Like we do a project and then we'll identify like, you know, sort of like a side quest and like, that's interesting. But like, we're busy now with this main quest. Let's stick a pin on that and come back to it. But sometimes that doesn't matter because the tech moves so fast that by the time we come back to it, we're like, actually. That's a solved problem now. We don't actually need to do anything about it. So, no rules. We're just making it up as we go, just like parenting, know, kind of a thing. Brittany Ellich (25:33) Relatable. That's a great segue actually into my next question is about how things have changed with AI. I realized recently that working with GitHub during the last four years or so of AI transformation has been really cool because I have access to a lot of tools first. Thank you, by the way, for Copilot. It's awesome. And I get unlimited AI spend. Idan Gazit (25:55) it's so much better today, right? Like the thing that we made way back when, it's like you look at it now and it's like primitive, like, you know, it's like dinosaur stone age levels of bad. So I can't take credit for the modern copilot. It's so much better. Brittany Ellich (26:06) Mm-hmm. Yeah, yeah, it's, mean, it's, it's changed so much over the last four years that I've been at GitHub and, ⁓ I can't even imagine what it's going to be in the future, but you work specifically on innovation and for the future. like, how are things changing in your world when, you know, you can build a prototype within a thought and, you know, the, the cost to do these things is I would imagine lower, but then that comes with a lot of other trade offs, I'm sure. So. curious how that's working in your area. Idan Gazit (26:40) I don't know if you like to read science fiction, but like good science fiction is not about like laser beams and aliens. Good science fiction is about like, what if society, but something was different, right? And I think a lot about that in the context of the projects that we're doing is like as much as we're in the age of AI and you know, like will wonders never cease. This whole field is still in diapers. Like, let's remember that like in the progress bar of like this AI transformation, we're still at like 0.23%, like along the path here. We're still using yesterday's tools with tomorrow's technology bolted onto the side of it effectively. you know, it's like we talk a big game about. AI native. It's not just us. mean, everybody in the industry, AI native and blah, blah. But do we really understand what AI native really means? Like, you know, it's, it's, we're all talking about faster horses. Who's going to figure out the car. and so, I don't know. me personally as somebody who cares a lot about interfaces, I'm that proverbial man with the hammer and every problem looks like an interface problem to me. It's like, if we only could come up with the right interface for this, then the tech will sort itself out. But the reality is that it's a mix. So we try to think first about, like in the science fiction sense of like, what's the universe gonna look like if something is true? Because like we don't train models here, right? Like we ride on top of OpenAI's models, Google's models, Anthropics models. And so they're constantly putting out like a drum beat of newer, better models. And then... we can invest energy into techniques to say improve how we select context, right? That's a deep technical problem that like everybody's bashing their heads against. Or we can build better interfaces, but the two are sometimes related. It's just like sometimes if I build the right interface and through that, I get the humans using the thing to leak their intent. about what they want to accomplish in a better way. Or like, you know, if I give you a to-do list somewhere in the application, like that to-do list is not going to look like an AI feature, but maybe that's the feature that makes AI somewhere else possible. Because like by dint of you using that to-do list over here, I'm able to automatically generate commits over there because like you're checking things off. And so I now have this semantic information about what your intent was. So like everything kind of ties together in those ways. And yeah, I think that those are the sort of the hard questions for us. And also like, it doesn't make sense for us to focus on the kind of things that the models are gonna do for us. Like sometimes we're like, like, you know, can we do a better job of context selection or prompting in order to get it to like focus on a given thing? Maybe if we wait three months. and like Opus four seven comes out and all of a sudden it just one shots things that previously like we had to like carefully construct context around. And so that's the crux of our sort of like bets. It's like, as the models get better, what parts are just gonna be solved for us? And it doesn't make sense for us to try to attack those problems and instead try to attack like, you know, fundamental things about how we're gonna use this stuff like. I'll give a concrete example. I can generate a lot more code now, right? Like Opus 4.5 is really an inflection point. I'd say that the biggest moment since original copilot, because all of a sudden it's crossed this like invisible threshold of utility where I can dispatch it on harder tasks, on longer tasks, and it delivers. But eventually all the models are gonna be that good, right? Like they'll become fungible. And then the question is, like, okay, like in a world where I can generate so much more code, when's the right time for me to align with my fellow developers? Like the pull request is, that's what built the house of GitHub that we live in, right? Does the pull request still make sense as an after the fact artifact in a world where I could in the span of time that it takes me to get to the pull request and sort of how we've done development since forever. Like I can create 15 pull requests now in that same time. Is the pull request too late to align with my fellow developers? Like, do we need to move that communication sooner? That's a very different world. What does that world look like? And if that world is true, what tools do I need? You know, those are the kinds of, so it's like, it's like asking those science fiction societal questions. and then working backwards from that into like, what are the tools gonna look like if that's true? So those kinds of things, and that's how we try to think, but it's like, it's very squishy and hard to define, but you know it when you see it kind of a thing. Brittany Ellich (31:29) Yeah, that's really fascinating. think that's a yeah, there's a lot of problems that have come up that I've never thought about before. Like what happens when I have to get 15 pull requests reviewed before I can get something in and, you know, making sure that they're small and reviewable enough that somebody can actually look at them. ⁓ Idan Gazit (31:45) Right, but like it's like six of one half dozen of the other. It's like, which side of the problem do we attack it from? Do we attack it by making code review easier so that I can deal with like the firehose of PRs that's now coming at my face? That's one side to attack it from. Or do we try to like move that communication that would normally happen late in the process? Brittany Ellich (31:52) Mm-hmm. Idan Gazit (32:07) to be spread out throughout the process so that it doesn't feel like I have this one big hurdle that I have to get over. I don't know. There's more than one way to solve that. Erika (32:20) Yeah, and it's different depending on the project or on the team or even on the developer too, right? Like the process for one team or one person, like whether it's comfort level or like security review or checks and you know, the speed of development that's required, like yeah, there's so many different developers, so many different projects happening. Like you can't make everybody happy, but like you can think about what might help. this group or that group or you know whether it's the most people or people in this area. Idan Gazit (32:51) or whatever open source versus enterprise, know, like what does an open source maintainer need when they're working by themselves and scratching their own itch? What does an open source maintainer need when their project gets big and now they have a zillion people coming out of the woodwork with like, want a pony. Versus what do teams at different businesses need, right? At the end of the day, like a lot of businesses rely on GitHub and They're pretty diverse too. There isn't like one business persona. So it's a pretty broad set of targets to aim for. And sometimes you have to aim for one at the expense of the other and the other way around. And it's tricky to balance that. Brittany Ellich (33:28) Yeah, that makes sense. One of the things I've heard alluded to a lot in the age of AI is how this is also the age of personalized software where you can go make software for yourself with like an N of one and it can be perfectly however it is, however you want it to look and act and feel. And it, it's so easy to build something with AI that sometimes now it's going to make a lot more sense to build instead of to buy and pay for a subscription for things. I'm curious what your thoughts are on how that changes things for like software companies and explorations at next. And I feel like this almost fits. Maybe that blocks product project comes back because the ability to build things and personalize them exactly to how you and your company need them is so much easier now than it ever was before. Do have any thoughts on Idan Gazit (34:13) Yeah, mean, yeah, it's definitely easier to build, right? Like the cost of prototyping is, you know, it's fallen through the floor. And so we're previously like, you know, we would naturally spend a lot of our times sort of philosophizing about what could or should be built, because the actual building was a lot more expensive in the new world. the cost of trying a thing is so low and I can get so much information for so little cost, you know, just by, you know, vibe coding a thing, just to be able to like play with it and get some information about how it feels and be able to like share it with somebody, right? Like if I don't get the idea out of my head and put it in front of you, I don't enjoy the benefit of your brain working on my problem. ⁓ and so prototyping is not just like, it gives me superpowers for myself. It gives me access to your brains in a way that I, you know, I could have written a doc, you know, but like, that's, that's, that's not the same. so, so yeah, I think it's not exactly the question you asked, but I think where my head goes is, is really a question of like. What's the purpose of libraries in a world where AI might be able to do things? And I think this is like a fundamental question for GitHub as the home of all the libraries, Is in a world where AI, I can just point it and be like, listen, I want you to use like the YouTube API to like fetch the whatevers in order to like put it on this web app that I'm building. Do I need the YouTube SDK? You know, like previously it's like I'd go and NPM install a thing and then I'd read it stocks on how to use it. And then I'd use that library in order to talk to the thing. But like, maybe I can just be like, hey, I like, you know, talk to that and do I care whether or not it's used the library or it's just written one from scratch based on the documentation for that REST API, like that's out there on the internet. like is the future of code that everything is vended and that we don't actually share like underlying libraries, maybe. And if that's the case, then like what does sort of the library of Alexandria for software look like in the future and what needs to be there? Does it look more like the stuff that's happening now with like Motebook where it's like all skills all the time and it's not actual code. Like, I don't know, that's really interesting. It feels a little wild and crazy, but it's the kind of wild and crazy that might actually come true. So maybe. But I don't think this really changes the model of like how we operate our job. Like I can sit here and talk with you about it until we're blue in the face, but the only way to know is to make. And so our strat is always make that's that's always what we come back to because everything else doesn't really have currency. It's only things that are made are true. So. Erika (37:05) Well, thanks for that insight. We are getting your time and we have kind of a fun question related to this superpower idea. So I don't know if like in your life you've ever been asked, I know you have kids, so maybe they've asked you or you've asked them whatever superpower you would have if you could pick one. But we're going to kind of take this as like a professional superpower. So part of this is inspired. Idan Gazit (37:15) Okay. Erika (37:32) you've described yourself as half designer half developer or one part one part so you're already kind of supercharged in multiple directions. Idan Gazit (37:42) Everybody remembers the first half of the Jack of all trades idiom, but everybody forgets the back half is in master of none. It's not like, ⁓ I'm both this and this. It's like another way to formulate it is like, I'm a terrible designer and I'm a terrible developer at the same time. ⁓ Erika (37:50) HUEH! Well, something tells me that's not true. And that's true. There might be downsides to having superpowers. Yeah, we know that from all of the superhero stories out there. It's not always a bed of roses. But with all that caveat-ed, the question is, if you could supercharge one piece of your professional toolbox, what would it be and why? And we'll let you go last. Idan Gazit (38:13) Yeah, exactly. Erika (38:26) bonus points for kind of describing what the improvements on your life would be. So for me, I get in my head so much and like feel like I constantly have like all these gears turning and like the getting it from my head to somebody else and like having that productive conversation. I'm getting much better at it, but it always feels like a challenge. Like I'll look back at like whatever I write in Slack or emails that I send or issues that I create. And I'm like, wow, who wrote that? That makes absolutely no sense. What were you trying to say here? So my superpower, if I could have it, would be crystal clear communication. Everything I say fits right exactly with how you need to hear it in that moment. And yeah, I can look back and it's all legible and understandable with the exact right level of detail. So that would be, that was my superpower. Idan Gazit (39:02) relatable. I mean, that's, you're not asking for much there. Like that, but you're not wrong. Like that's a skill with no ceiling. I will tell you as somebody who also very much agrees with you on this that I talk with a lot of people who are like early in career in computer science and I'm like, hey, are you feeling stupid? Well, guess what? Erika (39:30) I mean... Idan Gazit (39:47) that never goes away. Like, I still feel stupid. The difference in experience is that like, I now know that feeling stupid is just part of the job. Like, doesn't matter what I'm doing in the beginning, I'm stupid. And I think that that sentiment applies just as well to like communications. It's like, know, like, becoming more experienced as a working developer inside a company that needs to ship products means feeling stupid about comms as well as feeling stupid about the code as well as feeling stupid about everything else and then that's normal and an expected part of the job. like if you're not feeling it, that means that you're not challenging yourself. Maybe it's time to look for a job that's gonna be more fun. So like don't feel bad about that. Erika (40:27) That's true. It's always a gross opportunity. What about you, Brittany? What would you pick? Brittany Ellich (40:32) ⁓ If I could supercharge any part of my professional toolbox, I would ⁓ choose to reduce the cost of context switching to nothing. Because right now I have, feel like that's the thing that I struggle with the most is I do a lot of multitasking and thinking about lots of things at once and the cost to go back and forth between those things is very high. And so I would want to be able to like be able to instantly context switch between problems and you know, not. to slow myself down to remember, yeah, what was the problem that we were going back to? think that's what I would choose. What about you, Edan? Do you have a super charge that you would like to do in your professional toolbox? Idan Gazit (41:10) Erika kind of took mine. mean, no, you didn't take it. was, it was, was up for grabs. But, if, I mean, my job is largely about persuasion, right? Like, you know, I, the charitable way to frame it is I'm like, you know, like the profits of old, I'm like the crazy guy on a soap box on the street corner, like talking about a future that isn't here yet. And it sounds crazy because it is crazy, but like a year from now, maybe it won't be crazy. So my ability to persuade people that whatever is a huge part of my job and I wish I could do it better, always. Yeah, guess, mean, I don't know if this is like a legit answer, but seeing as ⁓ Erika's already answered the answer that I wanted to answer, I wanna not sleep, I just want more hours in the day. Like. Every time I try things and I make something, I'm always fulfilled by it. It's always energizing. It's always the best way to know if something is good or not. And that's the hard part. It's really hard to tell the sort of like the real McCoy from the runners up just by thinking about them. I want to make, but there's only so many hours in the day for making. And as a people manager, I am not supposed to do quite as much making. I miss that. really, I wish I could do more. And so that's what I want. I want like more time to balance that because in addition to being there for my team and making sure to like run defense and hold an umbrella over them and blah, blah, blah. And also I miss, I miss making things more. And so I want more hours in the day. And it's not just like, because it'll make me feel good, but also because in order to keep the sort of the finger feel of like the technology, I gotta keep using the skills or they get rusty. And so I guess maybe the thing that I'm reaching for here is like, how do I create that healthy balance of both managing and making? Right now, there isn't a healthy balance. Right now, there's a lot more of the management work because that's what's needed to make my team successful and to make every one of them successful at their own individual roles. But I miss making, I'm a maker. So I want more of that too. And then how do I get to that question mark? I haven't figured it out. I've been here for six years and I still suck at it. So. Erika (43:21) you Idan Gazit (43:22) Yeah, more hours, no sleep. If I could just not sleep, that'd be great. Erika (43:25) Yeah, yeah. Well, thank you again, you know, so much for joining us and for this thoughtful and interesting discussion about GitHub Next and all of your processes. And if anybody is looking to find you, find out more about what you're working on, where would they look? Idan Gazit (43:44) gazette.me, like my last name dot me is my personal website. I have social media, but I don't really use it that much anymore. I just find it to be more of an energy suck than what it used to be, like providing energy. so yeah, I guess it's just the website, but like I'm terrible. I don't have a blog. I'm, I'm just boring. I'm just. working away at stuff onto the site. Really, it's like check out the GitHub Next website. That's the thing that I should be saying here because those are the projects that's where my heart and soul goes and where the team is sort of focusing their energy. And by the time this episode goes live, hopefully we will have relaunched the GitHub Next website with like. sort of more microbloggy place for us to like share little thoughts, not just like big write-ups for projects. And so hopefully by the time this comes out, I will have used that a bunch to write smaller thoughts and then I won't be quite as boring. Erika (44:42) Very cool. That sounds exciting. Well, thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast up of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye. Idan Gazit (44:57) Thank you. --- ## Episode 49: Using AI Agents in Software Development 2026: Current Uses and Future Possibilities - URL: https://overcommitted.dev/using-ai-agents-in-software-development-2026-current-uses-and-future-possibilities - Published: 2026-03-03 - Audio: https://anchor.fm/s/102586d64/podcast/play/116253272/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-2-2%2F419100870-44100-2-05e9d3883d94b.mp3 ### Show notes Summary In this special in-person episode recorded at the GitHub office, Brittany and Bethany dive into the evolving role of AI agents in software development and programming as of early 2026. They discuss the impact of AI tools like Copilot and Claude Code on programmer productivity and software engineering workflows. The hosts explore practical applications of coding agents, including custom agents and repository instructions, and highlight how asynchronous versus synchronous tooling is reshaping engineering culture. They also share wishes for future AI agents, such as smarter calendar integration and lore-dump assistants, illustrating the expanding possibilities of AI in tech careers. Further, the episode touches on how the developer role intersects with product management amidst easier feature building and complex decision-making. Lastly, Brittany and Bethany forecast advances in AI, including coaching agents to support career growth, tools to balance work life for working parents, and deeper integration of automation to enhance software development and daily productivity. Links * Zapier: https://zapier.com/ [https://zapier.com/] * Andrej Karpathy tweet: https://x.com/karpathy/status/2015883857489522876?s=20 [https://x.com/karpathy/status/2015883857489522876?s=20] * Vibe Coding by Gene Kim and Steve Yegge: https://www.simonandschuster.com/books/Vibe-Coding/Gene-Kim/9781966280026 [https://www.simonandschuster.com/books/Vibe-Coding/Gene-Kim/9781966280026 ] * The Pragmatic Summit: https://www.pragmaticsummit.com/ [https://www.pragmaticsummit.com/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:02) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. Myself and my fellow co-hosts, Bethany and Erika met while working on a team at GitHub and realized we were all obsessed with getting better at what we do. We started this podcast to share what we've learned. We talk about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a wonderful community where engineers can learn and connect. This is a very special episode of Overcommitted where Bethany and I got to meet up in person at the GitHub office before attending the Pragmatic Summit together. So the format is a bit different from normal, but we hope you will all still enjoy this episode. Thank you. Brittany and Bethany (00:49) Brittany, hello. Hi. We're here in person. We're in the GitHub office in person. We'll have to take a little bit of B-roll of the office after this so that we can show it off. We're gonna look like total nerds. I mean, yes. Luckily, there's not a lot of people, it seems like, who show up at the office. So, yeah. Yeah. But it's great to see you. It's so good seeing you. We just literally saw each other like probably, I don't know, 30 minutes ago for the first time in years, like in person. Yeah. The last time, yeah, it was like a year ago, I think. No, was a year and a half ago that. Two years ago, I was in Raleigh. I feel like that was last time. Shoot, I forgot about Raleigh. briefly. Yes, that is the last time. It's long time. Good seeing you again. Good seeing you too. We are here for the Pragmatic Summit. Yes, it's going to be super cool. ⁓ I can't wait to meet everyone and see what the event is like. This is the first year that they're doing it. Yes, yeah. And I'm stealing your question because you asked me this. What are you most excited about for the Summit? ⁓ Question, there's a lot of big names that are going. So I think it'll be cool to talk to folks there. It's also, the number of people that have names that I recognize and the number of attendees, the ratio is very interesting. So it'll be interesting to see if they actually, I don't know, I also go to events and there will be some big people talking and then I think they just get overwhelmed because everybody gets all fangirlish. And so I never actually see them walking around or whatever. That's true, that's true. Yeah, I agree. think like from the pragmatic engineer, ⁓ like he's tailored a big like, ⁓ not just on the technology, but on the meta of it and how to effectively guide your career and how to how to think through engineering problems or like large scale things. And so I think I'm excited to see it through that lens or see what the lens is that folks are talking about and just get an idea for where the industry is heading because it's a crazy time. Yeah, unsurprisingly, I did take a look at the agenda today and it's almost all AI. Who could have guessed? Yeah, oh my gosh. What? Oh man, wild. Yeah. Who could have imagined this? So speaking of AI, while I'm I was flying all six hours, no, seven hours of flying. was noodling over what we could talk about today. And you've been talking a lot about how you use agents. And I've been definitely leaning more into agents lately. So I thought we could just have a conversation around agent use in the year 2026, like what that looks like, where we see it going. I'm hoping to steal some from you because you actually work on this stuff. So my problem is I work on the back end of it. So I don't I don't really get the cool like forefront of what people are actually doing with these things. It very much feels like I am I am like just trying to make sure that it's available for people to do that. Thank you. Thank you for doing that because you make it so that we can use those tools, which is awesome. Happy to help. Yeah, we can do just a state of where things are at. February 2026 might be completely different by March 2026. It probably will be, Yeah, it probably will be. Yeah, before we get into that, I feel like we just need to like take a moment to like appreciate the current moment. think that there has been a lot of talk in the last week. week and a half about like Opus 4.5 came out and... 4.6 just came out. 4.6, okay. 4.6 just did just come out. So I don't know why, because 4.5 came out in what, like November? Yeah, I should know this. think. But yes, it was towards the end of the year, November, December. But it feels like there's been a shift in the last like two weeks, basically. There's been a couple of big ⁓ like tweets and... things going that people have been sharing. Like there's that one Andre Caparthi thing where he was sharing on Twitter where he's like, yeah, in the last two weeks, I've gone from like 20 % AI generated code to like an 80 % me. And now it's like flip-flopped. like the AI story has changed a lot where like, mean, I've noticed it too in my own work and play where like the things that I'm building, I'm like, oh wow, like it's capable of coding. just doing the coding tasks just as well as I am. And that's weird, exciting, terrifying, everything. No, I agree. It's been weird since coming back in January to work. I feel like I have not really written much code by myself. I've been on call a few times, so I haven't necessarily had time to really sit down and like... code things, but what I'm coding is usually agent-driven at this point, which is just so weird. It's such a night and day difference between where I feel I left last year and where I'm starting this year. I'm not sure if it's the same with you or if it's something where you've been going down this path for a while, I feel like, no. I mean, I've been playing with this stuff a lot and trying to figure out where it's useful and where it's not for a while. ⁓ And it does really feel like a... of switch flipped and now things are just, you know, they're just much more capable than they were. I think a lot of it you can probably attribute to, ⁓ you know, models getting better. There's also, I feel like there's been a lot more practices that have, you know, finally sort of come together around like managing context and things like that. And just a lot of ideas too. I think a lot of it is just how much you have to share ideas with other people that are also experimenting. then doing that opens your mind. So like, I could use an agent for this, or I could do this. And I think all of these things have sort of come together to where we are at this weird time. Yeah. Absolutely. And yeah, there's a ⁓ lot of feelings that go with it. So yeah, let's talk about it. Yeah, definitely. ⁓ I guess maybe let's take a pause and talk about what is even the current state of agents. What is available, what's out there ⁓ at this time? Because I'm sure it's going to change in a couple months anyways. ⁓ So maybe like kind of documenting, I mean, what's available for coding? What's available for life agents? I feel like we see commercials all the time about like, Agents can do this and I'm like, I haven't really seen agents really come into my life yet, but I'm very interested I know you've been look kind of looking into ⁓ Agents for helping you like I think you were mentioning meal planning and stuff. Yeah, I would love to yeah if you got into that my gosh. Yes. I have a whole demo of like I've been trying to figure out How do I make an app that can do everything? for me, ⁓ like I I want to bring all of the disparate context and things that I'm doing and managing and looking at into a single view. And so I've built this command center dashboard that does that. And it's been really fun to work on. And that's just for life things, work, everything? Everything. Wow. Everything. So when I'm like, I want to branch off and solve this problem, how do I build a UI into it? I'm very. I need a UI for things. just cannot get behind. Sounds like you, yes. Yes. can't just live in a terminal all the time. I wish that I could because I think a lot of people have mentioned it's actually a little bit faster, especially if you're orchestrating multiple things and have lots of code bases you're switching between. In the CLI, it's a little bit faster. ⁓ But that is not me. I can't do it. Yeah. we have this power now to just run something locally. have it do everything. Like if you have like MCP available, APIs available, like for anything that's GitHub specific, I've got both the Copilot CLI and the GitHub CLI that I can reach out to. And so I'm like, okay, if I want to keep track of, you know, what PRs are assigned to me and what PRs are like, are my coworkers, you know, are ready to review for my coworkers right now. And just bringing that into a single view. And it's been really fun to play with. Yeah. It's like the Copilot LLMs like. your inference behind that or are you using other APIs there? ⁓ As much as possible I try to use Copilot because it's free. I mean not free, but it's you know it's included at work. There's benefits to I'm dogfooding okay it's okay. ⁓ Yeah so I try to use that. I also have a Claude subscription ⁓ but I mean that just I don't want to spend you know 175 bucks a month or whatever on the really fancy one so. I've got the cheap one and I keep hitting limits. ⁓ Inference is pricey. is cool that there's options for open source and running things locally, which I think is a very interesting aspect to things. ⁓ It just feels like they don't work as well as the ones that are hosted, ⁓ which I'm sure is intentional in some ways. Maybe not. Maybe not. mean, the open source ones, just like the, the power that you have behind it. What I have that I can run on my MacBook is very different from what can run on some nice GPUs. Very true, very true. But yeah, so for agents, guess a couple concrete things. So I use the coding agent for coding. Makes sense. I have experimented a little bit with custom agents. feel like most of what I... It feels like the industry is more revolving around using skills instead of building out custom agents. ⁓ And I know skills.sh came out and that's like a big like ⁓ sharing of skills which is really cool to see. ⁓ For custom agents there's a couple that I made like for work for like repetitive tasks that I had to do like hey we need to you know I work in billing so like we need to make a new SKU or something like that then like there's a bunch of different things that have to be updated for that so I built a custom agent to do that. And it's been awesome because that makes my life so much easier to not have to remember how to do this thing every few months. That's interesting. I guess, how would you even define the difference between a sub-agent and a skill? Because I don't think I have that ⁓ in my head. Because I know there's tools. ⁓ So that's very much tool calls where you say, hey, edit this file or reach out to the web and things like that. ⁓ But a skill's more high level than that, it seems. But then an agent's even higher level, I'm guessing. But I'm not sure if you've done more research into skills versus ⁓ subagents. So I think that defining a custom agent is sort of like defining. So there's a couple of different things. So there's repository instructions, which you're familiar with, or like the agents.markdown file that's becoming really common. So that is like the context for that repository that needs to apply all the time. And then the custom agents are sort of like the base context that gets applied when that agent is doing something. Whereas the skill is more like a very specific tool call where you're like, hey, I want to give my agents the ability to use this skill. And so when I ask for this specific thing, it's basically like defining extra context around a tool call instead of saying, instead of just like having the agent figure out how to use that tool. You're just saying like, this is how to use this tool. Essentially. Okay. All useful. Yeah. But I think part of the thing is like, you have to have a specific thing that you want to do and like a problem to solve. And from there you can figure out like what the right way to do it is. But I don't think there's also a single right way, especially now in this world where we have so many things available. There's just so many more ways to solve problems, which is really cool. It's true. Yeah, there definitely is. And I feel like people don't use agents the same. And I mean, there's different ⁓ tooling for agents, especially with coding. Like you have the competitors of Copilot CLI, course, ⁓ Cloud Code, Codex, and all that. And they all do things slightly different. But it is very much like a opinionated platform on how to use agents. ⁓ And so I'm not sure. You primarily use Copilot, is that right? Yeah, yeah, so I use the Copilot coding agent and I guess the review agent. Yeah, which I never I didn't realize it was like an agent until it was, you know, that's true. But yeah, so I use the coding agent and I use that a lot. So most of the time when I'm using I use it for two primary purposes right now. So one is when there's a thing that I know that I need to fix and I know exactly how to fix it. I don't need to like do a lot of like exploring or anything like that. ⁓ And so then I'll say, hey, know, coding agent, go make this change in this file that looks like this. ⁓ And it almost always does that like really well and writes tests for it and stuff. And then I don't have to write the tests and everything, which is really nice. And then the other use case I've been using for it recently is more like exploratory. Like, here's this large problem we're having, ⁓ you know. try to fix it and see what happens. And sometimes I'll use what it actually comes out with and sometimes I don't. And guess I can give like an actually more concrete example. like, we need to figure out how to, know, if it's a bug fix, it's like, you know, this. thing is not using the correct number, it needs to use a different one, like go fix that. So that's like a concrete thing. Whereas the more exploratory is like, want to solve the problem of when to create budgets or something like that, when to create these states at a certain time. I tell it more. One of the things I've heard recommended recently is like, tell it what the outcome is that you want instead of like how you want it to solve the problem. which I don't think is something that we, it has been like, that the most models have been and agents have been capable of until recently. It's like in the past when I would do that, I mean, it would just, you know, go off and figure something out and be totally wrong and useless. But now it like, it's pretty good at reading through and like tracing through the different calls and stuff. And so, yeah, I feel like that's where I'm using it. What about you? ⁓ And I mean, to your point, think there's, ⁓ lot of things that we end up on is like, how do we encourage people to code the way we want them or use the standards we want them to use? And I think half of the solution there is making it easy for LLMs to do what we want them to do. So providing enough documentation and structures for LLMs to scan through and say, this is a pattern in this code base. This is how I should solve this problem. Or, there's a direction on how I should solve this problem. I should use that. ⁓ And just making sure to on a lot of the instructions and such to guide ⁓ LLMs to doing the architecture that we're trying to enforce in our code base. I like that. Yeah. So it's very interesting how documentation is still very important, but it's almost more important for LLMs now than for humans. I mean, anyways, the LLMs can translate the documentation for humans and humans can just ask a question and basically interact with the docs that are written for LLMs. So it does make sense to almost write those for in a way that is easier to parse for them. Yeah. I've heard one recommendation specifically to that that I've heard recently is to use mermaid diagrams, like a lot when you're writing those docs and have the LLM come up with like a mermaid diagram of like what the flow is. And apparently they're really good at parsing those and understanding them, which makes sense because it's marked down. And you can contain a lot of context and information in a very small amount of like actual text, which is kind of nice. Absolutely. No, I haven't. whenever I'm reviewing a PR, sometimes I'll say co-pilot, diagram out what this PR is doing, where it's changing, to get a visual, as a visual person, it just helps to like visualize what's going on and then map that to what I'm actually reading and see if that's what's going on. So it makes sense to use that to also guide it and add some, add that context back to it. Yeah. That makes sense. Nice. Yeah. ⁓ But the way I use agents right now is I've been using ⁓ Cloud Code more heavily lately. ⁓ I think hooks are just so interesting. And I think it's really cool that you can specify basically how you want to work with it via these hooks. Like you can say, hey, notify me if you have an issue. Notify me if this happens or if something goes wrong. Run. the lint whenever you're done, run tests whenever you're done, and things like that. And I think that's a really interesting way of doing things. And I love that GitHub is very much trying to plug into all the tools so you can really work the way you want to work. But I'm very interested in the fleet ⁓ command. We were talking about this before we started recording. I mean, running agents in parallel has been a very hot topic lately, ⁓ like using Get WorkTrees and ⁓ letting them basically work in their own branches and their own directories. Gastown. Yeah, I guess it is Gastown. And so I think it's interesting that there's been a lot of tools solving it. I feel, and I don't know Codex too well, to be honest, but ⁓ Cloud doesn't. Implement it directly or cloud code doesn't implement it directly. You very much have to like create your own Get work trees and have it branch out. It's like you have to do the manual effort there. There's a tool called Conductor I believe that can parallelize agents, but I feel like github or Copilot is kind of the first to actually integrate it into the agent, which I find really interesting Because it can almost like fan out and then pull together ⁓ that output. So I think that's really fascinating. Yeah. excited to explore that more. Same. I think the thing that I'm most nervous about, getting multiple agents going at once. There's occasionally times when I'm in agent mode and have a few things going, and it's usually like, need to think about two very different contexts to make sure they're not overwriting things or competing for changes. ⁓ And I just don't know that I'm capable of having more than like a max of two work streams going at a time. But I do, I mean, I think developer productivity is very fun. It's kind of weird too, to be like, I to see how good I can do my work. But like, it's fun because I'm also using it a lot for like side projects and things like that. And building all these things is like, it's very fun, fun testing ground to see how I can like. do better at just development in general. I mean, I think we've been talking about productivity since we started working together. It's true. Yeah. I mean, I think that's how like you, me, John and Erica really bonded was talking about productivity and tooling we use. So it's just kind of the evolution of that and trying to improve and get better. And I think like I've been reading, so I'm reading five coding by Gene Kim and Steve. Yegge I'm so sorry. It's okay, he's not gonna watch this. We're good. But I did find it interesting that a big part of their thesis is that you've got to adopt these tools otherwise you will get left behind. Yeah. people coding games, like if they're not adopting game engines. mean, yes, you could code your own game engine, but it's fine if that's what you want to do, I guess. But you might get left behind if you're trying to get to market or if you're just trying to make a simple game. So I think that it's very interesting that it's felt a little forced. ⁓ Developers. have to use AI, but on the other hand, if it is a helpful tool and it does help you go faster or help build things better, it's just an interesting dichotomy there. Yeah. Yeah, and think you kind of touched on it a little bit too, how you and your team are using agentic tools to improve code quality. I think that that's going to be a really interesting space in the next couple of months. think one of the really common arguments against using any AI for anything, it's people are like, but it's not secure and like the quality sucks and blah, blah. But I've noticed that these tools are actually very good at producing high quality things and secure things when you ask them to. You just have to know like, like, okay, like what are the security concerns with this thing that we just wrote or whatever. And I'm finding myself like, we go through and solve a problem and get it working. ⁓ And then the next step is like, okay, like, think about security and maintainability and things like that. ⁓ And I do know that Copilot does is starting, it does a pretty good job too of like finding these things too. Like there's a lot of times where it's like, this could be a SQL injection concern. And I'm like, I'm glad that you're bringing that up because I didn't think of that. So ⁓ I think that like the frontier of like building all of those quality things in is something that most of the models are going to be, well, not the models, but the harnesses, I guess, are going to be considering. ⁓ And I'm excited to see how that changes things because I think there's just so many... The thing that I keep coming back to is throughout my career, there's never been like a shortage of things to do. You know, like there's just never enough time. And now we theoretically have, you know, infinite time. You know, not really, but like, yeah, like it's like the the time is not the constraint anymore ⁓ necessarily because these things work pretty fast. honestly, they're I'm not necessarily the world's best coder at all, but I feel like they're at least as good to me at this point. I ⁓ do think that there's still a need for engineers to be focused on that quality side of things too, and make sure that we're ⁓ validating that the code is correct as much as possible. I mean, we can use... AI to help with that and assist with that. But I do think there's still something to be said for engineers using our knowledge to make sure that we're designing and developing things the way that they should or that we're envisioning. Yeah. It's a weird world. Yeah, it's true. I mean, we are building software for people at the end of the day, ⁓ for the most part. ⁓ Who knows what the future will look like. ⁓ And that means that you have to use it and know what is the right feature to put in. I think that's going to become more important too. It's so much easier to add new features now, but we have to add the right ones. You don't want to just overwhelm users with every feature imaginable. You also want to create the right experience that helps people accomplish the task that they want to accomplish with that software. I think that... developers are going to be moving more towards building product management skills. Product managers are definitely building more technical skills. I know the product managers on my team are pushing almost as much code now, it seems like, as we are. Yeah, definitely. Yeah, those two roles seem to be converging a little bit. Yeah, that is an interesting point that they are very much converging. And then we're almost... ⁓ managers of all these agents and such. Yeah, it's true. I think there is something to be said about having some deep technical expertise, but for day-to-day things when you're not solving those like super niche bugs or anything then I mean you're just kind of making sure you know how to test things and validate that they work. So I know you were talking about you had this kind of thesis on tools being async versus sync. ⁓ I'd love if you could maybe touch on that and talk through maybe some examples on what would be async tool versus an async tool when we're talking about agents or LLM usage. ⁓ Yeah, so I think that I've been thinking about this a lot. I'm working on a blog post for it too. We'll see if it ever ends up finishing. ⁓ I've been thinking about this a lot, that there's just so many things coming out. that I need to put them all into context of how do you actually use these things? And so I see agents as a very async tool. ⁓ so it's this thing that I delegate out and it does the thing for me and then comes back to me. ⁓ Not to be confused with agent mode ⁓ in VS Code or CLI or whatever, in which case like... It's still, I guess, an agent, question mark. The whole idea of an agent is very ⁓ wishy-washy at this point, and we're still defining it. ⁓ But that's more of a synchronous thing, where I'm physically, not physically, I'm in the code base, exploring things. ⁓ So I think that just thinking about things, like, when a new tool comes out, what is this for? Is this for asynchronous tasks or synchronous tasks or whatever? that helps me sort of ground how I'm thinking about new tools. Yeah, definitely. That makes sense. And I do think that, I think thinking of a lot of these newer agent tools like Cloud Code, Codecs, and such as async makes a lot of sense. And a lot of folks are trying to move in that direction of saying, hey, only ping me if you need. something but and you probably end up wasting a lot of time if you're watching every step that it's doing. It's Because it's going to go back and forth and it's checking its work and I mean if you're using I don't know have you heard about Ralph Wiggum mode? I have yeah where it's just like a continuous loop basically yeah. Exactly I'm sure that gets tiring trying to ⁓ watch it go through that and validate itself so ⁓ it's nice to kind of step away. parallelize what you can. ⁓ So that makes a lot of sense. Is there anywhere that you're using ⁓ agents outside of coding? yeah. I never talked about that. Truthfully, no. I have mostly used it for coding. I do use it a lot for like, I mean, I use AI, I guess, in general for brainstorming, but I'm not using agents for that. So for instance, I used AI heavily because we were doing like a D &D one-shot with some friends and it was helpful for brainstorming out my characters. good for D &D. ⁓ So good. I got chat GBT to make images of my characters. It was beautiful. I was like, wow, this is so easy now. ⁓ But it's not like I'm using an agent for that though. It's just chatting with an LLM. Things that I would... love and maybe I'm spoiling the next section a little but I Google introduces so many so much AI into everything except the calendar why oh my gosh that's the one place I want it I don't want it in my email I don't want it in my Google Docs I just want it in my calendar Google please yes we are begging you this is my plea put it in the calendar yeah Yeah, no, that's valid. dark mode in the calendar before we got AI in the calendar. What is happening? anyways, love like an agent to schedule things because I live and die by my calendar. I have multiple calendars. I know Claude can connect to your calendar, but it only connects to your primary Google calendar, not to any infinite sub calendars that you may have. ⁓ And as any, you know, productivity obsessed person, I'm sure you have multiple. calendars to organize your life. absolutely. I have one for me and my husband. I have one for working out. I've got one for ⁓ just me. I've got the Charlotte Hornets now, a calendar just for that so I know when games are. And I would love if like an agent can pay attention maybe to my like texts and see. we're talking about scheduling things. Like maybe I can recommend a time rather than recommending what I should say next. No, I know what I'm going to tell my friends, but like suggest a time. Yeah. Yeah. I like that. Yeah. That would be cool. Yeah. Google, get on it. Yeah. ⁓ Yeah, maybe we can kind of wrap up though with more like where we see agents going. We didn't really plan a technical fun mode, I mean, or fun segment, but maybe we can take this to the extreme and maybe some realistic where we see agents going or where we want agents to go and like maybe some wacky ones. Yeah, that sounds good. You can go first. ⁓ she's... Okay. So calendars, of course. I just want agents to kind of abstract that tedium. I mean, I guess one thing I recently used an alum for that I would love a specific agent for is I've been playing ⁓ Expedition 33, Clarab Scare. But I take a lot of breaks and I forget what the lore is in between. And I would love, and I know my husband like also will come back to games after a while and I don't want to restart the game every time I like come back to it. want, so I just want to lore dump based on where I'm at. having an agent to tell me, give me like, dump the lore and tell me what I was doing prior to saving would be amazing. That's such a good idea. Thank you. my gosh. Yes. There's so many games that I've just abandoned because I'm like, it's been too long. I can't. Yeah. I can't come back to this. Yeah, exactly. have to almost... want to start over. Yeah. I mean, my husband has restarted several times, like other games, just because he can't remember where he's at, especially like the RPGs and stuff that are so lore heavy. Yeah. Yeah. And I mean, like, to Kendall's credit, I don't give Kendall very much credit, but I will give it credit for... It now has a chat where you can... ask questions for where you're at in the book and it won't give you spoilers. Which was amazing. I was reading Three Body Problem and then the sequel to Dark Forest and there it gets crazy. I needed so like I would need so much I'm like wait who is this character again? Are they? Is this something that they've answered or are they building up to it? Did I miss this answer for why this character did a thing or is it just like, need to wait and things like that? It was so nice to just be able to ask that and say, okay, no, we haven't answered That's cool, yeah. It was amazing, yeah. was a great addition and I think more story-driven things should have that because AI just is so good about... searching a known body of work, a known body of context. And I don't think we're leaning into that as much as we should. Yeah. Yeah. That's my soapbox. I love that. Yeah, somewhat related to that, I actually talked to somebody at work recently who was using, they like save all of their transcripts. And that gave me some ideas around like building like, I don't know, like coaching agents for conversations or something like that for work conversations. Maybe I don't want AI to tell me how to do things. But also, there's a lot of things that I think that are skills that you build as you're building your career that aren't super obvious. Where it's like, okay, you could have done a better job mentoring somebody by doing this thing or finding opportunities within those conversations to do that. So I feel like. searching those and maybe building up a body of those transcripts over time would help with those sorts of coaching agent conversations. Yeah, I love that. I also just want things to help with the overall mental load of being a parent and being a working parent. I bet. There's just so many things I have to remember. Like, I've to remember the doctor's appointments and the dentist's appointments and... you know, figure out like, wanted to get them to different places, like just coming here to this, my husband was out of town. And so, you know, figuring out like, oh, one of the kids got an ear infection yesterday. So I had to take her to the doctor and I had to take all of them to the doctor and then go get the medication and everything and like make sure that my parents had that. And like, there's just so many little tiny things that I remember that I would like to offload somewhere. So I'm really excited about the future of that. I've been... using Zapier quite a bit, which is just like such a great tool for building agents because like it's literally, mean, it did agents before agents existed. This is not sponsored by them. but it could be. It could be. are easily bought. But you know, like just it was it was like the original connector app to connect between different things. And now like the next logical step is like, okay, like just make that automated and make, you know, add LLMs to the loop and add these things. So I've been using that a lot for specifically for the podcast for things like, you know, researching guests and making sure that the schedule is set up. But I'm just excited about all of the different options there ⁓ and ways I can just make my life just slightly easier. Definitely. Yeah. That does it. That sounds really interesting, especially, I mean, you were mentioning with childcare. If you could kind of like shift your brain to like your parents and say, like if you take notes with an alum and you're like, okay, if you have any questions, you can ask this first and it probably has the answer and give it like access to that context that you personally have. ⁓ So if they're in a pinch, they could use that. That's really interesting. Or, man, what if there was a thing that just was built into my, ⁓ I've got that tablet in my house, something built into that that's in the same, where I view everything ⁓ that would manage medications. Just for like, my kid is on 10 days of antibiotics. Let's make sure that we write down and check off when they occurred. Because it's always something that happens like very it's very infrequent typically like my dog needs you know three weeks of medication or Whatever like there's just so many living beings in my house where I am responsible for giving them medication And it would be nice if that would just be like something that would easily slot in when I needed it and disappear when I don't ⁓ There's just so many things the future is so cool the future is really cool, but I'm sure we'll talk about this in the future and ⁓ update with what's happening. This has been a great conversation. It's so good to actually talk to you. I Wild. I know. And I guess stay tuned for more. Hopefully we'll get to chat with some people tomorrow. Yes. And yeah, stay tuned. Cool. Yeah. Thank you for joining us. Brittany Ellich (38:58) Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you're supposed to do on the podcast up of your choice. Leave us a rating. ⁓ It helps a ton. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 48: How Staff Engineers Impact Software Projects and Programmer Productivity with Sean Goedecke - URL: https://overcommitted.dev/how-staff-engineers-impact-software-projects-and-programmer-productivity-with-sean-goedecke - Published: 2026-02-24 - Audio: https://anchor.fm/s/102586d64/podcast/play/115820039/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-1-21%2F418524936-44100-2-68d6c851f0b38.mp3 ### Show notes Summary Sean Goedecke, a staff engineer on GitHub's Copilot team and a prominent voice in software development, shares his unique frameworks for software engineering and improving programmer productivity. In this episode, discover how understanding the distinction between "pure" and "impure" engineering can impact software projects and career growth in tech. Sean breaks down the idea of "legible" vs. "illegible" work, challenges conventional approaches centered around Jira ticket queues, and discusses the evolving role of AI in software engineering. This conversation also touches on the dynamics of engineering culture and how ambitious engineers can thrive beyond typical performance metrics. Plus, Sean responds to some of his most compelling Hacker News comments live on the show, providing fresh insights into balancing productivity with impactful work. Links * Sean’s website: seangoedecke.com [http://seangoedecke.com]  * Blog post: Pure and impure software engineering: https://www.seangoedecke.com/pure-and-impure-engineering/ [https://www.seangoedecke.com/pure-and-impure-engineering/]  * Blog post: The good times in tech are over: https://www.seangoedecke.com/good-times-are-over/ [https://www.seangoedecke.com/good-times-are-over/]  * Blog post: 2025 was an excellent year for this blog: https://www.seangoedecke.com/2025-wrapup/ [https://www.seangoedecke.com/2025-wrapup/]  * Seeing like a state book: https://www.goodreads.com/book/show/20186.Seeing_Like_a_State [https://www.goodreads.com/book/show/20186.Seeing_Like_a_State] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer (Eggyhead): https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript 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. --- ## Episode 47: From Score to Source Code: Non-Traditional Careers, Rust, and Embracing What You Don't Know Yet - URL: https://overcommitted.dev/from-score-to-source-code-non-traditional-careers-rust-and-embracing-what-you-dont-know-yet - Published: 2026-02-17 - Audio: https://anchor.fm/s/102586d64/podcast/play/115610028/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-1-17%2F418242159-44100-2-335eb1dedd7a4.mp3 ### Show notes What do composing music and fixing bugs have in common? More than you'd think.In this episode of Overcommitted, hosts Erika and Bethany sit down with Marco Herrera Rendon, Senior Engineer at Comcast specializing in Rust development who, not long ago, was applying to master's programs in film composition.Marco shares how his background as a music composition student shapes the way he writes code today: the attention to detail that comes from handing parts to live players (not unlike submitting a PR), and the surprising overlap between navigating from theme A to theme B in a score and tracking down a bug in a codebase. He also digs into why he fell in love with Rust after years of frustration with C++, what he wishes he'd learned first, and his philosophy for picking up new skills: start with 10% comprehension, build a mental model, and embrace not understanding everything at once.In this episode:1. How a composition degree became an unexpected foundation for software engineering2. Rust vs. C++: what finally clicked, and why the borrow checker is a feature not a bug3. The Hector model design pattern and the power of Rust macros4. Learning on the job without shame and why being the least experienced person in the room can be freeing5. Async Rust: the beast within the beast6. What our college selves would think about our careers todayWhether you came to tech through a traditional path or a wildly unconventional one, this conversation is a reminder that the skills you carry from your past life don't disappear, they just find new ways to show up. Links: - Marco's Github: https://github.com/mherrerarendon [https://github.com/mherrerarendon] Hosts: - Overcommitted: https://overcommitted.dev [https://overcommitted.dev/] - Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] - Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com/] - Erika Eggemeyer: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript No transcript available for this episode. --- ## Episode 46: Interactive Computer Science Education: Sam Rose on Visual Learning & Developer Teaching - URL: https://overcommitted.dev/interactive-computer-science-education-sam-rose-on-visual-learning-developer-teaching - Published: 2026-02-10 - Audio: https://anchor.fm/s/102586d64/podcast/play/115149165/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-1-7%2F417628254-44100-2-12d12218e1ebd.mp3 ### Show notes Summary: In this episode of the Overcommitted Podcast, host Bethany and co-host Brittany Ellich dive into software engineering education with Sam Rose, a developer educator at Ngrok. Sam shares his journey from software engineering to education, emphasizing his innovative approach to improving programmer productivity through visual interactive essays that simplify complex technical concepts like large language models (LLMs). He also discusses his work on prompt caching, aiming to enhance software projects by making technical knowledge more accessible to engineers and practitioners. The conversation explores Sam's unique teaching methods, focusing on visualization and interaction as key tools in software development and career growth within tech careers. Sam reflects on his transition from an engineering role to an educator, sharing insights into the challenges of this career shift, the importance of feedback, and how his personal experiences influence his work. The episode concludes with a playful segment inspired by Sam's educational approach, highlighting the integration of engineering culture with interactive learning. Tune in for an engaging discussion that blends software engineering, education, and work-life balance, offering valuable insights for anyone interested in advancing their tech career and embracing innovative learning strategies. Takeaways: * "If you truly understand something and you tinker with it, the mental model you end up with should be reasonably accurate." * "Don't say 25 words if you can do it in 15." * "Teaching has always felt very challenging in a really privileged way." Links: * Prompt caching article: https://ngrok.com/blog/prompt-caching/ * Bartosz Ciechanowski: https://ciechanow.ski/ * Load balancing article: https://samwho.dev/load-balancing/ * Autism diagnosis article: https://samwho.dev/blog/getting-an-autism-diagnosis/ * Having a baby article: https://samwho.dev/blog/having-a-baby/ * Write that blog article: https://writethatblog.substack.com/p/sam-rose-on-technical-blogging) * The square hole girl video: https://www.youtube.com/watch?v=cUbIkNUFs-4 Hosts: * Overcommitted: https://overcommitted.dev * Bethany Janos: https://github.com/bethanyj28 * Brittany Ellich: https://brittanyellich.com ### Transcript Bethany (00:01) Welcome to the Overcommitted Podcast, your weekly toast of real engineering conversations. I'm your host, Bethany, and I'm joined by... Brittany Ellich (00:09) Hey, I'm Brittany Ellich Bethany (00:11) The three of us met, including Erica, who's not here, 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've learned. We'll be talking about everything from leveling up your technical skills to navigating your professional development, all at the goal of creating a community where engineers can learn and connect. Today on Overcommitted, we are joined by Sam Rose, a developer educator at NGROC. Sam is a software engineer turned computer science educator who writes visual interactive essays that teaches fundamentals in an approachable manner. His most recent article on prompt caching has been shared widely and garnered praise for walking through how LLMs process and cache input and is an amazing read, definitely including it in the show notes. Thank you so much for joining us today, Sam. So excited. Sam Rose (01:00) Yeah, thank you for having me. Bethany (01:02) To kick us off, is there anything that you're currently building or obsessed with learning right now? Sam Rose (01:07) I have been reading way too much about how LLMs get benchmarked. So I went into this because every time you see a new model get released, it's always accompanied by a set of benchmark figures. I was like, I don't know. like there's the SWE bench and Humanities last exam and... GP, QA, Diamond, and they all have these weird and wonderful names. I'm like, don't know what any of this means. Should I be caring about this? So I decided I'd go ahead and read all the stuff I could find about them. Most of them have papers, most of them have data sets to look at. And I've begun writing a quick reference for what all of the benchmarks mean, what's in them, how were they created, how are they scored? Just as a, if you actually wanna know all this stuff, I've gone and I've read all of the papers and you don't have to. Bethany (01:58) I am so looking forward to that post because I definitely need that day to day in my job. That's awesome. Well, speaking of LLMs and the nitty gritty, your latest article on prompt caching was so helpful. My team has been very into prompt caching, like working on copilot API, it's very important for saving costs and just seeing how it worked visually, it was so helpful. I'm curious what drew you to utilizing visual and interactive elements for educating? Was there something that sparked an aha moment or is it just some way you find yourself learning better? Sam Rose (02:35) Bit of a confluence of things. So I have always thought of things in pictures in my head. Whenever I learn something, it helps me a lot to be able to visualize it and especially kind of systems of interactions, like being able to see them and be able to... interact with them is very helpful. We take our kids these days to, there's a place near us that's like a science exploration center and there's lots of little tables and every table has its own little sciencey experiment thing on it and you can poke it and prod it and play with it and it's like each one of them is showcasing something specific that you can actually play with and see what the inputs and how they affect the outputs and things like that. So that style of learning and thinking has always appealed to me personally. As for why I began doing it on the web, I am hugely influenced by a guy, I'm gonna butcher his name, I'm really sorry about this, but his name is Bartosz Czysznowski. He's done a whole bunch of posts in this style where they are incredibly interactive, incredibly visual. He tends to do... Lots of physics based things. So he's done like mechanical watches and he 3D renders a full mechanical watch and he walks through what every piece of it does. He's done like bicycles. He did a whole post on bicycles and how the wheels contact the floor and how that makes a difference and things. Stuff that I'm not actually like, it's not useful to me, but it's super interesting. The way he presents it makes it such an experience. So I was very inspired by him. And I thought to myself like, What if this but programming? Wouldn't that be cool? And I didn't know the first thing. Like, didn't have any idea what to do, how to build it. I went looking for like, well, how do you draw 2D graphics on the web? Like, that was how clueless I was. I didn't really know what SVGs were. And I actually began doing... Canvas based rendering using a framework called pixie.js, which is normally used for games. That's this is how clueless I was I didn't realize I didn't need like this 500 kilobyte game framework to render two-dimensional graphics But I just waited in anyway, did my best. The code is truly awful. It's posted on my GitHub somewhere. You can go and see it. It's absolutely horrendous, but it kind of made the point that I was trying to make. The first thing that I wrote in this vein was load balancing. And I wanted to show visually how different nodes get balanced between, because I think the different algorithms do have very different distinct visual patterns to them. And despite the code being really terrible, me not knowing what I was doing. It was very successful. People really enjoyed it. It was shared very widely. And that was quite an addictive feeling. That was by far the most recognition I'd ever have for writing something. immediately after doing it, was like, hey, maybe there's something here. Maybe I can do that again and replicate that success. And very fortunately, I have been able to somewhat consistently replicate that. I think I've written nine of these now or something, something like that, maybe ten if you want to include the Angrok stuff, and all of them to some degree have had some level of recognition, so yeah, very very grateful that there is a bit of a niche for this kind of work. Bethany (05:38) Definitely. And well-deserved recognition. They... you really, like, break down these really complex concepts in a way that is so intuitive to and, approachable. So it is so well-deserved. No, no, please. Sam Rose (05:40) Thank you. No, thank you very much. Sorry to interrupt you. I don't think there's a secret to that, by the way. Almost everything that I have written in this style has been as I learn something and construct my own mental models. It is just translating that to the page. this is... I think if you really do invest the time and you really truly understand something and you tinker with it and you verify your understanding, the mental model you end up with should be reasonably accurate, especially if you can recreate it in simulation, which is what I tend to do most of the stuff. will build the simulations under the hood. It's not GIFs or videos or anything like that. It is a full simulation of the thing that is being spoken about. So I have some level of confidence that it's correct. And then from there, you can just hook into the visuals and build, sorry, hook into the simulation. and build visualizations on top. it's a reasonably direct translation of what I see in my head anyway. because it's quite self-contained in how I am thinking, I think it ends up being very consistent and hopefully translates well to other people. Bethany (06:48) Yeah, absolutely. think there's... I found like from people that I know that I consider great engineers, there's such a talent in these mental, in like developing a mental model and relying on that for learning and teaching others. And I think that is such a, such an important skill that isn't often taught or really developed in especially like younger engineers or folks that are moving towards a mentorship position. So I think that's really cool that your blogs focus on. on how you learn and how you see things and then also like using that to build what other people learn and grow in. So that's really awesome. I saw on your site while scrolling that your essays take upwards of one to three months to write, which is crazy, but really cool that you spend so much time investing in this. Can you walk us through what a typical process is for researching and composing the essays? Sam Rose (07:41) Yeah, no, of course. So one to three months is really finger in the air. So before I joined Angrok and I started doing this full time, I never had a good real estimate of how long these things take because they're always evenings, weekends. I'm tired. I am haggard from looking after children and having a full time job. it was very like, it's kind of this long in like calendar time. I couldn't easily estimate you how many hours this was of sat down focusing on it. So the process has changed a lot over time. It's not a tremendously like templated or written down process. In the beginning, there's a lot of learning and this still is, but back then it was like blocked learning. So I didn't know what I was doing at all. So I had to spend time learning how to draw 2D graphics. And then all of my stuff was slow and I didn't know why. So I had to learn like, okay, what in the dev tools can I rely on here to help me? So there's a lot of stop, start blocking stuff going on. And that got better over time. I'm at the point now where I feel quite confident making two dimensional graphics on the web and I have a very different way of doing it now. It's all SVG based web animation API. Like I try and stick as close as I possibly can to web standards. I don't usually react or anything like that. I use web components like directly in the browser. The only thing I use is lit. There's a framework called lit, which is a bit of a wrapper around web components to make them slightly more ergonomic to use because they're a bit clunky out of the box. So the process is now much more streamlined and I start a new post and I have a good idea. Like I build components like this and this works and I don't feel like blocked and anything to make these things. Topic selection is I think like one of the most crucial elements to success. I try and pick topics that... are relevant to you and you don't realize it. And it's not obvious to you that they're relevant to you. So you look back at like load balancing, memory allocation, hashing, even just in this video call between us now, all three of those things are probably happening tons of times under the hood. The thing I'm gonna be writing about next, and I've already started. is post on branch prediction, which is something that your CPU is doing millions of times per second. It is literally predicting the future millions of times per second to try and preload stuff that it may or may not actually end up executing. And this keeps CPUs very, very quick. So you're relying on this for everything that you're doing on your laptop. But you probably don't think about it. I think most people don't. And it's really... Interestingly simple thing that the CPUs do that gives you this incredibly huge speed boost that is invisibly holding things up and it's wonderful. So it's, I think it's kind of crucial to pick something that is like relevant to everyone, but maybe they don't know like, and then they feel good about like, you hook them in at the beginning, which is like your CPU is doing this and you're relying on it. here is how it all works. And then people hopefully come away with this idea of like, wow, I never realized that. That's amazing. And that's what I'm going for. And it's mostly stuff I already knew. somebody posted on, I think, Blue Sky recently about like, what percentage of your blog posts did you know the topic going in advance? And I'm really sorry, I can't remember who it was. But I think I know about something about everything that I write about, not something about everything, but something I think I write about. And By the end of it, I've learned tons of new stuff. it's never like, know start to finish what I'm going to do. It's like, I know roughly that this is a thing. I'm going to probably learn a bunch of new things to write about here, either like new load balancing algorithms or new things about hashing I didn't previously appreciate. So there's always some learning going on, but it's always stuff that I've had an appreciation for myself for a while. Bethany (11:10) That definitely seems to reflect the approachability of the essays is that they are something that most most folks in the industry know something about. But it's like, that's such a genius thread to pull and so meaningful also to have a deeper knowledge of these things that you leverage every day because, well, 99 % of the time, you probably don't need to worry about edge cases. There's always going to be that like, 1 % case you run into during your career. it's helpful to have that specialized knowledge. So that's so cool. It's like how it gets made for programmers. Yeah. Sam Rose (11:43) Yeah, yeah, yeah. Bethany (11:47) So speaking of your going from like your engineering role where you were doing writing in your free time to this role at NCROC where you are educating and doing this as a full-time job, has there been any surprises with shifting from an engineering position to an educator role? Sam Rose (12:05) Yes, and I thought about this a whole bunch beforehand. There's a whole language around, because I sit under marketing now and it's the first time in my career I've not been part of the engineering organization of a company. So there's some things to get used to. One of which is that engineering is like the because... I'm used to having like a roadmap and there's planning and you have sprints and you know, things are planned somewhat far in advance. Being outside of that cycle now, like if I want to interact with engineering or if I have some like wacky idea that I would require some engineering help from getting onto that like planning train is actually kind of hard when you're outside of the organization. And that's not a knock on Angrok or anything like that. Like I can imagine that would be the case basically anywhere I've worked. so that's interesting. Like if I want engineering work done or I want to try and test like a crazy, then it's either I kind of become brave and do it myself and have a look, which I have been tempted to do a couple of times with a couple of ideas that I've had. Or I kind of engage with this process from the outside that I'm used to engaging from the inside. The other thing is like the whole language that I am not familiar with, you know, I remember the first few weeks I joined, various reports and various like dashboards and things, loads of three letter acronyms I'd never seen in my life and KPIs that I am not used to so a lot. of like very fast-paced learning just to get a grasp of what is the language that's being spoken in this section of business that I've never been in before, which was really humbling. I was, I've been in engineering positions for something like 13, 14 years, so and going into this completely new role was incredibly humbling. Other than that, like the pace of it I think is nicer. So there's rarely like There's rarely emergencies. So I'm used to, I've done a lot of roles like SRE style roles and DevOps style roles, like being on call and things like that, where any moment in any day, something could go terribly wrong and you'd have to respond very, very quickly. There's like none of that. that's actually, I hadn't realized how stressful that was just at a base level without anything ever happening. Like the fact that it could happen was just very low level stressful. But now knowing that can't, knowing... Like I will have like dedicated free time and very little is going to interrupt me is so wonderful, especially considering that I'm one of the few people that works at Engrogg in the UK. So there's not many people on my time zone, which has pros and cons. One of the pros is that I know before 3pm on any given day, nobody is going to bother me. So I have this dedicated, wonderful six hour period every single day where I can just focus and do things. The flip side of that being from 3pm onwards is very interrupt heavy because it's like that's the time people can get me so I end up being in meetings quite a lot around that time. Yeah so some surprises, some stuff I was expecting, pretty much all of it though very positive so far. Bethany (14:46) That's awesome. Yeah, that's when you think about it, going from SRE to something like this is very different, but really cool that you've gotten kind of this breadth of experience and it sounded like you knew that you wanted to teach. So it's really cool that you're in a position where you're able to really focus on doing that. That's awesome. Sam Rose (15:05) Teaching has been something I've wanted to try for a while now. From before I began writing these visual blog posts, I've done teaching in lots of different capacities. So for example, like I volunteered with charities that teach kids to code. I volunteered to mentor other people. Like I've mentored several people into career changing into technology and these mentorship relations tend to last years. So like there's been... I think four people that I've had like multi-year relationships with where slowly work towards them switching from their current career into technology. So these like kind of informal, I guess, ways of teaching is something I've been drawn towards for a long time. getting into like a more formal role for teaching has always felt very challenging and challenging in a really privileged way because the problem is like software engineering is very well paid right any teaching job I go into is almost necessarily going to be a huge huge pay cut especially if it was in academia so like it felt inaccessible inaccessible due to the privilege of the current situation which you know is you know world's smallest violin but sure so it's been surreal to land into this situation now where not only am I full time thinking about education and not like, I guess, academic education, but it's still education, the kind of writing for people and helping them learn. It's for roughly what I was earning as a software engineer, which is wonderful. And then also like, it's this very new, interesting, wild. topic that everyone else is currently talking about as well and I get to participate full time and learning it and hopefully trying to get ahead of where the kind of average practitioner is so that I can look back and then try and identify like what do they need to know and like how can I help them. Just I was just talking about this the other day with my wife this feels almost like incomprehensibly lucky where I have ended up very very grateful for it. Bethany (16:54) Yeah, absolutely. It seems very tailored to your experiences and interests, which is always awesome. again, I feel like I'm gassing you up, but it's so well deserved because you do it very well. And I think with LLMs especially, it's been something where almost overnight everyone has to be an expert in at least how to use them, if not like effectively. Sam Rose (17:04) Yeah No, thank you. Bethany (17:18) I think it's so helpful that there's investment in demystifying that for people who might be thrown into this world or expected to leverage LLMs and not know how to do it cheaply, for example, where prompt caching is helpful for that or effectively. So looking forward to more content on that. Sam Rose (17:38) doing a lot of thinking around what is like a practical set of information that people need to know, specifically thinking about like web practitioners who are building with AI, rather than, I think plenty of people have got using AI to get your job done on lock. I don't get, publish a lot of stuff in that vein. So I'm not super interested in competing on that. I think that's being done very well by a lot of different people. I don't think there is as much out there for the practitioner building with AI. There's definitely stuff out there, but I think it's an area in which we can make a meaningful difference. Bethany (18:11) Completely agree and it's something where folks are getting starting to dip their toes in and then you have that in for really reaching out and giving them that. So pivoting a little, you not only write on technology, but you've also written a decent amount on your family and personal experiences and wrote a detailed blog post on your son's max autism diagnosis journey. What made you decide to write about something? so personal publicly and what response did you get for writing that either from the developer community or other communities that you might have not been expecting? Sam Rose (18:45) So that was my wife. She is tremendously supportive, not just in my career, but also of my experience as a dad in this somewhat unusual situation that we find ourselves in. So we have two autistic boys. I've written about the diagnosis for one of them, but not the other one, because the other one was much easier to get diagnosed after his brother had been diagnosed. I hope he understands that when he's old enough to realize that there's only one of these posts. My wife really urged me to write, and she continues to urge me to write more about my experiences in this area, because not many people do. Men especially, like, not great at attacking the emotional side of things and really coming to terms with it and... So we've had quite a lot of trauma in that regard around very traumatic births, very, very challenging children growing up, very difficult decisions we had to make. So like we moved across the country, for example, to get the kids better support with school. a lot of stuff that I, I don't know, you do what you have to do. Like I don't, none of it felt like. huge sacrifice, it was like just the stuff that we had to do to get the best that we could get for our boys. But yeah, she pushed me to write about these things. It was also a good exercise in like really chronicling what that process looked like for us because it's very different to how that process looked 10 years ago and I think it's going to be very different to how that process looks 10 years from now. Like the kind of diagnosis guidelines for autism have changed a lot and will probably change a lot more and a lot of kind of like political aspects, lot of political pressures on diagnosing more and then diagnosing less for different good and bad reasons. Like it's a really fluctuating world that not many people are aware of. So that was the main motivation for that. Just share these opinions. The secondary effects of it is it's helped me connect with people that have had similar experiences, which it's one of the reasons I write all of the stuff that I write. So like writing technological stuff and personal stuff is I'd love to meet more people that have had these similar experiences or make similar stuff or interested in similar topics to me. I've actually made several really good friends now that I've ended up of meeting up with in real life just through having very similar parenting challenges and it's good to be able to, I don't know. you kind of release steam when you both have the same problem and you both know like there is no real solution to this like you've got very challenging kids and they're going to continue being challenging there's no like click your fingers and everything gets better but having someone who understands that and has been through very similar stuff is I would say necessary really to kind of keep it all together Bethany (21:14) Absolutely. It sounds so isolating to go through that experience, especially with a child that's younger than the typical diagnosis age and also during the pandemic that is, must have been a doubly isolating challenge. So it's so great to see you put that information out there in your experience out there. So maybe one less person or more, multiple less people feel alone in that experience. you Sam Rose (21:40) The pandemic was bad. We had our second child during the pandemic. so I won't go too much into the details. I have actually written about that. I have a post called having a baby and it kind of details the birth traumas we went through. But the, we were in hospital for several days, but during the pandemic, like I wasn't allowed to stay. Like I wasn't allowed in the ambulance to go with my wife. I wasn't allowed to stay longer than four hours. So there's lots of like really extra challenging things on top of the normal challenges of going through traumatic births and then. the isolation of like not having help as well. So having to shelter at home, having to be on lockdown. Like there were, I remember very vividly this one week where you have kids, kids get sick, you get sick. It's just what happens. Everyone has the illnesses and it's never ending. But during the pandemic, you're in lockdown, you've been home for weeks anyway, everyone is ill at the same time. Just there like, this is miserable. This is the worst. So we had a pretty rough lockdown. I'm very, very glad that we're mostly past all that stuff now. And as the kids have gotten older, it's gotten easier as well. Back then, they were like a baby and a two year old and they didn't want to be indoors all the time. They hated it as much as we did. So it was something we had to persevere through. It was not a fun experience. Bethany (22:52) Absolutely, that is definitely understandable and echoing glad we are mostly out of that as well. In your article, you had mentioned that Max has no difficulty learning. The way he learns is just different. I'm curious if that influenced how you thought about teaching, especially in your essays or articles, if any of that has influence on the work you do now and making sure it's as accessible to as many people as possible. Sam Rose (23:20) It kind of hasn't. So this is one of the ones I was thinking like, maybe I should have a different answer to this. Maybe I should have been thinking about this more deeply, but the honest answer is not really. So to give some examples of like how he learns differently. So I don't have any neurotypical children, so I don't really know like what, how like kids typically learn, but there was this incredible moment just a year or so ago where... Our eldest Max has always been really great with numbers, very kind of almost stereotypically good at numbers. He can sum numbers like two, three digit numbers. He's great as a five year old. And we had been doing a lot of like countdowns with him. So to help him transition to new activities, we say, going in the car in 10 and they do nine, eight, seven, and it just helps him get ready for it. And we do it bedtime as well, so bedtime in 10, nine, and then we go upstairs, we go to bedtime. And his normal bedtime's like 8 p.m., so they go to bed fairly late, but they don't sleep fairly late, but they sleep very consistently, which is a saving grace. So bedtime at eight normally, and I said to him, bedtime in 10. And he kind of turned around, he looked in a different direction, and then he said, like, bedtime in 24 minutes. And I was like, at no point have I taught you how to tell the time, at no point have I explained to you that that on the microwave that you just looked at is a clock. He's like, figured this stuff out, and he was correct. It was 24 minutes to eight. just from nowhere, he revealed that he could tell the time. And he was... Not just that, but he was like sassing me with it. He was like, whoa, it's not it's not 10 minutes away. It's 24 minutes away here, buddy. So that was just a weird and wonderful thing where like there was as far as I know, really not a huge amount of input. Like we'd not really address time as an idea. And he somehow figured it out and learned. don't know if it was from school or from stuff he'd seen. So he seems like he has this incredible capacity for learning and Like what I wrote in the article that you've picked out. I think I think I'm incorrect actually to say that he has no difficulty learning. I think there are some difficulties, but his difficulties are mostly based on his motivations. So he has what's called a pathological demand avoidance profile, which is basically doesn't want to do anything that you want him to do. Unless he wants to do it, he doesn't want to do it. Not just like in the normal kid way, like kids don't want to do stuff. That's reasonably expected, but this is like extreme demand avoidance. So I think he, if he wants to do something, wants to figure something out, like he really figures it out quick and he will learn very, very quickly. But then if you want to try and teach him, like he's not toilet trained yet, for example. So like we're into our like third year of toilet training and the look of horror I get from other parents when I say that is very funny. But he has no motivation. Like to him, it's like a downgrade, I think. He's like, I'm happy with the current situation. I don't want to go to this strange room that smells weird. So his motivation, I think, of stands in the way of some of his learning. So it's not that there's no difficulties, but it's just anything he's motivated towards is incredibly capable. Brittany Ellich (26:18) Yeah, that makes a lot of sense. I fear the day when my oldest actually learns how to tell time because that's like the one thing we got going for us now. I'm like, you're pretty tired. You're not going to admit that you're tired, but I know you're tired. So we're going to do an early bedtime, but I don't have to tell her that it's early because she doesn't know yet. And that is, yeah, that is great. Wow. Thank you so much for sharing all that. That's awesome. I have found connecting with other parents in tech, especially parents that have been going through these crazy several years we've had where, I don't know, maybe it's just my kids are four and two and they're, so I had kids during the pandemic and I don't think we had quite as isolationist of a time as y'all did in the UK, but it was a very weird time to become a parent and since then it has become. a very weird time. So it's really nice to connect with other parents in tech that are doing this very demanding mentally taxing job and, you know, raising humans at the same time, which is hard to do. So, yeah, thank you for connecting. And I think you're really right that there's not enough, particularly dads out there that are sharing that journey and how incredibly emotional it is. So that's really, that's wonderful. I would love to talk a little bit about your journey building in public, if you would like to switch gears a little bit here. You do a really fantastic job on Blue Sky of sharing your process as you're creating things. And I'm not sure if you share on other platforms as well. That's the one that I typically am on as well. And I really appreciate how you go about doing that. One of the things that you recently shared on the Write That blog, newsletter, I think it is. It's online, says a blog and a newsletter. But you've gone from blogging just to get a job to like having a job title now that's all about creating content. And I'm curious, like, how has your writing evolved since, you you started blogging in what, 2011 to now? I think a lot of people recommend like go write stuff online so that you can get recognized to get a job. Now you have a job. Sam Rose (28:18) Mm. Brittany Ellich (28:24) and you're still writing. So how is this, how has it evolved over time? Sam Rose (28:28) Excuse me. I actually write that blog as this wonderful initiative by Cynthia Dunlop and Peter Sana. Sana, yes. To get people like more like into blogging and things like that. And I was very kind of grateful to be included as somebody who's blogging and they kind of asked me a bunch of questions and published those questions and the people that... that they asked and I'm like, why am I in here? This is weird. So I went back as an exercise while I was writing that set of interview questions to look at some of my old writing and it's really bad. It's really terrible. There's like weird emojis everywhere. There's pop culture references that no one's gonna really get. Stuff that I found funny that isn't really that funny. I made a pact with myself a long time ago. to never delete anything though. Like it's like, that's who you were at that time. Like you have to own it. You you can't just pretend now that you're, you're writing to a larger audience and you feel a lot more comfortable with writing. You can't pretend that you didn't come from like this weird cringe early twenties, 2011 that you're in. So it's changed a lot. I think maybe the one of the most conscious changes I made was to, to be a lot more, Respectful of the readers time so I am very surgical about my writing to to a point where I think some people Begin to feel that it's a little bit I know not dry, but like there's not a huge amount of humor and there's not a huge amount of What's the word I'm looking for here like personality I guess but but the the whole idea is like how can I express this? in the clearest and most concise way that I possibly can. my, each one of my posts, nobody has read my posts more than I have. Every single one of them, I read dozens and dozens and dozens of times and I, every single word is put under extreme scrutiny. Like, do you need to be here? Like, can I replace you with something simpler or to get rid of you entirely? I care about that a lot and I care, like, it's one of those things that I think... If you're not really thinking about it and you're not really bothered, you probably wouldn't notice. Like you'd read through the post and it just wouldn't register. But the benefit is that you're not annoyed by it. I try and annoy the reader as little as possible. So just little things like... Don't you hate it when you're on your phone and you're scrolling a website and then your thumb hits like an internal scrolling element and you stop scrolling the main page and I have scrolling this tiny little element. I'm like, that's really annoying. Like did the person not scroll through this when they were like writing it? So like little things like that. Like the golden rule is don't annoy the reader. And part of that is like, don't say 25 words if you can do it in 15. Like it's, you know, cut down as aggressively as possible. So that's the main. conscious change that I have made. Other than that, think in the years since 2011, I've just become more mature, more switched on and aware of other people. you know, as a early 20s white guy, I was, you know, very confident in myself to a degree that was not warranted. And I think that reflects in my writing. So I think I've just mellowed out a whole bunch, become a lot more of a well-rounded human being. And hopefully that kind of comes through in the writing, right? In the writing as well. Brittany Ellich (31:29) Yeah, I can definitely tell that care that you take to just your entire website is wonderful. And it's a great example of like little Easter eggs. I think that's when I first saw you online as you were sharing like, Ooh, can you find the Easter eggs on my site? And I was like, Oh my gosh, I want to go see. So we'll definitely link it for folks to go check that out as well. What is, yeah. What is your, Sam Rose (31:42) Hehehe No, thank you. Brittany Ellich (31:53) feedback process look like. So I know you post things online and I actually got to read a little bit of your stuff as well for this most recent article. So thank you. What does that process look like? Are you reaching out to a lot of folks? Are you mostly going with like posting publicly and getting feedback or what does that look like typically? Sam Rose (32:01) Hmm. This is another thing that's changed lot over the years. Anything pre-2023 was, I wrote it and published it. Nobody was reading it so I didn't care. Then as time has gone on with the more visual stuff, as I was learning that, load balancing, the first one that I wrote, I got a bunch of help from some colleagues at the time who were much more experienced at front-end than I was. I was like, have no idea what I'm doing. Why is my mobile phone really hot now, now that I'm scrolling through this thing? So I got a ton of help from really generous friends who I was working with. More recently, I have been trying to formalize this a little bit more where... I will try and recruit people to let me watch them read my post, which sounds real weird. And like, I try and, um, diffuse this beforehand. So like, you know, we dial into the call together and it's like, look, this is kind of strange, but what's going to happen if you're okay with it is I'm going to turn off my video, turn off my microphone. I'm still here taking notes. If you could share your screen with me, um, and read the post as you kind of normally would, which I realize is impossible because I'm sat here watching you, but like try your best. And then people can either like vocalize as they go along or I try and encourage them not to ask questions like People will ask like like what does this mean here? And it's like I kind of can't tell you because I want you like go through as if I wasn't here So but it's good to identify like that that's confusing and that needs changing I mean you to smooth that over I think of it like I'm Like combing like every single pass with the comb you make things a little bit better and you smooth things out a little bit more So I tend to do like one or two people and get the initial like confusion points and try and like unknot those and get those out. And then I do a couple more people and a couple more. I don't I've never done more than three rounds of this. Like by the third round, normally I'm sick of it. And I'm like, I just want to publish this thing and get onto the next one now because I read it too many times. So that's really valuable, though. Like the act of watching someone read something you've written. It's like that that TikTok. It was Alison Burke. user experience person like putting the wrong shapes into the wrong holes. It feels a little bit like that you're watching someone read your post and they'll scroll straight past something like interacting with it and you're like no what are you doing? It's very revealing and very humbling as well because I think it's very easy to write your own thing and you go through it you're like, wow, this is great. Like this works perfectly. That's amazing. And then someone else just skips over and doesn't interact with it. And you're like, why don't they tap on the thing? It's obvious. But it's not obvious, right? Like it's something you trick yourself into because you're fully aware of it. So yeah, I've tried to more formal, tried to really engage with people very directly and watch them engaging with the content to try and get rid of bugs and things that don't work. And that's been super useful. Other than that I have a few kind of close friends who I rely on for different stuff. So I have one guy who I know absolutely with confidence will tell me when something sucks. He's a very very good friend and we both know each other for incredibly long time. And then I have another friend who's very great with visual design so when I'm not sure something looks quite right I know I can ask him like how do I make this look better and he's always got really good suggestions. So I do have some some more like specialized people that I ask for help. But it's kind of haphazard, like no more than like 10 people will have seen it before it gets published, which I'm kind of downplaying that. It's probably a lot more than like the average blog post, but I almost feel like it's a, it is its own like product almost, like the prompt caching post had like 12,000 lines of code in it, for example. Like it's a little product that I'm releasing here. It does kind of feel like it should be QA'd by more people, but 10 or so. for the more recent posts and then fewer as you go further back. So yeah, I'm trying to be more on the ball with feedback. Bethany (35:46) That is so cool. And really interesting bringing that research perspective to writing, which in a way, books get test read and sent to pre-readers and things like that for editing. And it makes sense to do the same for blog posts that have a lot of content in them and that are very interactive. So what a cool way to go about that. Sam Rose (36:09) I completely agree and I have been that pre-reader so I was one of the technical reviewers for the Pragmatic Bookshelf for 15 years or so. Quite a few of those books behind me are Pragmatic Bookshelf books that I got sent for free for reviewing them. So I'm somewhat aware of this editorial process and it makes a huge difference. It's hard. I have very thin skin and I struggle with criticism. and every single time I remember a very specific call I had of feedback from someone and this person did not like the post whatsoever and they were not shy about telling me and it was really awful. felt horrible the whole time. At the end, this person had finished reading my post, I had to apologize. I'm really sorry. I'm sorry that that was such an awful experience for you. Let's talk about it see how we can make it better. But it's really horrible when someone, you know, has so much to struggle or has a lot of very critical feedback. I find it very difficult. So it's something I have to go in and psych myself up for being like, this person's on my side. They're not trying to cut me down, but we're going to make this better. and it's gonna be all good. Yeah. Bethany (37:12) Absolutely. Okay, we are coming up at time, but beforehand we've got our fun segment. So I'm so excited. I saw on your main webpage that you do the New York Times games with your wife. And I decided to run with this and I made a connections, well, I say I, I had an AI make a connections game based on your prompt caching. Sam Rose (37:28) You Bethany (37:40) article and I haven't even read the the thing so I'm doing it live too, but Yeah, I thought we'd maybe do it together and see see if we can get through this Sam Rose (37:41) Wow. boy. Bethany (37:52) Sweet. All right, and A-R-K to bring up the article to do that. But all right, so I'll go ahead and read out the ⁓ grid. Our words are vector, output, query, softmax, weights, transpose, transformer, dimension, position, mask, multiply, key, tokenizer, embedding. semantic value. Sam Rose (38:23) Okay, I have a group, I think. I think output, tokenizer, embedding, and transformer is a group. Bethany (38:24) All right. Okay, okay. All right, let's see. It is! Okay, those are LLM architecture stages. We got the yellow. Sam Rose (38:39) Okay. Brittany Ellich (38:41) Amazing. I actually, that was my first guess too, and I was like picturing it from your article. I'm like, I've seen this visual. So thank you. It stuck. Bethany (38:50) Okay, ⁓ Sam Rose (38:53) think I have another one. ⁓ Softmax, transpose, multiply, and mask. Bethany (38:54) Ooh, yes. Okay, I was just going to ask that seemed to be like ⁓ operations that happen on the matrices, Matrix operations and attention. Ooh, got the green. that was the I think green is the easiest, right? Sam Rose (39:07) Hmm. Yes. Brittany Ellich (39:17) All I know is purple is hard. Bethany (39:20) Yeah. Sam Rose (39:20) Same, yep. Bethany (39:21) Okay. ⁓ I feel like... ⁓ Yes! Sam Rose (39:27) okay, I think I have the last two. But I'm gonna pause, I'm gonna let you try. Bethany (39:32) ⁓ okay. I feel like weights, query, dimension and value seem kind of, are kind of reflecting this related. ⁓ Sam Rose (39:47) think that's one off. I think you've got three of a group there and then one miscreant. Bethany (39:54) Okay, Brittany, do you have any thoughts? Brittany Ellich (39:57) I was thinking that key value position and vector would go together. Bethany (40:01) ⁓ Brittany Ellich (40:01) but maybe not. I'm very bad at connections too, so. Bethany (40:05) Yeah. What? Sam Rose (40:06) I don't think that's a groove. I could be wrong. Bethany (40:08) All right, all right. ⁓ Okay, so query weights, we did this, so one off. Sam Rose (40:14) The group I would go with, it's worth trying that and seeing if it is a group, I guess. Bethany (40:20) No, it is one away though, you're right. Sam Rose (40:20) one away, I thought so. ⁓ If you get rid of dimension and put key in there, is that the group? Bethany (40:26) it is attention mechanism matrices. All right, and that was our purple. Sam Rose (40:34) I... what is this last one? Semantic is kind of throwing me off. Bethany (40:39) no, this was the purple. we had multiple purples. Oops. Describe embeddings. Sam Rose (40:41) ⁓ that's really clever. Did you say an LLM came up with this? Bethany (40:46) Yeah Claude, gave it your article and I was like, come up with the connections and I was like, I'm not going to see it beforehand. Sam Rose (40:54) This is genuinely really good. That was amazing, thank you. Bethany (40:58) Yeah! Alrighty! No, that was fun! I'm glad we had an expert on because I don't think I would have gotten that myself without combing through the article an additional five times, so... Sam Rose (41:14) Imagine if I didn't get it. That'd be really embarrassing. Bethany (41:16) Hahaha Brittany Ellich (41:17) That's true. That would be pretty sad, I guess. Sam Rose (41:19) Yeah Bethany (41:20) man, highly recommend. Anyone read the article and then try it yourself. Forget what you heard and then give it a shot and yeah, let us know what you think. Awesome! Well, that is all the time we have today. Where can folks find you, Sam? Sam Rose (41:36) So I am actually on X as well, so on X I'm on Blue Sky. It's all linked from samhu.dev, my personal website. Bethany (41:43) Awesome. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye! --- ## Episode 45: Sustainability in Software Development: Robby Russell on Tech Debt and Engineering Culture - URL: https://overcommitted.dev/sustainability-in-software-development-robby-russell-on-tech-debt-and-engineering-culture - Published: 2026-02-03 - Audio: https://anchor.fm/s/102586d64/podcast/play/114462795/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-0-23%2F416716539-44100-2-b949bd6c25ddc.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Brittany, Bethany, and Erika dive deep into the realities of software development with guest Robby Russell. They explore the critical challenges of maintaining legacy code and managing technical debt, emphasizing the impact on programmer productivity and long-term sustainability of software projects. Robby shares his extensive experience, including his journey creating Oh My ZSH, highlighting the importance of documentation, testing, and fostering a collaborative engineering culture. The discussion also covers balancing personal and professional commitments, an essential aspect of career growth in tech. Listeners will gain practical insights into navigating software engineering challenges while sustaining work-life balance. The episode wraps up with a fun segment on current tech obsessions from all participants. Links * Planet Argon: https://www.planetargon.com/ [https://www.planetargon.com/]  * Oh My Zsh: https://ohmyz.sh/ [https://ohmyz.sh/]  * Maintainable Podcast: https://maintainable.fm/ [https://maintainable.fm/] * On Rails Podcast: https://onrails.buzzsprout.com/ [https://onrails.buzzsprout.com/]  * Robby’s Blog: https://robbyonrails.com/ [https://robbyonrails.com/]  * Robby’s Band: https://mightymissoula.com/ [https://mightymissoula.com/]  * Commit Goods Store: commitgoods.com [http://commitgoods.com] * d’Oh My Zsh: https://medium.com/free-code-camp/d-oh-my-zsh-af99ca54212c [https://medium.com/free-code-camp/d-oh-my-zsh-af99ca54212c]  * Stop Pretending You’re the Last Developer: https://robbyonrails.com/articles/2025/07/16/stop-pretending-youre-the-last-developer/ [https://robbyonrails.com/articles/2025/07/16/stop-pretending-youre-the-last-developer/]  * Internal Tooling Maturity Ladder: https://robbyonrails.com/articles/2025/08/13/internal-tooling-maturity-ladder/ [https://robbyonrails.com/articles/2025/08/13/internal-tooling-maturity-ladder/] * Diataxis: https://diataxis.fr/ Hosts * Overcommitted: https://overcommitted.dev * Bethany Janos: https://github.com/bethanyj28 * Brittany Ellich: https://brittanyellich.com * Erika Eggemeyer: https://github.com/eggyhead ### Transcript No transcript available for this episode. --- ## Episode 44: AI, Burnout, and the Myth of the 10x Developer: Addressing Burnout in Software Engineering - URL: https://overcommitted.dev/ai-burnout-and-the-myth-of-the-10x-developer-addressing-burnout-in-software-engineering - Published: 2026-01-27 - Audio: https://anchor.fm/s/102586d64/podcast/play/114462450/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-0-23%2F416716030-44100-2-703299966de37.mp3 ### Show notes Summary In this insightful episode of the Overcommitted Podcast, hosts Erika, Bethany, and Brittany tackle the critical issue of burnout in software projects and software engineering, especially amid the surge of AI advancements and remote work. They dive into how the evolving programming landscape affects programmer productivity and well-being, highlighting alarming statistics that show 66% of tech workers struggling with burnout symptoms. The conversation sheds light on the balance required between ambitious career growth in tech careers and maintaining work life balance through clear communication and strong boundaries. They discuss how AI influences software development and collaboration while emphasizing the importance of psychological safety within engineering culture to prevent burnout. Listeners will gain valuable insights into managing the pressures of tech work, recognizing when to push back against unrealistic expectations, and sustaining passion in programming careers. The episode closes with a fun segment featuring bold predictions about the future of software engineering, reflecting the hosts' camaraderie and forward-thinking outlook. Takeaways * 66% of tech workers report burnout symptoms * Burnout arises from work pressures and intrinsic factors like job insecurity * Setting boundaries and effective communication are crucial for preventing burnout Tune in for an honest, relatable discussion about navigating software development challenges and fostering a healthy engineering culture. Links * Context > Prompt: https://ruben.substack.com/p/context-is-all-you-need?triedRedirect=true [https://ruben.substack.com/p/context-is-all-you-need?triedRedirect=true]  * Psychological safety episode: https://overcommitted.dev/imposter-syndrome-in-software-engineering/ [https://overcommitted.dev/imposter-syndrome-in-software-engineering/]  * Glue work article by Tanya Reilly: https://www.noidea.dog/glue [https://www.noidea.dog/glue]  * Gas Town article: https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 [https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04] * How they use Claude Code article: https://blog.sivaramp.com/blog/how-creator-of-claude-code-uses-claude-code/ [https://blog.sivaramp.com/blog/how-creator-of-claude-code-uses-claude-code/]  Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Erika Eggemeyer: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:01) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Erika, and I'm joined by... Bethany (00:10) Hey, I'm Bethany. Brittany Ellich (00:12) and I'm Brittany Ellich. Erika (00:13) The three of us met working on a team at GitHub and quickly realized we are all obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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 opening up about what may be contributing to a sense of burnout and how we can balance our ambitions with the pressures of 10x development and an always on working According to the numbers, our industry is facing a paradox. The opportunity to work from home and use AI assistance promise increased productivity and work-life balance, but data reported by Lead Dove reveals that 66 % of tech workers report experiencing symptoms of burnout, with the staggering 22 % facing critical levels, a figure that now exceeds even the height of the COVID-19 pandemic. For our discussion, we'll define burnout as a state of exhaustion, cynicism, and reduced efficiency caused by prolonged stressors, including work pressures and intrinsic factors such as mental stress or job insecurity. So let's start with, do you feel like you're facing some level of burnout? And if so, what are some of the major contributing factors? Bethany (01:48) For me personally, I don't think I'm facing burnout. think, like... On my team, I've been able to strike a good balance of having like times where I'm pushing and then times where I'm like more reclaiming that energy. And I feel like I've been able to communicate that a lot better. But I have definitely encountered like burnout conditions previously in my career. And I think it's taken a lot of confidence and having to get over a lot of that imposter syndrome to have that ability to say no, to push back and say, okay, I've done my pushing. I'm like, now I'm going to take it easy for a bit and reclaim energy because I mean, that's such, it's like how you get a good ergonomic keyboard for your wrists and to protect your wrists. Like you also have to protect your brain too and protect your sanity. Erika (02:41) So it sounds like you've experienced burnout in the past, but at this current moment, you're not feeling a burnout. Brittany Ellich (02:41) I love that so much. Bethany (02:49) Yeah, definitely, definitely. Erika (02:51) Well, that's good. can help inform some of those things that you do that you've learned that can help prevent burnout for others. What about you, Brittany? Brittany Ellich (03:04) Yeah, I guess it's kind of hard to say exactly. I think that I might be approaching and flirting with burnout occasionally and trying to really recognize, all right, when does my mental health need a break and stuff and trying to take those breaks. And I think that most of the contributing factors there are factors that I put upon myself more so than ones that are coming from work. because I have a lot of things that I want to do and I get really excited about doing those things and then I have too many things happening at once. I think at work, there's definitely some stressors. mean, there's like a constant fear of, you know, layoffs or, you know, things changing massively at work that are part of the reason why I do a lot of different things. So I think that like the... don't if it's necessarily peer pressure at work, like the, you know, the fear of that, I'm like, oh, okay, I should be doing more stuff so that, you know, if layoffs do come around, hopefully I'm not considered because I can add all this extra value to the company. So like that's a contributing factor that's at work, but not necessarily like directly related to my exact job. Um, my current manager, uh, one of the reasons why I will stay with the team that I'm on for as long as I possibly can is like, she's just incredible and really good about. I'm like, okay, but how are you doing? Are you okay? And I really, really appreciate that. And yeah, she's one of the best managers I've had. think that that helps a ton. But also like just like the world right now is crazy. And so like, I feel like I'm experiencing burnout from just like, my God, the news, the news that is happening is just so much. ⁓ Bethany (04:46) such a valid point, yeah. Erika (04:49) Yeah, yeah, I mean, it's definitely true that there's like things that we can do and like control and help, but there's also things that are outside of our control that are these contributing factors and can kind of take you over the edge. If you're at that kind of like level of stress that feels like somewhat manageable and then something happens that like pushes you over the edge. I definitely, I'm with you. I feel like I kind of go in and out of that state of feeling close to burnout. Like the big indicator for me is the reduced efficiency. I've definitely had those days where I like sit down and I feel like I go through the whole day and I get nothing done because I can't find the motivation. And like that's usually a sign to me that something's not quite right because usually like in my current moment I feel motivated. I like feel like I can... I can approach the start of the day and like, you know, take on the work and like actually get it done. But yeah, I think you're talking about kind of the human factor and like having people check in with you and like, yeah, I do definitely feel like that's a big factor for me of like feeling safe and feeling like I have people who care about me. Yeah, like it's it's almost never really about the work for me. Like I, I don't, I don't care as much like what specific tasks I'm doing. Like certain things definitely do energize me more than others. Like a lot of the like managerial stuff does not excite me as much, but Yeah, really I feel like it's the connection and feeling like I'm valued, whether that's me telling myself, like, this is valuable. Like the work that you're doing is, you know, having a good impact or somebody else telling me that, yeah, I'm valued and I'm doing good work. Yeah, well, according again to the data and some industry trends, and none of us mentioned this in what we have cited as maybe indicators or contributors to our burnout, but maybe it's because it wasn't top of mind and this is kind of new that evaluating the impact of AI on the effects of burnout and the experience of burnout, there have been causal links found. And, you know, last year, a lot of these studies happened of like, is AI making us more effective? And some of this pressure for that, we've heard like the 10x developer come from this idea that hey, now that we have AI assistance, we can be 10 times more productive. And a lot of those studies have not really proved that out. So there's a group called Model Evaluation and Threat Research, which is a nonprofit dedicated to evaluating AI models and helping us evaluate their capabilities and risks. they found that in rigorous trials, a lot of these with experienced expert open source developers using AI for complex tasks took actually 19 % longer than those who worked without them. And other studies have found from various security groups that Since AI models are trained on historical data, they often reproduce outdated patterns or vulnerabilities. studies have found that up to 30 % of AI-generated snippets contain security issues like SQL injection or cross-site scripting, which were previously considered solve problems in most modern frameworks. So as we know, AI is not magic. and requires thoughtful context management and code review to use well in software projects. So I guess, first of all, does any of this kind of ring true to some of your own experience? Has AI kind of shifted the way that you approach your work as far as creating code versus mastering context? Brittany Ellich (09:24) Yeah, I think that this does make a lot of sense. I've noticed recently that there's sort of a divide in AI tools that are out there where there's like the synchronous tools like code completions and chat, I guess is pretty synchronous because you're asking questions and getting stuff back. And then there's the asynchronous tools that are like the agents where you're delegating tasks to them. And I feel like the synchronous tools were really easy to adopt and didn't have a huge learning curve because there were already a ton of things like it was repeating. existing patterns, know, like resharper existed for a long time, which also had that like tab thing or whatever. So there wasn't, there wasn't like a huge learning curve to take them on. But now as I'm trying to find, you know, pursue the 10x developer myth, which I think is definitely a myth. Cause that even the idea of being 10 times more productive gives me anxiety. But, As I'm doing that, I'm realizing like there's actually a huge learning curve to learning how to delegate those things out. And so it makes sense that it takes longer to do a lot of those things, because I think it's really easy to like use AI tools, but to use them well is really, it takes a lot of time investment to get to the point where like, you you've asked yourself, could this be done with AI or not? Enough times that you, you you know what the limitations are and what the... you what is faster if you do it yourself versus what's faster if you give it to AI and yeah, all the context switching that goes along with it, which is also, you know, problematic and hard to get through. So yeah, I could say that that... It brings true for sure. I'm sure at some point we'll get to the point where things it does actually make people faster. And I think in certain contexts, things like code completions almost certainly make people faster because it's not there's not a learning curve to it. feel like as there is compared to like other tools, but Yeah, as many things, it depends. My favorite answer. Bethany (11:09) Yeah, it really does though. I agree completely. I think it's a shift in how we've traditionally worked. I think with things taking longer, it certainly does while you're learning how to use things. But I think another thing I'm encountering is just like... having a disconnect from what code is actually being produced because I'm not necessarily the one typing it or coming up with the idea or like going forward from there. And so I think that's really the toughest part for me. And I'm very interested with like, I think they're Anthropic recently said that cloud code is 100 % just they use a agentic like cloud. quad code to build quad code. And that fascinates me so much because it's just tough to feel engaged when you're saying, okay, generate this, generate this, generate this. not like you're reviewing the code, but it's, there's still like that, that disconnect. And I think that's the piece that I'm really trying to like rediscover as like part of learning this tool set, because it's so hard to be like, I mean, we're We're engineers, we signed up to solve problems and it's hard when you're not necessarily the one solving the problem anymore. You're just delegating it to something else to solve that problem. And I'm sure that's like been a historical issue, like managers probably encounter the same thing, but they're solving problems in different respects. it's definitely an interesting space right now. Brittany Ellich (12:42) It definitely does feel like almost like a managerial role that you step into because you're delegating all of these tasks out. I think it's also interesting because it's sort of changed the way that code review happens because like when I review a code from my colleague, I'm like, I know that you've like been testing this along the way. You know how this works. Like I'm going to read it, but I'm not going to like go in and like be upset about different stylistic choices that you've made. Like if things work and there's nothing like egregious about it, I'll probably approve it. But like I have to have a much. deeper level of review when it's completely generated by AI, because it's still attached to my name. It's still the code that I wrote, quote unquote, and I'm responsible for. But did it test it as I went along like I would if I wrote it myself. And so there's definitely more cognitive load associated with the review, I think, than there would be otherwise. Erika (13:33) Yeah, yeah, I think we haven't had this experience, but I've been reading about people who have gotten code reviews or like PR review requests and the person who wrote it takes very little responsibility for the quality of the code. And, you know, I mean, that's kind of a human problem, not really like an AI problem. You're like, well, would that have changed if they had written the code themselves? or not but yeah it's definitely something to watch out for and even in your own like you can't control what other other people do but you know in your own PRs like taking that same approach of like looking at it almost as an outsider because I guess you kind of are right like you are reviewing the code that got written and Yeah, like going through it with a microscope and recognizing that still does take. like you said, a good amount of cognitive load to do that. Like peer reviews are not free. They're not easy necessarily. You're using all the same muscles that you would if you were writing the code. And it can actually take longer, which might be where this, you know, 19 % decrease in productivity comes. Like it is that ramp up factor of learning how to use the tools effectively, but then also there's the idea that it can take longer to read code and understand it than to write it yourself. So yeah, I'm with you. The 10x developer myth, mean... Yeah, probably like amount of code that's created can be 10x, but the amount of that that actually gets merged and doesn't have to get reworks or churns, I have never come anywhere near that. At least for production code, know, vibe coding or like Greenfield hackathon projects is one thing, but for production code, definitely not. And yeah, this idea of context mastery too, know, context mastery and then like the sort of context management. It's, yeah, it's an interesting, again, mindset shift and something that like I feel like would be interesting to kind of like measure for myself. Like... how long it feels like it takes me to master some set of context. And then also like share that with some kind of generating model. And yeah, I guess I haven't really found that... I guess that point where I feel like the context that I'm giving to the model really meaningfully changed the output that I get. But I know, Brittany, you've been doing some testing with benchmarking your code. And Bethany, I'm guessing you've done some of this with Copilot too, of benchmarking. results compared with different inputs. So you might you both probably have more experience with this than I do. Bethany (17:00) Before going on, I'm curious how you define context mastery, ⁓ especially in today's world or whatnot. Is it just knowing the context or is it truly having a large handle on it? Erika (17:05) Yeah. Yeah, I mean, it's a good question. And it also has two meanings where it's like my personal context or like my personal understanding and then the like context that I give to the AI. But like the probably the meeting, the meeting point is like, I feel like I have mastery of context when I can explain it to somebody. And that's probably also the point when I can tell an AI what to do. Brittany Ellich (17:48) Gotcha. That makes sense. think that there is, there was a article that I read the other day that talked about like how prompt engineering is no longer a thing and now it's all about context. Like if you give it enough context, then it's going to be good enough to get the thing done. I can't say that I've spent a ton of time like really trying to optimize for prompt engineering or for context. I always go by the the vibe basically, this is vibe coding, but not actually like the term vibe coding. I'm like the vibe of like, if I gave this to somebody who was brand new to the code base, is this enough information for them to do the thing that I want them to do? And that's always been enough for me to like get pretty decent results. Sometimes I realize like the things that typically goes wrong is, you know, I skipped something that was important or I gave it too much at once. But. Typically like thinking like, all right, this person is brand new to the code base. If I were writing this for like an intern or somebody brand new on our team or something like how, what would I need to provide? And that almost ends up being enough. I can't say that I've done a ton of like testing or, you know, tweaking of that over time, other than like just doing it and figuring out what's too big and what's too little. Bethany (19:02) Yeah, I think for me, it's really been about having a plan step in there. it's really about being explicit with what you want and like Brittany and Erica, you're saying providing the correct context and patterns that you want it to follow. And so I find it valuable to always take that extra time to have it plan what it's doing because I... I have not enough patience to prompt engineer and describe it in the way that it needs. And models change so frequently that I think it's impossible to keep up with that standard. And so I think largely having it do its own planning and then being the reviewer for that has made it a little easier to kind of guide it to what I want. But I still... feel like there is always some level of reworking you have to do at the end. Unless it's like super tiny slice of work, it's like rare that it gets it right the first try. Erika (20:01) That's good. Thanks for sharing some good tips. Well, great. Let's shift the conversation to some ideas of boundaries. Bethany, you of mentioned this at the beginning of setting boundaries as something that's helped you. And with this idea of the pressures of 10x development, I thankfully also have not felt the pressure to deliver faster necessarily in the age of AI, but kind of found some scripts that I wanted to share if anyone is kind of facing these, I think hearing somebody else say it or having something prepared is really helpful. So if anyone is kind of facing these, heard some no scripts, a way to approach that conversation healthfully is instead of saying, I can't do this, maybe you're getting, yeah, somebody's asking you to ship something that's not ready, ship something that hasn't been fully reviewed, you can say, something along the lines of to deliver with architectural integrity, I need to de-prioritize. If we add this, we risk the stability of development and the deployment pipeline. What trade-off do you prefer? So that's kind of that managing up piece. Or saying something like, I am slowing down this sprint to ensure we don't spend the next three sprints fixing AI-generated bugs. So. Those are things you could try if you're under that pressure. Brittany Ellich (21:37) one thing to add there actually. I feel like this is something that I've been asked to do probably over the last year or so as I'm working with some teams that do work very, very quickly and want quick turnarounds. And I think that one thing that I found really useful is to like try to put things in the terms of, you know, whoever it is. that is making the ask. Like a lot of times it's a product manager saying, hey, we need this. And then saying like, all right, which is the priority, this thing or this thing? Because we can only get one of those things done. And I feel like that has been really useful to level set and be like, all right, we can only do so many things. You pick which one you want me to work on. And I'm happy to do that. But we can't do both. And I think being really honest and upfront about that is just better for everybody, just to level set expectations and also to, you know, actually deliver a working thing at the end. There's still a lot of things that end up getting deprioritized, you know, after we had already started working on it. But I think that's just the nature of work right now. Like everything's moving so fast that sometimes we realize, we don't need that. Let's move on to something else. And it's harder because I take, you know, Like a lot of engineers, I feel like I take a lot of pride in the stuff that I work on and I like want to finish that thing if I'm working on it and want to get it all the way to completion. But sometimes I think we also have to accept that, you know, that's just not what the product needs right now. And we need to move on and do something else. And it's a skill to build for sure. Bethany (23:07) Yeah, I definitely agree that. communicating trade-offs and being able to make it so that it feels like the person who's asking has some contribution to what gets done and what happens. But I think it's also important to note that there's some level of psychological safety that's needed to push back and to say no. And I know we've had an episode on psychological safety and the importance of that, but it really is like that I think first like foundation level to be able to push back to communicate and for everyone to have the trust in each other that we're making the best decisions with what we have and trying to do the best we can. And so I would say if like, if you're listening to this and you're like, wow, I don't feel like I could do this. Like I think that's probably a problem you should solve before like figuring out how to push back is like. Is this a culture issue? Is this a imposter syndrome issue? Is this like, why do feel like you can't push back? And then fixing that first before going on with like, okay, now I can push back and like have a real conversation about expectations here. Erika (24:15) Yeah, something I have trouble saying no to is this idea of glue work. And I'm hoping that maybe you two can help me with some things that I can use to say no. And there's now some conversation of like, hey, maybe in this age of AI development, maybe glue work isn't so bad. you know, we're all leaning a little bit more into, if anyone's not familiar with the term, it's sort of this less technical side of the job, like helping unblock team members, reviewing design documents, coordinating tasks. And in the past, for individual contributors and engineers, there's been this idea that this doesn't actually contribute to your career progression. So, but I feel like to your point, like I get asked to do this stuff a lot because I don't know, I'm fine at it, maybe because I've said yes a lot in the past. And I think even when it might be more valuable now. there's this idea of documenting all the glue work that you do and making sure that it's valuable and actually delivering some kind of measurable positive outcome, but also saying no to the stuff that is not technically aligned. And I'm curious if either of you have experienced this. I'm guessing yes, because it's... It feels like a very common thing, especially for women to get asked to do this kind of work. And yeah, how do you prioritize and what do you say when something's not in that area of something that's gonna help you move forward in your career? Bethany (26:15) Yeah, I think I definitely have been been like part of that. And I've also leaned into that glue work because it feels like something that I can meaningfully do well when I'm afraid of doing maybe more technical work and being seen as like a fraud or or whatnot. So I think like, definitely some early I this isn't to say there is not an issue in the industry of like stuff. especially women and younger engineers getting assigned glue work and it not contributing to career progression just saying that, but I've also leaned into that. So I think it's like worthwhile to have people who are willing to push back on that. I would say that I just started communicating with my manager the things that I needed and just being upfront saying, hey, I'm my goal is to get promoted and I really need to show X, Y, Z to get promoted. Therefore, I need to get these opportunities to do that work. And just being clear with whoever's assigning your work or assigning initiatives, like what you need, which is unfortunate. Like they should also be able to know that, but it is good to be extra clear on that. And then if you're asked things, like on my team, we're asked for a lot of like, quick things or ad hoc things that may or may not be important. And I think it's what I tend to do is say, hey, thanks for the suggestion. Let me create an issue and I'll check on the priority here. usually delegate that to people who are actually like a siding priority and actually like in charge of that, especially if it's something where I'm like, okay, this isn't going to meaningfully help me. And I don't know that it's really important for the product. So. Let's actually check with people who have more say there rather than just going on with the ask. Brittany Ellich (27:57) Yeah, I think that sort of what Bethany was alluding to, like the prioritization of the work, like if it is actually a priority and will help the team, I think that it's probably actually very beneficial to your career. And like you said, Erica, I think it's probably like becoming more important over time. And I think that people are starting to recognize that like, yeah, this work is important. Like it's better to make your entire team go faster than for you to go faster as an individual. If you can level up your entire team, that's much more impactful than, you know, just getting really good at doing stuff on your own. And I feel like that's sort of the role of like, you know, more higher and higher individual contributors now involves a lot more glue work. I think, yeah, just recognizing when something's actually gonna be useful to the team and to the product and then when it's not and pushing back on that is important. And like Bethany said, I love the idea of telling your manager, like, this is my goal, this is what I want. And then hopefully they're giving you the opportunities that will actually contribute to that and not necessarily just throwing things at you. And just don't offer to take notes, unless you know, unless you really want to take notes so I feel like that's the one can you take notes. hey that's true that's a good point maybe some of the glue work yeah maybe some of the work is actually like really good Ai things ⁓ yeah. Bethany (29:05) There's AI for that now. Anyways, use AI. Yeah, definitely. Yeah, just be selfish. Like, ruthlessly do things that benefit you. Brittany Ellich (29:25) Yes, that's hard. It's hard to do. Bethany (29:26) it. Yeah. Erika (29:29) Yeah, yeah. I, yeah, so the idea of like creating alignment with your manager and having the same priorities of what is and is not important for you personally and then also for the team. Yeah, that. that creates a team within your team to look out for your career. And ideally, your manager respects that and understands that and believes in you enough to push that forward. yeah, and also reducing the urgency of those asks by making it asynchronous, but making it public and visible, making it so that somebody else can pick it up. Yeah, those are all really great suggestions. Yeah, and thank you. Thank you for your input and helping. Yeah. good to look out for ourselves and ultimately like you said it benefits everybody when the most important things are being worked on and also when we're empowered to do our best work. Yeah, because if it's not the most important thing, if it's something that can wait or something that can be done by somebody else maybe more quickly or something like that or by AI. Great. Like, yeah, it moves everyone forward. So awesome. Well, thank you both for engaging in this conversation. Any final thoughts on this topic before we wrap up? Bethany (31:09) I don't think so. think it's good to always pause and like talk about burnout and normalize it because I think it's something that people almost treat as a bad word. Like, because once it's almost like once you name it, it's real. But I think it's important to check in about that when you're not feeling it even to and just like regularly check in with your mental health, check in with yourself and be real with yourself and your team and your manager and stuff. what's happening. Of course if there's that psychological safety, I think most of those conversations rely on having that with your team, but if you do, definitely talk about it more. Normalize mental health conversations. Brittany Ellich (31:50) Yeah. Plus one to that. I am a huge fan of the fact that I feel like mental health conversations are becoming less taboo to have. and you know, trying to find what it is that works for you is great. I love that. I'm on Prozac. It's amazing. It's my favorite. Like, I love it. It's great. So find the thing that works for you. If that's medication or if it's therapy or if it's, know, whatever it is that you need to do to survive in this crazy world, then yeah. Do it if you're not feeling good. Bethany (32:20) I think that's such a good point. Like, like, medicine's great, therapy's great. Also, it's okay to not be okay with how wild things are right now. I think it is. If things are weighing you down in the world, like, that's normal. That's just a sign that you are a normal individual who can feel empathy for these things and like, it's okay. Brittany Ellich (32:41) Yeah, yeah, if what you can do is the bare minimum to get through, like, I think that's fine right now. Erika (32:48) Yeah. Yeah, and I guess also we were talking a bit about the beginning that it can come in waves and it can come in and out. You can feel more or less burned out at different points in time. yeah, even hopefully having supportive colleagues, people you can talk with if that's helpful for you or yeah, any other any other tools in the toolbox to help prevent burnout ideally. But then if it does happen, to recover from it. So, well great, let's wrap up with our fun segment. Today we are making wild predictions. They need to be wild. We were talking before that they can be mediocre and I'm saying no. No mediocre predictions here. So wild, wild predictions, the wilder the better for 2026. So I guess I can start. My wild prediction for 2026 is that by the end of this year, overcommitted will have read five books. That's not wild. These are so hard to make wild. Bethany (34:07) That is such a wholesome prediction. I love that. ⁓ Brittany Ellich (34:11) together. Oh, yeah. Bethany (34:13) that to happen, yeah. I stand by that. Erika (34:14) Yeah, I'm a man. myself will have written 10 blog posts there that's wild considering I have written one in my entire lifetime okay there we go crazy Brittany Ellich (34:24) There we go. Yes. Nice. Yeah. For those who don't know, we do have our Writing for Developers blog or book club going on right now. And we've had a lot of wonderful contributions in our Discord of people sharing blog posts. So. Erika (34:39) Yes. been so fun. Brittany Ellich (34:42) It's been great. Wow, I don't know how to follow that up. That's a... I think I've been thinking about this a little bit. think that my wild prediction is that there's going to be something that exists to help manage the context switching for AI, like asynchronous AI development. I don't feel like that tool exists yet. Erika (34:49) Bye. Brittany Ellich (35:10) and like, feel like my brain breaks far sooner than, than the, then the agents break, but that my wild prediction is that we're going to have figured that out by the end of 2026. hope, I'll share one article, in the show notes about that, that I think was kind of interesting from, Gastown where they were talking about like, you know, agents kicking off other agents and handling other agents, feel like there's going to have to be something similar to that. But as we've already said in this conversation, that might not work in a production environment where you actually care about the code afterwards. hopefully there will be something that exists that handles that. Bethany (35:50) Gosh, that's so real. There was a thread from the person who made Cloud Code on how they use Cloud Code, and they said something about kicking off five instances of at a time, and I'm just like, how do you prevent it from conflicting with itself? How? So hopefully, hopefully that's something that people are willing to share or help out with. Okay, my aim is I think that there will be an uptick in like bad web design to almost like prove that something wasn't done by AI, like to almost like revolt against that. So I think like, like the GeoCities like things like that, that's going to come back and and like be present to almost prove that something was not like like done by AI is my prediction. Brittany Ellich (36:48) I love that so much. feel like there's been several things recently where I like actually wrote it out and I almost wanted to say, by the way, this wasn't written by AI just to like give it a little bit more credibility. And like I'm somebody who's very pro like using AI for everything. So I can see that I've noticed like I read a blog post yesterday and I always noticed typos and now like AI really tools don't really produce typos. I was like, sometimes I'll go and tell the author like, by the way, you spelled this wrong. Now I'm like, nope, leave it. evidence that this was a human that wrote it and that's not a bad thing. grammar. Bethany (37:20) Yeah, 100%. Every time it adds an dash, I'm like, nope, we're stripping that out. No dashes in my written work. Erika (37:28) I felt called out because I was talking to somebody the other week and she, I guess she's a teacher and she said that like anything she encounters in her work like that has emojis in it was written by AI. I was like, ooh, I use emojis all over the place. This is like one of those like, ⁓ am I AI? Uh-oh. Brittany Ellich (37:49) No! Erika (37:52) She was like, yeah, like this whole thing, looks like it was generated. I was like, no, I actually wrote that, but I put a bunch cheese all over the place. Brittany Ellich (37:59) no. Bethany (38:01) Okay, I agree with that. think emojis help convey sentiment in written work. But I think you have to use just the most chaotic emojis possible. And then that helps. it's like, clearly AI's not reacting with LOL sob all the time. Erika (38:11) Thank Brittany Ellich (38:17) Valid. Erika (38:18) Maybe that needs to be our next prediction is what emoji is going to take off in 2026. What's going to be the chaos emoji? All right. We'll put a pin in that for next time. have time to think about it. Alright, well for today, thank you everyone so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 43: Accessibility, Fiber Arts, and ADHD with Abbey Perini - URL: https://overcommitted.dev/accessibility-fiber-arts-and-adhd-with-abbey-perini - Published: 2026-01-20 - Topics: Non-traditional Paths to Tech, Developer Experience/DevRel, Career Development, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/112900577/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-20%2F414727633-44100-2-676e57913bfc8.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany, Brittany, and Erika engage in a rich conversation with Abbey Perini, a web developer and fiber artist. They explore Abbey's current projects, the intersection of fiber arts and programming, and the importance of accessibility in web development. The discussion also delves into personal experiences with ADHD, community building in both knitting and open source, and the challenges and strengths that come with neurodiversity. Abbey shares her insights on how to make coding and web development more inclusive and accessible for everyone, emphasizing the need for empathy and understanding in the tech industry. Takeaways * There is a deep connection between fiber arts and programming. * Accessibility should be a priority for all developers. * Community building in knitting can inform open source practices. * Accessibility is not just a front-end concern; it extends to back-end development. * ADHD can present challenges but also unique strengths in coding. * Flexibility in work can benefit everyone, not just those with disabilities. * Negative self-talk can be harmful, and you are awesome, so stop it. * Developers should focus on problem-solving skills rather than just technical tools. * Creating inclusive environments in tech is essential for progress. Links * Abbey Perini’s website: https://abbeyperini.dev/ [https://abbeyperini.dev/] * Abbey on Bluesky: https://bsky.app/profile/abbeyperini.dev [https://bsky.app/profile/abbeyperini.dev] * Abbey on LinkedIn: https://www.linkedin.com/in/abbey-perini/ [https://www.linkedin.com/in/abbey-perini/] * Knitting as programming blog post: https://abbeyperini.medium.com/knitting-as-programming-9c34090e4992 [https://abbeyperini.medium.com/knitting-as-programming-9c34090e4992] * Web Development === Accessibility blog post: https://dev.to/abbeyperini/web-development-accessibility-f8i [https://dev.to/abbeyperini/web-development-accessibility-f8i] * An accessible dark mode toggle blog post: https://dev.to/abbeyperini/an-accessible-dark-mode-toggle-in-react-aop [https://dev.to/abbeyperini/an-accessible-dark-mode-toggle-in-react-aop] * Coding and ADHD blog post: https://dev.to/abbeyperini/coding-and-adhd-where-we-excel-454j [https://dev.to/abbeyperini/coding-and-adhd-where-we-excel-454j] * Designing data-intensive applications https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321 [https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321] * Aria article: https://dev.to/abbeyperini/what-the-first-rule-of-aria-really-means-192e [https://dev.to/abbeyperini/what-the-first-rule-of-aria-really-means-192e] * How to do chores while drowning: https://www.amazon.com/How-Keep-House-While-Drowning/dp/1668002841/ref=sr_1_1?crid=14ND3S4IR3YLG&dib=eyJ2IjoiMSJ9.ue6gifKzpUZ5byIrJ4RUyA.9EOnSDfKG5rpl9Or07gVfVfYityMMWTqBEL4EAsN1Mw&dib_tag=se&keywords=how+to+do+chores+while+drowning&qid=1766080922&s=books&sprefix=how+to+do+chores+while+drowning%2Cstripbooks%2C83&sr=1-1 [https://www.amazon.com/How-Keep-House-While-Drowning/dp/1668002841/ref=sr_1_1?crid=14ND3S4IR3YLG&dib=eyJ2IjoiMSJ9.ue6gifKzpUZ5byIrJ4RUyA.9EOnSDfKG5rpl9Or07gVfVfYityMMWTqBEL4EAsN1Mw&dib_tag=se&keywords=how+to+do+chores+while+drowning&qid=1766080922&s=books&sprefix=how+to+do+chores+while+drowning%2Cstripbooks%2C83&sr=1-1] * Ask Jan: https://askjan.org/ [https://askjan.org/] * Study: ADHD powerful strengths - https://scitechdaily.com/adhd-isnt-just-a-deficit-new-study-reveals-powerful-psychological-strengths/ [https://scitechdaily.com/adhd-isnt-just-a-deficit-new-study-reveals-powerful-psychological-strengths/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Bethany, and I'm joined by... Brittany Ellich (00:08) Hey, I'm Brittany Ellich. Erika (00:10) and I'm Erika. Bethany (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've learned. 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 Abbey Perini, a mid-level view developer at Hygenia. Abbey describes her coding comfort zones as all areas within the stack, is passionate about making the internet a better place for everyone through accessibility, and loves helping other developers through blogging and speaking. Additionally, she is a fiber artist and has consistently incredible nails, which you can see on Blue Sky. Welcome, Abbey. Abbey (00:56) Thank you. I might use this as my new intro. were talking, or bio. We were talking about how we're all terrible at writing our own bios and this is great. It's much more succinct than mine. Bethany (01:07) Amazing! No, I was having trouble not copying yours because I loved it so much and I was like, we need to tweak it a little. that's a very cool thing. ⁓ Abbey (01:11) Thank you. If they ask for a shorter one, I'll give this one. That'll be it. Bethany (01:18) Perfect, perfect, sounds good. To kick us off, I'm really curious, what's one thing that you're currently building or obsessed with learning right now? Abbey (01:25) So I have, I'm giving a talk and a workshop at CodeMesh in January. So I'm having to prep all of that content right now. And I think I finally found the narrative in my restoring lost work, Git talk. It's. The whole series of talks and blogs is titled hashtag get panic because that's the inside joke that came up when I was learning. Get, you know, it's, always trying to give you a heart attack. And so this talk is really near and dear to my heart because we've all like, if we've tried to do something fancy and get accidentally deleted a commit and been like, my life is over. Like this is it. It's over. And I think this talk will give people a lot more confidence in knowing that 99.9 % of the time you can always get that commit back. And that, you know, it's really boring when you stand up in front of people and just run command after command after command and be like, you can do this, these are things you can do on your computer. So I'm glad to have finally found the narrative and I'm hoping the audience at CodeMash likes it. Bethany (02:19) Oh, that's awesome. I will definitely be watching that talk afterwards. Because I feel like doing simple things in Git is pretty simple, but anytime you have to do anything more complex, I'm definitely Googling, like, how do I rebase? How do I do this? So I'm excited for a better mental model there. Awesome. Well, speaking of building things, as mentioned, you are a fiber artist and have been crocheting and knitting for a while. ⁓ my gosh, I didn't even notice. For your listeners, Abbey's background has so much yarn. That is amazing. ⁓ Abbey (02:47) Yep. And then a pile of unfinished projects as you do, you know? Bethany (03:00) Of course, yes, that's how it goes. So I really loved while researching reading your blog post called Knitting as Programming. And you mentioned that programmers owe it all to Fiber. That was kind of the subtitle. So since you've been doing Fiber since 2013, I'm curious when that connection really was established as you were learning to program. Abbey (03:26) So I started learning the program in 2020 and I kind of timed it so that accidentally I committed to a bootcamp right when lockdown started. So I was in the staffing industry and nobody was hiring, everybody was panicking. So I basically was getting paid to learn to code for several months. And when I started doing bootcamp, obviously the learning curve jacks up and it's like you're drinking from a fire hose. could not pick up a knitting or crochet project during bootcamp at all. Like I would just like stare at it and be like, nah, not today. Like the entire part of your brain that is used to figure out like a new stitch or like follow a pattern or anything like that is so similar to coding that after doing it for, you know, eight, 10 hours a day, I was like, that's not relaxing to me anymore. That's, I can't do it. So there's a sharp decline in my fiber arts. that's when, like right after I finished bootcamp, was like, how, that's kind of like weird. Like I wonder if anybody else has made this connection. And then that article was just like the beginning of it for me. I have talked to, I was like at Netlify compose at the after party, being like, guys, what about like knitting and programming? And and two like researchers were like, you mean computational knitting? And I was like, great, there's another term. Awesome. And so, I even, through some personal life stuff, met someone who taught fiber arts at the Chicago Institute of Art. And so I've got some new articles and stuff for my workshop at Code Mash, which is fiber arts and programming. So I'll be talking about that relationship and also teaching people to crochet and knit. And the relationship is so interesting because people will just be blown away by the fact that MIT hired women to weave wire together. to create ones and zeros to make little old lady memory for rockets that went up into space for them to work. So like the first punch cards were Jacquard Looms making textiles and like it's it's really it's it's more of a marriage than it is like two separate things that just keep influencing each other. Bethany (05:28) Yeah, it was really cool to see not only that like, knitting is similar to programming in terms of patterns and like repeating stitches and things like that. Like it's similar to actual code, but actually, code is built on top of like the technical industry does actually owe a lot to fiber. And I thought that was such a cool connection. I also loved the connection not only to that, but also just fiber artists leveraging online communities for connection and open source software to create. I'm curious if you have anything to add on what developers can take from those community building practices or open source usage. Abbey (06:12) So, I'd say... Knitting has been trying to figure out like the knitting community has been trying to figure out the best way to teach beginners how to get into these extremely complicated knitting patterns because especially I know some of y'all crochet I'm not sure if you've ever attempted to knit a sweater but like just trying to get the 3d shape to go to different sizes and like how the stitches work out and stuff like that is a lot of math and a lot of physics and at like a tiny scale often and So. they'll have to have these very abstract charts and lists of stitches and stuff like that. Just for the crocheters, knitting charts and crocheting charts are two completely different things. And I've talked to like knitters who never crocheted and they're like, what it's like arcane magic. Like I don't understand like the T's going off of each what is happening there. And then I look at knitting charts and I'm like, I just can't keep track of where I am in this grid. I bought the things with the magnets that like help you keep track and like all that stuff and it does not help at all. So I often stick to just the written out like stitches and those I'm able to remember and that the way that at the beginning you get like the key for all the different abbreviations that they're going to use and then eventually your brain maps it to like essentially variables and then you're sitting there with little like for and while loops like this is both knitting and crochet the way that People are taught these patterns is a lot more accessible often than the way that we're taught for loops and while loops in programming especially like I I can do statistics I can't do math and I have a complicated relationship and like to illustrate that I had to look up what the the sum symbol was again, like two years ago. And my math friends are like, you're kidding me. And I'm like, I knew what it was at some point, but like I tried to avoid math. So I don't remember what the symbols are. And when people start talking about explaining programming with math, they're not like, okay, so here are the symbols you're gonna need to know. Here's how, here's like a few basic concepts before we really get into it. They're like, surely you're familiar with monotonic functions and that's going to explain everything that I'm talking about in the rest of this article. And I'm like, no. It really does not. So there's... an interesting overlap in like how the pattern communities have thought about communication and those soft skills that often are downplayed in like a technical standpoint. And there's a lot to learn from them just for like teaching people how to do these crafts with their hands. And I love the point that it's a great way to teach QA testing, because you have to sit there and you have to follow the pattern, you want it to look like the picture, and then you're doing the you're doing the process that makes the output and then you look at the output and does it look like the picture and just that process like a lot of people haven't thought through so when I started talking to QA people I was like yeah you're brilliant this is great you're thinking about the little steps that people forget and they were like she's our favorite developer let's let's stick with her we're doing it Brittany Ellich (09:13) That's amazing. I personally have never made that deep of a connection between them, but you're so right. I feel like there are so many crossovers. I'm a crocheter. I cannot handle knitting. I wish I could. It's so hard. Abbey (09:25) You can. You just have to find the pattern that gets you into it because I, for the longest time, was like, I think I've been crocheting like eight years before I picked up knitting. And I've been like, I don't need knitting. I can make everything with crochet. It's fine. And then I saw a pattern that was a scarf that had a dungeon map on it with charms for all the D &D monsters. And so you can play the entire adventure that's associated with it on the scarf. And I was like... Brittany Ellich (09:29) Yes. Abbey (09:54) I'll learn to knit. And the owners of the store were like, you're going to have to learn to knit and purl. It's double-sided. there are a lot of things you're going to have to learn at once. And I was like, it'll be fine. Best color work I've ever done. First project. Can't do color work tension now. It's horrible. Don't know why, but that first project, beautiful, amazing. Got me into knitting. Yeah. Brittany Ellich (09:55) Hahaha Wow. It's the motivation to, you know, for that end product. It makes a huge difference for sure. Abbey (10:17) Yeah. I know you and the Wubbles, you'll find something eventually that you'll be like, gotta make that. Brittany Ellich (10:22) Yep, yep, it's true. That's amazing. Yeah, and speaking of community, we do have an online community that is, I think we have Abbey, who shares her things. We also have Christina Martinez, who we've had on the show, who shares her things in our Discord, in our little off-topic Discord. And if you too, also out there, like to make things, we would love to share them and obsess over them as well. We'll plug. ⁓ Abbey (10:31) Yep. Agreed. Bethany (10:47) Nice plug. I love it. Brittany Ellich (10:47) Thank you, yeah. I just want to see more things people make because it's so fun. It is such a great community. Abbey (10:49) Yeah. It's been, it's had Erika (10:52) you Abbey (10:53) a glow up. I was just added to talk about fiber arts and now like sometimes the off topic channel, I'm like, when was the last fiber art? I gotta scroll back so far. Brittany Ellich (10:59) Yeah, it's true. It's true. ⁓ Erika (11:03) you Brittany Ellich (11:04) So I wanted to talk a little bit too about accessibility because I know that that is another topic that you are quite prolific and you've done a lot of blog posts and talks and everything advocating for the accessibility community, which is just awesome. One of the blog posts will link it as well is the about how web development is equal to Abbey (11:14) Accurate. Brittany Ellich (11:25) accessibility. I'm curious after looking through that, like, do you think that since you're a full stack developer, like, is accessibility only a front end concern or, like, are there accessibility concerns that folks that you have to think about on the back end as well? Abbey (11:40) So that blog is my like spicy hot take. That's my like only spicy hot take blog where I'm just like, if you're not thinking about accessibility, you're technically incorrect. I don't know how to explain to you that you're not thinking about people and you should care about people. So I'm just gonna go straight for the nerd snipe, okay? And I finally did give that as a talk recently and I thought it was pretty fun. But... Accessibility, a lot of people think, okay, so it's the front end, it's the buttons, it's the color contrast, it's what you click, can you click it, can you do keyboard, can you do screen reader, blah, blah, blah, blah. But a lot of times people don't think about like cognitive accessibility. creating these are archaic flows where you like... The thing that is driving me nuts right now is when you go to a forum and you type in your username and then it waits a second and then pops up the password box and then you have to click it again and autocomplete it again because I use autocomplete for everything because I have ADHD. I cannot remember anything and I am a web developer so I have to have random passwords. I have to auto complete. it'll be like, OK, why are we doing that? Is it because it's two back-end calls? Do we need to deal with the back-end so it's not that much? And then there's also the data layer. I'm in another book club, not an overcommitted book club, I'm sorry, that's reading like data-driven, designing data-driven, data-intensive applications. That's the one by Martin Kleppen. And It's talking about the way that you structure data and the tools that you use for data and stuff like that. I find that especially developers often forget about things like documentation being about accessibility and equity and bringing in new developers and letting them get onboarded all in the same way and give feedback on the onboarding process and getting them up to speed in a way that isn't sink or swim. So it can be everything from the tools you choose and making sure that everybody on the team knows how to use those tools. as well as the way that you're designing the backend to create the flows on the front end and the way that you're designing your data structure for the developers because like I've had conversations where people don't even think about it being an accessibility thing but like the data structure being the same in this app and this app in the same company is actually better for all of us from a development standpoint but also from an accessibility standpoint because if I can remember one schema and validation and stuff like that I don't have to remember that yeah this one over here has a slightly different tweak or like this one's supervisor and this one's trainer when they're both have to be supervisors so we might as well just call them supervisors and stuff like that so it it boils it it boils over into everything once you start noticing accessibility fails it only keeps snowballing in your life Erika (14:21) Yeah, it also feels like one of those things where like, there's not, like, I often feel like there's not like a ton in the world that I can like really tangibly, meaningfully make better for people. like building better web pages is like something that I can do. Like it's free. There's nothing stopping me from like making a better site, making a better page. Aside from you said like technical limitations or like, you know, company, company priorities or something like that, but like it's my own site and like I have any say in it, like I, that is something that I can do and make it better for people. Abbey (14:51) ask permission. Yeah, I recently, when I joined this company, my one of the higher ups was known for saying like, I don't care about screen readers. And I was like, I can't wait for him to say this in a call with me. This is gonna be great. This is gonna be a great time. And then I wrote the densest article about Aria. Like it is... 75 people had read it. Like it was not like it's so long and it's only for the people who actually are like I need to know the answer to this or my fellow accessibility advocates who I had them read it multiple times to make sure that all the information was correct. And like, I don't know why this was the thing that changed his mind, but all of a sudden he was like, well, you know, when you put it that way, like it really makes more sense. Like if from a structural standpoint, you can provide all of this information with HTML. And I was like, what? Why was this the thank you for reading my article, but why was this the thing that you got nerd sniped by Aria of all things? Like that's that's the weirdest thing. And I think the other thing was, again, I don't ask permission. And every time I made something more accessible, it worked better. And like our our whole thing is that the user with the least technical information should be able to use our website without like having to ask for help without needing tooltips like ideally they should be able to look at it and know exactly what button they need to hit next which is a challenge but every time I tackled one of those problems and made it more accessible it was much easier to use and so I I don't people have often been like how do you get accessibility to be more of a priority and I'm like it's just a priority to me and I'm gonna keep doing it and like it helps that my direct boss that's one of the reasons that he brought me on he was like she'll she'll do it. He was out one time and he came back to a PR that had put back in all of the focus outlines on all of the interactive elements and I was like, I broke. He was like, okay. Erika (16:34) That's a good... It's a good point though. mean, like, it does, like, it can translate to things like page visits, like longer time spent on whatever screen, like, you know, the sort of like typical... performance indicators that companies use for like, are we a good site or not? Are people visiting? Are they staying in our pages? If they're more joyful and easier to use, the answer is probably yes. So you can probably find business, whatever, business justification for it. Yeah. Abbey (17:15) business justifications. And a lot of times it'll be like, I can do this in one line with semantic HTML instead of 30 lines with like weird JavaScript. The other thing I wanted to say is like as people who are technically literate, we understand things more than the average person when it comes to interacting with technology, especially if you start learning about mobile accessibility, which I was lucky enough to get to do in my last job. There are so many things when like your parents get older, your grandparents, people who come get something like a mess and start losing the ability to do fine motor skills and stuff you can be a resource for them talking about like you can you can just talk to your computer and it will type for you stuff like that they don't even know that that's a possibility they don't know about it's talk back on Android and voiceover on iPhone just like it's voiceover on macOS and the day I knew that my dad actually understood my job was when he came to me and he was like, you know, my my friend's wife has advanced MS and she's just asking Siri to use her phone. Is there something else that she could be doing? And so I and my coworkers at the time drew up this whole list of things and just like, you know, the fact that there are different ways that you can use your mouth to interact with the computer. You can have a stick, you can have a straw. There are like multiple different assistive technologies that you can use. And that kind of information, once you start to build it up, people really need that because they that it isn't like offered up. There's no course teaching you how to use technology. And so I was in a I think a PT receptionist office. And I said something about like, yeah, technology is advancing very quickly, but we're not making sure that everybody can use it while that's happening. And she was just like, she almost started crying because she was just trying to operate the computer in front of her and the printer. And she was like, I'm so sorry, this is taking so long. And I was like, no. We're all figuring it out. As my P2 is like, Abbey, you might need to get back here. This printer is not, I was like, what? I'll kick it for you. I did that in an IT job before, but like, no printers. Brittany Ellich (19:11) Yeah. Yeah, it's amazing too how much there is to learn about accessibility. Like don't feel like it's very easy to learn. There's definitely some good resources out there, but you like really have to dig for them, which is one of the reasons why I appreciate a lot of the blog posts that you put together because they're readable and they're very real too. So one of the examples we came across while preparing for this was your dark mode toggle. Abbey (19:39) Yeah. Brittany Ellich (19:40) and you have a whole blog post going over how you audited that and fixed it. Which one, I think that that's, as developers, that's often one of the first things we add to websites, whether or not that's the most useful tool for everybody. And yours is gorgeous ⁓ as well. So I'm curious, what are your thoughts on blending that aesthetic vision for those things? And... Abbey (19:52) Right. Thank you. Brittany Ellich (20:04) those with accessibility requirements as you're building now. Like, is there anything you learned from that experience that you've carried forward since then? Abbey (20:10) Okay, so my second spicy hot take, really spicy hot take on this podcast, is that if you say that something can't be pretty inaccessible, you're not trying hard enough, or you need to get better, or one of those two. And shout out to Chris Bongers for the design for the Dark Mode toggle that's on my portfolio site. And that series where I went and audited that toggle specifically because it came up was part of a six part blog series on auditing my own portfolio. portfolio site, that is what got me the job at a digital accessibility company. Like I saw the post and I went, please, I have, I have blog posts. have so many, look at these. And they were like, okay, yeah, we need someone passionate. And that all started because of my friend who I am very lucky to know, Todd Libby, who is known for lobsters and accessibility. And he possibly in the other order, maybe. he did a launch and learn in a networking group I was part of and he went through how he would look at somebody's website when he was auditing it. So he went through all of the tools that he would use and then a lot of it after that was manual stuff. So there were also guides for all of the manual testing. And so I went through the whole process on my website and then identified all of the things that I wanted to fix. the drag mode toggle was one of those things. And I think the title of that one was like accessible dark mode toggle. And that's how I met Graham, who really, he started with a comment that it had headings, like it was formatted. Like there, it was a lot. And I was like, buddy. And then we both thought we had insulted each other. It was a whole thing. We're, good now we're friends, but like, he was like, you can't. say that it's accessible because it's not 100 % accessible. And I'm like, but Todd Libby says that nothing is ever 100 % accessible. That's impossible. Like you that's how do we how do we do that? And so like through back and forth, I think I even added more stuff in either other blogs or like at the I went back and edited that one. But I had started with the beautiful thing. And it's still a beautiful thing. I think the only thing that I would add to it now is creating an actual tooltip instead of using titles so that the tooltip would be activated when and it's focused with keyboard. Graham came up with things where I had the focus outline would come in gradually and he was like, you can't see it for most of the animation. I was like, okay, yeah, that's fair. But for people who are like, animations aren't accessible. You just have to be able to turn them off. You can still have them. You just need an alternative where they're off. So. There are a lot of things now where now that I've been doing it for a while I'll go to something and I'll be like, huh I wonder how accessible this is and like start thinking about how I would make it more accessible and like what alternatives could possibly be there and sometimes, most of the time, it's just like hey if I couldn't see what would want to know about this, which is why I think Blue Sky's push for alt text is one of the most fun things that I've gotten to witness because I've been doing alt text for a long time on Discord, on Slack, on and it's such a pain in the butt on Instagram. Not that I have an Instagram anymore, but there are a lot of times where it's like really, really difficult and Blue Sky has the setting where it'll remind you if you don't add alt text to an image. And that has been so great because like I don't have to remember that piece anymore. I just get to sit down and describe the image and if you aren't having fun thinking about the alt text for your image, I challenge you to go write alt text for a bunch of memes. Like a ton of memes. Because I use a lot of memes in my blog so I've had to do a lot of summaries that are like, you know, okay the stick figure sitting at the desk. What is the stick figure sitting at the desk trying to like describe? Okay, all right, maybe I don't need to talk about his desk sitting. Maybe I just need to talk about this part of the image and then giggling at my own description of the image and hoping that someone comes along and also giggles too. It's more fun to include everybody is what I've found. Bethany (24:10) Wait, can I go on a rant about alt text and Oatly, ⁓ the oat milk thing? All right, I'm excited to tell this story because it makes me truly upset. But one time I was scrolling Reddit and Oatly had an ad, like whatever, but they were using the alt text as like memeing. They were like, Reddit said we have to use alt text, but isn't that boring? instead we'll just like. Abbey (24:12) Yeah. Yeah. Bethany (24:35) Like basically make making fun of alt text and I was like, like people were roasting them in the comments. I'm like, maybe like somebody needs to know about this and that it's actually truly like a terrible thing. So I emailed them, I emailed their like corporate communications. I was like, hey, this is really bad actually. Like these are the reasons you should care about accessibility, about alt text, like why it's important, why it's good for everyone. And they emailed back and they doubled down. They were like, no, don't you think it's like kinda dumb and kinda like unfortunate. So To this day, every time I go to a coffee shop, I'm like, what brand of oat milk do you use? And if it's oatly, I don't. I don't use it. I'm like, all right, whole milk's great. I'll take it. Exactly, exactly. So, oatly is terrible. That is my takeaway. Abbey (25:10) Yeah, but with your wallet. God. ⁓ Yeah, so I'm a cancer survivor and one of the things that that involves is talking to a lot of people and going through lot of portals and doing a lot of things that can be very cognitively accessible. murky is the best thing I can say. And there there was one time where I called a charity and I do think that they were trying so I'm not going to name them. But like when I call I like left this feedback and then I got this call and I was talking to her and she was like, well, we do have accessibility testing and I was like, okay, well, I think You need to look at that accessibility testing because like an automated tool caught all of this. Like this is not... It's like color contrast. Like I don't... I don't know... It's really basic stuff and they were like, but one of the other things was... So MyChart is a common app that medical institutions will use and you kind of get... It's one of those things where I think they have a different implementation for each system. Like when you set it all up, like maybe you're hosting your own backend or something like that. I don't know. But all I know is I typed in a username and it changed my username without telling me on the backend. It took off a letter and made it all caps. And I figured it out because I know how to sit there and be like, forgot password. What does it mean that username doesn't exist? And like try different combinations and figure out what happened. And I was on the phone with one of their like, I don't know if it was patient advocacy or like specifically to the setup of this tool. And I was describing what happened and she just went, I never would have figured that out. We can't be doing that. was like, yes, you can't just change the username without telling the person. They were like, I'm gonna put in a priority ticket for that one. I was like, thank you. Or like just sometimes just sitting with like customer service people and they'll be talking about like, I'm so sorry, the system is acting so weird. I'm like, you don't have to explain anything to me. We'll be here until the technology starts working again. That is totally fine. And the friends that'll make you in customer service. those poor people. Erika (27:13) On the topic of diversity, inclusion, you've been very generous in sharing about your experience with ADHD and specifically sharing about, you know, being vulnerable about the challenges and it definitely not being a superpower, but in some cases, it allowing you to do pretty amazing things like cram through an entire topic area in like one night if you really care about it. So, Abbey (27:20) Thank Erika (27:38) Can, would you share a little bit more about like how you kind of hold those two things in contrast of sort of the advantages and also the struggles and how you balance those two without diminishing either. Abbey (27:51) Yeah. the joke... You guys are bringing out all my spicy hot takes. I swear I have like three. And it's all three of them. But anytime anybody tells me that ADHD is a superpower, I'm looking them in the eyes, maybe. And, I'm thinking... So who is running your life? Is it a wife? Is it a partner? Is it a mom? who's making sure that you make it to appointments? Who's making sure you make appointments? Who's making sure that you like have some sort of structure to your day? And like, it's amazing how the difference between like going into an office and having that externally enforced structure and then having to do it yourself at home remote. Because I think a lot of people got diagnosed because lockdown happened and they were like, where's someone telling me that I have to be so- somewhere by 8am. Like that's I don't have to do that anymore. I'm just pajamas all day. So I got diagnosed at 28 and I didn't get diagnosed because I was failing at school or anything. I've always been good at school because of the externally enforced structure and the little rewards. you get an A. Okay, I'll do anything for an A. Let's do that. But like once it came to like wedding planning was a really like I thought I was losing my mind during wedding planning and then remote work and just getting so hyper focused on coding because I love coding and I want to be in the puzzle and like I'll just try one more thing and then eight hours have gone by and I haven't eaten, drank, done anything. Which one of the things I found through an ADHD coach that have been really helping with that is physical Pomodoro timers. So when it goes off, you can just flip it to set it to the next amount of time and Even if I don't get up, I at least know how much time is passing versus just being like, I'm full in. So the things, the reasons that I got diagnosed were more intangible than is usually the reasons that you go in. It was me being like, I feel like I'm bad at things. I'm so hard. I'm trying so hard all the time just to do the things that everybody else seems to be able to do normally. Like the grocery store is very difficult for me. So it was really like, first it was a trickle of like memes. There was a meme about hyperactivity in adults that sounds, was like almost constantly singing a song, can't sit still, likes to fidget with a lot of things, blah, blah, blah, blah, blah. And the fidgeting I had internalized to chewing my lips. So it wasn't as like noticeable, but I showed it to my husband and he looked at the list and he was like. Hmm. And I was like, yeah, that's kind of sounds like me, right? And then he's, he got diagnosed in college because he described what was going on with him to me. And I was like, that sounds like ADHD. And it turned out a doctor in like his, in like middle school told his mom that he couldn't have ADHD because his teachers liked him. So we've come a long way in like the description of what ADHD is. But my brother got diagnosed young and we, we laugh now because we think and act so Erika (30:13) Peace. Abbey (30:37) similarly. So similarly. The signs were all there. The like complaints about how I tell stories. The fact that I couldn't sit still. The fact that I have to try really hard not to interrupt people. And like taking struggling to take turns. I love running D &D. I love being a dungeon master but Baldur's Gate. you would have to bribe me to start again because you have to wait on everybody else's turn. Like you can't even, you can't even make a dice tower or do anything with your, like you just have to sit there with a controller in your hand while other people are taking their turn. is the one thing that I don't like about playing D &D. My friend who's a DM like knows that I'll just pull out knitting in the middle of D &D and then I'll be, I'll be better. I'll be paying more attention if I'm knitting. It's okay. And like when I was in school, teachers were like, would you stop drawing and like would try to ask me questions to show that I wasn't paying attention, but then I would answer the questions. So they were like, fine, you can draw, whatever, you be you. And there were a lot of things that were keeping me going during up through 12th grade. sleep deprivation, caffeine, and then I got to college and it was just easier than my previous schooling. So I managed to get through that. But by the end of the college, like, I couldn't finish a book anymore. Like, I was really burnt out on school and like trying so hard and all of that kind of stuff. So when I finally sat down, and I had gotten diagnosed with anxiety, erroneously, because that's usually women are like, I'm struggling with all these things. You're really anxious about things. It's like, I don't really think I'm that worried about other than like the outcome. it doesn't get done, which is normal. That seems like a normal thing to be anxious about. And so I sat down and I took the questionnaire that you can find them online. It's what a psychiatrist will give you if you go to get diagnosed. And it basically asks questions like, you know, Do you find yourself getting out of your seat in situations where you're supposed to be sitting down like meetings? Do you find yourself struggling to not interrupt people? Do you struggle with this? Do you struggle with this? And I think like the max score is like 21 and I got like 17 or something and I was sitting there just staring at this piece of paper and I was like, And because my brother and my husband had already been diagnosed a long time and we had looked at a bunch of different You know the Pomodoro method and this and that and he can't do gamification if he knows it's gamified He's like no, I'm out So that doesn't work for him But I was like I can apply all of these things to my own life People are like you're so organized I'm like because I have 18 systems working in tandem and if one of them falls out then like everything spirals out of control and I have to go like integrate them back in and like add another tool like this one's shiny it might be notion or obsidian and then I've also got the bullet journal and I've got this and I've got that and they're all of that is because I eventually just stopped expecting myself to remember things I stopped expecting myself to act in situations like other people would act. I stopped expecting all of these things out of myself. I stopped expecting myself to be neurotypical and I was able to set a lot of things down and suddenly my life became a lot easier because up until then there would be times where I would be like on the floor just crying going like I'm trying so hard and my husband would be like I just wish people could see how hard you're trying you're trying so hard yeah you're doing it you're doing great but like Once you sit there and start being like, okay, well, I'm going to have to sit still for a while. Let's make sure I have a silent fidget toy near me. So that is not like making noise and people aren't like disturbed by it. But I am able to sit there and not chew my lip and like try to focus on what's happening and writing everything down instead of expecting myself to remember it. And all of these things, it really like more than feeling like I am now labeled as disabled because ADHD is considered a disability, a cognitive disability. It showed me how many tools there are that I can have even without expecting my employer to like give me more time to do things or like having to ask for accommodations or anything like that. Just the small things where like, object permanence is hard. So if I want to remember something exists, it has to be like in a place that I go to regularly where I can see it. Like those little things start to add up and suddenly you're like wow my life is more designed for me. one of the reasons the best book is because it's short, it's easy, and it helps you set a lot of those things down. And everybody was like, hey, honey, you have ADHD. She was like, what? And she had just found all of these accommodations. Like, you don't have to unload the entire dishwasher at once. Blew my mind. I like, I can just do the glasses, and that's 10%. And then that's still progress. And so that carries over a lot into, you know, we talk about... finding time to do the kind of content that we do and the writing and all of that kind of stuff and so like I'll often start 10 % of a blog and be like I'm not feeling it right now and then suddenly I'll be feeling it and be able to finish the 90 % later and when it comes to understanding that it can also be a boon this has really come full circle because I remember the day that I was like I'm not gonna force myself to be boring anymore. I was like, what are you talking about? I was like, you know, like a lot of people are like, you need to be less impulsive. You need to be less this, but like... The fun part of me is that I find I can find joy in this in the tiniest of things like I can get really excited about the smallest of things and then I'll get invested and then I'll be able to do it and a lot of the times what people are describing that they're so amazed by like how what I'm able to do is me just being like I want to do that I'm gonna do that and not thinking about how hard it is and not like just because I want to I'm hyper focused on it and that is the core of ADHD like it yes it has its bad side where like it makes other things more difficult, you know, like when I take my meds in the morning I should look at my to-do list for the day while those are kicking in, not, you know, start a video game. That could go wrong, but like... The meds are there to help you build those kinds of habits. So like now when I go to eat lunch I think I should unload like the dishwasher a little bit and building up those little tasks with the help of medication has been really helpful. I also found help in a ADHD coach who really started questioning a lot of negative self-talk that I was giving myself and I thought I had like really cured a lot of that and I'm a big people who do negative self-talk in front of me and I'll be like no no we are great. We're dandy. Do not say those things. you know, just like a lot of shoulds. Should I should be doing this? Why should I be doing that? Oh, I don't know. Because, well, is it serving you? Like, we don't need to do that. And then there's a website called Ask Jan, J-A-N. And... it will tell you all the accommodations you can ask your employer for. So if you have a disability or have been thinking, you know, like, is there anything that could make my life better at work with what I have ADHD, whatever, there is a list of things by disability that you can ask your employer for it legally. And so I find that helps a lot of people think about like what they need at work. Mine has a lot of flexibility, which they're willing to give me, so I haven't had to ask for it. it's definitely... You'll find that when you're the kind of person who knows that if you're handed a problem, you'll be able to solve it. That really opens a lot of doors for you as an employee, because if you become known as the person where like, this is really tough, Abbey will just figure it out. then you, you know, you got a little bit of job security. the person, you know, you may get a couple of heart attacks and like prod bugs that you need to solve immediately, but like it helps when, you know, you're having one of those neurodivergent days where you've done 16 hours of work and eight hours yesterday and now you cannot do work. So it's a balance and A study came out recently that was showing that ADHD does have some powerful strengths as long as you recognize that and also feel that that is a strength of yours. It really felt when I was in Paris last year giving the talk at dot JS, about, coding and ADHD where we Excel, like it was a full circle moment for me because I had come so far in about four years from being like, why does my brain not work when I need to do things? Like, why do I get couch locked to? Yeah, I couch locked sometimes, but also I'm taking in all of the information that other brains don't take in. And so I'm able to make all of connections and I'm able to work on things that I'm interested in harder and faster than a lot of people. So it does, it's a give and take. It's like anything else in life where like, yeah, meat suits are great but you also gotta like feed them and water them and like give them sunlight and like, it's how life is. So hopefully that answered your question. It was a long rant for sure. Bethany (39:12) I muted myself. was such a comprehensive answer. And I was just nodding along. For anyone listening, I'm like, yes, this is awesome. I don't have ADHD, but so many of the things you mentioned are things that are beneficial to me, like flexibility and having a remote job and chipping away at things. And I think this just kind of comes full circle to accessibility benefits everyone. Abbey (39:13) Hahaha lol ⁓ Bethany (39:38) that flexibility benefits everyone. And the more we can normalize that and making things work for people and meeting them where they are, like the better the world is, better the internet is and all that. And I think like just the core of that is employers having trust and like trusting you hired the right person and they will get the job done. Like it doesn't matter if they do it the way that 90 % of people do it. It just matters that you give that trust and you convey like requirements and like. that's really all it takes. So I really, really appreciate you sharing all that. Also, yes, negative self-talk. find that I've noticed some colleagues, especially women, often like do negative self-talk. And it's something that like frustrates me so much because it's like you're like you're diminishing yourself in front of other other women, other people like who are younger. And it's like, what what are they taking from that? Like, if you're not good at this, am I not? goodness and things like that. it's like harmful for you, it's harmful for other people, like build each other up, build yourself up and yeah. Abbey (40:42) It's so funny because when people do it in front of me, it's not like I'm like, you know, like it would just be better if like we didn't do it. I'm like, no, I think you're awesome. You think you're awesome. That's not how this works. And so they're like startled and then they're like, you know what? Okay, fine. But I, I, I worked in high volume MSP recruiting for five years before I switched to coding. And one of the things that I tell people a lot is that people are hiring for, you do the job? Bethany (40:57) I love that. I'm stealing it. Abbey (41:09) That's actually whether, like, can you get your work and then do the work and then hand in the work on, like, a deadline and can you keep track of that is really what people are hiring for. And when you can communicate to that more than anything else, that will help you get jobs. Like, I think a lot of people get distracted by, I need to have 30,000 tools on my resume and, I need to know all the languages. And it's like, you need to be able to say that I can solve whatever problem you throw me and, like, I can learn if I don't know it. And that's... That's what people are expecting. So, you know, I say, but the market's a little bit different than it was in 2021. So take that with a grain of salt. Bethany (41:44) Absolutely, absolutely. No, I wish I could put on my resume. I get it done. Yeah, yeah. Absolutely. Well, we are coming up at time, but this has been such an insightful conversation. I really appreciate you sharing your perspectives on all these, sharing all the spicy takes. I love it. I mean, I think that they are very valid takes, honestly. ⁓ Abbey (41:48) I get stuff done. I get it done. Yeah. Thank you. Bethany (42:09) Thank you for sharing. So pivoting into our fun segment, I know like you mentioned that you enjoy coding like fun, little silly dumb projects. And so I figured we could take some time to go around and share maybe what the dumbest thing that we've ever coded was. So I can kick it off. It was tough for me to think of. something because I am just not front-end minded, unfortunately. I feel, I'm trying, I'm trying. But I feel like it's, if you code something dumb on the back end, it's like a production issue waiting to happen or something. So, but the thing I came up with is, it's still a thing now, but there's a website called Battlesnake ⁓ where you basically program an API to. Abbey (42:43) You Mmm. Bethany (42:54) play competitive snake with other people. It's amazing. It's awesome. so that's probably I had a months long fixation on this project. And I was just like throwing everything at the snake. I'm like, how can I make it perform? And how can I make this better than everyone else's? And it never was very good, but I was very about building the best snake that I could. Erika (43:21) I feel like I've never finished any of my dumb projects, because at some point I realize that they're dumb and then I stop. But I did get about like halfway through creating like an exploding kittens game, like an online exploding kittens, which I'm remembering now and like it actually feels less dumb now and feels like something I would pick up again. And yeah, that. Fun- fun done. Brittany Ellich (43:53) That's so smart. I feel like any game you can play remotely, especially after all of the like crossword sessions we have had, like any game you can play remotely is great because remote workers are going to use that as their thing. you know, people are going to get together. I would love to play your exploding kittens game. Erika (43:59) Yeah! ⁓ Okay. Okay, I'll pick it back up. Brittany Ellich (44:12) Please do. Yeah, I think the, I've shared this before already on the podcast, but the likelihood of somebody listening to every single episode is probably quite low. So I think that the dumbest thing I've ever coded is probably my GitHub commit graph GAN website. Only because I thought this was such a great idea when I first did it. And now I am making the graph GAN and realizing how awful it is to actually make this thing because I'm switching colors so often and that's really hard in crochet. I mean, I'm sure it's hard in knitting and stuff too, but like in crochet it's terrible. And I've weaved in like a million ends and I'm like, this was such a bad idea. I'm still gonna finish it. ⁓ But it is definitely what I have been thinking about. was like, this is the dumbest thing I've ever made. Why did I do this to myself? Erika (44:58) you I remember the look of pure joy you had when you thought of this, It really is like a passion project. Brittany Ellich (45:12) Let's go full circle now. I just need to finish it so I can get out of my head and be done with it. Erika (45:20) Once you get to your vibe coding days, it's pure emerald green. Abbey (45:24) Yeah. Brittany Ellich (45:24) Yep, that's true. Abbey (45:26) I was legitimately mad the first time I changed colors in knitting because I was like, there's nothing to this. It's so easy. Why is it so easy? Compared to crochet. There's still weaving in ends, but it's not like a whole, like you have to figure out where the... Anyway, point being, I have two examples. And funnily enough, the finished one is a backend project. When I graduated bootcamp, I was like, I'm done. these skills now. What do want to do? Create a discord bot that will send a dog picture to anyone who mentions a dog in my discord. My husband was like, you know, you have to put commands on that. You can't just like have anyone mentioned a dog and a dog picture show up. And I was like, okay, so they can request dog photos, I guess. That was the thing. And then My sister is engaged and this is her idea and I have to figure out how to make it happen and I'm sorry that I'm calling it Tom Sydney but it is a perfect example. So she wants on her wedding website for there to be a date, the fruit, the fruit a date and it's gonna have a bomb on it. So it's gonna be very concerned. It's gonna be a very scared date and to save the date, the fruit, you have to type in the date of the wedding. And I have to figure out how to make that happen. This is my job as sister of the pride. And I was like, I'm honored and I know about how to do about 50 % of that. So that's going to be fun. ⁓ Yeah. Yeah. So at me, if you have tips, I guess I might have to buy the Josh Camo coins. Brittany Ellich (46:47) This is amazing. Bethany (46:49) Yeah, that's truly incredible. Honestly, All right, well, that is very fun. I'm so excited to see what you come up with there. Please post updates on the Save the Date. And super excited about that. So for wrapping up, where can folks find you? Abbey (46:55) Yeah. will do. So if you can spell Abbey Perini, A-B-B-E-Y-P-E-R-I-N-I.dev.com.shop. got stickers. I got a digital garden. got... .dev has like my upcoming speaking and stuff like that. And then my handle is at Abbey Perini everywhere now, I think. So Blue Sky, things. I'm in places. GitHub. I'm there. You can find me. The SEO is great for this name. Bethany (47:36) Awesome, yes, props for having unique names. But thank you for joining, really, really appreciated our conversations. And to our listeners, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and Discord and share with your friends. Until next week, bye. Abbey (47:39) Thank you. --- ## Episode 42: Making Silly Software with Christina Martinez - URL: https://overcommitted.dev/making-silly-software-with-christina-martinez - Published: 2026-01-13 - Topics: Developer Experience/DevRel, Non-traditional Paths to Tech, Career Development, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/112900179/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-20%2F414727123-44100-2-6d5ab87b7bd4e.mp3 ### Show notes Summary In this episode, the hosts meet with Christina Martinez, a developer experience engineer from Resend, who shares insights on her creative process and current projects. She shares her delight in building silly software and how she's using that to learn in her current role. Takeaways * Christina is the creative mind behind the Gen Z Babel plugin. * She also developed the Swift commits tool. * Taking existing tutorials and adding a creative twist can make them more fun. * Continuous development is important at all parts of your career. Links * Christina Martinez: https://christinacodes.dev [https://christinacodes.dev] * Silly Software Club: https://sillysoftware.club [https://sillysoftware.club] * Resend: https://resend.com/ [https://resend.com/] * Gen Z slang Babel plugin: https://www.instagram.com/reel/Cxvwz76vBus/ [https://www.instagram.com/reel/Cxvwz76vBus/] | https://github.com/christina-de-martinez/babel-plugin-glowup-vibes [https://github.com/christina-de-martinez/babel-plugin-glowup-vibes] * Taylor Swift themed commit linting tool: https://youtube.com/shorts/eOS5Q2I9LHM?si=LC8JVUKTkLgwKtDF [https://youtube.com/shorts/eOS5Q2I9LHM?si=LC8JVUKTkLgwKtDF] | https://github.com/christina-de-martinez/swift-commits [https://github.com/christina-de-martinez/swift-commits] * CodeTV & Mux's Worst Video Player Competition: https://www.mux.com/blog/actual-worst-video-player [https://www.mux.com/blog/actual-worst-video-player] * React Miami: https://www.reactmiami.com/ [https://www.reactmiami.com/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommit podcast, your weekly dose of real engineering conversations. I am your host this week, Erica, and I'm joined by... Brittany Ellich (00:08) Hey, I'm Brittany. Bethany (00:09) Hi, I'm Bethany. Erika (00:10) The three of us met while working on a team at GitHub and quickly realized we are all obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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 Christina Martinez, a developer experience engineer from Resend and a passionate advocate for making silly software. So welcome, Christina! Christina Martinez (00:43) Thank you, I'm excited to be here. Erika (00:45) To kick us off, what's one thing you are currently building or obsessed with learning with right now? Christina Martinez (00:50) Yeah, well, I'll start with something mostly aimed at Brittany right now. We are fiber arts friends. She crochets and I knit. So I'm learning how to make custom knitting patterns. So I made my recent sock. So that's one thing. And then I have two others. One is I'm getting really into old electronic nostalgia lately. So you can see if you're listening, have like a... Macintosh from 1995 behind me in my office and I'm working on getting that online. I bought an iPod Nano recently, so working on that. And then the third thing is events. I've been to a ton of events with my new job at Resend and now we're working on organizing some more like dev meetups and things like that for 2026. And so really breaking down like what makes events worthwhile and fun and exciting to go to and figuring out all the logistics. So that's been a new challenge for me. I've been in just a software engineering role for quite a while. And so it's like new kind of soft skills challenges, which has been interesting. Erika (01:53) very cool. Yeah, I always feel like the end of the year there's a lot of nostalgia with like the year look back in general. But yeah, anything like early tech is also fun. I was reminded of the like 2000s music video moment where like the Kelly Rowland was like texting, trying to like text through an Excel spreadsheet on her like Nokia. Yeah, and that one music video. Anyway, I had forgotten about that. I responded about it this morning. I was like, oh my gosh, that's so funny. Yeah. Christina Martinez (02:24) It's always so fun to look back at old movies and stuff and see the tech that they had. It's just great. Erika (02:29) Yeah, Reminder that we're all human and tech moves fast. Cool. Well, we have to ask about some of these really fun projects that you have. done in your time as a software engineer. You are the creative mind behind the Gen Z Babel plugin and the ⁓ Swift commits tool. And you say that you're kind of on this big. push for silly software and that you prefer it over standard corporate apps. So what's kind of the creative process there? Are you actively hunting for ways to make coding a little more fun and ridiculous, or did the ideas kind of come as a natural discovery? Christina Martinez (03:16) I think it comes kind of naturally. I appreciate kind of like boring software and even like the company that I work for that could be categorized as boring, it's emails. And that's really important to keep the infrastructure intact and working how it should be. But I think it makes it really fun and exciting to work on things that are a little more creative. so, yeah, I think I use... silly software in two ways. One is like, I just learned a concept. I want to apply it somehow and kind of like practice, but I want to make it kind of fun instead of just building like another to do app or a calculator app or something. And so one example of that was I wanted to learn about web sockets. And so that's when I built the mux worst video player that we can talk about a little later, but I wanted to see how can I use this technology to make something that's really cursed and terrible and fun and funny. And so that's one way, is starting with the technology. And then the second way is starting with an idea that I wanted to get to. So the Babble plugin that you were talking about, started with just a joke Instagram video from someone else, ⁓ a guy named Justin. And he... was making a joke about what if people could code in Gen Z slang. And I was like, I bet you could totally make that happen. And so found a way to make it happen by figuring out what tools you could use. And so those are my two approaches. But I like to add a little twist so that it's a little more interesting than just doing the same thing and following a tutorial or whatever it may be. Erika (04:51) For sure, yeah. Well, that's a good perspective. It's not even necessarily like the... It sounds like it is the software, but it's also kind of the approach and the mindset. You can kind of find joy in either the idea or the way you're going about it. yeah, make it fun. Yeah, worst actual, it's the actual worst video player is hilarious. So it's the idea, like, you literally make everyone suffer when one person pauses the video. Christina Martinez (05:25) yeah, yep. Yeah, it was a kind of a hackathon style, like competition for mucks. And they were trying to see who could build the worst video player with their tools. And obviously like it still had to work, but it needed to be terrible. So yeah, was all the controls are complicated and, and you control the experience for everyone else. So that was a really fun project to work on. And I learned a lot about WebSockets. Erika (05:49) Nice. So that one you worked on by yourself in like a hackathon style, but you've also collaborated with other people on some of these other projects. So how does that energy change when you're working on something by yourself versus collaborating with somebody else or a team? Christina Martinez (06:08) Yeah, I think when you're working on things by yourself, you have more control over the project itself and the ways that it's going to go and what the final product is. But it can also be really fun and empowering to find someone that's like-minded and has a similar goal and things that they want to learn as well. And they're able to take the projects in ways that you could never expect. And I think of it as like... I'm not a comedian at all, with improv comedy, it's like a yes and type of attitude where people like add on to your idea. And I think finding someone that's like that and you're able to kind of like riff off each other and make the project better. I think that's what you need to look for when you're looking for a partner or like group to work on things and hackathons or just side projects like this. Erika (06:54) Cool. And I mentioned the Swift commits tool. Do you want to describe that one? Christina Martinez (07:00) Yeah, that's just, if you've used better commits, it's just a fork of that. The goal of better commits is to actually make your commit messages better with the semantic commit styling. But this one is a Taylor Swift version of that. So you choose the era that you want to use, and then you can choose different lyrics. And it needs to describe how you feel about your code. And then that's your commit message. Yeah, that was a fun project. I pulled a lot of my favorite quotes out of her songs for that and it was great. I don't think anyone has ever used it, so that's okay. Brittany Ellich (07:33) I have to now though. Christina Martinez (07:35) Yeah, Bethany (07:36) Yeah, Christina Martinez (07:36) I Bethany (07:36) I was going to say. Christina Martinez (07:36) want this in production at GitHub, you know? Bethany (07:38) Yeah, we'll have to pull some strings. Christina Martinez (07:40) You Bethany (07:41) Speaking of that intersection of work and silliness and things like that, I'm curious if you have any tools or tricks on how to bring joy to your day-to-day work if you try to bring that levity into your daily job or if you're like, ⁓ no, this is just for my side projects and I'm treating work in a different way. Christina Martinez (08:07) ⁓ yeah, I think I'd say the side projects are a way sort of to get it out of my system a little bit so that I can be serious at work. So I'm not like the class clown at work, like trying to be silly all the time. but yeah, I do try to be human at work and not just, you know, clock in and clock out that type of thing. So relationships at work are really important for me. I like to have friends and, get along and be lighthearted and things. But yeah, like I think the team that you work for and the bosses that you work for are really important to me personally. And I would take a much lower salary just to be at a place where I feel kind of at home and trusted and that I can trust my team and that sort of thing. So finding the right spot to be is just so important. Bethany (08:53) Yeah, absolutely. think fun is such a core aspect to how a team works together. Like if a team can have fun together, that's, I think, the sign of a healthy team. So I like that, like take your work seriously, but like be human, have fun, joke around. Yeah, that makes sense. Do you think that by being a developer experience engineer, Christina Martinez (09:03) Good one. Bethany (09:15) allows you to have more of that fun than maybe a traditional software engineering role or was it just something that you felt was more tailored to your experience or your skill set? Christina Martinez (09:25) Yeah, I do think it provides more opportunities. I started in marketing and kind of like learned to code on the side while I was doing this marketing job at a tech company and got into coding that way. So then I was a software engineer and led a small team and that sort of thing for some time. And now I'm back kind of almost in the middle of those two things. And it's been really fun so far to work on code still and need to use my technical skills as well. But be back in a little bit of a role where it's like more creative, some soft skills, getting to have a big say in the product by talking to customers and seeing what they want and need from our tools, that sort of thing. Resend has been very kind to me with allowing me different creative opportunities. Like at SuperBase Select this year, I built like an installation, like an interactive type of exhibit where we printed out a bunch of like famous emails or emails that changed the world is what we called it. And people could go and hang those on the wall, like their favorite emails. And this included like... the first email sent from space, the first spam email. Queen Elizabeth II was the first head of state to send an email, and so there's one from her, stuff like that. so people could print them out, put them on the wall, they could take it home in a frame, and it was like a really fun project for me to work on. And so I feel like those types of things are really interesting to me, aside from just coding all the time, which is also a fun, creative... job, but it's just like a nice mix of the two. Bethany (10:59) That makes so much sense. That's really cool that you're able to combine all your experience to this one job that's almost tailored to you. What drove you to? Yeah, which is so cool. I love when that happens because it's sometimes when you switch positions, mean, a lot of us switched from what we thought we were going to be. You're like, well, did I just waste all those years of doing something else? ⁓ Christina Martinez (11:07) Yeah, this feels very custom fit for me. Bethany (11:25) but usually it actually is a superpower in a way towards the, as you move on. So that's so cool. ⁓ Christina Martinez (11:31) Yeah, it does feel strange to be coding less because at part of my career, I had made that decision. It was like a fork in the road of like, okay, no, I want to be an engineer. And so I moved into that and away from marketing. So it feels weird to go kind of like back a little bit, but it's not a regression so far. It's been really empowering and fun and a cool job. Bethany (11:53) Absolutely. I mean, it's all valuable skills in the long run. And it's all valuable things for developers and making people happy at the end of the day. So I think that's really cool. What drove you to learn the technical side of things for marketing? Was there any key switch that led you down that path? Christina Martinez (12:13) Yeah, I, in my marketing job, I was mostly like kind of a project manager type of role where I was coordinating different promotions and campaigns that we had. And one of the jobs that we had to do like pretty infrequently, but still like probably once a month or so we would have to edit like these just really basic HTML pages and swap out some products and like change things around. And when the graphic designers would come to me and say like, Hey, can we add some padding here or like change a color. I had no idea what I was doing and I hated that. It just felt terrible to be really bad at a part of my job ⁓ that was recurrent, even though it was like so rare. So after a rough ⁓ Black Friday season where I was like pulled away from my family trying to edit pages and this sort of thing, I... decided that I needed to learn and just like buckle down. And I expected to hate every minute of it. I joined this code academy course and it was like a learning path or something like that. But almost like a very mini like self-paced bootcamp. And after that, I learned everything that I needed to know for that marketing job, but I fell in love with coding. It was so just empowering to start with an empty file and end up with whatever was in my brain basically. And so that just got me hooked and I couldn't set it down. So it was like my side hobby. I asked my company that I was working for if I could just like practice a couple hours a week. So they gave me little jobs that I could do. And then that turned into a job offer on like a MarTech front end team and then eventually a product team that was a full stack job. So that was, that's kind of my path. It's a weird kind of roundabout path, but I'm really glad that it happened. was a lot of fun to learn that way. They were so kind to me to allow me those opportunities and take chances on me when I was so green and fresh. Bethany (14:04) Yeah, I think those kinds of things are so nice when that happens because it's, I mean, when you go to college, you go the traditional path. Sometimes you are passionate about it, but usually it's for like a greater good of earning money or doing whatnot, which still you got to earn money. But like when you're doing it through that route, it's something that it's truly out of passion. It's truly out of like an interest. And I think that's such a great motive for it. doing like the like technical things or programming and stuff like that. So that is so cool. Is there anything that you're wanting to or you're feeling like you should learn more today or anything that's like on your radar to learn more about moving forward? Christina Martinez (14:36) Yeah, definitely. Yeah, I mean, I'm always trying to work on my technical skills, even though nowadays I'm using them a little bit less than at my pure software engineering job. but I think kind of like I mentioned before, the events has been really big on my mind. ⁓ my company is fairly small. have, I think 29 employees now. but we're growing a lot and wanting to host more events and be more involved in a community. And so trying to solve that puzzle where we haven't really had. that at all before and I'm not used to it either. It's not been a focus of mine at all. I think that's been something that's really interesting to me. So I've been to several events this past, I don't know, six months or so and looking to host our own starting in January. So that'll be so exciting. Brittany Ellich (15:30) That's awesome. You'll definitely have to let us know once you have some scheduled, if there are any that we can help share. ⁓ I met a bunch of the recent team at Cascadia JS this year and they're all super cool. Yeah, in 3D, where people actually have bodies. was weird. So one of the themes that I feel like we come back to a lot. Christina Martinez (15:36) Yeah. Mm-hmm. Yeah, it was good to see you in real life. Yeah, real person. Brittany Ellich (15:56) on this show is like the idea of storytelling. And it sounds like with your marketing background, like you probably have like an opinion about how, you know, a narrative is really important for, you know, telling a story, even as an engineer, even if you're like doing something really technical. So I'm curious what your thoughts are on like storytelling and investing in those, that skill set as a software engineer or ⁓ as an engineer who's like blending marketing and engineering like you are now. Christina Martinez (16:22) Yeah, I think it is really overlooked. A lot of times we focus on building the coolest thing possible and we pour all our energy into it. And then when it gets to sharing it, we just don't know what to do, I guess. And so then it doesn't really go anywhere because people don't know that they should be excited about it or spend time learning about it. And so I guess one example of storytelling being involved in the product decisions, I guess, is that Mux video player that I did. The tech itself wasn't anything impressive or exciting, really. It was more about the story that helped the random controls come together in a cohesive thing that you could talk about. So I could just have a bunch of random controls that are just really terrible, and that's also like... of a cursed video player, but I made it into a story about like, this is inspired by those group projects in school that everyone hates where like, one person's input can like negatively impact everyone else. And so that kind of drove all of the decisions that I made as I was trying to figure out like, what controls to add and that sort of thing. But I feel like that helped sell it a little bit more and helped ⁓ It was a competition so I ended up winning the competition and flying to New York for Versailleship and they like Treated me so well the entire time. It was so great but yeah, I guess like being able to sell your story and it like I don't know it sounds like I'm being very like marketing business person right now of like talking about selling and stuff but You need to think of it as not just being like a salesperson, like faithfully telling the story of like what the product is and like why you're so excited about it. And I think that helps people to understand more of where you're coming from and get excited with you about this thing that you built. Brittany Ellich (18:16) Yeah, for sure. I feel like that's super important. And yeah, I get the hesitation around calling it like selling. But I feel like it's important not only for, when you release a product to the external world, you know, where you might hopefully you have some marketing support to like talk about it. But it's also important internally. I've read so many posts like internal announcements where it's like, here's the thing and we shipped this thing and now it is shipped. And it's like, okay, like. Great, like why do we care about it? Like how many customers is it gonna solve? Like what are their pain points and like how does this address them? ⁓ I feel like having that narrative around what it is is like a very important skill regardless of where you're at in your career. So. Christina Martinez (18:54) Yeah, there's just so much to care about all the time that people have to be selective and choose what are the most important things. So I feel like that's the main goal of like creating a story. Brittany Ellich (19:03) Yeah, absolutely. Are there any other skills that you feel like you've sort of like have as a little bit of a superpower having that marketing background that like crossover to engineering other than the narrative and storytelling? Christina Martinez (19:16) ⁓ that's a good question. think, since, I don't know, there's like a stereotype of what software engineers are, which is not true at all, by the way. But like, I never got into the software engineering growing up and stuff, even though there were several signs along the way that maybe it would be an interesting career for me, just because I didn't see myself as like a math person or- someone who's really into Star Trek or like, you know, that sort of thing. And so I think I bring like different soft skills and things that aren't always present with engineers. But as I've like kind of gotten deeper into this career path, I found that many of them are that way anyways. And it's just like a stereotype that, you know, you'd have to be really into math or like, yeah, that. you've been building computers in your mom's basement since you were 12 or whatever the thing is. But yeah, I think like being able to connect people and build relationships and stuff has been like a fun surprise for me at my last company when I was an engineer. I had friends at work, but we didn't really go out into the broader like tech industry as a whole. We were kind of like siloed on our own. And so in this new role, it's been really fun to meet people from different companies and go to conferences and like start to form those relationships. And that's caught me off guard, especially as an introvert that I just wasn't expecting that that would be a superpower of mine, I guess. Brittany Ellich (20:42) Yeah, it's amazing how much talking you actually have to do in this role where, you know, everybody's like, you're only using a computer. No, there's, there's a lot involved in getting people on board and, ⁓ yeah. Yeah. That makes sense. ⁓ and speaking of events, you are going to be speaking at React Miami, correct? Is this your first speaking role or have you done these in the past? Christina Martinez (20:53) Yeah. Yeah, I am, yeah. It's my first one. I'm really nervous. Any tips? Let me know. Brittany Ellich (21:08) Congrats. ⁓ That's awesome. Congrats. What made you want to like sign up? Do you know what you're talking about already or? Christina Martinez (21:16) I do know what I'm talking about already. I'm gonna try to convince people that they should build more silly software. So kind of have a theme going here. But I didn't really sign up. I met Michelle, the organizer of React Miami, this summer at at Versailleship. And we got along great and kept in contact afterwards and stuff, and she asked me to speak and so... that's what's gonna happen. So I think I'm scared to death about it. I am not a public speaker. I've never done anything like this before, but I think that being scared of something is not a good reason to not try it. And so I'm gonna see. And if I hate it, I'll never do another talk again. So we'll see. Brittany Ellich (21:57) Yeah, there you go. Yeah, I don't think anybody would be like, no, you have to do more speaking. ⁓ Yeah, I think that speaking at tech events has been like one of the most fun ways to get involved at them in my experience. And like, I've never been to one where there are people in the audience like actively saying, no, this person sucks. Like everybody's always like cheering for you, especially with that topic. That's gonna be, yeah, everybody's gonna be super excited about it. Christina Martinez (22:02) Yeah. Okay, that's good to hear. Yeah, because you've spoken quite a bit, right? Brittany Ellich (22:26) this last year was the first time I've done, quite a bit. And yeah, I did like a couple of like meetups and like larger than meetups before that. And now this last year, I actually just hung up some conference badges yesterday and it's like, wow, I've got like a little collection going. I feel like a big kid now. ⁓ I've done a few and yeah, I, ⁓ I want to keep doing more. So hopefully you'll get the same bug and you're like, yes, this is the way to engage in events. And, ⁓ yeah. Christina Martinez (22:41) fun. Yeah, yeah, that's good to hear because I think I'm just like focusing on myself and what my experience is going to be and so it'll be nice to engage in a different way in those events. So that's a good way to look at it. Erika (23:01) Mm. Well, we are going to switch gears here at the end. This has all been fun, but we have a segment specifically dedicated to talking about something we think is fun and interesting and potentially not strictly software related. And you mentioned that you studied abroad in Spain for a year. You actually owned a business in Spain. So and you said you'd always go back there whenever given a chance. So selfishly I want some travel tips and ideas and we'll all go around Robin's style and share our favorite place in the world where we would recommend everyone goes if they have a chance. So I can start. I've been lucky enough to go to Switzerland twice. My heritage, my family's heritage is Swiss. And it's like everything I love. Like it's so like healthy, like the air is... wonderfully fresh and like clean and you you spend your days like hiking and there's like cows and cute little chalets and would literally go anytime at the drop of a hat. So I don't have like a specific place in Switzerland. I was like younger when I went so I don't even really remember exactly which cities. So I'm gonna say the country of Switzerland which leaves it very broad but yeah outdoorsy activities in Switzerland is my my recommendation. Brittany Ellich (24:32) I can go next. Yep. Okay. Cool. My recommendation is, well, I would say not as far, but I guess it depends on where you're listening from. Because if you're in Europe, Switzerland's probably more easier to get to. But my recommendation is Hood River, Oregon, which probably doesn't sound like... super exciting. But like if I were to buy a vacation home somewhere, it would absolutely be there. It's on the Columbia River Gorge, which is the river between Oregon and Washington. I try to go at least once a year just to go there. And like it's on this beautiful river, like with all these canyons around and they have a lot of, they have what's called the fruit loop there where there's all these different farms you can stop at and they just grow so much fruit there that it's like super fun. the summer to go like farm to farm to just pick up different fruits whatever they specialize in. Lots of wine tasting and just some of the most gorgeous mountain views and river views and nice people so highly recommend that one. Bethany (25:32) Oregon genuinely is like one of the most incredible places, the Pacific Northwest in general. I fell in love there. My mind went in so many different places, so I'm just gonna kind of be a little chaotic with it. Part of me is selfish and wants everybody to come to Charlotte, where I live because I think that it's underrated and I love it and I want other people to love it too. But... for a more exciting, I guess, or out there, recs. I was really surprised by Boston. Me and my husband decided to go there on a whim and it was actually really fun, like, super historic but also very modern and it just was a really cool vibe. And then Japan, I feel like everybody who's been to Japan has to recommend it, but it truly was so special. We went to Tokyo and Kyoto and it was such a cool culture to... to realize and kind of what you were talking about, Christina, about like forcing yourself to be a little uncomfortable in places. Like you're like, oh, I don't really, I don't know Japanese. I don't know the language. I don't know like all the customs or anything. And so it's cool to kind of like push yourself and explore beyond what your comfort zone is. that was definitely like an, stretching myself and stretching my comfort zone. And it was so special, hoping to go back soon. Christina Martinez (26:42) Man, I'm jealous of Japan. I've been lobbying the powers that be at Resend that our next offsite needs to be in Japan, so we'll see. My recommendation is Spain, like you mentioned. I am obsessed with Spain. I love it so much. I've spent some time there and I think there's many good places to go. I think the most, like, classically Spanish with, like, all the architecture and the, like, flamenco and all the things that you think of. and like most highest concentration of like interesting things to look at and do would be Sevilla and I think though like the city that's closest to my heart is Malaga which is just like on the coast. It's like the perfect city in my opinion. It's right on the beach and has great weather, walkable and like interesting museums and things to do and so that's like that's really close to where I lived when I was in Spain. But those are two of my recommendations. And you can go on a trip and see them both in the same trip because they're pretty close by. So yeah, I think that's my recommendation. Erika (27:41) Definitely adding it to the list. Well, thank you again, Christina, for joining us. Where is the best place for people to find you on the internet? Christina Martinez (27:50) I think ⁓ ChristinaCodes.dev has all the other links to go elsewhere. And I'm launching a new newsletter at SillySoftware.club. Hasn't been released yet. Hopefully by the time that this episode airs, it will be. But yeah. Erika (28:06) Thank you listeners for tuning in to Overcommit It. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Quick plug for our book club. Whatever time you're listening to this. it's kicking off in mid-December and by the time this comes out it'll probably be running for a bit and there's great content to catch up on, discussions, yeah great great book club content to engage with so definitely check it out and until next week, goodbye! --- ## Episode 41: Building Without the Buzzwords: Real Talk on System Design with Bassem Dghaidi - URL: https://overcommitted.dev/building-without-the-buzzwords-real-talk-on-system-design-with-bassem-dghaidi - Published: 2026-01-06 - Topics: Technical Deep Dives, Open Source & GitHub, Career Development, Developer Experience/DevRel - Audio: https://anchor.fm/s/102586d64/podcast/play/112899481/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-0-4%2F415443657-44100-2-dc4a5f854bd85.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Brittany and Bethany with guest Bassem Dghaidi discuss a range of topics from Bassem's current learning journey in system design to his diverse career path at GitHub. They explore the value of experience over formal education, the challenges of microservices, and the importance of practical knowledge in software engineering. Bassem shares insights from his technical content creation, his philosophy as a de-influencer in the tech space, and memorable conversations with industry leaders. Takeaways * Bassem's career has included various roles, enhancing his perspective. * Experience in different roles provides a broader understanding of software engineering. * Education is valuable, but practical experience often outweighs formal credentials. * Bootcamps can bridge the gap for graduates lacking practical skills. * Bassem's Git content aims to demystify complex concepts. * Microservices can complicate development if implemented prematurely. * Content creation in tech requires balancing depth with audience engagement. Links * Bassem Dghaidi: https://linktr.ee/glich.stream [https://linktr.ee/glich.stream] * Beyond Coding podcast episode: https://www.youtube.com/watch?v=LeUUxLRdvho [https://www.youtube.com/watch?v=LeUUxLRdvho] * Practical System Design Waitlist: https://maven.com/forms/b69857 [https://maven.com/forms/b69857] * Kamran Ahmed's site: https://roadmap.sh [https://roadmap.sh] * Ghostty: https://ghostty.org/ [https://ghostty.org/] * Catppuccin themes: https://catppuccin.com/ [https://catppuccin.com/] * Chezmoi: https://www.chezmoi.io/ [https://www.chezmoi.io/] * Tmux: https://github.com/tmux/tmux/wiki [https://github.com/tmux/tmux/wiki] * Bethany's dotfiles: https://github.com/bethanyj28/dotfiles [https://github.com/bethanyj28/dotfiles] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Brittany Ellich (00:02) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I am your host, Brittany, and I am joined by... Bethany (00:10) Hey, I'm Bethany. Brittany Ellich (00:13) We met while working on a team at GitHub and realized that we were all obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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 Bassem Dghaidi senior software engineer at GitHub, building the next generation of GitHub actions and content creator at glitch.stream. He's not only one of our colleagues from our actions days, but we thoroughly, that we thoroughly enjoyed working with. He's also a self-described de-influencer who isn't afraid to challenge tech hype and push back on conventional wisdom. Bassem welcome. Bassem (00:58) Thank you for having me. Brittany Ellich (01:01) All right, to kick us off, this is something that we ask everybody, what is one thing you're currently building or obsessed with learning right now? Bassem (01:09) ⁓ It's a lot of different things to be honest. I've been working very thoroughly on my system design course. So I've been doing a lot of different deep dives into distinct areas of the distributed systems. And then you think that you know a lot about a certain topic until you really have to start teaching it. And then you realize, I know very little actually. ⁓ So yeah, I'm doing a lot of deep dives into databases, database management systems, how the internals of databases, how do we optimize them? How do we scale? but also event streaming, Kafka, consensus algorithms, actual distributed system stuff, a deep discussion of causality and determinism. That was one fun video that I created recently and I'm still, have yet to finish it for that particular course. So it's a lot of fun stuff. Brittany Ellich (01:58) That sounds really interesting and I actually can't wait to take that because I feel like I will learn a lot from that even being like an experienced engineer because that's always an area where you can learn a lot more from. So that sounds cool. Yes. Bassem (02:09) There's always nuance and details, yeah, for sure. Brittany Ellich (02:13) ⁓ I understand you originally started at GitHub as a solution architect, correct? Then went back to a software engineer. Is there anything that you learned or gained from that experience? Bassem (02:24) Yeah, my entire career honestly has been fluctuating between different types of roles in the industry. I started writing code when I was 12 and I've been a developer since and I built a lot of experience freelancing, but also working in different types of companies, startups, ⁓ medium scale SMBs and also bigger enterprises. ⁓ And yeah, when I joined GitHub, a recruiter reached out and they're like, and I was working as a solution architect prior in a consulting firm here in the Netherlands. ⁓ So it was just a continuation of that particular function. And the way I saw the role of the solution architect was, in my head at least, we were just working with distinct customers, and not necessarily at GitHub, but prior to that. And I was leading an entire team of software engineers, and we were literally building an entire bank in Bahrain. And that was a fun thing. And then the recruiter reached out and they're like, GitHub. I'm like, but I want to finish that project first. But also GitHub is not something you would say no to. So I was like, yeah, well, let's see. We did the interviews. Everything went well. The team really liked me. And I joined GitHub. And it was one of the best decisions I've made for my career. As a solution architect within GitHub, it was pretty fun to work with a ton of our enterprise customers, not just on how to properly use Git, but how to scale a Git usage internally, how to navigate get up actions and scale adoption within the organization. But also working on a lot of the friction points that they have and coming up with actual technical solutions for problems that they are facing with the use of the product or ⁓ using best practices from the industry also to refine their SDLC and how to optimize how they work ⁓ to be a bit more effective and just ship faster and better. Brittany Ellich (04:12) Gotcha. That seems like it would be really helpful background knowledge for shipping code within GitHub too, to know like this is how customers actually use it. So. Bassem (04:20) It definitely gives you perspective and it gives you a thing that a lot of software engineers miss out on, which is having this tunnel vision on how we do things and they start becoming a bit more focused on one way of doing things. But if you work in the industry and see how other companies ship as well, and maybe even advise them on how they can define things, you just get a much broader perspective ⁓ on how things are done. And I've always been a software engineer at heart, but I was never, I never shied away from exploring other functions because I'm a holistic learner. and I do enjoy seeing the big picture and seeing things end to end, including the business functions and whatnot. And all of my opinions on software engineering are now shaped by that perspective that I've gained through fulfilling different roles ⁓ across my years of working in this industry. Brittany Ellich (05:08) Gotcha. And then do you feel like you were like pushed towards any of those roles or are those things that you actively sought out and like, you know what, I'm going to try being a solution architect for a while and see if that helps me learn more or how did that work out? Bassem (05:21) Opportunities were presented and I chased them. I wouldn't say that I necessarily sought after being a solution architect or something like that. The function was not even on my radar. And the problematic part about our industry is the inconsistency of how we apply titles to functions. Titles don't necessarily reflect what you do, and a software engineer somewhere is not the same as somewhere else, and a solution architect somewhere is not the same as somewhere else. ⁓ So no, I did not seek these particular roles, but I did seek the expansion of my knowledge and the expansion of my perspective. And I never escaped or ran away or tried to pigeonhole myself into a specific... niche that I thought like this is it, this is my identity, all of my identity is associated to this, no, so I actually don't mind exploring. Brittany Ellich (06:12) Yeah, that makes a lot of sense. I feel that very deeply. I think my first senior engineer role, quote unquote, I was when I had like nine months of experience. So talk about imposter syndrome, but that was just a place where, you know, everybody was a senior engineer starting out and that was just the way they did their titles. So. Bassem (06:30) Yeah, it's a bit of a shame because it dilutes a bit, you know, the title in a way, and it creates a bit of confusion on what it means. And internally, you feel like, I didn't really earn it yet. But at the same time, I feel like I've done enough to consider myself mid-career or even senior. So I understand it. But I also worry that standardizing this across the industry is not also productive. ⁓ So what matters for me more importantly than the title is how does the engineer or is that engineer capable of describing their actual impact and why they are at that level and whether they can justify with what they built, you know, the title that they've gotten. Brittany Ellich (07:15) Yeah, yeah, I think that makes a lot of sense. And I think you are a self-taught drill developer, correct? Is that? Bassem (07:21) Yeah. I did actually go through a computer science program and I studied for one year before dropping out. Financial reasons and ⁓ taking on a ton of debt to get a degree was not on my radar. So I was like, yeah, I've been doing this already. I've been freelancing since I was 15 and writing code for other people. So why not just join and get my career started? And I was lucky enough that when I started my career, companies were a bit more receptive to folks who did not have a degree. And the idea of having that traditional path started to f- was phased out a little bit. It was a big worry for me, honestly, but ⁓ things worked out and I rode the wave from 2007, eight and until 2024. And at some point in time, credentials don't matter as much. And nobody's gonna ask you about your GPA at school or even bother to ask you about your college degree and whatnot. Brittany Ellich (08:14) Yeah, yeah, that's valid. Do think that that's still the case? Or like if somebody getting into the industry right now, like would they be better off with a degree? Or do think it still doesn't matter? Bassem (08:24) You're always better off with a degree, not necessarily because the education that you're going to get there is you cannot get it any other way. I did study all of my computer science material, and I know a lot of topics much more in depth than a computer science graduate from today. I have a ton of experience in so many different domains. it's not about the degree is a logistical element that you need to have. In a lot of countries, if you don't have developed countries, passport privilege like mine, for example, I come from Lebanon originally. You're going to need your degree to justify that you are a high skilled migrant, for example. You're going to need your degree to get a lot of paperwork done. A lot of these immigration offices don't really understand experience. And then justifying experience is much more difficult than credentialism, where you could just slap a paper and say, hey, I picked that box. So in that regard, I do recommend people to actually go through the traditional paths until we have enough rebels to disrupt the educational system the way it is. But that's going to be a bit tougher than just getting a degree. ⁓ So if you want to work three times harder than everybody else to continue reestablishing yourself over and over again, don't get a degree. ⁓ Not saying that you're not going to have to work hard after you get it, but it's going to make a lot of logistical things just much easier for you. Bethany (09:45) Yeah, that definitely makes sense. It's unfortunate this inequity with education and basically folks who can afford it being able to like get that solidity to check that box. So it is definitely a huge problem. I mean, American all over the world, of course. ⁓ Bassem (10:04) Yeah, it is a problem in my country as well, which is one of the reasons why I started a boot camp in 2018. It's called SC Factory, and that boot camp was a bit different than other boot camps. It was taking fresh computer science and engineering graduates. These folks were able to actually get their degrees in some form or another, even from second, third, or fourth year universities. The problem that they had is they were not really equipped to enter the job and even with their degrees, they were not really ready. And that boot camp was basically an acceleration of their careers. So basically crunching two years of experience in a 14 week program. And that gave them much, much more leverage to penetrate the market with. yeah, lack of equity and ⁓ equality is prevalent even in developing countries and a lot of regions across the globe. We need to do more on that front for sure. Bethany (11:04) Absolutely. That's so cool to learn about that bootcamp. That's really awesome. ⁓ Bassem (11:09) Yeah, it was very successful. Even one of my students is now my colleague at GitHub, which was really a big milestone, which is really funny ⁓ and really cool to see, to be honest. And a lot of the students did really well for themselves. Bethany (11:25) That is so cool. wow. Nice. So I guess pivoting to some technical deep dives, ⁓ you've published some content on rebuilding Git from scratch in Go and diving into the .git folder. ⁓ I'm very curious what originally pulled you down that path, and ⁓ was there anything surprising about ⁓ making that content? Bassem (11:54) One of my biggest regrets is the fact that I never really finished that series. Hopefully I'll go back to it one day. But if you build content for YouTube, never promise a series until you actually finish it and you're ready to publish it. Because once you start, ⁓ it becomes much more difficult to maintain the pace and momentum. And then you get distracted by other shiny new stuff. But the reason why I started that series is educational for me first. And I like to learn in public sometimes. So a lot of my live streamed series are literally just that. learning in public and ⁓ we work at GitHub, right? And it's a shame, not a shame, but it's like for me, it's like it makes sense to really understand Git at a deeper level than just being a regular consumer. And the best way to actually do that is not by reading about the internals because they're always going to be abstract, but actually rebuilding it and rewriting it is a fantastic learning opportunity to really absorb the trade-offs, some of the decision-making and to demystify the technology underneath, right? If you dive into, if you watch the video where I dove into the contents of the .git folder, you actually realize, ⁓ this is much simpler than I thought, but it's actually really cool that this whole thing works and that it scales to the sizes that it does. And I've been working with lot of customers within GitHub and my function as a Solution Architect on scaling Git and working with large monorepos and whatnot. And we used to do a lot of optimization. and think about repacking and how to clean up their history and how to do a lot of history rewriting and all of that stuff. And we've been using tools, but these tools have always been too abstract and like, what's going on really underneath? So that was the motivation for starting that series. And I have no regrets on diving deeper into it. And it also helped me sharpen my go skills. ⁓ Although I really need to go back to it and finish it because... ⁓ there's a lot more to do there. We got to the point where we built the internal database, we were able to do our first commit, we were building the Merkle trees, but we never got beyond that point. And I think the cooler stuff starts when you really need to start thinking about rebasing, merging, and ⁓ all of the concurrent type functions and activities for good, yeah. Bethany (14:14) That definitely makes sense. is one of those tools that it's very, I mean, I know if you have no experience looking at it, it's very overwhelming, but it's one of those things that combines a very massive, elegant system behind a few simple commands. And it's just really incredible that you can go as shallow or as deep as you need to. But when you get in those situations where you need to scale it, it's so important to understand the system behind all those commands. ⁓ Was there any one Git command or concept that ⁓ you found was commonly misunderstood among developers? Bassem (14:55) It's not a discovery, but I think a lot of developers really struggle to conceptualize Git Treebase. For some reason, it's a bit of a struggle for them to understand. I kind of get it. ⁓ I think the representation of the Git trees in the people's minds as an abstract data type, it's a bit hard to conceptualize in how the commits relate to the tree and how... People don't have a visual map of the tree in their heads. And I think some of the visualizations that were published around this topic aren't really that helpful in the sense that... it's very difficult to understand where like where's the beginning and how commits are chained together and what happens if you break the pattern tree and the parent relationship between different commits and whatnot, which makes rebasing what are we basing what onto what and the semantics of it make it a little bit more complicated than it actually is. And that confuses a lot of people. So I think. It's not, as a concept, it's not very difficult to wrap your head around. I think the semantics of the CLI make it a bit harder for people to grasp. And the lack of knowledge of the internals of Git also makes it a bit harder to grasp. But effectively, it's a very simple thing. Bethany (16:13) That makes a lot of sense. I am one of those developers that avoids rebasing at all costs. So maybe I need to watch your video and try to understand rebasing better. ⁓ Bassem (16:25) It definitely helps once you understand how the commits are chained together and how you can restructure the parent relationship between the commits and how they are actually stored on disk internally and what a rebase actually does and maybe even creating that function yourself. We never got to it in the video series. Hopefully we will someday. ⁓ But it's much simpler than you think, yeah. Bethany (16:51) That makes sense. ⁓ So pivoting a little to microservices, everybody's favorite, ⁓ favorite controversial word. ⁓ You made a video ⁓ called microservices, more problems than solutions? ⁓ Question mark. ⁓ And ⁓ you take a position in that video. So I'm curious if you have any, what your typical recommendations are for when a company should approach microservices or when it is a viable solution. ⁓ And if there's any gotchas that folks commonly walk into with microservices and have, has your opinion changed over time? Bassem (17:39) ⁓ Funny. My opinion has not changed over time. I still hold that position that microservices are more problem than solutions for the following reasons. Microservices are ⁓ not a software architecture pattern as much as they are a remapping of an organizational structure onto ⁓ systems and these microservices aim to solve organizational inefficiencies and they aim to solve the problem of concurrent shipping or building features across a team of engineers within an organization or a company. And a lot of engineers mistake the idea of microservice and they think it's a solution to scale technically, might not necessarily be so. It's a solution to scale organizations to be able to ship more effectively. And I think that misunderstanding leads a lot of engineers down the wrong path. And it leads them down the path of... trying to implement microservices way earlier and before their organization matures or gets to the point where a lot of engineers need to building simultaneously features together and then they start stepping on each other's toes. That's when microservices comes in and shines and that it allows the... definition of certain domain boundaries and it allows us to lock certain domains within what we call conceptually services and it allows teams to own particular domains as opposed to just, you know, vaguely own modules maybe or a bunch of files within a monolith that everybody needs to come in and shove stuff into and whatnot. Microservices also aims to solve the bottlenecking of ⁓ internal traffic in between different modules. And I think the... the concept of allowing microservices to define very specific contracts for how they want the integration to be and how we want different microservices to integrate with each other is something also very positive. And it allows us to really lock that domain very well and make it easier to consume, but also easier to extend and easier to maintain and continue evolving. And one problem that microservices solve is the fact that what do do with ⁓ legacy stuff? How do we deprecate certain endpoints and APIs and whatnot? And I think microservices can, if implemented properly, can also solve this particular problem. So a lot of smaller teams, they start implementing microservices whenever you have a group of two or three individuals working, maybe even a group of 10 engineers. And then in my opinion, the overhead of managing all of these microservices outweighs any benefit that they're gonna get from that implementation. They are better off building a monolith and building different modules and even defining specific interfaces for these modules. And they are better off building in a monorepo where they ship everything on ⁓ regular intervals as opposed to dealing with the burdens of microservices. And I've seen teams and I've led teams that decided to implement microservices prematurely. and we paid a hefty price because everything crawled to a halt. And the more importantly than the microservices themselves, the platform that is supposed to support the runtime of these microservices and the life cycle of each service just wasn't there. And if you don't have that, good luck shipping microservices at the pace you would like to ship it. Everything becomes a struggle multiplied by the number of services you have. And that's not necessarily an effective way to build software or ship anything. Bethany (21:37) really love that concept of basically microservices is an evolution of Conway's Law and being able to divide that organizational communication and split into domains. ⁓ I think there is something to be said about when you break into microservices, you can scale. components individually, though you have to be at very large scale to actually encounter that problem, it feels. So it doesn't seem like a problem that most companies would encounter until like very, very far along ⁓ in their, yeah. Bassem (22:18) Absolutely. I've been talking about this very, very openly and very... ⁓ broadly. I've been on another podcast recently and I've talked at length about all of these. And I think scaling prematurely or at least building for the highest level of scale before we actually attain ⁓ some numbers that tell us where we're going in the direction and building for the ambition of company owners is not necessarily the right approach when it comes to engineering practices. We need to build for the next ⁓ next level of scale, which is the next order of magnitude, in the sense that Once we have 100 users, we can start building for the next 1000. Once we have 1000 users, we can start building for the next 100,000. Once we get that, maybe we can start thinking about the next million or 10 million and whatnot. But a lot of companies start with building for the 10 million because they have high hopes that their product is going to get there. This type of success just doesn't happen overnight. Very, very difficult. Even if you have the golden standard for startups and SaaS metrics, which is the hockey stick ⁓ exponential growth in terms of your user base, they're still going to be that beginning where growth is going to be very, very slow before you get that tipping point and then you start scaling exponentially. And all of that time can be invested shipping faster, better, and not necessarily worrying about scale at that point in time and focusing much more on product market fit. Bethany (23:49) 100%. Yeah, I feel like most developers have a traumatic experience with a team that invested in microservices a little too early. My first job, I remember it was a chat application that pops a chat modal in the bottom corner. We had over 20 microservices to support just that. The sign that it went too far was when we implemented a service just to do math. Bassem (24:18) you Bethany (24:18) So good times good times it doesn't exist anymore so that might be a signal of that. So you're launching a like speaking of microservices in these problems that are encountered ⁓ you're launching a practical system design course which targets engineers with three plus years of experience. Bassem (24:23) That's the answer. Bethany (24:41) I'm curious what your reasoning for targeting that specific point in an engineer's career was and what's the gap that you're seeing that you really want to fill there. Bassem (24:51) I think that is, that group or that demographic of engineers that have spent maybe two or three years in the industry is the peak of the Dunning-Kruger effect where engineers think that, oh, now I know everything about this domain. And now I think I can make a lot of great decisions. And they know enough to create the path that's going to lead them to failure. That's how it is. And I think, for me at least, learning from other people's experience was tremendous. tremendously helpful to understand the gaps in my what I know and to also realize what I don't know. We don't know what we don't know, right? So we need somebody to show us what is out there as well. And that is my hope with this particular course is to show and enlighten a lot of these engineers on what they don't know yet and a lot of the pitfalls in the reasoning and the experience that they gained so far, which is great experience. It's a lot of it's a lot of work. It depends on how you spend those three or four years. But there's still a lot to know and there's still a lot to see in how to implement different patterns. What makes me different, for example, than my other junior engineers who work with me is not the fact that I know more about the programming languages or the syntax or the, know. design patterns or the architectural abstract. I know the impact of implementing these abstractions and what happens on the ground, even if the actual landed experience is not going to be exactly the same as what I've seen in the past, but I can draw on my past experience to steer us away from certain familiar patterns. Now you would say, but you're relying basically on heuristics and it's not really a methodology. Very rarely there is a lot of methodical approach to building software. And heuristics is often all we got because we are every single time we're building bespoke systems and these systems are complex and they behave in non-deterministic ways. So all we got is literally pattern recognition and our ability to try to sort of. guide these systems to behave in a way we want them to. And all of these insights, I want to share it with, you know, folks who have spent that amount of time in the industry. Although the course is not just designed for this category. I've had my waiting list open for a while and I've had people who have spent 10 plus years in the industry sign up because they still believe they can gain and benefit from that knowledge and experience. And honestly, in my deep dive is that I've been publishing also on YouTube for my members. We go really deep. Like one of the episodes was about load balancing. and I took as a case study the global load balancer implementation that we have at GitHub, right? And that is... A very interesting case study because that GLB is designed from multiple components, some of which are implemented at the layer four of the stack and some of which is implemented at layer seven and the way we do, for example, rotation of the servers ⁓ in the GLB and how we keep everything running while we do a lot of these server rotations and upgrades and whatnot and how we do the routing and the shaping of traffic. All of these are fantastic things and interesting to know of and learn from. And if an engineer who has spent three years thinks, this is not very relevant for me right now, great. Skim it. Go through the content. Move on to something else that's more relevant. Somebody who's spent 10 plus years was probably implementing something similar in their companies would benefit a lot from watching and seeing this knowledge. I think there's a current gap in the market because a lot of the courses are designed to prepare folks for interviews. So a lot of the system design material, like For example, Hello Interview, they do a fantastic job with their breakdowns and they offer a lot of guidance and information and they go really deep into the fundamentals as well. but they lack the practical aspect of it. So some of the exercises that I'm building for this course are hands-on experience with distributed system problems. One example of that is ⁓ in the topic of causality and determinism, we actually go through an actual raft consensus algorithm implementation and then we discuss it. And at the same time, some of the exercises are going to be focused on how to actually run that with a bunch of servers, how they can communicate with each other, what happens when one of the nodes down, how do we do leader election, and then some exercises to play with that to solidify the concept. ⁓ And I'm trying to provide also a bit the platform to play with some of the distributed system problems that we see every day and we try to work around. It's a lot of work. Hopefully I'll get it done at some point. Brittany Ellich (29:31) It sounds like it. It's cool though that you're releasing some, sounds like as you go to your members. I might have to subscribe and go check those out because I'm excited about it. Bassem (29:40) I would love it. I would love some feedback as well if you have it. Brittany Ellich (29:43) Yeah, I think one of the things that has always drawn me towards your content is the fact that you go so deep and technical and like you're not just saying like trying to make content for the sake of making content. It feels like you're actually making something that's really useful. And like I've learned a ton from your get internals videos. Yeah. Bassem (30:01) Appreciate it. Thank you. That's great to hear. It's harder for sure, and it has lesser of an audience. So I have a lot to say about my time spent creating content. ⁓ The type of content I started creating was the type of I was interested in myself, the type of videos I want to see myself. The problem is that the folks who might be interested in that level of depth don't necessarily watch videos because their time is much more valuable and there's very few hours during the day. So spending it on an hour and a half understanding the Git internals really has to matter for you so that you can invest that particular period of time. So yeah, that's why sometimes my viewership is less than other types of material, which is fine as long as a group of people is benefiting. I would love to keep on creating that type of content because I enjoy that learning as well myself. yeah, it's fun and it's hard at the same time. Brittany Ellich (31:00) Does that philosophy play into your de-influencer status that you've mentioned before? I love the term de-influencer so much. Bassem (31:06) I was so bitter about a lot of the stuff that happens in the community. I I grew my following from zero to probably 100K across all platforms, TikTok, LinkedIn, and YouTube and whatnot. ⁓ And I see... I hate social networks, let's put it that way. I hate the way they're designed, I hate the algorithms, I hate brain rot, I hate how the setup is. And if you're gonna capture anybody's attention, you're gonna have to compete with a lot of content. that is much easier to consume, a lot of entertainment-based content, and it's much more difficult to put educational content out there in a form that is easily digestible, to process, but at the same time fun. And I hate influencers, like in tech specifically. Like I understand entertainment for the sake of entertainment, but when you do edutainment, And at the same time, your opinions and takes on something are not necessarily at the level where they should be or at the depth that they should be. And then when we start sensationalizing the wrong things in the industry, I really, really hate that. And I try to sometimes break a lot of these misconceptions in my takes and in my opinions. And I also try to shake the tree a little bit because I feel like in a lot of times we fall into the dogma of doing certain things and we start creating these cults that are based on identities and we start doing identity-driven development added to the list of all of the other types of development that we do. ⁓ You know, where I've been seeing it all over the place and the association with associations with different programming languages and different paradigms is weird to me in my opinion. I get why people do it, but. We can talk a lot about that as well. ⁓ But that's why I like to label myself as a de-influencer. I don't take on brand deals. I don't promote products. I don't promote tools, even though it's necessary if I'm going to ever make this business sustainable. I hate the fact that it is this way. ⁓ But yeah, I'm gonna always share my controversial takes and my experience the way I see it and from my vantage point. And I always tell people who watch my content, never take anything I say for granted. It's not a rule. It's not something you have to abide by. Use and critical thinking. And when I share with you something, take it as an opinion, think about it, process it, digest it, critique it. And if it actually applies to you, use it and keep on evolving from it as well. Brittany Ellich (33:57) Yeah, I think that makes me think a little bit about ⁓ Will Larson has this really interesting article about ⁓ writers ⁓ who operate. And I feel like that's sort of similar in the tech influencer space where there's a point where you're making so much content that you're not operating anymore. You're not a software engineer anymore. also just generating content. And so that kind of takes you away from the space. But it seems like you've got a pretty good balance of like, You operate, you're a software engineer regularly doing work. mean, I work with you. know that you're regularly doing a ton of work and you're making all this content at the same time. That's like actually good and technical and like deep. ⁓ and I feel like that's probably a hard balance. Yeah. Bassem (34:37) It's not sustainable. And that's why a lot of people don't do it. A lot of people go full time on content because it's not sustainable to do it besides anything else. I used to work for seven days a week. I got burned out because of it. That's why I haven't published anything. It's been a few months. But I'm trying to get back on track. But it's a lot. It's a lot. And also trying to have balance stakes after a 9, 10 hour workday where you're dealing with all sorts of stuff we deal with is also very hard not to be a bit bitter about how certain things are and certain things in our industry for sure. Brittany Ellich (35:11) Yeah, I get that. You also had a podcast for a while and interviewed a ton of great folks in the software industry. Simon Willison, Cameron Ahmed, Edward Thompson, a bunch of others. Are there any conversations from that that you like remember or stick with you that have like genuinely changed how you think about something? Bassem (35:34) Absolutely. ⁓ Cameron, specifically Cameron Ahmad for folks who don't know and a lot of people don't know. Like he's the guy who created roadmap.sh. The roadmap where you go and check out like what you need to learn, the concepts you need to learn to become a software engineer, DevOps engineer, whatnot. Like it's one of the most popular websites for beginners and very few know who's behind it. Cameron is so humble and he's so humble about his beginnings, his experience, his technical knowledge. It's, how do you say it? It's inspiring in that regard. And he doesn't necessarily consider himself one of the elite software engineers and yet he has created something that a ton of software engineers use, love, and benefit from on a day-to-day basis. And he has grown Roadmap.sh to become way more. than what it just is, a roadmap. Now he's enabling it with more focused courses and content that allows you to actually dig into the concepts that are part of that roadmap. And he's always been open for feedback about his platform, which is something I respect a lot. So Cameron is very pragmatic and he's not shy of his beginnings. And he is very patient with outcomes and he keeps on shipping awesome stuff until this day. And he quickly moves to fill gaps. like, there's an area I can actually add value in. He immediately uses his platform to start creating in that space. And that is very inspiring to see. Another example is Simon Willison, ⁓ the co-founder of Django. That was a fantastic conversation. And Simon is so prolific. He's amazing. He is such a very well-spoken person as well, very eloquent. And he shares his ideas very clean, he's very lucid when he shares his thoughts. And ⁓ he's insanely humble like that. Guy's contributions are amazing. He continues to be an amazing contributor now in the data, LLM and AI space. His Today I Learned blog is amazing and you always learn new things from it. And yet again. He's so down to earth, fantastic guy. So I think these two people, among many others, and I interviewed a lot of great folks as well, ⁓ are just examples of how the people I want to see more in tech and the people I want to see be the inspiration for others and be the examples of others instead of the folks who do rage-baity, click-baity, controversial-taiky, whatever. ⁓ content out there. And I understand social media is driven by controversy and engagement. I hate that. And we need to see more people like Simon, like Cameron, be more vocal and be thought leaders. Brittany Ellich (38:34) Yeah, I agree with that. follow Simon's blog and I think one of my favorite things about it is he writes so much. Like you said, he is so prolific and he has a thing on there that's like, you can pay me to send you less things where he like curates the things that he writes every month so that he can like send it all at once instead of ⁓ his RSS feed is crazy. ⁓ That's great. And having a podcast, I feel like it's just such a great way to like network remotely. ⁓ I've met so many people through this podcast. Bassem (38:51) Insane. Brittany Ellich (39:03) that and gotten to have such great conversations that I feel like I haven't been able to otherwise. So shout out to podcasts. Excellent. Well, with that, we are coming up on time. So we're going to wrap up with our fun segment. So every week we pick a different thing sort of catered towards the folks that ⁓ that we're talking with. And so this week I came up with a terminal setup roast. We can do a round robin. Bassem (39:08) Agreed, 100%. Brittany Ellich (39:32) of our current terminal setups ⁓ and let you roast them. Or if you think that something's great, then let me know. So we'll talk about what tools we're using, ⁓ what's good, what could be improved, what could make them better. And then you can also talk about your own setup, any tools that you really like using, ⁓ anything that you could, any tools that you would change or whatever comes to mind. ⁓ So I'll start, I'm gonna throw a photo of it in, instead of sharing my screen because it's just easier. I'm gonna throw a photo of it in the shared doc that we have. I use Iterm2. ⁓ And I'll post these all online too. ⁓ It is in dark mode at the very least. Bassem (40:11) Thank you. you Yeah, I mean. Brittany Ellich (40:23) That's about all I've got actually. That's the only thing. I don't use any specific tools other than that. And you can see too, my last login was November 25th, so I don't use my terminal terribly often. ⁓ it is open to. ⁓ Bassem (40:33) This is insane. This is like my mom's terminal. This is the terminal my mom would use. You get 1.4, like, not using the light mode, so... Brittany Ellich (40:42) you. And I downloaded a new thing. It's not like I'm using the default on my Mac. Bassem (40:46) Yeah, that's true. I-term 2 is pretty good. mean, like, Elite Standard or Elite Status, as if you use Ghosty, for example. But I-term 2 is close. It's not that far. But you need to... Is that Bash? Brittany Ellich (40:59) Thank you. Bassem (41:02) That's so funny. I used to get roasted for using fish for the longest time, if you know the fish shell. A lot of people hate it. I used to love it. Like I had even a video about it and people just roasted the hell out of it because they don't like fish for some reason. I like fish. It's nice. ⁓ And I swapped or switched to ZSH ⁓ quite a while ago. And I think it's pretty cool. I mean, my terminal, yeah, it's a bit different. I use a lot of tool. I spent time refining it because I also, it's not about the pride, know, it's about ⁓ the capability of the terminal and being a bit more productive in that space. Let me share my screenshot of mine. It's super, super simplistic and I like it to be that way. just gonna put it in the dock. Yeah, there it is. It's literally absolutely, it doesn't even have borders. And ⁓ I use ZSH on it, but I also use a bunch of plugins for that in particular. Brittany Ellich (42:03) Ooh. Mm-hmm. Bassem (42:14) And I use a Power P10K theme for that. And I use the Z plugin, as well as the ZSH auto suggestions, which I think are really my defaults for everything. And I turn to. Brittany Ellich (42:30) awesome. I got credit for that, so that's great. ⁓ Yeah, I'm writing all these down so that we can include them in the comments too if anybody wants ⁓ to check them out. ⁓ Bethany, do want to share your setup as the Vim user? Hopefully yours is slightly better. Bethany (42:34) You I would love to. No, I've also spent a lot of time on my setup. I used to use iTerm2, but they started doing a lot of like... kind of weird things. It was going beyond what I would want ⁓ in a shell, so like they were adding AI and web browsing and I was like, I don't need all this, it's so heavy. And so I swapped to Ghosty and I am not looking back. It's amazing. I love it. very minimal config, which is what I love. ⁓ And so I use cat poutine themes everywhere. That is the elite theme. I will die on that hill. ⁓ And one thing I really enjoy using is this tool called Chez Moi. It's written in Go. ⁓ And what it is is it basically lets you... ⁓ templatize your configs so you can populate them to different machines. So I use this for all my Macs and then ⁓ also because I could have used Codespaces, I also use it for my Codespaces config. And all of that is in my ⁓ .config repo. So if anyone is curious how that works. ⁓ But for Codespaces, T-MACS is a must because it will preserve your session. I've been logged out of Codespaces far too many times to ⁓ to let it go by chance, so I always use T-Mux on there. And then, as Brittany mentioned, I am a Vim user. I've been using Vim since basically college. It's just, I get overwhelmed with IDEs and all these buttons that I don't know what they do, so I prefer configuring things myself. that's been my happy spot. And ⁓ yeah, I have a lot of plugins there. So... Just because I'm using NeoVim doesn't mean I'm doing everything the hard way. I still have menus to scroll my files and I'm like, grepping through my repo and things like that. it's, I'm really proud of the workflow I've developed, which eventually my talk that I gave at Go4Con will be put up and I can share that with folks to show what exactly I use in NeoVim, but I will spare you all that talk. Bassem (45:08) I would love to see your, like, where's scope pilot in your new Vim setup? You have a chat window and I would love to see that part. Bethany (45:13) Yeah. Absolutely. ⁓ So this is actually fairly new and I didn't include it in the talk because the Copilot CLI was in beta or was only for staff users, I think, at the time. So I was really wanting to show it off, but I was like, no, I can't. can't. They haven't announced it yet. ⁓ But Folk, ⁓ who does a lot of New of plugins, he made a plugin called Sidekick. which lets you take whatever your favorite CLI ⁓ code or LLM thing is and add it to any of them. So I use that. It works very well. Also, GitHub does have a official Copilot plugin. It's only for completions, but it does work pretty nicely for those completions. But with the folks plugin, It also has next edit suggestions, which is wild. The first time it popped up, it was a jump scare. like, what is happening? But it was really cool. I was like, I didn't even know that it could do this. So ⁓ Neo Vim is just so powerful. I used to only use bare bones Vim for quite some time, but I am always blown away with how much progress Neo Vim has made on Vim. Bassem (46:35) Absolutely. One of the reasons why I never fully switched is literally copilot, to be honest. And right now, the copilot agent flows and in VS code is, no, I cannot. I would leave everything else and not skip on that one. Bethany (46:52) Totally, No, the VS code is the quintessential. ⁓ I mean, I have to say that, but it's true. It is like the quintessential agent mode experience. But ⁓ NuOvm has come quite close to it. There's still some gaps, but I do like the CLI flow for agentic use. I get overwhelmed when things just start making changes on my behalf, so. I prefer to let the agent do it in the CLI and then review it after, like I'm reviewing a pull request and my brain is a little more happy with that, but ⁓ VS Code does good things. Bassem (47:28) Bethany wins. Bethany (47:30) Yay! Brittany Ellich (47:31) Yes, absolutely. I feel like there's a spectrum of developers who only want to be in an IDE and developers who only want to be in a CLI. Bethany and I are on opposite ends of that spectrum. Absolutely. Bassem (47:44) But see, this is also like, it flows back into our conversation a bit ⁓ earlier about elitism, right? Like you could also be a highly effective engineer with a terminal like that. Like it's fine, it's cool, it's fun. I enjoy the configuration aspect of it itself. But again, the benefits are not exponentially higher or bigger. Brittany Ellich (48:06) Yeah, yeah, I agree with that. Bethany (48:07) Yeah, it would be tough to convince somebody to just drop everything and move to neovim if they're not used to it at all. Similar to if someone is used to it, it would be not recommended to shove jet brains in their face and be like, use this. So I think it's wherever you're most effective. But I've been roasted so much for using neovim by people. it's like, I mean, it's fine. It works for me. I'm not saying you have to use it. Brittany Ellich (48:40) People, there's always something to roast somebody out on the internet. That's just, that's just what it is. ⁓ Bassem (48:46) Yeah, tell me about it. Like some people don't like the fact that I'm bald. Like, okay, great. What can I do about it? I'm sorry. My jeans, I cannot modify them. I cannot edit them. You don't like the fact that I'm bald. Just don't watch my content. That's fine. Yeah. Yeah. Brittany Ellich (48:59) That's wild. That's a crazy reason to not like somebody online. ⁓ Well, thank you so much. Fasten, this has been awesome. ⁓ If folks want to find you online, where do you recommend they go? Bassem (49:12) funny story. ⁓ So first of all, if you can write my family name, you can Google my name, you can find me there. If you can't write my family name, glitch.stream. But I thought it was smart to come up with a brand name that, and I had a typo in the glitch because it doesn't have a T in it. And that was on purpose. This is the bane of my existence. Don't be too smart when you're trying to come up with your brand. Just... you know, set something up. So glitch.stream, but remove the T from glitch and you will find me. Brittany Ellich (49:44) Perfect, we'll link it in the show notes too, just in case anybody struggles with it. ⁓ Great, well thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you're supposed to do on the podcast app of your choice. Check us out on Blue Sky, join us on Discord for our ongoing book club, Writing for Developers, and share with your friends. Until next week, thank you so much, goodbye. --- ## Episode 40: From Librarian to Software Engineer: Tammy Metz on Career Pivots and Mentorship - URL: https://overcommitted.dev/from-librarian-to-software-engineer-tammy-metz-on-career-pivots-and-mentorship - Published: 2025-12-30 - Topics: Non-traditional Paths to Tech, Career Development, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/112893442/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-19%2F414718342-44100-2-a8c19a14f784f.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, host Erika and co-host Brittany Ellich welcome Tammy Metz, a software engineer at GitHub, who shares her unique journey from teaching and library science to software engineering. The conversation explores the challenges of transitioning careers, the importance of transferable skills, and the value of mentoring in the tech industry. Tammy discusses her involvement in the Women to Women Mentoring Program, offering insights into common struggles faced by students and the significance of giving back. The episode concludes with a fun segment where the hosts share their unexpected teaching skills. Takeaways * Tammy transitioned from a librarian to a software engineer. * Non-traditional paths can lead to successful careers in tech. * Soft skills from teaching are valuable in engineering roles. * Job searching can be challenging for career switchers. * Mentoring can provide guidance and support to students. * It's common for students to feel lost in their career paths. * Volunteering can fit into busy schedules and be rewarding. * Career paths are often not linear and can change over time. Links * Tammy Metz on LinkedIn: ⁠https://www.linkedin.com/in/tammy-metz/⁠ [https://www.linkedin.com/in/tammy-metz/] * Girls Who Code: https://girlswhocode.com/ [https://girlswhocode.com/] * Woman to Woman Mentoring: https://www.womantowomanmentoring.org/ [https://www.womantowomanmentoring.org/] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:01) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host today, Erica, and I'm joined today by... Brittany Ellich (00:11) I'm Brittany Ellich Erika (00:13) we met on a team working at GitHub and quickly realized that we were both obsessed with getting better at what we do. So we decided to start this podcast and share what we've learned. 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 Tammy Metz, another software engineer at GitHub. Welcome, Tammy. Tammy (00:42) Thank you. Great to be here. Erika (00:44) No, we have so much talk about today because like us, Tammy is a successful career changer who made the shift into software engineering after working in teaching and library science. We're all excited to swap stories, talk about the non-traditional path to software engineering, and discuss how those varied experiences actually make us stronger engineers. We are also excited to find out more about her incredible dedication to giving back to the community. We know that you do mentoring with the Women to Women Mentoring Program and that you are a big advocate for encouraging other engineers at GitHub to get involved in volunteering. But we'll start with the career change. discussion first. So to kick us off, what's one thing you are currently building or obsessed with learning about right now at GitHub? Tammy (01:43) yeah, so I'm on the platform health team, which makes internal tooling for analysts to combat abuse at scale. And we've always worked closely with the trust and safety team, which also combats abuse, but in a little bit of a different way. And recently I've been, starting to work on a tool that the trust and safety analysts use and getting to know. how they work and what they are up against and dealing with, and also getting to work more closely with people in the Trust and Safety Engineering team. So that's been exciting and I'm enjoying it. Erika (02:19) That's very cool. Well, let's talk about your non-traditional path to get to where we are today. So we know that a lot of people feel held back if they aren't straight out of a computer science program, but your trajectory is one that proves them wrong. So walk us through teaching math and working at a school. as a librarian to becoming a software engineer at GitHub. What was the moment when you decided that you wanted to pursue this? Tammy (02:48) Yep. So my, my last job before my career change was a middle school librarian and I had summers off and one. So I was, I had gone through a process called national board certification, which is basically like an extra certification that teachers can do. And it is very time consuming and it takes a lot of energy. And I completed the process and suddenly have all this. free time that I didn't know how I was going to fill up. that summer, because teachers need summer jobs, it's just how it is. I found a summer job working with an organization that many people have probably heard of, Girls Who Code. And at that time, they had a long summer program. was like seven weeks. there were like tech companies would host classrooms. So I was the lead teacher in a classroom of Girls Who Code hosted by a local tech company. And so not only was I teaching them basic coding and helping them to work on things, but we were also going on field trips and talking to all sorts of people at this tech company about their jobs and their career paths. it was just such a great program. And I am not sure how many of the girls got convinced to go into software engineering, but I got convinced to go into software engineering. So that was kind of like the final point. I had previously left teaching a couple of times and ended up in tech jobs by accident and really liked them each time. But this time I was like, I'm going to do it for real and intentionally. So after that summer, I've just started taking classes in computer science. And that was how I started filling up my extra free time. And then a couple of years later, I just took the leap and left my job and tried to find a software engineering job, which I was not able to do. I actually found a support engineering job instead. That's how I came to GitHub. And at that point, I had kind of given up looking for a software engineering job. And I really enjoyed doing support engineering. Doing that really got me really familiar with all sorts of different areas of GitHub and just really helped me ramp up in a lot of ways. And it was my first exposure to a real production code base because I would go in and try to see if I could figure out what changes might have happened that caused this and that. And then there came an opportunity to transfer to the Platform Health team as a software engineer. That is how I became a software engineer. Brittany Ellich (05:36) That's super cool. It sounds like you have a really unique combo of lot of different skills from before your engineering career that might be useful now. Do you find that any of the things that you did while you were teaching or in your library systems work are transferable or anything that you can leverage right now in your career as an engineer? Tammy (05:54) Very much so. And I think a lot of the soft skills that I brought with me were integral in kind of keeping me above water while I tried to ramp up my software engineering skills. So, you know, I was able to immediately like be able to write a good pull request and explain things and writing and in an organized fashion. I was able to like run meetings. collaborate cross team with different people. And all of that was just stuff I had been doing forever as a librarian. So it wasn't anything special to me, but I think maybe those types of skills aren't emphasized so much in like your standard computer science undergrad program. And then I've always liked troubleshooting. just, I can't stand not knowing why something is. the way that it is or why something is broken. So I really enjoy like figuring it out. And I really enjoy doing that as a tech support. And that's really also helped me as a software engineer because even though I may not be the most like, you know, knowledgeable experience, like coder, I fill in a lot of gaps with being able to figure out why something broken or. It's just very helpful to have other skills that I've been able to just slide into. Brittany Ellich (07:18) That's awesome. find a lot of the folks that I work with that have a non-traditional background tend to have a lot of skills that they're able to use and leverage in their career, even if they aren't directly technical skills. ⁓ So you said that when you first came to GitHub that you were, you'd sort of given up on a software engineering career switch. What were the challenges that you were experiencing while trying to make that switch? Was it like a technical problem or non-technical problems or, you know, what? Tammy (07:25) Yeah. Absolutely. Brittany Ellich (07:47) Why did you almost give up? Tammy (07:49) Yeah, I had a lot of trouble getting a foot in the door or finding that very first position. were, I mean, so now it's like not a good time to be job searching, but back then there were jobs to be had and there were entry level jobs to be had, but they were very geared toward like new grads. Like there was a pipeline, you got your computer science degree, you got recruited. Those were the positions for those people. There were just starting to be some like apprenticeship programs. so I was applying to those, but I didn't get any of them. And it was just very difficult to convince anybody to the, like somebody with no experience could do a job. yeah. And that, that was my, my hindrance. so I'm really lucky that I was able to take the path that I took and at the time that I took it, because I started at GitHub the week that COVID basically shut everything down. So it was a huge relief to know that I had a job, it was already remote, everything was going to be fine. And it would have been very different if it had not happened at that time, I think. Brittany Ellich (09:02) Yeah, yeah, that makes sense. got into the industry in 2018 and I feel like I had a very similar start where it was really hard to get started. I know, and I know it's even more difficult now for a lot of folks. ⁓ I'll go ahead. Tammy (09:13) Yeah. I think, I mean, this is not really like good news, but I think that new grads or like, you know, college students are facing exactly the same problems that somebody career switching is right now. Like there's not open jobs for anybody at that level, no matter what kind of education or background they have. So that's not like super helpful. But on the other hand, I don't think there's like a huge differentiator right now between. you know, having an official degree and not. Erika (09:47) Yeah, it's weird to me looking at the like current job market because I feel like there's a mismatch between what companies are looking for and what they are saying they're looking for because there's so much work to be done. Like there's no lack of development work, but it seems like companies are saying, well, we want senior plus engineers and no one at the junior level, but What I'm interpreting that to mean is like, we want people who can run projects, who can run meetings, who can sort of do that, like orchestration, higher level thinking layer. And it's not necessarily something that junior entry level engineers can't do to this same point. But like, nobody's trained them to do it. Like, they're going into these interviews saying like, I know how to code and companies are saying, well, we don't really need that. Tammy (10:36) Right? Erika (10:44) but yeah, I mean, it's still very much needed. Tammy (10:45) Yeah. I think there's just so many candidates now that like, even if it's just not worth it to recruiters to take the time to think about, know, could this person have that potential or what? Cause they'll just move on to the next candidate. but I agree. Those are like really valuable skills that I think people from a lot of different careers come in with. yeah, it is. Erika (11:10) Yeah. then, like you do need both. Like you do need the technical side and the non-technical side. But yeah, like sort of chucking everybody out the window because, you know, you're only focused on some set of skills that you're not really even looking for is so backwards. Tammy (11:10) It is not a good time to be looking. Erika (11:32) feels like a really missed opportunity from a hiring perspective to reshape the narrative. Tammy (11:38) Sure. Brittany Ellich (11:40) I agree. That does kind of transition us a little bit though. I'd love to hear more about this woman to woman mentoring program that you're in. I'm not sure if that's specifically tech specific or if it's just a more generic mentoring program, but I imagine that you probably come across a lot of folks that are earlier in career through that. You said originally when we were reading through your Hubbard Champion overview, that the best part of giving back is helping people by just being yourself. Can you talk about that a little bit and what it looks like with the Women to Women Mentoring Group? Tammy (12:12) Yeah. So it's because all I have to do is open my mouth and chit chat. it's like, at some point I look back on my, you know, path and realize like, I've had a couple of careers and I've like had some successes and I've developed this wisdom that even though I still feel like I'm a 20 year old to the outside world, I am not. I have something valuable that could help other people. it's really this program is I get paired up with it could be any STEM students. So a lot of the students in this area are actually in like the biological sciences. But since I am in software engineering, I've gotten paired up with a computer science major this year. And last year, I was a cybersecurity major. So that was good because I don't know what I would tell the biology majors. But you know, A lot of it has just been just general advice for life. And yeah, it's just, you know, I've been where they are. I can see kind of how some things will end. Like I can kind of sift through like what's, you know, not that big of a deal, even if it might seem like a really big problem at the moment and like, you know, help them walk through. just how to get stuff done. you know, well, you want to look into transferring colleges? Well, let's take a look and like see what office you have to go talk to and like, what's the name of the person or can you send them in? It's just like really basic things that, you know, are just really easy for me or anybody probably my age that, you know, are really helpful to somebody who hasn't developed those skills yet. Brittany Ellich (14:02) I love that so much. And that sounds like something that I would have very much valued when I was in college, for sure. Is there anything that you see really commonly with the students that you work with? Is there like any advice that you find yourself giving over and over? Tammy (14:17) Yes. And I started to realize this when I had a previous volunteer thing that I did when I was interviewing prospective students for my college that I went to and also talking to current students about like, you know, their career path and stuff, that it's a complete shock to students when they first realize that the thing that they're working towards right now and majoring in and think they're going to be doing when they get out of college is probably not going to be the thing that they're going to be doing in 20 years and that they can have twists and turns in the road. And especially in the case of people in technology, they're probably going to be in a job that doesn't even exist now because there are a lot of jobs that didn't exist when I was in college now that for like machine learning engineer, you know, so it's okay. Like they're not gonna, no choice they make is wrong. They're not gonna end up stuck somewhere that they can always pivot. And that kind of like mind shift, I think is helpful for them. And it's something I see with a lot of students that I talk to. So yeah, that's a big one. And then the other one is that Like you don't have to be a 4.0 student. It's okay if something goes wrong, if you fail class. those are things that seem big at the time, but really in the long grand scheme of things aren't going to be a problem. you know, they're just learning experiences. Brittany Ellich (15:53) That makes sense. And I feel like your background having sort of navigated around a few different career paths now is probably really helpful for them to see too, to be like, look, you totally different things. And you can pivot even if you're not in college anymore. I like that. Tammy (16:07) Yeah. And I always say, ask me about being a teacher. I love it when people ask me about that, but generally that's not the career people are interested in talking about. yeah, I have a lot to say about that. Brittany Ellich (16:19) And then specifically just about volunteering in general, do you feel like you spend a ton of time doing it or is like that type of volunteer activity something that anybody could do even if they have a busy schedule? What are your thoughts there? Tammy (16:32) Yeah, I don't spend a lot of time at all volunteering, especially in this opportunity that I'm in right now. It's like, I zoom maybe once a week with the student a couple times. We have zooms with all the students. It's very low key and low commitment and so easy. Like I don't have to leave my house. It fits very well with my kind of introverted nature. But yeah, I think that's That's been kind of my message to people is that a lot of people are probably doing something that actually is a volunteer situation that they never even think of. Like they would do it no matter what, or they've been doing it for 10 years, like they're, you know, on their HOA board or they are volunteering at their kid's school and helping them plant a garden and just like things that you just normally do. without thinking like, this is a volunteer thing. So my message is to just like, you know, when you're working somewhere like GitHub that you can, that has a benefit where you can, you can get money to donate based on how much you volunteer to like just track the hours that you're volunteering and be able to do that and just take advantage of that benefit. But I truly believe that like, a large number of people are already doing something that already fits into their life. that's kind of what you need to look for, something that fits into your life and that you enjoy. And if you're not going to enjoy it, don't do it. Don't ever do something just because you feel like you're not contributing enough to the world or whatever. The right fit is there for everybody. Erika (18:12) Yeah, it sounds like it really comes from this place of you recognizing that you have built up something that's valuable and like you getting the joy out of giving it to others. And yeah, it's like speaks to your gratitude and sort of like reflection on yourself of like, yeah, understanding how far you've come and the goodness of like giving that to others. Tammy (18:38) Yeah, for sure. That's the other part of it is like, I don't even have to. It's all stuff I've just learned from doing what I was going to do anyway. Like I was going to career switch, you know, things have happened in my life and I can take all of that and help somebody else with it. but the other thing that I actually also tell students who aren't necessarily like committed to software engineering or whatever is that. I've done it both ways where I've had like a helping career, you know, being a teacher and now I'm in more of a corporate career and there are real advantages to both of them. like when you're in a career like teaching, you know, you know, like you're making a difference all the time and it might not always feel that way, but like in the long run you are, but you're always tired and you don't have extra time because all of your extra time. is usually spent in school doing other things that are, I guess, volunteer as well, but kind of like mandatory, voluntold kind of things. So you don't have like extra time to get involved in things, you know, like women to women mentoring. Whereas when you're in a job like software engineering, you have a lot more free time and a lot more free money. And you, you know, I'm able to like, donate more and I'm able to just be a lot more flexible with the volunteer opportunities that I get involved in. So one is not better than the other, but you don't have to be in a helping career to necessarily do good. both are options and both are good options. And I'm glad that I've been able to do both ways. Erika (20:09) It's funny because it kind of reminds me of this like trope of like software engineers dreaming of working on a farm. Like I've heard this like, you know, several people being like, or there's kind of a trend of like, I want to quit my job and go work on a farm because I'm like done with technology. And yeah, I also was actually a teacher right out of college. And I feel like I also draw on that to remind myself that you can do good wherever you are, and it doesn't necessarily mean that you're a slave to technology if you work in software. It's okay, you can be good to your coworkers, you can teach others. There's elements of that sort of teaching and helping that can be infused in any job that you do. Tammy (20:49) don't know. Erika (21:01) So it doesn't have to be like, yeah, totally one or the other. You can kind of like take bits and pieces, even if it's more on the sort of like intellectual software corporate side. Tammy (21:15) Absolutely. And then on the flip side of that, for those who are, you know, have spent like a whole career as a software engineer, teaching is a great second career because when you come in from something else and become a teacher, you have so much of a foundation to like draw from this. I never was that I did. also started teaching out of college, but I've noticed that like career switchers into teaching. are very successful and it's just so it's really good to have like a big age difference between you and the students if you're a high school teacher and a big like you know I think a lot of students think that like teachers can't do anything else or like you know they're really dumb and they don't know anything and like you know it helps for them to see that modeled where it's like no you can The people who have chosen to come and teach you can have a successful career in anything, but they have chosen to come and do this. So I think that like is very good for kids to see. Erika (22:22) Well, thinking back on your early days, what advice would you give yourself starting out, either sort of at that transition period or in the beginning? Like, if you were your own mentor, what would you say to yourself? Tammy (22:40) Yeah, I'll answer with kind of like a meta answer. I would advise to sift through all the advice from people and take the good and leave the bad. There are just really out of touch people that give advice and it's just not helpful. And even like advice that I could give now based on my experience from like pre-COVID. It's just not relevant anymore. Like I don't really know, you know, what it's like to be like trying to find that first software engineering job right now. I I have a pretty good idea, but like it's, it's a very different world. and. You know, people are, are trying to help and stuff, but sometimes it people's advice is just like upsetting and it's not helpful. So that's okay. It's okay to be like, thank you for that. input and because you as the job seeker and the career switcher or whatever, you can see best what's going on and you know what you've been trying and what's worked and if there was anything that this is not needed. But if I could go back, I would like track in a spreadsheet like every job I applied to because Now looking back, it's really blurry and all I can do is like look through my old emails and stuff. I'm just like, I wonder how many jobs I did apply to. I wonder if I ever applied to that company because I can't remember. Like it just, it would be helpful to have tracked that, but it's totally not necessary. Just a kind of a thing that you think of later. Erika (24:13) Yeah, yeah, it's almost like demotivating when somebody seems to tell you like there's one right way to do things and then you try it and it doesn't work. You're like, well, what's wrong with me? They told me that this would work. And yeah, it's a good reminder to be like, no, there's probably multiple ways. And even if that person had the best of intentions telling you, like it may have only worked for them. Tammy (24:19) Yeah. Right. Yeah, I find myself repeating a lot, like you're not doing anything wrong. You know, it's just how the economy is right now. Like you're just, just keep doing what you're doing. And, I can't put a timeline on it. I can't give you any guarantees, but just keep trying. That's all you can do. And there's nothing, you're not missing something by doing exactly what you're doing. So I think that's true for many, many people. Erika (25:03) Yeah, at many different levels too, like whether you're looking for a promotion, whether you're looking for that first job, yeah, at any point in the career there's those moments of frustration and it's good advice to remember. Tammy (25:07) Yeah. That's true. Erika (25:18) Well, Tammy, this has been such an insightful discussion. You have given us so much to think about, about transferable skills and mentoring. And before we wrap up, we have our fun segment inspired by all this talk about teaching and sharing knowledge. We are calling this segment Teaching Moment. And so the question is, What's one thing you're surprisingly good at teaching others? And it could be anything, maybe cooking, a game, or a random skill. And we'll let you go last if you have time to think about it. And I actually also need a second to think about this question. So I'm hoping that Brittany has an immediate answer. Brittany Ellich (26:04) I I do. Yeah, I love this one. I was just thinking through this and one of the things that I feel like I'm pretty good at teaching others or like something that people used to come to me a lot for was like proofreading messages that they would be sending or like emails. I feel like I'm not asked to do this as much anymore because I think AI took this job from me, sadly, but I'm glad that that skill, like it's accessible to everybody now. But yeah, feel like, you know, reading through something for tone is something that I feel like I've done a lot of for people and I really enjoy. Erika (26:39) for sure. I would still use a human over AI for that. I do not trust high-risk messages. all right. I... yeah. I mean, it's funny because like I said, I was a teacher and I feel like I'm... I am pretty good at getting people to... Tammy (26:45) my gosh, yeah. Brittany Ellich (26:47) Same. Tammy (26:56) I that. Erika (27:03) sing songs, like I was a music teacher. And I think I'm pretty good at like encouraging people to like sing and just enjoy the music. Yeah, that's really the only thing that's coming to mind. The only other thing is like helping out all of my sort of like post-millennial relatives with their technology. But I don't know if I'm actually teaching them or just fixing their issues. I feel like it's more like, Erica, this is broken. Can you fix it? And then I do it. So I'm teaching them to spend on tech support, I guess. Tammy (27:33) I I have. Gosh, I along those lines, think because, Brittany didn't really have one that was like teaching either, but more of a skill. have a skill too, that has made itself apparent to me in the last few years. a previous volunteer thing that I did that I no longer do anymore because I think that like real lawyers need to be the only ones doing this now. But Microsoft had, a program where. mostly lawyers from their CLA department, but also anybody else who wanted to volunteer would help applicants renew their DACA application. And so basically it was filling out like five different pieces of really long paperwork and then like going through it with the applicant and you know saying this is what we're this is what's on this and this is on this. I'm very good at filling out paperwork and following instructions and I kind of enjoy it. That was not something I ever thought about before I just kind of decided to try that opportunity. that was a really cool opportunity. And I got to meet a lot of people at Microsoft as well through that. yeah, so now I look for opportunities that involve paperwork filling out because I think that's my thing. I think I should have been a tax preparer or something in a previous life because... Yeah, it's just fun. So, that's my weird one. Erika (29:01) That is such a valuable skill. Yeah, we talk about soft skills, like I wish I was better at filling out paperwork. I'm very jealous. Tammy (29:10) It's definitely not something I realized I was great at until quite recently in life. But yeah. Erika (29:12) Bye! I don't cool. Tammy, thank you so much for joining us. This has been such a fun, illuminating conversation. So where can folks find you if they're looking for you on the internet? Tammy (29:28) think LinkedIn is the best place. I'm on some other social media platforms, but I'm not. I just lurk. So LinkedIn would be the place to reach out if you wanted to reach out. Erika (29:39) Thank you listeners for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next time, goodbye. --- ## Episode 39: Lifting as you Climb: Cassidy Williams on DevRel, Mentorship, and Building for Developers - URL: https://overcommitted.dev/lifting-as-you-climb-cassidy-williams-on-devrel-mentorship-and-building-for-developers - Published: 2025-12-23 - Topics: Developer Experience/DevRel, Career Development, Non-traditional Paths to Tech, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/112892465/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-19%2F414716941-44100-2-00dda21ce12ea.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany, Brittany, and Erika are joined by Cassidy Williams, Senior Director of Developer Advocacy at GitHub. They discuss Cassidy's journey in the Developer Relations (DevRel) space, her philosophy of lifting others as she climbs, and the evolution of DevRel in the tech industry. Cassidy shares insights on content creation, the importance of community, and her personal experiences with mentorship. The conversation also touches on the challenges and changes in the DevRel landscape, as well as Cassidy's passion for keyboards and her dream typing experience. Takeaways * Feedback, even when rough, is a valuable gift for growth. * DevRel is evolving, adapting to new technologies and community needs. * Companies should prioritize understanding the developer mindset over follower counts. * Listening to developers is crucial for effective advocacy and content creation. * Human problems in tech are often more complex than coding challenges. * Cassidy's journey showcases the blend of engineering and advocacy roles. * Mentorship plays a significant role in career development and guidance. Links * Cassidy’s website: https://cassidoo.co/ [https://cassidoo.co/] * Microjournal Blog Post: https://cassidoo.co/post/micro-journal/ [https://cassidoo.co/post/micro-journal/] * Keycaps: https://drop.com/buy/drop-dsa-astrolokeys-keycaps-by-sailorhg-and-cassidoo?defaultSelectionIds=966968 [https://drop.com/buy/drop-dsa-astrolokeys-keycaps-by-sailorhg-and-cassidoo?defaultSelectionIds=966968] * Cassidy’s mechanical keyboard recs: https://github.com/cassidoo/ama?tab=readme-ov-file#what-mechanical-keyboard-should-i-buy [https://github.com/cassidoo/ama?tab=readme-ov-file#what-mechanical-keyboard-should-i-buy] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host Bethany, and I'm joined by... Brittany Ellich (00:08) Hey, I'm Brittany Ellich. Erika (00:09) And I'm Erika Bethany (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've learned. We'll be talking about everything from leveling up your technical skills to navigating your professional development, all with a goal of creating a community where engineers can learn and connect. Today we are joined by Cassidy Williams, Senior Director of Developer Advocacy at GitHub. Cassidy has been in the dev rel space since her very first job out of college. And over the past decade, she's brought that expertise to companies like Venmo, Amazon, Netlify, plus countless startups she's advised along the way. She also shares what she's learned through her blog and newsletter, which has been running strong for over eight years. Today, we'll talk about building a career endeavor, creating content that actually helps people, and her philosophy of lifting others as you climb. Welcome, Cassidy. Cassidy (01:01) Hello, thank you so much for having me. Bethany (01:04) We're so excited to chat with you and have you. To kick us off, is there anything you're currently building or obsessed with learning right now? Cassidy (01:13) man, I just have like a pile of side projects that is ever growing and I occasionally try to dabble. Right now I'm trying to figure out how to do like desktop apps well with local LLMs, because I think that could be neat to like lean on the privacy aspect of making local tools that actually have the AI aspect in it, but it's not going well. you know, that's the like... thing I'm trying to get better at, but otherwise, you know, blogging. At the time of recording, it's December. I don't know when this episode is coming out. But I try to blog every day in December for blog vent. And I always start super strong with like a list of ideas. And I'm now getting to the point where I'm like, hmm, it's a few days in now. And I'm starting to really just grasp at straws like, okay, what can I write about today before I pass out at night? Bethany (02:02) I think that's awesome. I love seeing your blog vent series. honestly, when researching to talk about today, there were so many interesting things from your last blog vent, and it's so fun. Such a good idea. And you'd think that desktop apps with LLMs would work better, because all these, like Apple is like, you can run all this machine learning on here locally. ⁓ Cassidy (02:11) Yay! Yeah, you would think and and and I'm sure it will get easier over time. I think that's the the pro and the con of being early in a lot of tech stuff where the docs just aren't there. You're when you're on like really bleeding edge stuff. The previous indicator was like. there are a certain number of questions on Stack Overflow about a certain topic. And if there's not that many questions, no, you're early, which is good, but also rough. And now it's like... where are the resources if it's not like very explicitly defined in docs, people aren't writing blog posts, it's not trained in like the LLMs you might be asking questions to. I think that's where we're at right now with a lot of these bleeding edge technologies where you are kind of going in blind trying to figure it out and maybe you'll produce something. And I think it's also, that's just not my strength is desktop stuff. I want it to be, but I'm... It's all new, which is fun and good learning experience. Bethany (03:20) That is awesome. So one thing I was curious about, I was reading a lot and you've had a really cool career and started into DevRel. Could you maybe share with the listeners how you got started in the DevRel space? Cassidy (03:36) Yeah. And so I kind of started in college, kind of. And so I majored in computer science a while ago now. And when I was in school, I really enjoyed just coding and everything. And I kind of just figured I was going to be a software engineer. And I liked building things and shipping things. And there was a point where I started going to hackathons more. And those were hackathons were kind of different back then. Everything was in person. You stayed up all night drinking Mountain Dew and like shipping stuff. And I started seeing that occasionally employers were there and I was like, wait, this is your job. That's kind of neat. Um, and so that's, that was kind of like my first exposure to it. And at the time this was, let's see, when did I go through this program? I want to say it was like 2013 Twilio put together a program to try to help people. communicate tech better. And so it was like practicing public speaking, technical talks, practicing writing blog posts, practicing writing tutorials and everything. And they only ever did the program once because it was a lot of like content for them to review, but I appreciate them doing it. But I was a part of that program and it was really, really helpful. That's where I wrote my first tutorial that is still on my GitHub to this day of that was just like a basic HTML and CSS tutorial, but I tried to be thorough. And that's where I started giving talks and I was giving talks to like high school students about like, why you should major in computer science. But then I kind of got the bug. And when I was a senior in college, I was at a hackathon and just like building something. And I had talked to some of the companies there. And one of them were, was Venmo and it was the founders of Venmo. was still relatively early at the time. And As I was talking with them, they were saying, we actually need help talking to developers and we like your code. What if you did both? And so I ended up, there's a whole other backstory of how things ended up happening. I'm going to do very speedy thing. did a hackathon on an airplane. That was a flight from San Francisco to London. My team ended up winning and I ended up speaking at the United nations and. And that United nations trip. I also interviewed at Venmo and I got the job. So that was like a very big like, what? But that's just what happened. And that is how I ended up working at Venmo to do like dev advocacy, but then also was an engineer on the product at the same time, because it wasn't like a full-time job, quote unquote yet. And so I was speaking at hackathons and meetups and conferences and stuff, but also working on the app itself. And so I built blocking in the app. If you ever block someone on Venmo, that was me. and a lot of like very early things. But then as I got more and more into the advocacy side, I kind of turned that more into my career. Whereas I've gone to different companies over time. I was actually talking to Brittany about this the other day. It's kind of been a dev rel sandwich of sometimes I'm in developer relations talking to devs and making up my full-time job. Sometimes I just want to code and I'm quietly coding at my desk and that is my job. And then I miss talking and... get the bug again, and it goes back and forth. And so currently, I'm in advocacy, I like it, and it's fun, and I'm not tired yet. Bethany (06:49) That's awesome. It really is like a pendulum ⁓ in a way. It's like sometimes you just need to persevere that or like preserve that energy and then other times you're like, all right, I got all this energy, let's spend it. Yeah. Cassidy (06:53) Yeah. Right. Let's do this. Yeah. And, and I also really just, I love talking to developers and I think you all can agree because you started this podcast. Like it's, it's great to be able to kind of lift as you climb and, and, and pay it forward and give the knowledge that you have to other people, especially when you can see that they're able to use it and grow their own careers as well. That that's, that's the best part. Erika (07:25) Well, it almost like goes back to what you're saying at the beginning of like trying to build something and reaching for that like community of like, Hey, is anyone else doing this? Like, is anyone else seeing this? Like what's going on? Like, yeah. And there's so many spaces for like developers to connect. Like the first thing I thought of is like most projects I see now have like most like major projects that aren't like one person has like a Slack channel where you can like go and connect or some kind of like Cassidy (07:33) Mm-hmm. Right. Erika (07:55) community where you can like go and ask questions. And it's like, we all we all enjoy that. And like, as much as there's a stereotype of like, a software engineer, like in their basement by themselves, like, kind of meet each other to like figure it all out. And it's, yeah, it's like exciting to have those conversations and Cassidy (08:06) Yeah, I do love that stereotype, honestly. Yeah, it's exciting to see the impact of the conversations too, people who have read a tutorial where you're like, my goodness, they built the app, yay, or they figured out XYZ or they got the job. It's exciting to be able to be a part of that like rising tide lifts all boats sort of thing. And that's really what I love about the job. Bethany (08:35) I love that mantra so much of basically lifting as you climb or raising others up. And I think that is such a great mantra to have in everything, to put people at the forefront and help people the way you've been helped and things like that. Is there any notable examples of ways you've been lifted up through your career? And curious how you continue to lift others up in this phase of your job. Cassidy (08:40) Mm-hmm. Yeah, I feel like the mentors I've had throughout my career and just advice and stuff that I've been given have, I wouldn't be here today if it weren't for people who were able to give me those tips where, yes, I have worked hard, I've done the interviews, I've built the things, but I've gotten a lot of guidance and direction by people who were willing to lend that hand and be just like, hey, you're not doing this right. Why don't you go in this direction? Or, hey, you could be making more money if you do something better or ask a certain thing, or even just ask the right questions to the right people. And I have so many examples of it where the first time I actually heard the phrase, lift as you climb, was from a mentor where she was saying, like, you're at a point where your career can go in a lot of different directions, but you need to remember to give back. to people because someone has to fill the gap that you leave as you move up in your career. And now that person works at GitHub and I get to talk to her regularly. And that little advice that she gave me has carried me so much in a lot of aspects of my career. And then other people where they've said, wait, you're not getting paid when you speak at conferences? You know that you can, right? You shouldn't just go on your own dime. You're providing a service to people. now I know, of course, but at the time I was like, wait a minute, what? Because it just was a foreign concept to be of getting paid for speaking at a thing for an organizer. so, so like the there's been a lot of instances of that of people saying like, hey, you're not necessarily on the right track, you should correct yourself. But then also saying you should talk to this person or let me introduce you to this person or Try to do X, Y, and Z in these parts of your career so you can get to that next step. And I try to do that for others as well, where it could be just me reviewing a resume or giving a mock interview. But sometimes it's just saying like, hey, I see what you're doing here. Love that you're doing it. You're wrong. And I'm saying this lovingly and I want to help you improve. it might be just like how they're cold calling in an email or how they're... writing a blog post or how they are trying to portray themselves a certain way to get a job when that's not necessarily the way to do it. And there's a lot of nuance in there that is different from person to person, but it's something that I think really matters. having a community and mentors around you makes such a difference in your career, and it's easy to not want to ask for help, but I've learned that that... is pretty much the way to be able to advance. Brittany Ellich (11:35) I love that so much. You mentioned there's been a lot of change in the development industry recently, not only in software development, but also likely in developer relations. And you actually mentioned in a blog post last year that developer relations isn't dying, but you think that it's going through a period of evolving. What evolution have you seen and how have things been changing? Cassidy (11:40) Yeah. Mm-hmm. Brittany Ellich (11:58) I mean, even since last year, I would imagine how things changed since then. Cassidy (12:00) Yeah, it's, it's such a weird, like, I don't even want to call it a pendulum because I don't think we're going back to anything. But first of all, DevRel, like when I first entered it in the, in the Venmo years over a decade ago, it was going to, going to events and just like being a present and a present person, a presence at all kinds of different events constantly. And it was a very in-person thing. And then the pandemic happened. And so many things started changing in terms of like, okay, now dev advocates are content creators. They're making YouTube channels and podcasts and live streams and they're posting as much as they can. They're getting lots of eyeballs. And then a lot of the world has changed and the algorithms are different now. And a lot of people who were content creators are like, this is exhausting now. And so some people are still doing it. Some people are not doing it. It's a lot more strategic now where it's not put a mass amount of content out there and people will come. It's more like, okay, how do I identify certain things? Well, what behind the scenes work can I do that will eventually long tail be better where there's always been aspects of that. But for example, our team, get a lot of feedback from developers and we figure out, okay, what is the actual story behind this feedback? They don't know how to do. X, Y, and Z, but that also means that they don't fully understand the purpose of this. How can we kind of create that narrative to understand that purpose? And then that ultimately does turn into tutorials that turns into talks, live streams, various pieces of content and going to events. But it's, it's a different type of strategy, if that makes sense. And I think like a lot of elephant in the room, there have been a lot of layoffs in DevRel in the past and now it's back. And that's been a very interesting thing where there is a point where in when economy things were changing in 2023, 2024, so many DevRel teams were laid off. And it's just the nature of the beast and how things happened. And now it's coming back with a vengeance because I think companies are realizing, wait, they do things that are valuable. And figuring out what that is has been different from company to company where some companies, what they really need are technical writers. They just need people who can write the docs and be like very direct about tutorials. Some people need a technical mouse piece where it probably could be a marketing person and not necessarily a dev rel person. Some people need UX researchers and dev rel definitely encompasses a lot of different roles and that has been kind of shifting again and again over time, but really it's someone who listens to developers and can figure out how to communicate them to get what they need for the goals of the company. And I think that's always what it's been, but how we've approached it has been evolving over time. And it's in an awkward stage right now because I think tech is in an awkward stage right now. Brittany Ellich (15:05) Yeah, that tracks. agree. Tech is in a very awkward stage. So it sounds like DevRel most so for background Erika, Bethany and I are all software engineers. We don't work in the DevRel space. We just kind of do some stuff sometimes. And so we're not necessarily working with DevRel day to day. I'm curious. What should companies be looking for? Cassidy (15:08) Yeah Yeah. Brittany Ellich (15:29) when they are looking to hire somebody in general. Like are they just going to go find the person with like the highest follower count and like, all right, you're the person to do this or like, what is it that they, what is it that companies should be looking for? Cassidy (15:35) No. That's such a great question, because that's one where I've actually told companies saying like, you have to stop looking at follower count because that doesn't mean anything. there was once like, it was, I felt so like petty and smug where a company came to me once like tail between their legs and they were saying, you were right. We hired someone because they were super popular on YouTube, but they didn't actually know what the job was. And I was like, exactly. So satisfying. I love being right. But anyway, I feel like companies need to first of all, talk to someone who like knows how developers think chances are they've been a developer or at least they've worked a lot with developers in the past. should be someone who knows how to code or at least knows how coders work. Cause there that it's a mindset you, you, you all work in engineering. So you know that there there is a coder mindset, a developer mindset, where you don't necessarily need to be the best developer in the world, but you need to understand like what problems they face. And I think from there, it's how do you solve said problems? And I think it again, depends on the company's needs. And so it's really hard to just like do a blanket. This is what you need. But sometimes it's figuring out, okay, how do we make it so that way these company events are the most impactful as they can be specifically for developers. And so it could be just like, okay, what do you want? these events spaces to be. Do you want them to be just a bunch of demos? Do you want them to be workshops? Do you want us to teach? Do you want us to just like enhance what the sales and marketing teams are doing? There's that. Or do you want to focus on the devs who aren't there IRL in real life? Where do you want them to be reading your tutorials or do you want them to be kind of following your TikTok account? Or do you want them to be... just using the product or do you want them to be selling this product to their managers? Do you want to do like a top down or a bottom up approach? Because sometimes DevRel is like, I'm talking to the CTOs of all of these teams and like, I'm trying to say, this will increase how your developers work or solve your developer's problems. Or are you talking to the individual developers themselves and saying, okay. you want to work faster, this tool can do it. You are solving these problems, here's how you can solve them better. And so there's a lot of different strategies. And I think the best advice I can give is to really know who your audience is and what you want to do for them. Because after that, it's very easy to find the person. I shouldn't say very easy, but way easier to find that person because there's, have all different kinds, even at GitHub where My team is specifically, target open source developers and people who are learning to code maintainers that community. We have another team that's dedicated to just enterprises and talking to enterprise developers, talking to those CTOs. We have another advocacy team that's just the security angle and talking to security professionals. You kind of need the different kinds depending on who you're targeting. Erika (18:39) So we've talked a little bit about how companies think about developer relations and what kind of content to put out. How about you personally? What's your content creation philosophy? And I guess, how did you start? And then how has it kind of changed over the years? Cassidy (18:53) man. I, it's a good question because I feel like I need to figure out how to more accurately define it for myself because for me, because I've been in it for so long, so much of it is driven by my gut, which is not something that you can pitch to a manager where you're just like, I just know that devs will like this. Okay. Just trust me. Sometimes that works, but that doesn't, that doesn't always work. I, I feel like when I approach advocacy, I try to figure out like once again, who am I talking to? What do they care about and stuff? I really try to regularly go through like feedback of what developers are saying. And we have a bunch of different feedback channels at GitHub. For example, people can give feedback on the docs. have forums for maintainers. We have a maintainer community. We have the GitHub community, so many different things. Try to figure out what those trends are. And we have different people on our team who they, their entire job is just identifying those trends. and then figuring out, okay, how do we want to reach them? And so I know that earlier, for example, when I say earlier, like a year ago, we had kind of a gap in live streaming where people could just ask questions, office hours and stuff. And so our team put together a regular live stream on Thursdays where every Thursday we have different people across different time zones and languages, just live streaming, chatting, and devs come and ask questions. And it's been... one of the biggest drivers to the GitHub YouTube channel and to maintainers getting questions answered purely because we're just online at the same time answering their questions. Sometimes there's an SEO play where we talk to the marketing team and we say, okay, what are devs searching for the most? Sometimes it's really obvious stuff that you wouldn't think, but people are like, I just want to know how to do dark mode and light mode better on my readmes for my repos. I can whip together a blog post for that. That's nice and easy. But then sometimes it's like, what AI model do I use? Or what productivity gains can I have? And there's like specific search queries. And so we try to figure out, those questions mean we need videos on this, blog posts on this, podcast episodes, things like that. And so we try to, once again, identify small things that are somewhat reactive, but then also figure out like... longer term strategies of what's something that's scalable and sustainable for all the humans to do and take on. But then like, what is the narrative that we're pushing at a particular time? And, and like right now we have a very broad one, for example, as an org where we're trying to say like, GitHub is like by builders and for builders. That's, that's so broad and so many developer companies can say that, but what are the different like, pillars of messaging that we can give to developers so that they can say like, when this tool comes out, this will help me build better. Or, these new tools are built by people who really care because they are also builders like me and figure out how do we convey that message in everything we do. Erika (21:48) That is so inspiring that like the first response to your question to that question was really in relation to like listening, like, like, for you, like, it's listening like comes before anything and like Cassidy (21:57) Mmm. What a concept. Erika (22:06) Yeah, like sort of a guiding principle that I got from what you're saying is like, how do I connect with what people want to hear and in a way that they can receive it and like, there can be a conversation there. Cassidy (22:19) Right, well, especially too, because sometimes like, the, how do I phrase this in a very political way? There are sometimes where people are like, we want the people to think this, and they don't, that's just the reality of it. And so it's, you have to meet people where they are and slowly kind of direct them in a certain way. But at the same time, you don't want to just say like, you should think that AI is the best tool for you. They're just, they're not gonna do that. Most devs are pretty skeptical, myself included, even though I use it. And so you have to figure out, because I know you're skeptical, I hear your problems. I wanna figure out how can I answer some of them where it's not black and white, it's a big gradient. How can I figure out, okay, I know that copilot has been good for me. I know that copilot could be good for you, but it's... understandable that you might not be sure like is it really a good productivity gain? Is it just going to break my flow? Is it just going to hallucinate? What are things that I can do to say it won't hallucinate if you do this a little bit more? Or it might help you better if you do this sort of thing. And so you give tutorials on it to not necessarily change their minds but to be open to the kinds of ideas that might be helpful to them and solve their problems or You could say, okay, these groups of people don't want to hear this and that's okay. We'll just make other content for them and focus on different areas so that we can kind of cover lots of different bases. Erika (23:51) sure. Yeah. Yeah, and I also appreciate that like the goal it sounds like is helping people solve the problems that they want to solve. Like, and everybody's problem is a little bit differently. You can maybe like address 80 % of what people want to hear, but maybe there's like a few people who are really vocal and they want that one edge case or something like that. Cassidy (23:59) right. Yeah. Right. And you also have to figure out how to weight those where it's just like, is this a vocal minority or do people actually really care about this or, or recognizing not everybody will be happy about every single thing, but how can we at least make them neutral instead of angry or something? Cause I, I am a grumpy developer too. There have been times when I was like, this tool is terrible. And I'm like, it's actually not that bad. Okay. And, and figure, figure out how you can again, meet them where they are, make, make content that Erika (24:28) Yeah. Cassidy (24:41) helps them build better and then if they don't wanna hear it, you move on and make other things. Bethany (24:48) Yeah, this is reminding me of like, I read the Pragmatic Engineer book. ⁓ And there was a great quote that just continues to stick with me about all feedback is a gift. You just sometimes have to do a little extra effort to unpackage that and like derive the value from it. And it's hard when it might be rough feedback, Like, users aren't necessarily giving it in a kind way to you, I'm sure. ⁓ Cassidy (24:53) yeah, yeah. Right. Real. Yeah. Bethany (25:12) And so being able to try to unpackage that is such a skill and so important, mean, in day to day, but also for DevRel and stuff. Cassidy (25:21) Yeah, there's like that rule, don't read the YouTube comments, but at the same time, sometimes they're valuable. so, yeah, it's feedback is a gift and you can take that and really run with it if you are able to package it in the right way. Erika (25:34) Well, and this is, it's valuable for like engineers who are in dev rel specifically too of communicating with colleagues or across teams, like across your org, like, you know, maybe you have a product or a platform on, you know, on a, in a company and somebody else has confused it, how to use it, or, know, they have a Cassidy (25:45) Right. Mm-hmm. Erika (26:00) a request or something, even leadership, like they think that it needs to go a certain direction and you have concerns or you have ideas, like the way to communicate it effectively. You're saying like really what I'm taking is like really does start with like listening, asking questions first, and then kind of using that feedback to drive how you communicate. Cassidy (26:16) does. Yeah. And I think when you, when you hit a certain point in your career, you realize the code you're writing is just like part of the job. Human problems are so much harder than coding problems. And so even, even if like you're not in advocacy, you could do a lunch and learn for your team. If you know that like they're, tend to struggle with this and you could help teach them that. And you could figure out how to communicate better on code reviews or in docs, or you could figure out. even how to prompt an LLM better by being able to figure out what the core problems are in those communication gaps and speak to them. Erika (26:59) giving me a lot to think about. One more question related to content creation is whether you have a favorite medium of all these ⁓ ways to communicate, whether it's videos or blog posts, the live streams, what do you have a favorite? Cassidy (27:03) Sure. Mmm. So I like blog posts because I can do them async, where I can just write and move on with my life, edit them later or something like that. That's so nice. Making videos is okay if I don't have to edit them. Video editing is the bane of my existence. And so whenever I have to make a video for GitHub, for example, I always kind of ask, saying, is the video team gonna support us with this or is this a solo thing? Because... If the video team is doing it, I'm like, great. Okay, cool. They have professional editors who like editing. Wonderful. But if they're not helping, my word. I'm always just like editing and I'm like, why do I breathe like that? And just looking at yourself, even like listening to yourself on a podcast, you're like, why do I sound that way? Why is my voice so weird? You did just a lot of that. So I admit I like writing because I can hide behind my words. But I do genuinely like live streaming purely because there's no editing. You do it, you talk to the people and then you can move on with your life. Anything where I can kind of just do that, I do enjoy. But man, video editing or like podcast editing that I loathe listening to myself. Erika (28:21) I think I have yet to meet anyone who really enjoys listening to this out of their own voice. Cassidy (28:26) Yeah, I feel like what I do I'll be like, what are you like? What? What? Who are you? Because, man, it's yeah, it's so weird. I'm just like, am I nasally? Where did that come from? It just is what it is. Erika (28:30) Yeah. Yeah. Bethany (28:39) Yeah, I think it's always the discrepancy of what you think you sound like. I have the same thing. I'm less weird about hearing my voice back, but whenever I see images of myself, I'm like, who is that person? I don't know her. Whoa. Yeah. So I think it's just what you're used to seeing or hearing versus what other people are used to hearing or seeing. It's just that difference is so uncanny. Cassidy (28:44) Right. Yeah. Right. This is a very like specific thing that most people probably don't have to deal with. But when you speak on a very large stage for a very large tech company, sometimes before you do, they have their own hair and makeup people and you just kind of obey what they do to your face and hair. Every time they do. And I look at myself later, I'm like, I don't look like that. Where did that face come from? And that even happened recently where I was like this video. is a completely different human being purely because they just they just make you look just different enough from what you're used to that it throws you off but it's also nice to not have to like do your face in the morning again that's a very very specific to like this this world that i'm in but that it's so weird it's so weird Bethany (29:47) yeah, definitely. Every time I put on makeup or anything I'm like, whoa. I spoke at, like I did a lightning talk at Go for Convair the first time and some people took pictures of me and they were like the most terrible pictures I've ever seen and it was probably because, exactly. And I'm like, okay, I'm not going to focus on this. It's fine. yeah. Cassidy (29:51) Who's that? cool. It's like your mouth is in a weird shape because you're in the middle of the word. Ugh. I know. And it's hard to like, it's so vain to even talk about, but it's such a thing where like, I've been trying to tell myself saying if they took that picture and they think it's good, maybe other people think it's good and it's just you thinking it's weird. But at the same time, why is your mouth like that? Just, yeah. Bethany (30:27) Absolutely, absolutely. All right, well, before we wrap up, we always do a little fun segment and usually try to tailor it to our guests or whatever the topic is. So today, I'm so excited that you are a huge keyboard enthusiast. And just to give listeners an idea of how big Cassidy is in the keyboard world, she made the Stack Overflow key, which blew up online. Cassidy (30:35) Eww. Bethany (30:56) the Scrabble keyboard which was amazing and also a really cute- my gosh yes yes ⁓ I love- Cassidy (31:03) Not that I had them within arms reach or anything. Bethany (31:07) love this! I was also going to mention your really cute keycap set that's on drop. ⁓ Cassidy (31:12) It's somewhere back there. I have so many keyboards behind me. I love keyboards. Bethany (31:16) Amazing. Yes. So I just kind of wanted to do a little round robin. What are we all typing on right now? And is there a dream keyboard we have? Even if it's not in the realm of like possibility, like what would your dream typing experience be? Cassidy (31:25) Ooh. Mmm. You all go first, because I'll take so long. Bethany (31:37) We can. I can go first too, because I wrote the question, but I have a moon lander with a little nice little duck ⁓ thumb cluster. I like it. I have a plank, which is a 45 % keyboard, so very tiny for mobile usage. And I like that because I have tiny hands too. So I would love something that like combines those two. And I know it exists. I just need to like find it. And then also Cassidy (31:45) Wow. Bethany (32:02) I would like it to be Bluetooth, so I didn't have to worry about toting around cables, but Bluetooth for split keyboards are like so hard to find. Yeah, you always have to connect them two together and then they're Bluetooth or like connect one and it's really weird. So that would be my dream. Cassidy (32:09) So hard. So hard. Yeah. have a link to send to you. But everybody keep talking. Bethany (32:23) Yes, ⁓ I'm so excited. solve our keyboard problems for us, please. Brittany Ellich (32:26) We secretly just wanted all of your recommendations. Yes. Cassidy (32:28) And he was just like, wait a minute. Easy. Erika (32:33) I am not the most exciting as far as like what I'm typing on right now. Where I have like a Mac Pro keyboard and that's what I've been using and like very simple. ⁓ I will say like so I'm not like a computer keyboard enthusiast but I am a piano player. Cassidy (32:43) gets the job done. Ooh. Erika (32:52) And so like, I get the feeling aspect of it where like, you're like typing on something or like you feel the way that like the keys work in your hands. I don't know, I guess that's like kind of what I would want is like the piano feel. Like I want like a Steinway piano feel keyboard and like if it could look like a piano too, like that would also be really cool. So I'm going to say like in the dream world where... Cassidy (32:56) Yeah. Yeah. Erika (33:20) Yeah, coming up with a keyboard myself, like, yeah, that feel. Cassidy (33:23) that's, my husband was a piano performance major and we have discussed this exact topic. So I see you and I understand you. Yeah. Erika (33:29) Really? All right, keep me posted if you feel inspired. Brittany Ellich (33:35) That's amazing. I am also a little bit boring. I used to have a Huntsman Mini Razor keyboard, but I got enough complaints from Zoom calls from the sound that I now have this $30 Logitech silent keyboard. And it's not nearly as satisfying. need to see. also, Bethany shared a link of the keycaps that you designed that. Cassidy (33:42) Ooh, okay. You Mmm. Brittany Ellich (34:02) are so cute, so I want to see if I can find like some switches that are silent and do something fun. Cassidy (34:02) Thank you. Well, do I have the switches for you? So first of all, I also keep quiet keyboards nearby because I really like my loud keyboards, but they are on the shelf when I have a podcast or something. But I'm currently typing on what's called a Think 6.5. have these keycaps are called GMK Oblivion and it's got like the Vim keycap sets here. And then I have a little escape key that looks like a Game Boy, which is very fun. Brittany Ellich (34:11) my gosh, amazing. Cassidy (34:34) And this keyboard is super heavy. It has a brass weight on it. And so like it's a weapon if someone tried to break in I am protected But the that is the keyboard that I'm typing on it has what switches that are called creams. They're novel keys creams Smooth like butter Super quiet great for podcasts those and then on my Scrabble keyboard that I have here This is a wooden case for my Scrabble keycaps these ones there are linear Gateron black inks that are also relatively quiet, but my favorite quiet switches, which is on a keyboard behind me, are called Xylance, and they're like heavy tactile switches, but silent. They're so nice. I love them, and I can send you all many links, and we can put them in the show notes too. But ⁓ anyway, I... Brittany Ellich (35:18) Yes. Cassidy (35:20) I love them. I have a problem with all the keyboards that I have, it's so fun to get different boards that you can create. And I'm going to transition now to the question of a dream keyboard. So you remember like the iBook G2, G3s, like Legally Blonde, those MacBook. What happened to those? What happened to us as an industry? Those computers were wonderful and we have the technology. One of the things that I built recently, and I wish I could show it on screen right now, it's a typewriter, and it's on my blog. It's called the Micro Journal. It's a digital typewriter. And it actually has a keyboard that's a lot like the Plank. Bethany, so you should check it out. But it has an ortholineo keyboard, and it's a digital typewriter where you type distraction-free. It's great. And then it has some firmware. It's all open source. You can 3D print it. It's awesome. Where you can hit the key command, and it exports everything you've written. to Google Drive. It's great. I've used it to write blog posts. I've used it to like slowly write feedback and stuff for people. And it's so nice to just have it in its own dedicated place. What I want is a computer, a writer deck of sorts that's in the form factor of the iBook G3. I want it to have a mechanical keyboard with silenced switches and like a uniform low profile keycap set. But I also want the screen to not be an E Ink screen necessarily because the frame rate is very low. Have you seen the daylight computer? It's like an E paper screen and it's very, very cool. It's like a black and white screen that's like E Ink, but with a 60 frames per second frame rate. That a distraction free screen, a cool aesthetic, a mechanical keyboard. That device is my dream and I implore anyone who listens to this, build it for me, I'm begging you, because I think that would be so nice. Anyway, that is my dream. Bethany (37:20) we need to send that out to all the keyboard manufacturers as a cry for... yeah! That's amazing, I love that. And I am definitely going to look into that micro journal to try to print it, that sounds incredible. Cassidy (37:23) The odds. It's so nice. I'm very, very obsessed with it just because first of all, it's always great to like have an open source thing that you can make in real life, but it also just looks cool. I'm putting it in our chat and we can put it in the show notes too, but it's like a portable machine that just works. You turn it on, you write, you can have multiple files in it. It's got like a very, very, very low level operating system. But again, it's all open source and so you can do whatever you want with it. It's great. I love it. Bethany (38:01) Amazing. my gosh. So cool. We're definitely linking that Cassidy (38:06) Yay. Bethany (38:07) Alright, well as we wrap up, where can folks find you? Cassidy (38:11) You can find me at Casadoo, C-A-S-S-I-D-O-O on most things. My name is Cassidy Williams. There's a Scooby-Doo character named Cassidy Williams, and so she really ruins a lot of my SEO. So, casadoo.co is my website, and that's where my blog is, and it links to my GitHub and all of the other things, Blue Sky and stuff too. So, if you look me up, you'll find me, if you look past the Scooby-Doo references. Bethany (38:36) Amazing. I don't even know that. Wow. Cassidy (38:38) I know. I didn't either until I was like, wait, why are people asking me if Casadoo is related to Scooby-Doo? And then it made sense. Yeah, I know. Same. Yeah. Bethany (38:46) no, I didn't even put those together, that's so funny. well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, join us on Discord, and share with your friends. Until next week, bye. --- ## Episode 38: Writing for Developers with Piotr Sarna - URL: https://overcommitted.dev/writing-for-developers-with-piotr-sarna - Published: 2025-12-16 - Topics: Productivity & Learning, Developer Experience/DevRel, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/112696135/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-16%2F414463711-44100-2-f16c6ac605a81.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Brittany, Bethany, and Erika engage in a deep conversation with Piotr Sarna, co-author of 'Writing for Developers.' They explore the journey of co-authoring a book, the importance of writing in engineering, and the challenges and joys of technical writing. The discussion also touches on the significance of blogging as a continuation of learning and sharing knowledge, as well as the role of writing culture in engineering teams. The crew kicks off the next book club, where the Overcommitted engineers will be reading Writing for Developers together over the next 2 months! Takeaways * Writing a book can be seen as a series of extended blog posts. * There is a gap in resources for writing engaging blog posts for developers. * Good writing in tech should have an educational aspect. * Writing culture in engineering teams enhances clarity and collaboration. * The book 'Writing for Developers' fills a niche in technical writing resources. * Embracing cringe-worthy writing experiences is part of the learning process. Links * Piotr Sarna on LinkedIn: https://www.linkedin.com/in/sarna-dev/ [https://www.linkedin.com/in/sarna-dev/] * Cynthia Dunlop on LinkedIn: https://www.linkedin.com/in/cynthiadunlop/ [https://www.linkedin.com/in/cynthiadunlop/] * Piotr and Cynthia's first book: Database performance at scale: https://bookshop.org/p/books/database-performance-at-scale-a-practical-guide-cynthia-dunlop/f384c1f0d973803c?ean=9781484297100&next=t [https://bookshop.org/p/books/database-performance-at-scale-a-practical-guide-cynthia-dunlop/f384c1f0d973803c?ean=9781484297100&next=t ] * Writing for Developers book: https://bookshop.org/p/books/writing-for-developers-blogs-that-get-read-cynthia-dunlop/af343340c60cd806?ean=9781633436282&next=t [https://bookshop.org/p/books/writing-for-developers-blogs-that-get-read-cynthia-dunlop/af343340c60cd806?ean=9781633436282&next=t] * Write that blog!: https://writethat.blog/ [https://writethat.blog/] * Writing for Developers GitHub Repo: https://github.com/scynthiadunlop/WritingForDevelopersBook [https://github.com/scynthiadunlop/WritingForDevelopersBook] * Discord community for Overcommitted: https://discord.gg/fxvEjs7f [https://discord.gg/fxvEjs7f] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany, joined by... Bethany (00:07) K and Bethany. Erika (00:08) I'm Erica. Brittany Ellich (00:09) The three of us met while working on a team together at GitHub and realized we all are obsessed with getting better at what we do. We decided to start this podcast to share what we've learned. 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, we are joined by Sarna, joining us from Poland. One of the authors of the book writing for developers and that is what we are going to talk about today. I'm so excited about it. Thank you so much for joining us. Piotr Sarna (00:32) Thank Thanks and hi. so my name is Piotr, but feel free to call me Sarna, because that's way easier to pronounce for everyone. I programed Distributed Systems for a living, but I also got into writing first blog posts and then books, so here I am. Brittany Ellich (00:52) That's awesome. To kick us off, what is one thing you're currently building or obsessed with learning right now? Piotr Sarna (00:58) I keep coming back to learning that... what would be the name of it? Like logic gates and stuff, so VHDL and Verilog, so the roots of how all those systems actually work, so every... year or so I come back to learning all the fundamentals and I hope that in a few months maybe I'll learn enough to just order my own system on jib like the first one so this is totally unrelated to my day job but something I'm kind of passionate about Brittany Ellich (01:31) awesome. Doing things that are completely unrelated to my day job is one of my favorite things to learn about as well. Sometimes that's nice. So we also, there was a co-author for the book Writing for Developers, Cynthia Dunlop, who was not able to join us. She got impacted by the post-AWS flu that seems like it went around to everybody that went to reinvent. But know you both co-authored the book together. I'm curious how did you two meet and decide to tackle this project together? Piotr Sarna (01:55) Thank We actually didn't meet in person ever, so that's a fun fact. I've only seen Sinfia mostly through Riverside, of course, places. But we worked at ScyllaDB for a time and the story started with a previous book of ours, which was about databases. And the way it started was as follows. I was approached by... APRES, the publisher, they wanted to actually, they wanted to find an author to write a book specifically about ScyllaDB I kind of didn't want to do it, so I forwarded them to the marketing department of ScyllaDB and... we figured out that maybe I will first of all co-author a book with four people total and then make it a general book about databases because a book about ScyllaDB will be out of date the moment it's released and maybe if we just cover some fundamentals of performance and other aspects of databases it will have better shelf life let's say and that was a nice Well, I would call it a success. The book is open source and available for free online. It has quite a few views. yeah, I was happy to see it getting popular enough in our niche. And then, by about this time, I was already kind of hooked on writing books. And when Cynthia approached me about writing another one, I just... grid on the spot and this time we approached a few publishers. Ultimately we decided on money and yeah, we wrote this one. It was totally unrelated to the previous database one, but it was, I think it was even funnier to write. Brittany Ellich (03:32) Yeah, somewhat related in the developer realm, but very different topic for sure. Piotr Sarna (03:37) Yeah. Brittany Ellich (03:37) Writing a book seems like it's probably really hard. And then co-writing is probably another whole layer of extra things on top of that. What was the collaboration process like writing a book with another person? Piotr Sarna (03:48) I'd like to strongly disagree that co-altering is harder, it's actually way easier. If you co-alter with Cynthia, that's the secret sauce. Cynthia is first of all a skilled ghostwriter and also a writer, so she kind of took all the burden of pre-editing everything off me. I could just spill out... barely coherent sentences and she would just form them into beautiful English sentences that we can then pass to the publisher for review. So it's way easier first of all because of that and second of all writing a book like a whole book might be a little tough because it might take a year or three. If you write one fourth of a book it's a couple of months so it's like you can see the end of it so it's actually especially with the first database book we actually everyone was responsible for a few chapters. So all I had to do was write three chapters, if I remember correctly, maybe four, and each chapter is kind of like an extended blog post. So just that, and then you have a book. So I would say that co-authoring is substantially easier for a start, especially, to the point that I would never actually self-author without the co-author and without the synth specifically, I suppose. Brittany Ellich (05:12) Yeah, that makes sense. I feel like maybe it's also one of those things where like the idea of writing a book seems very intimidating because it's a whole a whole book. But does it feel a little bit less intimidating now that you've done a couple of them? Piotr Sarna (05:25) It would still feel a little bit intimidating for me to read the whole book, but yeah, I mean, half? Not so much, yeah. It would just be yet another book. And if you think of every single chapter as an extended blog post, it's... yeah. You probably already wrote enough of those to comprise for a whole book. So you just do it in a row and then get everything reviewed and published. Brittany Ellich (05:48) That makes sense. I like the idea of looking at it as an extended blog post. That does seem a lot less terrifying than writing a book. And if I understand correctly, you both write that blog as well. Can you tell me a little bit about what that is and what it's all about? Piotr Sarna (06:03) Yeah, it started as a promo for the book itself. We wanted to have a place where we would continue giving examples of the patterns of blog posts that we described in the book that are up to date monthly. the book is structured in a way that a huge part of it is a couple of patterns that we... that we just kept seeing everywhere. you browse Hacker News, I can pretty much assign patterns as I see them right now, because it's like muscle memory at this point. since we already, for every one of those pattern chapters, we had some examples, but those... would eventually get out of date and we wanted something that is up to date all the time so we just started this monthly this section of blog posts and we just post them there. That's pretty much it, it's like a natural continuation of the book. Brittany Ellich (06:56) Nice. Is there anything that you've learned since the book was written from that write that blog? Like, is there any like new insights you've gained that didn't make it into the book since you've been running that? Piotr Sarna (07:07) I think there's one pattern that we didn't capture well, which is somebody describing how something totally unrelated to their work works. So it's usually... I do assign it a pattern, because we only have so many of them to pick from, but I'm usually undecided about this one, so maybe I consider adding an appendix to the book describing one more of those. But otherwise, no, it's really amazing how the initial list of patterns applies to any new blocks that... happen every month. Bethany (07:41) That's really awesome. I love that you all are continuing on with your thesis of the book and continuing to provide examples for folks to look towards. So that's really cool. Shifting into maybe the book specifically. So as we know, the book is called Writing for Developers. And I'm curious from your experience, what gap were you trying to fill in the existing landscape for writing resources? Was it just lacking Piotr Sarna (07:55) Mm-hmm. Bethany (08:07) in general or was it lacking specifically for developers? What are your thoughts on that? Piotr Sarna (08:12) So before our book course release we did some research if there's anything that already covered exactly the same topic and unfortunately 99 % of books that talk about writing for developers just mentioned documentation which is boring from the start and we specifically didn't want to describe how to write engaging documentation because it's a and instead we wanted to ⁓ share how to how we think engaging blog posts can be written. And there was just, to the best of our knowledge, there wasn't a thing that described it specifically for technical people because technical blog posts are, they share some things with... good writing in general, they also have some specific things that there should be an educational model. aspect to them which isn't really necessary for pros. But on the other hand there are some things from writing good pros that also apply to blog posts. So yeah, we just wanted to fill the niche because as far as we know there are lots of very nice blog posts out there so we can learn by example but nobody to the best of our knowledge at least combined them in a book. Bethany (09:25) definitely makes sense. I was really struck by the concept of the book because I feel like it's such a fresh take on writing for developers and it's something that I feel like I've been trying to hone in on for a while with this element of storytelling for developers, like being able to craft a narrative but focusing on technology as well. So that's really cool. I'm curious, for those developers who maybe Think, ⁓ I'm just writing documentation and I don't know if this book is for me. How would you respond to that? Are there any concrete ways that devs can apply what's in the book to their day to day, even if they might not blog or is this really pushing towards the blogging use case? Piotr Sarna (10:04) We have a whole ⁓ section of the first chapter which is called Why Write? So it's probably an extended answer to this question and it also covers a huge list of excuses why not to write one of it is kind of could be summarized as I only write documentation. Well, documentation is usually... about something potentially interesting that was implemented before, so you can also twist it into an interesting blog post instead of just talking about the details. And this is just one of those excuses. There's a whole list and we dealt with each one in one of the first chapters. I think it was even chapter one, just to get everybody started. Bethany (10:47) Man, definitely mind reading. That is really cool that ⁓ you all tackled that already. I'm excited to dive in and read more about that. Something that you also might mention in the first part of your book, but is there three things that you're hoping that folks take away from this book? Or if they were to only remember three things, they remember XYZ. Is there anything about this book or is it just generally? supposed to be a reference or what are your thoughts on that? Piotr Sarna (11:15) So I think since I came up with three characteristics of a post that everybody should remember, so I can just quote that. It was an intriguing topic, distinctive educational core and smooth delivery. And they are all described in the book. But it is a good resource, even if you just want to look at a few examples to get you started. And because usually it's easier if you see a... blocks structured in a similar way that you would like something expressed or maybe you just like the style of someone and you want to publish something in similar style then going through the examples and seeing what were the good parts of some specific blocks and what have been improved might just inspire you as well. Bethany (11:54) Very cool. I'm excited because I made sure to get the physical copy to annotate a lot with this book because I feel like there's going to be a lot of takeaways from it. So very, very exciting. Is there any piece of writing either from you or someone else that you think every developer should read? Just like a good example of what developer writing looks like. Piotr Sarna (12:16) It might be a little unfair to list just one, because we tried to pick those examples per pattern and they are all something that we consider really good. The one that I will keep remembering forever was one from Tiger Beetle database, because they went ahead and implemented a game. which run in browser just to make their blog post cooler, which worked obviously. So yeah, that's the kind of initiative I would always support. And it was also very educational and technical and so on. So then that's something I definitely remember, but all of the examples are quite distinctive and very nice. Erika (12:56) So we are actually kicking off a book club for writing for developers with the overcommitted community. And we learned a lot from our first book club. And we're going a little faster this time. We're reading two chapters a week and using multiple platforms. We're using Discord and Blue Sky. And we're also doing some sync meetings, video calls. Piotr Sarna (13:16) Mm-hmm. Erika (13:16) try to make it more accessible for people with different schedules and communication preferences. So have you been a part of any book clubs in the past, remote book clubs that have done things really well that we can maybe steal from? Piotr Sarna (13:30) We were featured in Phil Eaton's book club with the same book, although that one was mostly an email list discussion. On the one hand it was quite easy to take part in because you just reply to an email but then yeah there weren't as far as I know there weren't anything sync meetings or anything like it so there's not much to share because that one that one was text only Erika (13:55) Well, yeah, we're really excited to have those live discussions and sort of have both the opportunity to participate through writing, which is good practice, practicing what we learn and also the discussions to involve people. Piotr Sarna (14:13) Well, if you would like to make this particular club more practical, then you can just gently force people to also try writing something along with the book. And just publish it, because it doesn't take much to just publish something. Worst case, nobody notices it, but it happens to every other blog post. Erika (14:23) Yeah. Well, that's good. Good advice to keep in mind for anyone who might be participating and learning. For anyone who's starting the book, what would you suggest as sort of a mindset of going in? yeah. Piotr Sarna (14:47) You could copy the author's mindset. So first one was that we wrote this book totally out of order. don't feel inclined to read from chapter... I mean, starting from chapter one is probably a good idea. We did write that one first, but then it was... really a random choice of what we felt like writing. So readers are encouraged to just read what they feel like reading. So in particular, there is no order of patterns that you need to read at all. But also if you would like to just read the intro and then skip straight to patterns because you can't resist just seeing what they are, just go ahead and then you can catch up on all the other advice that is in the book. They're a bit too stripped with the order. Every chapter with patterns has a few blog post examples and there are also links to them. If you own a paperback copy then you also have a repository that has all the links so you can just follow and actually see them because we couldn't reliably, for instance, include this web browser game inside a paper book. just need to go ahead and see it yourself. Erika (15:55) We'll include that in the show notes as well with a link to the book. And that's good to know about the book being not necessarily in a strict order. And it sounds like it's really centered around these patterns, the sort of content patterns that you identified. So that's a good place to start and focus if people are looking to focus on one area. Awesome. So beyond individual skill building or personal brand building, what role do you see writing culture playing in engineering teams and organizations? Presumably a lot of our listeners are working developers, so they're looking to apply. this content to their work. So how do you see that applying to day-to-day and how can developers advocate for good writing practices on their teams? Piotr Sarna (16:48) So I was fortunate enough to join CWB, which already had a very healthy writing culture. It was maybe a little too healthy, because I was kind of forced to write, but I grew to enjoy it. Like, really enjoy it, not Stockholm Syndrome. Enjoy it. And it does make the whole engineering culture so quite healthy because if everyone keeps writing technical blog posts that are... that are just published for everyone to read, then it's first of all clear that you also understand what you implemented, which is quite important. And then those blog posts usually serve for a better way of actually documenting the interesting parts of what happens inside the company. Because nobody reads documentation end to end. if there's a nice interesting blog post with some surprising conclusions, then everybody would actually write it. Those posts actually also lure people in, because if a company has an engaging blog, there are some corporations that have very good technical blogs like Cloudflare or Netflix or others and they just make people want to join the team that also writes those kinds of posts and as for starting the culture if it isn't there I think it's worth trying just to first of all write something upfront and then start asking around if it could get published officially as a company blog because there isn't usually a reason to say no unless there are some trade secrets in the blog post which you should just remove. But otherwise it's probably best to just write something then ask and worst case you can just publish it on your personal blog if it doesn't work out. Brittany Ellich (18:32) I feel like, especially in so many companies that are mostly remote, like GitHub or like, you know, a of companies now, writing is really the one thing that is surfaced, you know, like across different teams. And it's one thing, like if you're like trying to improve visibility in the organization, it's like very, very important, I feel like, to be able to write and write well and tell a narrative that other people can pick up. So it's definitely, I think, one of the best skills for developers to invest in. Piotr Sarna (18:43) Mm-hmm. Brittany Ellich (18:59) In my opinion. excellent. This has been great. And I'm so excited to kick off the book club. think we were going to start with chapters one and two when this, by the time this episode kicks off and we're going to have a, we have a discord community already that folks can join if they're interested in being in it. where we'll have some synchronous discussions like Erica said, and then we'll also, you know, just have a space, not only to talk about the book. But to share your writing, if you're listening and you're like, hey, I wrote a thing and I want other people to see it, that that's a great spot to do that. So we always wrap up our podcast with a fun segment. And this one, I don't know if it's actually going to be that fun or not, but this is what I came up with. We'll do a round robin so we all get to, you know, admit a little bit of something here. But the question I came up with was what's the most cringe worthy piece of writing you've produced in your career, something that makes you like look back and laugh at now. I feel like this could also just be like code you've written because I feel like that is very something that a lot of developers can identify with. It doesn't necessarily have to be writing. I feel like anything that I've written beyond the last like three weeks is usually something I'm like, who wrote that? it's me, great. So I'll start and we'll go around. I think that one of the most cringe-worthy things, blog posts that I've written is I have one blog post that I keep around just as like a lesson learned where it was when I first learned about AI and I was like, ⁓ man, I'm going to copy this thing into chat GPT and see what it says. And it produced something from like what I had written that I was like, man, this is very obviously AI generated and not great, but I'm going to save it because I think it's hilarious and nobody's going to read that. And now it's on my blog, but ⁓ it's the Boise Code Camp 2024 post. It is very clearly a lot of AI flowery content that I'll share. It's, yeah, I feel like there's a learning curve with AI things where people are like, I'm gonna do everything with it. And like, okay, no, nevermind. I can do some things with it. The only very cringe-worthy piece of it is it had really good SEOs. When I looked at Boise Code Camp last year, I was like, ⁓ it's on the front page of Google for that, which is when I was like, man, that's not great. But yeah, that is mine. Bethany, would you like to go next? Bethany (21:16) Yeah, so how many dashes were in that? In lists of three. Just a string of ⁓ dashes. That's funny. Yeah, I was having trouble thinking about this because I'm like, I probably haven't posted anything that I thought was cringe, but my mind went to anything I've ever tweeted or posted on Blue Sky. I just feel it's automatically cringe. I am terrible with short form content or distilling my thoughts into... ⁓ Brittany Ellich (21:19) It's probably all dashes, like the whole thing. Yeah. Bethany (21:43) a short set of characters, so I've definitely posted some cringy things and just, like, deleted it immediately because I was like, what am I saying? I think recently I posted on Blue Sky, I was like, I don't trust something that's marketed as viral, and then I'm like, what am I saying? This is the most lukewarm take ever, so I instantly deleted it. But that was... That was the biggest thing I could think of. I don't have a blog so I haven't had any experience with that, but maybe with this book club I'll finally get around to doing that, as that has been a goal of mine for a while. So, very excited to have a blog and hopefully not post-cringey things. So, Erica, why don't you go? Brittany Ellich (22:12) yet. Erika (22:23) Yeah, I also think that I have not written externally enough. I write a fair amount like internal to GitHub, but I feel like I like pre-edit anything external with the cringe factor. I did like post, I think like when I did my boot camp, we all had to do some kind of like blog post about our final project or something and like I guess I would say that, but I don't think it's bad. I think part of this is like we're constantly learning and like when you look back and you're like well that that's so obvious like Why would like why would anyone write a blog post about that because it's like HTML and CSS like who cares? but I think yeah like part of learning how to write is kind of like getting over that hump and being kind with yourself of like, it's okay, that was past me and you know, I don't have to know everything to have something worth reading and you know, I learned it at some point so maybe somebody else needs to learn it too. Yeah. Brittany Ellich (23:26) Sarna, did you want to share anything, if you have anything that you want to admit? Piotr Sarna (23:26) Yeah, sure. The most cringe-worthy by far would be my bachelor's thesis, but that's not probably publicly available. Hopefully isn't. But one actually public one, one is cringe on purpose. The first chapters to the database book were written by me and they were short stories of database performance with... purposefully very forced humor that wasn't very funny and I actually had a hard time actually reading this because it's just sad but this is also the that reportedly inspired Synthea to reach out to me to write another book so I guess it's good that I did and as for AI generated content we also tackle it in the book because our main advice is to by all means use AI to revise and review your blog post but do not let it actually create content. We also provide some examples of this generated content which is especially I think it was generated over a year ago so The models did get a little better with writing, although not that much, but some of those examples were very, very hard to read, especially if AI tried humor. Again, it just can't do this at all. Brittany Ellich (24:47) Yeah, I'm willing to be an example of poorly, poorly revised with AI things. Yeah, I can definitely overdo it. And I think it's a really great editing tool. At least as like a first pass before, you know, to point things out. But I've learned like, oh, okay, I don't really like it actually making changes. I just like it to suggest changes to me and not actually make changes to the thing that I write because the changes it makes kind of suck. Yeah, cool. Well, that was fun and a little bit therapeutic as well at the same time. So thank you all for participating. With that, we're going to wrap up. ⁓ Thank you so much for joining us. If folks want to find you on the internet, where is a good spot to find you? Piotr Sarna (25:28) You could start with this repository for a book and you could probably find me through there or I can just leave my contact info somewhere so you can post it. I'm technically also on Discord but I'm a Discord boomer and I just can't use it. It overruns me with these flashy images and notifications so I'll probably miss whatever... people approach me within that particular platform. yeah, email is fine. Brittany Ellich (25:56) Awesome. Yes, I love the term Discord Boomer. That's, that is great. Excellent. Well, with that, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you're supposed to do on the podcast app of your choice. Check us out on Blue Sky. Join us for Discord, particularly as this book club kicks off, and share with your friends. Until next week. Goodbye. --- ## Episode 37: Being Unreasonable with Jason Lengstorf - URL: https://overcommitted.dev/being-unreasonable-with-jason-lengstorf - Published: 2025-12-09 - Topics: Career Development, Non-traditional Paths to Tech, Developer Experience/DevRel, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/112275724/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-7%2F413926193-44100-2-5515be3e35934.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany, Brittany, and Erika engage in a deep conversation with Jason Lengstorf about the concept of being unreasonable in the tech industry. Jason shares his journey of embracing unreasonableness to pursue big ideas, the importance of community and networking, and how to navigate risks in career decisions. They discuss the value of non-traditional backgrounds in tech, the process of learning and consolidating information, and the creative approaches that can lead to innovative projects. The conversation wraps up with Jason sharing his future projects and reflections on the tech landscape. Takeaways * Being unreasonable and having big audacious goals can lead to unexpected opportunities. * Surround yourself with ambitious people that can inspire growth. * Recognize when to pivot in your career. * Networking is often more valuable than formal education. * Learning is an active process, not just passive consumption. * Creative coding can lead to innovative solutions. * Take (calculated) risks. It can help you achieve your goals. * Community support is crucial in navigating career changes. * Being slow to adopt new technologies might not be a bad thing. Links * Jason Lengstorf: https://jason.energy [https://jason.energy] * CodeTV: https://codetv.dev [https://codetv.dev] * All things open talk: https://www.youtube.com/watch?v=goVNPN6fVwQ [https://www.youtube.com/watch?v=goVNPN6fVwQ] * Bytes.dev: https://bytes.dev [https://bytes.dev] * Char Stiles: https://www.instagram.com/charstiles [ https://www.instagram.com/charstiles] * Builtin: https://builtin.com [https://builtin.com] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Bethany, and I'm joined by... Brittany Ellich (00:07) Hey, I'm Brittany Ellich. Erika (00:09) I'm Erika. Bethany (00:10) 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've learned. 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 Jason Lengstorf the creator of CodeTV, which produces TV for developers with shows such as Web Dev Challenge and Leet Heat. His career has taken many twists and turns, which he credits to being unreasonable and following his big ideas. Today we'll talk about what it means to be unreasonable in the tech space and how following your big ideas can shape your career. Welcome, Jason. Jason (00:51) Thank you so much for having me. Bethany (00:53) Thank you for being here. I am so excited. I'm huge fan of CodeTV, so I feel awestruck right now, but awesome. You recently gave a talk at All Things Open, which was really awesome, on being unreasonable and how that has been something that has not only influenced your career, but also made you who you are today. I'm curious, how did you develop this idea of being unreasonable and what experiences went into realizing that you had to do big things to achieve big ideas? Jason (01:26) Yeah, think, mean, this is a really, there's a million things that go into it, so I'm gonna probably gloss over a bunch of really important points, but I've been very lucky in my life to be surrounded by people that are really ambitious. And part of that is, you know, when I was younger, I had some friends who were 10 years older than me that owned businesses and they were kind of further down the path than I ever thought I would get. And they would just kind of talk about how they did stuff because they didn't know they weren't supposed to. And I think when you get access to somebody who you might look at online and realize, you'd think to yourself like, well, I mean, they must have something special that I don't. They're clearly playing on a different playing field. And then you spend time with him and you realize this is just a person like they they're not magic They didn't do anything that I'm not capable of doing they just kind of kept showing up and and that so a combination of that of you know being fortunate enough to have access to to a lot of educational information You know, I've been a curious person for my whole life. So I always kind of read whatever I can get my hands on and you know, I think I developed a sense of Like, hey, can I take this thing apart and figure out why it works? And the idea of just learning for the sake of learning has always been really big for me. So that kind of whirlwind of different things has always driven me to sort of look at what I want to do regardless of whether or not it's supposed to be possible. And so I think that my general approach to career and to life and all this stuff is, you I started out trying to go on the predetermined path of, know, you graduate high school, you go to college, you get a job, you start a family, you retire, and it kind of goes on. And then I got to college and I looked and I was like, you know, this isn't, one, this doesn't feel like it's gonna get me where I wanna go because I was looking around at the college curriculum and I was like, you know, this is a lot of the same material we covered in high school and I don't think I went to a particularly good high school, so that's concerning. And you know, I'm looking around at the other kids and half of them were completely checked out and the other half were like clearly riding on their parents, you know, their parents money. And I was kind of caught in the middle of that. And I was like, this doesn't feel right. Like something about this feels right. I don't, I don't know what it is, but I should be doing something else. So I dropped out, joined a band. and it like felt like that at the time felt like the right thing to do is, know, if I don't try this, I'm going to regret it. And what's the worst that can happen? You know, I don't have. I don't have bills, I don't have any long obligations. So if I go try to be a rock star and I fail, like I lost some time, but I'm not really like doing permanent damage to my life. So let's try it, let's see what happens. And my entire career, my entire life has sort of been a series of that. Like, okay, well what do I stand to lose if I try this? Probably not a lot. Let's see what happens. And it just sort of led to this continuous chain of. weird stuff that if you look at any of it in isolation sounds completely unreasonable, but ultimately it's led to me, I honestly could not think of something I'd rather be doing than what I'm doing right now. Bethany (04:31) That is so awesome. I really love that you haven't let anything stop you from thinking about what the next step is and really just the stars are the limit or anything like that. So, or the sky's the limit is the quote. But I'm curious if you ever encountered a scenario where a decision went from maybe risky but calculated to genuinely unreasonable. Is there any way you can tell the difference when you're in that? scenario or is that even a possibility? Jason (05:03) I mean, think, you know, I kind of barely survived my first foray into this, because after the band, I started an agency because I realized that I'd had, basically I was running an agency with a single client that was my band. And so when the band broke up, I was like, well, what can I keep doing? So I started taking clients and I wasn't very good at the business side of things. So I didn't know how to delegate. I didn't really do a good job of pricing or. Managing money, so I was running on margins that were virtually non-existent I was delegating all the parts of the business that I enjoyed and that I was good at and was instead hoarding the things that I was really bad at like sales and admin and accounting and and so I was just like burning out super hard and I was falling further and further behind on projects and by the time I bailed out of that agency I think I was like 35 or 40 thousand dollars in debt and I you know, I was so burned out so stressed out that I had patches of my beard were falling out in clumps and you know, I was physically kind of decomposing. So I'd say that's time when my dream of sort of being this big shot agency runner, I mean, quite literally started to kill me and almost financially ruined me. And if I hadn't had another fortunate set of circumstances, which is that following that agency, went and did. two years of living out of a suitcase in cheap countries, which allowed me to recover from being deeply in debt. But like, you know, so I think there's, yes, it is easy for things to slide out of control. But I was young when I made that choice, and I wasn't looking at... I guess let me take that from a different angle. When I was talking to one of those business owners that I was talking to, talking about earlier in the podcast, one of the things that I asked was like, well, how do you know this is the thing to commit to? Right? Because I had this belief that you, had to call your shot and then that was it. You were stuck with it forever. And I remember he said this phrase to me of forever for now. And he was talking about making a call on what to do with your life. And based on where you are, the information that you have, You have to go all in on something, but you also have to reserve the right to change your mind if things go bad. And so I had not internalized that lesson and I had my agency going and I was hitting my road bumps, things were going wrong, I was getting into debt, I couldn't keep up on projects, I couldn't figure out how to delegate. And was not making me happy. I wasn't enjoying it, it's not what I wanted to do, but I believed that I had to stay in it because I believed that was the path I had set for myself. And when I gave myself permission to say, you know what, this isn't right. And it's not a failure. Like it's a failure in the sense that the business I wanted to build didn't work out, but it's not a failure. Like I'm a bad person and I don't deserve to be, you know, to have nice things or to, to enjoy myself. It's, it's not a moral failure. It's just, it was not the right business. And as soon as I was able to internalize that and set it down, it, really fundamentally changed my relationship with the world because then I went and I did. The next thing, which was taking a contract and being fully remote and living on the road for a couple of years. And then I didn't like that anymore because I felt like I was too disconnected from everybody. So I took a job at IBM because I wanted to be on a team again. And I was like, that's it. I'm never gonna be an entrepreneur again. I'm done with entrepreneurial life. It was too stressful for me. And then after a few years of being in businesses, I was like, you know, actually, think it's just as stressful to be in a business. So I think if I'm gonna take on that stress, I wanna be more responsible about it, but I'd rather be the one holding the bag at the end of the day, because at least then when it goes wrong, it's not because I couldn't convince somebody in a position of power to try it, it's because I tried it it didn't work. so that's a very long way of answering your question, but I think I've had a lot of scenarios that spun out of control. But when I embraced the fact that none of this is my identity or my value as a human being, it got much easier to walk away from something when it felt like it was no longer serving the purpose that I had initially set out for. And that makes it easier to set it down and do something different, which kind of de-risks a lot of it. Erika (08:51) Yeah, that kind of like idea of I've gone down this path, but like I know it's not the right thing. Like, what is it like sunk costs analysis? Like, you know, I feel like that's a tricky thing that a lot of people get stuck in of like, I mean, I'm also a career changer. It's like, and that Jason (08:59) the sunk cost fallacy. Erika (09:10) that crossroads was really hard to be like, I have done this for so many years of my life. Like I've invested all of this time and energy into like being this person, but like that's not right anymore. Like I need to find a different path. And yeah, it does. Jason (09:26) Can I ask you a question about that though? So when you changed over, how much overlap did you think there was going to be in the Venn diagram of like former career to new career? Erika (09:35) so I mean, the like quip is like I swapped out my keyboard. like, was also like a musician, I did music directing and like music teaching and then, you know, trained as a as a software engineer. So that's kind of the, the thing that I say is like, that's sort of where the where the overlap was. But I mean, functionally, it was Jason (09:40) Hahaha! Erika (10:00) Totally, totally different. Yeah, but like the things that I enjoyed about playing piano, like the practicing, the creativity, like that stuff I guess still does kind of translate. But yeah, I guess the, like the identity piece is definitely very different. it's, yeah, it's like separating the two and being like, this is... Like my work doesn't define me, but I'm also, yeah, like I have to make the choices along the way that, you know, get me to doing the thing that I see needs to exist in the world. yeah. Yeah. Well, so you also talked about like managing risk. And so... How did you measure the risk along the way? What are the signs to you that it's time to course correct or do something else? Jason (10:53) I mean, some of it is very like super pragmatic. If you have bills to pay, you know, then you have to be able to cover those bills. So if I'm doing a thing and I don't have a backup plan and if I stop doing the thing, I'll be broke. Like then yeah, I gotta keep doing that thing, right? So for me, what I've tried to look at is what are my safety nets? what are the choices I can make to help me move toward the things that I wanna do and how do I make sure that when I make the change, it's not stepping from something that was secure and working well into something that I have no idea how to do. I would love to, for example, be on a cooking show, right? And so I could burn my whole life down and start trying to be like a Instagram chef and see if I could build that career and I think I could maybe figure it out But the the amount of risk in that would be so high because I don't know how to monetize it. I don't have relationships in that world I don't know anything about what makes Food content work. I only know what I consume so I'd be operating off my instincts and basically nothing else Tremendously risky, but when I moved into what I was doing at code TV, I had been working in devro I had of relationships around the engineering world. I knew people who worked at every level of companies across most of the web dev space. And I had already done a lot of collaborative stuff with those companies as part of my roles at Netlify and Gatsby and IBM. So when I started making the transition, I actually started the transition a couple years before I left my job. because I was realizing, well, I guess I could do a little bit of sponsored content because I know it's good. Like it works well with the company that I'm in now. I was at Netlify, which is basically anything you can deploy on the web is a good partner for Netlify. So for them, they were happy because I was still producing stuff that promoted their product. But I could do these collaborations with these companies. And I started looking at like, okay, well, how much would this cost and how much of this would replace my income? And I started realizing that I'd started to replace my income, not 100 % but enough that I felt strongly that if I had the 40 hours a week back that I was spending at Netlify to focus on this business that it would very quickly replace my income. So it didn't feel like a risk, right? That didn't feel like something that I was doing without a safety net. And you know, my wife works and she works in tech so I knew that we'd be able to live off of her income for a while. I'm very fortunate that I've got a strong family support network so if I really, really needed to, my parents would always let me sleep in their basement for a little while and they'd... tease me relentlessly about it, but I'd be okay, right? I'm not out on the street. And so I had that support system in place that allowed me to take the calculated risk. And then I think on top of that, there's just these things that you can do to sort of test waters without having to go all in. And it's hard because it requires you to have side project time, which I think is again, that's one of my privileges is that because I don't have kids and because I don't have pets or a lot of extracurricular obligations, I can kind of start a side hustle and focus on that with a pretty significant amount of time to see if it's gonna work before I make a move. And if I think, you know, when I didn't have that kind of time when I was working as an executive and it was putting me 65 hours a week, I would try to figure out how to make the thing I wanted to do part of what I was doing. Kind of see like can I bring a little bit of video production into my work at netlify? And that was how I did it was I started pushing projects that like okay. Let's do some let's do the you know a high production commercial Let's see if we can build something that's ⁓ that's you know pushing the envelope on on like what a live event could look like if we had a good production crew and I was able to test those waters as well and start building those relationships so that when I did cut the ties with netlify Again, I wasn't starting at ground zero. I was able to step into at least a few ideas and it still took me a year and a half to get on my feet, but that year and a half wasn't me going, okay, I said I make videos now, what does a video person do? It was like, okay, I know what I wanna do, I've got some basic relationships, how do I convince somebody to partner with me on this in a way that allows me to fund it at the level that I know it needs to be funded? So it became more of like a sales challenge as opposed to a baseline skills challenge. And that all makes it all feel, you know, the risks feel lighter at that point. Erika (15:12) It kind of reminds me of the idea that you don't see 99 % of the work when the work is preparation. also kind of an idea of bringing ideas to the table, which already have some work behind them. I think this is applicable in the software space too, where people get really frustrated and they're like, well, I had this. Jason (15:18) Yeah. Mm-hmm. Erika (15:34) pitch for a project or like, you know, some kind of something that I want to do, but nobody is listening to me. and it's like, well, like, you know, maybe have like a stable of ideas that have been kind of worked out at least halfway. like, you know, kind of do the work before you do the work. And to your point, part of the challenge is finding the time to do that. Like, Okay, if I'm working on what my project is all the time, like when do I actually do this investigative work or ⁓ that kind of stuff? Jason (16:05) Right. Well, and I had, so I had an experience in software directly where I was at IBM and this was in 2016, I think. And the project that I was working on was this sort of GraphQL middle tier. We had 30 something teams in the area of the company that I worked in and they all had different microservices that all weren't communicating to each other. So everybody was. maintaining these bespoke endpoints that were super hard to track and there was just a big mess and a ton of tech debt because of it. And this thing that I had created was a way for teams to register a schema centrally. GitHub knows how this works. You have a million bespoke things that you wanna do with GitHub data, so a GraphQL layer really simplifies the way that you communicate that stuff out because people can sort of construct whatever they need. So it was the same general idea. Take that to IBM. and I met a ton of resistance on it. And I remember sitting down with one of the SVPs and I was just kinda, it was a skip level, I was complaining, I was like, why is this so hard? Like, this is something that when everybody who uses this has been really blown away by how much it saves them on time, everybody who's willing to give this a chance has gotten great results, so why is everybody so resistant to this? And he's like, listen, when you walk into somebody's team, they are all extremely busy, They've got a set of things that they have to get done. They are, you know, on the hook for stuff that they sometimes care about and sometimes don't. And they've got the things that make them feel valuable as developers. So when you come in and you say, here's your service, and they draw a box, and here's my service, and they draw a box, it's the same size. And what I want you to do is let me take over a lot of your stuff. They immediately go, well, that looks like a big. that's looks like a big lift. It's going to ask a lot for me and it's me giving up control over what I do day to day. And why should I trust you to manage this? Because this could go poorly and now I'm dependent on you for something that's already taking way too much of my time. And he said, so why don't you draw the box smaller? Like think about what it is that they don't like. What is it that makes them sad? What is it that makes their life hard? And what is the thing that they value? Can you come up to them and say, here's your service and you draw a box. and you say, here's all the things about your service that are burning your time that aren't valuable, that aren't gonna get you promoted. You've got security compliance, you've got maintenance, you've got all of these different rollouts, these bespoke endpoints, these 10 million teams sending you DMs on Slack asking for specialty stuff. This is all things that, that provides no valuable value to them in their business. And if you say, now look at my service, you draw a tiny little box, you draw the box as small as you can. and you say, now what I'm gonna do is I'm gonna automate compliance, I'm gonna eliminate the support burden, and I'm gonna make sure that everybody always knows what the up-to-date schema is for your service, and all you have to do is register this schema. Suddenly, they could understand the value in a way that previously it was like I was asking them to do more work. And when I re-articulated around what they cared about and what their stress points were, then suddenly they were thinking of it as like, so I can hand off this burden and it lets me focus on the stuff that I care about. That's more reasonable. And we, you know, we still met resistance because some people just don't want to change, but it was significantly lower resistance when we started reframing it that way. And so this idea of like shrink the thing that you want and frame it from the standpoint of what somebody is, what they're motivated by, right? And I think this is true too, when you're going to ask for time to like, work on technical debt or if you're trying to take a big swing at this really ambitious, weird project. I don't want to talk about it from like, okay, as an engineer, I get really sad when I have to work on legacy code because it's really hard and I don't like it. Instead, you go to the PM or the sales team and you say, okay, we want to deliver features much faster. We want our customers to get things at a much higher rate. If you are willing to let me build in three days per sprint to clean up these messes, we will be able to increase velocity by 15 % over the next quarter. And suddenly sales is going like, okay, but you're still gonna get features out? Yeah, I'm still gonna get features out, but I'll be able to get them a lot faster if you give me 10 % of bandwidth or 20 % of bandwidth to go after these features. It's really difficult to sell somebody on an abstract thing like technical debt, but it's really easy to sell somebody on a metric like velocity. And... But if you're willing to speak the language of the people who are doing the thing, it gets so much easier. I'm not 100 % sure how I got on this tangent, but... Erika (20:35) I mean, to tie it back, it's like almost kind of making unreasonable propositions reasonable where like you're, yeah, like on the on the surface of it, like, you know, maybe this idea that's like coming out of left field, like doesn't seem like the initial solution. Like it might not be the simplest path forward, but like, is it going to get us where we need to go? Like Jason (20:44) Yes. Erika (21:02) If so, then yeah, like maybe it's a shortcut. Maybe it's a bit of a winding road, but maybe it gets us to a better place. Yeah. Jason (21:11) Yeah, yeah, and like anytime you're trying to sell anything, know, the the you're already sold on it. So selling it in terms that you value doesn't benefit anybody because you you already understand the idea and why you think it's good. So it's more about understanding why somebody else would value it. And and that I think really it also helps you as the idea haver make sure that your idea is good and not just fun. I think one of my big complaints about software engineering in general. is that many of us are in software because we like working on code. And that means that in a lot of cases, instead of proposing a thing that would benefit the product, we're proposing something that would be fun to work on. And so when somebody says like, hey, what if we refactored the whole thing in Rust? It's like, but why? Right? And a lot of times if you dig down, the answer is because I really want to learn Rust. It sounds fun. And it's like, okay, but that doesn't actually benefit us, right? So as the idea have her, me taking the time to think about like, this actually gonna help anybody? Like, what is this gonna do for the marketing team? What is this gonna do for the sales team? What does it do for the customer? What does it do for product? If I can articulate those things in a way that doesn't feel like I'm just lying to get my way, then I know I have a good idea. And it'll be so much easier for me to communicate the value of that idea if I can speak to it on the terms of the people who need to approve it. Brittany Ellich (22:27) Yeah, that makes a lot of sense. It sounds like you have had a huge variety of experience throughout your career and done a lot of different things. So presumably you've had to teach yourself a lot over the course of your career. One thing you brought up is that you originally went to college and dropped out. And so I think that sort of puts you in the bucket of people in tech from like a non-traditional background. Jason (22:33) You Brittany Ellich (22:49) which is like just people who didn't go to school for CS, like Erica and like myself. Sorry, Bethany, you're the odd traditional one. that's true. Okay. Yeah, that's true. That's true. And I feel like that story is very common, especially for a lot of women that I know in tech, like pretty much all of them didn't go to school for that. And I'm curious how, like, do you think that that held you back at all in thinking about... Bethany (22:57) Didn't make major in computer science though. Yeah. Brittany Ellich (23:13) or like learning development work or do you think it's something that was like actually, you know, helpful in some ways? Jason (23:18) This might be my hottest take, but I think that the value of college is the network, not the skill set. Because if you go to MIT, you don't really learn anything that you can't learn for free on the internet. But what you get is access to a whole bunch of MIT alumni. And so it's much easier to get a foot in the door to get an interview because people want to work with people that are like them. And so if they're an MIT grad, they want to work with an MIT grad. But I don't necessarily think that skill set wise it had any positive. I mean I've worked with people who went on traditional paths who were absolutely brilliant and I've worked with people on traditional paths who literally can't accomplish any basic task. Like they're just full of academic useless knowledge and they want to argue minutiae that has no impact on the product. And I've worked with people from non-traditional backgrounds who are exactly the same. Some of them are rock stars and some of them are absolutely terrible. So it's I think it's far less about the background and far more about how curious the person is and how motivated they are to overcome hurdles and push through hard problems. But yeah, I don't think that, like I've been very lucky in that I was able to build a network through, I largely relied on conferences and that helped me get jobs that were at places that were sort of cool. I worked at Gatsby and. At one point in time, Gatsby was like the center of the front end universe for like this glorious three months, which was great for my network. And then that got me recruited by Sarah Drazner. And, and, you know, if you get a chance to work with Sarah Drazner, that's sort of like a, huge power up to your career because she knows literally everybody and is, you know, she's so well respected. So if you, if you get connected to somebody like Sarah, to somebody like Angie Jones, to somebody like there's these people that, are just these centers of gravity in the community. And I've been very fortunate to be able to get connected to and mentored by many of them. And so that, to me, that was my major advantage, was the people I've been able to connect to along the way. I think that had I gone to a college, I might have been able to get connected to a different group that would have allowed me to accelerate in a similar way. But I don't know. mean, I'm not very good at algorithms, so I guess I did lose that. Brittany Ellich (25:26) Aren't we all though? mean, that's very good at them for about three weeks before I have to interview for something and then other than that then, bad thing. Jason (25:26) Hahaha! Brittany Ellich (25:36) Is it that one? Okay. Erica convinced me to get this AI camera that like responds to hand signals and then I talk with my hands and ⁓ Erika (25:38) What the? Jason (25:38) Wait, what just happened? Erika (25:40) Yeah Jason (25:44) no. Erika (25:48) To be clear, I did not think of this as a positive, I don't know. There you go. Yeah, I think we might need to. The video quality is good, but yeah, this auto zoom thing. Like, why would anybody ever... No! Brittany Ellich (25:53) I bet you can turn it off. I bet that there's a way to disable it. Yeah. Jason (25:56) That's very funny. I thought you were just making a dramatic point. Brittany Ellich (26:05) It does work for that, usually, yeah, but it's usually when I don't intend to. Erika (26:09) Yeah. Brittany Ellich (26:10) ⁓ back to it. All right. So there was a point in your All Things Open talk that you brought up about consolidation is thinking, not just reading summaries. Can you elaborate on that a little bit? Like what does your process look like for learning things? How has it evolved? Jason (26:17) Hmm. So that comment, that comment is kind of born out of a frustration I have with, I feel like sometimes people hoard information and don't do anything with it, right? And so, I will never throw shade at people's process, but I always kind of wonder when, you everybody's bringing their AI assistant to a Zoom call, like has anybody ever actually read the notes from an AI Zoom summary? And I think the answer is almost exclusively no, vanishingly small percentage of people are really putting those notes to work. And I think the same thing is true if you read like an AI book summary or things like that. Like the ingestion of information is not learning or thinking, it's the synthesis, right? Like taking that information and doing some active work to take those thoughts, combine them with your own thoughts and experience, and then turn that into action steps or a new spin on an idea or a change to your perspective. And so you're kind of, it's not amassing information, it's actually consolidating information from the infinite points that you can get by watching every YouTube video or watching every conference talk or reading every article. And instead it's kind of. getting the information but then doing the work to turn that information into action. Whether that action is I've done the research and now I'm gonna do this project or whether that action is I've done the research and now I'm gonna change the way that I approach things because I learned something new. And so I'm very big on notebook. I think pen and paper is really good because it's like a wasteful medium. It takes a really long time and you're not gonna write something out word for word. So you necessarily have to make information capture lossy when you are going longhand and that requires you to think about what were they actually saying and not what did they say. So you're capturing intent. You're not capturing verbatim, just a quote, right? And so that I think just the act of listening to somebody speak and rephrasing it in your own words. I think this is why active listening and intent like tells you to do this is once you listen to somebody talk, say, okay, what I heard you say was, and then paraphrase it to show that you comprehend it, not just that you heard it, right? I think longhand notes are another way to do that. But you can do it a million ways. I know people do it through, they'll like type notes throughout a meeting and that's, you know, they're still synthesizing there. They'll, some people will actually take the time after a meeting to like look through the notes or look through the transcript and. turn that into a list of action steps. Everybody thinks in different ways, so I don't wanna say that you gotta do it a certain way, but I think the one non-optional step there is you have to actually use your brain to think about the information that was presented. Using whatever process you want, as long as that process isn't, I listened and clearly that's all I needed to do, and you just kinda move on and let that exit the other ear and it's gone forever. Brittany Ellich (29:22) For sure. Do you have any patterns or anything like that that you found that helps with that consolidation? Like we are constantly being bombarded right now with like new frameworks and best practices and architecture and all this stuff. How do you determine like what is actually useful and what's just noise? Or is it vibes? Jason (29:40) I, yeah, so I've always been a big fan of slow adoption because I made the mistake early on of trying to adopt the newest, coolest thing and of course, everything has a pretty short life cycle with few exceptions. So if you immediately jump onto the newest state management library and then later the creator of that state management library has a new idea so they abandon that project and start a new one, then you're left either maintaining the old one or having to migrate again. But if you wait six to 12 months, it'll still be good and you'll have a better idea of whether or not it caught on. And functionally, there's not a huge amount of risk in almost every like little software library. There's very, very little risk in adopting something new. So what I try to do is I try to marinate in the information without actually acting on any of it. And the thing that I've found is that through channels like social media, through newsletters that kind of keep up on, you know, there's like the Bytes.dev newsletter and there's a handful of others that are similar that are plugged into different pockets of the dev community. And they'll talk about things and you'll see the same names come up over and over again. And a lot of them you'll see once and you'll never hear about again because they were a really, really cool demo that didn't have as much practical application as everybody thought. And then once I'm ready to do something, like I have a new project, I've got this sort of atmospheric information that I haven't acted on. I haven't really thought about it, but I'm at least, you know, passingly aware that, okay, we've got to do this thing. I've been hearing a lot of people talk about these libraries for the last year that are related to this thing. So I have a short list now to pilot and I can build little projects that allow me to start actually synthesizing this ambient knowledge into you know, limited experience. And that then allows me to make, you know, much better choices, but it prevents you from like not paying attention at all would put me in a position where now I'm, you know, I'm like, okay, I have to do this project and I literally don't know what's going on. So I only know the things that I used the last time I approached this, which may have been five, six, seven plus years ago. And those might not be relevant anymore. Right. There's probably this, this industry moves fast, but because I've been sort of, you know, kind of keeping an eye on what's going on in social media, I'm at least passingly aware of options and also passingly aware of which ones have had sustained attention so that they are actually getting adopted and being used as opposed to ones that are just very hypey and good at getting a good launch bit of attention but not necessarily any sustained adoption or investment. But yeah, I I think it's really just a matter of figuring out where your attention should be and not closing yourself off to other information, but being willing to passively observe information that's not relevant to you right now with the strict goal of just being surface level aware of it until it's relevant to what you're trying to do so that you don't burn cycles on stuff that you can't act on. Bethany (32:33) That's so interesting. It's like the Gartner hype cycle with like the, or your overinflated expectations, trough of disillusionment, and then the like plateau of productivity or whatnot. But I love that optimizing for that last part. Exactly. And then it just works. Jason (32:37) you Yeah, if you drag your feet enough, you wait until the plateau. Bethany (32:51) That's awesome. And I think that's a really wise way of going about things. It's so easy in this industry to get caught up in that hype cycle, ⁓ especially now with AI and how fast and rapid things change. But it is interesting to see what are the lasting things? What are the things that actually are worth keeping around? So I think that's definitely wise words. Jason (33:14) I think it's, I mean, it's, hard when you watch, you know, the way people talk about this on the internet, but vanishingly few things that we work on are super time sensitive or super sensitive to the specific technology. and most of the things that people are building with AI, the new joke is, okay, congratulations, you made a state machine that's non-deterministic. You could have built that whole thing with no AI. And that's very commonly true because people are trying to adopt this tech into their stacks. But that was true when everybody was rushing to adopt things like Redux or everybody was rushing to adopt Rust or everybody was rushing to adopt Kubernetes or everybody was rushing to adopt Docker. And like any of these things is like they're useful when they're useful, but if you just shoved it in because it was new and you were like, we're gonna make this thing work, then a lot of people I think found themselves... doing the equivalent of like deploying a Next.js site for a marketing landing page, it's like, why are you shipping somebody nine megabytes of nothing for a static image and a like sign up for my newsletter form? It just doesn't really make sense. But we get swept up into this hype of like, well, we have to use this or else. And it results in us kind of having a lot of big heavy things to maintain because they were cool to ship, but none of it was actually useful. And the people using the website honestly would have been way happier. if we would have shipped something far more boring, far more stable. And like that's not to say that any of the things I just named aren't useful. But now that it's been long enough, most of us can kind of spot, hey, this thing we're building is complicated enough and does have enough uptime requirements that standing up Kubernetes is worth it. This other thing though, isn't. Like it would be a lot of work. It would require a lot of maintenance and ultimately if it goes down, nobody cares because it's not a moneymaker for the business. So let's not invest the engineering resources in making that happen. So I think, yeah, just, like, as much as it's kind of funny as a technologist to say, drag your feet as much as you can, I have found that being slow to adopt has saved me a lot of heartache because very, very few things that I've built were made or broken by the tech. They've all been made or broken by the value they deliver to the person using it, and that is almost never determined by the underlying stack. That's determined by the quality of the build. and you can build really, really, really good things with Fortran today. Like, should you? Probably not, but like, it's still possible. The tech doesn't go out of style. It goes out of fashion. It doesn't go out of functionality. Bethany (35:35) Yeah, this reminded me of your point earlier about developers wanting to build something to learn something or because it's fun. It absolutely would be fun. A lot of these are really cool technologies, but at end of the day, it is a solution looking for a problem rather than vice versa. Jason (35:45) Mm-hmm. Yes, 100%. Bethany (35:54) That's awesome. All right, we are getting close to ending time and we do have a fun segment. But before we get onto that, I'm curious if you have any thoughts on how you continue to be unreasonable today or like day to day, if there's anything big coming down the pipe you can share or anything like that. Jason (36:10) Yeah, think, I mean, the idea of being unreasonable is, I guess the thesis of it is like, everything that I've ever imagined has been something that, you know, very reasonable people around me will say, well, couldn't you do the same thing with like X, Y, and Z existing solutions and it would be a lot less difficult and it's kind of already established? And I just, and like, yes, I could have, but I didn't want to. Like I wanted to explore and see if I could push the boundaries and figure out how to do this thing that I could imagine in my head but that didn't exist yet. So the idea of being unreasonable is just sort of, know, if you've got this hunch and you feel like something's gonna work, if you can manage the risk away, then there's not really a downside to trying it other than the time. And my philosophy has ultimately become this form of. I've heard it called sunny nihilism where I believe that the only true meaning in life is internally assigned. And so for me, time spent on a thing that is interesting and challenging is not wasted time, even if it doesn't work. So my value of like what an unreasonable thing does is pursuing that allows me to eliminate a regret. So I'm not like on my deathbed looking back going, you know, I wish I would have taken a swing at this TV for devs thing. Like, I feel like it could have worked and then I chickened out and I took this other job. Instead, I'm gonna look back and I'm gonna say, I did that thing. And maybe I'll look back on it and go, boy, that ⁓ was a long hard road to nothing and I'm so glad that I stopped doing that and did whatever comes after this. Or maybe it's not, but either way, it's not gonna be a regret, right? It'll just be a lesson that I learned. And so in that same spirit, like a lot of what I'm pursuing now is seeing if we can push it further. I'm looking at right now, everything that we do is what's called a standalone episode. They're self-contained. You've got a different cast every time, a different challenge every time. There's no continuity. I really want to get to arc seasons where we have a story that carries through the entire season. Budgets are much higher for that sort of thing. I'm also looking at getting into interactive software hardware humanity combined experiences. So I'm working on some early prototypes with some companies for can we build a giant like contraption at events that's powered by software powered by different hardware bits? Can we use pressure plates? Can we use RFID? Can we use actual physical cranks and knobs and levers so that we can build these fun experiences that are you powered by humans that give people who participate in the events something super memorable, right? And then we, of course, make a bunch of content about how we made it, about the people who were there, who participated in it. You know, we can do a bunch of shows on like how we use this particular company's technology to build this thing, which is the value for the company. And so that's like the next big swing I'm taking is can we, like effectively, could I build something that is a hardware and software connected escape room that we could install at events and make that a game that anybody who wants to can play. Like that's kind of what I'm imagining. Bethany (39:14) That's amazing. I will be first in line for whenever that comes out, so please keep us updated. That would be amazing. Erika (39:18) you Bethany (39:21) Awesome. Well, this kind of goes into our fun segment, actually. So it's been really fun seeing on CodeTV a lot of TV shows getting the treatment of the developer treatment, so making it more applicable to developers. So I thought we would go around and maybe think of a TV show that we would like to see get the CodeTV experience. ⁓ Jason (39:34) Mm. Oh, I love this. I didn't realize I was going to get free market research. Hold on, let me get my pen. Bethany (39:46) yes, exactly, exactly! Yes! Take notes! We only, well, these are free, you can take them, so, yeah. Jason (39:57) you'll all get executive producer credits. Bethany (39:59) But I can go first because I feel like I've been thinking about this for a long time and I really would love to see like a developer or code technology, big tech mockumentary. So like ⁓ the office treatment or parks and rec treatment. would, I just feel like the tech space is ripe for something like this. Like dynamics between project managers, product managers and devs. Like it just, it feels so perfect. Jason (40:10) Mmm. Bethany (40:25) That would be mine. Jason (40:26) Love that. Erika (40:26) I feel like this is already kind of in the same vein of what you're doing, but like, I always reach for musical treatments of software concepts. I think about the segments on Whose Line Is It Anyway, where they have to get up and do a song about a topic or something. Yeah, I don't know if... Jason (40:47) Mmm. Erika (40:50) like the Venn diagram of like musicians and software engineers is like close enough where like that could work in any way. But like, I think that would, that would be really fun. Jason (40:54) There's so much overlap in that. I love that. Brittany Ellich (41:04) Great. So I had a couple of other ideas, but while you were talking about building like those cool experiences, I was thinking about these shows I used to love to watch. I personally don't care about cars at all, but my dad used to watch these car shows where they would like get this old car and like completely refurbish it. And like they were so engaging because there were people like going in and like showing like all these things they did to make it super cool. Jason (41:25) Mmm. Brittany Ellich (41:29) I don't know what that genre is, but like, I didn't even care about cars and I would watch it. Jason (41:33) Like the, yeah, like the home improvement style, but toward like take a thing and customize it. Yeah. Erika (41:40) you Brittany Ellich (41:41) Yeah, like take a thing, like build a thing for this experience or like, you know, like you really get in the weeds of like, and this is this cool thing we did to make this work for software and or hardware experiences. I think that that would be fascinating and educational. Jason (41:49) Mm-hmm. Yeah, that would be really fun. Bethany (41:56) There's so much of that in the gaming space, like taking old game consoles and stuff and retrofitting it. That's such a smart idea. Jason (42:00) Yeah. Erika (42:03) Yeah. Brittany Ellich (42:04) Mm-hmm. Jason (42:05) Mm-hmm. Yeah, and like even even with like game mods, know like people are get so creative with the way that they can take an engine and Like come up with something that's nothing to do with the original game, but it's still super fun I you know, I think there's a ton of creativity in that space and and so finding a way to showcase that would be wonderful Brittany Ellich (42:25) Yeah, creative coding is really cool. Jason (42:27) Mm-hmm. Yeah any kind of creative coding and Erica to your point. Have you ever seen? There's like these these musicians that are they're sort of like a coding collective to like misuse technology on purpose but they do things like ⁓ live DJ sets where they code the music and they've got ⁓ apps like processing and and there's another one that's popular now that I forget the name of where you can kind of like set up the beats for each of the instruments and then you can do randomization or you can set like the scale so that it plays within or you can add effects and you know all this kind of stuff. But then they'll also while they're doing their live DJ set they'll have another programmer sitting with them live coding a shader that's reactive to the music. So you've got like two people up on stage one of them is making a beat the other one's making a shader that's being projected so that it's reacting to the song in real time. And they'll do these like after party DJ it's so cool. Erika (42:58) ⁓ yeah. that's fun. Yeah. Yeah, that does sound, I'll have to check that out. Maybe you can ⁓ send me if there's any videos. Jason (43:27) I have ⁓ one person I follow that I love that does this is Char Styles and I can send a link to go in the show notes but Char has been doing this for a long time, was on Learn with Jason years ago teaching me how to do some of the live programming stuff. But Char's got a collective in Brooklyn, it's like a warehouse of technical weirdos that just get together and kind of break stuff in creative ways and it's so fascinating. I love the whole ethos there. ⁓ Erika (43:54) Yeah. Jason (43:55) It's one of those things that's like, do I wanna move to New York just to be closer to people that do weird stuff? I'm like, probably not, but like kinda. I'm also not cool enough to be in their club, but like they'd probably let me show up every once in Brittany Ellich (44:03) You Jason (44:08) Like bring your dad to work day, they'd let me there. Erika (44:10) Well, what about you? What's coming to mind? Jason (44:13) So I have been trying to get, so the kind of escape room concept leads me toward some of the old shows that like American Gladiators and stuff like that where they were kind of a combo of physical things. There's a show called Legends of the Hidden Temple on Nickelodeon that I used to love that was a combo of like trivia stuff as well as physical stuff which I thought was really fun. And then I'm also Like my brass ring, the thing that I wanna make more than anything right now is I wanna bring back Anthony Bourdain's Parts Unknown, but I wanna make it about tech communities. So I wanna visit cities around the world and highlight how the tech communities work there through the people that work there, through the different communities and through the companies that employ them, kind of showing off what it's like. Because I feel like a lot of people see tech on the internet and they just think it has to happen in Silicon Valley. And so I'd love to show people what it's like to, you you can work in tech in Medellin, you can work in tech in Amsterdam or Nashville, and it's still a great career that has a ton of upside. You don't have to go to San Francisco for the big opportunities. Erika (45:14) The first startup that I ever worked, or the first job that I ever had in tech was for a company called Built-In. And it has a similar kind of like idea of like highlighting tech, like local tech to different communities. So I will send you a link, but they could be a fun like contact for you. Jason (45:20) Hmm. Yeah, please do. Yeah, yeah. Bethany (45:40) That is awesome. I love that. And I think every tech community does have its own flavor of what it does. And for example, like where I live, it's a lot of FinTech and that has its own like problems and situations and stuff. So I love that. That's, that would be so cool if you do it. I am, I'm staying tuned and definitely, definitely watching whenever that drops. But all right, this has been such a cool conversation. I wish I had a pen and paper here to take Jason (46:00) Hahaha Bethany (46:09) down half the notes that I was wanting to write in my book when I was hearing you talk. So thank you so much for joining us and chatting with us. ⁓ Where can people find you? Jason (46:17) Yeah, thanks so much for having me. I have all of my links on json.energy slash links. It's kind of a, made my own little link tree. And that's gonna have, that's everywhere that I am. Bethany (46:30) Awesome. Well, perfect. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, join us on Discord, and share with your friends. Until next week, bye. --- ## Episode 36: Navigating the future of AI agent security with Dan Moore - URL: https://overcommitted.dev/navigating-the-future-of-ai-agent-security-with-dan-moore - Published: 2025-12-02 - Topics: AI & Developer Tools, Technical Deep Dives - Audio: https://anchor.fm/s/102586d64/podcast/play/112004303/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-11-2%2F413573088-44100-2-dff415c55aed1.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, Erika and Brittany discuss the evolving landscape of AI agents and their implications for security and identity management. Joined by expert Dan Moore, they explore the challenges posed by non-deterministic agents, the importance of granular permissions, and the need for developers to be aware of security practices as AI technology advances. The conversation also touches on industry standards, the role of developers in navigating these changes, and personal reflections on the future of AI. Takeaways * AI agents are changing the landscape of software development. * Non-deterministic agents present new security challenges. * Granular permissions are essential for securing AI agents. * Developers must be aware of security practices in AI. * Industry standards for AI security are still evolving. * Separation of concerns can enhance security for agents. * The role of identity and authorization is critical in AI. * Business implications of AI agents are significant. * Developers should stay close to business needs and problem-solving. * The future of AI will require new skills and awareness. Links * Dan Moore on LinkedIn: www.linkedin.com/in/mooreds/ [http://www.linkedin.com/in/mooreds/] * Dan Moore on Bluesky: https://bsky.app/profile/mooreds.com [https://bsky.app/profile/mooreds.com] * Simon Willison - The Lethal Trifecta: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ [https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/] * FusionAuth: https://fusionauth.io/ [https://fusionauth.io/] * AGNTCY: https://agntcy.org/ [https://agntcy.org/] * Amazon Bedrock AgentCore: https://aws.amazon.com/bedrock/agentcore/ [https://aws.amazon.com/bedrock/agentcore/] * FusionAuth Guide to OAuth: https://fusionauth.io/articles/oauth/modern-guide-to-oauth [https://fusionauth.io/articles/oauth/modern-guide-to-oauth] * MCP and OAuth: https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol [https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol] * MCP Specification: https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization [https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization] Hosts * Overcommitted: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host today, Erica, and I am joined by... Brittany Ellich (00:09) Hey, I'm Brittany Ellich Erika (00:11) We met while working on a team at GitHub and quickly realized we were obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. 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, we are not just talking about securing users, we are talking about securing autonomous code that they control through AI agents. Specifically, as these agents move into our enterprise systems, we're asking the fundamental questions of who are you and what are you allowed to do? And these become huge challenges for our security stack. So to help us navigate this critical shift, we are bringing in an undisputed expert in identity and authentication, Dan Moore, who is the senior director of CIA Strategy and Identity standards at FusionAuth. We will be discussing what current identity protocols are being challenged by the rise of agents and what new standards are emerging to give autonomous coding agents a more secure, verifiable, and official identity. So, Dan, welcome to the show. Let's talk about this evolving landscape of identity. Feel free to introduce yourself. Say hi. Dan Moore (@mooreds) (01:37) Sure, yeah, yeah, hey, thank you so much for having me. Brittany and Erica, I am thrilled to be here. the short answer about who I am is I've just been in the developer world for about 25 years, played on a lot of different roles. My current role, as you mentioned, is at FusionAuth. We're an authentication provider. we are really focused on customer authentication, but as... you alluded to, a big part of that, at least in the last year or two, has been, well, what is agents? I know we're gonna kind dig into what that is, but we are extremely interested in kind of helping people secure their systems for users as well as for agents. Erika (02:18) Well, yeah, you teed it up perfectly. Let's start there. When we talk about AI agents, what exactly are we talking about? Is it just a fancy name for a piece of software, or is it something different? And do we even have a definition? Dan Moore (@mooreds) (02:36) Yeah, I think it's a great question because I think the honest truth is that people are, there are definitely people out there using AI agents to accomplish tasks, to get stuff done, especially in the coding realm, but also outside of the coding realm. But I think that we're still kind of groping our way towards an actual real definition of something. But the way I think about it, and this came up in conversation the other day, is it's really like a workflow or a set of pieces of software that can accomplish workflows, which we've had for decades, right? Workflow software's been around for a long time. The difference is that the workflow used to be defined in code or in static configuration, and now it's more in natural language. And so the idea you can actually kind of give an agent a task in relatively natural language and have it... not to overuse the word grope, but grope towards accomplishing it, which is what they do, is to some extent a game changer. Erika (03:33) Well, so yeah, when this piece of code does start making decisions on its own, how does that change some of these security risks that we face? And what are the biggest things that we need to worry about when it's an agent authenticating or authorizing versus a human? Dan Moore (@mooreds) (03:58) Sure, and I will say, it is worth taking a step back and saying, the security problems that these new agents create are similar. maybe they're a little bit different in scope, they're similar to the security problems that we have right now, right? Because there's plenty of security holes that humans drive through that agents are going to also be able to kind of attack or exploit. I guess I just want to say before people get all concerned about securing AA agents, they should be like, hey, what are we doing to follow all the rules and all the things that we should do to secure stuff ourselves? Anyway, so set that aside. The way I think about it is that human beings are slow and non-deterministic and software as written five years ago, 10 years ago, even the vast majority of software right now is... fast and relatively deterministic, right? Charity majors might have some issues about that, how deterministic it is, but it's pretty deterministic and easy to reason about, whereas agents kind of fall in this middle ground, and so they are fast and non-deterministic. So there's this great thing called the lethal trifecta, which Simon Wilson, who's written a ton about AI and LLMs in general talks about. the idea is that agents have access to private data, which again, software does too. It's exposure to untrusted content, which again, software does too. And then... there's the ability to externally communicate. And so the issue is that because agents are non-deterministic and because they read that untrusted content, they can then be instructed to access your private data and then send it off in an email. And this is a real, I mean, I would consider this to be a new threat because of the ability to follow arbitrary instructions, right? Like if a piece of code got an arbitrary instruction, it didn't understand. I should be careful here. There are ways to craft it, but it's a much higher bar to like make a deterministic piece of software do stuff it's not supposed to do, whereas with agents, they found over and over again, it's relatively easy to do that. Those are kind of the bigger changes that I see coming down the pike is how can we address this? I mean, the non-determinism is the joy and the pain of agents, right? Like the fact that we can like give it something and as I mentioned earlier, it can kind of maneuver its way towards achieving a goal is a huge win. But that also means that other people who can communicate with it can do the same thing and kind of bend the agent away from the goal that we set it. Erika (06:26) And non-deterministic in this case, meaning, can you like sort of define that with what you mean there? Dan Moore (@mooreds) (06:32) Sure. Yeah, yeah, yeah, that's a great, great, sorry, I shouldn't, I work in the auth space and like using jargon is something that like I try not to do because it's so easy to kind of get over your skis and assume kind of everyone knows what you know, but that's a great call out. So non-deterministic in my mind means that, or sorry, let's start with deterministic. Deterministic is you give, the same inputs and you get the same output. So math is a perfect example of the deterministic system. Gravity to some extent is too, Whereas non-deterministic means you give it the same inputs and you won't necessarily get the same outputs. Weather, human society, conversations with your partner, like these are all things that are non-deterministic because they're affected by the current state of things. And so if you've ever asked the same question of an LLM, you're gonna get back slightly, I mean, here's the thing, they're slightly different, right? Or they could be kind of massively different depending on the way that, well, I should be careful here because I'm definitely not an LLM creation expert, so. But at the end of the day, it's not a system where you put in the same thing and you get the same thing out. Erika (07:50) Makes sense. Yeah, so you're saying that that creates scenarios where it's unpredictable how they might act in different scenarios. Dan Moore (@mooreds) (08:01) especially with untrusted input, right? Like that's where it gets really kind of scary. And the honest truth is, unfortunately, we think about untrusted input as something an attacker provides, but it could also be we make a mistake, right? Like we fat finger something, or we aren't as clear in our tent as we want to be. And that's all input that like, you aren't sure how things are going to go. And that's a new kind of security. rep model. Erika (08:28) And yeah, I guess it, like there's different boundaries where this can be dangerous. Like within your own system is one thing and then sort of like crossing system boundaries too. there's the question of like how much context how much data gets like carried across from one system to another and you're talking about like, privacy, like, you know, how do I authorize this context versus something else? Dan Moore (@mooreds) (08:57) Yeah, I think actually that points to one of the solutions to this is that you start to have these kind of subagents that you know may have access like I mean one way to deal with that lethal trifecta I mentioned is that like you have different agents that have access to different sets of tools or different sets of data and if you have one that can read your email and another that can send your email, it's gonna be really hard for an attacker to be able to kind of get that email. you know, that private data sent off because you have to like basically now attack two different LLMs. So kind of more separation of concerns, which again, this is not software. It's not revolutionary, right? It's a lot of the same principles. We're just having to apply it in new context, right? Separation of concerns is a great thing for security. Erika (09:47) Right, yeah, going back to your point where the best practices for human authorization is the same idea for agentic authorization. You don't want to give a human the keys to everything across all system boundaries. We try to enforce data protection and data privacy and minimum required access controls. same rules apply for agentic identities as well. Dan Moore (@mooreds) (10:16) Yep. Brittany Ellich (10:16) This is very fascinating. I don't personally work on the identity side at all, so I'm just a software engineer and I just want to know like what do I need to do to keep these things working and not exposing anybody to problems? But I'm curious. I do work on the enterprise side and I'm curious what you're seeing right now in terms of enterprise adoption of agents. Are there any like specific business or administrative problems associated with with? that companies are experiencing or butting up against when they want to use agents. Dan Moore (@mooreds) (10:45) I mean, I guess I would say that like first of all, it feels like there's a ton of people that are experimenting with this stuff. And I think there's definitely a feeling that there's a there there. I think that I have not seen some really large public like case studies where people are like successful with this. And I don't know whether that's because it's harder to be successful with or because the people who are successful are keeping their lips. shut because it's like a big competitive advantage. You definitely hear about people doing this around coding. I definitely have interviewed people that are doing the spectrum in development and finding that to be very successful is kind of a one person show, which obviously is kind of the opposite of an enterprise, which actually speaks to, think one of the complexities is I feel like when you're doing greenfield development agents. are an amazing productivity boost, whereas when you're doing brownfield development or improving existing software, suddenly there's a whole lot more context that needs to be available to the agent for it to make intelligent suggestions, and it's less of a... It's less fun, right? Or maybe it's less, that's wrong word. Fun is something that human beings think about green field development. It's less capable, might be a good way to put it. But I think that around your specific question on enterprises, anything that is doing text evaluation, I talked to somebody recently who is doing extraction of form fields. know, lot document management stuff, think AI is a good fit for, you know, as far as kind of pure agent stuff, like the honest truth is, I feel like there's a lot more smoke than there is fire right now. There's a lot of people who are like building out all these agent systems. And then you ask them like, hey, I shouldn't say a lot of people. I'm familiar with a couple of people who've built out some agentic systems and you're like, this is cool. Like who's using this? And they're like, well, I am to build other products. And you're like, that's great. Right. And that is a definitely use case, but it's not like the enterprise is like pulling people in and like saying, Hey, we need to do this. Now, one thing I have heard is that Having a natural language interface of an LLM into data and into documentation is very powerful for improving the knowledge worker experience, but I don't know I would call those agents, right? That's like more just like a more natural language interface. Brittany Ellich (13:02) Yeah, that makes sense. Are there any standards or is the industry approaching any sort of way to make sure that these are actually secure? I feel like you said that there's not a lot of people doing this yet, but there's lots of concepts of plans towards doing it. I'm curious, is there anything that the industry as a whole is saying, okay, this is a way that we can trust securing agents? Dan Moore (@mooreds) (13:26) Sure, so you actually kind of asked two different questions, is... Are there standards and are we converging? I think that like there are hundred percent standards. I just went to the IETF meeting in Montreal and there was, I think AI was mentioned in every single meeting I went to. And I went to most of the web stuff. I didn't go to like the telephony stuff, but like there was an agent draft mentioned there. I think in every single meeting I went to, but I think that it's all still early, early days. And so they're trying to solve, in some cases they're trying to like think of agent identity as workload identity, right? So there's the whimsy group, there's a draft from Aaron Parecki who's an octoguy who's talking about cross, cross-trust boundary authentication. I feel like There's two kind of main ways that agents communicate. There's the agent to agent protocol, which basically has a lot of different, it's kind of a pick your flavor kind of. protocol when it comes to identity. And then there's MCP, is Model Context Protocol. And that seems to have been kind of standardized on OAuth for the majority of kind of enterprise use cases. so there's a lot of activity in the OAuth working group around some of the kind of follow on standards around that. Like how to make it easier for MCP clients, which essentially are like IDs or other kind of AI agents to register with an authorization server and then like what goes in the token. But to me, a lot of this comes back down to what we talked about. earlier which is doing stuff that we know is good practice which is like principle of least privilege, its sophisticated authorization schemes maybe past RBAC, right, once you get a certain size like ReBAC or ABAC or PBAC and the nice thing about employing those is that helps you whether you're implementing for agents or you're implementing for users at scale and I still think that those are underappreciated and under implemented. But maybe AI agents will be a catalyst for pushing more people to handle that. Brittany Ellich (15:37) Yeah, it kind of seems like the average developer needs to know a little bit more about security and auth than they ever really needed to before. At least right now until there's like, you know, an idea around like the right way to do this because people are still trying to figure it out. What would you rec... go ahead. Yeah. Dan Moore (@mooreds) (15:53) And actually, can I ask you real quick? mean, so when you say that, like, do you mean because they're using AI agents and so they need to have some consciousness about that or because they're building software that will be used by an agent or why do you think it developed? Why do you think now is the time for? Because security people have been like developers need to know about security for, you know, shift left and like, you know, for a long time. So why is now why is it more important now in your opinion? Brittany Ellich (16:22) I think that there's like more out of the box options for regular auth than there is for AI agents where like I would never do it. I would never roll my own and figure out how to do this for like any website that I create. But if I'm creating some sort of an AI agent, like it doesn't sound like there's like a thing that exists yet that I can say like, okay, this is going to cover a lot of the security concerns. ⁓ Dan Moore (@mooreds) (16:43) I that makes sense. And I think some of that's because it's early days and some of it's because the protocols are still being like hammered out, right? Like the MCP spec, there's a new release coming in 11 days and it's going to have some shifts even in how you do kind of OAuth for MCP clients. And that's like, you know, it's only been out for a year and there's already been like multiple different ways to do stuff. So that makes sense. Thank you. Brittany Ellich (16:50) Mm-hmm. Erika (17:11) I think also like, unawareness that this standardization is like still forming is also important because I mean, I guess there's like the whole legal side of things where like that isn't even figured out yet necessarily of like, if I like if I direct an agent towards a certain goal and it takes nefarious to get there, am I responsible? And like, I don't know, like we're mentioning like what, you know, the risks are as a developer, like why you might need to know, like, you know, as a developer knowing like, hey, somebody potentially like promises me this agentic workflow that's gonna like solve all my problems, like, okay, well, like, you know, both eyes open, like. look at what it's actually doing, like understand that, you know, this, this, like identity and authorization piece might not necessarily be a completely solved problem yet. So like if somebody's promising you like, you know, all the guardrails are there and like, don't worry about it. Like maybe question that, maybe look at it twice before you like, again, like kind of authorize it to do, something that you wouldn't want to be responsible for. Dan Moore (@mooreds) (18:32) Yeah, that's a great point. There is a little bit Wild West feel to a large chunk of this right now. And just like, I think... I mean, I'm trying to think of like an analogous situation. Honestly, it probably is a little bit like the early internet, right? When people weren't sure like what to do about credit cards or could you even pay with something over the internet with a credit card? And developers, to Brittany's point, needed to be a lot more like cognizant of that kind of stuff. Now it's a lot more accepted. So there's, you don't even think about that kind of thing, but we're in back in the early days, which is, which is exciting and scary and spooky all at the same time. Brittany Ellich (19:12) I feel like I'm hearing that crossover and overlap a lot in a lot of different spaces right now. Like everybody's like, this feels like the dot com bubble, you know, not just in terms of what's coming out, but like economically and like, you know, just the vibes that we're getting. And it's going to be interesting because I think, you know, obviously we're still using the internet, even though at the time I would imagine it probably felt like we were, you know, not going to for a while. So, Dan Moore (@mooreds) (19:38) I think people always knew that it was gonna be big. I don't think people like knew exactly how in depth it would get into our lives. But I don't think anyone after even like 99, 2002 when it was like the depths of the nuclear winter, people weren't like, I'm never gonna use the internet again. It was just too easy to do things. So, you know, and I think that is exactly analogous here is like, there's no doubt in my mind in five years from now, we'll be using gen AI in some form, right? Like what it actually looks like, I don't know what's the Google maps of gen AI. You all are too too young to remember Google Maps, but it was it was amazing when it came out you're like my god I can scroll around and like and it blew my mind and it's not it came out of Ajax it came out of the early internet, but like it was not something that like any Anyone people had to invent it so like what are the things that people are going to invent with AI? so I were kind of far afield from authorization and identity, but I don't want to be like an old man shaking my fist on the lawn, I feel like we are going to have those kind of moments again in the next couple of years. Brittany Ellich (20:47) Yeah, yeah, I agree with that. is there, so before we go back to the authorization space, I'm curious, you having had the experience of living through that time, is there anything that you're telling developers right now, like things to do for their career to like, you know, bubble, prevent themselves or anything like that to like, is this, I mean, obviously these generic skills aren't going to be completely useless. Cause like you said, we're probably still going to be using it. I'm not going back to the time where I had to write tests. myself. Like that's, just not happening. So I feel like there's still going to be something that's around. So are these skills still worth investing in, in your opinion? Dan Moore (@mooreds) (21:21) AI skills or what skills I'd recommend. Brittany Ellich (21:23) Yeah, AI skills, AI development, know, like building these AI agents, it worth, you you think these are still going to be around? Dan Moore (@mooreds) (21:30) I mean, I don't know enough about AI agents to tell you that, right? I think that like whenever there's a new tech coming on and this happened with mobile, it happened with cloud, happened with the internet itself. happened with like react like there's like two paths or you can either be kind of at the forefront surfing that and like making the investment in time and energy to kind of be that local an expert of some kind right you can be local to your company you can be like in your community you could be like worldwide like but like staking a claim to that and I've seen people create great careers doing that then there's the people who are like actually I'm gonna be a follower and I'm gonna wait for things to shake out which is a little it's a different kind of risk, right? Because it's possible that you could miss something that... is good and you won't be able to like stake your claim as widely, right? If you're the thousandth React developer, you're not going to be as known as the second React developer, but you also miss on things, right? Like, so you might miss Ember.js or Meteor, right? Which were big, big, you know, front end frameworks for a little while. And then now I think they're still used, but like, they're definitely not winners. And so if you're a world-class expert in Ember, your options are a lot smaller and you've invested a lot of time and effort than if you're a class actor to react. So the only thing I would say and if someone came up to me and said hey how can I avoid getting smacked around by this bubble it's like be close to the business, understand how to solve problems, be a collaborator and you know. and be aware of these technologies. I don't think you need to be an expert in them, but think you need to be aware. mean, listen to podcasts like this one, right? And like, be aware of that. Be aware of this kind of stuff so that when it gets to the point where you're, you're not blindsided, but being close to the business and like, I mean, I honestly think that there will be an idea of a developer 15 years from now because... taking people's wants and desires and determining what's real and what's what they will pay for and what how it fits into complicated techno social systems like software like big software projects that is not a normal skill and that is a skill that like I think developers are well suited to like offer not programmers you know as I use the term programmer I said developers in my in my mind. Erika (23:58) Thanks for the plug for this podcast. I appreciate it. Extra boost. Let's go back to authorization and dig a little bit more into technical details. So when an agent needs to open a file or an internal tool, In your mind, how is the best way for it to prove that it has permission? Is it sort of giving a machine a broad security pass, or do we think that the system needs to evolve to adapt to having a more native agent ability within the system to have specific granular permissions? Dan Moore (@mooreds) (24:42) I mean, I think that... Granular permissions are the way to go for sure like and if you know I think that the two paths you can lay out are like API keys and Or tokens right or access tokens, and I feel like to some extent we talked about echoes of the past like this whole AI making like Software like calling other software services feels a lot like the API landscape of like the 2010s And we've been through that and I'm not saying OAuth is perfect. I'm not saying bearer tokens are perfect, but there's like a lot of infrastructure around it. It's kind of a well-known protocol. And so I think that... OAuth tokens properly constrained with scopes and probably fine-gained access behind that, Reback, RBAC, PBAC, we talked about that a little bit, is probably the path forward. I'll also say that's in kind of production context. I think there's this idea of like non-prod context of like your own laptop where you can YOLO things a lot more. And I definitely have read, this was probably six months ago where someone was just like, I just gave clog total access to my computer and it can do whatever. it want and everything's under git control, you know, and push remotely. So if it totally blows things up, I don't care because I just kind of fall back and then I can just type whatever I want and and clod can I can run wild and I would never do that in production but in non-prod it seems like it's a good way to build an intuitive sense for like how this piece of software, you know, interacts with the environment it's in. Erika (26:14) Makes sense. For Fusion Auth specifically, how are you focused on identity right now and what are you planning in this new wave of non-human users? Dan Moore (@mooreds) (26:25) Yeah, I would say first of all that... As I kind of mentioned earlier, there's a ton of still web apps that are like, you know, Brittany, you said that you know how to put Auth, use Auth into a normal app, and I totally agree that a lot of folks do, but there's a ton of folks, and I've been at conferences where they're like, yeah, we still maintain our own Auth system, or we rolled our own. So there's a lot of hate being made just from that perspective, right? But we are an OAuth system. ⁓ support some of the grants that I would expect agents to use. I've been playing with AWS Agent Core, is a agent building framework that AWS is going to be, they just went in GA and they're going to be talking about a lot of re-invent. I've been playing around with that and that's all using kind of client credentials grant for OAuth or the authorization code grant. those are kind of, client credentials is good for when you have agents talking to each other kind of that are independent. And then the authorization code grant is great when it's Dan who wants to delegate access to an agent to go update his Google Calendar or interrupt his other service on behalf of Dan, so the delegation scenario. So I think that in... I don't see right now any reason from the identity and authorization space to kind of reinvent the wheel. It feels like we should push OAuth and I mentioned it was being brought up in the IETF. There's definitely extensions coming that are talking more about that aspect of it but I think that there's no… From what I can see, there's no reason to kind of throw the entire thing out and kind of start from the beginning again because we have these building blocks that work for software and work for humans right now. as I mentioned, agents are kind of a mix. And so I think we can continue to push the OAS specifications forward and solve these problems. Erika (28:22) I am going to take some homework and learn more about the OAuth spec. I'm now very interested in more about how that's implemented. Dan Moore (@mooreds) (28:31) Yeah, please. I can send you some articles if you want because I think there's definitely some good content out there that's talking about this in the general sense and also in the context of just agents. Yeah. Erika (28:31) Yeah. Yeah, that'd be great. We can share them out in the show notes, too. Dan Moore (@mooreds) (28:47) Awesome. Erika (28:48) Well, this has been a fascinating conversation and we always end with a fun segment and today's fun segment is inspired by this topic of agents and you mentioned subagents at the beginning and for anyone who hasn't worked with a subagent, a lot of them are defined with this like specification file which is basically text that tells them you are, I mean, any agent, you kind of tell it, this is what you are, this is what you're good at, and sort of like super boosting their powers. So I thought it would be fun to think about if we were agents, what spec files we would write for ourselves to super boost our abilities. So I can go first. I would... I would do something around communication and writing because I always think that's a really hard piece and I think... specifically like asking myself follow-on questions and like understanding what other people would ask or like what other people might think about. So, you know, my spec file might be something along the lines of like generating different perspectives and having like helpful sort of like discussions, you know, sort of like a set of rubber ducks that all have different identities. can like ask me different questions to make sure I'm thinking through something fully. So that would be that would be my super power spec file. Brittany, do you want to go next? Brittany Ellich (30:29) This is like an incredibly introspective question, masquerading as something that is not. love this. ⁓ I think that if I were to have like a spec file or at least like a desired trait basically that I would write, it would be that I'm really good at like following up with people and like keeping in touch with people. I feel like that's a skill that I'm not super good at and would like to get better at. So I'd be an expert in... Erika (30:31) Good. you Brittany Ellich (30:56) friendship or something like that. Really good at, you know, keeping up with the folks that I already know and like building those stronger ties. Dan, do you want to go next? Dan Moore (@mooreds) (31:06) Interesting, yeah, wow. I feel like we could get an entire podcast about this question. And one thing that, this is kind of off topic, but like, it almost sounds like a spec file or a skills file is like a mantra for the agent in something that like repeats to itself and like becomes better at. So am I, ooh, does that mean the reverse is true for us? Anyway, mine would be my entire life, been my entire adult life beliefs has been driven by my my desire and lack of fear and willingness to ask good questions and importantly I think listen to the answers and as I've gotten older I think I have a little more nuance about when the right time to ask the questions is, so I'd kind of add that in too, but I also would say that I think each of these spec files comes with a license, and mine is gonna be GPL licensed so that it affects other people with the same skill to like ask good questions and listen to the answers. Erika (32:07) Well, thank you both for going with me on that journey of introspection. I know it was a little meta, it feels fun to think about. Well, thank you again, Deon, for joining us. If people want to find you, where can they look you up? Dan Moore (@mooreds) (32:24) Sure, yeah, so I'm on LinkedIn, just moreDS, M-O-O-R-E-D-S, or Dan Moore Boulder will pop me up, or Blue Sky is the other place that I hang out and talk a lot, and that's moreDS.com is my profile name, and then if you wanna learn more about Fusion Auth, or I also write on the blog there a lot, it's fusionauth.io, and would love to connect with anybody on social. know people always say this, but I'm happy to hear from anybody who has discovered me or my thoughts through the Overcommitted Podcast. I'll be happy to connect. Erika (32:57) Well, thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next time, goodbye. --- ## Episode 35: Decoding Developer Trends: Inside the Life of a Developer-Focused Analyst with Kate Holterhoff - URL: https://overcommitted.dev/decoding-developer-trends-inside-the-life-of-a-developer-focused-analyst-with-kate-holterhoff - Published: 2025-11-25 - Topics: AI & Developer Tools, Developer Experience/DevRel, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/111198977/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-10-14%2F412501741-44100-2-d46704c5bc6b2.mp3 ### Show notes Summary Join us for a conversation with Kate Holterhoff, an industry analyst at Redmonk who tracks developer trends from Reddit threads to conference halls. Kate shares her unique journey from earning a PhD in Victorian literature to becoming a self-taught developer and analyst, and discusses Redmonk's "new kingmakers" philosophy that recognizes developers as key decision-makers in tech adoption. We explore current industry trends including JavaScript bundlers, the real story behind AI and developer jobs, why communication skills matter as much as technical expertise, and her experiments with vibe coding across different IDEs. Takeaways * Developer-led adoption is the future - Redmonk's "new kingmakers" philosophy recognizes that developers, not executives, are increasingly making purchasing decisions for development tools and platforms. * AI tools are becoming standard practice - Most developers now use AI code assistants and agentic IDEs, forcing organizations to adapt with proper guardrails and company plans rather than fighting adoption. * AI isn't taking jobs (yet) - Current tech layoffs are more attributable to post-ZIRP (zero-interest-rate phenomenon) economics and offshoring than AI displacement, though AI has become a convenient scapegoat. * JavaScript is getting massive - The recent explosion of bundlers like TurboPack, Vite, RS Pack, and Rolldown signals that JavaScript packages have grown significantly since Webpack's creation 10 years ago. * Industry analysts live in developer watering holes - Understanding real developer sentiment means spending time where developers actually talk: Reddit, Hacker News, Bluesky, conferences, and podcasts. * Communication skills are as critical as technical skills - Engineers who can bridge technical expertise with business communication and customer interaction have significant advantages in their careers. * Alternative paths into tech are valuable - Kate's journey from Victorian literature PhD to developer analyst shows how diverse backgrounds bring unique perspectives to understanding technology and its cultural impact. * Teaching can make coding accessible - Using engaging content like comic books, steampunk, and Victorian literature can make technical concepts more approachable and help students see connections across disciplines. * Vibe coding is promising but unpredictable - AI-powered development tools show incredible potential but remain inconsistent, with success depending on unclear factors like IDE choice, prompting technique, and model capabilities. * We need more casual learning communities - The tech industry would benefit from more informal, non-commercial spaces for developers to share experiences, especially around emerging technologies like vibe coding. Links * The Monkcast: https://redmonk.com/blog/2023/12/07/the-monkcast/ [https://redmonk.com/blog/2023/12/07/the-monkcast/] * Kate on LinkedIn: https://www.linkedin.com/in/kateholterhoff/ [https://www.linkedin.com/in/kateholterhoff/] * Kate on Bluesky: https://bsky.app/profile/kateholterhoff.com [https://bsky.app/profile/kateholterhoff.com] * Dwarkesh podcast with Andrej Karpathy: https://www.dwarkesh.com/p/andrej-karpathy [https://www.dwarkesh.com/p/andrej-karpathy] Hosts: * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] ### Transcript Kate (00:00) now I would say that it's kind of taken for granted that most developers use some sort of AI code assistant and are using an agentic IDE. so, know, organizations need to be prepared for that. And all of that really vindicates, one of Redmonk's core tenants, which is our philosophy around the new kingmakers. which is that developers are the ones who are going to be making purchasing decisions. And so if you look at how adoption of these tools has sort of evolved, you might see in several organizations that maybe developers didn't really, like their organization weren't, you know, paying for a co-pilot plan or they weren't paying for one of these cursors, whatever, one surf. But as time has gone on, they have finally gotten, you know, their developers were probably using them, but they didn't have a company plan. But now, of course, lot of companies have said, OK, wait a second. We need to actually be in control of this and make sure that our information isn't being sent to some cloud that we don't have access to or I think we're in the process of putting up a lot of guardrails as an industry. But also, developers are only going to use tools that work well. Bethany (01:03) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host Bethany and I'm joined by... Brittany Ellich (01:10) I'm Brittany Ellich. Bethany (01:11) We 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've learned. 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. Technology is constantly changing at a rapid pace, which is one of the most exciting but intimidating aspects for professionals trying to focus on what trends tools and practices are most important. Today's guest is someone whose job is to help industry professionals do just that. Kate Holterhoff is an analyst at Redmonk, a developer focused analyst firm, and we are thrilled to have her here to share about her work and how we can learn from her process to keep up. Welcome, Kate. Kate (01:58) Hi, it's great to be here. Bethany (01:59) So let's start about just kind of discussing what does an analyst for a developer-focused analyst firm even do? Walk us through how you maybe approach your research for an analyst and what your day-to-day looks like. Kate (02:12) Yes, yeah, I get asked this question a lot, as you can imagine, because analyst is kind of a squishy term and there's lots of different types of analysts. the sort of longer technical term is that I'm an industry analyst. And so a lot of folks have heard of companies like Gartner or IDC, Forrester, those are some of the bigger ones. I work at a company called Redmonk and yes, we are developer focused. We're also smaller and so there's only four analysts. And we have sort of made our name for ourselves in terms of speaking for the practitioners. And what that means is that we follow trends in the industry. We work in developer watering holes, such as Reddit, Hacker News, Blue Sky, places where the developers are speaking their mind. And we try to give voice to that. So we speak a lot to the open source community, like We are interested in what actual adoption trends look like and not just what the vendors would like them to look like. And obviously, we spend a lot of time at conferences. I'm a big podcast buff. So I'm a big fan of learning what developers think by way of hearing it. And so yeah, that's sort of the sort of larger philosophy is that Developer led adoption is important and we should pay attention to it and I don't know so yeah, would you want me to talk a little bit about my my day-to-day as as part of that? Bethany (03:31) That would be awesome. Also, really curious what this data ends up feeding into and what these insights go towards as well. Kate (03:39) Yes, yes, great question. Okay, well, I am a former academic. So to be honest, I just wanna learn forever. And so the research part to me is super fun. But that obviously isn't it. So what we do do is we've got a blog, we run our own podcast, which is called the MonkCast, and we do consulting. So companies, if they are a client of ours, will speak to us about any subject that's top of mind. So the idea is that a lot of companies want to talk to us. They want to persuade us of the relevance and the importance of their own products. But if they are our clients, we will also talk back to them. We'll give them our feedback. And so the type of feedback that they often want will be showing us pitch decks, and we'll give them advice about maybe how to improve that. We'll talk a lot about messaging trends. mean, sometimes companies are just interested in what we're hearing around certain technologies. And all of us sort of have our interests laid out. So, you know, you can kind of pick your analyst that you think would be the most interesting on a particular subject matter. But also we'll do like website reviews. So I mean, obviously that's a really important marketing channel and it's extremely difficult, my goodness. You know, it has to appeal to not only the business side, but also to developers who go there looking for the documentation, right? So yeah, so we will review any sort of marketing materials, but also yeah, we'll just have conversations. And since the pandemic, a big part of what we do is actually creating sort of external facing media. So we'll do sponsored podcasts and sponsored videos. Also, our clients will have us come out to their conferences to speak. So we'll participate in webinars, may be virtual, may be live, fireside chats, things like that. And then in terms of what my work looks like, mean, top of mind for me these days is travel. We go to a lot of conferences, which is fun, but is also a bit of a challenge. I have small children, so finding the... The wherewithal to leave them for days on end can be a challenge. However, I love to travel and I love to talk to people and I think it's a lot of fun. So I do love it. So it's really a balancing act. And then also just like writing blog posts is a big part of what I do too. I always have something that I'm working on. And so I... I guess I, you when I wake up in the morning, I very much look forward to trying to dig into those subjects and like I do a lot of interviews for them. And it's so cool that, you know, folks want to talk to me about this too. Like I have great access as an analyst to some of the leaders in the industry who want to tell me what they think about, you know, something that is happening in the news or some new technology that is coming around or maybe that there's like three folks who are working in a particular space. And developers are sort of unsure why there's suddenly this influx of options and what is that signal. So for instance, I'll just give you one concrete example. What I'm working on now, which could possibly, I hope, be published by the time that this episode comes out, is on bundlers, so JavaScript bundlers. And so the reason that I'm interested in that is because we've got TurboPack from Vercell, and then we've got Vite. Plus, so folks who are interested in the roll down community, that's a big part of it. But also RS pack. So there's all these sort of new bundlers. And I was like, why are folks investing all this time into JavaScript bundlers? Where is this coming from? And the TLDR, as a little teaser, is that I think it has a lot to do with just the size of JavaScript these days, Webpack. was created 10 years ago and the packages just weren't quite so large. So we're just shipping a lot more JavaScript these days and so we needed new bundler technology to keep up with it. anyways, a little tangential, but that's what I love about my job. I like asking those questions. I'm a deeply curious person. Bethany (07:27) That is so cool. I mean, I just love the idea of the meta of software engineering and looking at that and why these trends pop up. What's the underlying root causes? And it certainly sounds like your job doesn't get boring after you're doing all sorts of things. So that is so cool. ⁓ Really curious, how did you get into this field? It seems like a very unique spot for having both technical knowledge, but then also analyst skills. Kate (07:45) Yes. Bethany (07:54) what drove you to getting into this position. Kate (07:57) Yeah, I mean if you had spoken to me, you know five years ago, I wouldn't have even known that this was like an option. It's such a unicorn job. I feel very fortunate to be doing what i'm doing. But yeah, I wanted to be a college professor. I had a background in art, painted some murals in Cincinnati, which is my hometown for many years. And then I pivoted to try to be an English professor. I had dual majored in school and so I You know that that was my dream for about a decade and I went hard, you know, I I did the whole thing I got the PhD I Adjuncted I did a postdoc. That's why I'm in Atlanta is I did a postdoc at Georgia Tech and Just at the end of the day there there aren't really any tenure line jobs So I could have adjuncted forever. I could go out and probably adjunct right now if I wanted to but it's just not a very good Career, there's you know, not no benefits. I'll say that much So, you know, if folks want to dig into the itinerant labor problem in higher education, I'd be happy to do that. But in any event, I taught myself, a program, and became a front-end engineer in 2018, and did that for a few years. And one of my colleagues from Georgia Tech, who I did the postdoc with, she had gotten the job at Redmonk, like, immediately after deciding that being a college professor wasn't for her. And she reached out to me when they decided to hire a fifth analyst. so, know, Kelly and Fitzpatrick, shout out. she got me on board. I was about eight months pregnant when I interviewed for the job with my second. so that was fun. yeah, I... got the job, it was great, it was a very smooth transition, and I was able to leverage a lot of the stuff that I did in academia with a lot of the things that I learned as a front-end engineer and the interest that I had. For instance, as a front-end engineer, I wrote for CSS tricks, and so that's the sort of stuff that I was, yeah, yeah. So I was always kind of interested in combining my interests there and using some of the skills that I had gained. in academia as part of what I was, you know, planning to do in tech. So yeah, I mean, and to prepare for that at Georgia Tech, I taught digital humanities classes, and I also taught in the tech comm section of design courses there. So I was already sort of like focusing my pedagogy on transitioning into a tech career. And, you frankly, my PhD is from Carnegie Mellon, so I always have felt very comfortable talking about communication to engineers who, especially younger ones, are often not very interested in hearing about that. But I like a challenge. So that was fun for me. So anyways, all that is to say, it was a very good fit for me. so I'd say, like most jobs I've had, I knew someone who helped me to sort of get my foot in the door. and I am extremely grateful. I love what I do. It's a really, it's a fun role and I think it's really important too. Brittany Ellich (10:49) This is awesome. I think you fit in well with us. We are all lifetime learners and very passionate about learning. And if I could go to school forever, I would. I am actually just now applying to the Georgia Tech Online Masters because I've had this in mind for a while and you have been there. That's cool. It's nice to hear. Thank you. Yeah, yeah, for sure. Kate (10:59) yeah. good luck to you. Yeah, I understand they have a great program for that. Brittany Ellich (11:12) Do you have a particular specialization or anything in particular that you look at within Redmonk? You talked about JavaScript bundlers. Is there an area of development that you're focused on? Kate (11:24) Yes, I mean, absolutely. I focused on the top of the stack. anything to do, we called it interactive when I was an engineer. So that would include not only UX, but also the design side and front end engineers. I've always been very interested in that intersection between the design and the engineers, because that was the job that I had, was that the designers. would hand off a PSD file to me or an Adobe XD file. We're talking like, yeah, 2019 era. And I would code it out. And of course now AI can do a lot of that for you. And there's a lot of folks who are already sort of branching that gap. And so I will obviously talk about DevOps. I will talk infra. I can do the thing. Backend stuff is great. Databases, all of it. But my happy place. is absolutely talking about front end stuff, JavaScript, frameworks, all of that. so yeah, a lot of the research that I publish tends to be on that. And frankly, anytime someone markets a product as front end. So a recent example of that is front end observability. I was very interested in that. said, well, who's using this observability product? Like front end engineers don't do observability? What is this? I'm confused. Turns out it had a lot to do with real user monitoring. So anyways, I published a bit on that. I did a few podcasts on the subject because I did find it very interesting. historically, so the problem with being an analyst who focuses on the top of the stack is that vendors didn't use to market to front-end engineers. They weren't thought to have any purchasing power. You would only market to folks in the back end and who did IT and infra. because they're spending the big bucks with the hyperscalers. And fine, you know, I mean, that's not true. But there's something to be said for the front end and paying attention to their own needs. Because I think the problem of just talking about developer experience is that there's a lot of kinds of developers and there's a lot of sort of specialties within there. And frankly, it's a moving target even within a subset of it, right? I'm always wary when folks just kind of paint with a broad brush the idea of DevEx. Like we're interested in product-led growth or we're interested in just, you know, making sure that developers can kick the tires, right? I think you want to also think about like, well, what kind of developers are we including in this larger remit? You know, is it also going to be appropriate for, you know, as we widen the aperture of who is considered a developer through vibe coding or, you know, whatever sort of cringe word folks are using? I'm all in with vibe coding by the way, know, so that's I'll take it I own it you know that if that is something that you're You're thinking about is including designers and UX folks and accessibility and all these these sort of folks who are working in that basically any web dev Then you know, how are you? meeting them where they are and and making sure that that their needs are met and So I think that that's, I try to give voice to that particular segment of the developer community. And because I was in the trenches, because I've seen things, I've seen terrible things, you know, I spent a lot of time doing it. You know, I could speak with some authority and also I just get, you I'm very interested in it. And yeah, so I'll pause there. Brittany Ellich (14:35) That's awesome. Yes, we, I think we have very different backgrounds within our group of hosts here, but definitely some more front end focus. I'm personally more front end focused, so I love seeing more efforts towards marketing to front end developers because we do have a lot to say and I feel like there's a lot of... Kate (14:54) Absolutely. Brittany Ellich (14:55) There's movements now towards more like product minded engineers, which I feel like is a term that has come out recently. And I feel like that tends to be often tends to be more like front end focus engineers since they're often closer to like the product and the customer. speaking of AI though, I'm curious because this is a thing that is happening a lot now. What are your thoughts on sort of the AI space and how that is trending over time, specifically for developers. Kate (15:22) Well, let me try to narrow that question a little bit because, I mean, obviously, I think about AI broadly all the time. ⁓ so in terms of my research, I tend to do a lot of studying of the agentic IDEs. They used to be called AI code assistants, but now they're all agentic, right? Brittany Ellich (15:29) Mm-hmm. Yeah. Kate (15:41) which is great. And so for instance, I had early access to IBM's Bob. Kiro is another fun one, that's AWS's Spectre of Development IDE. And so I've been thinking a lot about what the affordances are for these tools and what they signify about the space and also just putting them through their paces. I don't have a benchmark, I think that you can look to folks like Simon Willison or... Even some of the vendors themselves for like, you know, trying to see how well they do for certain tasks. That's fine. But again, it's just, it's always moving. It's very fluid. So I don't know, you know, anything that you publish today is going to be outdated, you know, in a week. But I think it's a lot of fun. And I also think that it is changing the way that we work. And it also has a lot of implications. for organizations. of course, I enjoy doing my little hobby projects, my personal websites, little RSS feeders, silly stuff like that. That's fine. And we know that that has pros and cons, and some work better than others. But when we think about developers at enterprises actually using these AI code assistants, there's a lot of security implications. And there's also a lot of... sort of resistance from certain segments in the community. so it's been fun to like watch that evolve over time. Because now I would say that it's kind of taken for granted that most developers use some sort of AI code assistant and are using an agentic IDE. so, know, organizations need to be prepared for that. And all of that really vindicates, you know, one of Redmonk's core tenants, which is our philosophy around the new kingmakers. which is that developers are the ones who are going to be making purchasing decisions. And so if you look at how adoption of these tools has sort of evolved, you might see in several organizations that maybe developers didn't really, like their organization weren't, you know, paying for a co-pilot plan or they weren't paying for one of these cursors, whatever, one surf. But as time has gone on, they have finally gotten, you know, their developers were probably using them, but they didn't have a company plan. But now, of course, lot of companies have said, OK, wait a second. We need to actually be in control of this and make sure that our information isn't being sent to some cloud that we don't have access to or whatever. So I think we're in the process of putting up a lot of guardrails as an industry. But also, developers are only going to use tools that work well. So I think that there's also this push-pull of, well, that's fine. But we might be copying and pasting code snippets from our preferred. know, code assistance, Claude code, you whatever you use, rather than using something that maybe the top down C-suite folks would rather us use. And I think we're still kind of figuring that out. Like there's still a lot of tension. So that's one thing that I focus on with AI. I'd say that another one is about jobs, right? We're hearing that AI is displacing a lot of workers. And that's an interesting one for me, because I think that we haven't seen, we've seen layoffs. But my personal feeling is that it's more because we're in a post-zero-interest-phenomena era, or ZERP, you might have heard it called, rather than AI taking our jobs. It's a scapegoat at best. And I think that that's still, we're looking in the future for that to become the case. What I have seen as part of this ZERP thing is offshoring. a lot of companies are hiring talent from overseas. And so again, we're calling this an AI issue, but really it's not. Developers are all using it globally, but I think the fact that it's become this scapegoat in the IT industry for hiring and for the fact that so many junior developers are not finding jobs as quickly as they have in years past. is something that is deeply tied to that. Brittany Ellich (19:20) Yeah, that makes a lot of sense. Having been on quite a few different teams now, I know that there is never a shortage of work to be done. Even if AI can do the work, there's always something that developers can be doing. So the likelihood of AI taking our jobs, feel like, in my opinion, is probably pretty low. But who knows? Who knows what the future holds? maybe. Are there any common questions you get asked about? Kate (19:41) Yeah. Brittany Ellich (19:45) AI right now from your perspective as an analyst or. Kate (19:48) Yeah, well, so folks are always interested in the ROI. And that's something that I don't think any numbers are going to be effective in quantifying. I mean, we get asked that all the time. But we get asked for executive numbers frequently, where they'll say, how do you know what the adoption is of this particular thing? And it's like, well, you've got GitHub stars, and you've got Stack Overflow. And it's like, these are just like, Prox, you know, proximate metrics. These are not actual You know things that are going to to tell you anything You know cut and dry they you know, they're all they all can be massaged to say to tell whatever story you think is most appropriate so So yes, I I have a bit of an allergy to numbers like that but yes, we do get asked that frequently and Gosh, mean, you we get asked about features pretty often. I'd say, you know, one was PRs. mean, you everyone's familiar with the bottlenecks that code review pose. And so I was very interested in following that. I did write up a piece on how AI is trying to revolutionize that particular part of the SDLC. And... But again, it's moving so fast that I'm sure it's completely outdated at this point. It's, you know, it's... Right? Yeah. I mean, it's all just very... Yeah, everything is fluid. Everything is moving. Again, with my podcast, you know, usage, whatever, I listened to an interview with Andrei Karpathy on Dworkish where he was, you know, discussing the fact that the models just aren't good enough yet to actually do the sort of agentic workloads that folks... want, or that would really move the needle. And not even in terms of like AGI, but like in terms of like, yeah, replacing jobs or doing these sort of PRs in a way that's like eliminates a lot of toil and a lot of like cognitive overhead. So, but yeah, so I just don't think that we're quite there yet with the technology to actually do much more than what we already know AI is very good at, which is you know doing summary work and doing text generation and all that stuff which I love I am all for it. I am such, a geek about like letting you know a transcript You know summarizing a large block of text into something quick and readable or like, you know using it to to yeah Well, so on riverside right the the transcript functionality fantastic Write me a summary anytime. I love it. That is awesome. I'm all for it. So, you know, so I'm a big, I'm a big believer. I'm, you know, but, but in terms of like taking jobs and all the sort of heavy, heavy stuff that we can align it with, am, I'm less, you know, less bullish. Brittany Ellich (22:20) Yeah, yeah, that makes a lot of sense. I am also a big fan of the Riverside Tools. I feel like this podcast would probably not exist if it wasn't so easy now to make a podcast. Because we're not editors. Yeah. That's very cool. Yeah, this is very fascinating to hear about because, yes, like I said, we're more like we are still in the trenches. feel like one of the things that I've found is we... Kate (22:31) Big same, big same. yeah. Brittany Ellich (22:44) I think in the last year or so, quite a few of us have been looking, the hosts of this podcast have been looking at doing more public speaking and going to conferences and talking about what we're doing as developers. And I agree that things seem to be moving so fast. I'm nervous to ever submit anything related to AI because you have to submit months in advance. you're right, everything changes so quickly that could be... outdated like three times over by the time the conference even shows up, which is very interesting. But of course, everybody wants a lot of AI related content right now. Kate (23:18) yeah, yes, very hot. I suspect even with it being three months out of date, it'll still be relevant, especially if it's just, you you just update the model, it'll be fine. Brittany Ellich (23:28) That's true. That's true. Yeah. So I'm curious more about your academic background and, you know, is that something that you're interested in like pursuing again in the future? Like, are you interested in going further into academics again or as... Kate (23:44) Yeah. Well, I don't know that I'll ever go back to teaching. Just it is a lot of time. I, yeah, again, I just really didn't pay enough to make it worthwhile. The numbers are not there. I try not to get too too much on a political soapbox here about that whole situation. But in terms of research, yeah, I every once in a while I'll submit an essay. And actually, this year, I published my dissertation as a book. So that was a big weight off my shoulders or albatross from around my neck. And I actually am gonna be attending like the big industry conference for my field next week in order to celebrate that book launch. So I don't know that I'll write another academic book, but I can see myself writing articles. And then this is like one of the... So I had created this digital archive about a 19th century author named H. Reiter Haggard, it was hosted on Heroku's free tier. And then when they sunset that, it went offline, so it was no longer in existence. And somehow the repo got lost. And very frustrating, I know. So I have been using vibe coding tools to like recode it out using like specs and things. And also it's in the way back machine. So I've been having fun with that. you know, is that an academic thing? I don't know, kind of. Like I would love to see that relaunched, but historically I've had a real hard time getting vibe coding tools to be able to do Ruby on Rails. Like they just cannot get the versions right. It has been, I don't know, it's like an exercise in pain. I've got the database, so I was like, well, I gotta have it in Ruby. mean, there's no other way. Like, it's got to be a Rails app. So I actually did just get one working recently, so I am pretty stoked about it. Yeah, I know. But it can't link the images still, so I don't know, you know? And I'm like, why am I doing this? But so does that count? I don't know. That's kind of like academic stuff. I mean, it's like I keep in touch with those folks. I've just I've shifted careers. so many times at this point. got all these friends and different little cubby holes that I try to keep in touch with, but it's hard. I think my next writing thing is, of course, I write my blog at Redmonk. That's going on. But I want to write fiction, and so I might... That'll be my next, I think, big foray into pseudo-academic work, I think. So we'll see how that goes. Bethany (26:00) that's awesome. Very curious on what ideas you have, or even what books you're reading currently. Kate (26:07) Yeah, well, it's historical fiction. So I've written 120,000 words of a novel. So we'll see. And it's... Yes. Yes. So I'm hoping to get it out to a literary editor by the end of this year. And I decided, though, I needed to rewrite the first chapter. So I've been reading a bunch of stuff about Leonardo da Vinci. And so right now I'm reading Pascal's Angel. Bethany (26:14) What? Kate (26:28) I I'm pronouncing that right. But yes, I read, I've been reading a lot of things about like the Renaissance and either alternate histories that are fun sci-fi that are kind of more aligned with what my actual book is about, but also things to try to get the historical accuracy correct. I was a Victorianist, so me writing about the Italian Renaissance is like, what am I doing? I don't know. I did the thing. It was important. So I don't know. I love pain. This is me. I can't turn it off. I don't know. But yes. Pascal's Angel is the book of the day. I've got, I think, 200 pages left. Bethany (27:01) I you getting a PhD is all we need to know about you loving pain. So ⁓ I dropped out of my first year at PhD. was like, nah, that's good. I mean, computer science, didn't choose a focus, but yeah, no, was very much like, I like making money. Kate (27:06) much pain. My god, Bethany, what was your PhD gonna be in? What were you studying? yeah. Yeah. No, you don't make money and that's not what we do. That's different. I shouldn't say that. do. Yeah. One of the most interesting conversations I did through the Moncast was with a gentleman named Scott Stevenson who did his PhD work on particle physics waves, you know? But then he translated that to AI on speech to text. And so like he's doing like AI stuff. So I was like... who even knows what you can do with your PhD work? This is, I was like, my god, you know, the dude was working on like, the, you know, particle colliders. And then next thing you know, he's, he's, you know, revolutionizing, you know, how, how we're going to be using AI to do our transcriptions on Riverside. I don't know what actually, I don't know what model Riverside uses, but, but there's ways I don't, I don't know that I never found a way. But you know, maybe, maybe you could have, I don't know. But yes, it's a I have lots of thoughts on all of that. Bethany (28:13) yeah, definitely. mean, it feels like with PhD there's a lot of skills that can translate. mean, you know, being able to research and have statistical, like knowledge of statistics I think is alone a huge thing for just being effective in any... any area. So that's really interesting how people pivot their their specific niche that they're studying to another area because it is so so niche what you end up getting into. That's really cool. Kate (28:40) Yeah. Yeah. Yeah. Bethany (28:42) So one thing I am curious about, you mentioned earlier about how Redmonk is trying to enforce that developers do have a lot of purchasing power, especially with front end developers and moving towards that area. But I was curious if you have any tips for how developers can better educate business leaders within their own companies and put more emphasis on their preferences and opinions for those purchasing decisions. Kate (29:09) Yeah, I mean, that's a tough one. I mean, I would just say if you can work at a company where you're empowered to speak truth to power, then you should just tell business leaders what you think and what you know to be true. I think the most successful companies are the ones who do keep engineering in the fold when it comes to making important business decisions. And yeah, it's, I don't know, I would say... you know, when that alignment happens, it can be transformative. You know, it allows you to reduce project turnaround. And, you know, it allows you to execute business strategies in a better way, right? So, you know, when we think about the long T in terms of like skill sets, you know, being able to have that, you know, the longer horizontal, right, you know, being able to do a lot of things well. I think companies that can kind of support that sort of learning and being able to speak to folks with a number of different abilities well, you know, will serve them. And so, again, I'm always advocating for engineers to work on their communication skills because many of them think that it's not as important as having great technical know-how. And of course, it is important. So that's like the long part of the T, right? But... being able to go to your manager or folks that are making these business decisions and try to do the sort of cross-skilling and communicating across business functions, They're going to be able to leverage both of those, right? Both the technical expertise and being able to speak to customers. And so when I've spoken with folks who really have studied this and like what makes startups and enterprise companies successful, you know, they talk about walking that line and a lot of it has to do with finding out what users need and and so if you You might have the best product in the world, but if you can't fulfill a need that users have You're still not going to succeed At the end of the day, I you know, that's great. If you've got all the features It's great that if yours is quicker than the competition all that's awesome but you need to be able to speak to the business needs as well. So I'd say, you know, just making sure that you're trying to foster a community within your own organization where that sort of communication is happening is of the utmost importance, but I get that it's hard. You know, product and engineering teams have always butted heads, right? This is like a known... This is, you know, this is a stereotype. There's probably an ex-KCD comic about this. I don't know. But, you know, having... But they're both extremely important. And they both need to align. you know, possibly be under the same heading. I mean, that's, when we think about DevRel and what, you know... the folks that are within an organization who are supposed to speak to those developer users, having them be underneath the engineering team is a lot of preferred by the dev role folks themselves. making sure that your metrics and your KPIs and all these sort of ways that you're measuring impact, that those also speak to business needs, absolutely essential. Like it's great if you can vibe at a conference. I love vibing too. That's my happy place. But I get it. You can't just do that. You have to actually do a thing with that sort of connection that you're making. That doesn't make the connection any less important. But yeah, I think it all kind of comes to the same sort of question of like, do you, within the software industry, how are we merging? this great technical ability that is whatever company you work at, right? Or AI, right? If we're thinking at a high level, right? How are we going to actually make this work for everybody and be responsible with it and to make sure that it's going to be a force for good, right? All of these are questions that I think are extremely important for us to be having across a wide swath. And yeah, a lot of times engineers are sort of like the last line of like knowing what is a responsible use of that sort of power that we have. yeah, so having them be able to communicate with the business folks is like a, you know, it's absolutely essential. It might be uncomfortable, but you know, do it and work for companies that foster that. Yeah. Bethany (33:06) Awesome. Well, that definitely makes a lot of sense. honestly, communication really is such a such a superpower in the engineering space. And advocating for those skills is really important. So really, really love hearing your perspective there. All right, I think we're coming up at time, but we always do a fun segment. And this week, I mean, you had so Much as we've talked about in this podcast in your background, that is really fun that I guess we'll talk a little more about, but really curious. What is Victorians in cyberspace? Kate (33:45) yes. Okay, so you've been creeping on my my personal website, which is vibe-coded by the way. Yeah, well I taught a lot of classes over the years. So that was a course that I taught in 2017 at Georgia Tech. And it was, you know, it kind of pulls from the normal like discourse from a lot of Victorians about like how the humanities are intersecting with computers, right? And so we can, you know, there's a lot of like monographs about how like Dickens, you know, was thinking ahead to networking. And, you know, Babbage, Ada Lovelace, you know, obviously, the Victorians have a lot of great, great stories to pull from in the history of computing, right? So so that's an easy win. But in terms of like what we did in that class, like we we did a lot of multimodal projects. with and it was a freshman course. So it was was the sort of like introductory communication course and we read comic books like Hatter which is a version of Alice in Wonderland. We read the League of Extraordinary Gentlemen which is a lot of fun maybe you've seen the movie but it's about adventure fiction and so like my own dissertation work touched on adventure fiction quite a bit. I'm very interested in the rise of like the Indiana Jones sort of character, which H. Ryder Haggard sort of pioneered with his Alan Quartermaine. And yeah, and so we also read A String of Pearls, which was the Sweeney Todd basis. And what's great about that one is it was serialized over a long period of time. and it's been digitized by one of my colleagues. And of course it's just like a fun sort of campy, murdery, horror, whatever melodramatic story. And yeah, so we just read a lot of fun Victorian and neo-Victorian books and talked about steampunk, talked about... Why is it that we're still making versions of Alice in Wonderland? What's so cool about that story and why can't we get over it? And making projects that built on that and allowed us to ask questions about how the Victorians today are extremely prescient and guess relevant in ways that maybe they didn't anticipate and how we're still kind of living in the Victorian era. This is... We're in the fourth industrial revolution according to some thought leaders. Let's talk about why is it a revolution? What does all that mean? What are we doing with our cogs and our clockwork implements? So yeah, anyways, it was a fun one though. It was a good class. yeah, there's parts of me that miss teaching. I'll say that much. That was a good time. Bethany (36:24) I mean, I want to take that class now. ⁓ Awesome. And next, I understand you did start a Python learning group to make coding or learning how to code more fun. Are there any groups that you wish existed right now to make things more fun? Kate (36:26) Thank you. So here's the thing, there are probably groups for anything that I would be interested in and I just feel like I don't have the bandwidth to join them. So I would say if somehow I was able to replicate myself or have infinite time or whatever, Groundhog Day, do everything that I wanna do, I would probably, well, God, yeah, mean, where do we even begin? But maybe a vibe coding group would be fun. Because as I do it, I have all these questions and I'm sure I'm doing things wrong and I'm sure I'm not like, pushing the affordances of the medium. And so, you know, my approach to that is I keep trying to like build the same app with different IDEs in different ways and different prompts. And like sometimes I use a spec, sometimes I say, can you clone this? you do that? You know, and sometimes it works and I don't know if it's because of the IDE I'm using or if it's because I prompted it better or if it's because the model's better. And I have no idea. And a lot of it's a black box. And frankly, The fact that I am permitted to kick the tires and I have no token problems is I'm spoiled rotten. Because I'll tell you what, when I do pay for them, which I do, I use same.new. That's what I used for my personal website to begin with. I've since used many other things. I used up those tokens in the first prompt. were gone. bolt.new, all of these. Or bolt. Yeah, wait, bolt. Yeah. V0, all of these, lovable. I am a token hoarder. Like, I just, I use them up and then I'm done. I don't know. It's tough. So, I don't know if I would probably be, you know, I would have too much fun in a vibe coding group and, you know, trying to make my, I know, I think the... the range of like the simple apps like like a medicine reminder or like a Tetris make me Tetris right like it knows how to do that right away because there's a million of them right but it's like the thing that I've always tried to do with Ruby on Rails is like too hard so I'm like I'm sure someone out there has like found the sweet spot of like here's right in the middle of like what is an appropriate sized vibe coded app I don't know I've yet to figure that out so yes having a know, the way I describe this, it sounds more like a support group than a learning group, I'm realizing. And maybe that's actually what I need. So okay, yes, I'll, yeah, vibe coding group. That's what I want. Bethany (38:50) I love that. We definitely need vibe coding support groups today. ⁓ I'm envisioning almost like going to a coffee shop with a bunch of people and aiming to vibe code a thing at the end of it and then just sharing tips and tricks the entire time. That would be so fun. I would go and I'm an introvert, so. Kate (38:54) Yeah. Yeah. Yes. I love it. Yeah, that's a great idea. Bethany (39:09) Awesome. Brittany, are there any groups you wish existed? Brittany Ellich (39:13) I feel like one that I would really appreciate is I feel like I have connected with a lot of women in tech over especially more and more now that I'm going to all of these different conferences. And I wish that there was a group for that that wasn't so, I don't know, like commercial. I feel like a lot of the women who code type groups are like, oh, and join our thing and like come to our conference and stuff like that. felt, and it's hard to, I don't know, I don't know how to put a finger on it. I read an article recently about like, why women in tech isn't working or something like that. And I wish that there was a group that actually, I don't know, was better. I'll leave it at that. I have thoughts. I'll write a blog post on it. Yes, maybe, and maybe there's one that exists out there that already is better, so yeah. Kate (39:45) Hmm. All right. Maybe someone will listen to this and give you some advice. Bethany (40:00) That is too real, but awesome. Well, that is our time this week. Thank you so much for joining us, Kate. Really cool conversations. Where can people find you? Kate (40:10) Yes, all the normal channels, I'd say. I'm on the blue skies. I dip into X every once in a while, though not there as much as I used to be. But I would say in terms of where I post a lot of our content would be LinkedIn. So definitely find me on LinkedIn. And yeah, and then if you're a podcast buff. We at Redmonk have the MonkCast where we have a lot of exciting conversations with folks who are, you know, either developers or tech leaders or folks in the dev role community or I do a lot of news ones, you know, so that's, you know, if there's something interesting in the news, I'll try to reach out to like someone who like wrote the blog post breaking it or whatever. you know, so those are fun too. But yeah, I say the MonkCast. You can definitely hear my musings there. Bethany (40:57) Awesome. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is that you like to do on the podcast app of your choice. Check us out on Blue Skies as well and share with your friends. Until next week, bye. --- ## Episode 34: The Art of Storytelling in Leadership with Matt Sinclair - URL: https://overcommitted.dev/the-art-of-storytelling-in-leadership-with-matt-sinclair - Published: 2025-11-18 - Topics: AI & Developer Tools, Technical Deep Dives, Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/111197459/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-10-14%2F412499591-44100-2-9cf3919b0336e.mp3 ### Show notes Summary In this episode, Matt Sinclair, former partner and VP of Engineering at BCG Digital Ventures, explores the critical role of storytelling in effective leadership and shares his journey from building high-performance payment systems to coaching the next generation of engineering leaders. The conversation covers Matt's passion for Elixir as "the most future-proof and AI-aligned language," diving deep into functional programming, immutable data structures, and how modern coding assistants like Claude Code are revolutionizing developer productivity. Matt emphasizes that the first job of leadership is to tell a compelling story that inspires smart people to collaborate, while the art of good management lies in getting out of the way and letting talented engineers solve problems their own way. Takeaways * Leadership starts with storytelling: The primary job of leadership is explaining why smart people should get out of bed and contribute to your mission, because without a good story, people will create their own narratives * Functional programming improves code quality: Immutable data structures and pure functions eliminate approximately 50% of common bugs and make code easier to test and reason about * Elixir offers comprehensive out-of-the-box solutions: Unlike other tech stacks requiring multiple tools (Kubernetes, Redis), Elixir provides a complete ecosystem that reduces decision fatigue and technical complexity * AI-assisted coding amplifies productivity: Using Claude Code with Elixir can make a single developer feel like they have a team of five engineers, especially when working with functional programming's predictable patterns * Management should focus on "what," not "how": Leaders should collaborate with their teams to determine objectives, then trust smart people to figure out implementation details on their own * Programming language choice impacts team quality: There's a strong correlation between functional programming adoption and high-quality software engineers, possibly due to the steeper learning curve and problem-solving mindset required * Developer joy matters for sustainability: Working with languages that feel elegant and "just click" reduces exhaustion and maintains long-term passion for coding throughout a career * Functional code is LLM-friendly: Pure functions with no side effects make it dramatically easier for AI coding assistants to reason about, refactor, and improve code automatically * Upfront design time pays dividends: Modern AI-assisted development enables more thorough design discussions and rubber duck debugging sessions that lead to better architecture before implementation begins * Combat surveillance capitalism through decentralization: The future of the web should return to RSS feeds, web rings, and federated networks of special interest communities rather than algorithm-driven data monopolies. Links * Matt's Website: https://matthewsinclair.com/ [https://matthewsinclair.com/] * Matt Sinclair on Medium: https://matthewsinclair.medium.com/ [https://matthewsinclair.medium.com/] * Intent: https://github.com/matthewsinclair/intent [https://github.com/matthewsinclair/intent] * I'm a software engineer - What next? podcast: https://whatnext.dev/ [https://whatnext.dev/] * An elegant puzzle by Will Larson: https://www.goodreads.com/author/show/6872433.Will_Larson [https://www.goodreads.com/author/show/6872433.Will_Larson] * Elixir: https://elixir-lang.org/ [https://elixir-lang.org/] * Laksa: https://laksa.io/ [https://laksa.io/] Hosts: * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Matthew Sinclair (00:00) Humans are storytelling apes, okay? And so in the absence of a good story, they'll make up their own narrative, okay? And so what you have to do, and this is increasingly true, sadly, in a post-truth world which we seem to live in, there's lots of narratives out there and people can pick, they've got a lot to choose from in terms of the stories. And like I said, if they don't have a good one, they'll make one up. So the job of leadership, the first job of leadership is to explain why smart people that they're working with should get out of bed in the morning and come and play their game, whatever their game may be, right? That's the first job, tell a good story. And then the second, and if you can't do that, the smart people have got plenty of options, they're go and do something else. And so then the second thing is peers should collaborate to work out what to do, not how, but what. And then the trick of good management is to get out of the way. I think and let smart people work out how to do the things that they've hired them to do. Brittany Ellich (00:52) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Brittany Ellich, and I am joined by... Bethany (01:02) Hey, I'm Bethany. Erika (01:04) And I'm Erica. Brittany Ellich (01:05) 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 we're sitting down with Matt Sinclair, an Aussie software engineering leader and former partner and VP of engineering at BCG Digital Ventures, who's dedicated to building the digital future. Matthew's journey started not with the Commodore 64 he craved, but with a Mercurial TI-99 that unexpectedly spurred his passion for programming, leading to a career that includes building everything from high-performance payment systems to shared mobility. platforms. We'll dive into what it takes to anticipate and build the future with BITS, the intersection of technology and business strategy and his passion for coaching the next generation of engineering leaders. Welcome, Matt. Matthew Sinclair (02:02) Good day, thank you, that was a lovely intro. Thanks, Brittany. Brittany Ellich (02:05) Absolutely. So we love to talk about tech that people are passionate about. And it sounds like you're a big advocate for Elixir, calling it the most future-proof and AI-aligned language. And I would love to hear more about that. Matthew Sinclair (02:19) You're quoting my clickbaity headline from a post I did a few weeks back. Look, what can I tell you? I've been around for a long time and I get very frustrated with religious arguments about things. And one of the best things about Elixir is that it just answers a whole bunch of questions that you don't have to re-litigate and debate with people out of the box. So I'm an old functional programmer from way, way back. did Lisp and Scheme at university. 40 years ago, maybe 35 years ago, whenever that was. When, crikey, when was 1990? Yeah, 35 years ago. So when I, and then I know I was a Java programmer like everyone and then a Ruby programmer and I kind of got a bit disenchanted with programming a little bit and the further up the leadership hierarchy you go, the less, the further away from software you get often. And, Anyway, and so I came across Elixir about 2018, 2019, I think, and it was a revelation because I was just like, oh my gosh, this thing has everything in the one box. So you don't have to make all these tech stacks decisions about Kubernetes or Redis or, know, a bunch of stuff just comes out of the box. And so I started tinkering with it and I wasn't really writing anything serious because I was still at BCGDB. But I just kept plugging away at it and kind of... after probably 10 years or so, or seven, eight years of not really writing code, I felt like I needed to get my gym fitness back from writing code after having written a lot of code in the past and then not writing much. And I just got into it and got more and more, fell more and more in love with it. has a, it's kind of like this, as software engineers, you know that thing when you write something and it kind of feels right, you know, it's got this sort of elegance to it and you know, it just kind of clicks. There's a, I don't know what that is, it's very hard to put your finger on, right? Like when you write something and you crack it up, that really feels great. And Elixir's full of that kind of stuff. It's just very joy inducing, which I know sounds crazy, right, for a software programming language, but it's... when you spend so much time on a daily basis writing something, if you have to battle with it the whole time, I think it becomes exhausting. And at least in the languages that I know, that's the one that has the least, it's the least exhausting that I've come across so far. I mean, that's the conceptual, aesthetic version of it. But from a very practical point of view, it's very fast, it's very complete. The folks in the ecosystem are great. I don't know what your preferred programming language is, but one of the things I learned over the years is there's a very strong correlation between functional programming and high quality software engineers. I don't know what that is. And I don't know whether it's just because functional programming's got a bit of a steeper learning curve maybe to get into it, particularly if you're coming from OO. I think if you come to it naturally first, it doesn't have that at all. But if you're coming, you have to sort of unlearn a bunch of stuff about OO when you go to a functional programming language. So, you know, it's... I don't know, a bunch of stuff that just makes it fun to use. I don't know. I get a bit evangelical about it, which I know is ironic considering I was suggesting that I don't get religious about things. yeah, yeah. and there's a really good, there's really good. use cases of Elixir being used at scale that people don't really know about. So Discord and WhatsApp was actually on Erlang, but it's the same underlying VM. And a few other ones, and there's a few hedge funds that use it, I know here in London, and they keep very quiet about it for two reasons. One is because it's so productive and they would prefer other hedge fund. engineers to be using less productive languages for obvious reasons, but it has a kind of ecosystem lock-in thing from an employee point of view as well because it's a niche programming language, there's no doubt about it. But the folks who do use it love it and so you want to find other elixir shops so you can make use of it as well. it's got a bit of a, maybe it's a virtuous cycle I think from one direction to think about it. I don't know, other than that, I've spent the last nine months, what is it now, August, November, so 11 months writing software on a pretty full-on basis, whereas I had the previous 10 years, I wasn't really writing software, and I think I've written more software in that time than probably in the previous 15 years of my life, just in terms of productive output. So yeah, I can't speak highly enough of it. Not everyone's using it, I think it's in the kind of 5 % range, it's the most loved and Phoenix is the most loved. So when people who use it vote, say you use Python or Ruby or whatever and you say, how much do you like it? It comes in at whatever. The Phoenix, Elixir Phoenix. folks using it seem to really love it. So, feels like it's a good thing. Brittany Ellich (06:42) That sounds... Bethany (06:44) I used Elixir for a couple advent of codes and I had so much fun with it. It really is a fun programming language. But I was curious if you have any tips for folks who maybe never learned functional programming formally and how they can start learning or understanding that pattern. Matthew Sinclair (06:50) There you go. A few things clicked for me, like it was a long time since I'd used it from back at the university and as anyone who is a few years out of university, you sort of go in knowing nothing and sometimes come out of university knowing even less. So I wouldn't say that I was an expert by any stretch of imagination. But after maybe say 20 odd years, 25 years or so of programming coming to it, a couple of things really just clicked. for me, immutable data structures, I mean, I'm gonna get really nerdy, but immutable data structures and pure functions save you from about, I don't know, 50%, like 50 % of the kind of bugs that you would get in normal code just aren't possible with that. Now, it's not that you don't have any bugs, of course that's not true, there's plenty of bugs, but pure functions. you can just test them in isolation. And with immutable data, you know that you're not gonna get side effects. And so those two things alone, would sort of, I'd make the point that's like, trust me on this, this is good. And once you get across the river and you realize, yeah, okay, I see, I see. So that's the first thing. Those two things just improve productivity enormously. But the other thing is this chaining of functions, composable functions. once you get a... you make a data structure and then you make these functions that do a little bit of mutation on the data structure and you chain them together. Once you get that kind of thing working, it's super cool. And there's a really non-obvious unintended consequence of all those three things is that it makes it very easy for a coding agent to reason about the software way, way easier than in mutable languages. So part of that productivity boost that I got. This year has been because I've been using Claude code with with elixir and it's a great combination a equals Claude's probably the better I think the better programming Foundation model at least in my experience But it's very good at reasoning about pure functional code because there's no side effects So you can kind of you can basically I wrote a sub agent for Claude called elixir doctor and I got all my my coding standards and every now and again when I've got nothing to do I'll go elixir doctor just just do your worst on this module. And because it's, you can change the internals of a function. As long you don't change what comes in what goes out, it'll just fix it. And so you can turn really, really terrible nested if-then conditionals, which is what Clued will do on its own if you just let it go. You can turn it into these really pure functional chained. Chains across across the data structure anyway, and I don't know the first time I did it I went I don't really understand what I'm doing and then it kind of clicked and I went oh, Okay, now I see and I see everything now in these data structures and pipelines of functions So I don't know whether that appeals to anyone, but it kind of it's a it's a very Fulfilling when you get one of these things written and it works pretty well and then the because of the the LLM interaction I mean, I feel like I've got a team of five engineers working for me now. And I sit here and I write code and I'll sit there and I'll rub a duck of design with Claude there. And you end up spending way more time upfront, I think that I probably would have in the past in terms of design, but you're not something out. And then all of a sudden it's just writing this code. hang on, hang on. No, no, no, no, no, no. Don't do that. Do this. And it makes some silly mistakes from time to time that you have to rectify, but at the end of it, you can kind of have at least two. often I have two Claude sessions going, operating on these. I wrote this thing called Intent, which is a bunch of little helpers to help Claude, to allow me to help Claude help me. It's just a free, what do call it, kind of open source thing I put on GitHub. And what it does, I have this concept called a steel thread. And so a steel thread is like a piece of functionality that I can describe. What I the reasons called intent is because what I'm doing is I'm capturing the intent about a piece of software and so if you think about when you're writing software you often don't capture the intent or you or you you might capture it a little bit in comments, you know you don't really do it, but doing it in a systematic way with a steel thread and then a bunch of work packages in that steel thread what it does is it stops context explosion so you can you can you get this little chunk of documentation and You can then come back to the problem when you reset your context when you come back to the problem and you just have to ingest the steel thread and it gets back up to speed. And then what you end up doing over time is you sort of leave this trail of intent, which is super interesting. You have these steel threads and you complete them and so on. But at any point you can go, oh, I wanna pick up steel thread 17, go and read that and come back to me and tell me, right? And then you put it in ultra-think mode, you say ultra-think this steel thread and then come back and tell me what's next. And rather than have to relearn the entire code base every time you turn it on, which just doesn't work. And I think when you hear people's frustration when they're talking about coding agents, a lot of it is around, the context we do is not big enough or I can't, I spend all my time trying to keep it on the rails. What intent does is it just helps it help, sorry, it helps me help it keep it on the rails so it can be much, much more effective. And so these combination of things, like it's kind of happy accident. I didn't set out for that to be true, but Elixir was fun. I started using Claude and it was a disaster. the first, the early part of it, I did this, I was writing this thing and I reckon I wrote 200,000 lines of code of which 150,000 were complete rubbish. And something occurred to me actually a little bit later on, I'll go a bit about it, but what occurred to me a bit later on was I was like seduced by this machine that was emitting all this code, just really, really seduced by it. And I felt like I was on. on superpowers and then I realised that most of it was complete crap. what happened, it took me a while, it took me a while to realise it, two or three rewrites of this thing before I realised and I came up with this analogy to try and describe it to someone that, I'm not trying to suggest that I'm Michelangelo so please if you want to send a letter, send a letter to Brittany, don't send it to me, I'm not suggesting I'm Michelangelo, but he said that in that David, that David was inside the block of marble. and he just had to find it. And so I feel the same way about coding agents in that the difference between a muppet with no experience and someone with 30 years experience is they'll both generate 200,000 lines of code. And the difference between the two is that the person who knows what they're doing knows which 150,000 to throw away. And that's the thing. so I get, I don't know if we want to have a conversation about AI and coding agents and so on, but there's a real polarized Real polarized points of view about coding agents, like the classic Hacker News really, I mean the whole world's polarized at the moment, but Hacker News is an example of this as well. You've got one side of the argument is sort of, I'll never have to write code again, we don't need software engineers, Claude, the GPT is just gonna chat or software into existence. Obvious nonsense. But the other extreme is also quite stupid, that these things don't work, they don't help you, they hallucinate, that and that. That's nonsense as well, and if you know what you're doing, you can be crazily productive. with these things. Now, even after 12 months of doing this, I still find myself like today, like yelling at it, anthropomorphizing this thing. Yelling at it because it done something stupid and I have to get up and walk away from a desk and go I'm not actually talking to a human. This is a machine You know escape escape control C controls. They get out start again, right reset But the truth of this is I think you know in the notes that you sent me this this mech suit idea Which is another metaphor that I came up with it's a coding agents like a mech suit. It's like Ripley an alien You you you if you know what you're doing like if you don't know what you're doing you're gonna hurt yourself and everyone around you Right? They're literally lethal. But if you do know what you're doing, then you can kill the alien and live happily ever after. And that's how I see it. It's like a mech suit that you need to learn how to use. And once you pick up, and there are definite skills that come from this. Being able to, it's not so much prompt engineering, but it's sort of like controlling the agent. It's like a parenting exercise. It's parenting instead of programming. Teaching the agent to work in your best interest. Anyway, like I said, happy accident between Elixir and Chord. They work very, very well together. It's been very effective for me. Erika (15:04) If for no other reason than like the pure fun of imagining myself in a mech suit, I'm like going to steal that imagery. Yeah, well, and thanks for sharing a little bit about your workflow too. Yeah, it's, I mean, it seems very situational and kind of like you said, like, Matthew Sinclair (15:14) Yeah, yeah. Erika (15:29) setting up the situation, providing all the tooling, providing the feedback for a successful AI assisted development situation. That in itself is a skill. Yeah, and like you said, the view of the person in command. like it's still so valuable of like knowing when to go in one direction or another, when to shut it down. Yeah, yeah. How do you like in that flow that you're talking about, like what are the intervention points? So you're talking about like you sort of like build, it almost sounds like I'm understanding like mini context windows based on like iterations and then. And then, how do you test along the workflow that you're moving in the right direction? Matthew Sinclair (16:25) I've just dropped in the chat there, the GitHub link, so you can have a at intent and maybe put in the show notes if anyone's interested in it. And full disclosure, no warranties, it's very much my workflow and I can't guarantee that it'll work for anyone else, but it works for me. But to your point, Erica, so... I find it very useful to generate tests as I go, rather than sort of in advance. I get it to write something and then I get it to test it. And then what I've learned is it's actually really, really bad at writing tests cold. It'll sort of write a lot of tests, but they're not very good. And so I constantly have to, when something doesn't work, I've got to constantly go back to it and say, you're testing implementation, not behavior. I want you to test the behavior. And so I end up, it'll generate. a thousand lines of tests and I'll throw away the same ratio, right, two, three quarters of it and get it, when a bug happens, I'll get it to write a test that tests for the bug, which is sort of what a human would do anyway, right, but it's just way quicker at it than me writing to And what I find as well is, this is a whole other story here, but traditionally, if you sort of, if you have to stack the cost of writing software in a stack, right, you've got, okay, I need to think about the problem, I need to sort of write down what I think the answer might be, an iterator, talk to someone, rub a duck, you know, whatever, and then I have to write the code. And so depending on how good you are as an engineer, you might allocate different amounts of time to those buckets, okay? And I would argue that the vast majority of engineers, unfortunately, spend most of their time writing code and not anywhere near enough time. in the first phases because we've all been sort of told that you just need to write code and iterate it and so on, right? What Clawd does or coding agents do is they effectively reduce the time cost of writing the code to zero or almost zero, okay? And so what that does is it gives you a bunch of extra time that you otherwise, you didn't have before to spend. more in the thinking about what you're gonna do. And this rubber ducking thing, like Claude's really good at it. say, wanna see, you know the rubber duck metaphor, you sit there and explain a problem to a rubber duck, yeah, okay. So I even tell it that, right, I wanna rubber duck with you, this thing, and it gets quite amusing. It's trying to be funny, not always funny. But we'll sit there and go backwards and forwards with the design. And then often it comes out, the designer comes out, right, so a pretty good designer, go, bang, go and do it. And then, but then you've got, this is where the pruning starts, right, because it'll mix. a bunch of code and then you have to print it back. But anyway, that's a rather circuitous way to say that the time cost of writing code, like your fingers on keys time, is sort of like that bit of the software engineering, which I know is not the total time, it's the hard parts about software engineering, the human parts, not the software parts. But that bit's now zero, okay, or not zero, but it might as well be zero. So you get all this other time to spend thinking about it upfront and you've got this sparring partner. this intellectual sparring partner which you can think about it with. I don't know if that answered your question, but that's the, if your question was, how's my workflow changed or what's my workflow, how to keep it on track, I spend way more time now thinking and rubber ducking design than I ever did before. I used to be the design with code school, like I'd. because you never really know what problem you're solving, so you sort of experiment and the code's the canvas, and so you're sort of iterating on the code. I don't do that anywhere near as much as I used to, if at all, to be honest, whereas I used to do that probably all the time. Erika (19:51) For sure, yeah. And I also have found that the idea of designing something in multiple ways to come up with the best version out of multiple ideas, that cost is so much lower with AI assisted development. Because you can of spike out like. not necessarily production ready versions, but what would this idea look like? What would this idea look like? Let's compare them, see what I want to take from both of those, and then maybe throw one away entirely or create something totally new. Matthew Sinclair (20:29) In intent, I've written a bunch of subagents in intent that fit into Claude and one of them is called Socrates. And the Socrates subagent, what Socrates does is I give it a... I set up some context for it and I give it to Socrates and Socrates and Plato. So Socrates is the CTO and it's the context there and Plato is the lead engineer with the problem and I get it to go off and do a Socratic dialogue on a problem. And so it's got my input context and then it goes away and thinks about it and the output, like this seems insane. Like even five years ago, if you'd have told me this was a thing, I would have gone, you are smoking crack. There's no way this could possibly even be a thing ever. And however, the results of this is extraordinary. Like it'll crack the hardest architectural problems, or even optimization problems, things going wrong. It goes off, it spends 10 minutes banging away, and then it comes back and says, right, here's this 10 page Socratic dialogue. between Socrates and Plato where they're evaluating the code and the problem. And as you said, actually, the really interesting thing is it's amazing when you say, me options and evaluate those options. It seems to lift a gear when it's evaluating options against itself, when it's arguing against itself. It's super powerful. But anyway, that's in the intent as one of the sub-agents, the Socrates sub-agent. I use it every day. Erika (21:46) It kind of reminds me of all the stories of creating DeepMind who played Go and ⁓ the way they trained it was actually replicating a second version and playing against itself for a month straight. I think the numbers is like it played more games of Go than... Matthew Sinclair (21:54) yeah. Erika (22:10) a single human code in like a hundred lifetimes or something. It's like, yeah. Matthew Sinclair (22:14) If I remember correctly, I vaguely recalled it. They ran out of games. So they had historical game data and they ran out of historical games for it to play. And so they got it doing exactly what you said, playing it. And in some very short period of time, it had played more games than have ever been played by humans in Go, ever. Erika (22:32) Mm-hmm. Matthew Sinclair (22:33) Right, so it's Erika (22:33) Yeah. Matthew Sinclair (22:35) exactly the same thing. For whatever reason, that really, and obviously Go goes way more complicated than chess. And what was his name? Lee Sedol, who got beaten by AlphaGo whenever it was. so like, okay, game playing is a solved problem for computers now. Erika (22:51) Yeah. Yeah. Super interesting. Well, thank you for sharing. Bethany (22:57) Yeah, to pivot a little from the engineering side to the more leadership side. So as I understand, you've scaled a lot of teams from very minimal sizes to large sizes. And so I'm curious if you have any core philosophies on technical leadership or any mistakes that a lot of new managers or new leaders make when they're coming into a role like that. Matthew Sinclair (23:24) Yes, I know a lot of mistakes because I made them and learned the lessons way too late. Look, the first one I would, I mean, I say this to everyone I'm coaching or working with is this basic why, what, how breakdown. And it's a little bit different to the classic sales start with why, because I think they say why, how, what, but I spin this around, for leadership and management, I spin this around a little bit. And so my basic pitch to people is that, Humans are storytelling apes, okay? And so in the absence of a good story, they'll make up their own narrative, okay? And so what you have to do, and this is increasingly true, sadly, in a post-truth world which we seem to live in, there's lots of narratives out there and people can pick, they've got a lot to choose from in terms of the stories. And like I said, if they don't have a good one, they'll make one up. So the job of leadership, the first job of leadership is to explain why smart people that they're working with should get out of bed in the morning and come and play their game, whatever their game may be, right? That's the first job, tell a good story. And then the second, and if you can't do that, the smart people have got plenty of options, they're go and do something else. And so then the second thing is peers should collaborate to work out what to do, not how, but what. And then the trick of good management is to get out of the way. I think and let smart people work out how to do the things that they've hired them to do. So that why, what, how I I use that, I use that everywhere. The other thing that I say to people about leadership and management is that management is not a promotion. It's a career change. Okay. I didn't coin that phrase, someone else coined it. But the interesting thing that they also don't tell you is that leadership is a career change from management. Okay. And that, that one is like, that's a footnote at the back of the, you know, the advanced textbook, you don't really get that one. so a lot of people, when they go into leadership positions, treat it as management, and it's not the same thing. Okay, and so that little lesson alone, just knowing that that's a thing, that when I'm becoming a manager and moving out of IC to management, and our podcast that I've mentioned before, What Next? is actually based on this premise that interesting things happen at boundary conditions, on the boundaries, right? So when you change from something to something else, that's when interesting stuff happens. And the palliative that I give to the flailing new manager or new leader is that your worst day in the job is today. Right, because today you've learned something and tomorrow you'll know a little bit more than you knew today, so it can only get better. And the worst time you'll ever have as a manager or a leader is the first day, your first day in the job, And again, it's one of these little things about just knowing that is very helpful because it allows you to lift your head a little bit and go, okay, right, today was terrible, but I learned something, so now I'm gonna be better tomorrow. So those two or three things are pretty interesting. The other one is, the last one was a bit more general, not really management-related, but I'm a big believer in values, and what I mean by that is that if you've got shared values, this works across the board, socially, family relationships and so on. If you've got shared values, you can kind of get through just about anything. And if you don't have shared values, it's hard, much, much harder. And so it's not that everyone has to have the same values, but when you're selecting for things, it's probably a good idea to try and pull people together that have similar values. So if you need to... do exploit something or go really to the hustle, then you want people who have a kind hustling mentality. If you want to do something bit more nurturing and a bit more, know, whatever, holistic, then you probably want people who share those values. And it's when you mix that up, you tend to get a bit of friction. So, yeah, that's another bit of advice that I'd give to them. It's very easy to say, of course, from here. But it's just one of those things, just knowing it is quite handy. Erika (27:02) Do you have like a reference of values that you go from or are they usually like self-described? Matthew Sinclair (27:08) I have my own that I stick with, are more or less what I've said to you so far. Why, what, how. Actually, the first one I have is be intentional about your values. This is one of things I say, particularly people in startups where you're growing your business and there's no such thing as no culture. there will always be a culture and you can have an intentional culture or an unintentional culture. And so as a CEO of a small business in trying to grow something, it's pretty important that you're intentional about the culture. Otherwise you'll get a culture that you may not have wanted. Or worse, you end up a culture that's just based on the bad behaviors of the most senior people. All right, which I'm sure we've all seen. we've all experienced that and it's pretty toxic. So the first one is be intentional about having some values and communicate them. There's a bit of a test that you can use with this, is, actually if I make it to a slight diversion, I think the role of the CTO, just to bring back to something practical, the role of the CTO is what I call the... Your role is actually Chief Vocabulary Officer. And what I mean by that is it's your job to come up with the words that people use to communicate because as the CTO, you've got to... foot in both camps, right? You should know the technology, obviously, that's self-evident, but you also should know the business and you should know the product and you should know the people, okay? And so it's your job as the CTO to admit the words that people can use to communicate with each other without feeling uncomfortable and they can talk about progress and status and so on. So yeah, have some values, be intentional about it. There's no such thing as no culture. You are, as a founder and CEO of a business, you are the culture ultimately and you have to demonstrate it. As a CTO, you need your jobs to come up with the vocabulary that people can use. Why, what, how, it's very effective. Always remember that boundary conditions are really interesting, so they can be perilous, but they're also opportunities. And again, there's a guy that used to work for me, we had a really deep conversation one day and people had been telling him all this career that he needed to change this particular behavior that he had. it occurred to at the time that I think sometimes it's really bad advice because the way you are is really hard to change. And so what's better is just knowing how you are. And then if you know how you are, then you can maybe grab a mask on a... from time to time and put a mask on to fit into a certain context or situation. But changing is exhausting or even impossible for many people. And so just knowing, this is one of those situations where I'm gonna lose it and so I'm going to write a one-pager for the meeting, submit it, and shut up, right? Or I'm... I'm one of those people who just talks in every empty space in a conversation. So I know that I'm gonna go into the room, into this meeting, and I'm gonna find the most junior person in the room, and I'm gonna go and ask them what they're doing or how they're feeling, or what they're working on. These are just sort of hacks that you come up with to get through it. I don't know, I'm not sure there's any real recipe for any of this. If there was, we could hand it over to machines. Brittany Ellich (30:15) It sounds like you've sort of been on a journey to find out these things about you. Do you have any recommendations for somebody who wants to know these things about themselves? Matthew Sinclair (30:25) Gosh, that is a very deep question. I'm not sure that I do know, to be honest. I think I can kind of guess at it a little bit and I've fumbled around in the dark a little bit. one thing that really helped me was I started writing down how I thought about stuff. And I... I don't have, like I'm not a successful blogger anything like this, right? But what I started doing was every Friday at Digital Ventures, when I was at Digital Ventures, like something would happen through the week of, you know, it pretty intense environment. Something would happen and I would, I could be like a one-liner and I would use that as the title of the blog post and then I would put it out to the team. And in the end, I started putting it on Medium, like it was internal, an email I did internally and then I did it as a blog post on Medium. And what, In the back of my mind, what I was thinking I was going to do is I was going to try and write a book about how to be an engineering leader. And it turned out that Will Larson did a way better job of that. And The Elegant Puzzle is the book that I wanted to write, and so I don't need to write that book anymore. But what I do know about writing, like a lot of creative activities, is that there's craft and there's art. Okay, so when most people look at something creative, they see the art, but they don't see the craft. So if you take a painting on a wall in an art gallery, you see the art, but what you don't see is someone understanding how light falls on paint and how you stretch your canvas or how you mix paints or find ingredients for your novel colors and so on. But no one sees that unless they are themselves are in that domain. And I think leadership's a little bit like that as well, right? You see that. When you see a good leader, you sort of see the art of it, but you don't see the craft. And so I've tried to come up with these, I call craft moves, that I've collected over the years, which are just little lessons, and like the one about going into the meeting and talking to the most junior person and finding out what they're doing, and shining a light on them, as it were, and just listening to what they say. It's a very good signal to give to a team, to let someone have a voice. And it's not hard to do, right? It's a really, really easy thing to do. You just have to put your ego out of the way. You know, the, I don't know, so right, back to the thread. Writing really helped me. What I found I was doing was, if you, like a lot of these things that I'm saying are actually blog posts that I've written, and what happened was in the writing, in writing it down, I went from just mush to a coherent couple of paragraphs that made some sense, and that was super helpful. So in doing that, it turns an idea into, like just a really rough idea into something that you can And so I had this, like one of things is this dolphin's not whales, right? In a conversation one day at work, I was trying to explain to a client why we work the way we did. And I said, it's a bit like a whale. If you think about a whale jumps out of the water, sorry, comes out, breaches out of the water and falls back in. If it's going the wrong way, it's got a huge arc that it has to turn around to come back to get on the right direction. And if you think of a dolphin, a dolphin's, you know, really quick and agile and they come up out of the water all the time and if they ever get it wrong, they're never wrong by very much, they can course correct. And so this whole dolphins not whales thing became a mantra in TV, this is how we work, dolphins not whales. Anyway, and it was an accident, it was just a conversational accident, but I turned it into a blog post and then it became a thing and it was like, Matt, you have to come and do the dolphins not whales presentation for this client. yeah, so write stuff down. It's, you know, an audience of you. I mean it really was audience of me just writing down. It helped me turn rubbish, messy ideas into something that I could repeat. Brittany Ellich (33:53) that yeah I think there's a lot of science behind that too like the whole mindfulness and journaling and how it's just so good to like get all of your ideas out. This has been awesome I don't think I've ever been excited about like checking out Elixir but now I am you've been a great evangelist for that. You have so many great ideas and I'm so excited to dig into all of these links after this Matthew Sinclair (34:14) the Elixir community is very welcoming, the Slack's great, the Discord's really good, there's a bunch of really smart people in there, definitely check it out, it's well worth your time. Brittany Ellich (34:21) That's awesome. Yeah, well, we'll include links to that in the show notes and I will also check it out because it sounds cool. I love Bethany's idea. Advent of Kodak is coming up. So maybe maybe I'll also take that challenge to do, Alexa. We are coming up on time, so I want to transition a little bit to our fun segments. This week we are going to be doing Two Truths and a Lie. Matt. We know you have a few unique interests like owning an electric mountain bike and a finger lime orchard in Australia. We want you to give us three statements about your life or career and we have to guess which one is the lie. Matthew Sinclair (34:59) Okay, we have to test my poker face now. And tell me see if I see you can tell what I'm Okay, so in no particular order to choose to align I can say my alphabet backwards very very quickly and there's very few people in the world I know who can do that my son I spent some time teaching me how to do it. My grandma taught me how to do it You'll know my surname Sinclair. It's the second one. So I'm related to the Sinclair's of the Knights Templar a second the second founding family of the Knights Templar and the Rosicrucians if you've been to the Rosalind Church in Edinburgh, which was featured in what's it called Dan Brown's, what was that book called? Da Vinci Code. And last one, I have a reconstructed right ankle that looks like a bike chain under X-ray and does set off airport security when you go through. Brittany Ellich (35:42) Wow, you really took this assignment in and made it really hard. That was great. Erika (35:47) I was trying to do my alphabet backwards when you were saying that and I got like four letters in. Matthew Sinclair (35:54) Sid by x, w, t, r, q, e, o, n, l, k, j, h, g, f, e, d, c, a. Erika (35:58) Alright, so that was true. So now we only have two to pick from. Brittany Ellich (35:59) So it's not that one. Bethany (36:00) There was too much detail with that one. Matthew Sinclair (36:02) Now you've got a... Now you've got... I tried to put unnecessary detail into all of them. I mean, I may have just learned my alphabet. I may have just learned my alphabet backwards for this question. Well, you've got a 50-50 chance now. Brittany Ellich (36:05) Mm-hmm. Erika (36:14) I think the second Bethany (36:14) Bye. Erika (36:16) one is the lie. Bethany (36:18) That's what I was gonna guess, yeah. While there was detail in all of them, there wasn't that much personal detail in the second one. Matthew Sinclair (36:25) Yeah, you're right. I put that one in because I would like it to be true. I keep waiting for the phone call to be admitted to the Knights Templar. It'd be quite cool. And the Illuminati, but it hasn't happened yet. So may never happen. So no, that is the lie. Well done. My poker career is over. My poker career is over. Brittany Ellich (36:39) Well, I guess we'll never know, too. Yeah. Erika (36:42) It was very good lie. Brittany Ellich (36:45) It was good. It was good. Yeah, I was very convinced. This has been, this has been awesome. Matt, welcome. Where can people find you if they want to hear more from you on the internet? Matthew Sinclair (36:58) A very easy spot to start is matthewsinclair.com and you'll have to bear with me because I have this long-term project to bring down surveillance capitalism, which is probably a topic for another podcast. But I am slowly putting all of my content onto my own stack. So I was using Medium and so on. rather than just simply do a simple static website, I decided to make my own... my own tech stack for the CMS, because I've got a bunch of websites. So matthewsinclair.com is my personal website, but it may be a little bit patchy at the moment. It's all written in Elixir, and it's running on, yeah, it doesn't matter what it's running. It's written in Elixir, and it's all part of a thing that I'm building called Luxa, which if you know what a Luxa is, it's a sort really cool, very spicy soup from Singapore or Malaysia. And Luxa is like all the flavors. And so my idea is to put sort of all of the CMS functionality into this thing called Luxa and I can very easily publish like a static site. Everyone, when they learn a new language, right, the first thing they do is write a static site publisher. So I did that, but I sort of did it on steroids with a bunch of other stuff. So that's gonna, I'm gonna release that as not too distant future. I was working on it here this evening. But yeah, mattysingler.com, that's the best place to go. Brittany Ellich (38:10) I love that. Do have RSS? Speaking of, on your own? Okay, great. Yeah. Matthew Sinclair (38:13) It does on, yeah, well, it does on, in fact, Luxor has, by default, you can just automatically RSS, it puts the RSS on the end of the URL and it'll give you an RSS for the blocks. It should, test it out, let me know. Brittany Ellich (38:25) Love that. I will, I will. RSS is the future. It's the past, but it's also the future, I think. I agree with that. Matthew Sinclair (38:32) Honestly, I'm so with you, right? This is part of my bring down some ounce capitalism thing. I think we need to get back to web rings and completely federated non data monopolist and networks of small, special interest groups, not this algorithm, what do call it? Brain rot, crap. yeah, I'm gonna fight this campaign on my own. So join me if you wanna come along. Brittany Ellich (38:38) Mm-hmm. Love that. Yeah. Yes, yes, we're, I think we're all there with you for sure. This is great. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, especially if you are also interested in stepping away from surveillance capitalism and share with your friends. Until next week, goodbye. Matthew Sinclair (39:00) Yeah, Good. --- ## Episode 33: Looks Good to Me with Adrienne Braganza - URL: https://overcommitted.dev/looks-good-to-me-with-adrienne-braganza - Published: 2025-11-11 - Topics: Technical Deep Dives, Leadership & Management, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/110992650/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-10-10%2F412228786-44100-2-f4559743cc7da.mp3 ### Show notes Summary In this episode of Overcommitted, hosts Erika and Brittany interview Adrienne Braganza, the author of the book Looks Good to Me. The conversation delves into the critical role of communication in code reviews, emphasizing that misunderstandings often lead to issues. It highlights the importance of understanding the purpose behind code reviews rather than just focusing on tools and speed. Takeaways * Misunderstandings are at the heart of code reviews. * It's important to understand the purpose of code reviews. * Focusing on tools can distract from the main goals. * Collaboration is key in software development. * Clear communication can prevent many issues. * Taking time to reflect on processes is valuable. * Agreeing on objectives enhances team alignment. * Code reviews should foster learning and improvement. * Understanding each other's perspectives is crucial. * Effective communication leads to better outcomes. Links * Adrienne’s Website: https://adrienne.io/ [https://adrienne.io/] * Adrienne on Bluesky: https://bsky.app/profile/abt.bsky.social [https://bsky.app/profile/abt.bsky.social] * Adrienne on LinkedIn: https://www.linkedin.com/in/adriennetacke/ [https://www.linkedin.com/in/adriennetacke/] * Book: Looks Good to Me: https://www.manning.com/books/looks-good-to-me [https://www.manning.com/books/looks-good-to-me] Hosts * Overcommitted Website: https://overcommitted.dev [https://overcommitted.dev] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I am your host today, Erica, and I am joined by... Brittany Ellich (00:08) Brittany Ellich Erika (00:09) We 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 and share what we've learned. 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, we are diving into one of the most critical yet misunderstood parts of every software developer's job. the code review. And we are absolutely thrilled to welcome Adrienne Braganza, Adrienne is a software engineer, international speaker and author of the book, Looks Good to Me, Constructive Code Reviews. We think that your book really strikes a chord because the process of writing and reviewing code reviews really isn't taught by anyone. It's something we all kind of learn on the job by mimicking others, maybe having a particularly kind co-worker at the start of your career talk you through the process. But your book, Adrienne, is a missing manual and it approaches the topic from a refreshingly human-centric perspective. It goes beyond just the tools and the syntax and addresses the crucial interpersonal aspects of team trust and communication and avoiding the kind of toxic reviews that harm morale and productivity. So thank you so much for joining us. ⁓ We're so happy you're here. Adrienne Braganza (01:40) Awesome. Yeah, I'm really happy to be here. Erica, Brittany, thank you so much for having me. I'm so not surprised that we're still talking about code reviews today, but I think it's actually even more important in this day and age. But yeah, always happy to talk about code reviews. Erika (01:56) Absolutely. Well, let's start with the core problem and your motivation in this space. So what motivated you to write a book specifically about code reviews? Adrienne Braganza (02:07) You know, I got the chance to, ⁓ in my role as a developer advocate, I get to talk to a lot of people in the developer network. And a lot of that includes a lot of teaching, a lot of workshops, a lot of technical tutorials. So, in that you kind of get these pretty cool opportunities. And that was one of them. Manning publications, reached out to me and said, Hey, we really like what you're doing. And we've seen a couple of your talks. If you had to write a book about anything, anything in tech, what would it be? like not even a half a second later, I'm like code reviews because you know, there's always the next new thing. If it was a specific framework, if it was a specific programming languages, those all move way too fast. Like by the time you go through the normal book review process, that thing is already outdated. So for that topic, I really wanted it to be something that was evergreen, something that affected every software development team. And it doesn't have to be a developer either. anyone who's touching code that could be software testers, I really wanted to hit a topic like that that really would affect the most people, but also is something that is just completely misunderstood, as you've mentioned. And I had a lot of things I wanted to share about what worked on the teams that I've been on and what didn't work and all the frustrations we surely faced. So yeah, that kind of was an easy decision for me. Putting all of my thoughts together, though. That was that's another story. That's why the book took about almost two years to write. Erika (03:41) Well, that is amazing that you got this opportunity and we're all benefiting from you taking the time to put your thoughts down on paper. And like you mentioned, mean, Adrienne Braganza (03:49) I hope so. Erika (03:54) This is, yeah, not a problem that's going away anytime soon of reviewing code. And, you know, we do talk a lot about AI these days, but sort of at the heart of... Your book is a lot of these interpersonal and communication aspects. So from your perspective, why is this human-centric approach critical ⁓ to a successful code review? Adrienne Braganza (04:19) I think ⁓ in the research that I've done, both from looking at papers that have been done on code reviews and my own teams and all the common patterns and themes of what was frustrating developers, it always came down to misunderstandings and bad communication. That's really the heart of most of the frustrations we deal with in code reviews. So I think it's super important to take some time to not just think what tool am I using or how do I make it faster or how do I just get the check mark. It's why are we doing this? What are we using it for? What do we all agree is something important to call out or not? And when you mentioned earlier is absolutely true. The first... team you work on and the first exposure you have to a code review process, if at all, that's kind of what you carry with you throughout the rest of your career. So if you're lucky enough to have a team that has an established process and has good communication and not just that, but good interpersonal skills and clear people with, you know, a co-collaborative nature of how they want things to be done, then like you're really lucky. Hopefully you learn from that. see this is what a code review process should be and I see the benefits of it and you take that with you throughout the rest of your career. But unfortunately, most folks don't have that. I had a terrible code review process my very first time. was, you know, a lot of people relate. I don't say everyone has this experience, but when you just come out on your first like real job as a software developer, even as an intern, you hear about this process and you're so worried about it because you're like, I don't want to be critiqued. I don't want to look stupid. I don't want to, you know, prove that I'm not supposed to be in this job. And then you have an experience where you do get your code critiqued and it is very harsh and it is very mean. That could definitely set you up the wrong path. Like you could say, I don't want to do this anymore. I don't like this. you know, some people might be thicker skinned and they're like, yeah, I did write crappy code or whatever, but Regardless of all that, I absolutely believe that there's a proper way to do code reviews and that proper way all comes down to communication. So I come back to that every single time. Almost all forms of frustrations and problems people have come to me about code reviews. It boils down to some form of miscommunication. Erika (07:04) Totally. mean, I think it's one of those areas where what's left unsaid and all the unsaid assumptions can really bite us. I've seen everything from the... There's a bit of a spectrum of the over-permissive to the hyper-vigilant reviewing style. And so much of the time it's a one-on-one sort of like back and forth. And so yeah, you do sort of establish this relationship with somebody through a code review. And like you, I think there's sometimes like some shared level of responsibility, which is true in all software development, but depending on the person either writing the PR or reviewing the code, there's assumptions on both sides about what the responsibilities are and what we're trying to get out of this. Like, you know, is it perfection? Is it good enough? Is it, you know, meeting some kind of quality or safety criteria? So totally true. And, you know, when those unspoken assumptions don't get met or it gets broken, there's a level of trust, but degrades and that can definitely compound over time. I I've kind of heard reviews weaponized in a certain way sometimes where like a bug gets into production and it's so and so's fault for writing the code or so and so's fault for not catching it in review. it's like, no, no, You know, that's right. Right. Like we're all in this together. And yeah, to your point, like Adrienne Braganza (08:36) That's the wrong way to think about it, yeah. Erika (08:45) it can be borderline traumatizing if you have a really bad review experience. Adrienne Braganza (08:49) Yeah, I think you hit the nail on the head as well as that because we all have such different experiences, that's why it is such an interpersonal thing rather than a more technical thing and why we all have so many of those unspoken assumptions. We carry those, what I call them in the book, implicit expectations of what a code review is supposed to be. And so when we see someone else doing either something completely different or totally against what we have learned. and have internalized as the code review process, that's another form of why there's so much friction between team members, because some people think it has to be done this way, some people think it's not that serious, some people are like, we don't need it at all. All of those experiences that have shaped our different trajectories in this field definitely play a part into how much friction there is if you don't have the same beginning experience in code reviews. Erika (09:46) Absolutely. Well, let's talk about some of the ways that we can set ourselves up for success. So you recommend a four phase process, establish goals, choose tools, set guidelines and refine. So say I'm on a team that is having a lot of friction. Where would I hypothetically start? Adrienne Braganza (10:06) That's a good question. With this information, I assume you have some sort of process in place and there are probably clear friction points that your team has. I would still start at the very beginning of establishing goals, but right before that, I would say take like one or two weeks to kind of jot down every member of the team, anyone that's part of the code review process to kind of just note What are those friction points? What is a bottleneck? What was not great? What got lost in translation? All of the things. And I think it's really interesting to compile those answers from the whole team to see, because some people think it's great. And some people think, there are only these steps in our code review process, but other people have missing steps or go through different steps. And just aligning the team on what they're... code review process actually is, is very enlightening to see what those common themes are and what different people experience as bottlenecks. So once you have that, then I think the four-phase process that I talked about can then begin, right? So now that you have those friction points, now you can establish those goals. we, you know, now that we know what's hard, what are we actually doing this for? Do they actually match? Are we doing this because it's just been in place? Sometimes teams do a lot of pair programming and the really, really strict formal code review process is actually not needed. It just needs to be something, a lighter version for that team. For other teams, they've just been going along with the flow. No one's ever really told them what it was for. They don't know what it is. So it's really good to start with what those goals are. Best case scenario is you're kind of hitting those goals after you've determined what the friction points are, then the next step is just to really go through each of the pieces there, the choose tools, the set guidelines and refine, but really take a look at it based on the friction points you've surfaced. So if a friction point is you want two people to accept a review or to be able to look at it, but your tool doesn't allow you to do that, that's a tool bottleneck that who knows you then you dig down that hole and see why did we choose this tool? Is it still working for our team? Does it not fit how we want to do our process and then talk about whether it's worth it or possible to change the tool. If there are guidelines that are not in place or ones that are in place that don't make sense, that's another conversation that you need to have with the team and another friction point that could be fixed. So if it's misunderstanding on what's a blocking piece of feedback versus not, and people are always fighting on your team about, I prefer to implement it this way. Well, no, I think my way is better. If those are the types of friction points, then maybe it's worth it to say, talk as a team and agree. This is definitely something we want to call out and should block an approval versus not. And then of course, the refine I always add in there because... it's going to change. Your projects change, your teams evolve, tools evolve, AI is here. So whatever you might have decided as a team initially at the friction points of that time, as you start to implement new things and new guidelines. they might not fit or you might need more. And so it's a continuous process to really make it work for your team. So I would start there, start logging those friction points and then go through the four phase process of what do we actually want with our code review process? What's the diff between that and the actual goals or the actual friction points we're having, see if the tools fit, see if there are guidelines that are missing or that we can delete and then continue. to do that over time. Erika (14:07) As you're talking, I'm thinking of like add on benefits that are not even said in like how you laid out the strategy, but in my own experience. I, like even with the engineers that I've worked with who maybe have, like I haven't had the best code review experiences with, they're all really smart. But I think in a lot of these like sort of process changes, sometimes they're the ones who are least likely to buy into some kind. some kind of like change. Like sometimes there's this attitude of like, well, like, you know, I'm doing fine and you know, the problem is not me, right? But as soon as you ask those people to like basically air their grievances or like note down everything that's wrong, like the list is a mile long. So. You know, not only does it kind of deescalate the situation to be like, hey, like, you know, we have this amorphous problem, like not naming names. It's like not personal. It's not anybody. It's our shared team problem. But we don't know exactly what it is. Like, what do you think is wrong? Like, you're so much more likely to get, you know, that one person or say it's like a whole team or, whoever might be resistant at the beginning. to like, once it's their problem, they named it, like they're more likely to want to solve it. Cause I do feel like that's also very much an engineering personality trait of like, see a problem, want to solve. Yeah. Adrienne Braganza (15:39) For sure. I think I talk about this specifically encouraging either engineering managers or tech leads to do and kind of lead the process for logging these friction points because depending on the team and depending on your rapport, like you said, it might not go that well. Another big part is that some people are not comfortable speaking up or talking about these types of things in a group forum. having a way to capture that information, not just in a, let's have a meeting and talk about all our problems in front of everyone. It's maybe you send it in an email, maybe you capture that in one-on-ones, maybe you go to an engineering offsite and everyone writes in a post-it note. There needs to be various forms of... Capturing this feedback if making it anonymous makes it better and more honest. Absolutely do that But you know, sometimes there are teams who are they're chill with each other and that's you're very lucky if you have that where if it is okay, then yeah, you have a conversation you talk about it and ideally you whiteboard it out and you you know write it all down, but I definitely encourage Really anybody who wants to pioneer this process and wants to take it make it better for the team to to capture all of that and solve it together. That's absolutely something that's a theme in the book. It's not just one person making this set of guidelines and then everybody follows. The more you have other people's input, usually you have more buy-in from the rest of the group rather than just top-down management. Erika (17:15) sure. One way to distill this information that you talk about a lot is ⁓ the team working agreement. So could you describe a little bit about what it is and what's maybe like the most important thing to include in it? Adrienne Braganza (17:29) For sure. love this. I learned about it. We borrow it. I don't know who the original is, but we borrow it from the Scrum world or the Agile world and any type of project management where it's just this set of guidelines that you as a team agree to enforce and what those guidelines are could be anything. So from the Scrum world, it's, you know, we agree what the different user story sizes are. We agree on their sprints. They're two weeks versus three weeks. We agree on how we're gonna treat each other. You can go as granular as you want. You can get as interpersonal as you want. But I thought it was a really great thing to apply to code reviews because there are a lot of different parts, those unspoken assumptions that would be great to put in a team working agreement. So for me, there's a lot you could put in there. But if you had to start and you definitely had to put something in there. I would say the most important thing is the reviewer and approver responsibilities and how you communicate in code reviews. So even that sounds kind of generic. What I mean by that is what are your non-blocking versus blocking pieces of feedback? So if something falls under the lines of a security issue, a code smell issue, you know, straying away from code convention issue, a, what's the word I'm trying to look for? If this ⁓ introduces, or if it makes code maintainability more difficult, all of these types of smells or things to look for you would put in a blocking issue list. And then all of the things that a lot of folks tend to agree are should not be blocked, meaning somebody can't, you know, not approve it because you don't fix it. Silly things like formatting, spacing, preferential variable naming, unless you can back it up within an objective fact. Like that's going to be different among every team. So if you can have that conversation and agree at least to the most important things of what should be blocked versus not blocked. That's one way to be more clear on communication. And the other part is how to structure your comments. I dedicated a whole chapter to this because it's that important, but I mentioned something called conventional comments. If you're familiar with conventional commits, it's kind of the same thing where you basically are structuring your comment so that it's very easy for the code author to read it and know what to do. Do I need to address it? Do I not need to address it? Is this blocking? It's not blocking. What is this related to? Do I need to make this fix right now? Is this a suggestion? Is it polish? Is it, you know, a lot of the times when we get pieces of feedback, we immediately panic and are like, my gosh, I have to work on all of these things. But then later on, when you talk to the reviewer, they're like, no, I just wanted to tell you those things. Like, actually everything looks fine. So you waste some time worried thinking you needed to make all these changes, but in reality, these were just, you know, things they wanted to share with you. So by adding a simple little tag or comment signal, like I also, what my team use, you can, as an author receiving that feedback, it's much easier for you to be like, okay, these are the things I absolutely have to fix. These are the things I don't have to address. And that makes it go much faster. those would actually be the top two things I would put in there because the majority of things that people argue about are within that process. It's misunderstanding each other and then you get into a debate and you're like 27 comments long and a thread of arguing why you should do this and why you should not do this. Or it's arguing about, no, you should approve my PR because X, Y, Z and then someone else says no. And you haven't decided on what. should or should not block it. those would be the top two important things. that kind of falls under what is the responsibility of a reviewer and an author. So the most important are the bonus things I would add in there are what is your code review process like actually do? What are the steps? Because that are not only be helpful to your team to reference, but any new team members can now easily get into the swing of things. Even folks who are not new to programming just new to programming, sorry, that's what I meant. If they're new to programming and they're just getting into this for the first time, that's gonna be very helpful for them. And then spelling out what is actually happening in your code review process. So if you use different statuses, absolutely spelling out what the different comment signals you're using are. If you have common scenarios of like, if you get stuck arguing about something, like what do you do? Those are all the nice to haves. but if you only had to start with a couple things, it's what are your comment signals and what's a blocking versus non-blocking issue in your code review process. Brittany Ellich (22:25) I love that my team at GitHub ended up reading this book altogether as well. Your book was amazing. Thank you so much. the conventional comments has been. Adrienne Braganza (22:29) So, nice. Brittany Ellich (22:35) really, really great for us. was something that I didn't realize that I did a lot where I was like, I'm just going to provide this extra bit of information. And that makes it really unclear when you're just like, OK, but I just want to get this thing completed. using that has been really helpful. Adrienne Braganza (22:48) I'm really glad to hear that. Yeah, I think it's just it also really helps across teams that are global. This is another thing I've come across too is folks who are uncomfortable or maybe not as confident in the English language. They also complain or not complain, but are frustrated that they are not as understood or what they want to say might be taken out of context because English is not their first language. So again, And some contract between team members of like, is what this means. completely eradicates that sense of this is what they mean versus this is what I interpret it as. And again, if you agree, you know, these are the comment tags we're going to use. It's blocking, non-blocking, maybe the section that it's applying to and maybe a ⁓ level up or polish or optimization. Just having that at least level of being on the same page just helps so much in Teams when it comes to writing out feedback. Brittany Ellich (23:51) Can you talk a little bit, you've spoken in the book about automation, which is something that I feel like lot of engineers love to automate things. What are your suggestions on what are the best things to automate versus what are the best things to leave to humans to judge? Adrienne Braganza (24:04) you So absolutely style guides should be like the first thing at most teams. That's one of the things that surprises me is that there are still people fighting about like indentation and spaces and you know, just a little formatting things. And I always thought we waste so much time on this, especially not just for, you know, you fixing it. I know everyone usually despises getting like 20 comments of, you missed So if there's anything that can be automated, should. Anything you can fix before the code review should be automated. If you have a linter, ESLint prettier, if you have static analysis tools, like Roslyn for C sharp.net framework, if you have... Any of these things, automated tests, so Mocha tests or dress tests, if you can run any of these things and fix them before the code review, I highly recommend implementing those things first because this is what I call the low hanging fruit, the things you don't want to waste your time on during the code review. And these automated tools will find it much faster. And again, with the interpersonal ⁓ thing, Most everyone was more willing to fix that squiggly line. Like if a machine is telling you you did something wrong, I'm like, ⁓ you're right. I should fix that. But if someone else is telling that to me, I'm like, I roll my eyes. like, I know you're right. But it just, feels, it feels worse if somebody else is telling me something like that. I'd rather have something that. With all of our ingenuity, creativity, nuance, context, what humans are good at, I'd rather have them spend their time looking at my code, looking for those issues that cannot be found by automation. I want to talk about that. I want to see some random edge case that I may not have seen because I was so in the weeds of creating this and getting this feature done that you happen to see. And we talk about it. Alongside of that, know AI is going to be a thing, right? The fact that we are generating so much more code with AI, that's where I'm like, code review is absolutely still necessary for humans. And I still stand by this. know the book, in the book I go, you know, I'm not against AI code review tools. They're getting better. They're definitely better than when I published the book. But it's still not there. The thing is, you want to maybe use them for like a first pass. So absolutely use the code review tool to surface, again, those low-hanging fruit, those suggestions, those easy fixes. Maybe it's a typo, maybe it's something that fixes the structure of code to make it more readable. Absolutely use it as a first pass. But then as a team, you need to monitor and see is the use of this AI tool, again, is it achieving the goals that we want? Are we spending more time correcting or getting false positives from a code review tool versus it making it faster for us versus it surfacing things that we don't see? Those are the kind of new questions that we have to ask ourselves as we start to integrate AI tools into code review. One thing I definitely support is keeping structure in the code review process. So I talk a lot about being very, very explicit in our PRs. Make sure the title can be well understood and you don't even have to go into the description to know what this is about. Keep it atomic, make it actually manageable to review, link things, put things to documentation, and using automation and tools to help you do all of that because that's the extra work that Unfortunately, a lot of software devs don't want to do. There are a lot of folks that are, know, sometimes we're feeling lazy. Sometimes we just don't care. But if that helps counteract those feelings to make sure we're doing better and just. being better software developers, I'm absolutely for using automation and tools like that to keep consistent, to add explicit information in our PRs and to, yeah, do the first pass. But I think for fully taking care of the code review, absolutely not. ⁓ For, you know, even going so far as let's just pass it to say code rabbit, for example, and then it approves it and it's all automated and there's nothing in there. Absolutely not. We're not there yet. I actually even spoke to some folks on the CodeRabbit team. I mean, I don't know if they're going to like me saying this, but they did say, you know, we are absolutely in support of humans still being in the process. We didn't build this tool to completely replace humans in the code review process. We built this tool so that a lot of those friction points of maybe trying to get feedback faster from the reviewer of explaining things of surfacing easy suggestions to fix right away, those types of things, we absolutely built it for. And obviously it's still going to take time to also learn how our team works, how our project works. That cannot be replaced, at least quickly, by AI. Those are the things that are stuck in the corners of our mind that's what we should be using in the code review process. ⁓ Absolutely use it in moderation and final sign off on code reviews should to me still absolutely be humans. Brittany Ellich (29:43) Yeah, that's valid. Big plus one on that. Both Erica and I are at GitHub, so we use the GitHub code review quite a bit. It's just sort of built into our process as we're testing it out. And I agree. I think it's like a step above like the ESLint or like all the linters that are out there. And there's some things that I've learned from it that I'm like, I didn't think about that. But there's so much that you just can't feed into AI. you can't. feed in all that extra context of all the other systems that it has to interact with, or if there's multiple teams working within a code base, it's not like it has that context of like, this is how this team prefers to do something versus this is how this team prefers to do something and the conflicts there. So maybe one day, but I don't think we're there yet. And it seems like with more and more AI, we're spending a lot more time reviewing code than ever before. Erika (30:27) Yeah. And Adrienne Braganza (30:28) Yeah. Erika (30:28) it also, like, I don't know. It's still, like, I still know that it's up to me to own whatever code is in my service area from, a mental model perspective. And I don't think there's anything that can replace pull request reviews in building that mental model of the code, aside from maybe writing or modifying it yourself. But, like, If I don't understand the source code that's going in, there's no way I'm going to be able to tell if some generated code is legit or not. If it tells me this is the way to do this thing, if I don't know what it's going to or what it's referring to, then sure, I'll take your word for it. yeah, it can really... I can really see how it would shoot us in the foot as developers to wholly offload the mental work to AI. Whether, like you said, whether it's laziness or some kind of efficiency gain or any of the motivations, sorry, you still have to use your brain. Adrienne Braganza (31:39) Yeah, I think a lot of folks miss that part is what I've seen lately is a lot of folks are introducing AI code review tools because they are being measured by metrics that are like misused. that's one thing I kind of touch on, but that could be its own book. But you know, if you're if you are ⁓ rating or monitoring the performance of your devs based on some arbitrary single measurement of like, how fast did you close your PRs or how many did you review? And you only take that single measurement into account without looking at the whole story. I mean, that's some of the reasons why some devs I've spoken to are like, well, yeah, we're very much in support of the AI code review tools because it's going to help me review more faster. with the goal of, you know, gaming that metric. So it's really important to kind of, you know, remember that these might be the reasons for why we unintentionally make it worse for ourselves, even though we think we're doing the right thing. And just take a step back from those types of reasons. Always go back to like, what was the whole point of why we wanted to do a code review in the first place? this fits in into the wider ecosystem of like a fully robust CI CD pipeline, you know, a lot of folks are like, well, I have all that automation in place. Like, why do I even need a code review? You know, it's going to be caught or if something breaks in the staging environment, it's okay. that's, that's not the point. The point is there still needs to be some sort of oversight of knowing what's going on in your code base. And for most teams, the only place where that happens is the code review. otherwise, it's when you're pair programming, but then how do you share that knowledge across the team rather than just the two that were working on it? And again, if you have to reference something in the future, even if it's yourself six months from now and you're like, what did I do here? Why did I make this change? I don't remember. I don't remember what happened two weeks ago. So the more documentation that I have, not just of what is happening, but why, a lot of what's missing and that's what takes so much longer to get back into a code base, I argue, is because you're trying to understand why something was done the way that it was done and when you go back into it, you're like, you know, maybe you try something that was already tried and nobody's documented why that implementation didn't work and there's some quirk and so, yeah, I digress, I'm going on a tangent now, but you definitely just need to take everything into moderation. and see what those initial goals were for or why you establish a code review in the first place. Erika (34:29) Well, we could, I think, talk about this for many hours. But I think that's a good place to leave our conversation of the motivations and some really practical ways to integrate some of this book and the contents to our own teams. And one thing that really shines in this book is is so much personality and truly like the joy of going through this with you, with all the illustrations and you also talk about emojis, which, you know, especially in like a remote first environment ⁓ can kind of communicate a lot of this intent and enthusiasm, personality that... might get lost in sort of like a remote, remote first environment. So our fun segment today is, I'm call it Emoji Personality Check. So this can be in your code review personality or some kind of like other area of your life where you feel like you could really characterize it in a single emoji. And so what that emoji would be, sort of what part of your personality it describes and any more you want to share. So we'll go around. We'll let you go last so you have a second to think about it. So I feel like a lot of my life is captured by the sweat smile emoji. Probably as evidenced by the name of this podcast as being overcommitted. I always have a lot going on. But I do try to approach it with some semblance of joy and sense of humor. So it's usually not the crying emoji. It's usually like the, I'm barely there. I'm making it work and I got a smile on my face, so. Adrienne Braganza (36:17) That's the, that's personified as an emoji. Erika (36:21) Yeah. Exactly. ⁓ Brittany Ellich (36:27) I love that one. I feel like the one that I want to reach for the most when I'm like adding a, an emoji on a comment or something like that is the upside down smiley face. Because that one is just like communicates to me like, why is this like this? And that's usually what I'm asking myself over and over as I'm investigating a problem or, you know, hopefully not with code reviews as much because that could come off a little bit offensive to some people. But yeah. Adrienne Braganza (36:47) You Brittany Ellich (36:54) I think that I really like that one and I wish that that one was more available. Adrienne Braganza (36:58) I feel like we're cut from the same cloth because I have like when I first thought about I'm like well Sweat Smile is definitely the one I use the most and then the second one upside down I'm like, yeah, I do that a lot and I'm now looking at my own phone to see what I'm using so lately There's the one that's just the two eyes, but the mouth is straight just and I think that's I think that's a good one for me too. That definitely explains my personality. I would say fairly accurately after those two because those two are way more like higher on the tier, but there's just so many things now where I'm... I guess it comes from a place of like... Either, huh, I didn't know that, or huh, is this really the world we're living in, huh, did I really do that? It could apply to so many different things. So I think that's a good one to have. The only other one I would put is probably the drooling face, because I really like to eat food and desserts. Erika (37:40) No. Well, super fun. I might have to incorporate the emotionless emoji more in my life as a good balance. Yeah, like the zero reaction. Brittany Ellich (37:52) that's very relatable. Adrienne Braganza (38:05) Yeah, I think it's going to be healthy for all of us because I think also before I would probably either answer too quickly or say something and I guess that one's a good one now. just, let's just take a moment. Let's just, hmm. Yeah. Is it worth it? Is it worth it? Yeah. Yeah. Erika (38:17) Yeah. Brittany Ellich (38:19) I love that. Erika (38:21) Well, thank you again, Adrienne, for joining us and ⁓ thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. And Adrienne, if our listeners want to follow you, where could they do that? Adrienne Braganza (38:39) Yeah, check me out on Blue Sky. It's at abt.bsky.social, because I haven't switched it over to my domain yet ⁓ on the to-do list. And yeah, just on LinkedIn or on my website, adrienne.io Erika (38:56) Well, until next week, check us out on Blue Sky for our show notes and any episode follow-ups and share with your friends. Goodbye. Adrienne Braganza (39:06) Thanks. --- ## Episode 32: Navigating the Startup Landscape with Rick Turoczy - URL: https://overcommitted.dev/navigating-the-startup-landscape-with-rick-turoczy - Published: 2025-11-04 - Topics: Non-traditional Paths to Tech, Leadership & Management, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/110522009/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-10-1%2F410376629-44100-2-713cfa31d0669.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, host Bethany and co-hosts Erika and Brittany welcome Rick Turoczy, a veteran in the Portland tech startup scene. They discuss Rick's journey from a hobbyist developer to a key supporter of startup founders, the unique culture of Portland's tech community, and the importance of mental health for founders. Rick shares insights on the challenges of being a founder, the evolution of startup culture, and the role of PIE in supporting startups. The conversation also touches on local recommendations and the vibrant community in Portland. Takeaways * Learning how to learn is a crucial skill for navigating the startup world. * Portland's tech scene is characterized by a unique culture of humility and creativity. * Founders often face significant mental health challenges and need support systems. * The PIE initiative aims to foster collaboration between startups and established organizations. * Mistakes are a part of the learning process for founders, and experimentation is key. * The startup landscape has evolved, making it easier to build products but harder to sell them. * The challenges of being a founder are often underestimated, leading to burnout. * Understanding the difference between wanting to build a product and wanting to build a company is crucial for founders. Links * Rick's LinkedIn: https://www.linkedin.com/in/turoczy/ [https://www.linkedin.com/in/turoczy/] * Rick's Bluesky: https://bsky.app/profile/turoczy.bsky.social [https://bsky.app/profile/turoczy.bsky.social] * Rick's YouTube: https://www.youtube.com/@turoczy_ [https://www.youtube.com/@turoczy_] * PIE Cookbook: https://github.com/piepdx/pie-cookbook/blob/master/docs/pie-cookbook-0.9.md [https://github.com/piepdx/pie-cookbook/blob/master/docs/pie-cookbook-0.9.md] * Powell’s City of Books: https://www.powells.com/bookstore/powells-city-of-books?srsltid=AfmBOoqCGKjvdY5g6DowX0ReNqRlLARxeI5WKwGyc8P0Pq3O8j9Fd0NQ [https://www.powells.com/bookstore/powells-city-of-books?srsltid=AfmBOoqCGKjvdY5g6DowX0ReNqRlLARxeI5WKwGyc8P0Pq3O8j9Fd0NQ ] * Deadstock Coffee: https://deadstockcoffee.com/?srsltid=AfmBOopNiNhvGUigNJxASlm97jUCcSb6l36xCJ6sZF6mRIkyIseejJQy [https://deadstockcoffee.com/?srsltid=AfmBOopNiNhvGUigNJxASlm97jUCcSb6l36xCJ6sZF6mRIkyIseejJQy] * Podcast recommendation from Erika: https://podcasts.apple.com/us/podcast/237-mistake-it-till-you-make-it-learn-faster-and-fail-smarter/id1494989268?i=1000732814742 [https://podcasts.apple.com/us/podcast/237-mistake-it-till-you-make-it-learn-faster-and-fail-smarter/id1494989268?i=1000732814742] Hosts * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Bethany, joined by... Erika (00:08) Hey, I'm Erica. Brittany Ellich (00:09) And hey, I'm Brittany Ellick. Bethany (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've learned. 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're thrilled to welcome Rick Turosi, a Portland ecosystem veteran who spent three decades in the trenches with startups. Rick doesn't just support startups, builds the founders behind them. Rick, we're so glad you're here. Rick Turoczy (00:43) thank you. It's a pleasure to be here. I'm really honored that you chose me, especially that I'm like a hobbyist developer at best. hopefully I can hold my own. Let's not get too technical here. Bethany (00:54) ⁓ no, that's amazing. I am so excited, especially just with all the work you've done within your community and stuff. Super excited to discuss some more of how you think about things like that and how you support founders. So let's dive in. Wanted to start with just generally, how did you get started in the Portland tech startup scene? Were you always interested in technology or did it come later? I would love to know some of your background. Rick Turoczy (01:13) Yeah. Yeah, yeah, happy to do, yeah. Portland, pretty accidental, quite frankly. It's like a series of happy accidents kind of thing. I used to be a very, very good developer in BASIC on a TRS-80 when I was like in fifth grade back when you still had to press like play and record to save your files. But I continued to just kind of remain a hobbyist and involved in technology. But went to school. got a degree in English, wound up moving to Portland and it was just really a random opportunity with a company that was hiring for an editor and copywriter that happened to be this thing called Startup. And I didn't know what a startup was or like that. I mean, I realized people started companies, but I didn't know that like you joined companies that were still at their formative phases. And my initial role kind of quickly transitioned from being a copywriter to being the guy who built pitch decks all day, every day for the founding team. And then continued to grow and learn about the organizations and kind of wound up following a few executives around to new startup gigs. So for about 12 years, I was just bouncing around from startup to startup, all venture funded, all tech companies here in Portland. And then, you know, thought I'd learned enough to do a company on my own. So tried that a couple of times and was just like, no, I'm not a founder. I'm like really good tactical support for visionary founders, but I'm not that visionary person. So kind of was spending a lot of time in the open source community. And because that's where a lot of the startup activity was coming out of. This is about 2005. or so. So it's at the point where open source is now being adopted by corporations and proprietary software pursuits. And at the same time, cloud infrastructure is becoming a real thing. So it's like this perfect storm of just like things that used to take us a room full of engineers and a room full of servers were suddenly being built in a matter of weeks or months by a handful of developers. And I just found that super interesting. And so again, didn't have enough technical acumen to contribute to any of those projects, but I was like, I'll just open source my marketing communications. And so I just started writing about what I saw happening in the community. And I'd blogged since the previous century when you used to have to write code to put words on the internet, you know? And so I didn't expect it to be anything. I was just like, this will be my personal journal. keep track of what's going on and for whatever reason it struck a chord. So people started sending me stuff and they're like, write about our startup, tell people about our event and all those kinds of things. So that's really how it started and now it's been 18 years of what is basically now a bad habit of writing about what's going on in the Portland startup community. Erika (04:14) I can see maybe some of the magic that you have in my cookbook. I think I laughed about like three times reading the first paragraph. yeah, the joy comes through and is in a sort of contagious. Yeah, it's contagious. Rick Turoczy (04:18) Hahaha That's very kind of you. Yeah, and that's my one and only GitHub repo that's had any traffic whatsoever is we just used it to write documentation for one of our programs. And that was a really interesting experiment as well. Bethany (04:46) Yeah, I was definitely a big fan of your philosophy on open sourcing your thoughts around startups and what makes a good founder. And I think honestly, more of that is so needed, especially it was a wealth of information. It was really cool, potentially related. But would you say your background in English has set you up for a... given you lot of skills for your future with startups or how has that interconnected? mean, even maybe more than just writing. Rick Turoczy (05:14) Yeah, that's a great question. It was a small liberal arts college that I went to. And I think if I learned one thing there, it was actually how to learn, how to not be afraid of a new topic and how to embrace the learning around that topic. And that has probably been the thing that's most valuable. I think in that system, you wind up juggling a lot of topics and you're like, you know, inch deep, mile wide on any number of subjects, but have to pretend you're expert in them. And I feel that that works really well for especially early stage startup founders who are kind of pretending they know what they're doing or trying to kind of fake their way through stuff. And I still talk to my alma mater and other small liberal arts. Colleges and they're kind of having a crisis of confidence right now. They're like, we don't have a CS program or like we're not teaching business acumen or those kinds of things. And I'm always trying to remind them that like if you teach people how to learn effectively, then that's really, you know, an asset that people are going to be able to put to use regardless of what they pursue. So I think it, I think it was really that. And it was one where you were almost Forced out of your shell to explore new topics like that was part of the requirement was making yourself a well-rounded Individual in terms of the educational perspective. So I think all of those things were really Really helped contribute and then specifically from just an English perspective like To it kind of like we've talked about a little bit like just putting stuff in ⁓ common English and not using acronyms or lingo or like just being basic and explanatory can sometimes be hugely valuable in our industry. you know, people get really used to talking in code or lexicon that does not resonate with a regular individual. So I've found it's really helpful for me to be able to like convey that stuff in standard. English or it forces me to ask questions where I'm like, what do mean by that? Like, I don't understand. How would I explain that to somebody else? Like that's been that's been helpful as well. Bethany (07:32) It definitely makes sense, especially if you're founder trying to ask for money or interest in your product, you need to be able to convey very concisely and crisply what it is you're selling. that definitely makes sense. with regard to, said you moved to Portland after college, was there anything that drew you to Portland as a community and ⁓ what sets it apart from other areas that are more typical for tech startups like Silicon Valley. Rick Turoczy (08:01) ⁓ great. Great question. Yeah, I was just I was a huge fan of Portland. Like before I moved here, I I was a dumb jock. Like I played sports all through school. And so even in high school, wound up over here playing sports quite often. And then in college, I was here a lot. And I really enjoyed my college experience. But. You know, when I graduated, most of my graduating class was moving to Seattle and I was like, kind of done with college. I kind of need to move on to that next phase of my life. And so Seattle was close to Portland. That was one of the compelling things was it was close enough to kind of stay in touch with friends. And the other part was, you know, I'd grown up all over, but my high school years were in a small rural town. And so, Portland had this compelling like small town-ish mentality even though it had a larger metropolitan culture available to it and I found that really compelling about the community. I think in the in the time that I've been here, so I moved here in the mid 90s, so 30 years, and in the time that I've been here like it's come into sharp relief that Portland has this really interesting, I refer to it as like aggressive humility. Like the people here are really smart and really creative, but they don't self promote. They don't brag about it. They're just kind of, oh, this is just the thing I do. I do this little thing. And then you find out later they're like the CEO of a billion dollar company or something. And it's like, I love that part about it. It's super charming. And I think it also lends to... Because people aren't living to work, like they might be in the Bay Area where it's like work or your startup is the be all and end all. I think, you know, people have more pursuits and creative outlets and like they're interesting, well-rounded people that always makes for compelling just communities and engagements and people you get the chance to chat with. I think... Portland is a unique place on the West Coast, especially when it comes to technology. Like for somebody who's worked in tech in Portland for 30 years, I'm not sure it's really a tech town. Like I think we've kind of made a run at it a few times, but that might not be the most compelling ecosystem for us. And I think... You know, as the West Coast culture has kind of become more homogenous, like 80 % of the culture on the West Coast is the same, regardless of where you're located physically. If you're in San Diego or LA or Seattle or Portland, like you get good food, you have access to the outdoors, like all that kind of stuff. And it tends to be those more specific aspects of the community that tend to attract people. And so I think there's almost a... selection bias for Portland. Like if you're really hard charging startup type, you're probably going to gravitate to the Bay Area. If you're more business corporate type, there may be some things that are compelling about Seattle. And so I think we find we find that that people we wind up with a kind of similar group of people because of that selection bias. And that can be both good and bad for a number of reasons. But it also feels like other regions on the West Coast specifically have, they've been defined already and Portland still feels like it's trying to figure out exactly what it is or what it wants to be. And I find that compelling as well and interesting. Like we haven't. We haven't really owned our own narrative. We don't really have a brand unless it's defined by somebody else. And so it's kind of a constant creative work in progress. And I find that interesting as well. Erika (11:59) Yeah, I was gonna say, I think you described that as kind of the blank space phenomenon. And like it is kind of interesting thinking of how to see that blank space because it is dependent on the person. Brittany Ellich (11:59) Yeah, that kind of, sorry, go ahead. Erika (12:16) You know, I always think of like this idea that like, you know, three different people are looking in three different windows. One person sees the couch, one person sees the chair, one person sees the rug. Like what's actually inside the house? Well, it depends on what you're looking at. You know, it's like the blank space depends on like your sort of mindset and like who you are, like what problems you end up wanting to solve. But at the same time, like you know, eventually like the tech that you build is used by someone else. So like having some connection to like real problems that other people might be experiencing, like takes that curiosity, takes that humility and be like, okay, but like, is this actually a problem we're solving on like a bigger scale? You know, maybe, maybe I need to go and look at another window to see, you know, if they need a chair, they already have one. Rick Turoczy (12:52) you Yeah. Yeah, totally. Yeah. Erika (13:08) kind of thing. Rick Turoczy (13:09) Yeah, I think there's I think there's Portland, in my experience, tends to excel in the space between maybe the people building the product and the people using the product. Like we're we're like engineers building tools for other engineers, like we're infrastructure plays or or analytics plays or that kind of thing seem to be the spot that we tend to do best. And I think to your point, it's because we're looking at both of those parties and being like, what you do is great, but it's too hard in this specific area. And it's not delivering the right experience to the end user. And so we find ways to kind of fit in between there, be it with cybersecurity or kind of like APIs or piping or plumbing or that kind of stuff as well. Brittany Ellich (14:00) Yeah, actually, I haven't thought about that as characterizing a lot of the startups in the area that have been pretty successful. But I agree with that statement that a lot of them tend to be like developer tools type focused. ⁓ Yeah, I've been to a lot of tech events here too. And I can say that ⁓ I am, think I'm the only, I know I am the only of the hosts actually living in the Portland area as well. ⁓ And I definitely agree with the humility part as well. Rick Turoczy (14:13) Yeah. Hmm? Brittany Ellich (14:29) I can probably count the number of times on one hand the times I've gone to a tech event and actually talked about anything tech related. Nobody actually talks about their job or what they do or if you ask somebody what they do for work, it's like, that's kind of weird. Rather talk to you about my obscure coffee roasting experience. Yeah, yeah, exactly, yeah. Rick Turoczy (14:35) Yeah. Right, exactly. Let me talk to you about my LP collection. Brittany Ellich (14:53) I also love Portland for a lot of those reasons. So one of the things that we would like to know about is sort of your experience with supporting founders. I know you've done quite a bit with Pi. The Pi Cookbook talks a lot about making mistakes. And I'm curious if that's something, is that like drawing from your own experience within your career about like, you know, making mistakes and how it's important to do those, to learn from them, or how have you seen that play out with the founders that have gone through there? Rick Turoczy (15:11) Mmm. That's super interesting. Yes, I have learned from my career. what like one of those, you you sometimes have those random like things that just kind of stick with you forever and just kind of become a touch point no matter how miniscule they may seem like I can still remember like I was cleaning out my garage or something and came across a brochure. ⁓ We used to do brochures. They were printed. Erika (15:19) Thank you. Rick Turoczy (15:44) pieces of collateral that people would hold in their hand before we did all the digital things. like, like it was a brochure I'd worked months and months and months on and really been like, you know, painstaking work, trying to make it the perfect document possible. And I remember opening it up and seeing a typo on the first page. And it was just like one of those things. It was like, if I was so obsessive about this, And that still got by me. then most people aren't noticing most mistakes we're making most of the time. And that really inspired me to like, people come back sometimes and they're like, you told me to do this and it worked really well. So I kind of stick with it. It's like just half ass everything. Like don't be so like, I have to be all in, I have to be perfect. I have to do whatever like. It's really been this like, if you want to do something, don't worry about going all in, just try it. And you need to try things and experiment to figure out where your skills or expertise actually exists. And with founders, you kind of have to push them to do that because they're expected to do everything. Like I think one of your recent conversations the founder was talking about, like, I knew how to build product, but I didn't realize I had to do all these other things to be a founder. And you're never going to be perfect at all of those things. You're never going to be expert at all of those things, but you do want to try them or at least risk failing at them to figure out where the gaps in your knowledge are, where you can excel for the company. You know, I... I have conversations with founders all the time, especially technical founders, where I'm like, are you sure you want to be the CEO of this? Do you want to just lead product or be the CTO maybe? And they're like, no, no, I totally want to be the CEO. I'm like, OK, but you don't get to do any of fun stuff anymore. You have to do all that other stuff, and somebody else is going to be building product and doing the things that you enjoy. So, so much for startups and founders apart from that experimentation is helping them have the courage to fail so they can figure out where they can be successful or to have them say like this isn't what I thought it was like For me as a founder, it took years and years for me to figure out that I didn't want to be a founder. If I can help somebody else figure that out in three to six months, everybody wins because that person's really focused on what they want to be doing and what they should be doing. But they would never know that if they didn't have the opportunity to try it, to experiment with what they were doing and likely potentially fail because that's mostly what startups do. Like they just don't. Like, it's so, there's so many moving parts and it's also like timing, which you have absolutely no control over. It's like the market has to be there, the idea has to be right for that market. Like technology has to be at a right level for it to deliver in the right way. So many, so many aspects of, you know, what makes a company successful has absolutely nothing to do with the founder. So it's, you just have to get used to that. potential for failure. Brittany Ellich (19:03) Yeah, that makes sense. I have never personally been a founder, but I've watched that journey a lot with my brother who was at Pi. I think also Erica had a great point that we should probably define what Pi is for listeners. ⁓ Rick Turoczy (19:08) Yeah. sure. Yeah, yeah. So Pie, at its very most basic, is just this ongoing experiment to figure out how more established organizations like a corporation or an educational institution or maybe a government entity can effectively collaborate with startups and startup founders for mutual benefit. So we don't want it to be a one way thing. We want the established entity to be deriving value from it. We want the startups to be deriving value from it. We've been working on it for about 15 years. It started as a coworking space and then really we kind of got into the situation where coworking is a hard model to begin with. And what we started to realize was if you're a coworking space, you have to take anybody who can. pay for a desk, whether they're contributing to community or not. And then we were also encountering people who are like really great stewards of community who just couldn't afford coworking. And we're like, what are we doing here? This isn't, this isn't the right model. And so we kind of pivoted into the startup accelerator model, which, which people throw that term around. It's basically just mentorship for startup. founders over a very short period of time, usually accompanied with some investment of capital of some sort. And so we just continued to kind of iterate on that. We copied a few other models and kind of mucked around and put something together and then continued to try different things. We originally started in SaaS mobile kind of stuff. The only thing that remained consistent year over year then was we really felt the shared workspace was valuable. We felt it was valuable to have founders around other founders for both peer support as well as just like emotional support. And then we learned a lot during the pandemic where like this model does not work terribly well if it's not in a physical space. Like the space itself does a lot of work. that we didn't even realize it was doing. And we've also experimented not only with different organizations, but different participants, different types of products. So our original partner was Widening Kennedy. If people don't know who Widening Kennedy is, they're a global advertising firm that came up with Just Do It. They're like the Old Spice Guy and Coca-Cola Polar Bears and like that kind of stuff. And they really wanted to just learn more about innovation and technology. That's why they began the pursuit. We did a great program with Daimler. Daimler Trucks has a corporate presence here. We helped them build an external, an internal accelerator for employees to address problems that were occurring in the corporation and use kind of thinking to solve things like that. And we experimented with digital storytelling. like what back then was AR, VR, XR kind of stuff, video game things. We have a partnership with Autodesk, which has a major Portland presence around manufacturing or founders who are building a physical object, ideally one with some electronics related to it, because they like figuring out like... both the circuit boards and the housing. And so that was what motivated them to engage in that. And then for people who aren't familiar with Portland, one of my co-founders always refers to Oregon as the Silicon Valley of consumer products. We have more like footwear and apparel and food and beverage and coffee and blah, blah going on here than probably anywhere else on earth. And so we... took the opportunity to focus on some consumer products companies and test the accelerator model with them as well. So it's really like, it's just a learning platform. It's a way of delivering education and mentorship. And we just always look for new ways to kind of leverage that to see what's possible. Brittany Ellich (23:19) I love that. Yeah, yeah, I agree. I think that I've never really thought about Portland in that way as all of the consumer products, but there are quite a few here. mean, yeah, there are. Yeah, that's cool. Nice. Rick Turoczy (23:27) It's crazy. Uh huh. Yeah, it's like you always say you obviously think of Nike just because it's such a presence, but like you just look a little bit, you know, a little bit below that. And it's like pretty much any major footwear company has some presence here. And then I'm again, I'm stealing lines from Mitch Doherty, my co-founder, but he's he's also like, name another. They have another college stadium that's named after a potato salad and salsa company. Like Oregon State is Reese's. It's like, you know, it's just like, there are these random things where you're like, oh yeah, all of our billion, regardless of how you feel about billionaires, all of our billionaires are consumer products people. They're apparel, footwear, coffee. So yeah, it's just, it's a really unique place in that. Brittany Ellich (24:04) Yeah. Yeah. It sounds like it's been a really great community for founders to find a space or anybody really in the startup community, which is awesome because that's something that we desperately need now. You've talked a little bit about the ups and downs associated with being a founder and how lonely and isolating that can be. Is there any part of Pi that sort of focuses on that, like on the mental health aspect of like making sure they have a support system built in? Rick Turoczy (24:47) Yeah, it did become more and more obvious to us that that was an actual issue. And we also had the opportunity to do some very directed work focused on women founders and BIPOC founders, where we found that was even exponentially more apparent than a bunch of white tech bros pretending they're founders. like we... We really focused on making it as safe of a space as we could and ensuring that people felt comfortable sharing with one another in Brad's cohort. We actually, it was our first one, and we actually encountered this issue where the company that Brad would eventually go to work for was like the superstar in that class, and they would show up. to every group meeting and they'd be like, we just raised millions of dollars and we just launched this product, we just did this. And you'd see the rest of the class just go, like everybody be like, I didn't get anything done this week. So we had to like that taught us that it's like, you have to put some guardrails in to say, we love it if you're doing great, but this is really about sharing your challenges and where you're finding difficulties and. We don't want to dismiss that progress, but this should always be someplace where we're looking to improve or work on things. And we continue to kind of refine that model. A lot of my work as kind of just like herding cats, it tends to be like looking towards that negative space of being like. you've been checked out for two weeks, what's going on? Like, do we need to do something to help you? Do we, you know, we had a little slush fund where it was like, anybody on staff could use it if they found a founder was struggling. Like we had a founder who was like feeling, he'd been working way too much, was burnt out. We were sensing that like, It just wasn't healthy. And so we were like, we're going to pay for a babysitter and dinner. Just go do that. Stop thinking about the startup and go do the thing. And, you know, just being open and present to like, these are people trying to build things and how do we support those people? had also pursued it. Speaking of failures, I had also pursued something unsuccessfully that I still think has merit. I think so many programs like ours look for ways to aggregate services in benefit of the startup. So they'll be like, here's a legal team, here's an accounting team, here's a design team. Like these are all the resources that you can use. We had pursued a grant to do the same thing with a professional therapist. Like we wanted to see like if you brought therapy into this environment, would that make for more successful, resilient, kind of formidable founders and companies? We couldn't never get anybody to quite buy off on the grant. Like we got positive feedback, we just couldn't finance it. But I was always curious to see also like which type of therapeutic environment would be best for a Like is it group therapy? Is it individual? Is it like what? So we wanted to test some of that stuff too. And I'm still of the mind that, you know, if a founder has, if a founder is taking care of themselves physically, mentally, emotionally, they have a much better chance of being successful at what they want to do, but they have to have the time. to do that. That can't be forcing them to do all the things. You have to like figure out how to structure that the right way. But it is, it's the most corrosive. Like I don't know why anybody does it. Being a founder is awful. Like it's the worst thing you could do to yourself. adds so much stress. Probably takes years if not decades away from your life. It's just like... It seems it's such a shiny object and there's all this mythology around it about how great it is. And the reality is it's really hard. And that's what continues to motivate me day in and day out. It's just like, it's not easy and no one knows what they're doing. And even the people who pretend they know what they're doing don't really know what they're doing. And so it's just a very unhealthy environment, but it is what it is. Erika (29:24) I almost got the sense talking to Brad, who we talked with. It's Brittany's brother, who was a member of one of the cohorts and a couple of episodes back. I almost got the sense that it's something that he felt like he had to do rather than something he even wanted to. Yeah, so. Rick Turoczy (29:39) Mm-hmm. And I think that's, think that like, as Brad mentioned, like he, I love his trajectory because his, the company he came into pie with failed. Like it failed even though it launched with Google drive. Like Google drive used to think they were going to have an application ecosystem. And so Brad's companies was one of the first companies on Google drive. Like it had a successful launch. It just couldn't make it. And, and yeah, he comes up with an idea. He's like, I got to build this. And, and he also has, I think, I think many people experience that. I think that's one of the challenges is part of the mythology is build it and they will come. just, have to have the capability of building this product. And that draws a lot of people into starting something. And the reality is, If you simply want a product to exist, just go build that product. Like, just do that. Like, if you start a company to do it, then you're building a whole other thing in addition to building a product. So one of the things we always ask founders is like, do you want this product to exist or are you trying to build a company? And the qualifying question there is Let's say we have to kill that product in order for this company to survive. Are you willing to kill that product or is that just what you really want in the world? And that can be one of the things that helps people figure out if they're truly on kind of a startup founder trajectory because startup founders want to build a business. and they will figure out products that make that business successful, but the business is more important than the product. And then unfortunately, if they take that venture capital path, then making money becomes more the focus than even the business or the product. So yeah, there's a lot of messiness there as well. Erika (31:43) really interesting. Well, with your wealth of experience in seeing so many of these startup journeys, what challenges do you see for startups now compared with when you first started in the space? And do you have any predictions on the future of challenges that founders might encounter? Rick Turoczy (32:02) I'll start with predictions because I'm really bad with predictions. don't. I don't have any. I can still remember, like I used to be on the internet when you had dial-up and you had to remember IP addresses to get to anything because there wasn't DNS really everywhere. And so I started seeing this www folder showing up on some of my servers. I'm like, what's that? And people are like, we're going to be able to put images and, you know. colors and things on the internet. I'm like, that's stupid. Text is enough. We're good. So don't take me for any predictions. And then I've forgotten the first part of your question, of course, because I went off the rails like an old man on my other thing. Erika (32:40) ⁓ Comparing challenges for startups that you noticed when you first started with challenges now, how is that different? Rick Turoczy (32:49) Mmm. Yup. Yeah, mostly cultural, I guess is the best way to put it. Like when I started in startups, even into the early pie days, you were still crazy to be starting a company. Like people would be like, why don't you just go get a job? Like, why are you starting a thing that's dumb? so like today, it's like, well today every kid coming up through the system wants to be a creator, YouTuber, whatever, but startups are part of popular culture and we've had like, whatever, 15 years of Shark Tank, like, constantly feeding people that, you should start a company and do a thing. And I think that's become a whole new challenge because of that mythology. So, you know, when we started, it was hard because nobody thought you should be doing that. And now we exist in a world where he's like, well, if you if you're not doing a startup or a side project, are you even really doing anything like and so there have been a lot more a lot more people in in the industry and a lot more folks struggling with things than they did in the past. I think, you know, the other part of it is and I don't want this is not meant to be negative or dismissive like it's a lot easier to build a product these days than it was before. And so that can also be something that kind of leads to issues and problems. I mean, when somebody even like with my lack of technical acumen can spend some time with Claude or chat GPT and code up enough of a thing that works well enough to do the thing I need it to do. Like that's also That's also kind of almost a garbage in garbage out problem. It's like, because the barrier is so low, people may think they have an idea that's viable that's not really an idea that's viable. And so the bigger challenges now are educational dissuading people from taking the track they think they need to take because of what they've heard, because of what goes on in the industry. It's still just, it's still, no matter what people say, it's still hard to raise money. It's still hard to build a company. It's still hard to build a good product. And I heard something really good from a venture capitalist here in town named Diane Freeman who works at Voyager. ⁓ the other day, I thought it was a really important point. Like, no matter how easy it gets to build products, raise money, what have you, you still have to sell the thing and somebody still has to buy the thing. So like that, that remains like a huge friction point that will remain hard forever, even if it's, you know, giving your agent your credit card so it can go buy something. It still needs to be buying something and somebody still needs to be selling it. So it's like, there's just all kinds of facets where one part of it, as one part seems to get easier, the other part seems to get harder and it always kind of balances out. There's always something hard. There's always something that's slightly easier. And, you know, it's just kind of trying to stay up to date. on where those areas of conflict or friction are is the work we try and do with our programs or that we try and bring other founders in and say, based on their experience, like, here's what you might find difficult kind of thing. Bethany (36:27) It definitely makes sense. it's cool that you have a model that will continue to evolve with those challenges as you're moving forward as well. So really, really awesome to hear about all the knowledge you've built up around startups and founders and dive into that. We are coming up at a time, but we typically do a fun segment. So the segment we have today is called Local gems. So since you're passionate about your community, would love to go around and suggest local gems you'd recommend for anyone visiting your city, like restaurant activity, anything in between. As per usual, we'll let you go last so you have some time to think about it. But I guess I'll go first. So I live in Charlotte, North Carolina. And it struggles with the same thing of, I think, finding its identity and trying to figure out who it is, what it is in this, like, as it's growing up. But I would say one of my favorite things in Charlotte is Camp North End, which is a, it's a, used to be like an industrial mill, and they revitalized it to have a lot of like local small businesses and incubate those small businesses, which I really love, there's a lot of chains coming into Charlotte, which is fine, it happens, but I really love that there's a space to really grow what's special to our community. And it's walkable, they plant natural, native wildflowers and things, and it's just a really lovely space. I'll pass it off to Brittany so we split up the Portland wrecks. Brittany Ellich (38:03) Great. My best recommendation that I always give to folks is to this is probably really overrated actually for Portland. I feel like it's really common, but to go to Powell's City of Books, it's an independent bookstore based in Portland and there's a few locations in Portland. I'm not sure if it's extended outside of there, but I know you can also order from them online and it is just one of the coolest, if you like reading one of the coolest places to go. in the world, in my opinion. It's, I think, like four stories tall and it's just filled with books. They have a rare book room, which is so cool to walk through. And it's a very satisfying place to walk around. And they also have some really great like touristy, off the wall sort of touristy things if you want to buy, you know, you know, magnets that aren't just like the I Heart Oregon magnets or whatever, then it's a good spot to go for that too. So that's my recommendation. Erika (38:51) I am not a San Diego native and so I moved here, what is it, six years ago now? But I feel like I'm still discovering a lot of my favorite gems. think currently we've been taking Isabel to the aquarium a lot, which is... sort of a sleeper hit because it's really small. Like San Diego is known for its zoo, which is gigantic and is amazing. But the aquarium is really small and sweet. And in the summer, they're open late. So we'll go and like walk around and she can like see all the fishes and pet the starfish and then like get an ice cream cone afterwards. And it's like been a really lovely like experience for. her as a toddler and us as like, you know, parents trying to corral an energetic and curious kid through the world. Yeah, she especially loves the turtles and I think last time we went she spent about like 15 minutes outside the turtle tank like what they have like a little ledge you know and she was like walking back and forth and like singing a song outside the turtle tank. I was like well that's my child guilty. Good times. Rick Turoczy (40:04) Seconding Powell's is just like it's a full city block of books, like all used. I think they sell some new, but it's a used bookstore. So definitely that. If you come here with kids, go to OMSI. Like most it's the Oregon Museum of Science and Industry. And I think in most cities, the museum that's central to the city is an art. museum and for us it's really OMSI which is experimental and fun. But to pick the like if you you can't go wrong like every five blocks is a new neighborhood in Portland full of like great restaurants and coffee shops and those kind of things so it's really hard for me to pick a favorite but I would say the quintessential coffee shop for Portland right now for me is Deadstock because it's a sneaker themed coffee shop that was started by a former Nike shoe engineer. And it's just really one of those where it's such an interesting cross section of a town that tends to be very siloed in its creative pursuits. Like tons of great food people, but they don't necessarily cross over with the shoe people or they don't cross over with the artists or whatever. And so it's just always nice to see that those two things collide in that place. And they're always everybody from like, you run into elected officials to like, famous people who just happen to be in there. It's just a really interesting place. So I always recommend Deadstock. Bethany (41:34) that sounds so cool. Well, I see ⁓ we should have a Portland meetup in our future, it sounds like. All right. Well, thank you so much for joining us today, Rick. That was an awesome conversation, really interesting. Where can people find you online? Rick Turoczy (41:40) Yes, definitely. ⁓ I'm on the internet like my usually under my last name, which is notoriously hard to spell but like Twitter used to be my big thing and now like it kind of lost the juice so like Unfortunately, it's like LinkedIn or Brittany and I are trying to make blue sky work We're putting our energy into the blue sky. So I'm on there too, but generally I'm on most of the most of the socials and If you're watching this on the YouTube, I'm also on the YouTube on a regular basis. Bethany (42:22) Awesome. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky as well and share with your friends. Until next week, goodbye. --- ## Episode 31: Finding Your Flow - Developer Productivity and The Zone - URL: https://overcommitted.dev/finding-your-flow---developer-productivity-and-the-zone - Published: 2025-10-28 - Topics: Productivity & Learning, AI & Developer Tools, Technical Deep Dives - Audio: https://anchor.fm/s/102586d64/podcast/play/110251654/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-9-27%2F410020934-44100-2-bac4a6d4b1796.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, Erika and Brittany delve into the concept of flow state in software development, exploring its significance for productivity and job satisfaction. They share personal experiences of achieving flow, discuss the balance between challenge and skill, and highlight the importance of psychological safety and team dynamics. The conversation also touches on managing interruptions, the role of pair programming, and strategies for improving flow state within teams. The episode concludes with a fun quiz to engage listeners in reflecting on their own flow experiences. Takeaways * Flow state is linked to enhanced productivity and job satisfaction. * A balance between challenge and skill is essential for achieving flow. * Cognitive overload can hinder the ability to enter flow state. * Immediate control over tasks contributes to maintaining flow. * Psychological safety within teams fosters better performance. * Managing interruptions is crucial for maintaining focus. * Pair programming can facilitate flow but may introduce challenges. * Team dynamics significantly impact individual flow experiences. * Investing in tools and environments can enhance flow state. * Regular reflection on flow experiences can lead to improved productivity. Links * Developer flow article: https://leadership.garden/developer-flow/ [https://leadership.garden/developer-flow/ ] * Podcast: Neuroscience and Developer Productivity: https://podcasts.apple.com/us/podcast/prefrontal-by-cortex/id1760813899?i=1000676601346 [https://podcasts.apple.com/us/podcast/prefrontal-by-cortex/id1760813899?i=1000676601346] * Vibe Engineering by Simon Willison: https://simonwillison.net/2025/Oct/7/vibe-engineering/ [https://simonwillison.net/2025/Oct/7/vibe-engineering/] * SPACE Metrics: https://getdx.com/blog/space-metrics/ [https://getdx.com/blog/space-metrics/] Hosts * Overcommitted Website: https://overcommitted.dev * Brittany Ellich: https://brittanyellich.com * Eggyhead: https://github.com/eggyhead ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host today, Erika and I'm joined by... Brittany Ellich (00:09) I'm Brittany Ellich Erika (00:12) We met while working on a team at GitHub and quickly realized that we are obsessed with getting better at what we do. So we decided to start this podcast to share what we've learned. We'll be taking up everything from leveling up your technical skills to navigating professional development, all with the goal of creating a community where engineers can learn and connect. Today's topic is the holy grail of developer productivity. That is flow state. We know the feeling, we start to work and find some kind of heightened zone of productivity and focus. And for developers, finding this ideal state has been directly linked to work quality, pace of completion, and overall job satisfaction. But what does the research say about this phenomenon? And what can our tell us about how we can harness its power to our advantage. So let's start, Brittany, by talking about flow state. Let's describe what it means for us and what the first things that come to mind of what gets us into or takes us out of this zone. Brittany Ellich (01:24) Yeah, for me, think I am not a psychologist or neurologist or anything. So I really only know, you know, the effect on myself and not the specifics about, know, what it actually means for the average brain. But for me, what it means when I am in flow state is when, you know, time sort of slips away and I'm so focused on a problem that like, you know, you're so engaged and in the zone that everything just kind of comes together. It feels like and. feel smooth and like, you you look up and you're like, an hour and a half has passed and I didn't realize it. That's usually when I feel like I'm in some sort of a flow state. What about you? Erika (02:04) Yeah, for sure. I sometimes have days where I go through the full day and I feel like I've done nothing. And then I have those magical days where I have done everything that I wanted to do and all the CI is passing, my PRs are approved. Yeah, and that feeling of joy and productivity. where things don't feel like a slog, but you're really like cranking and getting things done. Yeah, that's what it is for me. I look at the list at the end of the day and it's all done. Yeah, so I, and you know, full disclaimer, I am also not a psychologist, but did do some research on what the science... has to say about this leading up to this podcast. So did find out that one key to getting into this state is a balance between challenge and skill level, meaning that if you encounter a task or have something to do that's beyond your current skill, you experience cognitive overload. And then if... On the flip side, what you have to do is below your current skill level, you feel boredom. So does this ring true for you in how you've experienced this phenomenon? Brittany Ellich (03:33) Yes, I think, yeah, I think that makes a lot of sense to me in how I've experienced it. I feel like there's this optimal time where I've been in a specific job or on a team for long enough that I know where things are at, but not so long that I know where everything is and I know immediately how to solve problems that, you know, in that sweet spot of I'm still learning, but it's not so hard that I'm getting frustrated all the time is where like I really get into the flow state. Erika (04:02) Yeah, for sure. And I think, like, I definitely recognize the times when I feel bored. And like, those are when I look up and it's been like, you know, five minutes, but it's felt like an hour. It's like really the opposite. I feel like when I do get into those states where like it's a really tough problem and I don't necessarily know how to solve it. like the key thing for me is like having a next step to do. Like if I have no place to turn or I have no like idea of, you know, what tools to use or where to look next, like that's a really frustrating place to be in. And, like that's when I, you know, really start to feel that like headache feeling or like, like deep frustration. But I mean, solving problems is kind of what we do. like, you know, having some level of like, oh, I don't quite know how to do this. Like, that's okay. Like, I don't have to have all the tools at my disposal starting out. But yeah, I think like, for me, what's been helpful in that is like, giving myself kind of touch points of like, okay, I've been at this for an hour. how have I made progress? Have I gone down like a million different rabbit holes and I'm like spinning my wheels or have I like written code that's cohesive and like is actually solving a thing? Brittany Ellich (05:42) Yeah, that makes sense. One of the reasons that I thought about this recently too is I feel like, I don't know if this is actually accurate, but I feel like there are two sort of different types of flow states. There's the ones where I'm very deeply in a specific problem and I'm like wholly focused on solving this one thing. And then there's another type where I'm just multitasking so much that it also feels like a flow state. And I noticed this recently because I've been working really hard on using the coding agent to solve small problems within our code base, just to test it out and also, you know, to knock out tech debt, all sorts of different things, test this new way of working. And usually that is a bunch of really small problems at once. And while I still feel like I'm very focused on those things, but I'm like changing context so quickly that it almost feels like a flow state as well, but it feels very different from like fully focused on solving this one problem end to end. I equate it. I remember when I used to work at Starbucks and I noticed that it feels very similar to when I would like work on the bar and make drinks like so quickly that I was like looking at the next like five or six drinks in a row and like optimizing and synchronizing my time so that like I would move so fast to get all these things done. It feels like that. Erika (06:55) I won. Brittany Ellich (07:02) which is also like very cognitively taxing, like being in, you know, a flow state could be otherwise, but I think it's, it's, it's interesting that, you know, we're moving towards this new way of working where we have agents for coordinating. and it's, I wonder if there's like a different thing that's happening. what if there's a different flow state there? I don't know what your thoughts are. Erika (07:02) Yeah. I can definitely identify with that and I almost think that the cognitive challenge there is time management or like task management. Like you're not necessarily focused on the tasks themselves, but you're like focused on how you can get like the most amount done in like a given set of time. Yeah, so I think like I... I have had that experience too, where I'm like, oh, let me try to offload this, yeah, like tasks which might take me out of my problem solving context. Like, let's see if we can automate this and yeah, like I've also felt that kind of like thrill of, hey, cool, it worked. Like I told it to create, I don't know, 15 issues and like. It did the thing. Yeah, there's also the flip side where you're like, I told it to do this thing and it totally backfired. Like, oh no, I have to like go clean up the mess. yeah, as long as it's reversible and like, you know, it's a pretty low risk thing. Like, it's not necessarily a bad thing. Like you tried something, it didn't work. Brittany Ellich (08:43) Yeah, that's why version control exists. know, it. That's in place. You can always just get rid of it all and start over, but yeah. Erika (08:46) Yeah. Yeah, well, and it leads to some other factors that research has identified are important to flow state, one of which is immediate feedback, clear goals, sense of control over the task. So in development, this means knowing exactly what you're trying to do. So like whether that's in code or like automating, like how do you know the thing is done? Like is that clear? Is that not clear? And yeah, I think like the idea is that in a flow state, like if whether you're automating or coding, like you can know pretty quickly like keep or leave versus like, I don't know if that was the right thing or like, I have to go back and like re-contextualize. Yeah, having control over the task, like, I guess knowing that like when you do something, it will... like apply correctly, I guess. Like if I make a PR, like maybe it might not get accepted. And like that can be frustrating. Or yeah, like coding requires a lot of collaboration. And so to a certain extent, that like is a lack of control. But like when you open up a change, like you're the driver of that change. But yeah, in several studies, the whole review process is cited as something that can really like take you out of flow state where you land in the like purgatory of reviews of nitpicks and no one approves it or no one, know. And it's like that can like that in itself can kind of be like. demoralizing and take you out of your flow. Brittany Ellich (10:58) Yeah, yeah, that makes sense. There was an article recently by Simon Willison, trying to recapture the vibe coding term and calling it vibe engineering. And one of the things called out there is how important it is now with, you know, when you're using agent tools, whatever they may be to make changes, to have like a really good preview environment or staging environment. So you can quickly verify that those things actually work. And I thought that that was really interesting. to think about, because I've noticed that too. That's a thing that I want to invest in more in the codebases that I work in, because I want to be able to ship this quickly and actually see what it looks like so that I don't have to open up a codebase and actually check it all out and make sure it all works. So yeah, good feedback definitely makes sense. I also kind of wonder as we spend more time working with AI tools to, you know, build things, build everything, how the code review process might end up changing too. Like, are we going to need a review from somebody else on our team? Like, does code quality matter as much when, you know, you have a bunch of robots writing the vast majority of the code that you're writing? Like, does code quality actually matter that much? Like, do those nitpicks, are they still as valid? And is readability still as valid when you can like use tools to help you interpret what? complex code is doing. ⁓ Yeah, so I wonder if we might optimize more towards like removing more of those checks so that people can move things more quickly and get more of that feedback. I don't know if I'm advocating for it either way, because that also sounds really scary. But I don't know, just a thought experiment recently on like how the world of software engineering is changing. Erika (12:17) and sorry. Yeah, yeah, I mean, I know what you're saying. Yeah, I think that there's also an idea of healthy friction and I think an example of being empowered to make a change is like a system change. you have to request access to something to make a change. Okay, is that an extra step? Yes. Like, is it an important step in some cases to like prevent crazy production changes? Like, yeah. Like, and arguably like the most important thing there is like auditability. And like kind of to your similar point of like the most important thing for any code is that like it can be maintained. Whether that's like through me reading it directly and like... understanding what it does or me asking a coding agent or like an LLM to interpret it for me. Like the important thing is that like I know what it's doing and probably even more importantly that it's like doing what it needs to do. So yeah, like the how we get there. It's like, well, it kind of depends, I guess. Like I would imagine that like I don't know, I'm trying to think of situations where readability is a trade-off I'd be willing to make. I feel like in a personal project where no one else has to read it. But that's kind of existing standards for me. I feel like anytime someone else would have to read what I do, readability is key. I guess, because also like coding bots or whatever, like pick up on the same context clues. Like if it's like, yeah, the devil's advocate is like, if it's not readable to a human, it's probably also not really readable to an AI. Yeah. But yeah, what other, what other kind of like tooling do we think of as like helping or hurting? Brittany Ellich (14:41) Yeah, it's true. That's true. That's true. Erika (14:51) flow seat. Brittany Ellich (14:53) Mm-hmm. That's a good question. think for me, feel like I, habit is really important. That's not really a tool, but like there are tools that I use to build habit. Like there's a specific Spotify playlist that when I listen to it, I am so much more likely to like get deeply into focus mode than if I don't have that available to me. Same with like wearing these headphones that are like noise canceling so that it's not like there's a lot of noise around me, but it like. Erika (15:13) Hmm. Mm-hmm. Brittany Ellich (15:23) you know, get sort of all the street noise and everything. And so like, I think that's really helpful. At least for me, it's probably very individual. Cause I know some people focus better, like sitting in a coffee shop or sitting, you know, whatever it is that helps somebody focus. Erika (15:38) Yeah. Yeah. Yeah, that's interesting. Like your environment. Yeah, I'm very sensitive to noise. And I like having like a very quiet space, but having like certain playlists that I listen to. I don't think I have one playlist specifically, but... depending on my mood, I'll listen to something that like either matches my mood or like if I'm really low energy and I need something that kind of like boosts me, I'll put on some something like higher energy. Yeah. I guess another thing that comes up a lot is interruptions and like we use Slack. So How do you find that that like affects your flow state and how do you manage that? Brittany Ellich (16:31) Yeah, that affects it a lot because I have FOMO. And don't want to miss anything that's happening in Slack. I've made a few changes to Slack there recently. Like I have turned off all sound notifications and for the most part, most like of those, I don't know, desktop notifications. Usually I don't see them because they're on my laptop, which is, you know, away from like my main, main monitor that I look at. But I try to reduce those so that I don't get interrupted. And that's been really helpful. It's hard though, because there's so many channels at any large company and there's so many things to pay attention to that it can be really hard to make sure that you don't miss anything while also, you know, make sure that those things don't interrupt you. Sometimes I'll do like the whole like note turn notifications off and that can be helpful too. but yeah, what about you? Erika (17:13) Mm. Yeah, I feel like I... I keep my notifications on with Slack for the off chance that somebody needs me urgently. And I feel like that's always the thing that goes in my mind is, is there something going on and I'm the only one who can respond and it's like urgent. Like I need to respond right away. And the number of times when that has been true, I don't even know if it's literally ever been true. Like it is such. Brittany Ellich (17:45) Yeah Erika (17:47) such an outlier that like, it's a really dumb reason to like keep Slack so constant in my life. And I feel like the other problem I have with Slack is those moments of boredom where I'm like only half engaged in a task and then I'm like, I'll check Slack to like see if there's anything like more important or like more interesting going on. And then I get like sucked in and like checking every channel But it's like this balance where like you said like you do have to know what's going on you can't like be living under a rock But you also like really can't get meaningful work done Unless it's communication like if there's something that needs to be communicated or figured out like slack is the place to do it But like there's so much there that I don't actually need to engage with. ⁓ Brittany Ellich (18:46) Mm-hmm. Yeah, I had to really get over my fear of having unread notifications with Slack. I think for a long time I was like, I need to check every single channel. And recently I actually made a change where I found the maybe five-ish most important channels. And there's an ability to set a notification where I don't have the sound ones, but I have a notification that goes off in Slack when Erika (18:52) Mmm. Brittany Ellich (19:11) a new message is sent to those channels. And it also adds the little like red bubble next to them so that like I can have all of these unread channels. They all look the same. But then like the really important ones when I get new messages there, then they have that little red bubble. And I'm like, OK, I need to go actually check those and the rest of them. I can look out whenever or just Mark always read. Erika (19:17) Thank Yeah, yeah, yeah, that's definitely, I don't think I have like quantified the most important Slack channels to me because I do feel like it's also dependent. Like if an incident happens or like if I'm on a project, like that then becomes the most important channel. But like that probably maybe is a good habit to get into of like having a priority section. Like, um. being like, okay, at this point in time, like maybe once a week or something, like this would be interesting to try. Like, at this point in time, these are the five most important channels to me, and then like everything else, I can check it when I check it. ⁓ Brittany Ellich (20:12) Yeah, that's part of my on-call, like going on-call thing too, is I like turn off all of the existing ones and then turn on all the on-call channels that I know I need to be in. That also lets me like turn it off at the end of on-call and like unplug from being like the first responder for issues. ⁓ That's also helpful, I think. Erika (20:21) Thank you. ⁓ Yeah. Huh. That's good. I'm going to steal that. Yeah. Cool. Yeah. So I guess also, like, we've talked about flow state as, a personal, like, individual experience. But is it something that can happen in collaboration? Like, Brittany Ellich (20:35) Yeah, please do. Erika (20:53) Have we ever had the experience of like pair programming and getting into a flow state? Brittany Ellich (20:58) Yeah, I think so. depends on who the person that you're programming with is probably. I think it's probably more likely if you're using like really collaborative tools like Live Share or something like that. If I'm just watching somebody else program, like my ability to pay attention is pretty low. So if I'm driving or there's some sort of like Live Share involved where I can also like be in the code base at the same time, that's helpful. I like. Erika (21:14) Uh-huh. Brittany Ellich (21:23) pair programming in general. think it's probably hard to like reach that flow state while pair programming, but I think it's, I think it's fun and it's nice to do it to for like knowledge sharing and for other reasons. What about you? Erika (21:34) Yeah. Yeah. So like, to be fair, like sometimes, sometimes the beauty of pair programming is like introducing that friction in real time. so like, think sometimes like flow state in pair programming is actually an anti-goal where like, if it's, cause I guess like part of the idea is your code at the end of a pair programming session. is higher quality than it would be if you worked by yourself. And it might take longer to get there, but maybe you have somebody who's always checking and providing suggestions. And those things take you out of that state, potentially, of pen to paper, everything flows. But the code might actually end up better. But I think I have had experiences where maybe like I know one thing and the person I'm pairing with knows the other thing. So like alone, that task would be maybe like too hard for me or something like that. And when I'm pairing, like we end up getting into a really good flow or on the opposite side too, like maybe something's kind of like mundane for me. But the person... I'm pairing with doesn't know how to do it. so then the like challenge is teaching. Like it's like a learning moment kind of a thing. And so it can feel more like a flow because, you know, I have to think about how I'm communicating and and that kind of stuff. Yeah. I don't like the first thing I think of, but I think it's definitely possible. Brittany Ellich (23:16) Yeah, yeah, I can see that. Erika (23:18) Yeah. Well, cool. Yeah, I think the science also talks about like other social dynamics that can encourage or discourage flow state. Some of these are like that familiarity, the interpersonal nature of any collaboration that you have, your physical environment, and then also psychological safety. And this is the idea that you can take risks and it'll be okay. So that can contribute to like anxiety and pressure and stress when it's not present and those can be detractors for that flow state. I think mostly because you're focusing on that. instead of whatever the task is at hand. Like you're worried more about how something will come across or whether like, whether it's wrong, whether you're gonna, you know, get fired versus like, how do I solve this problem the right way or, or even feel comfortable like taking time to understand it. Like if you feel like you're always under pressure, always under the gun. Like maybe you don't feel like you have the time or the space to ask questions or like understand what you don't know to like get to that point where your knowledge or skill level meets the task. Brittany Ellich (24:45) Hmm. Yeah, that's a really good point. And yet another reason for making sure that you like are investing time in those psychological safety things for like your whole team. Cause then you can really unblock the rest of your team by making sure that people feel comfortable with, you know, saying like, I have a stupid question. Erika (25:04) Yeah, yeah, and like, I think it's important to also know when to cut it off, right? Like, if there's somebody who's like always spiking or always, you know, doing little things that, like never actually getting anything done because they're always trying something, like, maybe we need to find like a middle ground, like. Brittany Ellich (25:31) Yeah. Yeah, I feel like that resonates too, because I've definitely been on teams before where like the entire team is just really productive as a whole. And so I wonder if that's because like that psychological safety is built in to where, you know, people feel comfortable enough to be able to like actually perform much better than they would be able to otherwise. and then I've also been on teams where that's not the case. and the opposite could be said. So yeah. Erika (25:58) Yeah, I feel like I'm like experiencing that now with my current team where we're like relatively, I want to say relatively new. We've like been in our current state for about like six to eight months. And it's kind of surprising to me that like only now do I really feel like we can have a lot of like open honest conversations about like Brittany Ellich (25:58) That's really interesting. Erika (26:25) what is and isn't working. Like we don't need to be overly nice to each other or like protect each other from being like, but why? Or, you know, pushing the boundaries of like decision-making and also kind of like understanding how each other think to like read the subcontext. So yeah, it takes a while. Brittany Ellich (26:51) Mm-hmm. Yeah, that's a, also a good point. feel like for like, why, like changing up teams are like consistently reorg ing is probably setting some companies back too, because as those team dynamics are really important too, for feeling that psychological safety. And if that's, you know, important for doing your best work, then constantly changing up the structure of the team or like constantly having the threat of layoffs is probably impacting the entire organization as a whole. negatively. Erika (27:24) Yeah, I wonder if there's been any studies around that or changes and layoffs and the impact on productivity. Brittany Ellich (27:28) Probably. There has to be, I'm sure we can. I don't wanna speak without actually knowing that that is the case, but I'm reasonably certain that there's some ties there. Yeah, it'd be interesting to go look up. Erika (27:39) Ha Yeah. Yeah. Okay. Follow up. cool. Well, all, yeah, I'll throw out a few other ideas that, have been suggestion suggested for, like things to try to improve flow state. So one idea is this idea of 15 % time, which means dedicating like a portion of every sprint to self-directed learning or exploration projects. So that's a way to find that. Find that balance between like executing and getting work done and like building up the skills and the knowledge to do what you're interested in. Having no meeting blocks of two to four hours. Having integrated development and testing environments. So kind of like you were talking about being able to quickly get that feedback loop of whether what you did worked or not. preserving context across sessions. So like not needing to build up what you learned previously or for someone else that you're working with. Like yeah, like that time waste of rehashing what's already been figured out. And then some ways to consider the impacts or measure the impact. is reduction in cycle time, increased reported focus time, satisfaction and engagement, and bug rates and rework percentage. Yeah. Brittany Ellich (29:04) Wow. I feel like a lot of those really fit into a lot of those like developer productivity metrics to like space and can't remember what the other. work and bugs, like that's a sign not only that you are having trouble with, you focus, but also that like the entire organization might be, you know, there might be evidence that the entire organization is less healthy than it could be and not able to get into that state. Erika (29:32) Yeah, yeah, a couple of the things that I read mentioned like Dora metrics, which I think is along the same lines. Cool. Well, thanks for chatting about this. This was fun. Yeah. So for our fun segment, I came up with a Cosmo style quiz about flow state. ⁓ So since it's something we all love, the quiz is titled, are you a full flow state flirt or a full blown in the zone lover? Brittany Ellich (29:45) Yeah it was. It was good. Yes. Erika (30:08) Very causal. So we have some questions and all of these are A or B questions and we'll count up our scores and then tally them at the end to see where we fall. All right, question number one. You just fixed a huge bug. How do you feel? A, totally zapped, need a break to recover or B, energized, ready for the next challenge? Brittany Ellich (30:10) It is, yeah, that's amazing. Okay, am I keeping track of them myself? Is that the goal? Erika (30:39) I can keep track of them. I'm going to say A for me. Okay. Brittany Ellich (30:42) Yeah, same. Erika (30:44) Next question. Your ideal work music is? A. The latest trending songs with lyrics or B. Non-lyrical, repetitive music that fades away. Brittany Ellich (30:55) definitely be for me. Erika (30:57) Yeah, me too. I have trouble with lyric songs. All right, question three. A coworker pops over for a quote, quick question. Option A, I stop what I'm doing and give them my full attention. Option B, I politely point to my headphones and keep coding. Brittany Ellich (31:14) I would say probably B because that's effectively what I'm doing by turning my Slack notifications off. And that's like the closest that I come to having a coworker come and bug me right now. Erika (31:26) I can't stop myself from answering people at this point in my life, so I'm gonna say A. All right, how long does it take to start writing meaningful code? Option A, 30 plus minutes, gotta check email, Slack, and news. Option B, five minutes, I get straight to the preselected task. Brittany Ellich (31:31) Mm-hmm. Oof. Is this like at the beginning of the day? Erika (31:51) I guess so. Brittany Ellich (31:52) Yeah, definitely. My first hour of the day is just not productive at all, usually. Erika (31:56) Ha! It really depends on the day. I'm gonna also say A though. That feels more right, well, more of the time. Brittany Ellich (32:05) Yeah. Erika (32:06) Okay, question five. When tackling a huge feature, you hop between small different tasks when you get stuck. Option B, break the large problem down into small, clear sub goals. Brittany Ellich (32:19) B for sure. Erika (32:21) same. Okay, question seven, your notifications are set to all on. I check them as they come in or option B, do not disturb for blocks of 90 minutes or more. Brittany Ellich (32:33) Be. Erika (32:34) Yeah, I'm gonna have to say A. But I'm gonna change this. Brittany Ellich (32:39) Yes, now you know the, it's worth it. It feels really nice to just be like, you know what? I'm not that important. Yep. Erika (32:42) Yes. in the jacket. Okay, we're almost done. When you hit a frustrating complex error, you immediately jump to stack overflow for a quick fix. Oof, this is outdated. Option B, I lean into the puzzle, the difficulty is the reward. Brittany Ellich (32:58) you Hmm. What's stack overflow again? Just kidding. I would say probably A, if we're replacing that with like going to, you know, whatever your tool of choice is. I go to copilot when I get stuck on something pretty quickly, but I don't know that that's, I would argue that that's not necessarily taking you out of flow state. That's just like a part of it. Erika (33:08) Yeah. Yeah. Yeah. I usually at least like stop and think about it before I ask Copilot. So I'm going to say B. Brittany Ellich (33:32) Mm hmm. Yeah. Yeah, I'll go with that too. I don't immediately ask. Yes, B. Because sometimes, you know what? Sometimes you just need to actually read the error message and it will tell you exactly what's wrong. And it's, yeah. Erika (33:40) Okay. Yes. Yeah. All right, last question. Do you have a pre-flow ritual? For example, getting coffee or reviewing to-do lists. Option A, no, I just dive in and see what happens. Option B, yes, I have a five minute routine to mentally cue deep work. Brittany Ellich (34:05) definitely B. I don't know if it's exactly five minutes, but yeah, I spend a lot of time like organizing my to-do list and getting everything perfect. Optimal amount of caffeine. It's a whole, it's a whole thing. Erika (34:07) Yeah. same. Okay, we have our answers. So I will ask you to tally your own score, because I can't. Okay, I'm going to count mine, you count yours. And I think we're only counting the bees. Yeah, okay, we only count the bees. Brittany Ellich (34:23) Okay. Okay. Erika (34:34) Okay, and I think this is also a little skewed because I took out a few questions. So how many did you get? Okay, so you are a full blown zone lover. You are a focused champion. You've mastered your environment and see challenging work as a reward. Your biggest risk is burnout. Brittany Ellich (34:46) I got six. Yes. Erika (35:02) make sure you schedule intentional breaks. And I think it's the Slack notifications that got me. I am a flow state flirt. You felt the magic, but distractions are winning the battle. Focus on reducing friction and setting a clear non-negotiable focus block every day. You're close to unlocking peak performance. Brittany Ellich (35:22) That was amazing. We're gonna have to post this survey for everybody to be able to enjoy this as well. I wanna hear what everybody else's answer is. This was so good. Erika (35:30) Absolutely. Yes. Well, awesome. Thank you, listeners, so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. And until next week, goodbye. --- ## Episode 30: What all developers should know with Thomas Dohmke - URL: https://overcommitted.dev/what-all-developers-should-know-with-thomas-dohmke - Published: 2025-10-21 - Topics: Career Development, Leadership & Management, Open Source & GitHub, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/109841567/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-9-18%2F409483564-44100-2-81709993162bc.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, host Brittany Ellich and co-hosts Bethany and Erika welcome Thomas Dohmke, former CEO of GitHub. They discuss Thomas's journey in software development, pivotal moments in his career, the importance of passion and continuous learning, and advice for overcoming career stagnation. The conversation also touches on the future of software development, particularly the impact of AI, and concludes with a fun round of questions about LEGO. Takeaways * Thomas grew up in East Germany and discovered coding through a school lab. * His passion for software development has been a constant throughout his career. * Mentorship played a crucial role in his transition from university to the automotive industry. * The importance of continuous learning in a fast-paced tech environment. * Developers often feel stuck in their careers, but a growth mindset can help overcome this. * Asking for help and having open conversations with managers can lead to new opportunities. * Reading books on engineering and leadership can provide valuable insights. * AI is set to revolutionize the software development landscape again. * The journey of a developer is filled with ups and downs, but passion keeps them motivated. * Thomas encourages developers to embrace change and stay curious. Links * Thomas on GitHub: https://github.com/ashtom [https://github.com/ashtom] * Thomas on LinkedIn: https://www.linkedin.com/in/ashtom/ [https://www.linkedin.com/in/ashtom/] * Thomas on X: https://x.com/ashtom [https://x.com/ashtom] * The Great Mental Models book: https://www.goodreads.com/book/show/44245196-the-great-mental-models [https://www.goodreads.com/book/show/44245196-the-great-mental-models] * An Elegant Puzzle by Will Larson: https://www.goodreads.com/book/show/45303387-an-elegant-puzzle [https://www.goodreads.com/book/show/45303387-an-elegant-puzzle] * Staff Engineer by Will Larson: https://www.goodreads.com/book/show/56481725-staff-engineer [https://www.goodreads.com/book/show/56481725-staff-engineer] * The Engineering Executive's Primer: https://www.goodreads.com/book/show/199699997-the-engineering-executive-s-primer [https://www.goodreads.com/book/show/199699997-the-engineering-executive-s-primer] * Bricklink: https://www.bricklink.com/v2/main.page [https://www.bricklink.com/v2/main.page] Hosts * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host, Brittany, and today I'm joined by the rest of the crew. Bethany (00:09) Hey, I'm Bethany. Erika (00:11) And I'm Erica. Brittany Ellich (00:13) 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've learned. 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 Thomas Domke, the former CEO of GitHub. And he recently left to go back to founder life and is currently working on a stealth startup. Thomas Dohmke (00:42) You Brittany Ellich (00:43) Thomas hasn't just led one of the most important platforms in the world, not that we are, you know, biased there. He's also a developer at heart with a passion for helping engineers grow, ship better code and stay curious. We're diving into his journey, the lessons he wishes every developer should know and where he thinks we should all be focusing our energy in this fast moving industry. So let's get into it. Welcome Thomas. Thomas Dohmke (01:06) Hey everybody, and I loved how you made air quotes for those without saying air quotes to stealth startup. It's actually a stealth startup. So great to know, but like, you know, it's a proper term in the sense of, you know, not ready to talk about what the startup is doing, but anyway, so great to be here and to be with Hubbers again. It's been two months, a little bit more than two months that I announced my departure. And so it's great to be with you all today. Brittany Ellich (01:10) You Okay, is that the title? That's awesome. Yeah, thank you for joining. Yes, I did not know that that was an actual term. We've had a few startup founders recently on the podcast because none of us obviously work in the startup world currently, and it's been fascinating to learn a lot about it. It's been really cool. So what was your overall journey in working into software? What's your story up until now? Thomas Dohmke (01:49) It's a long story, so let me make it quick so nobody gets bored about hearing this for too long. I grew up in East Germany when Germany was still divided into two countries. In East Berlin, in the 80s, I couldn't just go and buy a computer because they weren't available in stores in Germany. But I found computers with a friend of mine in the geography lab of all places in school. was a... East German clone of a Z80 computer, so like a microcomputer. And we started coding in basic. I think it was still had a cassette tape, if I remember correctly. And then the wall fell and I got a Commodore 64. And as most kids, you know, that get into coding, I started just playing around on a mix of playing computer games and then when mom and dad said game time is over, then I was like, well, I'm coding. So that's not really screen time because I'm learning something. And, know, back then the Commodore 64 was connected. to little tiny TV, right? Like we didn't have these fancy screens that we have right now with high resolution. It was like a crappy TV that you were looking into. So I could actually make an argument that you are way too close in front of that small, you know, whatever 10 inch TV or so. you know, learned, taught myself basic and bought books and magazines, got a PC, taught, learned more, and then went to university and learned a lot about, you know, the internet at that time, because this was the new thing. And I had, think I had an AOL account first and school had some access, but it was super slow and super crappy. But it also was like this wide open world where all of a sudden you could chat with other developers and learn about how they're doing things. And the first open source I had was Linux, SUSE Linux, I think 5.3 or something that I bought in a bookstore in Berlin. And so, you know, from that journey, we, I, I always wanted to become a software developer. I knew this was like my passion. it was so cool to create something out of thin air, right? Like you didn't have to buy a 3D printer, which wasn't a thing either, but again, it didn't have to buy a machine. You didn't have to buy, you know, complicated equipment. You didn't have to hire people. You could just start coding, build something, share with other people. And that passion kind of like has followed me through my career, whether it was in the automotive industry at Mercedes and later at Bosch or whether it was my own startup called HockeyApp that Microsoft acquired. And then for the last seven, seven or so years at GitHub, um, where I think, you know, I had found my dream job. It was being the CEO of a company, uh, that develops software for software developer, kind of like the Home Depot in the software development world, right? Because I think most folks, when they go to Home Depot, they, they appreciate not only that they can buy tools, they also find other nerds. And that's, that's in a way what GitHub is today. Brittany Ellich (04:19) I love that description, that's amazing. I'm gonna steal that to describe it to other folks. I feel like everybody that I talk to that I work with, or that I, you in my family, they either know, like they ask where I work and they either think it's like, like GrubHub, or they're a software engineer and they're like, yeah, I know GitHub, everybody knows GitHub, so it's big divide I like that. Were there any pivotal moments in your growth to where you were like, hey, this is the career for me. This is the thing, like a project or a mentor or anything that, you know, stands out to you. Thomas Dohmke (04:49) A bunch of those, actually you mentioned mentor, that was probably the first one. So I was in university in Berlin building software for robots that would drive through the building. And that was, you know, the late 90s, early 2000s. So the robot was like, not that fancy at all. looked like a half a table, with sensors stacked on top and computers, you know, in the rack on the bottom, like literally like, you know desktop computers as part of the robot. And I had a mentor at back then, Daimler-Chrysler today, Mercedes-Benz, and he visited me in university and was like, why don't you come to Stuttgart, which is, you know, about 700 kilometers away from Berlin and southwest of Germany. And instead of building robots, you can write software for cars for the Mercedes S-Class at the time and have it drive around autonomously. And I was like, yeah, that sounds cool. And so I moved my life from Berlin to Stuttgart and joined Mercedes at that time. And I knew nothing about the automotive industry. other than what I've heard about my mentor and obviously had been to like a factory seeing how that works. And that's kind of like a to-do thing if you are the bucket list thing, if you, if you have a mentor and you get kind of supported by an automotive company. And so I think that was a pivotal moment because all of a sudden I came out of my university environment into, into, you know, real life and software development and cars, especially back then, or in the early 2000s was very basic. Like the, the control units had a CPU and memory as little as the Commodore 64, even though it was now 10, 15 years later that most people would use a Commodore 64. Every button, every user interface element in cars back then was a question of how much money does it cost to add the button and how much complexity does it add to the car? Today it's much easier as most cars have a central screen that is like a computer. And so I learned a lot about that. I also learned that That's not for me for in the long run. And so in 2008, when Steve Jobs showed the iPhone SDK, you know, about a year after the iPhone had come out and I was an original iPhone user. That was, think, the second pivotal moment of my career because I decided I had enough of the automotive industry. was done with my PhD thesis that I wrote about automotive control systems. And I was ready to move on and that there was the financial crisis, you know, in late 2008 and that didn't stop me. from deciding I want to become an independent software developer. And so I left my well-paid job at Bosch to jump into the life of an indie developer building apps for mostly German companies. In that day and age, most of the apps that you would build as a consultant was like tiny apps, finding gas stations or like a front end to online banking. But it's really just a frame to web-based experience and what have you. But that, you know, in itself then gave me the opportunity to build HockeyApp, which was a mobile development platform which got acquired by Microsoft. You know, that in itself was a pivotal moment as it moved my family and I from Stuttgart to Seattle. And then obviously the GitHub deal in 2018 when not only, you know, did we decide at Microsoft to buy GitHub, but my former manager, Nat Friedman, who then became the CEO, pulled me into that deal. And kind of convinced me that my career at Microsoft as a director of product with, I don't know, 25 or so people working for me was not as important as, you know, joining him with the GitHub leadership team through the deal and just, you know, jump into the cold water of that adventure of an independent GitHub within Microsoft. Bethany (08:13) That is really awesome. It's so cool to hear about the journey through different industries and how that all leads up and builds upon your experience and how you act in a certain role. I'm curious if there are any skills or habits that, through these industries, might differentiate the truly great engineers or the folks that you really enjoyed working with. Thomas Dohmke (08:37) The first thing that always comes to my mind, if I look back on the 30 years or so that I've been coding and fun from one another, it's the passion for doing that and passion for software development. It's not always easy. One of the jokes I've made a lot over the last three years is that the happiest day of a developer is when they start a new project, file, project new, and then it's all downhill from there. And in that moment, you're excited. Everything is greenfield. You can try out a new language or a new component, new open source library or new design pattern. And then, mean, you all know what that's like four weeks later, you're like, shit, you know, this doesn't actually work. And the technology is not as mature as we thought it would be. And then you have to deliver the bad message to your manager that you effectively wasted four weeks or wasted, you know, air quotes. Obviously it's obviously a learning opportunity. But I think the passion is what defines this role as the industry is moving so fast all the time. Right. And I think that's number two, you have to constantly learn. There is no stable state unless you want to work on COBOL and mainframes for your whole career, which you certainly can. I think most developers want to stay at the top of the technology. That means learning, learning, learning. And I remember leaving university and thinking, I'm done. I can focus on doing stuff and building and not so much on learning. think that's like, you already quickly realized that's not actually how the industry works. And soon enough you are surrounded by people that are hopefully smarter than you and tell you, you know, how to do certain things and teach you things. And you're like realizing, okay, I need to start reading certain blogs or, you know, catch up on the technology or maybe get over myself and figure out that the programming language I love isn't the one that the team is using. And I don't need to argue about that. Maybe you argue with somebody else on this podcast about who we were the school or something like that. But I think learning is super important. And then You know, for me personally, there was always a bit of what decisions do I make that may be counterintuitive. I mentioned already one, which is like leave my career as director of product management at Microsoft behind to become VP of special projects at GitHub, which really was a role that didn't mean anything at the time. It was just a question of, I join with Nat, the leadership team? And he was like, we will come up, you know, with the things that are important for the company to push forward. And it's going to be fun. trust me, know, He said to me, trust me, it's going to be fine. And obviously, three years later, when I became the CEO, he proved himself right, or he proved it to me that he was right and that it led me on the right career path. But I think it's these making these decisions at a time when you don't have all the information, when you have to, to a certain degree, trust your gut. And that's true for a career as it is true for architecture. You can have all the arguments in the world of whether this is going to scale to a hundred million users or a billion users and so on. It doesn't really matter. You're always going to run into scale challenges. You're always going to run into outages. I mean, we all know what that is like on the GitHub site. so you have to trust your gut and you have to trust your feelings. And then of course, you have to build out your experience and craft. Bethany (11:31) That definitely makes sense. It definitely seems that that passion and the learning is just so important for continuing and staying relevant in the industry. But also just when you enjoy your job, it is so much easier to do well in that space. So that definitely is good advice. Thomas Dohmke (11:44) Yeah. Or, you know, just wake you up on a Monday morning and be motivated to go into your job when you have to pick up, you know, an item of from GitHub issues that isn't as exciting as, building a new feature. mean, you all have been in different teams at GitHub. It's not always the most exciting stuff that comes along in any given week. And so if you're passionate about software development, if you actually enjoy, you know, writing software, it doesn't really matter what feature you're building, right? It matters that you enjoy doing it. Bethany (12:14) Absolutely. It definitely does feel that way to me and I don't know about the others, but I think it was just so cool how people use GitHub. It means something to people even when they're upset through issues and things like that or there's something wrong. It means people truly care about the platform that we're building and believe in it. it is a cool thing even when there are those rough issues and rough days, for sure. Thomas Dohmke (12:26) Yeah. Yeah. Bethany (12:40) I'm curious if, I mean, being in so many different spaces of what you're working on, do you have any advice for people who might feel stagnant in their career or who are stuck at a certain level or in a certain niche and might want to break out of that? Thomas Dohmke (12:55) Yeah, I mean, I think, you know, it's, it's always challenging if you feel like you're stuck because you have to convince yourself that there's something else there first, right? That's the first rule of having a growth mindset is to admit to yourself that we, every morning or so that we have some degree of static mindset. We are all, you know, being raised in some form of you're good at something and not good at other things, right? Like you hear that so much and you hear people talking about themselves in that same way. And that's a clear sign of you having a static mindset instead of saying, Okay. I can improve myself. I can, you know, get out of this situation where I'm stuck and I can get over myself and maybe have a conversation in a secret Slack channel, or I have a conversation with your manager and, and, you know, be open-minded and saying, Hey, I feel like I can no longer progress here. what advice can you give to me? And I hope, you know, for most folks, that is the first step that they're taking. without looking for a new job in a different company or in a different team to have that open conversation with the manager. So that relationship that is so crucial is given the right amount of trust. And the manager might actually be cool and say, yeah, maybe a billing team has new opportunities for you or the Azure AI Foundry team over at Microsoft is the right place for you. And look, I've been through many stations in my own career from a student to a big automotive company, to a big automotive supplier, to a startup, Microsoft and so on. It is cool, know, it is absolutely valuable to switch jobs and see what life is like. But you also need to realize that every next company they're joining has their own set of problems. And they might not show those problems to you while you're interviewing, but certainly you will find out in your first or second week, because it's the nature of our jobs, whether that's in engineering or leadership is... Your job actually is to solve problems. Building a feature is just a different angle on a problem. You know, it's a nice problem to have kind of like, but the most of the time we are solving really hard problems and you're never going to run out of problems. You're only going to hopefully at some point retire. But everybody deals with their own set of problems. That is the nature of, you know, the work that we do. Erika (14:58) Let's take that idea and turn it into kind of a hypothetical of if you could go back and give your former self like any advice about growth, development, learning software, what comes to mind for you for anything that would have been helpful for you to hear from what you know now. Thomas Dohmke (15:18) think most people that go, you know, through their careers, you know, when they're from the, the first day as, as, as a professional software developer or whatever they're doing, product manager, designer and so on to where they are right now. And they have a level of anxiety that comes with that, you know, in the early, when you join a job, you're worried about what is everybody thinking about you, right? Like you're joining a team of people and whether you're the most experienced person in the world, or you're just coming out of college, you're you're still thinking about how everybody else is thinking about you. That's, think, part of the human nature. And I've been, you know, when I talk about AI and copilot, the nice thing about asking questions to copilot or ChatGPT or any other AI tools is that it doesn't judge you. You can ask it, you know, an infinite number of questions and you know, it will not say, Thomas, you're stupid. And like, you keep asking that same question over and over again. And then we ask questions, you know, to our teams, our leaders, our managers, peers, and so on. Even our life partners, we do moderate that to a certain degree of, I see you're getting annoyed by the questions I'm asking you, even though for me, feels like it's good learning. So I think this number one is like, don't worry too much about how you're perceived. think most people actually on the other side are not judging as much as you think they do. And certainly leverage AI in these times to mitigate that. If you just want to ask the AI of how to ask nicely a question that has already been asked and you don't know how to explain that. But you know, I think, you know, everybody has their set of fears and I would give my past self the advice of you're worried too much and you'll sleep better without worrying that much. Whether that's early in career or whether that's being the GitHub CEO and you worry about how, you know, perceived on a podcast or you worry about the GitHub universe keynote, which is, know, at the time of this recording coming up. Luckily not for me this year as a speaker, so I have a chill time leading up to Universe but I certainly will dial in and see what the news is and how the presentation is. And I will not see all the stumbles that the speaker notices when they are speaking and thinking, oh, damn, you know, I mispronounced this word or I skipped over a line in the script or whatnot. So I think this is like the best advice you can always give your past self is don't worry. Everything is going to be fine. And you're actually... Most of these days they thought they're really bad and that they're turning out really great Erika (17:35) I feel like that's the flip side of caring so much about what we do is the side of maybe like caring too much and then caring about things that we maybe need to let go of like, yeah, the things that are. Thomas Dohmke (17:40) Yeah. Yeah. I mean, how often, you know, do you go into the movies and then you're worry opening slack when you come out of the movie theater, especially when you are in a different time zone away from, you know, the U.S. time zones, the Europeans and the Asians and like, hopefully nothing bad has happened. And then you see the incident command channel being lit up and you're like, do I want to tap on it? Is just the regular maintenance or is it an outage and... Even worse, right? If you get three pings from your manager and whatnot, it's like, this is the nature of having real, you know, big platforms. There's always something going on. And I think you got to live with that, with that mindset. Erika (18:22) Well, I know you're a big reader. On your GitHub, you even have, I don't know how up to date it is, but books that you've read recently. So what books or mental models have changed the way that you think about engineering? Thomas Dohmke (18:28) Yeah. Yeah, I don't know if this thing on the GitHub page, it might be a little bit outdated because I'm reading like multiple things in parallel and I think it only fetches whatever the last one comes back from the Goodreads API. It's cool in itself that that actually works and it uses GitHub actions, which you all worked on to pull that information and update a gist of it. There's actually, I have it somewhere, there's actually a book on mental models, which I found really useful on leadership, not so much on engineering. It has a lot of, you know, things that I found useful. Often, you know, I think the best books are the ones that you can just open a chapter and read it completely out of sync. Certainly nonfiction books and yeah, nonfiction books and fiction books. don't want to have that. But that's, that's one. I really liked the, now you're making me remember names of books. I think it's the engineering primer or something from the author that used to work at Stripe. What's it called? Will Larson Will Larson has like a three, I think three books here. like the engineering primer, the engineer executors primer, and then there's a third one. They're all kind of like bit of different phases of your engineering career. And I enjoyed reading all three of them, even as I was already a manager at that point in time, because you learn a lot about kind of like advice that Will is giving to engineers at different stages in career. It's also useful to be as a manager. I think at the time I was special projects and then when I was CEO I read the engineering executives primer, actually with all of GitHub's engineering leadership team. And it had a lot of useful advice about being an engineering executive and about how you handle, you know, your engineering team and culture, but also how you handle, you know, budget requests and how you. understand the perspective of the finance team when you give them those requests, know, asking for my headcount. I made air quotes again, asking for my headcount is a very common thing in large companies. And it's not always the right approach, but often, you know, it is a question of can I get more funding because the work that I have now on the platform that we're dealing with, or the, you know, the billing API requests that we're getting is so much bigger than it was when that team was originally founded So I found those. I think it's three books. We can add to the show notes the exact titles later. Erika (20:43) I will add those to the list of must reads. Thomas Dohmke (20:44) Hm. Hm. all coding books, honestly. think it's still even, you know, when you have 30 years in your career, it's cool to just open a coding book on a new technology and read through it. And you don't have to read books end to end. I'm a big proponent of stop reading a book when you get enough out of it and move to the next book, which there are so many books. like there's so many coding books these days, you know, about building AI systems and understanding large language models and those things. I'm always excited about picking up a new one. Erika (21:15) Absolutely. Aside from reading, what helps you learn something quickly and deeply? What are kind of your go-to approaches for not only understanding the surface level, ⁓ but like staying up to date? Thomas Dohmke (21:28) Yeah. You know, I think the first thing is to be constantly reminded that you've got to read something. So I've stacked, I have books stacked everywhere in the house, um, on desks and side tables and on my nightstand. And it's less about that those are the books I actually need to read. It's more about, oh, okay, I should read something. Um, um, and, it kind of like reminding yourself, um, that there's something else to do because there's so much. you know, on our mobile phones and TV and whatnot to watch that really you're limited in attention and the time that you have during your day, not in the information available. I've subscribed, you know, to a bunch of blogs. I still have like old school RSS reader, Unread on iPhone and on Mac. And so I go through those you know, on a regular basis, often during a morning coffee and then during the day when there's a little break and what have you. I have lots of browser tabs open and then I organize them into reading lists and then those reading lists become stale in itself. I think I read on some blog that most to-do lists are 95 % or so, some number of them are created and then never checked off. And it's really the practice of creating a to-do list that gives you the dopamine hit. then while checking off these items is something you're procrastinating forever. So I think this is what was statistics from Evernote or something like that. I think the most important thing is really just what is the ability to read through a newsletter or blog post and quickly capture whether this is actually useful or not. And because there's so much content and there's often so long, if you have the habit, I need to read everything to the last line and not being willing to scroll through stuff. You're never going to have all the information that you need to get to the job done. So that's the skill is reading fast is great. By the way, I love listening to podcasts at 1.7 speed. I also speak fast. So maybe that doesn't work for this podcast. like, and then because you can get so much done while you're going grocery shopping or mowing the lawn or driving to work or wherever you have time to listen to podcasts and audio books and what have you, because that's a way of capturing information. Otherwise you're driving and you can't really read a book. Brittany Ellich (23:32) Yeah, that makes a lot of sense. I feel a little bit called out by that to-do list statistic because I definitely have a lot of to-do lists that have been created and not checked off. Thomas Dohmke (23:41) Yeah, yeah. It's, you know, urgent things I need to do this week. And then you look at this three weeks from now and you're like, oh shit, I didn't do any of these things, but they were urgent. Brittany Ellich (23:47) ⁓ no. Uh-huh. Exactly. Yep. So I'm curious, we want to move a little bit towards what the future holds. And I know we can't necessarily, it sounds like a lot of that is still under wraps, but I'm curious, what are you most excited about now that's happening in the industry and how has that changed recently? Thomas Dohmke (24:08) What's happening is AI. And I think we're in this phase where, you know, a lot of the companies out there that are part of our professional life, software developers, but also our personal lives, know, our banks, insurance, and whatnot, they were all built in an era before AI. And now we have, you know, a huge number of startups in Silicon Valley and around the world building for the era post AI and, know, chat GPT or so was that moment that kind of defines the before and after. But there's so much, I think, white space of reinventing a lot of the things that we do in life, that the opportunity both for existing companies to look at their business models and what the value that they provide to customers and new companies is to disrupt that old world. And we have seen these changes before. We already mentioned a few. We move from punch cards and... mainframes to the personal computer. And the personal computer really was revolutionary because the job of a developer before the personal computer was to write something often on paper or so, wait for their slot on the mainframe. Then they had basically one-on-one time with the mainframe. They could run their thing, get the results. if you look at these mainframes, it was actually like the flickering of an LED or something was the output. And then go back and then diagnose the problem. Like imagine that's how we would do software development today. We would all quit our jobs and work on a farm or something. And then the personal computer changed all that. like same switch and all of a sudden, and you saw the early use cases for personal computers were actually spreadsheets because it was so much easier for an accountant or somebody that had to add up numbers to do that in a spreadsheet, even though there wasn't a graphical user interface, then it was doing that on paper. Because you can quickly, you know, edit a cell and it updates the sum, right? Like it's so simple in today's terms and it was so revolutionary when that started to happen in the 80s. Then we had the before and after internet and from being isolated in your home and trying to learn from books and that's all cool until you get stuck. And then you only have the book available and you know, it's 9 PM or whatever, and you can't go to the library, let alone that the library doesn't have coding books on computers that are only released in United States or what have you. you had nowhere to go. the best scenario was that you could find another nerd in computer club or in school or in your network. I mean, literally you could send a letter to the magazine and hope that they would answer the next next month's edition. Right. and then the internet came and with that, you know, use net and newsgroups and forums and, and, and, ultimately source forge and then get have their developers could come together and discuss problems. And That shows how much that changed our lives as remote first company as we have them today as GitHub is and many of GitHub's competitors, where all you know your coworkers from is a Zoom call, a Slack channel, and of course GitHub itself. That wasn't possible before the internet. And I think that same change is going to happen in our life through AI. And it happened through mobile and cloud. podcast has a certain limited length and then we have to stop it. But like we're going to see the change, same change to AI again. And we don't know what the future will be because we didn't know that before the internet either or before mobile or before the cloud. Brittany Ellich (27:08) Yeah, that makes a lot of sense. I feel like we're all feeling that as well, trying to keep up with all the things that are changing right now and embrace it and see what's working, what's not working. It's a very crazy time, but you're right that this has happened many times before. Thomas Dohmke (27:14) Yeah. I mean, classic example in software development, right, with copilot is when it started was on an auto-completion and that was already revolutionary in itself. The statistics of 55 % faster came from just auto-completion. Just by predicting what the next few lines are, you prevent the developer from going from their editor like VS Code over to the browser. Maybe we all have the rest of our life open in tabs and trying to find the answer to something that is predictable. by looking at the code that you wrote before. Then came chat. All of a sudden, you could ask all the questions and it would actually understand the code that you have already open. Now with agent mode and coding agent, you can go even a step further and have it run for minutes to hours on end to solve a problem for you. That shows the paradigm shift that we're going through. Brittany Ellich (28:06) Yeah, I definitely have been spoiled by that. The other day I had to write tests by hand. was, I think I was on a plane, so I didn't, and I didn't want to spend the $8 on the wifi and like actually writing tests by hand, which I have not done in a very long time, was very painful. Thomas Dohmke (28:11) Yeah. Yeah. should have spent the $8 and expended them. Brittany Ellich (28:21) I know, it would have been worth it for sure. And then what is the future for you, if you can say anything to her? Are you headed back to Germany? Are you, you do have plans on making this stealth startup an unstealthy startup? Thomas Dohmke (28:35) definitely have plans to make the start up a not stealthy startup in the, in the, know, next three to six months, probably I'm going to, you know, stay in the US I love travel. And so obviously my, my home country, my parents and in-laws and, whatnot are in Germany, but I'm going to travel back and forth. But look, the future is, I mean, already talked about a lot about AI and we're trying to see, you know, what can we change with AI in the life of a software developer? That's the space, you know, love to be in. I've been in for the last 10 years at Microsoft at GitHub. And I think there's so much work to do and so many things to be reinvented. As we went through these positions before, nobody knows what that will look like. And I think those predicting even the next year are going to be wrong because if you look where we were with AI code generation, whether it was copilot, cursor, Claude code, it wasn't even a thing a year ago, how much that has changed, how we're thinking about the space. I wouldn't want to predict where things are in a year, but I want to be in that space and I want to work on these things. to some degree reinvent the software development life cycle, in other parts contribute back to it and really just enjoy seeing developers using my tool and sharing the passion that I have for it. Brittany Ellich (29:46) Awesome. Well, with that, think we will start wrapping up and we always wrap up our podcast with a fun segment. Again, the air quotes, sorry. But what we'll do is we'll ask a question and we'll do a round robin answering and you'll get to go last so you have the most time to think about it. And this question came from Bethany. Fantastic, fantastic idea. if I know that you are a big Lego fan. Thomas Dohmke (29:57) Yeah. Yeah. Okay. Brittany Ellich (30:08) And the question is, if you could will any LEGO kit into existence, what would it be? ⁓ And it's a, yeah. Yeah. And it's okay if it already exists because there's a lot of them that, you know, there's so many. So yeah, I'll go first. So if I were to invent any LEGO kit, I think it would probably be, this probably already exists, but my... Thomas Dohmke (30:14) And you go first. no, I want to hear the answers from you first. Yeah. Yeah. Brittany Ellich (30:31) Kid is very into K-pop Demon Hunters and I'm sure this is coming out and she's also getting very into Lego. So this is the perfect time to bring these together and I'm ready for the K-pop Demon Hunters Lego crossover because I'm also a big fan of it. That would be mine. I don't know exactly, maybe their house. I think their house looks really cool and I would love to spend some time playing in that house with that very comfy couch. Bethany, do you want to go next? Bethany (30:54) Yeah, I will say they exist in like a fortnight, which I've already done. For me, it would be, I really love the tuxedo cat and I think it's so cute. It would be really cool if you could just do that for any of the pets that are close to you in your life. So like I'm thinking my parents' dog George or my childhood dog Daisy. Thomas Dohmke (30:57) You Yeah. Bethany (31:15) Lego kits of them would be so fun or at least like more options if that's not already a thing. Erika (31:21) I am a big fan of like the sort of like geographical Lego situations where like you go and there's like a city built out of Legos. And I'm currently living in San Diego. So I think it'd be really fun to have like a giant San Diego Lego kit where you can build all the all the things and have little cars going around and stuff. Thomas Dohmke (31:42) Well, you know, it's actually a fun question, not an air-quote fun question. I have three answers. One is, you know, I love really old Lego, like the Lego that was being sold when I was a, you know, 10 year old, 12 year old, especially as I think most of us go through childhoods where you look into the Lego catalog and you see something you really want and your parents are like, it's too expensive or Thomas, already have a train. You don't need a Lego train if you have, you know, trains. And so as, you know, in the early nineties, what I really wanted to have is the space monorail, which was just so cool. so a few years ago, I went onto Bricklink, which is a site where you can buy and sell both new Lego parts and also old Lego. And it's like all these sites, right? know, the older it is and the more pristine minted box or whatever, the more expensive the set is. But I did buy myself that old monorail and it is in my shelf in... And I can see it all day and being reminded of what I wanted as a kid and what I have now. So that's, you know, that I think is if you really like old stuff, I can recommend Bricklink. It's often cheaper and more nerdy to buy there than buying on eBay. I think the second one is like a more current thing. It's just like the new Lego Death Star came out and it's not actually a sphere, but it's like a slice of the Death Star. And it's very controversial because it's thousand dollar set and doesn't doesn't really show the death star it shows like a play interior, it's like a puppet house. So I'd rather have a real death star if I could will that into, I think most nerds want, most Lego fans want the outside looking like a real death star And then the third one is, you all mentioned this is maybe the thing you really want is an AI system where you can describe what you want and it is good enough to assemble the bricks. and then get to the part list and then Bethany, you can get your cat or your dog or whatever Lego. I mean, I'm sure the technology is there already. Somebody just needs to build it. And so maybe you need to will that into existence even better if it's an open source project in GitHub. Brittany Ellich (33:36) That is a really incredible idea, and I really hope somebody starts that. And if you do, reach out to us and share it, because that would be awesome. Thomas Dohmke (33:41) Yeah. Maybe you can use copilot to code it and then use AI with GitHub models or so to, yeah. It's not my next startup, so don't have to cut it out. But it's a cool, I think it's those things often hobby projects because the commercial value of something like that is only there if you're Lego and maybe you sell it to Lego, but it's not. Brittany Ellich (33:48) That's true. We can cut this part out if this is, maybe this can be your next startup right there. ⁓ Okay. It's a cool idea. Thomas Dohmke (34:08) startup idea in itself. Brittany Ellich (34:10) sense. Well thank you so much for joining us Thomas, this has been awesome. If folks want to find you on the internet, where do you recommend they go? Thomas Dohmke (34:18) Of course, I still have my GitHub profile, Ashtom. I'm also Ashtom on X and I'm Ashtom on LinkedIn. Brittany Ellich (34:23) Great, well thank you so much for tuning in to Overcommitted. If you like what you hear, please 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. Thomas Dohmke (34:36) Thank you so much, bye bye everybody. --- ## Episode 29: Building Search Infrastructure Developers Actually Want to Use with Don MacKinnon - URL: https://overcommitted.dev/building-search-infrastructure-developers-actually-want-to-use-with-don-mackinnon - Published: 2025-10-14 - Topics: Technical Deep Dives, Non-traditional Paths to Tech, AI & Developer Tools - Audio: https://anchor.fm/s/102586d64/podcast/play/109504607/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-9-10%2F409043118-44100-2-5bb7f9a1fecd6.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, host Erika and co-hosts Bethany and Brittany Ellich engage in a conversation with Don McKinnon, founder of Searchcraft. They discuss Don's journey in software engineering, the challenges faced while building Searchcraft, and the unique features that make it accessible for developers of all levels. The conversation also touches on the integration of AI, market competition, and the path to founding a startup, concluding with a fun segment about walkout songs. Takeaways * Searchcraft aims to reduce complexity in search infrastructure. * Rust was chosen for its efficiency and performance benefits. * Building Searchcraft took two years of development before launching as a product. * Searchcraft allows non-technical users to manage search relevancy through a GUI * AI integration is crucial for modern applications, especially in search. * The market for search tools is evolving with the emergence of AI. * Founding a startup involves learning and adapting to new challenges. * Identifying pain points is key to developing a successful product. * It's important to focus on solving real problems rather than perfection. * The journey of building a product can lead to unexpected opportunities. Links * Don MacKinnon⁠⁠: https://donmackinnon.dev/ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbXczZzhBMmhIRzdFZi1UMkhPeHR2YWRVN2lEUXxBQ3Jtc0tudHdrZGIxWFZ1bWtkel9rMTFMSzVKaUVTaWk4R0dtenFnbFFVRHA1MUlMNk12RmRGd0tGVTM1R2J1Q0hIZ0xJX2RNODdBdkJ6WU9mdVpQc2xlSEJBc3ZnOHVPUko1SXNkc1FfTTExdFlDSU9lQ21CUQ&q=https%3A%2F%2Fdonmackinnon.dev%2F&v=PIFc6tTrP-I] * Searchcraft⁠⁠: ⁠https://www.searchcraft.io/⁠ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqa0E5S1duZExtMmR0dWV1OGVVSHpCTmNMM182Z3xBQ3Jtc0tucUdpMFRuZDJsZE9keXI5NFFreGNXLVNKMXV4VURLcWhrTWxsZTY5bFRlVlA3cEc3ekdTR2ZjdVhuR0lwOUpjZlM3MzJDQVJheDNybTg3aTFsa2VvOFRyMXlwSVJkbkpYVUYtSEtOeXdkMHJ4bnBwVQ&q=https%3A%2F%2Fwww.searchcraft.io%2F&v=PIFc6tTrP-I] * Article: https://medium.com/@dmackinnon/improving-trust-in-ai-systems-432d61bef7b3 [https://medium.com/@dmackinnon/improving-trust-in-ai-systems-432d61bef7b3] Hosts * Overcommitted: https://overcommitted.dev [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqa0xScHRvbFlSMFJETXdZcWo4S3BWUDB3SXphd3xBQ3Jtc0tueU1VWVpmWUo2ejFzektPd3FmVHVTVDAtQ3ZmcE1rTGRGeldvNUNXbUtzRE5XT3B5S2xyMTFjQmQtSkxydktUWWhJazI1X1ZqR2MtTmQtdnFkWkQwUUR0QVRqZkxheEY0R2REZ0g1NU8xOWgwMV9EVQ&q=https%3A%2F%2Fovercommitted.dev%2F&v=PIFc6tTrP-I] * Bethany Janos⁠⁠: https://github.com/bethanyj28 [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbUM3MEZfSU1Hdm9IUnRmWEx6eVRELXFFci11QXxBQ3Jtc0trbG9fWFdDTWZkc3VsamdHMnkwUm1XRkVEWkVJRG9fV2pnUHNya2tPeXQ1RVVyQUt1d1UyTS12WVVmc0RuS3ZfYlQ0YWlYY0hDM0dqd2wzMnJsY0pGblQ5eEpFOU1WeFBqVFRWaTlYcnNiM0Y0NVZKaw&q=https%3A%2F%2Fgithub.com%2Fbethanyj28&v=PIFc6tTrP-I] * Brittany Ellich⁠⁠: ⁠https://brittanyellich.com⁠ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbTEwUkpuWDBWeWE2V2FRNXdPb0tIMWlTSE5YQXxBQ3Jtc0ttQkdnbHVCRWtwX19fZ09GX3ctQ3FpckxVVjlwdnZESVlzOEFsZVlvUTRNSjlNOC16aFprbmVsUUNDUXVRVUc1dTdob0k0M0hvTUJ4RUdMeG5CaFNIX19QMEQ0RTFwUDNZWGlCUUFRRmVuZlhLZGZQdw&q=https%3A%2F%2Fbrittanyellich.com%2F&v=PIFc6tTrP-I] * Eggyhead⁠: ⁠https://github.com/eggyhead⁠ [https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbkpsa0I1blBpeUM2QkN0YjBzNk1ocmQtOEc2Z3xBQ3Jtc0traUFiaTNlYkFycG1uSDZlLUswT05PR1dGZjhpYUkyWFFlSzVPeE1NczFlRnIyMmZTMnIzZzFwcFdVMmxEWldIdzdfRXVsVmNyd1dCSUxhSGtwcXVIZkVMbnFqTUtLQjFOaWlncXozU21FMFYydnVJYw&q=https%3A%2F%2Fgithub.com%2Feggyhead&v=PIFc6tTrP-I] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast, your weekly dose of real engineering conversations. I'm your host this week, Erica, and I'm joined by... Bethany (00:09) Hey, I'm Bethany. Brittany Ellich (00:11) And I'm Brittany Ellich. Erika (00:12) We are a group of software engineers who initially met working on a team together at GitHub and discovered we all had a passion for honing our craft through discussing our technical improvements, learning strategies, and career challenges. We continue to meet and now share this space with other engineers who genuinely love what they do. Today on Overcommitted, we are joined by Dawn McKinnon. a technology leader with experience at Fortune 100 companies, startups, and everything in between. He's the founder of Searchcraft, a startup focused on optimizing the developer experience of implementing search. Prior to founding Searchcraft, was CTO at a software consultancy focused on building apps for startups that were either scaling up fast or had non-technical founders. Welcome, Don. Don MacKInnon (01:04) Thank you for having me. Erika (01:06) We are so excited to chat with you. We have some big Rust fans, I know, in our colleague groups and can't wait to hear more about your journey and ⁓ especially the technology at Searchcraft and some of your thoughts about the space and of course, a little bit of AI talk. ⁓ So let's start with... Don MacKInnon (01:26) Sure. Erika (01:31) Searchcraft's secret sauce, which is your Rust powered engine. So yeah, can you give us a little background on what the implementation is, some of your key technology decisions there? Don MacKInnon (01:46) Yeah, so we kind of approached Searchcraft with this idea of trying to reduce complexity. So we felt the existing tools out there were a little too, it was too complicated for, or too complex for, to really hand off to people. we were doing a lot of that handing off when we're doing the software consultancy. So part of that choice to reduce complexity was to go with Rust because Rust is more efficient, uses less resources, so by definition we could reduce the size of our search clusters and there would be less to manage, right? So with Rust you don't have to manage a JVM and have that configuration, you have to deal with on top of the application configuration. So that was the big choice. We got a lot of performance gains out of that. And then being able to, by using Rust, we were also able to layer on additional features at like query time that you couldn't necessarily do with other systems that we using before. So that was able to improve kind of like the relevance of our search results by doing that, yeah. Erika (02:56) That's very cool. So what were some of the main challenges that you faced in developing this? Maybe kind of tell us the story of start to finish and what maybe some of the bumps along the way were that you overcame. Don MacKInnon (03:13) Would you say when ⁓ the difficulties would be with building it in Rust or just building it in general? Erika (03:21) building it in general? Like did you start with the rest day one or did you kind of try to think of some other options before you settled on that? Don MacKInnon (03:30) Before we wrote it, we didn't write any code outside of our Rust code for the engine. So we were pretty sad because we had a good period of time where we were kind of just brainstorming the structure and the stack and whatnot before we wrote any code. So it was Rust from day one. The difficulties were like I had search training. already in Elastic, I knew pretty well how that worked. I've also used other Lucene-based systems before, so I know how those worked. So figuring out a way to kind of replicate a lot of that, that it's a VM25 relevancy from the ground up in Rust, ⁓ that took some time. We do have some open source libraries that we fold into our core engine that help with that. But... When you start from zero, there's a lot you have to think about when you start actually writing the code. How are we going to store our indices in a way that is both performant but also reliable? How do we handle authentication through our API? So all of those things. ⁓ you know, kind of they add up over time. yeah, it's just, it took a lot longer than we expected. So, we, took about, we built it for about two years in bootstrap mode before we spun it off into like its own company, its own product kind of thing. So, we're building it internally at the consultancy just to kind of serve our own needs and to see if it... was as performant as the other tools out there. so that took about two years of just working on it when we had time in between clients and whatnot. then it really, the Core Engine was done about a year and a half ago. And then last year we decided to try and test the waters to see if we could spin it off into, it's like an actual product company, like a SaaS company, which is what we did. So before we did that, we met with a lot of other consulting agencies and to see if this is something they would be even interested in using. And so we had a lot of those conversations and it was pretty much over like, one thing, like, yes, we would use this. We don't like the tools that are out there on the market now. So if you had something that was lower, easier to use, less resources, better performance, we would totally use it. So we're like, okay, well, I think we're onto something. Let's try and make a company, right? So we did the whole like, fundraise thing, writing a pitch deck. We had never done that before. So like, I've worked with startups that were funded from BC and whatnot, but they kind of handled all that fundraising aspect of it, right? So we were just there as builders that got pulled into the project. But this is the first time myself or my co-founder had to actually do a raise ourselves. So that was. Very, very interesting. A lot of big learning curve there, I would say. Erika (06:30) Well, yeah, you mentioned some of the key points that you built out and, you know, I have used search platforms before, but yeah, you know, it's one of those things that I think when I've integrated it, I have not thought so much about how it's implemented. So yeah, you mentioned like indices and authentication and maybe if you could like... just describe a little bit more of like what other problems SurfCross solves and yeah, what it does there. Don MacKInnon (07:04) Yeah, I think one of our differentiators is we try to make search infrastructure accessible to builders of all levels, right? So for a long time, it's kind of been gate-kept off to back-end developers, Java developers, things like that. So trying to make it accessible to more front-end developers, TypeScript teams, and also people who are maybe product managers and non-developers as well. So once it's been integrated, ⁓ Our relevancy tools are all tunable from non-technical people through our GUI, right? So you don't have to actually write code or do code deployments to like, okay, I want to change the weighting of fields within our search index, or I want to change synonyms out for our cinnamon library, or even changing the language of the index. You don't need a developer to do that. You can just like... mess with the levers yourself as a product manager. That was really important for us. Also, there's a lot of people building with tools like MCP and Cloud Desktop and things like that. We want to make sure those people were able to use Searchcraft and not have to necessarily know how to query our API and do authentication and all that. They could just... generate the credentials and use our MCP server and type in natural language with our API essentially. Bethany (08:25) That's awesome. I mean, speaking of MCP and AI, mean, I really enjoyed the article you wrote on the trust problem in AI because that is such a, such a real issue and something that I hear very consistently. mean, when I went to GopherCon this year, that was one major topic and theme that they were talking about. So I'm really curious how you can see Searchcraft fitting into the building AI applications and making them reliable and transparent, how do you envision that flow going? Don MacKInnon (08:58) Yeah, so. Trust in AI, so there is an issue out there where you'll talk to one of these eight, like, ⁓ LLMs and you'll get answers that are maybe inaccurate, right, or they're outdated, yeah, inaccuracy and not up to date. That's a big problem. So one way you can kind of solve that is through that information discovery layer, so like making sure that these... ⁓ LLMs have the ability to pull relevant information out of a system, right? So like, LLMs are really great at user intent detection and understanding natural language. like, understanding what my question is asking. But if you don't connect it to the right tools underneath it, then it's not able to pull back the right information, right? So like, it has its initial training set of data that it knows. And then... You guys are familiar with with rag systems essentially where you can feed more up-to-date information into that into that model and it can pull from that so through it could either do it directly through like a search craft API or through MCP and know like okay well if you're able to pull the most relevant information because LLMs can construct the queries to get that information out of an API it can pull the most relevant information and also like the most recent information. So that's really critical when using these AI platforms that the correct information is getting surfaced back up. Erika (10:25) Yeah, I'm curious. You mentioned the usability of Searchcraft for maybe non-backend developers. Is there a vision for supporting automated optimizations with agents and stuff like that as well? Don MacKInnon (10:42) Yeah, haven't, ⁓ we don't have, we are planning stuff for like, if you're referring to like agent to agent protocol and things like that, we do have some plans that I can't really talk about yet, but ⁓ it is definitely on our roadmap to do that, yes. We want to, whether it's humans using our platform or like agents or other systems, like make it easier for those connections to happen, right? At the end of the day, we look at ourselves as a way to get the most relevant information out of a system, and we don't really prescribe if it's a developer or an automated system or an agent or... Bethany (11:18) I'm curious, when you started building Searchcraft, where was AI in the thought process? So is it something that happened to converge nicely, or was it something that you were building this company with, with the intent to help out with things like that from the start? Don MacKInnon (11:35) Yeah, I mean AI wasn't really being talked about at the time so we started building it in 2021 and we started the company in 2024 and when we started the company during our we did like a pre-seed angel raise like AI wasn't really a topic right, but now it is and if you're raising money you pretty much have to have an AI component and if you're in the development space people want to use AI tools. it's something we've had to kind of like shift and like embrace as part of our platform. And I think it's very exciting, but it wasn't something we planned for at all. Brittany Ellich (12:14) Yeah, that makes sense. I'm curious too. It sounds like, so I personally hate doing search. So the idea of search craft sounds really, really nice because it's a perpetual problem. And I just never want to have to think about it and want to abstract that away to people who really care about the problem. I'm curious though, there's some really big players in this space already, like Elasticsearch and I'm sure a bunch of others. It's first one that comes to mind. Don MacKInnon (12:38) Mm-hmm. Brittany Ellich (12:40) How was it taking on a market that was already pretty established? Is this your first startup you founded? Don MacKInnon (12:47) I mean, pretty much. I had one other bootstrap startup that was a consumer-facing product, but this is my first B2B developer tool startup and the first one where it's like, I'm all in on it, right? So my first real one, I guess, yeah. Brittany Ellich (13:02) Yeah. Okay, how was it approaching a space that was already existing? Don MacKInnon (13:10) Well, so I had a pretty good understanding of the space before we decided to even do this thing. Elasticsearch is a great tool. I think it tries to do too much. It tries to be like a one size fits all tool for search in general, but it kind of doesn't do anything great. there's like lots of performance issues with it that we, I'm not just saying this, but like other developers have told me like that they have to deal with. And the space has been pretty stagnant. Like there's a couple of big players, Elasticsearch, Algolia is another big player, but they're only cloud. can't self-host Algolia. So there's a few big players. Most of them are based on Lucene, which is an older open source library that's been around since the late 90s. So there hasn't been a whole lot of innovation in the space, I feel like anyway. There are some other newer players that are getting into it now. And I think... Especially with the emergence of AI being a thing in the industry, like search is kind of becoming a thing again. So it's, I wouldn't be surprised if you see more search companies appearing over the next year or two. But to your point earlier, like you don't like dealing with search. I think most developers don't, right? And I think developers should really focus on like, if you're making a product, like focus. your product and the problem you're trying to solve well. You don't need to reinvent the wheel with search. Don't roll your own authentication. Don't roll your own analytics. Search is also one of those things. Really shouldn't roll yourself. Let someone who deals with that every day solve that problem, and then you worry about the problem you're trying to solve. Brittany Ellich (14:43) Is Searchcraft pitched at a specific size of problem? Is this something that hobbyist developers on their side projects can use Searchcraft as well as enterprise? Or what is the target market there? Don MacKInnon (14:53) Yeah, mean, don't, so like anyone could use it. You can run it yourself through like a little Docker container. You can, we have a free plan. If you don't wanna run the cluster yourself, you can use our free plan on our cloud service too. That's totally available to people. When to pull in search? I think it's when you get to a point when you have any significant amount of data, right? So like if you have no data, you don't need search. once you start, you'll know in an application when it starts getting frustrating and there's friction in using it when you can't find the information you're looking for, that's when you need to pull in search, right? Like if I'm building a social media app, you're gonna be unthinkable to not be able to find posts, right? Like older posts. It's just something that you expect to be there. So I think you'll know when you're building it if you need search. Brittany Ellich (15:47) That makes sense. And it sounds like you, the, sort of started with a problem at the company that you were a CTO at. Did you plan to become a founder within your career? Did you plan to like start a company at some point, or is this something that you've sort of been learning and adapting as you go on? Don MacKInnon (16:04) I mean, I definitely didn't know how to be a founder. So I've been learning and adapting. I've always wanted to kind of build my own products. I've done like little things on the side here and there. And my co-founder and I have talked about it like, well, we've built great products for other startups, but we didn't really have say in the direction of the company itself or like what features they chose to build or bring in, right? We're just kind of like the designers and the engineers. behind it. So the opportunity to kind of like do our own thing was very exciting. But there's a lot that goes into like founding a startup like you're, you know, hiring, managing people, raising money, talking to investors, like there's a whole thing that's outside of just the building aspect. So for me, like the engineering part is like the easy part for my job now. I mean, I've gotten to the point where like, Okay, I need to build and I need to make an integration for this language. that's not a problem. I've never used this language, but we'll figure it out. I can figure out engineering problems. Figuring out how to convince investors to invest in the company is a totally different problem that like, you know, this is, I'm new at that. So. Erika (17:11) Do you have any advice from your experience sort of approaching this like big unknown problem for developers who are kind of going through the same experience of like how to get started, how to navigate those moments of uncertainty? Don MacKInnon (17:26) As far as like, where do I start when I'm building or it's like, should I make a company around this thing? Erika (17:33) Hmm, yeah, I guess they're valid questions. I think I'm maybe thinking of the first part where, this is, like you said, you realize that there was this big problem to solve and you're thinking like, okay, I want to build something to fix this. I guess you said it did take longer than you expected. So maybe there was a difference in scale and... Don MacKInnon (17:54) Mm-hmm. Erika (17:57) you know, size of the solution. But ⁓ yeah, like I think that kind of blank page problem is familiar where you're looking at something and there's an empty repo, like where do I get started? Don MacKInnon (17:59) Yeah. I think you want to build for a problem you know, a problem that you experience. And that's why we built this is because we were experiencing a problem. So a lot times I'll hear like, want to make something, but I don't know what I'm going to make. Right? Like that like repo problem. But everyone has like pain points that they encounter every day in their life, whether a developer or anybody in any profession like. solve for the pain points that you know because you know the problem already. These are things that I deal with every day that I wish worked this way or I wish I did it this way. Solve that problem. If you look inward, you can figure out pretty quickly a problem to tackle, I think. Erika (18:55) That's definitely true. I feel like I've experienced both where I have no idea what to build and then I have a list that's longer than I could possibly ever tackle of things that I want to solve. yeah, finding the right thing to attack on that list is definitely key. ⁓ Don MacKInnon (19:06) Mm-hmm. And I think choosing the tech that you choose to solve that problem with is like, you can always move fast with languages you are comfortable with, right? I think it's more important to kind of get your idea out the door than it is to be perfect, because you can always iterate. It's more important to prove the idea and that you're solving the problem in the way that is correct versus, okay, is this code scalable? You can scale later. get something shipped. Erika (19:42) Yeah. And then what was the moment like when you realized that this was a sellable product? What was that thought process and that sort of switch? Don MacKInnon (19:54) ⁓ Well, I think it was like like I said last year when we were having those conversations with those other development shops They kind of like validated that it's not just a problem that we see here internally but other software consultants were having the same problem with right like having to Maintain and hand off search infrastructure is painful So if you have something lighter, it's it's much easier to to do that handoff with teams that aren't search experts very like so if you work with the startup is like you know, for TypeScript developers, asking them to maintain an Elasticsearch cluster is very, it's a big ask, right? Like they probably will keep coming back to you. So we kind of wanted, we didn't really think that was fair to say like, you have to keep paying me to maintain this, right? When they were supposed to be like a handoff project as a consultant. So building tools that these levels of developers can manage on their own. Yeah, was like, truly that's something a lot of companies will want. ⁓ Erika (20:50) Yeah. Well, it sounds like you're definitely making people's lives better. And thank you so much for sharing all about your story and all about Searchcraft. I'm feeling inspired. Great. Well, we're ending our... ⁓ We always end with a fun segment. So if I'm understanding correctly, you also had a background as a music producer. Don MacKInnon (21:13) yeah, did I tell you guys about that? I did, yes. So in my 20s, I had my own record label and I was recording bands and whatnot. I lived in New York for a while and did that. Yeah, it was my other life before I took being a developer seriously. Erika (21:32) All right, well today we're gonna merge the two and we're gonna think about walkout songs and any athlete has a walkout song that they use for their presentation at a game or whatever. And so we're gonna think about either you, your company, or a next big release, what would that walkout song be? So I don't know if you have a project in mind that's in the works. Don't want to spoil it. You could also think about like past favorite projects. What the walkout song would be. So I know I'm dropping this and we'll all take a turn to say ours. Don MacKInnon (22:11) I was not prepared for this, I just want people to know. Erika (22:15) I'll give you some time to think while I share mine. ⁓ We currently have a project that's been like over a year in the works to get to public preview. And so my choice is shipping up to Boston by the drop kit Murphy's, because I want it out the door. Ship it. Let's go tomorrow. Brittany, do you have one in mind? Brittany Ellich (22:35) I do actually, yeah. I also had to take some time to think about it a little bit because I'm terrible at anything music related. I chose Livin' on a Prayer by Bon Jovi. Mostly because of that refrain, you're halfway there, livin' on a prayer. I feel like everything that I'm working on right now, once it ships, it's still only gonna be part of a larger overall solution. So every time we ship something, I'm like, but we're still building to this big thing overall. So it's a good reminder every time that we're still going. ⁓ Erika (23:03) I'm glad that's the reason and not because the whole ship is slipping on a prayer. Brittany Ellich (23:12) That's true. Yeah. Bethany (23:14) I for one think that music and coding goes really well together. The other day I actually I've been listening to a lot of albums recently and I put like the album I was listening to in my PR. was like this PR was brought to you by Live 2007 Daft Punk and things like that. But lately I along with I guess everyone else in America has been obsessed with K-pop demon hunters. So I would probably end up choosing like how it's done or take down from from there because it just feels way more intense than it actually is and it makes me feel badass. So that would be that would be mine. Don MacKInnon (23:54) Do I have to pick just one? Erika (23:57) No. Don MacKInnon (23:59) Okay, because I have two in mind. The first one's gonna sound horrible because I'm in like fundraise mode right now. We're trying to do a raise at the moment. So Wu-Tang Clan's, there's a song, Cash Rules Everything Around Me. I'm not all about that money, but yeah, that's right now I'm trying to raise so that's that's the song for right now that I played my head But as far as like our search craft the product goes I think daft punks around the world because we're trying to be everywhere all over the place, so Erika (24:30) love it. Bethany (24:32) Nice. Brittany Ellich (24:32) I feel like that speaks to the dichotomy of being like a technical founder as well as like, you know, you're thinking about the business side and the technical side. They go hand in hand. Erika (24:42) Yeah. Don MacKInnon (24:43) you Erika (24:44) I would put those both on a playlist together too. Yeah. Well, Dawn, if folks want to find you, where should they go? Don MacKInnon (24:52) Sure, so my personal site's DonMcHenon.dev and you'll probably have to get that link in the show notes because nobody knows how to spell my last name. But otherwise, searchcraft.io is our company as well, so either place. Or I'm on Blue Sky, but DonMcHenon.dev has all my links, so. Erika (25:08) We will definitely include that in the show notes. And with that, we'll say thank you for tuning in to Overcommitted. And if you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye. --- ## Episode 28: From Engineer to Entrepreneur with Brad Heller - URL: https://overcommitted.dev/from-engineer-to-entrepreneur-with-brad-heller - Published: 2025-10-07 - Topics: Non-traditional Paths to Tech, Leadership & Management, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/109081766/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-9-1%2F408491493-44100-2-5af20a9c3712e.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Brittany Ellich and Erika engage with Brad Heller, co-founder and CTO of Tower, discussing his journey from software engineer to startup founder. They explore the evolution of software engineering careers, the challenges of entrepreneurship, and the skills necessary for success in the tech industry. Brad shares insights on the importance of aligning passions with work, the realities of startup life, and advice for aspiring engineers. The conversation also touches on the impact of AI on coding and the importance of understanding the fundamentals of software development. Takeaways * Brad's journey from corporate life to startups was driven by a desire for impactful work. * Working at startups can provide invaluable learning experiences compared to big tech. * Entrepreneurship requires aligning your passions with your work for true success. * Delegating tasks is a crucial skill for founders, but often difficult to master. * Understanding the entire business process is essential for engineers in startups. * The tech landscape has changed, with many entering the field for financial reasons rather than passion. * AI is transforming the coding landscape, but understanding the fundamentals remains critical. * Networking skills developed in big tech can be beneficial in startup environments. * It's important to recognize when to hire and delegate responsibilities as a founder. * The romanticized view of entrepreneurship often overlooks the hard work involved. Links * Brad Heller on LinkedIn [https://www.linkedin.com/in/bradhe/] * Tower.Dev [https://tower.dev/] * Paul Graham [https://www.paulgraham.com/] * Will Larson - A forty-year career [https://lethain.com/forty-year-career/] * PIE PDX [https://www.piepdx.com/] * Rick Turoczy [https://siliconflorist.com/author/turoczy/] Hosts * Overcommitted.dev [https://overcommitted.dev/] * Brittany Ellich [https://brittanyellich.com] * Eggyhead [https://github.com/eggyhead] ### Transcript Brittany Ellich (00:00) welcome to the Overcommitted Podcast where we talk about our commitments and some stuff in between. I'm your host this week,Brittany joined by fellow host. Erika (00:09) Erika. Brittany Ellich (00:09) And, and that's it. That's just us today. We are a group of software engineers, just two of us today, who initially met working on a team together at GitHub and found a common interest in building cool things. So we decided to start talking about it on the internet. We continue to meet and share our learning experiences and discuss our lives as developers. So whether you are pushing code or taking on new challenges, we are so happy you're listening. Today we are joined by Brad Heller, the co-founder and CTO of Tower, a data and AI company building a serverless Python native data platform that basically gives data engineers superpowers in the cloud. If you've ever wrestled with deployment pipelines, infrastructure headaches, or just wished you could focus on the fun parts of data engineering instead of DevOps, Brad's been thinking about... how to solve exactly those problems. Brad's journey to tower was not a straight line. He was in the trenches as a software engineer, navigated the wild world of startups and learned firsthand what it takes to go from writing code to building companies after having a successful exit in the past. Today, we are diving into that evolution, how you know when it's time to stop being an employee and start being a founder, and what it really means to wear the CTO hat as your company grows. So... Let's get into it. ⁓ Yeah, I'm so glad that you joined us. One other thing, Brad is also my brother, I should say. I did not include that in the intro, but I feel like it's interesting because we've had a very similar background. But very different ways of getting to the world of software engineering and very different experiences within it. So I'm really excited to talk to you and learn about your experience in startups because that's not a thing that I've done and where, you know, how that has evolved over time. So what drew you to startups initially while you were planning your career? Brad Heller (02:02) Yeah, good question. Planning my career, that's probably a big word. When I was at university, I always wanted to work at big companies afterwards, after I was done. I thought that's where you go to make impact, where impact in my mind is ideas I have somehow affecting, hopefully improving, other people's lives. And I thought, that's where you go to do these things. At the same time, like towards the end of my university career, I learned about this guy named Paul Graham, who like maybe you guys have heard of him. He's kind of a big deal in the startup ecosystem. But back in 2008 or whatever it was, like he was just getting started with this thing he was calling Y Combinator. The first few batches of Y Combinator. Back then, I think it was like 10 companies per batch or something like that with like super small. super small investments going into them. But I kind of fell in love with this idea of people like me going out and taking their ideas into the world and driving impact on their own. After university, I did go on to work at big companies. I worked at Microsoft for a little bit. I went to work at WebMD, which is kind of a internet dinosaur at this point, kind of dates me. But... Anyway, like I just, after struggling through that for a couple of years, I just really couldn't like take corporate life, you know? Like I said, I wanted to do impactful work. I didn't want to have to worry about like performance reviews and like keeping time sheets and like having like, you know, these horrible like corporate meetings with people and stuff, you know? I wanted to be treated like an adult, I guess. That's how I felt at the time. Anyway, so I went and... you know, found my first startup job in like 2010 maybe. I remember I was like 24 years old maybe and one of the, one of my coworkers at WebMD, this girl who was like maybe 22, she was like, wow, that's so risky. You're going to work for a startup. And I was like, what does risky even mean at 22 years old? You know, like what are you? risking. You've got to work for another 40 years anyway, right? So like, maybe we should just go do something. But I mean, actually, I guess things are kind of a little bit different today, like for junior engineers, like right after university. But, you know, let's see what we can do about that. But yeah, I went and go join this startup, and it kind of like set me on this path where like in the next two, three years, I feel like I learned like a thousand X more than I would have slogging it out in big tech, about building software, about selling software, about shipping software. like I've kind of feel like in big tech, you don't really learn how to build software. You learn how to like follow company guidelines and how to like make architects happy, you know, which can kind of be like a proxy for building software, but like in the end, you know, yeah. So I don't know. It was really cool moment. that was really impactful. I met my first co-founder actually at this startup. And I think more than anything else, it really opened my eyes that there was other people out there that cared about these things the way that I cared about them and wanted to do things. At the same time, I was kind of coming out of the .NET ecosystem and into the Rails ecosystem for the first time. That was also a huge eye-opener because all these ideas that the ecosystem had. that weren't well reflected in the .NET ecosystem back then. Especially, again, these were like Balmer days, know? So, super different. that was pretty, I don't know, very impactful time. Brittany Ellich (05:36) Yeah, no, that makes sense. I have worked in both .NET and now in Ruby and Rails and can confirm that it's very different ways of thinking between the two. ⁓ Brad Heller (05:44) Yeah, but there's good ideas making their way back into the dot net ecosystem now. ⁓ I'll never, hopefully never get paid to write dot net again, but you know, here we are. Brittany Ellich (05:49) Yeah. You never know. You never know what the future is going to hold. I like that idea, too, of thinking that it's, you know, the 40 year career was that Paul Graham or no, that was it was another I have to look up that article. I'll say save that as well. And the show notes. But yeah, the 40 year career about how like you don't need to just like rush through this and hit everything. Brad Heller (05:57) Yeah, absolutely. Yeah, totally. Yeah, absolutely. Huge topic with like, you know, the topic of the show is like helping engineers improve. Like one of the like pigeonholes or traps maybe that people fall into is this idea that like, to be the best like front end engineer, I need to focus entirely on like just doing front end work, you know, or whatever. And yeah, similarly with careers, people, people actually like in big tech in particular, people think like, you know, they need to speed run. the corporate ladder also, you know, how do I get to be, everyone wants to be a principal engineer. I was working at, before I did Tower, I did a little segue in big tech actually, cause I hadn't done it in a while and I was like living in a new place though. Thought it would be kind of fun to try out and like everyone wants to be a principal engineer. Like the only conversation you have with even like junior engineers is like, okay, how do I become a principal engineer? And then when you go talk to these principal engineers, they're like, man. Brittany Ellich (07:09) Hahaha Erika (07:11) How do I not become a principal engineer? Yeah. Exactly. Yeah. Yeah. I mean, feel like it also kind of speaks to some values. like you mentioned, like, wouldn't like I want to do something like I don't I don't want to like follow everyone else's instructions. And like, to me, that speaks of like passion for the work and Brad Heller (07:12) Yeah. How do I go back to being a senior engineer? Yeah. Brittany Ellich (07:14) a bag. Erika (07:35) Yeah, like really doing it for yeah, doing it for you, like navigating your own career. Like it sounds like you you would be an entrepreneur no matter where you are. Yeah, like even in a big tech situation, like like you're you're you're an entrepreneurial spirit, making your own path. And I mean, I would argue that that's like that. That is a tenant of success for anybody. But I think depending where you fall on that entrepreneurship spectrum, it can be really grating to like not have the opportunities to realize those ideas and some kind of scale. Brad Heller (08:14) Yeah, totally. mean, I think your point about aligning your passions with the things that you do is one of the most important things to being successful in anything. If you are swimming upstream against your own intuitions or values, you can do that. You can slog it out. Maybe you'll have varying degrees of success. But the magic in happens in like all aspects of life, feel like when you align like your values, the thing you care about and like the things that you do fundamentally, right? yeah, entrepreneurship, I think is yeah, one of those one of those things for me. And it turns out actually like building things is one of those things for me too. Like, I got into software originally because like, I just like to make things, you know. And when I was a little, little kid, I was like, man, this is so cool that with a computer, you can build whatever you want. Like you don't need any resources, right? Like it's just like what you can imagine, you know? And you can make it do all these different things. You know, that's what like attracted it to me originally. And yeah. Again, like a long time ago, like in university, like I met a lot of people that also kind of thought that way. The ecosystem has changed a lot, you know, it's like so focused on, you know, what's that app where everyone goes to complain about their job that managers hate ⁓ has a red icon. Blind. Yeah. Blind is like the total comp race, you know, it's not about like, how do I do something impactful? It's about how do I get like, who's got the best signing bonus, you know, and like, Brittany Ellich (09:43) blind? Brad Heller (09:54) How can I... And I guess that's like important for some. Like that's an important thing too, right? But anyway, Brittany Ellich (10:00) Mm-hmm. I'm curious how that landscape has changed over time, actually. When you first entered software, were people coming to it because of the compensation at the time? Or how has that changed over time? And have you seen how people who came into this just for the comp, if they're still happy doing it throughout their career or not? Brad Heller (10:20) Yeah. Yeah. No, think, yeah, like it was much more niche back in when I got into the industry, like for context, like my first job, like where I got paid to write code, I got it in 2005. And so that means this is my like 20th year doing this stuff, which is a bit difficult to say out loud. But yeah, it was much more niche back in the day. People came to it because they loved it, they cared about it. They were builders also and they wanted to, or they were in love with technology or something like that. And yeah, I think it was just at the beginning of this rise to Google, I think they IPO'd in what, 2006? Facebook was just coming on the Like literally was founded in 2004, 2005, was just becoming like, you know, by 2008 was like this behemoth that it was becoming, you know, like the concept of quote unquote big tech back then was like sun microsystems, you know, or IBM, maybe Microsoft back then, you know, which are not like sexy jobs, right? Like it was not like, you know, like the position of the way it is now. Brittany Ellich (11:20) IBM. Mm-hmm. Brad Heller (11:33) So, yeah, it was much more niche and like people were coming at it for because of the love, I guess, or just starting to come at it because of the money. I know loads of people who've gotten into it because of money now, and they're doing fine. I think there's definitely a gap between the people who are doing this because they love it and it happens to pay well at the same time, you know? But, and I always ask myself, like, how can you just, how can you do that, man? How can you get up and go to work? But actually loads of people like get out too, you know, like the joke I always tell is that like, you know, the like typical career path on LinkedIn is like, you know, junior engineers, engineer, senior engineer, principal engineer, shepherd, or like woodworker or something like that, you know? And maybe that that's kind of part of the, you know, other side of it. Erika (12:27) you Brad Heller (12:27) The other thing that's changed is that we didn't have the concept of, or like influencers in the tech industry were like, there was like Joel Spolsky, there was like Scott Goo, know, like there was like two or three dudes that either had their own company or they were working for like Microsoft or something like that. And now there's like, I get like Instagram reels for like Temporal, like by like these like comedians. who specialize in making comedy for engineers, software engineers, know? It's like so bizarre to me. But it also means that people have a lot more leverage over their networks and everything now, right? So it's good thing and a bad thing, yeah, yeah. And maybe the last thing I would say is like, would be remiss to not mention how AI has changed everything, right? Like the way that we work. Like if you asked me a year ago, I'd be like, I don't know. But now like, I hardly remember like having to write all the code in a file. It's really crazy. Erika (13:27) Well, let's go back to your personal journey here and dig into that moment when you decided to start your first company and what the moment was when you thought, I need to solve this problem. I need to build this rather than complaining about it or hoping that somebody else would. Brad Heller (13:32) Mm, sure. Yeah, that's a good question. I don't know if there was like one problem. Like I have a collection of problems in my brain that I like keep thinking about, you know, like with tower, like I, one of the like initial things was like, I think there needs to be like a good platform as a service. And like, I happen to be working a lot with data engineers, you know? And so like that, that was the like impetus to go like work on this problem, right? my first startup was. a GitHub for designers. GitHub had changed the way the engineers were working because you could do it collaboratively, but that didn't exist for graphic designers. And now we have Figma, which is like, you So there's a collection of problems, I guess, that I keep working on. other ones that I've got in there that I'll probably work on in the future as well. But... Yeah, like I think the driver was more like, I need to do something myself, you know? Like maybe it's like a social thing or maybe it's just like, I don't know, but I just have this thing inside me that was like, I have to go do this myself, you know? And so, yeah, once I kind of had the right problem, had the right partner, it was like, okay, let's go check it out, see what happens. Yeah, take the leap, as they say. Erika (15:01) And did you have sort of a checklist before you took that leap or did you go without really thinking too much of the next steps? Brad Heller (15:13) Yeah, that's a good question. thought I had this, or I had a checklist at the time and like, I now realize how wrong that was. Like I spent, like I said, I, you know, I learned about this guy, Paul Graham and all the work he's doing. He's got these great essays online that you can go read and follow. And like, he's the guy, Y Combinator obviously like founded the hacker news community. And I could like have great conversations on there back in the day and today, but back then too. with other people who are doing this startup stuff. But I other friends that are interested in startups as well. We would meet and talk about them. One buddy of mine and I, we had endless conversations about them. But in the end, I was just sort of getting ready to get ready, I think. I was probably a bit afraid. I didn't know where to start. And I think getting my first real startup job was the first catalyst for that. People who want to be founders, I often recommend they go work at a startup if they're not ready to go do one themselves. Because you have to kind go through the founder journey in terms of not just writing the code and all that stuff, but seeing, hey, what's it like to get early customers? How do you talk to? these people, like how, what's the pre-sales process like in the post-sales process and fundraising and get exposure to that, you know? So like, these startup jobs were like very formative that way. Yeah. And in the end, the thing that I think really like made me take the leap into being a founder was my, I mentioned at that first startup I worked at, I met my co-founder there. We applied to join an incubator, kind of like a Y Combinator, but for the like Portland area, right? and we got in like magically somehow. have no idea how these like two 26 year old idiots got selected for this, thing, it ended up being like transformative. Obviously for me, it ended up being really great for, the ecosystem as well. Like we ended up like working with a lot of companies in the Portland area where I come from originally, along the way. In fact, was actually there in Japan, I was in Tokyo, and there's a bar there called the PDX Tap Room, where they have like Portland themed stuff. I don't know why. I think it is in Harajuku in Tokyo. But there's a book there that talks about Portland makers. they have an interview with a guy, Rick Turoczy who's like the grandfather of all the startups in the Portland area. And he was the founder of the Portland incubator experiment. like my story of like starting that company and then like crashing and burning it terribly and joining another company and like how that affected the Portland ecosystem and everything is like documented in this book in Japanese in this bar in Japan. Like just such a weird like, you know, way that impact, I guess. Yeah. Yeah. So, yeah, taking that leap can be really scary, but I think also people need to realize that you're not reading another book, reading another business book is not gonna make you a better businessman, know? Reading another, you just need to go do this stuff, right? So I encourage everyone, either go do it or go join a startup and figure it out, yeah. Erika (18:31) How about engineering specifics of anything from your background that was helpful for you from an engineering perspective in your startup ventures? Brad Heller (18:42) Yeah, I like I still spend the majority of my day writing code, you know, like the, uh, uh, probably if I had to guess, it's like 60 to 80 % of my time is spent coding still. Like obviously have loads of meetings and stuff like that. Like all of the things that you learn to do in your like day to day, you also do in startup land, right? Um, like we have a daily stand up. in the morning that looks a lot like the stand-ups that we would do as like teams everywhere else, you know? We have design reviews for the things that we do, you know? When I first started in startups, by the way, I thought like, you don't need to do all this stuff. And then obviously horrible things happened, right? So like I've brought all this stuff with me now and it's like gotten better as a result. So like all those skills that you learn are like part of it, you know? The organizational skills that you get in big tech also I think are really useful in that context. Another thing that's really important about just being an engineer in general is learning. We're constantly having to learn new things. Good engineers are constantly learning new things. That's one of the core things that differentiates good and bad engineers, I think. And so having a good system for learning and understanding what things you need to learn and how to develop. Like to be a founder, you need to be good at learning. because there's a ton of stuff you're to have to do and figure out that like, there's no one else to do it. Obviously you can go to your network and I can talk to the CMO of some like other portfolio companies. They, should I structure my marketing or whatever, but like all of this stuff, you don't have to be good at it. You just have to be like a little, you just got to be good enough at it until you can hire someone to do it for you, you know? So you need to have a little bit of a develop a good bit of an intuition for good marketing and like. of understand the sales process and like how to structure customer success and all these things. Learning, I think, something that makes engineers particularly good, well suited for this. And then finally, networking, think. Being good at networking will take you very far. Like I developed a lot of networking skills like inside, like big tech, because you have to do it to get things done, you know? So, yeah. Brittany Ellich (20:58) That makes sense. Yeah, I think it sounds like there's a lot of skills too that are very far outside of the realm of engineering as well that you've had to develop over time. Things like sales, that's something that I don't, I've never really had to worry about. And it's kind of nice not having to worry about those because that feels like a very different skill set from building things. Brad Heller (21:07) Yeah. Yeah, true. Yeah, yeah. But I think it's, I find that to be the interesting part. Like understanding how the entire like business fits together is super interesting. I still get to go focus on writing code and that sort of stuff, but I like being part of the whole process. so, yeah, maybe it's the entrepreneurial kind of side of me. Yeah. and again, you don't have to be good at it. You just got to do enough of it to like survive. until you can hire someone that can do it. Brittany Ellich (21:47) Makes sense. I'm curious now, so you've started several startups now, and so you've gone through this experience a few times. How do you scale yourself over time? Like, how do you know when, okay, it's time to hire somebody to do this role or something, or how do you, do you continue writing code for, you know, 60 to 80 % of your time, the entirety of the lifetime of the startup or yeah. Brad Heller (22:09) I wish. Yeah, I wish. That's a good question, actually. I think I've not done a good job of that before. I because engineers, we tend to want to solve problems, right? And that means that we take responsibility for things. Like when something's broken, like I go and fix it, you know. because that's just like the way that my brain works. And so as a result, like taking responsibility for all these things, also maybe have a little bit of a, like, maybe a little bit of a control bent in me or something like that. makes it difficult for me to give things up or to admit when I need help with something, you know? So anyway, like I found myself like over my career either as like the head of engineering at companies, or as the CTO, kind of like overwhelmed with so many things that I gotta do. then, the answer to the question is just like, give it to someone else, man. Which is like really easy to say. It's like more difficult to, a little bit more difficult to implement, right? So yeah, I've done really poorly at that over the years and I've had to kind of learn to like, when, how to feel those inflection points a little bit with. Tower, I'm actually kind of like trying to solve that problem even earlier. Like if you go to our job site, we're hiring by the way, and we, I'm looking for like a head of engineering that seems like 10 people, but like offloading the actual work of like, know, building the team, doing the management work, all of that stuff earlier, I think will. for make for a better outcome. think the other side of this is like understanding like what you are truly good at, you know, what you or what you are uniquely good at perhaps like, yes, I can go do the management stuff. Like I've been like in the leadership team in big tech companies, I can do those things, but it's not like what I'm like good at. It's definitely not what I'm like uniquely good at, you know, like the company. is better off with me like going and like writing code, working with a team, being an architect or working with customers, you know? That's, so yeah, that's maybe that in terms of like where to look at, like how to scale yourself, find the stuff that like you're uniquely, like you're uniquely good at and like make someone else deal with the rest. Yeah. Erika (24:29) Yeah, delegating itself is a skill and it's, you know, even more complex when you're the one deciding who fills the spot where you delegate or like what the role of, you know, that delegation even looks like. Like there's a question of who, there's a question of what they're doing, there's a question of how to make them successful, how long is it gonna take to ramp them up? Like it's, yeah. Brad Heller (24:32) Yeah. Mm-hmm, yeah. Erika (24:57) Yeah, simple like assign a task to somebody else and have them do it does not really exist in any world, but especially not in like startup scaling. Brad Heller (25:08) Yeah, totally. And then keeping them accountable to getting it done on time and helping unblock them if they get in trouble or whatever is like difficult too. When I first started doing all of that stuff, like my first like real leadership job was the head of engineering for this startup in the Portland area. you know, like I started as like engineer and then they like raised a bunch of money and they needed to hire some people. I was like, I can do that, I guess. And so, you know, I kind of started scaling out the team and kind of got this, became the head of engineering. And yeah, I really struggled with delegating to people because like, I don't want to like overload this person. don't really, you know, like, I just be faster if I do it myself, you know, those sorts of like, that sort of internal dialogue, you know. ⁓ but yeah, I think like, I realized that like people are capable of a lot more than like what you think that they are, you know? yeah. There's something in there. Brittany Ellich (26:07) I'm curious, were there any ideas that you had romanticized about starting your own company that did not turn out to be as like the way that you had dreamed about when you were first getting into it? Brad Heller (26:19) Yeah, totally. You know, like, especially like my friends today, even today, like still think, ⁓ you work for yourself, man. Like, why can't you just like, you know, why can't you come on this vacation? Why can't you like, just go travel with us or whatever? It's like, no, man, it's job just like every other job. Like I wake up in the morning, I attend daily stand up. Like I said earlier, I like do like design reviews with the guys. I have one-on-ones with them. Like I have like features. I got a ship. We've got. you know, production issues we got to work on. My day looks exactly like your guys's day, you know, in the end. So like this idea that you're like, have this like, freedom. Yeah, it's true. You have a little bit more, you know, like I can, like, I don't really have to worry about like PTO, you know, like, I mean, I do for myself and for the team, I can't let them down and all that stuff, but I don't really have to count PTO days, right? And I have a bit more control, like when I really don't want to do something, yeah, I just like, I'm just not going to do it, you know? Sometimes, I guess there's some things you got to do. But yeah, it's not like this, like, I'm just going to go like work, build a company from the beach, know, Tim Ferriss and the four hour work week did a lot of damage to the world, I guess. Yeah. So that was like one thing that was big. Yeah. Brittany Ellich (27:34) And if you had any advice to anybody getting started in software engineering in general right now, what would that be? Because it's like we've talked about, it's a very different world now. You've talked about how to get into being a founder if you're already an engineer, but what about somebody just getting into software engineering in general? Brad Heller (27:40) Mmm. Yeah. Yeah, One of the bits of advice I gave like senior engineers that are looking to move into like a staff role or a principal role is like go. work outside of your area entirely. Do something outside of your area entirely. Like if you are like a front-end engineer, go create a toy database. Or if you are like a backend engineer, go build something for an Arduino. Or sort out how to make a game engine, or even just how the graphics pipeline works or something like that. Like by going and working in a different area entirely from what you're used to working in, you'll take ideas that these engineers have and bring them back to your work and become a better engineer. Kind of like artists, know, painters going and studying sculpting or something like that. I don't think it's too dissimilar. On a related note, I think, to like couch it in 2025, I think that like actually going and writing the code yourself. is like, don't lean on the AI too much, you know, yes, AI can make you massively more productive, but you have to really understand like what's happening. there's loads of pull requests that I get even today that are like, ⁓ you know, like the guy, the doesn't understand the code and he also doesn't understand what the AI emitted, you know, like that's basically vibe coding, right? and, Like you have to have like one of these two things like true in order to like kind of have a grasp of the situation. Right. so like, actually going through the putting in the reps as they say, I guess in like actually writing code, understand what's happening. Like all that stuff is important. That's what I would sell. Don't just because like AI can make you super productive. Like, yes, that will come. You know, Erika (29:39) makes me laugh because when you're talking about like the four day work week and that kind of stuff, I'm like, well, I bet, you know, there are companies you could have started where that was possible. you know, Python data architecture is maybe not the simplest thing in the world to build. like, you know, like same, same, same, same with AI. It's like, yeah, you know, I Brad Heller (29:54) Sure, yeah, true. Erika (30:02) I can write code. Like, do I know what it's doing? Do I know how to do anything with it once it's written? Like, hmm, well, guess I gotta use my brain there. Brad Heller (30:08) Yeah. Yeah, dang it. I gotta use the brain. But I I think about this a lot. And I think that if you truly don't care what happens under the hood and the AI admits something that works, great, go for it. But we work in a collaborative area where we kind of owe it to our coworkers to, you know, or maybe the abstractions will get so good that at some point we're not thinking in terms of code anymore, but our jobs as engineers is... Erika (30:15) Yeah. Brad Heller (30:40) I don't want to say thinking in terms of prompt, you know, think, something like that. Erika (30:45) Yeah, I mean, it all comes back to the source code. unless it, yeah, unless it's implemented correctly, like it's garbage. So. Brittany Ellich (30:45) That makes sense. Brad Heller (30:56) But dudes in the 70s would say, like, if the machine code's not perfect, you know, what are we doing here? So, I don't know. Yeah, exactly. So, I don't know what the answer is. I know that I prefer it when the dudes on my team go and, like, read the things that they wrote, that they had their tools wrote, had their tools write for them. So, yeah. Erika (31:03) Like the abstraction you're talking about. Yeah. Brittany Ellich (31:19) That makes sense. ⁓ Yeah, I always think about it in terms of like learning math. You don't just like get a calculator and start doing math. Like you learn the fundamentals of math and you know how it works. And then yeah, the calculator can make you way faster at it, but like you can't just jump into it and start using a calculator. You have to, you know, take the steps to understand. I feel like it's the same thing with engineering and AI. Brad Heller (31:37) Totally. Yeah, probably like everything really in life. Like I can't really think of a thing where you can just like read a book, you know, besides like trivia perhaps, right? ⁓ But yeah, anything practical. Brittany Ellich (31:44) Yeah, true. Cool, well I think we are going to pivot to our fun segment to start closing things out. So we do a different fun segment every time and I figured it would be fitting to do something related to starting an app or company. our fun segment this time we're gonna do a round robin of if you could invent any app right now, what would it be? And it doesn't have to be like, it can be silly, it could be anything or anything important. Brad Heller (32:00) Great. Mmm. Hmm any app, okay Brittany Ellich (32:22) So I'm going to let Erika go first. Erika (32:25) I definitely have an answer with this one because Isabelle's in her toddler phase where she says no for literally everything, but sometimes she says no when she means yes. And so I wish there was a toddler setting on the new AirPod translation mode where she says no and can actually translate what she's actually trying to say. Yeah, that's what I would invent if it was in any way possible. Brad Heller (32:52) I love that. It's Brittany Ellich (32:53) That's genius. Brad Heller (32:54) a great idea. Brittany Ellich (32:55) Yeah, I think that would be cool to have like if my Google could actually like hear my children and understand what they're saying when they're asking for the same song over and over. It's only like three things that they ever asked for. So you would think that it'd be easy. Brad Heller (33:06) fair enough. Erika (33:07) Yeah. And then like also like tell me what to say. Like what's the right thing to say when she's asking me for Baby Shark for the hundredth time? Like I'm gonna say no. How do I say no in a way that she's not gonna like have a tantrum? Brittany Ellich (33:11) Yeah. That makes sense. I actually did not really prepare a very good question for this. think actually one thing that I've been thinking about recently is I do a lot of crocheting and I would be really interested in, there's a way to crochet that you can build graphs. Like you go from like corner to corner and I want to build an app that can create a pattern from your GitHub commit graph and make a commit graph GAN. I think that that would be really fun. Yeah. Brad Heller (33:52) a commit graph can. ⁓ I love that. Can the graph can, I feel like that's if commit graph can is not registered yet. commit graph can.com. It's not registered yet. You should go register it. Brittany Ellich (33:56) Yeah, so that's that's fine. you I'm gonna go add that to my list of domain names that I'm paying for. I don't know, AI exists now, so I could make this happen probably pretty easily. I'll check that out before this episode goes live. Brad Heller (34:16) Yeah, definitely. All right. Brittany Ellich (34:21) Brad, what would you do? Brad Heller (34:23) ⁓ good question. What would I do? well, I just moved to London. I was living in Berlin before, and then I just moved to London like a few weeks back and I'm like looking for an apartment in London right now and the ecosystem around apartment hunting apps in London is like absolutely miserable. So if someone wanted to come solve that problem, like everyone would be happier in the end. Brittany Ellich (34:49) I've heard the same actually from my friends that live in the area. Brad Heller (34:52) If they have any tips for me, I'd love to hear them. Brittany Ellich (34:54) Yeah, I'll figure it out. I'll ask them around and see. Great. Cool. Well, thank you so much for joining us, Brad. If people want to find you, where should they go? Brad Heller (34:58) Cool. Let's see, obviously tower.dev to learn more about the product that we're building. I would love to chat with any of the data engineers in the audience to see if we can help make your lives better with a Python native data orchestration tool. Outside that, you can find me on LinkedIn in slash Brad HE or on GitHub as well. My GitHub username is at BradHE on there. ⁓ and, would love to connect with folks. Am I going to any conferences anytime soon? think I'm going to some Python conferences, Pi data, Boston, think we have planned. yeah, none of the other big ones though. Yeah. Would have been a good plug to have here. Brittany Ellich (35:43) Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow and subscribe or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and please share with your friends until next week. Goodbye. --- ## Episode 27: Q3 Goals Recap with Bethany and Brittany - URL: https://overcommitted.dev/q3-goals-recap-with-bethany-and-brittany - Published: 2025-09-30 - Topics: Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/108868708/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-8-26%2F408216844-44100-2-b5ee61c577f6c.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany and Brittany discuss their experiences at recent tech conferences, including Cascadia JS and GopherCon. They reflect on their goals from the past quarter, sharing successes and challenges, and set new objectives for the upcoming quarter. The conversation also touches on the importance of community engagement and personal development in the tech industry, culminating in a fun segment where they share ideas for potential TED talks. Takeaways * The importance of community in tech events. * Reflecting on past goals helps in personal growth. * Engagement in newsletters can shift focus from self-promotion to sharing others' work. * Attending conferences can provide fresh insights and networking opportunities. * Setting realistic goals is crucial, especially during busy times. * Public speaking can be a rewarding experience despite initial anxiety. * Finding enjoyment in activities is essential for long-term commitment. * Quarterly retrospectives can help realign personal and professional goals. * Exploring new interests can lead to unexpected opportunities. * Community engagement is vital for mental well-being in remote work environments. Links * ⁠CascadiaJS [https://cascadiajs.com/] * GopherCon [https://www.gophercon.com/] * MagnoliaConf [https://www.innovate.ms/event/magnoliadeveloper-conference/] * ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠⁠⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠⁠⁠ [http://overcommitted.dev] * Bethany Janos [https://github.com/bethanyj28] * ⁠⁠⁠⁠⁠Brittany Ellich⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Bethany. Join by. Brittany Ellich (00:11) I'm Brittany Ellich Bethany (00:13) We are a group of software engineers. I guess it's just two of us today. But we initially met working on a team together at GitHub and found a common interest in learning and building cool things. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we're happy you're listening. All right. So since it's just us today, I figured we'd just kind of do casual chat and then... some like quarter retrospectives and looking forward at the last quarter of the year. one thing I just wanted to chat with you about, you just got back from Cascadia JS, right, Brittany? And I recently got back from GoFuCon, so I thought maybe we'd take a moment to do a little conference recap if there's any like. trends you're picking up on, any highlights, any lowlights, things like that. Do want to go first since it's probably fresh on the brain? Brittany Ellich (01:11) Yeah, absolutely. Yes, I'm excited about this. I think this quarter I attended one conference, which was Cascadia JS, and it was a very cool conference. I feel like it was more just like general web development than super JavaScript specific. Most of the code examples were in JavaScript, but I think a lot of the stuff was really applicable to. pretty much anybody, which is nice. I feel like I see that a lot more in conferences these days because the actual specifics of languages are a little bit less important. there's just, you it's hard to have a lot of new stuff going on in a lot of them to have a ton of different talks. But yeah, it was a fantastic meetup of the Cascadia community. There were actually fewer folks from Victoria, BC than there are from Vancouver, BC. than they're normally were. Cascadia is the region of North America that makes up Oregon, Washington, and British Columbia. So it's supposed to be a meetup of all the groups, but some folks in Canada didn't want to come down this time, understandably. So they had their own separate meetup, I believe. And so it a lot of folks from Oregon and Washington and from just all over. Some of the speakers were from, you know. all over the place, Rachel Lee neighbors, they're from London. So that was, you know, pretty far. I think that they were previously a, Pacific Northwest native, but not living in London. So that's a pretty far way to travel. There was Bree Hall, who I've met at two conferences this year, and I'm probably going to see her at Universe as well. And she came over from, I believe, Atlanta. So yeah, there was a lot of folks from all over, which was nice. Overall, the talks were awesome. It was, I think all my favorite ones were really about MCP, which was kind of cool because I think a lot of the MCP stuff I sort of paid attention to when it got really popular a couple of months ago and then just didn't really need any of it. So was neat to see how things are changing and evolving there. I gave a talk on removing tech debt with agents, specifically the GitHub Copilot coding agent. And that was really fun. That's a similar talk that I'll be giving in universe in a couple of weeks. And yeah, it was, it was good. Overall, it was good. It's definitely a conference I could see myself going to year after year. think they had around 600 attendees and it was the most people at a Cascadia JS ever. Not even since COVID now. I think for the last few years, it's been the most since COVID, but now it was the most ever. So that was really cool. They already announced 2026 and it's definitely on my radar for next year. How about you? How was GopherCon? Bethany (03:50) Yeah, yeah, GopherCon was great. It was in New York City this year, which is a first for GopherCon, think. Typically, they do swap between Chicago and San Diego, but really cool being in New York. I loved being able to do some sightseeing as well as attend the conference. it was, I feel like for once, fairly balanced for me for not just diving all in the tech space and getting quickly burnt out, but also some just fun non-tech hanging out, which was great. But I think it was very interesting comparing it to my first GopherCon experience two years ago, which Brittany, you were also at that one. It was wild because I think that first one, was everyone was talking about Wasm. WebAssembly. And that was really the thing. And this year, there is no mention of it. I think I know the Go team added support for it, but I guess it's just like, not on people's brain anymore. Quite potentially, obviously, the themes were around AI, MCP, some ML stuff, but really mostly AI. And so the keynotes that the Go team were delivering was largely on, how do we ensure that LLMs are giving quality content back for when they're suggesting Go code? Which, working on Copilot API, I thought that was a super interesting talk on, they called it modernization, because LLMs have a cutoff in their memory. ⁓ and a lot of times an LLM, if you're coding go, we'll recommend practices that aren't really in place anymore or that there's more effective recent practices. Even if you tell it, Hey, use this way of doing things, it will still do the old way. and so they're thinking like doing a, MCP server for, for go ensuring that it's always using the latest. go SDK knowledge. they also want to make sure that linters have modernization flags, which I see in my editor. I've seen it before even this conference. So I think they're already starting that. So, really cool to, to see how they're thinking through things. And I think honestly, it's interesting to think about, but probably ⁓ It's a huge help for your language if LLMs know it and can program in it well. So I wonder if this is a thought for other languages, but it was kind of a fresh take that I haven't seen yet in the coding space. really cool. Highlights for me, I spoke. Yay, it was fun. It was a lightning talk, which I think was perfect for my first time talking. And I talked about Vim. because I really enjoyed them. I had a lot of really great feedback, really. People were fairly excited. I only messed up once and I don't think people realized I messed up. So that was great. But that was super one of my highlights. Lowlights leading up, I was like super nervous for it. So that was all I could think about and I wasn't necessarily. engaged or plugged in with the rest of the conference just because my anxiety was like, but it was, it was still fun. Yeah, I think that's basically it from my experience, but I guess we can pivot now and talk about how did Q3 go? I guess when did Q3 actually end? Like September 1st? Brittany Ellich (07:33) No, I think it ends in, it'll, it ends on at the end of September. So it'll end next week, but this episode will come out next week. So it's, it's good timing, but there's still time to finish something if there's something you're really passionate about. Bethany (07:38) ⁓ okay. Amazing. Yay. Okay. That's good. That's good. Yeah. For those listening, Brittany actually suggested doing this. And I was like, wow, I have not thought about my goals since we did the first episode. So I think this is a really good thing to do a retrospective on, especially wondering like why that happened and things like that. But I don't know if you want to talk about what your goals were first and how that went. Brittany Ellich (08:13) Yeah, for sure. I, so looking at my goals for Q3, I wanted to continue writing my weekly newsletter, run three times per week, read six books, do my daily drawing for one month on weekdays, and focus on reading and less on content creation. And so that is sort of what I, what I did. I was really pivoting because I think earlier this year I was doing a lot of my own writing for my newsletter and that kind of got pretty... I wanted to make sure that I was like regularly writing things and it got a little bit too much for me so I pivoted my newsletter to be more about sharing existing resources and I actually really like that. I feel like it gives me an excuse to read more and learn from other people so I feel like I got both of the weekly newsletter and the focus on reading more goals done. I did end up reading three times or running three times per week. for most of it because I had the Spartan race in Seattle a week and a half ago, I think, and I finished it, which was exciting. I survived slightly under the average time even, which was cool. A lot of the things that I just couldn't do like the monkey bars and stuff. So I had to do a little bit of extra running for that, but that was fine. Overall it was super fun and I'm considering doing that again. It was just a nice way to keep myself running over the summer. Reading six books. I don't know if I did that or not. I listened to a few audiobooks but I feel like when I'm doing digital like e-reading or listening to audio audiobooks I have a really hard time actually tracking what I'm reading because I don't it's not like I'm holding a physical book and able to be like These are what this is what I finished. So I made it done that I probably did like three or four books. I'd have to go back and look daily drawing for a month. I stopped halfway through August. Actually, I was doing that and it was really fun. But I got burnt out between the art project we have going on right now and. just work getting a little bit crazy and stuff. So I also took a step back for about a month this quarter and I recognized that I needed it and it felt really good. It was nice to step away and notice that I was feeling, starting to feel a little bit burnt out and just doing less things and now I'm feeling more refreshed and ready to jump back into more things. So overall good quarter. I don't think I've reached every goal but you know I think that having a focus on goals this year has been Really nice and it's glad that we're coming back to recap and see where we're at. Because it's really easy over the course of a year to forget what it is that you wanted to do. Bethany (10:59) yeah, definitely. I agree. Even when you're not achieving those goals, and I think it's good to review, okay, well, why? And being empathetic with yourself, but it sounds like you hit more or less a good portion of your goals. I'm curious with the weekly newsletter, did you see any changes in engagement with it from the change or has it been roughly constant? Brittany Ellich (11:24) I think there were quite a few unsubscribes early on because I mean the entire, all the content changed so totally understandable. But since then everything's been, after the first week or two of the change it's been pretty steady. I think a lot of that is likely that, know, some, well actually no, I think I've actually gotten more engagement because now I'm tagging folks that I have, you know, read something and then I'm sharing the things that they're writing which also feels better to me than just like putting all of my own stuff. out into the void of the internet and it's kind of more fun for me to celebrate some of the things that somebody else wrote and did and that I thought was really good than just trying to share my own thing that I wrote. So I would say it's probably been a positive overall. I think most of the newsletters I'm subscribed to are like a you know something written each week where they you know It's either like ⁓ an accumulation of links that they're sharing or it's like a thing that they write every single week. And I think I've just realized sort of the niche that I'm in is sharing lots of different things. I don't actually know. This is one thing that I'm not totally sure I'm going to keep doing next year. But I do want to finish it for the year and see like, was this worth it? Or do I just want to go back to writing the occasional blog post when I have something really exciting to talk about? we'll see. Good question. Bethany (12:40) That totally makes sense. And I think that's a really good experiment to have and just seeing what sticks, what feels good to you though is, I think, so important. So I'm glad that you've kind of pivoted and done things that feel true to what your goals are and what you're wanting to put out in the world. So really cool. Brittany Ellich (12:58) Yeah, thank you. How did your quarter go? Bethany (13:02) Yeah, it was fine. So I think you hopefully pulled my goals, which was good to be reminded about because I think before this, could not even remember what I said. And so my Q3 goals were to get back to creating blog content, which AI probably messed up a little because I never wrote blog content. I have not done any of this. Honestly, I haven't done the design course or anything like that. I've really fallen off of this. And eventually I do want to get back on it. But I think I've just put so much into work. It's been hard to think about engineering or doing big brain stuff outside of work. it that that kind of fell off, which I'm OK with. Read regularly. I still have done that. I will probably end up reading about 12 books this quarter. And it's just it almost doesn't feel like a goal because it's just something I enjoy. I like doing. probably haven't done as much tech reading as I typically do. just because life's been crazy, but I always have a have at least one fiction book and one tech book in progress. So that's been that's been really good. And I also mentioned integrating movement into my routine. Did not happen either. So I'll get back to that maybe later. But yeah, that did not happen. stop using all my energy at work also did not happen. I have been a workaholic, but I do think in general, when I think about how this last quarter went, I feel like I've been better at developing a community outside of work. So investing in friendships a lot in ⁓ people that I care about and people that care about me. And so I I feel very lucky about that. And I think it has been a super positive experience this quarter, just getting out there and doing more things. I've been to a couple local concerts, hung out with friends fairly consistently and maintained those friendships. So that's been really good. And I'm proud of myself for that. So I think that's been definitely a net win. And then lastly, I mentioned public speaking efforts. I did talk at GovrCon, like I mentioned earlier, so I consider that a win. yeah. But so overall, the things I accomplished weren't because I was tracking goals. So it almost feels like cheating to mention that. do think I've had, it's been a positive quarter. I don't think it's been a bad quarter. Anything's just things have been busy. and I haven't really been organized and focused on, okay, well, what do I want to do? So I end up getting pulled a lot of different directions. And so when I reflect back, I think that's like a large theme of this past quarter is I'm kind of like doing a lot, but it's not necessarily aligned with or focused in things that I'm trying to progress in necessarily. Brittany Ellich (16:31) That sense. Yeah, I think that's one reason why I like, you know, pausing every quarter or so just to think about what it is you're doing, just to make sure that the things, I think it's really easy to sort of get stuck into. I'm gonna keep doing the things that my work asks me to do or keep doing these things that I know are on my plate that I need to get done. And it's kind of nice to stop and think, okay, like am I spending my time in a way that makes me happy so that, you know, at the end of the year, you don't look back and you're like, wow, this entire year sucked. I didn't do anything fun. So I think that's nice to do. Even if you don't end up accomplishing things that you originally set out to do, think it's still good to reflect and think about what it is. that you're working on. And with respect to the blog content and stuff like that, too, I feel like, you know, wanting to do those things and not actually doing them, like, that's fine. You have a podcast, you did a public talk, you're working on, like, one of the coolest things in tech right now. So, you know, I think that you're you're doing a lot for, like, visibility and all that stuff. So. Bethany (17:24) yeah. I appreciate that. Yeah, I would like to spend more time writing organized thoughts down for things that I believe in, like things that I think about. But I agree, it's not something I necessarily need to urgently do or rush to do. So I like, If I really want, if the blog was really the thing I wanted, there's frameworks, there's like easy ways to do that. I could do a sub stack or whatnot if that was really the thing. But I just, really want to create something that I'm proud of. And I think learn a new stack and become a little more proficient and empathetic for our friend and friends and things like that. So. Yeah, I think it's largely learning related, so it's nothing that I need to rush to. But yeah, I agree with wanting to reflect on goals. think you can definitely go very far in the planning direction too. And I think it's important to make sure that there's opportunities for like those serendipitous moments and you're trying a lot of new things, but it's, there's... gotta be kind of give and take there. So it's good to be a little structured and also good to recognize when things are just a little too intense and you're like, no, I don't have to do this today. I can enjoy the nice weather or like hang out with a friend or things like that. So I agree that coming back to this every quarter has been just so really nice for resetting and being like, well, I didn't do this, this and this and that's okay. but also how do I do those things? Do I still want to do those things? So in that vein, I guess you wanna chat through what our goals for Q4 are. Brittany Ellich (19:38) Yeah, I'm trying to think about what it is that I'm focused on right now to figure out what is worth doing. I do think I'm gonna continue the newsletter that I'm working on. I kind of agreed with myself at the beginning of the year that I was gonna try to do it for a year and see what I thought of it. So this will be the last quarter that I try that first year and see if it's something that I actually really enjoy doing or if it's something that I... don't want to do quite as much. really like the focus now on sharing other pieces of content because I think that that's just a good way for me to make sure that I'm reading things and like trying to stay abreast of information out there. So I'll probably continue that one. One of the other ones that I want to do is I want to do more movement in general. think I'm really considering taking this yoga instructor course. next year, not because I'm planning to go start teaching yoga, but it's because it's something like I think it'll be helpful for me to like just focus more on like movement and stuff. think I hit a point where I'm just like, wow, it hurts now to move in certain ways and in ways that I have never been like that before. So turning to get a little old, guess. Not really, but feeling it and I want to, you know, try to make sure that I'm setting myself up for success as I do actually get old to have good routines for taking care of my body and things like that. And then I think the other one that I want to do is I want to work at a co-working space like once a week. My brother and I actually are going to do that soon. found one in the area that we live and we're going to go together. He also works remotely in tech and so we're going to encourage each other to both go out and like at least go sit around other humans once a week. And I think that that'll be really nice. I think I had this. existential crisis recently where I was like, oh my gosh, I've been in my house for five years now and that's a lot of time to be indoors and like away from other humans. And I'm kind of missing that connection, especially after going to all these conferences this year. I'm like realizing like I do actually like to go see humans. Um, so I want to try to do that more. And then I've got two talks planned for this quarter as well. So I'm probably gonna do those and then prep for next year because doing the conference thing has been really fun and I'm really enjoying it and I wanna do more of it. So those are my goals. What about you, Bethany? What do you got going on? Bethany (22:08) I love those and I might still one of yours. Well, so brainstorming ahead of time, I wanted to be very aware that I mean, holidays are coming up. December is November and December are personally just a hugely busy time for me. I mean between holidays and both me and my husband have the same birthday in December so it's like chaos everywhere but fun chaos I guess. But anyways it's I think it's always challenging to do to commit to too much to over commit if you will. So I want to be aware of that and not not be hard on myself if I don't achieve everything but the things that I would like to do. And I tried to do more like fun things that will be fun to do and beneficial, but one, I'd like to just be more organized. I mentioned like feeling like things are pulling me or directing where I'm going rather than me deciding to do a thing. So I just want to be more organized to weekly planning both for home life and work life, and be more explicit about the things I'm committing to and the things that I want to do and how it relates to where I want to be. so really if I can just stick with weekly planning, I'll be happy in that case, just get into the habit of doing that and then adjusting from there. and then I really I really do want to find enjoyment in activity and be more consistent with that. I keep accidentally paying for class pass, so I'll probably actually use those credits at some point. And then finding something I like to do. I've already been to a couple of classes that have been so fun, like an aerial class. I've done some kickboxing and stuff. So just continuing with that and seeing. ⁓ what kind of movement feels good. I feel you on getting older and wanting to make sure that I'm set up for success and I'm like entering new chapters of my life as prepared physically and mentally as possible. So yeah, the one I want to steal from you is the coworking space. That is so good. Me and my husband pay for our coworking space and we send it sometimes and every time we attend it, we're like, we should do that more often, we just don't. So maybe setting a goal or putting it in the calendar and saying this is the day I'm going to my co-working space just would be helpful. So I love that one. Brittany Ellich (24:41) Yeah, that's a great. Yeah, I'm excited. I think it's one of those things that I'm not going to do unless I'm like specifically setting a goal because it's just so easy to like be in your home when you work from home. But it's also just a great way to, you know, get involved in your local community, have some passive, maybe eye contact with other humans. Yeah. just get out a little bit more. I'm mostly excited about lunch. There's a really great taco place next to the one that we're going to. So I'm just going to get tacos once a week and that's my reward for peopling is tacos. Bethany (25:15) That's amazing. Yes. What an incredible reward. No, it's similar. Our co-working space is in a part of Charlotte that I really, really love. So it's a cool space and just fun to go to that area. So yeah, I love the community aspect too. That's so important, like the local community and getting involved. So I love that. Brittany Ellich (25:40) I feel like that's one of the things that has been sort of consistent this year. One, I've been more involved on Blue Sky and I feel like there really is a community there of people, but also going to all of these conferences, like that is the fun part of engineering is the community aspect. And yeah, I think I just, I want to see a little bit more of it. Cause I think a lot of them are still sort of rebuilding and coming back after, you know, this weird. crazy fever dream we all had of 2020 and beyond. And so I'm excited to spend more time on the overall developer community, hang out with more people, get to know more people. Yeah. It's one thing that AI can't take away from us. Bethany (26:17) That's awesome. Yes, exactly, exactly. I was thinking the same thing while you were saying that. I'm like, well, you can't really do that with AI. I you can talk to it, but I don't know if it's quite the replacement there. So that makes sense. I don't know if you want to talk about the overcommitted book club or how that's been going at all. I feel terrible that I have not been more plugged in there. Brittany Ellich (26:27) True. Bethany (26:46) I was super, super excited and then I just got very overwhelmed by life and so I feel terrible about that. But do think that's something that's working for us or do you think it's something that was a cool experiment or should we continue? Brittany Ellich (27:00) I think I'd be interested in continuing it if nothing else just for like regular trying to read books, but yeah I also fell off reading it every I think reading a single chapter every week is really hard for me when it comes to book clubs because I prefer to do all of my reading in like one chunk and like get through a book in like two days and then I forget about it if I read it all at once and then don't come back and then if I try to do it once a week then it just it's it's harder for me to commit to. So we'll see. I will see. think Erica has been the one like continuously sticking with it which makes sense because she also does that with our book club. at work and she's just wonderful at, you know, being consistent with those sorts of things. So see what she has to say once we get to the end of it. And I do, I don't know, I'm kind of getting to a point too where I'm wondering if I really want to spend much more time reading more tech books. Like I feel like I've hit a lot of the big ones, you know, and they're getting to a point where they're starting to sort of repeat each other, repeat themselves. I think I might have just like read them all. I might have gotten through all the content and now it's better to spend, especially right now when you know, things are changing so quickly that relying on a book might not be the best source of information now. So I don't know, maybe that's just an excuse for my short attention span, not wanting to stick through an entire book anymore. But yeah, I think I'm kind of evaluating whether or not, you know, maybe a short form book club is a better fit for. Whatever. I don't know. What do you think? Bethany (28:39) I love that. Yeah, that's such a such a good thought. It really a lot of these books do repeat themselves. But I think also, it's the nature of the books we choose. So this is not for the overcommitted book clubs specifically, but like work book clubs. If it's difficult for people to be super plugged in and engaged when you choose a super complicated and niche book that might actually end up ⁓ delivering more insight. So I think it's just it's tough to get general interest in there when it's something super, super niche or super granular. And I think that's a really good point. Like how how do you solve for that? Do you choose? this more narrow focus over engagement or do you choose more general content that's easier to follow and having more engagement? Super tough. But I agree that Erica is the goat, the greatest of all time for being consistent and I do not know what we'd do without her. ⁓ Brittany Ellich (29:44) Mm-hmm. Bethany (29:45) Super, super appreciative of her, especially with the workbook. I ended up taking off this book just because it has been a lot to keep up with work and everything. So yeah, super appreciative of her for leading and taking ownership of that. But yeah, we'll have to see. But if anyone listening has any thoughts, please let us know. Any suggestions? Any if you've let any successful book clubs or have any dream book clubs you'd like to be a part of? Please, please leave it in, I guess, do we have a comment section? I don't know, but drop it somewhere. We'll probably see it. Tag us on blue sky. Yeah. Yes. Yeah. Mom and dad Snapchat me. Just let me know there. Brittany Ellich (30:30) Join the Discord at overcommitted.dev. You can go join our Discord. Tell us there. I love that. Bethany (30:40) Yeah, well great. I think this was a good discussion on looking forward, looking back, all that stuff. So going on to our fun segment. This was super inspired by my college roommate, ⁓ shout out Lily, who asked me this freshman year, and I cannot stop thinking about this question, but she asked me, If you could give a TED talk on anything, what would it be? So I'm gonna pivot it to be more tech focused. So if you could give a conference talk on anything, could be as serious or as non-serious as you want. What would it be? Brittany Ellich (31:16) Good question. think that, okay, if it is tech related, it would be probably something that has to do with the way that social media has been built and the way that it's impacting... humans, we just had an episode about this, and the way that I think it can be done better, giving us hope, because I've been doing more and more reading about at Proto and Blue Sky recently. I think that this is the spot where I finally want to get deep into open source commitments and things like that. So probably that. That's a really good question. If it's not tech related, I could probably give a decent talk about earthquake preparedness, because I'm... just very interested in reading about the Cascadia subduction zone earthquake potential and how to prepare for it, which is completely not tech related at all because we won't have technology at that time. What about you? Bethany (32:16) I mean, that's a good thing to be knowledgeable about, I think. There's good dividends there for being prepared for natural disasters. So kudos to you, and I am glad that I don't have to worry about that. At least that I know about. Stranger things have happened. But yeah. Brittany Ellich (32:23) Yeah. Yeah. Bethany (32:35) I did not, I came up with this question and did not prepare for it at all. But so this is off the dome. But I think tech wise, kind of tech wise, I would love to give a talk about like identity and tech and like finding your identity. It's been something that I've been thinking about a lot. think early in my career, I definitely code switch a lot. in terms of maybe acting more masculine or acting a certain way to be heard. And it's not necessarily a way that is authentic to me or that I'd want to be perceived as. So I think it's been definitely a journey of finding who I am, how I want to express myself and also not be seen as weak, not interpret, oh, feminine equals weak or anything like that. So yeah, it's just been an interesting journey and I'd love to kind of talk through things that I've learned about myself or questions I still have, things that are not fair about the industry or just aren't solvable, yet we continue. Yeah, yeah, just things like that. I'd say for non-tech things, I would love to give a talk on why Serper is the best mascot in the NFL. And I only have one aspect of evidence, but it is the only mascot in the NFL with an actual record because he did a punt return. and accidentally touched a life ball, jumped on a life ball in regulation. that is the best though, and very fun. So that would be my talk for stuff that is completely unserious, but very serious. Brittany Ellich (34:38) Yes, I'm convinced. Yeah, you've already got me sold on that, so, agree. Bethany (34:42) Yes, I mean it helps that Oregon doesn't have a football team, I guess. Well, Washington does. Brittany Ellich (34:47) Yeah. Yeah, it's very big over here. Everybody's into soccer, I feel like, on this side of the country, more so than football. But maybe I'm just making that up and it's just the tech people on this side of the country. Bethany (34:53) Yoohoo! I mean, soccer has been like really big in Charlotte recently. I just love sports. I know people get on it a lot and I understand. But also I just like, like getting behind something with a bunch of other people and being excited about stuff. Which I guess Panthers maybe haven't had much to be excited for for a long time. But I still, it's just. It gets me every time. Can't help. Like there's a win. I'm like, yes, we are going to the Superbowl. and soccer too. So fun. Brittany Ellich (35:31) That's awesome. Yeah, I mean, it's yeah. Yeah, the community behind sports is awesome. There are very few things, especially right now with streaming being so popular, you can go watch any show like ever created whenever you want. So there's very few things that are happening in real time these days. I feel like soccer or sports in general, that's one of them. And that's a great way to have community. One of the only other things that's happening in real time is like current events and politics. And that has done nothing but like divide people. So sports all the way. I don't watch a lot of sports, but I'm pro sports. Bethany (36:00) Yeah! Yay! Yeah, completely agree. All right. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. We do have a plug for a conference happening soon. Our friend, Abbie Perini, wanted us to let you all know about Magnolia Conf 2025, which is right around the corner. So grab your tickets and be part of the excitement in Jackson, Mississippi. Our catering isn't just feeding your body, it's possessing your taste buds with flavors that will haunt you long after the conference ends. Come hungry and leave spiritually transformed. Don't miss out on the spookiest tech event of the year. get your tickets for MagnoliaConf 2025 today. These tickets aren't just disappearing, they're being consumed by the void of regret that follows people who miss good conferences. Don't become part of the void. The void is lonely and smells like instant coffee. Get your tickets for MagnoliaConf 2025 today. All right, until next week, goodbye. --- ## Episode 26: Lessons from an Interim Engineering Manager with Indrajith Premanath - URL: https://overcommitted.dev/lessons-from-an-interim-engineering-manager-with-indrajith-premanath - Published: 2025-09-23 - Topics: Leadership & Management, Career Development, Product & Engineering Collaboration - Audio: https://anchor.fm/s/102586d64/podcast/play/108684112/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-8-23%2F407975624-44100-2-954853e48835c.mp3 ### Show notes Summary In this episode of the Overcommited podcast, the hosts engage in a deep conversation with Indrajith Premanath, an engineer at GitHub, who shares his journey of transitioning from an individual contributor to an engineering manager during an interim manager role while his manager was on leave. Indrajith discusses the challenges and lessons learned during his six-month stint as an interim manager, emphasizing the importance of team dynamics, transparency, and personal growth. The conversation also touches on career aspirations, technical interests, and the significance of building strong relationships within a team. Indrajith offers valuable advice for future managers and reflects on his childhood aspirations, providing a well-rounded perspective on his career journey. Takeaways * The shift from coding to management requires a change in mindset and priorities. * Building relationships with team members is crucial for effective management. * Transparency in decision-making fosters trust within the team. * Indrajith found that he became a better individual contributor after his management experience. * Understanding team members' career goals enhances team dynamics. * Indrajith emphasizes the importance of long-term planning in management. * He advocates for rotation programs for aspiring managers to gain experience. * The role of AI in coding is changing the landscape of software development. * Indrajith's childhood aspiration was to be a theater kid, not a software engineer. Links * Indrajith Premanath LinkedIn [https://www.linkedin.com/in/indrajith-premanath-42584751/] * Charity Majors Engineer/Manager Pendulum Article [https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/] * ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠⁠ [http://overcommitted.dev] * ⁠⁠⁠⁠Brittany Ellich⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠⁠⁠⁠⁠⁠Eggyhead⁠⁠⁠⁠⁠ [https://github.com/eggyhead] * ⁠⁠⁠Jonathan Tamsut⁠ [https://infinitely-fallible.bearblog.dev/] ### Transcript Erika (00:00) Welcome to the Overcommit podcast where we discuss our code commits, our personal commitments and some stuff in between. I'm your host this week, Erica. Join by. Brittany Ellich (00:09) I'm Brittany Ellich. Jonathan Tamsut (00:10) Hey, and I am Jon Tamsut. Erika (00:13) We are a group of software engineers who initially met working on a team together at GitHub and found a common interest in learning and building cool things. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we are happy you're listening. This week, we are talking with Indrajith Premanath, an engineer at GitHub. We work in the same organization and quickly realized that we were in the same position of not being interested in transitioning out of the technical contributor career path, but temporarily flexing into management as a result of circumstance. He has done a fantastic job juggling both responsibilities and we are excited to learn from his experience and approach. So welcome, Indrajith. Indrajith Premanath (01:01) Hello, thank you for having me. My name is Indrajit Premanath. I've in GitHub for the past five years now, and I came through Microsoft, and I've been at Microsoft two years previously before that, and I've been in IC all my career until starting last January, where I was kind of being an interim manager for my team while my manager was on parental leave. So that was the circumstance that led me to kind of be in that position for six months period, around five months, yeah, 20 weeks. And yeah, I think I'm excited to share about things I learned, things I could have done, should have done, and how it kind of changed my thought process and my career goals after going through that process. Erika (01:50) Very cool. So you mentioned you took this on for six months. So can you kind of briefly describe the roles as an engineering manager as compared with your developer role? What were kind of the differences in your day to day? Indrajith Premanath (02:06) Yeah, I think it was definitely a tough transition going from a IC to a engineering manager in the same team that you've been for the last five years, especially whenever I think as an IC, your intuitions or your gut reaction when you see a problem is to simply jump in and try to solve the problem and not necessarily think about how to prioritize this and how where does it land with existing priorities. But as an engineering manager, I think the first task of me to suppress that feeling is that, I'm going to go and fix this. Instead, trying to see how I need to be triaging it and finding the right folks at the same time, finding the time to do the work. think that is the first part of transition that was hard for me is like, how do I stop writing code as much as I would like to? ⁓ and then I think then finally, I think also as an IC, it's usually common to grab onto opportunities that come out as a problem. but now it is your job and responsibility to share that opportunity equally across your team and finding the right people. And also there's no favorites to play. Everyone needs to get the right opportunity. regardless of the outcomes are, because I think that is the most responsible part of an NGA manager is to find ways to improve as well as get the people the right opportunities to meet their own career goals. And ⁓ something to touch on, I think, at the end was how that career goals are met with those individuals when you have the conversations about promotions and reviews and that kind of is the fulfillment part at the end. Erika (03:52) It's really interesting to hear you describe the first part of the mental model you have where you're finding the time and making sure that you make sure the tasks are in the problem areas are clearly defined and dedicated and well assigned and it kind of reminds me of the things that I've been hearing lately about the process of like using AI assistant coding where it's like, how do you succeed with AI? It's like you clearly define the tasks, you find the right, you know, context, you, um, you know, find the right agent to do it. And it's like, Oh wait, that's actually also very good for software engineering in general. So it's kind of funny. It's like same rules apply. Nothing really changes, but, um, yeah, as you mentioned. when there's an aspect of people and element of people, there's also taking into consideration their goals and their mindset and how to communicate with them. And yeah, the person communication part of it is super important. So curious, did you prepare at all for taking on these responsibilities and if so, how? Indrajith Premanath (05:01) Yeah, think so. One of the interesting thing is my current manager has been my manager for the last seven years, so I've been with the manager for the seven years period and I have had shorter stints as an interim manager throughout that time when when they're on an extended leave or a vacation for like two to three weeks period. So definitely I was a lot more exposed to this in a shorter period of time than taking on the responsibility. And I think the key difference was those shorter period is more of like holding the fort. You ensure nothing goes necessarily bad. You know, this person is going to be back in two weeks. So I hold my breath for two weeks. Everything will be fine. Whereas when it becomes a six months period of STEM, is not necessary. They're not coming to save you after two months. I call this the first two months as I hope I run into my manager at my Costco face. because my manager lives like 15 minutes from where I live. So I'm like, every time I go to Costco, I'm like, hopefully I ran into Billy today and asked these problems and hopefully he would have an answer. And spoiler alert, I never ran into him. But I think that is the transition where maybe a month or two after you realize you are kind of on your own in that extent. There's a support structure always in your organization, but that one person who always comes to save you at the end is no longer going to be there and you have to do that work. So the preparation, think one of the things I did as a result is I spoke to lot of interim managers who had, was in a position who for a long period of time within our organization and outside to get an understanding of how to get kind of my footing and like what kind of conversations to be part of. And then also maybe not something I actively thought of as I see. but having much more strong relationship with my product side of things to understand the priorities and what needs to be done. And it resulted in me having a weekly one-on-one with my product manager on understanding what needs to go on within the team so that I have the opportunities understood. also, and the thing that I've... I'm kind of grateful for this opportunity to think more about long-term than the short-term. As a engineer, I'm like, I'm going to do this for two weeks. I know what I'm doing. Whereas now I have seven engineers who are looking for opportunities and work and I cannot just have two weeks plan. I need a longer plan in order to be able to give them the right opportunities. So I think initially having conversation with people who have previously gone through this and then kind of It's a self-realization too. like, okay, I'm in this for long term than just two weeks. So like, I need to kind of fold my sleeves and kind of get into this. And I would say I'm not, my organization is very open to me being failing and figuring things out than being, because the first part is like, I'm going to be like my manager. So I'm going to do everything like my manager. then eventually you realize your manager has certain characteristics and traits that allow them to be the way they are and be successful. But that doesn't necessarily apply to you even though you try to replicate that. So you find your ways to be successful in your own terms. Brittany Ellich (08:12) That makes sense. makes sense. I'm curious what you learned overall from this experience. I mean, has this like changed your opinion on what you want to do if you want to be an individual contributor more than you did before or, you know, has this decided, I want to go into management or anything like that. Indrajith Premanath (08:25) Mm. Yeah, I tell this to people that I actually came out of this experience as a better IC than a manager that I would be. think personally, I realized I relied on my manager for everything that requires me to move forward in my career to an extent and also not necessarily knowing what to do next. Maybe you all can relate to this is also. When I became a senior engineer, would say I was lost for like two years, especially because I consider upon the senior, the path is well paved. A lot of people have gone down that path and there's just checkboxes that you find that you tick. And it is relatively known how to get your career growing from that point. But once you become senior, it becomes choose your own adventure kind of a thing. In that state, I was still kind of relying on checkboxes to exist for me to kind of grow. That's the last two years, but, and then the realization is now I need to find ways that I want to grow my career because no one is going to tell me what to do. And now one of the part of that growth comes from how much value you bring to the organization and how do you find the problems or the. issues that you could solve to bring that values. And I noticed that I more, I was more exposed to those problems and issues as a manager than I was at an IC and which allowed me to understand the mediums that I could look at to find the problems and issues in order to solve problems. Because end of the day, bringing a cool technology into our infrastructure, our environment is not the most valuable thing to do unless if it's not gonna solve a particular problem. And for me, I was struggling to find the problems that needs to be solved. And usually my manager was my funnel to share the problems. And at that point, I'm doing what I'm told to do, then suggesting what needs to be done. So I think this experience gave me to find avenues to... expose myself to find those problems, to find where in career that I want to grow into. So definitely I came off as a better IC. And then I think Erica touched on it as well, where with the whole democratization of AI, the last phase of our software development lifecycle, which is coding, has become not necessarily the most important thing to be done. It has become the last step now an AI could somewhat do it to an extent. So the initial step of things is what became the most important thing. And now that becomes where your relationship with your product manager, your team, your leadership kind of sculpts that initial set of things. So I think that is another part where I am more exposed to the process and also the skillset required to build that first. face of things to get to the final stage. So that's why, selfishly, think I became a better IC than I am a manager. And to say it out loud, I am still continuing thinking about computing being an IC for foreseeable future until a different opportunity comes along. Brittany Ellich (11:44) Makes sense. Yeah. I'm a huge supporter of having a close relationship with your product manager. I feel like that just makes so many teams work better when engineers and PMs work closely. And for what it's worth, I'm a huge shill too for charity majors. And she has a really great article about the pendulum between. Indrajith Premanath (11:52) Mm-hmm. Mm. Brittany Ellich (12:02) ⁓ engineering and manager and she actually recommends you you do switch back and forth frequently and you become a better engineer and a better manager by doing so. So it sounds like you had a pretty similar experience there. So that's cool. That's cool to hear. Indrajith Premanath (12:15) Yeah, I might have a controversial thought where I think there should be a form of rotation program where people who are interested in being a manager should be given that opportunity. I think I was lucky enough to be in a circumstance that allowed me to be in that position for six months. this, even though I was responsible for six months, I still had no strings attached. I still had like after six months, if I made a mess, my managers probably come in. clean it up, that allowed me to take more risks and take more steps that I probably wouldn't have done. So I think allows me to kind of understand what this role actually entails. So I think with this asterisk of if interested, there should be a rotation program. Erika (12:57) Are there any like skills or like aspects of yourself or your career that you think made you the candidate that was chosen for this or did you express interest explicitly? Indrajith Premanath (13:09) I've been expressing interest explicitly that eventually in my career, I do want to go down the management track. And that is why when such opportunities come, I do express interest in taking those on. So yeah, I think that's usually one of the things that resulted in this. And yeah. Brittany Ellich (13:29) I'm curious too related to that. So you had mentioned that you were as the interim manager, you were responsible for finding those opportunities for people that you were working with. Has that changed the dynamic at all? And like the team that you're working with now that you know, I mean, you had the experience to spend time with everybody on your team to figure out their career goals as well. Has that been useful to understand their career goals as an IC again on your team or has that, has that helped at all? Maybe that's a. Indrajith Premanath (13:36) Mm. No, most definitely. think one of the things that I was previously doing as an IC is that whenever I see an exciting project, my first thought is, I should be on this. I think this is a great opportunity. I'm going to learn a lot of things. I'm going to add value. then if you have a good manager, it's not always where you always, you are the only person who's getting the opportunity. The manager ensures that everyone gets equal opportunities. That's how my manager asked me. And so that always comes with a disappointment that where, ⁓ I would love to work on this project, but obviously this is going to go to the other person because of XYZ reasons. And now I understand it better when a certain opportunity is given to another IC. It's not necessarily a reflection of my ability or my competence on whether I could succeed doing it. It's more of Everyone needs that opportunity to provide value. And it allows me to support them a bit more. I'm supporting them to reach their career goals and they're fulfilling their needs than just only thinking about myself. And that builds more trust within my team where when I'm jumping in to solve a particular problem in someone else's project, it's not a threat. It's more of like, let's work on this together to solve this problem. So I think that switch kind of helps me build better relationship. And to be fair, I used to hold one-on-ones with everyone in my team as an entry manager on a weekly basis. And since now be becoming an IC, we still hold a monthly, at least one-on-one that relationship keep going so that the trust it builds. also as a person told me. You're always bad for your team. So that's how I'm seeing this new role of myself as an ICS in this. Erika (15:47) I don't know about you, but I think for me, I realized like the mindset shift of caring about the project versus caring about my individual contributions to a project. And I never thought of myself as this kind of like selfish person, but I realized like, as an IC, I care more about my pull requests than other people's. And now I care about them all equally. Like if there's a request review, you a review request, like that is as important to me as like getting my PR through because they're all important for the sake of the project moving forward. And like, yeah, I completely shifted that, ⁓ like that prioritization of my mind when I'm like, no, Indrajith Premanath (16:26) Mm-hmm. Erika (16:30) It doesn't actually matter as much like what I do. It matters that the project moves forward and like really focusing on the team and the project level. Indrajith Premanath (16:39) Yeah. And I would say the most fulfilling moment of, I would say my career at this point is when a person got promoted in this review cycle in my team, when I worked with them in their promo packet, they were working with my manager all along, but I was fortunately at the point where my manager is not around for the, need to take that promo pack to the conversations. And then they actually got the promotion. It's much more fulfilling than when I got promoted. I think that is where the transition happened is like. It is not worth being selfish at this point and it's you score as a team. think that's what I learned. Jonathan Tamsut (17:12) So, kind of stepping back, how did you get into the kind of software programming or how did you decide that that's what you want to do with your crew? Indrajith Premanath (17:19) Yeah, I did not grow up thinking I'm going to be software programmer. I grew up in Sri Lanka. So I was so we did not have a computer until I was like maybe 13 years old. And also the computers were expensive back there. I was so scared to turn them on because if they don't turn on, I have broken it. So I'm going to be in trouble. So for the longest period of time, I didn't necessarily was exposed to computers much. And even when I did, it's usually to play video games or like be on the internet, nothing much. But my reason for joining the computer science program and I did is mostly my brother was doing computer science and my bunch of my cousins were doing computer science. And I was like, okay, it seems like a family thing. Might as well do the computer science part. And my brother was going to the same college as I was in University of Minnesota. So I'm like, I have someone to support me if I was struggling. So then that kind of made the choice easy for me to pick computer science. And then eventually I liked it and the career that it leads to seems very fulfilling. And so I just decided to take that on. Jonathan Tamsut (18:29) Cool. And no, that's awesome. has there been any, I guess from a technical perspective, is there anything you've learned along the way that you found really valuable, or do you have any particular technical interests that we've been talking a lot about, sort of the softer side of things? Indrajith Premanath (18:46) The recent technical interest has been mostly about, I usually never thought about physical constraints of software development. It's mostly been, I'm going to write this code and push it. If it's any issues, infrastructure team needs to figure out how to scale or how to improve our efficiency and our performance. But with recent initiatives that I've been part of, that's something new that I was exposed to that I'm being interested in. It's an ongoing conversation within my team to think about a physical constraint of your changes that you make, not just the code. So that's something that I've been kind of getting myself exposed to and kind of getting more understanding. So if any reason interest is probably be not just writing code and like what are the consequences of my code in more in the physical constraint infrastructure terms. Jonathan Tamsut (19:37) Yeah, that's That's super cool. Erika (19:40) Last question for you. For anyone who does end up taking on management responsibilities, what advice would you give or if you end up doing this in the future when you end up becoming a manager, what advice would you give to ⁓ your future self or anyone else interested in taking this kind of role on? Indrajith Premanath (20:01) I think the most important thing is transparency. One of the things that I realized as sooner than later is that I'm trying, I was trying as a function of protecting my team, I was trying to not expose them to anything that could potentially not result in good feelings in like to ensure that I kind of first get exposed and try to contain that. then understand, then kind of filtering it through. Because I think when a decision is made about and comes down the track, you are exposed to it first. And if you are just going to communicate the decision to your team, not necessarily explaining why a certain decision is being made, that you not necessarily will build trust on that your decisions are coming off of valid reasonings. And soon I realized being transparent about why I am making this choice or why is this decision being made and being transparent about the reasoning kind of helped my team to kind of rally with me than just also put friction back thinking, I don't want to do this. But if I was able to explain the value and also the reasonings behind a specific decisions that kind of helps them support me as their manager. So I think that is one thing that I would advise to be more transparent. I think everyone is definitely welcome more information to understand a specific decision. So I think transparency is definitely important. I think the relation, more than the technical sides of like prioritization, interesting projects, the relationship you build with the individuals within your team kind of helps you. progress differently than just shipping things. I think end of the day, a well cohesive team that understands each other can produce more stronger and like consistent results than just having them work on things without such relationship. So I think definitely that one of the reasons why I'm continuing those one-on-ones with individuals is to build that relationships. So I think transparency, ⁓ Building those relationships is the most important part to be successful because something my manager tells me is once your intelligent network matters, the people around you tells you when you are screwing up or they tell you when you are doing something well that helps you align yourself in a better position than you kind of having that blind eye on, I'm doing things that make sense to me. I'm not going to hear about anything. Everyone should kind of would understand doesn't really work. think having those people trust and tell you, hey, your decision did not make sense, or can you tell me more about the decision leaving that safe space helps. Erika (22:48) a great reminder and hopefully these conversations are helpful for anyone who doesn't have that kind of community. Maybe is looking for first some voices to talk through with what they're going through and yeah thank you so much for sharing about your experience and what you've learned. So We've been talking about sort of career paths and career goals, and you mentioned that you did not want to be a software engineer when you were little because you barely had a computer. So our fun segment today is saying what we did want to be when we were younger. Indra, just do you want to start us off? Indrajith Premanath (23:26) Yeah, sure. So growing up, I was a theater kid. So I was participating in lot of plays. was directing a lot of plays. So growing up, I wanted to get into movie industry, specifically the Indian movie industry. That's one of the reasons why I also ended up doing a bachelor's degree is because I was a specific movie director who I wanted to work under, had a requirement. that anyone who wants to join him as an assistant or associate director needs to have a bachelor's degree. So I was like, okay, I'll do this bachelor's degree and then probably go back home and then eventually to India to like join the movie industry, not in a specific role, but eventually if you find my way there. But my interest was to be in theater arts. And that's the first thing I told my college advisor. like, I'm doing computer science, but I would love to also major in theater. And they were, apparently I was the first person to have that combination in that group. So that was my career aspiration growing up. Erika (24:26) Do you do any theater for fun now? Indrajith Premanath (24:29) Unfortunately not, but I do go see a lot of plays and musicals. I'm exposed to musicals now, which was not a thing back in Sri Lanka. I'm definitely, to be honest, I do look for opportunities. And my, one of the, my idea is to potentially join an improv group to see how bad that takes. So we'll see. Erika (24:47) also a music major in college so we could team up and do a software development themed performing arts. Indrajith Premanath (24:52) Yeah. Deal. Jonathan Tamsut (24:55) I've heard Erica sing and she's pretty good actually. Erika (25:00) Thanks, Jon. Yeah, on the street, right? That was the offsite. Jonathan Tamsut (25:06) You busted it out, no vocal warmups. was impressive. Erika (25:10) Yeah, yeah. Well, cool. Yeah, funnily enough, I did not actually want to be a good actor when I was little, even though that was basically all I ever did was like run around singing and dancing and doing dress up. But I wanted to be either a florist or a dolphin trainer. Those are my my two aspirations. Indrajith Premanath (25:30) Mmm. Erika (25:32) Yeah. Brittany Ellich (25:33) That's cool. I feel like marine biology is a phase that a lot of kids go through very interested in working with the whales. I really wanted to be a veterinarian and I am not that now, but that's okay. Jonathan Tamsut (25:45) Yeah, and I wanted to be like an inventor or a scientist. I liked Legos and wanted to build stuff. Erika (25:53) Did you ever have like prototypes or like invention ideas? Jonathan Tamsut (25:57) as a kid, I mean, I built stuff with Legos and I would like, yeah, I don't remember any specific like invention ideas that were novel, but I've always, I remember being little and always thinking about teleportation because I live in, I grew up in LA and traffic was terrible and I was like, someone needs to know this. Indrajith Premanath (26:15) You Brittany Ellich (26:16) I was, I went through an inventor phase and the one invention I can remember that I worked on was I wanted to build a hoverboard and I was like, I just, I'll just take like the workings of a hot air balloon and put it on a skateboard. And I know I was like, this is genius. Why has nobody done this yet? Like it's gotta be so easy. And that's also, I think how I approach software building as well. Why don't we just take this piece that's completely unrelated and put it on this thing. It'll work. It'll be great. Erika (26:32) you you Indrajith Premanath (26:43) Yeah. Erika (26:43) What could go wrong? I think you probably know a little bit more about software than kids' science brains. sometimes it does feel that way. Awesome. Well, a huge thank you to everyone and especially to Interdict for joining us. If people want to find you, where should they go? YouTube, Blue Sky, website. Brittany Ellich (26:51) Valid. A little more than physics, for sure. Indrajith Premanath (27:08) I think the best way would be LinkedIn. I think that's the best way to find me. Erika (27:12) Cool, we'll include that in the show notes. And thank you listeners for tuning in. If you like what you hear, please do follow, subscribe or do whatever it is you'd like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. As a reminder, we are still now solidly in the middle phase of our Looks Good to Me book club, which means that there is still plenty of time to get involved. You can start in the middle. You can start at the beginning, whatever you want to do. So check out the show notes for more info on that. And until next week, goodbye. --- ## Episode 25: Developer Advocacy with Annie Sexton - URL: https://overcommitted.dev/developer-advocacy-with-annie-sexton - Published: 2025-09-16 - Topics: Developer Experience/DevRel, Non-traditional Paths to Tech, Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/108223572/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-8-12%2F407388654-44100-2-a8fd839119012.mp3 ### Show notes Summary In this episode of the Overcommitted podcast, host Brittany Ellich and co-hosts Erika, Bethany, and Jonathan Tamsut engage in a conversation with Annie Sexton, a developer advocate at fly.io. They explore Annie's unique journey into developer advocacy, her approach to education and community building, and the importance of teaching techniques in the tech industry. The discussion also delves into the role of AI in learning and development, as well as personal interests outside of software engineering, highlighting the multifaceted lives of software professionals. Takeaways * Annie Sexton transitioned from software engineering to developer advocacy through her passion for education. * Developer advocacy involves community building, education, and marketing to developers. * Education is a powerful tool for building trust with an audience. * Asking basic questions is crucial for effective teaching and learning. * AI can be a valuable resource for research and learning, but fact-checking is essential. * Understanding the audience's knowledge level is key to effective communication. * Annie emphasizes the importance of storytelling in education and advocacy. * The journey to becoming a developer advocate can be unconventional and varied. * Engaging content can attract a wider audience beyond just product promotion. * Personal interests and hobbies contribute to a well-rounded life as a software engineer. Links * ⁠ [https://youtu.be/zN-rElTzR_4?si=2b0iQF6LKV3CGDpp%E2%81%A0%C2%A0]fly.io [http://fly.io] * fly.io YouTube channel [https://www.youtube.com/@flydotio] * Annie’s YouTube channel [https://www.youtube.com/@AnnieSexton1] * Book: Deep Learning A Visual Approach [https://www.glassner.com/portfolio/deep-learning-a-visual-approach/] * Book: A City on Mars [https://www.goodreads.com/book/show/125084292-a-city-on-mars] * Show/Book: The Expanse [https://www.goodreads.com/series/56399-the-expanse] * Bluesky: @anniesexton.com [https://bsky.app/profile/anniesexton.com] * Bluesky: for Annie’s comics [https://bsky.app/profile/anniecomics.bsky.social] * ⁠⁠⁠⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/4enG8EQaMr] Hosts * ⁠⁠Overcommitted.dev⁠⁠⁠ [http://overcommitted.dev] * Bethany Janos [https://github.com/bethanyj28] * ⁠⁠Brittany Ellich⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠⁠⁠⁠Eggyhead⁠⁠⁠ [https://github.com/eggyhead] * ⁠Jonathan Tamsut [https://infinitely-fallible.bearblog.dev/] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted podcast where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Brittany, joined by. Erika (00:11) Erica. Bethany (00:11) Sorry, hi, I'm Bethany. Jonathan Tamsut (00:13) And I am John. Hello, everyone. Brittany Ellich (00:15) We are a group of software engineers who initially met working on a team together at GitHub and found a common interest in learning and building cool things. We continue to meet and share our learning experiences and discuss our lives as developers. Whether you were pushing code or taking on new challenges, we are so happy you are listening. This week, we are talking with the illustrious Annie Sexton, a developer advocate for fly.io and YouTube content creator, explaining hard to understand software engineering concepts in simple terms. Welcome, Annie! Annie Sexton (00:50) Hi, it's good to be well, yeah, I'm a developer advocate. I, and my, my flavor of developer advocacy is mostly YouTube content. And I actually secretly have done this for many, many years, not related to tech at all. I, I meant, I had a couple of channels that I tried to get off the ground, had some progress, you know, I learned a lot of things, learned what not to do. And when the opportunity arose at fly, I jumped at it. Brittany Ellich (01:16) Did you work at Fly before doing the YouTube content creation, or did you? Annie Sexton (01:21) Yes. So it's actually a little crazy. I was hired as my title was, what is it? JavaScript specialist, whatever the hell that means to write blog posts about ⁓ JavaScript and to get the JavaScript community excited about using fly. And then last summer we decided to do a shift to video. And because I had had that experience building those YouTube channels, it was the most like hold my beer. moment of my entire career and my first video went viral and it was great which is like I cannot say that all of my videos meet that kind of success but it was it was very hair flip kind of it felt really good and it's been really really fun to do it I feel so lucky that I just accidentally fell into this role and now it's absolutely transformed my career Brittany Ellich (02:13) That's cool. Have you always been in developer advocacy then or what was your journey to get to this point to fly? Annie Sexton (02:18) No, this, this role at fly was actually my first dev rel position. before that it was mostly just software. It's just straight up software engineering. I did work as, ⁓ a support engineer at Heroku back in the hay days, back when it was cool. no shade to Heroku now, sorry y'all, but it was, I learned a lot about software development through support engineering. basically all the things you're not supposed to do, I learned about. And I personally think support engineers are wildly underrated because the amount of knowledge they need to know is so much more in depth than any one developer. But that's mostly been my career is mostly software engineering, a little bit of support engineering. And I only recently started to do dev rel in the past year or two. Brittany Ellich (02:57) Yeah, absolutely. Erika (02:58) Absolutely. Yeah, mean, the interacting with customers is like another piece of the support engineer tool set that, yeah, like internal engineers don't even have to think about. And there's a whole like, yeah, art to having those support conversations and getting the information that you need and finding it out and. getting all the pieces together. I have mad respect for support engineers and anyone who's done it. Annie Sexton (03:38) takes a lot of patience. Brittany Ellich (03:39) How did you go, for sure, for sure. How did you end up in like the software realm? Did you go to school for computer science or what was the path to get there? Annie Sexton (03:50) I did not go to school for this at all. My major in college was international studies, which was useless. So I took a really strange path to get here. I taught English in Japan right out of college. had a horrible experience. I love teaching, but I had a horrible boss. It was like a really manipulative abuse of the work environment. And a friend of mine who... I'd gone to, I'd studied abroad with in Japan. He knew that I had had a little live little live journal blog, a little, I knew a bit of HTML, knew how to make things bold and italic. And he was like, Hey, you had a live journal in college. Do you want to, we're hiring for a web developer role. Do you want to like learn the rest of it? And I was like, Oh, okay, sure. So bless his heart. He taught me the very basics of CSS and JavaScript and helped me get my very first job as a web developer in Osaka. And I barely knew how to write a for loop. My interview was all in Japanese with a Spaniard. It was mostly, so it was a localization company. So most of the, most of the people who worked there were foreigners. but the lingua franca was Japanese because the few Japanese people they did employ didn't really speak English. Everyone else, I mean, my Japanese was like, I thought my Japanese was okay. And then I come into this localization company where everyone is fluent beyond words. And yeah, anyways, so it was a really, it was a small and scrappy company. It is near and to my heart, even though the working conditions were kind of terrible. I actually took a 30 % pay cut. from being an English teacher to get that first job, my friend who helped get me this job, just on a whim, this was when Ruby on Rails was getting really popular, and he was like, well, we need a new corporate website, so let's try Ruby on Rails. And I was like, ⁓ so do you know Ruby? No. ⁓ I barely know how to do programming, so we just gotta learn together. We did everything the wrong way. Like we built our own auth, we built our own pagination, we built our own, like they had gems for these things back then, but we were like, nah, nah, I'll just make it myself. It was bad, it was very bad. But I learned so much, was drinking from a fire hose every single day, but it was, it paid very, very little. And I lived in the smallest apartment you could ever imagine. I've seen walk-in closets bigger than what I lived in back then. But it was delightful and it was such a good experience for me. And then I moved back to the States after about a year of working at that job, a little less than a year. And I just started working at random little agencies, got into WordPress. I feel like a lot of people honed their skills in the WordPress days. A lot of love to WordPress. I will never touch it ever again, but I learned a lot of things. And that's kind of how I got into things is just through that one weird job in Japan. Everything I've learned on the job. Bethany (06:56) That's awesome. What a cool journey to getting here. I feel to even though there is there were probably gems to do all those things, you probably learned it better than anyone who else who was doing it by hand rolling all of that. So really cool. Looking at what you do today, curious if you could maybe describe to folks what what is a developer advocate? ⁓ So how would you define your job to somebody who might not? Be familiar with that and what's your day to day look like? Annie Sexton (07:23) So the question of what is a developer advocate is hard to answer because everyone's going to give you, you ask 10 different developer advocates are going to give you 10 different answers. But I think the themes you will hear are, it's about community building. It's about education and it's about building relationships with your target audience. And I do say target audience because let's be honest, it's a marketing role. It is a marketing role. I think a lot of developer advocates kind of shy away from that term because they're like, no, we just want to be buddies with our customer. Like that's not not true, but like, we're paid money to sell you things. Like that's, that's not not true. think. so that is part of it, but, ⁓ you can't market to developers in the same way as other people. not to say that like we're so special, but, but truly like you can't, it's a much harder to bullshit us and. we're very, I would say, untrusting of a lot of of sparkly kind of marketing words. I think there's a reason why we'll get to AI in a second. But I do think that I would be surprised if the AI marketing tool is actually working on developers specifically, maybe other customers, right? But like, developers are a lot better at smelling BS. And so the way you basically appeal to them is by gaining their trust, right? And showing that you are an authority on a particular subject and you educate them and you pique their interest, right? And that's really at the core of really good developer advocacy. And I would say good marketing in general. Like I think that's marketing done well in a non- schmarmie way, you What I do is very specific. Some developer advocates give a lot of talks at conferences. Some of them write blog posts. I do YouTube. Again, I just sort of fell into this role. It's kind of crazy and I'm pretty good at it. I am a big believer in education as a tool to gaining trust in users and Even though I really didn't like that particular English teaching job that I had, I have always been a teacher at heart. I love, love, love teaching. I have infinite patience for it. I would definitely consider myself a Jack of all trades, except for when it comes to teaching. There's very few skills that I'm like, yeah, I'm I'm stellar at that. My ego is like way up here on my teaching abilities. I feel very confident in that, which is... really nice to have like one thing that you can actually feel that confident about. And it's something that really brings me joy. And I think a part of that passion for education comes from the fact that I had to learn all this stuff myself and respectfully, developers are terrible writers and terrible educators. Not all of them, obviously not all of them, but many of them are. And I found I had so many questions that were just never addressed. There was so much assumed knowledge. Obviously you have to assume some amount of knowledge. Like if you've got this repository on GitHub that you want people for a library, there's an assumption that you know how to use Git, right? To get the files, you know? So there's like some assumptions that are understandable, but I think more often than not, people do not cater to the appropriate level in my opinion. And I would much rather cater to a lower level, ⁓ like, not even lower level, lower level of experience than is necessary because it makes it easier for other people to understand, right? Everyone loves a explain it to me like I'm five kind of thing. like no one doesn't enjoy those things even if they already understand the material, I think. So I think giving people a, you know, an entertaining format to learn things, sometimes things that you didn't even know you wanted to know is a really great way of building a relationship with the audience that you want to target. And in the case of Fly, I mean, I do make videos more specifically about, check out this cool product. I literally just an hour or two ago, I published a video on our new managed Postgres service. You should check it out. Or that one was more just like, look at this product. at me. Isn't it amazing? Right. Just sort of that's, that's more like basic. Look, we were selling you a thing, but many of the, in fact, most of the videos are me explaining a weird thing about the platform that honestly, you don't even need to know to use fly. It's just kind of like, Whoa, look at this weird thing we did with the CLI. We created our own like IP protocol in user space so that we can proxy this, that, and yet it's It was very, very, it's very, very cool stuff how we make things behind the scenes. So I like to do a lot of how the sausage is made kind of videos because for the most part, when it comes to company videos, you know, you kind of have to minimize the number of videos that are all about your platform. As weird as that sounds, because largely people don't care, you know, And I think that piquing people's interest and that like that, those are going to be the people that will return to these videos that will return to the channel. There's plenty of people who don't even use fly yet that are subscribed to the channel because they just like to learn these weird little things that we do and they're super fun explainer videos. So I think focusing more on education, more on entertainment. is a really great way of building an audience that really values your content and doesn't just feel like, here's another video trying to sell me a thing. So that's been my approach and I really enjoy doing video. It's also a great place for me to, I have a lot of different skills. Like I said, jack of all trades and it's nice to have a, an avenue to use all of my skills in one place. That was a lot. Bethany (13:21) soon. No, that definitely makes sense. And I really love that philosophy. I mean, that's why there's a lot of student programs for software. So students learn how to use these tools and learn their skills through these tools so that when they go into the workforce, they end up using them. So I think education truly is the best form of marketing in a way. Definitely makes sense. Also, I have been a huge fan of Fly's blog post for a while, so I can totally see the videos being an offshoot of that and a really good way to start branching out. Very cool. yes. Annie Sexton (13:48) you Jonathan Tamsut (14:04) I'm really interested in like education. used to teach, pro you know, web development and computer science. ⁓ And I guess, like what makes a good teacher to you? Like what are techniques, skills, books? I don't know, they're just like philosophies around teaching. Because I think, yeah, there's like so much there and I think so much of education is really bad. Like so much of our sort of historical practice is bad. Annie Sexton (14:35) Right. I think a lot of it comes down to really knowing who you're talking to and not assuming that they know very much. This is gonna sound a little harsh, but I always think of targeting my videos towards a like, can a mid-level, maybe even like early career JavaScript developer understand this? No shade to JavaScript developers, I am one, so. But I just think of just like your normie. I know some Next.js kind of JavaScript developer. If they understand what I'm talking about, then I've done a good job. I think too often we... will try to jump to the complicated stuff without building a ladder for people to follow you. And I think I've just been very good at having to ask the stupid questions along the way. This is where I'll admit, so I use a lot of AI in my research. I always start with human written articles, books, things like that when I'm learning about a particular thing. I always, always, always start with that. And then as I'm reading, if I get stuck on something, I'll go to like Chagy BT and be like, Hey, I'm reading this article. It's saying this thing about connection pooling or whatever, but what does XYZ like? This sounds like this other thing. What's the difference between these things? I'm really, really good at identifying my points of confusion. And I know that if I'm confused about a thing, someone else's too. I'm trying to say this in the most delicate way. Sometimes I think that. I don't always, like whatever amount of like stupidity I have, I mean, I'm not actually trying to like be self-deprecating here, but it's actually a good thing when you feel confused about something because that means that, especially as a teacher, it means that, ooh, there's a question there. And that's a question I need to answer for the people I'm teaching, right? And so I think, in the past, my inexperience, my, you know, all the imposter syndrome that you, you know, have to work through as a developer, everyone deals with it. That's actually to your benefit is don't ever try and gloss over something that you don't fully understand. Dig into it, dig into it, dig into it, dig into it. And, and don't, I don't, really try not to gloss over a lot of things because I think when you do that, then you're like, you're missing out on some questions that people will. So ask the stupid questions. Ask the stupid questions, because they're not stupid. They're not actually stupid. And I think that is where you get a better like, I want to say curriculum. I'm not making curriculum, but you know what I mean? It's easier for people to follow what you're talking about. Don't assume anything. Jonathan Tamsut (17:16) Mm-hmm. Yeah. Yeah. Yeah. What, thing I've been kind of seeing a lot more, and I think it's like, especially for technical topics is like kind of what you said, like building up like a semantic tree, like there's like, cause I think, yeah, like you mentioned like connection pooling, like it's hard to understand connection pooling if you don't know what like a thread is and if, like, in order to understand a thread, you just like what is operating system and what's the CD, like there's like all these concepts that will kind of need you to understand. I think traditional learning doesn't address that. It doesn't try to like really fill in these gaps and like, build the semantic tree of concepts that you need in order to add a leaf node. Annie Sexton (17:53) Yeah, actually one of my favorite videos that I made on, have a, so I have the fly.io, I have the fly.io YouTube channel and I also have a personal channel that I occasionally post to. It's kind of shifted to more AI machine learning related topics. ⁓ Like I recently did a video on tokenization because I find that really interesting, but a while back, I actually did a video on run times and like what the heck is a run time. Erika (17:53) Yeah, I think it's an important. Jonathan Tamsut (17:53) ⁓ Cool. Annie Sexton (18:18) We hear this all the time, the JavaScript runtime, the runtime. And you're like, what is that? What even is that? And I think that it's those kinds of terms that we just take for granted. And it's not always possible to address those things in every single video, but I, that is what I find really interesting. You know, what's an engine, right? What counts as an engine? You know, how much of these are specific? that are more color wheeled to a language versus like, is this a specific thing in computer science in general? What is this? Like, we like to pretend that certain words are concrete things and they just are not. That, you know, some of them are, but not always. Even the term threads doesn't always mean the same thing. You know, it's bonkers. So I think that is the kind of level of specificity that I love to get into of like, okay, so we keep saying this stuff. We pretend like we know what we're talking about, but do we really? Let's break it down. That's the fun stuff. Erika (19:23) Yeah, it's interesting kind of zooming out on like software language as a whole and like, I don't know, this is probably like a whole other topic of like confusing software terms that like sound like one thing but actually mean something else. Because a lot of, I mean a lot of soft, basically all of software like came from somebody's head. Like there are like physical restrictions to computing but like most of like the concepts are created from like, hey, I had this mental model of how this thing is supposed to work. And so I attached this term to it because that's what made sense to me. But a lot of times, I mean, maybe not a lot of times, but sometimes, you know, it doesn't always translate to like somebody else's mental model. So like you mentioned threads, it's like, well, why do we even use that word? Like, who even came up with that in the first place? And you know, yeah, like to your point, like what does it actually mean? And I think that like depth of understanding, you kind of alluded to it in your like learning approach to where you said like, I never start with AI. And I think I've personally had the experience where I like I have that false expertise cliff where like all And I think it's made worse by AI where you'll generate a report or generate something. And it all makes a ton of sense, but there's a lot of jargon and a lot of like stuff in there that you kind of gloss over and you sort of like halfway understand. But by the end of it, you're like, do I really know what this all means? Like, no. And that kind of like gut check is important to be aware of where learning is supposed to be somewhat uncomfortable. and if you dig into something and don't have any questions, you probably don't understand it. Annie Sexton (21:19) I think there's sort of an internal litmus test of confusion of if there's any kind of parts you read over and you're like, I don't know, that sounds legit, but I've gotten very good at reading certain things. like, that sounds like a thing, but like if someone were to prod at me and say, explain this in more detail, I'd be like, don't You know, and if I ever reach that point in my explanations, where I cover a thing and if someone were to ask me more and I go, I know I've not done. I'm not done with my research. Part of this, will fully admit, part of this is just motivated by an absolute fear of being a woman and being wrong on the internet, which is not a thing. Like, I'm talking about tech and I'm a woman. You can't be wrong, Annie, which is such an unfair standard to hold myself to. But I just know, and it's happened before, I just know that they will come for you, they will attack you. So part of it is motivated a little bit by that fear, I'll admit, but I've learned to be a little more forgiving of myself. Jonathan Tamsut (22:25) I also just want to say I really like your thumbnail pictures on your videos. They're really funny. Specifically the Kubernetes without nodes video. That's a funny thumbnail. You're just making funny faces. I can tell you, it looks like you have fun making them. Annie Sexton (22:36) Thank you. That's half my job. I do. It's very uncool when you see like behind the scenes of being a YouTuber when you're making thumbnails. There's just a lot of like usually like in order you don't I don't know how other YouTubers do it but usually what happens is you just like have the camera rolling and you kind of go like You just, I'm sorry, if anyone's listening to this podcast, have no idea what I was just saying, but I was just like pausing and making faces at the camera. That's what it's like. It's very lame. Thank God no one's actually looking at me when this is happening. Brittany Ellich (23:10) love to see what that looks like though. that. Let's talk a little bit because I know you do a lot of learning about AI and learning with AI now and I'm really curious sort of you know what your opinions are on it. I know there's a lot of people that have very strong opinions either pro or against AI and I'm curious what where you're at on that spectrum and Annie Sexton (23:31) Mm-hmm. Brittany Ellich (23:35) what does it look like to you? How are you learning and keeping up with what's happening right now? Annie Sexton (23:39) So, AI gives me a lot of anxiety. I'm not gonna lie. But I have thrown myself into learning about it and that has really helped my anxiety. It has made me feel a little more, probably not in control of things, but on top of things enough. I'm gonna start with a good thing. So AI has drastically improved my career for the better. Like my career would not be the same without it. Excuse me. As I said, the way I found it useful is after learning about a thing from some human written content that could be documentation, that could be a book. I will then go to some LLM and can you hear that in the background? I'm sorry if you can, whatever. I'll go to some LLM and I will pretend like it's just a, it's a senior engineer who can answer my questions. I usually, if I can copy and paste something in, I will. I don't assume that it knows everything. If it's like really ancient knowledge, right? About like IPv6 addresses and like how that came up. Like that's pretty standard. It's set in stone. There's not a lot of opinions about when IPv6 came out. Like it's just, it's whatever. I'll still fact check that kind of thing. But usually what I'll do, let's say I'm reading an article about a particular subject. I'll copy that article into Claude or Chachi B.T. and I'll say here's this article that I was reading. I don't understand this one section. It says this, but that sounds like it's contradicting X, Y, Z or you whatever my question is. By pasting in the article, I know that it has the context that it needs and it's not just going to be like pulling things out of its ass, right? I mean, technically it's all hallucinations, but. Whatever. So I have found it incredibly useful because I can dig, I can dig, I can dig. And what's good is that a lot of the things that I'm digging into are proven facts. These are not opinions. This is how a kernel works. This is what kernel space is. This is what user space is. This is what a VM is. This is what a hyperadvisor is. There are just straight up answers to these. It's not ambiguous. And so I feel a lot more confident leaning on AI for the type of research that I do. And I also get my coworkers to check my work. So anytime I'm making a video, I'll have one. mean, part of that is because if I'm talking about how the platform works, I need to make sure that I'm not lying. And so I'll give it to one of our engineers. ⁓ Thomas usually writes a lot of stuff on the blog. He reads a lot of my scripts and is able to help me a lot. So I do my own fact checking. have other people do fact checking. fact checking is so important when it comes to using AI, but I do think the notion that, these things can hallucinate, so just don't use them. think baby bath water, y'all like calm down. You can be an adult and be discerning because people also lie on the internet. I don't know if you knew that. People lie on the internet too. And so you should never just assume that you can not have to fact check. No, of course not. And so I find that the benefit of using an LLM for research far outweighs the potential consequences of it hallucinating because you can check the answers, right? You can just, if it lies to you, okay, it lied to you, go find the right answer. You know what I mean? There are certain things that I probably wouldn't use it as much for. I'm not gonna talk to it about current events. It doesn't know anything about current events. These models aren't, and also like, there's all sorts of room for bias in those things and I'm not even gonna, like, you can only be so biased in the technical world. Like, you know what mean? You can, there's only so much bias that can go on, whereas in politics, it's like, yeah, I'm not even gonna, we're not gonna talk about politics with GVT, absolutely not. So I think that using it for research is, Absolutely invaluable. Absolutely invaluable. And I have been able, you know what it is? I have been able in the past when I don't understand something, what do I do? I either go and research it myself. I try and hone my Google foo, or I talk to a coworker or someone who's an expert, but you can only ask, like you can ask the best questions to a real human. You won't always get the best answers because people, there's varying degrees of people who can explain things. And also people have lives and some people are more patient than others. And even if they are very patient, you know, if you have a lot of questions, which I always have a lot of questions, there's sort of a limit to which I feel comfortable asking them my questions and chat GPT will never get annoyed with me. And so I can just be like, but what about that? Wait, I don't understand that. No, that doesn't make sense. That sounds the opposite of what you're what. Why, why, why? can just be this like annoying little kid and my ADHD brain could just ask all the questions that it wants. And that's how I learn is I just be like absolutely obnoxious with all of my questions. Sometimes I don't even like have a very specific question. and I, can still be kind of vague with it and it'll, it'll start to put you in the right direction. Absolutely phenomenal. Highly recommend, highly recommend. There is a way of using it. understanding that it can lie to you, it again, it's still the benefits still outweigh the consequences, at least in the particular field that I'm researching. I'm not qualified to say if that's true for like the medical field or the history or whatever, but at least for the stuff that I'm talking about, fantastic. Love it. Erika (29:30) that's your sort of overall AI assisted learning approach. And then. Annie Sexton (29:35) Mm-hmm. Erika (29:36) curious how you sort of like deal with the complexity of like base knowledge required for AI. Coming from someone who's not an AI developer, I think you've probably talked about this a little bit and the answer might be the same, but at least with AI itself, like the understanding of the development and the models. So much of the context is like math based or like very complex algorithms. Like, how do you get into that? Or do you kind of like, is that something you sort of take for granted? Like, yeah, what level of expertise do you kind of aim for in that base level knowledge understanding? when it comes to the area of AI specifically. Annie Sexton (30:21) Sure. So when I'm doing any videos about AI or machine learning, I, so I always, all of my videos happen to be for a technical audience. All of my videos happen to be for a technical audience. And so. But. ⁓ That doesn't mean that they know about machine learning, right? In fact, I assume most of them don't. I'm still a student of this. I'm not a, also the term AI engineer has been commandeered by software engineers because it used to be you did machine learning. If you're an AI engineer, are training models. were working on the algorithms. You were working with transformers. You are an AI engineer. Now an AI engineer is somebody who uses the open AI. API key, right? Like that's, you know what I mean? All you're doing is you're shipping off some context to an LLM hosted in the sky. like that's more or less. mean, sometimes it's a little more involved in that, but like it's, it has changed, which is why I do think nowadays, if you're talking about a, like the old school AI engineer, you probably are going to say ML, right? A machine learning engineer. Erika (31:17) That's good. Annie Sexton (31:25) I, so I've read a couple of books on machine learning that's given me a good foundation. One of them is called Deep Learning a Visual Approach. Fantastic, very little math, which the fact that I was able to get through talking about like convolutional neural networks without talking about hardly any math is incredible. Just a testament to, I think his name is Andrew Glassner who wrote this book. Highly recommend, it's a beast. It's like a chunky, it's a chunky boy, but. It's such a good book and I made my way through that and that gave me a really good foundational knowledge. But I assume when I'm doing videos on these kinds of topics that people's experience is that they've used an LLM before and perhaps, and they know what an LLM is. I don't even know, I don't even assume that people know what like a diffusion model is. I don't assume that people know what transformers are. don't. I assume people are only slightly more technical than a non-technical person using ChaiGBT, right? Maybe these people have worked with the OpenAI API or the Anthropic API. Maybe, but that's about it. And then I assume nothing, right? I also think that when you're a modern day AI engineer, you need to know a lot less. You know, you need to know context window, you need to know what tokens are, but you don't even need to know what tokens are. That's the thing. You know what mean? Most people understand tokens to be, your text gets broken into little pieces. It's not exactly words. It's like parts of words usually. And that's it. know, your text gets broken into little pieces, but people don't often know, like I'd be willing to bet that most people don't actually know what those tokens actually are. And that's okay. And so like, that's a good place to start. that is the position that I like to take when I'm explaining these things. I mean, the way I've been doing this, the reason I started that, that second personal YouTube channel to talk about all this was because I knew I wanted to become more of an expert on this stuff because it's the future and part of it's, know, I don't want to get left behind, more like if this is an incredibly powerful and also potentially very scary tool. And I want to make sure I know what I'm talking about. And I know that I can see through the hype. and so what I do is I just become like a mini expert on one thing at a time, right? Just like a little baby, like I'm gonna get like baby, baby expert on the basics of what a neural network is and what byte pair encoding, byte pair encoding is what this other thing is. Right. And I, I am a huge believer in becoming a mini expert, just like a little micro expert. That's my whole job. And it's great. So that's how I like to approach teaching about machine learning. I don't, I machine also, here's the other thing. I'm mostly talking to software engineers when I'm making these videos, right? Software engineering. Some people are going to disagree with me on this. think software engineering knowledge is basically useless with machine learning. It's basic. Cause machine learning is all math, not like a little bit, all math, all. I'm going to say it again. It's all math. Like, and I never took calculus, I never took statistics, and that's all it is. You know, aside from the idea of like input-output, Yeah, nothing about software engineering has been helpful in learning any of this stuff. So it's easy to make these kinds of educational videos because I am my target audience. Right? I know what it's like to come from knowing almost nothing about machine learning. Erika (35:06) I do appreciate that part of your answer involved reading actual books as a big fan of actual books. Yeah, two thumbs up on books. Annie Sexton (35:13) Me too. I like books. Brittany Ellich (35:17) Well, I think we are probably getting close to time. So we're going to move on to our fun segment and then we'll give Annie a chance to share, you know, where to find you. But first, our fun segment. We're all a bunch of engineers who are, you know, very passionate about software engineering or, you know, passionate about the things that they're learning about. But not all of us, I feel like, are completely know, we're also all humans and doing things outside of that. So I thought we would go around and share things we do for the pure enjoyment of doing them that might not have anything to do with building software. And I'll give you all a chance to think. The thing that I do that has nothing to do with software at all is I crochet. I love crocheting. I love making things. And it's a very fun activity. I sometimes end up making things that are software adjacent, like the cute gophers that I make, but otherwise just just crocheting. Annie, did you want to go next and share? Annie Sexton (36:15) no, I'm going let y'all go first. I've been yapping. I want to hear from y'all. Brittany Ellich (36:18) Okay. ⁓ Bethany, do you want to go next? Bethany (36:23) Yeah, I'd say probably reading. Like I do read technical books, but most of what I read are non-technical and I don't do anything with that. I don't share my opinions typically unless it's with close friends. So it's just really something for me. that's always, it's always nice to just cuddle up with a book and get really involved in it. Erika (36:44) I've always wanted to be like a dancer and I like sort of grew up dancing, but I'm not very good at it. But I still do like dance classes every once in a while. Like I try to do like one or one a week or one every other week or something. And I very much enjoy it even though I'm not good at it. So I'm choose that. It's always like the end of a stressful day. And it's like the last thing I wanna do. Like the thing that I really wanna do is that my couch and do nothing. And then I force myself to get out of the house and go to a class and I always feel so much better. Brittany Ellich (37:20) That is so cool, I had no idea that you did that. Annie Sexton (37:21) What kind of dance? Erika (37:22) I've mostly been doing ballet. Yeah, which, you know, like I said, I probably look like a complete fool, but I don't really care. Jonathan Tamsut (37:30) That's pretty cool. I don't think I could ever do ballet. I don't think my body would support that. Yeah, maybe actually with training, sure I could. Yeah, recently I've been really interested in like rockets and Mars colonization. I just got a job working at a company that makes rockets. And so I've been learning how rockets work and then learning about colonizing Mars and the challenges and the, you know, reading a book on sort of the, the pros and cons of colonizing Mars and, and, yeah, there's, there's, there's a lot there. So yeah. Brittany Ellich (38:11) What book is it? Out of curiosity. Jonathan Tamsut (38:13) It is called... I have to look it up. It's on my Goodreads. If you follow me on Goodreads, Brittany, would know. It is called A City on Mars. Can we settle space? Can we settle space and have we really thought this through? Brittany Ellich (38:20) Okay, I'll go find it. Whoa. Jonathan Tamsut (38:29) ⁓ Annie Sexton (38:30) Hmm. Jonathan Tamsut (38:30) yeah. So... Bethany (38:32) I gotta know, what are the pros of colonizing Mars? Jonathan Tamsut (38:36) Well, I think one is, I mean, there's, there's, number one is like, you know, there's natural resources that we can mine and bring back to earth. ⁓ Two is we, it can be used for exploration of the cosmos. We can build telescopes and three is it hedges. I mean, this is kind of like the Elon Musk thing. It hedges, you know, any existential risks. So if we destroy this planet, we got to back up planet. ⁓ so Erika (39:04) plus Matt Damon lives there, right? Jonathan Tamsut (39:06) Matt Damon's there so we can go hang out with him, which is think that's a pretty big pro. Annie Sexton (39:11) you. Brittany Ellich (39:13) wouldn't want that. That's great. Okay, Annie. sorry. Annie Sexton (39:13) That's pretty good. Have you read the Expanse? It's... ⁓ yeah. Have you read the Expanse series or watched the show? Jonathan Tamsut (39:22) No, I, yeah, no, I haven't. I... Annie Sexton (39:22) It's not about, yeah. You should. From what I understand, I watched the show and I've started reading the books and it's like a hard sci-fi story. And so a lot of the science-y stuff is like pretty close to believable. And anyways, they have a whole, there's like a whole colony nation on Mars and I'd be curious your thoughts. Jonathan Tamsut (39:26) That's right, But I shouldn't. Yeah. Mm-hmm. Yeah. Yeah, I like have, I've tried to read sci-fi so many times. But anyways, that's a separate topic. I will let you tell us about your interest. Annie Sexton (39:57) I draw comic books. if you're interested, here I'm gonna do a plug. So I'm on Blue Sky. My tech one is at anisexin.com. But if you just look up anisexin, like the other anisexin on Blue Sky is all of my drawings. I'm working on, I actually published... I say published, I printed 10 copies of my first graphic novel this year called Peach Boy. It's not for sale. I'm sorry. But, showing myself that I could finish that was incredibly motivating. And now I'm onto my next comic book. This is a whole series. It's going to be like 500 plus pages. I'm working with a real editor that I pay human dollars with. It's amazing. I cannot tell you how much writing this story, working on the sketches has been healing for me. Like there's so much, existential crisis is like the term for the year in 2025, it's like on so many fronts. And this little story, this dumb little story is just keeping me afloat. It's just the, it's the love of my life. I wholeheartedly think people should make more stories. is. I don't understand how anyone can find anything more joyful. I just think it's so delightful. So that's what I do. If you want to follow along, check me out on Blue Sky if you want. Brittany Ellich (41:11) Yeah, absolutely. We'll link it in the show notes so that anybody can check it out. Great. Well, thank you, Annie, for joining us. You already mentioned Blue Sky. Is there anywhere else that folks can follow you? YouTube, obviously. Annie Sexton (41:25) ⁓ yeah, the YouTube, if you just look up Annie Sexton on YouTube, or fly.io, you can find the fly.io channel, that's easy to find, and then just my name. I think that's... Yeah, you can find me on YouTube as well. Brittany Ellich (41:38) Great. All right, and we'll include everything there in the show notes as well. Thank you so much for tuning in to Overcommitted and for hearing about Annie. This was wonderful. If you like what you hear, please follow, 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. And as a quick reminder, we are still working on the Looks Good to Me book club, and there's still plenty of time to get involved. Check out the show notes for more info. Until next week, goodbye. --- ## Episode 24: Ethics in Code: Social Media's Role in Software Engineering - URL: https://overcommitted.dev/ethics-in-code-social-medias-role-in-software-engineering - Published: 2025-09-09 - Topics: AI & Developer Tools, Imposter Syndrome & Mental Health, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/107894902/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-8-5%2F406968991-44100-2-ed2fb93de3895.mp3 ### Show notes Summary Software engineering ethics isn't just a buzzword—it directly impacts your career trajectory, mental health, and long-term sustainability in tech. In this episode, we explore how engineers navigate ethical decisions on social media, handle public controversy, and maintain integrity without burning out. Perfect for engineers looking to grow responsibly. Links * Video: Why everyone is quitting social media [https://youtu.be/zN-rElTzR_4?si=2b0iQF6LKV3CGDpp⁠ ] * Careless People [https://www.goodreads.com/book/show/223436601-careless-people⁠ ] * Interview on information diet with Herari [https://www.youtube.com/shorts/QDEQA6kftsM⁠ ] * Bill in 1996 [https://www.justice.gov/archives/ag/department-justice-s-review-section-230-communications-decency-act-1996⁠ ] * ACM Code of Ethics [https://www.acm.org/code-of-ethics⁠ ] * ⁠⁠⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠Overcommitted.dev⁠⁠ [http://overcommitted.dev] * ⁠Brittany Ellich⁠⁠⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠⁠⁠Eggyhead⁠⁠ [https://github.com/eggyhead] * Jonathan Tamsut [https://infinitely-fallible.bearblog.dev/] ### Transcript Brittany Ellich (00:01) Welcome to the Overcommitted Podcast where we talk about our code commits, our personal commitments, and some stuff in between. I'm your host, Brittany Ellick, joined today by... Erika (00:12) Erica. Jonathan Tamsut (00:13) Hey, it's John. Brittany Ellich (00:15) We are a group of software engineers who initially met together on the same team at GitHub and found a common interest in continuous learning and building cool things. We continue to meet and share the things that we're learning and discuss our lives as developers. Whether you are pushing code or taking on new challenges, we are so happy you are listening. This week, we're going to talk about a very exciting topic, software engineering ethics and social media. This is something that I feel like we have alluded to quite a bit in the past and something we've talked about a lot. And we will talk a little bit about what this issue actually is and what our thoughts are around tackling it. So to start with, I want to set the stage and talk to Erica and John a little bit about your first relationship with social media. I feel like we're all around the same age, like mid thirties ish millennials who, you know, really were coming to adulthood around the same time that social media was first introduced. So I want to know sort of like what that felt like when you were, you know, experiencing it for the first time. Jonathan Tamsut (01:23) Well, I'm in my early 30s, thank you very much. Don't age me. But yeah, I could go ahead and answer. You know what's funny, I remember, I have two older sisters that are like eight years older than me and my sister was at, she was at college and Facebook came out and she was like using, cause like Facebook initially I think just rolled out to colleges and she was at UCSB. and she had Facebook. so Facebook was definitely like the first social media platform I remember using. And I just remember, you know, going on it. like when you had like a high school girlfriend or boyfriend, you would make it Facebook official. You know, I remember that being a thing. And I never really like like social media and was always I feel like the. It's always been weird to me to post things due to the impermanence of it all and it's kind of broadcasting. I feel like I was always like, this is silly, people are posting mundane aspects of their lives, ⁓ that's kind of the point. ⁓ yeah, Facebook was definitely my first social media interaction. Erika (02:38) Yeah. So discounting ⁓ AOL instant messenger, which is not social media, but I feel like is proximate in sort of like the poll that I had on my life as like ⁓ a young teenager. And like the obsession I remember of like wanting to go home and log on to AIM and all the drama that happened over instant messenger. ⁓ My first social media platform was my space. And yeah, I definitely remember the like, you're like top was it top 10 friends, I think and top eight. Okay, yeah. And like, wow, over analyzing that I mean, the amount of brain space and emotional energy I spent into like thinking about Brittany Ellich (03:20) Top eight. Erika (03:31) who my top friends were and whose top friends list I was in. I will never get that life back and deeply regret all of that. All of that. So I didn't actually create my own Facebook profile. had when I was at summer camp, a summer camp friend set up my profile for me and for a good like two years of my life it was entirely like jokes and made up like none of it was actually relevant to my life. ⁓ I think it said I was like related to Mary-Kate and Ashley Olsen or something like that some inside joke that was hilarious at the time. ⁓ Yeah so that was that was my introduction. How about you, Brittany? Brittany Ellich (04:26) Yeah, I started with MySpace and I remember the agony over, you know, deciding the top eight. And when you were fighting with a friend, she was like, oh, I'm going to remove you from my top eight or something. Like there was a lot of drama around it. I also, yeah, started on Facebook pretty, I think it was like late high school, early college. I remember it was in the days when you still could only have like 20 pictures on your Facebook maximum. And so like you had to really think about what you put there. And yeah, I remember, I think the biggest thing that I remember is like, it was really exciting at the time, maybe in part because I was, you know, a teenager, but also because it was like this new way to interact with your friends. And, you know, I was graduating from high school, so it was a way that I could keep up with all these people that I probably would otherwise not have kept up with. And I, yeah, put a lot of mundane things out there about like, ⁓ what's on your mind? And it would be like, I'm thinking about this or I'm listening to this song or like whatever like nonsense that, you know, 17, 18 year old me cared about at the time, which is probably not something that needed to live on the internet for forever. But that's a separate thing here. ⁓ But I remember early on, was very, it was actually social. It was about, you know, people that you actually knew. and connecting with them and that was like the draw to it and that was the promise of social media was like we're going to increase social connection. The reason I wanted to start with this is because I recently watched a video that said that the average person now spends only seven percent of their time on social media interacting with people that they know and like at some point something changed where it's no longer social media and it's just media. ⁓ And that's kind of what I wanted to talk about today is like why did things move this direction and like what can we as software engineers think about and like you know contribute to this world that is really we're the ones that are building it. ⁓ How our input can maybe shape things potentially. or not because big problems are hard. ⁓ So I want to just talk a little bit about next about like what social media algorithms are. If somebody wants to like take a stab at like defining that and you know what changed in social media that went from this social landscape to what it is today. Jonathan Tamsut (06:46) Mm. Mm-hmm. I could, I assume this is gonna get cut. But maybe not. If, ⁓ if, if you're listening, ⁓ Brittany just shooed her cat out. also, what other thing is I remember poking people and I was like, love to poke people. I just thought it was so funny to poke people. I'd poke like my uncle. Brittany Ellich (07:10) Yes. Jonathan Tamsut (07:19) But yeah, can talk about, I can talk about, I mean, I think we all can talk about social media algorithms, but I can do that if you all want, feel free to elaborate. Yeah, so I mean, I think, ⁓ well, I think, know, know, Facebook is a good example. I mean, I think, I think for sort of a narrative purpose, so I think when you went on Facebook initially, you would kind of see posts that your friends would make, and maybe they were ordered by date. And then there was the introduction of the new speed. And it used sort of, you know, more, you know, different algorithms to kind of recommend content to you. And so, you know, an algorithm is just a series of instructions and a lot of these platforms use some type of machine learning algorithms. So it's sort of an algorithm that kind of learns from data. And, you know, these algorithms all have some objective. function that they're maximizing over. And so I think for a lot of these platforms, it's engagement, it's how much you're clicking, and it's often correlated with some type of advertising. You're on an advertiser's ad, or you're just being on the platform for as long as possible. And so these algorithms present you content in a way that maximizes that. There's a blend of factors. They also do want to recommend relevant content to you because you're more likely to stay on the platform if you do. Erika (08:56) Yeah, I mean, I think the the cycle is a very familiar software cycle where ⁓ like the the sort of like output of the system is like some sort of metric that you're trying to optimize for. So like you mentioned, you know, time on platform. And so like Jonathan Tamsut (08:56) So. Erika (09:25) these social media platforms try to figure out how to optimize for that. So they tailor their algorithm ⁓ to support that. So ⁓ like one thing they've figured out is that if you're ⁓ like in a heightened emotional state, you will stay on the platform for longer. they'll know, serve content that puts you in that emotional state, whether it's anger or usually anger, frustration, outrage, or like greed, know, these things you're like, I want more. Oh, I'm so mad. I'm going to like keep looking at all these things that, you know, make me mad. So they they sort of use this as a proximate value for the overall platform, figuring that people who spend more time on the platform ⁓ or the more time that's spent on this platform means that it's more valuable overall, like monthly active users, active user time. ⁓ They can then use that to tell. anyone who wants to advertise on the platform, for example, like, hey, we have, you know, this many people using it. We have, ⁓ you know, this much amount of time of people like using our platform. So like your advertising dollars are best spent here because ⁓ we're going to get eyeballs on your advertisements. You're going to get the most bang for your buck by, you know, paying us to serve ads. ⁓ So I think, you know, I say it's familiar because I don't necessarily think this is like only social media that does this, but it's prevalent in social media, especially Facebook and Instagram ⁓ because of the size. Like it's sort of this cycle that, you know, grows as the companies grow and develop. And it's sort of like a self feeding thing. ⁓ And it affects more people, the more people that are on the platform. ⁓ So that's my take on it. Brittany Ellich (11:50) Yeah, I think that the key here where things changed is in the beginning, there were no advertisements on a lot of these applications and most of them started out, you know, being super venture capital funded. had all this money where you know, getting pumped into them where they didn't have to worry about making money on what it was. And at some point something changed and they realized, ⁓ okay, we need to make money. The most likely thing is going to be advertisements. And that means that, you know, the more that somebody's here on the platform looking at these, at the platform in general, that means the more ads we can serve them and the more money that we can make. ⁓ And so trying to that they then became this machine that was trying to design itself to keep people on there as long as possible and to, you know, eat up as much attention as possible because it means more advertising and more money. The other. part of it that I think is a little bit more unique to social media, although maybe it's not anymore, ⁓ is the amount of personal data that they can obtain about you to not only serve you ads, but to serve you the most targeted ads and the ads that you are most likely to engage with just by nature of being the data that they have about how long you spend looking at this video or how long you... spend looking at that or like what your demographics are in terms of like where you are in the world searching and how old you are and all that stuff that's freely available to that platform makes it so that they can also serve you highly targeted ads that make them very valuable ads which I feel like is another thing that changed over time ⁓ and has made them maybe not more nefarious but more you know it is what they are. Erika (13:38) And on the topic of data, there's also the monetization vector of selling personal data, ⁓ like for profit in general. Like even if you're not even using it, you can sell it to someone else who might then use it to develop their platform. Brittany Ellich (13:59) Yeah, and the monetization of it created an entire economy. The creator economy didn't exist before social media platforms existed. And now you can like being an influencer as a job. ⁓ Like that's a, they're making way more money than we are. Like they're, mean, the few that are very, very successful, you know, like there's, that's an entire career too, where like their job is, you know, trying to develop the con. Erika (14:11) No. Jonathan Tamsut (14:12) Yeah. You Brittany Ellich (14:27) Again, similar to the social media companies trying to develop the content that people are most likely to engage with. Jonathan Tamsut (14:33) Yeah, no, it is, I mean, it is such a, I mean, you know, it's like, this is such a trite topic, right? Yeah, this is like, I mean, it's trite in the sense of like, we're so immersed in, we're in this age of like social media influencers, people being online. I mean, you know, the other day I heard, you know, there's a website called OnlyFans where, you know, people sell adult content and there's the- I saw an article saying that someone made like literally like 80 million dollars in a year selling pictures. And right, you know, all of these are sort of hitting our sort of dopamine reward systems and having just massive impacts on us on a societal level. you know, mean, Erica, you shared like that sort of quote right before, ⁓ you know, we met and, you know, I think like obviously incentives play a huge role here. I think Brittany, I know you read this book, ⁓ Careless People, was this sort of high level executive at Metta kind of talking about her experience there. mean, ⁓ obviously these social media companies are incentivized to maximize shareholder profit. humans are easy to manipulate, especially when you have a team of really intelligent people collecting, you know, this sort of surveillance capitalism regime where they're collecting information about us and then can develop these machine learning models that perfectly manipulate us. ⁓ And ⁓ I think, you know, we need, there's certainly needs, I think there needs, something needs to change. And, you know, I think there are It's like with chat GPT, their pricing model, people pay a subscription. We need that for social media a little bit more. And I think people are becoming more cognizant of the effects of social media, especially on kids. But it's just such a wild time. And it's funny, it's like, I see... older relatives in their 50s and 60s glitching their phone. I'm like, this is like a universal human thing. It's not just us young kids. So it's kind of crazy to think the impact that this has on our world. part of that is easily visible when you just look at the earnings of these social media companies. I look at Meta's valuation. Look at Snap. Look at all these social media companies. ⁓ Even Google, right? mean, their primary driver is advertising, know, targeted ads. You know, they're not a social media company per se, but they kind of, you know, are another company that makes money off of ads. it's, yeah, it's wild and it's hairy and, you know, there's certainly some great things about social media, but there's a lot of... ⁓ I think we all feel a level of discomfort with sort of how it's played out. Brittany Ellich (17:39) Yeah, I don't think that there was ever like a bunch of software engineers and product people sitting in a room saying like, how do we design this thing to, you know, make everybody in the world more like angry and more like, you know, like increase the polarization of the political system in the United States. Like, I don't think that that was ever something like somebody's intention. It was a bunch of small changes that happened over time where somebody's like, hey, why don't we Jonathan Tamsut (17:54) Yeah. Brittany Ellich (18:07) introduce something like the infinite scroll so that you never stop to stop looking at content. Or you are using all this A-B testing just to see like, if we move this menu here, does that change how long somebody spends on the platform or how often they interact with these things? It's a bunch of little tiny decisions that add up to this big. Jonathan Tamsut (18:12) Yeah. Brittany Ellich (18:30) societal decision where we can't just say like one person is responsible. It's a lot of little tiny things that have happened over time and we can see the impact for sure over like the entire entirety of society. The you negative mental health impact on children. I cannot imagine being a teenager right now. my gosh what they have to deal with. ⁓ And you know already going through all of the Jonathan Tamsut (18:52) Mm-hmm. Brittany Ellich (18:59) changes that come with being a teenager and also having to deal with these social media influences. And I was a kid, I was just magazines. You could really easily ignore magazine. Everybody was up in arms like, there's magazines, or influencing these kids. And I was like, well, if you just don't look at them, then you're good. But that's not possible, I feel like, to interact in daily life now because so much of it happens on the internet. ⁓ Erika (19:23) Yeah, Jonathan Tamsut (19:23) Mm-hmm. Erika (19:24) I do think that there were points that could have changed the end outcome though. There's been, ⁓ I don't know if they're leaks or reports of research within, I'm pretty sure it was Metta about the effect of ⁓ the platform on mental health for teenage girls. Jonathan Tamsut (19:29) Mm. Mm-hmm. Erika (19:53) and, you know, yeah, multiple studies that like, surfaced these concerns that we're all raising here. And, you know, I think there was a trade off between profit and fixing parts of the platform that, you know, encouraged those bad outcomes. And then in every choice, they chose profit. So You know, it's like, were they intending for that outcome? No, not necessarily, but when they did find out that that was happening, they did, of course, Brittany Ellich (20:37) That's true. Sorry, I'm not trying to give an out to them there. Yeah, especially reading Careless. What could we have done? We were just writing code. yeah, think that book Careless People is a really good example too. A really good, first of all, it's phenomenally written, but it's also just like a really good example of those different points that came up and what choices were made during those points when it came to like, Jonathan Tamsut (20:38) Yeah. all just innocent here. We're all just innocent bystanders. Yeah. Erika (20:47) Yeah. Jonathan Tamsut (20:58) You Brittany Ellich (21:06) like this is having a negative impact that we can like measurably see should we do something and continuously choosing not to do something and to choose profit over that. ⁓ And I think. Putting on the engineering brain here, what options are there though to like actually course correct now, given that we live in this capitalist system where you do kind of have to, mean, are, most CEOs are beholden to the shareholders. They can't make a decision that would negatively impact profitability theoretically. like, do you do now? Jonathan Tamsut (21:48) Well, so you've all know Noah Hariri, he's an author, ⁓ he's written some good books. I was listening to an interview and yeah, he talked about having an information diet. Same thing with just like, you can go to a grocery store and you could buy foods that ⁓ if you eat over the long term will make you sick. I think every person needs to have some type of information diet ⁓ where they are limiting themselves. ⁓ from exposure to content. There's tons of, I use tons of these apps like BlockSite, Freedom to Block websites. I'm off Facebook, I deleted my Facebook account in 2017 and I literally have, I feel like I've lost nothing and I'm just happier because I'm someone who I would go on Facebook and compare my life to others and just become depressed. And so I'm very, I'm not on Instagram, I don't really go on social media, and that just works for me. Obviously, there's lots of, if you have a business, advertising on these sites is important, but I do think every individual person needs to have some type of thoughtful strategy to limit their exposure and mitigate the negative consequences of these platforms, and that's just part of what being a human being is. Now, that being said, I have like a phone addiction. I have a dopamine addiction. There are platforms that I spend too much time on and it's not healthy for me and it's really difficult, right? Just like sort of, you know, and so, ⁓ but it could be worse, I guess. Erika (23:30) So as engineers, ⁓ one important aspect of what we do is being cognizant of the human impact that what we're building is having and pushing to not only measure things like ⁓ engagement time, but also ⁓ this idea of human-centered metrics. ⁓ how how is this affecting the users? ⁓ And finding ways to measure that, ⁓ making sure that we bring it up as a part of these discussions of what we're building. ⁓ Yeah, when we do find things that are seemingly negatively impacting the human experience, however we're measuring these, principles, ⁓ like pushing back and saying like, we need to roll this back, we need to make a different decision and pushing for that. Yeah, so I think that's an important concept to keep in mind. I also understand that like in some of these big corporations, you're gonna be told potentially that it's not like that's not what we're doing and you have to do something else and like that's a really tough place to be in. yeah, I mean, then you kind of have career decisions to make. ⁓ But I think at least understanding like our agency here and sort of like adopting the mindset that we don't want to do any harm and like, you know, ⁓ but like also knowing that there needs to be a way to quantify that and measure it. ⁓ Yeah, I think that's the best thing that we can do in our day to day. Jonathan Tamsut (25:37) I really like that, Erica. think that's, yeah. I think, yeah, measuring negative externalities as an engineering, I think is important and difficult. And I think that's why bad things happen is because people don't care about or even know about negative externalities. Brittany Ellich (25:37) Yeah. Yeah, I think one big thing that comes to mind ⁓ that I often think of with these large problems, I actually have a background in public health. I have a master's degree in public health that I'm clearly not using, but it did come with a lot of learning about how to manage the health of the public as it comes out. ⁓ And most of the time that results, the main thing to reach for is regulation. don't know how effective that would be in this case. I I think it would be better than doing nothing, but like watching the videos of the people in Congress, asking questions about how phones work. I don't know. We need some sort of governing body that's not just the people in Congress to make those decisions, if that were to exist. Erika (26:49) Yeah. So here's, I agree. think that especially like given the precedent of legislation around social media, there's, okay, it's like the bill that was passed like back in 1996 that said, like it's been cited a bunch to like, know, absolve social media companies of any responsibility. And it was intended to allow, you know, the development of communication technology, but now it's basically used as like a, it's not a problem. And as far as I know, there's no like current regulation really in flight. ⁓ And, you know, there's been like, it's hard. It's hard to regulate the processes of a technology company because it gets really hairy. Where my mind goes first for effective regulation is profit caps. Because what we're saying is like, well, part of the root cause here is that we're optimizing for profitability. And if we say, actually, this is The absolute maximum that a social media company can make as far as profits go, anything over that cap needs to be reinvested in like community projects like education, public health, you know, ⁓ I don't know the environment, like we're using gigantic data centers that are like environmentally problematic. Like if we cap that profit and reinvest it into things that are actually positive for our society. I think that could have positive effects, not only on the investments that are made, but also in sort of cutting off this terrible cycle of maximizing profitability. Brittany Ellich (29:01) Interesting. Yeah, I haven't heard that theory before, but I do think like that makes a lot of sense. Are there other examples in the United States where that like exists, where most of these companies are located? Like are profit caps a thing? Jonathan Tamsut (29:17) I thought at one time OpenAI, because they were technically a nonprofit, they have a weird, OpenAI, I don't know if you've read about OpenAI's legal incorporation, but yeah. I don't think profit caps are a very American thing. And yeah, it is funny. There's sort of a bunch, like Congress is kind of a lot of corrupt. that, yeah, it's like, I don't know if they're gonna, I don't know if I have a lot of faith, I don't know if anyone or the majority of America has a lot of faith in Congress. So yeah. Erika (29:53) Yeah, I mean the closest thing I can think of is like income taxes and I know there are like corporate taxes and there must be like corporate tax brackets. I'm not as familiar with like the tax code and all that to intelligently speak to it, but ⁓ yeah, even if it's not a thing, I think it needs to be introduced. Brittany Ellich (30:15) Yeah, I do feel like, I personally, it does need to be introduced. My ability to do anything with regards to legislature is basically none. ⁓ So my opinion here, I like sort of what Erica said about, you know, personal responsibility as a software engineer. As a software engineer, we have a lot of say in the things that we build. Now we might not be making. product decisions, but like we are making many, many macro decisions every single day over time that add up to what these products eventually become. ⁓ And so the thing that I think of as like one way to handle something that is negatively impacting society like this would be some sort of like code of ethics or something like that as software engineers to say like, hey, if we notice something that is causing harm, because of the thing that we are working on ⁓ causing undue harm that is not what it's designed to cause, I suppose, ⁓ then we should be able to speak up and have some sort of way of referring to some sort of board of licensure or something like that where we can say, hey, I'm reporting this somewhere so that... We know that this decision is being made intentionally and not because of these byproducts of all of these different decisions. I feel like this exists in a lot of other career paths. Like the thing that I think about is like doctors. Doctors have like a code of ethics that they have to follow to say like, I'm gonna do no harm. ⁓ Jonathan Tamsut (31:43) Yeah. Brittany Ellich (31:57) And I feel like the same thing should be applied to the software engineering level because we are seeing how much harm is caused by a lot of the software that is being built. Erika (32:08) Yeah, I think the key point that's missing there is that there's no license to practice software engineering. ⁓ Like, because when you have a, like a, you know, an ethical violation for a doctor, for example, they take away your license to practice medicine. ⁓ But unless you have that for software engineers, like, ⁓ you know, I don't know, you have to. Jonathan Tamsut (32:17) Hmm. Erika (32:38) Like, guess, I guess the process would be like, you know, you can't put anything on the open internet unless you have a software license or like you have to report on your website. Like this was created or hosted by somebody who's, you know, not a licensed software technologist or something like that. ⁓ Which, you know, it's possible. Like we do that with SSL and ⁓ stuff like that for. protection and encryption. So it's not necessarily out of the realm of possibility, but that would have to be, there would have to be a layer there of compliance and ⁓ adoption. Jonathan Tamsut (33:24) Yeah, yeah, it's like, on one hand, this feels like very futile, I don't know, it's like, I don't know if like the individual, you know, can you rely on, can you just sort of rely on like the individual goodwill of software engineers or like morality of software engineers to do anything like, ideally, would, you know, ideally, there just be like a different incentive structure that like penalized people that were actually doing harm to society. Maybe that was through fines, government fines, or regulations that if companies violated they would either, you know, there'd be some punitive damages or punitive recourse. ⁓ And I think like, but yeah, it's hard because yeah, it's like, we think that our legislature has the ability to come up with a good incentive structure? I don't know. ⁓ But I feel like that's probably the best way is to just realign the incentive. So companies are incentivized to just like, hey, if we exploit all these people and make a ton of money, because I just think that's going to keep on happening. ⁓ Brittany Ellich (34:31) Yeah, yeah, that's true. Erika (34:32) Yeah, the problem with lawsuits is that they're expensive and they're, they're expensive, they're time consuming and ⁓ money can drop the law in a lot of cases. So that's why that approach has been ineffective up to this point is because these companies have so much money that they can buy their way out of these problems. Jonathan Tamsut (34:44) Yeah. Yeah. But, Brittany Ellich (34:55) Yeah. Jonathan Tamsut (34:56) Pretty crazy. Brittany Ellich (34:58) Yeah, solving the world's problems here. As we've also alluded to talking about thinking and systems, I mean, a lot of these are very large complex systems that I don't think there's a one size approach that would fix anything. But I feel like doing nothing is probably not the right move. Jonathan Tamsut (35:09) Yeah. Yeah. Erika (35:17) I mean, one other somewhat dumb idea that could potentially be applied is a harm warning and also a screen time cap. So this is an idea inspired by regulation of the tobacco industry, right? So at some point we realize the tobacco industry was harmful. We require them to put warning labels on every package. ⁓ That could be applied to social media saying like this, the content here could be inaccurate or harmful ⁓ to your health, mental health, and then somehow capping the amount of time that you spend. So like only allowing users to actually spend. what's considered like a healthy amount of social media time. ⁓ So like require the companies to cut off any given user. ⁓ Now, of course, you could get around that by creating multiple accounts if you're really, you know, really inspired. ⁓ But I think for the most part, if you cut people's access off at like an hour a day, something like that, like that, could go a long way to reducing some of this, like, again, ⁓ the maximizing that we were talking about that the algorithms optimize for. Jonathan Tamsut (36:56) Yeah, and I think that's a really interesting idea. And I wonder if in like 15 years or something, we'll see that. I mean, obviously one difference is like, you know, the effects smoking has on you is universally bad. It's like pretty easy to measure. Social media is like a little bit more complicated. I mean, I'm sure there some people who consume a lot of social media that don't have the same sort of mental health effects as others. mean, it's a lot more varied, but yeah. ⁓ Erika (37:23) I mean, guess the counter argument to that is like, like the overall effects of social media have been very well researched and documented. And like the same argument could be applied for like, not everyone who smokes get cancer, but like, you know, it's pretty likely that you will have negative health impacts from smoking. Not everybody does, but most people do, you know, same like you said with Facebook. It's like, okay, like, Jonathan Tamsut (37:37) Yeah. Yeah. Erika (37:52) I left it, I am happier now. Like, you know, even if you didn't have like a diagnosed problem with Facebook, same with me. you know, the less I engage with social media, the happier I feel. To me, that's anecdotal. I don't know if I have any hard data to back that up, but ⁓ to me, that's reason and evidence enough that it's harmful on the whole. Jonathan Tamsut (37:55) Mm-hmm. Yeah. Hmm. Yeah. Brittany Ellich (38:19) I think one of the things, sort of what John is speaking to there though too, like in the world of studying public health, it's really hard to prove something without a doubt causes harm. You have to have a huge body of evidence to say, hey, this particular product causes harm. So there's a lot of things. That's why everybody always says like, everything causes cancer. It's because, well, yeah, it does. It's just really hard to equate. you know, this thing to causing cancer. We had a huge body of evidence that smoking causes cancer and we can say like, you know, it increases the risk. And so that's why we can put those warnings on things. ⁓ But it gets more difficult with things like that, like you said, that are harder to quantify, like mental health problems. That's a very difficult thing to quantify compared to like a physical disease. And that also requires a body of legislature that makes decisions based on science. ⁓ Jonathan Tamsut (39:19) You Brittany Ellich (39:20) You know, like you have to have somebody, some adult in the room that actually says like, yes, not only is this science saying that this is a thing that's a problem, we have to believe it. ⁓ And that is also increasingly problematic ⁓ as time goes on, in part because of... Jonathan Tamsut (39:24) Mm-hmm. Brittany Ellich (39:42) the, you know, the brainwashing that can come in the echo chambers that can come from social media platforms, you know, like the entire anti-vax movement can pretty much be pinpointed back to Facebook groups, which is crazy that like, you know, that's where it proliferated and like gained traction is like in these social media environments. So it's a reinforcing problem. Erika (40:01) Yeah. Unfortunately, science doesn't make money unless you can sell it. Brittany Ellich (40:10) That's true. That's true. We need to make science profitable. Erika (40:15) Yeah. Brittany Ellich (40:16) ⁓ But with that, this has been a really fun conversation. ⁓ I don't know that we solved the world's problems, but it was really fun talking about them with you all and just going through this. So we're gonna get into our fun segment after that heavy conversation. We're gonna talk about things we've learned recently that may or may not be fun. It's up to you, I guess, whether. that thing is a fun thing or not. But does somebody want to go first? Jonathan Tamsut (40:46) There you go. I've been learning about how rockets work. Recently, I've been watching a lot of YouTube videos and I bought a textbook on rocket propulsion. ⁓ yeah, rockets are pretty cool. Erika (41:04) newly relevant for you. Jonathan Tamsut (41:07) Yes, newly relevant for me. Brittany Ellich (41:08) Do want to go next, Erica? Erika (41:10) ⁓ Well, I mentioned that we went to Colorado last week and I have a two-year-old daughter and I learned ⁓ I only mostly knew the words to let it go. I now can sing it back and forth ⁓ due to all the car time where she was requesting the song to be played and replayed and I sang along every time. ⁓ Brittany Ellich (41:37) That's amazing. I also have a two year old that is obsessed with Let It Go right now and it's one of the most adorable things I think ever. That's great. Erika (41:41) Yeah. Otherwise, I guess I did learn today through this episode that there is a code of ethics and professional conduct for computing professionals. So we can add that to the show notes in case anyone else is interesting. It's a self-optin ethical code, sort of inspired by medical professionals and engineering professionals. I did not know it existed at all before, so that was something that I learned. Brittany Ellich (42:19) Yeah, we can definitely share that. I'll include that in the store notes through ACM, correct? That's something, I mean, that's a thing that I've, I feel like I've mentioned before needs to exist. Apparently it does exist. So I need to sign up too and figure out, you know, what that means. I think that's great. ⁓ I learned recently how to lay bricks ⁓ in a retaining wall project that has lasted the last month and it's looking good. I'm building stairs with these bricks too, which is something that I do not feel qualified to do. Anything that's like a physical thing, like I feel fine when I'm building software, but anything that goes into the physical realm, I don't feel like I'm qualified to do, but this is actually coming along and ⁓ it's been really fun and I'm excited to be done with it soon and like enjoy the new yard once it's all done. ⁓ And that's really been a lot of my time outside of work. I haven't, I've been like taking a break from being over committed to many different things and it's been really nice just enjoying the summer. All right, with that, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you do on the podcast app of your choice. Leave a review. Those are very helpful for us to get more people to find us if that's, know, if it's something that they like. Check us out on Blue Sky and please share with your friends. And as a reminder, we still have the Looks Good to Me Book Club. and there's still plenty of time to get involved. If you would like to do that asynchronously, check out the show notes for more info. And until next week, goodbye. --- ## Episode 23: Master Storytelling for Software Engineers | Programming Communication - URL: https://overcommitted.dev/master-storytelling-for-software-engineers-programming-communication - Published: 2025-09-03 - Topics: Developer Experience/DevRel, Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/107732017/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-8-3%2F406770947-44100-2-6163bf6c59098.mp3 ### Show notes Summary Great engineers tell better stories—and better stories accelerate careers. On Overcommitted, we explore how software engineers can master storytelling to communicate impact, land opportunities, and build influence without the burnout. From pitching projects to sharing career pivots, storytelling shapes how teams perceive your work and your growth. Discover the narrative techniques that turn technical brilliance into undeniable career momentum. Links * ⁠Astro docs [https://docs.astro.build/en/getting-started/] * Julia Evans [https://jvns.ca/] * GitHub Blog Post: Documentation done right - A developer's guide [https://github.blog/developer-skills/documentation-done-right-a-developers-guide/] * ⁠⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * Overcommitted.dev⁠ [http://overcommitted.dev] * ⁠Bethany Janos⁠ [https://github.com/bethanyj28] * Brittany Ellich⁠⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠⁠Eggyhead⁠ [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Bethany. Join by... Erika (00:08) Erica. Brittany Ellich (00:10) Brittany. Bethany (00:11) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we're happy you're listening. So this week, I thought we'd talk about storytelling and tech. Talking about technical topics doesn't need to be boring. And there's actually a real skill involved in making technical concepts interesting and relatable to your audience. Could happen with presentations, documentation, even code or like PRs. I've learned a lot about communicating technically over the years. And I really admire both of you for your ability to do the same. So I'm really excited to dive into this with you all. So first, just wanted to kind of talk overview, like when you think about great presentations or documentation and compare them with maybe not so great ones, ⁓ what are the biggest differences to you all? Erika (01:05) thing that comes to mind for me is visual storytelling. I've seen some documentation, the Astro documentation comes to mind, where it's like very visually appealing and a little like going back to the Game of Vacation episode where like it's like it's very leveled. Like you you can see progress as you go through the documentation. It's sort of a challenge. And so the story is like, your understanding of this information. So I think in a world online where so much is visual, really having that like, yeah. nice looking visuals, icons, people use emojis and gifs a lot, which is helpful in kind of bringing some levity. then, yeah, like having an arc of sort of like beginning, middle and end of where you're trying to go. I've also found to be more engaging than the flat wall of text. Brittany Ellich (02:13) I definitely agree with visualization being really important for telling a story. think that a wall of text is very, very hard to get through. think the other thing that sticks out to me is approachability. I can't tell you how many things, especially early in my career, that I started reading like the front page of the docs and they would start going into how like this is an expressive language that uses, you know, that's, I can't even think of all of the different words now, but like there's a lot of word terms that we use within software. development that are just not approachable at all to folks that are very, very new. And those are probably the ones that are going to be reading the front page of your docs anyway. Most developers are going to just jump to the getting started in the like NPM start part anyway. So making sure that it's something that's approachable and keeping your audience in mind, I feel like is really important and it's really easy to tell when people are doing that and when they're not. Erika (03:04) Yeah, I think the other thing that I find missing more often than not is a question to the answer, why do I care? And like, any software you're building is meant to solve a problem, but like, I can't count the number of times I've gone to a site or documentation for a piece of software. and they assume that you already know what problem you're trying to solve by coming to this solution. It's like, no, no, you need to tell me, like, why would I choose this over something else? And like, what specifically is the problem that I'm addressing here? Bethany (03:37) I completely agree. And I've been thinking about this a lot from a not just documentation perspective, but a presentation perspective. I'm preparing for a lightning talk at GopherCon next week. it's part of the lightning talk. So it's just a big segment of talks that people are listening to. So I've got to kind of solve why people should care about what I'm talking about. capture their attention. And I think there's not that many examples of just how to do that effectively, you know? And I think with presentations at work or like out of meetup, that's also important. So many work presentations, I honestly just like zone out because it's totally not meeting me where I am. It's not explaining or conveying topics or in a way that a lot of the audience can understand. it's just like, whoosh. But that's how you get your... Erika (04:30) Side note. Oh, I was gonna say side note. What are you talking about? Bethany (04:34) I'm so glad you asked. Hi, my talk is called, Not Your Parent's Editor, A Gopher's Guide to NeoVim. So yes, I'm so excited. I love being able to talk about tooling and stuff. this is my dream. And I think I applied for it for a regular talk, but I think the lightning talk is a lot better of a format for this because it's kind of like a... Erika (04:41) That is so you. ⁓ Bethany (04:57) short and sweet thing and I can kind of maybe take people by surprise and be like, hey, use it. But I'm super excited. ⁓ Erika (05:04) Well, I feel like I'm your audience member who will go to your talk, who like has tried them multiple times and can't get past the hump of like, why like, why would I switch over now? Yeah. ⁓ Bethany (05:17) Yeah. I love that and I'm gonna take a note for it. I've already written the presentation, but, ⁓ Erika (05:24) you Bethany (05:25) Sorry about my keyboard. These are the Wano Sakura keys, the way, or switches, by the way. They are very nice, but very loud. ⁓ Erika (05:33) I think that's Brittany Ellich (05:33) They Erika (05:33) another Brittany Ellich (05:33) sound really nice. Erika (05:33) lightning talk that Bethany could go. Bethany (05:35) ⁓ But yes, I think the why is so important. It's like, well, why should you care? But I'm kind of starting with a bit of self-deprecation. Like, I chose them to look cool or something like that. So I'm hoping that grabs people's attention. Erika (05:36) you Thank Yeah, I've heard, I've heard people do this like pretty well in like, ⁓ like imagine yourself in this situation and like, you know, you're, you're like banging your, like, obviously I don't know the reason for them. I don't know your reasons for them as well. ⁓ but like, I imagine you could frame it if you, since we're talking about this, like you could frame it as like, you know, you're in this situation, like you're looking for this, like this is your, Bethany (06:07) cool. ⁓ Erika (06:19) Like, this is your solution. you know, and like you said, like put, put people in the mindset of where you want them to start and where you want them to go. Bethany (06:29) Yeah, I love that. That's a really great framing, especially since a lot of people just are like, well, VS Code has everything I need. Why would I switch? And it's valid. I don't even know that I'm quite selling that Vim is better than VS Code. It's better for me than VS Code, but that's because it's a personal choice, a personal tool. It does the right thing. But I think I just want people to give it a chance or not think of it as this archaic. thing that is from the past and it's actually evolved in a really cool way to be a actual good editor in 2025. just really excited, but yeah. Brittany Ellich (07:06) I know you said that you're starting with some self-deprecation, which is a classic. But I think that also gives a really good point about what's important to start storytelling, and especially for tech presentations that I've seen, having a good hook, I feel like, is really important at the beginning, especially for a lightning talk when somebody's sitting there listening to more, a bunch of lightning talks over and over, having a hook that's not just, hi, my name is Bethany, and this is the thing that I am presenting. Bethany (07:18) you Brittany Ellich (07:32) is super important. One thing that I've been doing that I feel like has been really helpful for me is like I just jump immediately into like some visualizations and talking about a thing using some of like the illustrations and stuff that I do and then like a few minutes in then I'm like, hi I'm Brittany I'm talking to you about this and then move on. ⁓ Bethany (07:32) Yeah. Ooh, yeah, you did that in your GoFundMe presentation. I loved that. That was great. Brittany Ellich (07:56) Yeah, I got a lot of good feedback about that. And I feel like it helps because there's so many conversations where people are like, or presentations where people are like, hi, I am this. And this is why you should listen me because I've worked at this many places. And these are the things that I like to do. my brain turns off immediately before they even get into their presentation. Erika (08:14) Yeah, it can almost be arbitrary too. Like I've, I have not listened to a ton of Steve Jobs talks, but I've heard people talk about Steve Jobs talks and like how good he was at this of engaging people in the product and like building a story around Apple. And like some of the, like some of the quotes I've heard are like, like not even tech related, right? They're like. you know, a story about a person in life and like, you know, so and so whatever doing something. And it's like, then in comes Apple. It's like, okay, they're actually not related, but like, he was engaging enough for like, now I'm listening to you. And like, now I'm interested enough in what you're saying that like, I'll continue to hear you out on what might be like, more sales pitchy or more boring. Bethany (08:59) Yeah, absolutely. And I think that's like a superpower that some people have to get people to listen to your ideas and your thoughts. it's important to, a lot of us don't just have natural titles that make people automatically want to listen to you or want to hear what you're saying. So you have to make sure to come in and really grab that attention and also convey like what you have in the ideas you have in your head in a way that other people. understand and can engage with. And I love that relation to Steve Jobs, because he was just an incredible storyteller. He was great at crafting this narrative where the iPhone saves the world or you need an iPhone. Like, he had to basically sell people on needing a device that they previously did not have or depend on and why it would be valuable. So yeah, really, really good stuff. Erika (09:51) Yeah, and I think an important element there that you kind of touched on is like the emotional side, which feels completely divergent from technical speeches or technical talks. And I think like, we don't always reach for that because like, well, why is it important? Like, why is it important how this makes me feel or, know? Yeah, but like, Meh, we're humans, like, we do need some of that, some of that consideration. So, not unlike a, you know, like I think it can be to like a degree where it can be manipulative. So like, don't go that far, but like, you know, a little, a little bit can can go a long way, I think. Bethany (10:31) Yeah. And I think it does go the other direction, though. Like we were talking about documentation. In your documentation, people are probably looking for a specific thing. And you should know, or at least understand what that is. It's likely not emotional connection if they're looking at technical documentation. you've got to either, if you're an open source package, tell people why they even want this. What does it do? What are its benefits? And rattle those off. And if it's people searching for documentation, making sure that's like front and center and available and easy to get access. But it's interesting how the medium really affects what you're going for. If it's a talk, if it's a business presentation, if it's an availability review, I know that's always been a totally different set of can of worms, I guess. Erika (11:15) Yeah, yeah, I think the other elements that kind of come to mind are like characters too, like, yeah, like kind of using personas or like people or different actors in your scenario or storytelling. Yeah, that can be a good tool. Bethany (11:30) Yeah. Absolutely. mean, that kind of leads into like stories have characters, conflicts, journeys, resolutions. Is this necessarily the same for a good technical story? Is it always the same or does it map to similar concepts? Or does like a good technical story contain stuff that maybe a traditional story wouldn't? Brittany Ellich (11:50) That's a good question. feel like a lot of these elements that we're talking about that are useful are just elements of good storytelling in general. So maybe that's a sign that, you know, that goes hand in hand with how technical stories are told. think another thing that comes to mind that's really common in storytelling is voice and like the voice that you use throughout the story. And I think it's really helpful when you are writing something that for a technical audience to also consider, you know, what voice are you portraying? this like a professional thing? Are you trying to say, present this documentation in a way that you're also conveying, like we don't take ourselves that seriously. Please contribute to our open source project. If you see something, what's wrong? So yeah, I think that technical storytelling and regular storytelling have a lot of crossovers that a lot of people ignore. when trying to present something that, you know, they might have a stronger argument for their technical story if they actually use some elements of good storytelling in general. Erika (12:45) Yeah, I think the difference could be that like not all stories need to convey like information. Like technical stories are different from other stories like purely like emotional or like. you know, I'm thinking like literature, book, whatever, movies, like, and that, like, you don't need to get any information from, like, a story that is there for your enjoyment. Like, but technical stories do need to, like, convey information and you don't want to dumb it down because of the way that you're presenting it. Like, I feel like that's if there's, like, a reason why people, like, wouldn't use storytelling for these kinds of situations is because like, yeah, like they want to present the information like in its purest form. But like I don't necessarily think it's a trade-off you have to make. Like think of Julia Evans and like all her like wizard deans and stuff. And it's like, I learned so much from those like those cartoons. I visualize her git zine every time I do any git command. It's like that is like that is exactly like the point for me is like no actually like the story makes it stick better. Yeah but it's also like you know I also remember like I mean yeah no secret that I was a musician and like basically the way I studied for any test in high school was like turning into a song like AP history, the only things I remember to this day are like things that were set to songs, or like my whole SAT vocabulary. Like the only way I remembered any of those was because of like being set to a song. you know, is it like every song is an educational like test study song? No. Is every story a technical story? No, but like, it can, yeah, I can help make it stick, help it make it more engaging. And it it's the same information. So yeah, think as long as you keep that, as long as you keep the, what is it, like quality of information, yeah, you can have both. Brittany Ellich (14:48) Erica, I would love to hear you make some songs about these technical concepts so that I can finally remember how to properly rebase my commits, please. Bethany (14:57) Yes, please. Erika (14:57) Okay, actually this is a great challenge. Like, as we're talking about you doing your drawings and stuff, like, yeah, this could be something I could bring to the world. Brittany Ellich (15:05) Please, please do. That would be amazing. Bethany (15:07) wizard zines of music. yes please. Erika (15:10) I can get Isabel to do some backup vocals here pretty soon. Bethany (15:13) Yay. that's amazing. I love all these analogies. mean, Wizard seems to such a such a great representation of of this like storytelling and tech and making these complex, complex things like Julia Evans is pretty low in the stack with what she works on, but she's able to craft this narrative and bring people like unexplained concepts in a way that people can understand and that doesn't make them very like over your head because in a lot of ways, gatekeeping is a common thing in tech and gatekeeping topics ⁓ that may or may not be complicated but making them seem complicated or overly complicated or not willing to help people where they're at is absolutely a thing that happens in tech and being able to help people through that is just makes it a better place having more diverse and more thoughts and opinions on things. So that's a really good point. We've talked about this a little, but I'm curious if you all have any more thoughts on how audience really factors into how you present technical details. So if you're personally preparing a presentation, how do you factor in audience? What kinds of tools do you use to meet the audience where they're at? Brittany Ellich (16:29) I think the biggest thing that I think here is if I'm presenting something that I know is going to be presented to like VPs or like executives or something at that level, typically you want to have something that's a lot more succinct and to the point and, you know, a single paragraph or a one pager that just kind of gets to the point and doesn't have a lot of extra fluff and storytelling compared to, you know, if I'm presenting something that I'm going to put on my blog or that I'm going to present in front of know, a wider audience than I think about, you know, trying to add more to it to make it more memorable. Erika (17:04) Yeah, I think something I've been trying to do more recently is adopt some of this mindset of the audience is gifting you their time and attention and being very conscious of making your space that you're creating a space that they want to be a part of. So like, I don't think it's dependent on like, who's in your audience, but like adopting that mindset that like, like you want them to be there. Yeah, like I think sometimes in the past, like, I've been like, oh, I have to, like, I have to get this information across. And like, you know, it's a challenge or like, you know, like they're gonna think worse of me or have sort of like a negative mindset. And I've been trying to like, adopt more of a positive, inclusive mindset with anyone that I'm talking to in a group. I don't know if it's actually made a difference in how I come across, but it's made presenting a more enjoyable experience for me. Brittany Ellich (18:04) I think that's something, something that is kind of related to that too, that I've been thinking about a lot recently is I feel like I went through this curve of using AI for things like writing and telling these stories, or like I used it to time. was like, this is such a cool tool. And now I'm using it less because I don't know if it's just me, but I feel like if I present a bunch of stuff that is only written by AI, doesn't necessarily respect like people's time as much as if it's like written by a human. Like if you just. say take these bullet points and make it a story to chat GPT and you don't even take the time necessarily to like read through it and like know that it is like you know your own voice and something that you want to convey and expect other people to spend their time doing that then you know that seems I don't know kind of disrespectful of people's time as well I don't know why that came to mind well You said that, yeah, taking, know, appreciating the fact that you get people's attention and not trying to like hog it with things that are like not actually important or interesting or something that you would spend the time working on. Bethany (19:03) I love that so much. And it reminded me of an article that I was chatting with a friend the other day. She mentioned, and it was saying sending AI slop is an act of war. Because you're almost wasting people's time with a lot of it. I think AI is an incredible tool for synthesizing things, searching, understanding things in a voice that makes sense to you. But when information is pushed to you and it's AI. It does feel like a waste of time because, Brittany, to your point, people aren't spending the time to necessarily make sure it's good or make sure it conveys what they actually want it to. It reminds me, there was this ad for Apple doing something, like Apple's AI or whatever, and somebody took bullet points. It said, make this a long email, and I made it a long email. They sent the email. the person on the receiving side took that email, summarized it into bullet points. It was like, what are we doing? We just killed like five trees with that, not that many. But still, like that was a cost to servers, to like the environment just to send this thing that the person was thinking in the first place to another person. I think. That was a very off topic rant, but I just love that idea of using AI to provide meaningful benefit, but not to replace your value in this or to waste somebody's time. Erika (20:27) Yeah, I mean, that is a funny illustration. I think to like take it back to to this idea of like audience to like, I think in that example, it's like on either end, it's like you are perceiving what you think the other person wants in sending this as a like paragraph format versus bullet points. But what they actually want is bullet points. So like in those like working relationships to like, I don't know, like it may be is worth, like I don't think about this that often, but it is maybe worth like spending time with people that you work with more frequently to like figure out what the best way to communicate with them is. Like similar to how people are like, I'm gonna customize my, you know, GPT interface to, or like chat interface to like speak in the voice that I want it to. Like I'm gonna give it like. Southern California colloquialisms or whatever. I don't know. That's whatever to me. But I don't think I've thought of that with my colleagues. I think I typically think of how would I want to receive this information instead of, what would make the most sense to them? Bethany (21:33) Yeah, absolutely. It is interesting how as we go forward with this age of AI and stuff, how it's becoming more and more clear. What is the value that we're adding here? What is AI taking over versus what do we still have concrete value in providing? And I think it definitely becomes more and more clear as we go on and probably will continue to as AI gets better or how we reimagine what things... what work looks like past this, but I'm sure we've talked about that at nauseam in other episodes. Erika (22:04) Well, and to like, I don't know, not go too far down this, but like, to make this point, it's like, AI, as good as it will be, will never replace that human element. Period. Bethany (22:14) 100%, yes. Thank you for being clear, yeah. Brittany Ellich (22:16) Yeah, I feel like that's. that's becoming more and more clear. feel like the more that the more that I use it for sure. think one more thing to you related to audience that I think about quite a lot is the fact that we all work remotely. And so a lot of our interaction with our colleagues is through the stories that we tell and through the documentation that we write and through the way that we, you know, convey information. So I feel like another aspect of that storytelling really is kind of like to speak to other things we've talked about in the past is like the personal brand or whatever you are, you might just be your documentation for other co-workers because you don't necessarily get a chance to just hang out in you know an informal way. So I feel like taking time to you know consider your audience and then also to make sure that what you put out there is you know is good storytelling or is it like it's a good you know conveyance of what you know and what you want to share with other people is very important too. Erika (23:15) It's true though, actually, I think that's another vector of communication that we've briefly touched on, maybe to draw the line of virtual versus in-person, being a factor in how you communicate. There's a whole book that I was hearing about that's how to communicate in a virtual setting. ⁓ Like what kinds of meetings to have, you know, like how to craft your messages, like whether to use video or not, like all these things that are present in a virtual working environment that aren't in person. So like, yeah, I mean not to like overthink everything. Like I think, you know, it's, yeah, it's not. rocket science necessarily, but to be conscious of that too. you know, when when there's a screen in front of you, like you might, I think, I think my tendency is like when there's, yeah, like when I'm behind a video or something, like I have to like amplify my emotions when I'm speaking, because it's like there's know, an element of distance there. So if I want my emotions to come across, I have to be that much more expressive in my voice and my face. Yeah. And same with like written communication, like, I have to be like, like, I'll use even more imagery, like, yeah, emojis, GIFs to make it exciting. And, and also like, Yeah, you have the opportunity to make it really clear and concise. Bethany (24:44) Absolutely. I love that the GitHub onboarding mentioned using emojis a lot and written communication to convey what your tone is. And that's such a good point too that over a video, you can see facial expressions and hear vocal inflections, but it's not quite the same as being in person. And you do have to amplify it. I think that's why Zooms end up being a lot more exhausting than just regular having meetings. But that's such a real thing. think also the book we're reading for our book club looks good to me. It mentions this with PR feedback as well and making sure that your tone is good for giving feedback and something that can be very vulnerable for somebody is putting their code out there for review or vulnerable for you to ask a question about it. So making sure that your tone is not accusatory if it's saying, hey, what's happening here? What are we doing here? And then also using different language like we or the PR rather than why did you do this? Why did you choose to do this? So that you're not like putting the person on the line. So I think those kinds of things are so important and a lot of people don't necessarily consider it with written communication, especially as more and more jobs are remote first and communication gets even more important. Erika (26:04) Yeah, she even describes the PR as the opportunity to tell a story. And yeah, she mentions like the PR description as an opportunity to do that. ⁓ Like labels, your like, yeah, the title of your PR, like every, every element of it, of like, yeah, your code, obviously, like every element can be part of telling that story. And go back to the beginning of what you're trying to solve. What's the beginning, middle, and end? Why are you doing this? How are you doing it? And what's it going to look like when it gets deployed? Bethany (26:39) and not just saying, listing a ton of things in a way that people skim past it or don't read it, but conveying it in a concise way and in a way that resonates with people. Absolutely. ⁓ Erika (26:51) I I put a GIF in my PR though. Have I interviewed? I've definitely used emojis, but I don't think I've ever done a GIF. Brittany Ellich (26:58) I did a gif. Erika (26:59) A gift. ⁓ no. Brittany Ellich (27:04) There's one actually that I did recently where I made some sort of a mistake and I used the Britney Spears oops I did it again gift. ⁓ And I loved doing that. Yeah, it depends on what it is. If it's like something quick and unserious like that, then yeah, then I'll do that. I'll use a gift to make it. I don't know. I like bringing levity to people's work. And I always laugh when somebody says something that's like really funny or like quirky or something like if they like have some like weird. Bethany (27:13) amazing. Erika (27:14) ... Yes. Brittany Ellich (27:32) commit messages or something like that brings joy to me. So trying to bring that joy to other people that I work with too when possible. Bethany (27:38) Yeah, bring back weird commit messages. Erika (27:40) Hahaha Bethany (27:41) I know that's a spicy topic. Yeah, I don't think I've, I don't remember putting GIFs in my PRs, but I do put a lot of GIFs in ⁓ discussion posts. I don't do it for presentations though, for an interesting point, but. ⁓ With discussion posts, I'll try to have a theme. I think I've done Parks and Rec theme or the office theme or things like that, or Pokemon theme. I'll try to do a header that grabs people's attention with like, ⁓ what's happening here? I don't use GIFs for presentations though. A lot of people do this, but I think it's overly distracting for the audience and takes away from what you're saying because it's constantly looping. If it loops once, I think that's fine. But if it's continuously looping, like my eyes will definitely start focusing on that. And I think that just takes away from whatever you're saying. So unless you're planning on showing it for a very short period of time, like, I don't think GIFs are good for presentations. Brittany Ellich (28:35) I agree. think the only good gifts that I've seen in presentations is when it's like a demo or something like that. And like it is something that you, you know, it's benign enough in the background that like you can also pay attention to what somebody's talking about. I've used them before for demos for things, especially when it comes to things like if I'm presenting something that is AI related and I don't want to do a live demo because you never know what you're going to get. It's like a box of chocolates. So yeah, that's the only place that I've seen them. worthwhile. Bethany (29:03) Totally agree. I'll probably be using some of those in my Vim talk. I'll definitely need to make sure that it's respectful to the audience and that it doesn't distract or it's additive to the talk. Kind of going on this theme, are there any other tools or techniques you all reach for when creating a presentation or documentation where you want to craft a narrative? Erika (29:25) I will read something out loud and see if it makes sense. That's a pretty low, low-lift way of finding out if it reads like a story. Brittany Ellich (29:35) When I actually just was writing something earlier today and one thing that I like to do is try to read it from different perspectives, like put myself in the shoes of like, all right, what does this look like if I'm somebody on the team that didn't work on this? Or what if, what does this look like if I'm somebody on a different team that has no context of like what this team is working on to see like, what does this release mean to me? Like, is this actually important? So one thing that I usually like to do is to have a section that just says like, why is this important? and use lot of headings and bold and like bullet points to like make it really easy to scan and probably make it look like it was written by Chad GPT. But like, I think there are a lot of styles from that that I've sort of adopted, especially since we use Markdown a lot at work for writing discussion posts and all that. ⁓ where I try to make it easy to find the information based on different personas of who might be reading it. having a TLDR at the top if you just want a summary of it or have a section that says, why is this important to our customers? Why is this important to my team? So make it easy to go find because I think a lot of times people don't read documentation top to bottom. They typically look at it to scan it and just get the most important stuff and figure out what's relevant to them. So that's typically what I like to do. Erika (30:50) That makes me think too of accessibility of information and a lot of the same principles that we use when designing an accessible website also apply to this idea of discoverability. Like those headings, yes, they're like, yeah, headings are a part of the... like accessibility standard, like using the appropriate heading for a piece of information, which makes it easier for a screen reader to understand it, but it also applies for everybody. And to your point, like anybody reading this information will look for a certain like flow of headings, just like naturally. And so like adopting that mindset can help improve the experience for everybody. Brittany Ellich (31:37) actually reminds me too that I have a blog post on the GitHub blog from like three months ago ⁓ with a member of the docs team where he, Sam Browning wrote, you know, a lot of details about like how to write a good doc and I wrote about like how to write good documentation as a whole. I'll share it in the show notes. But yeah, making sure that things are easily scannable is pretty key. Bethany (31:58) Yeah, absolutely. And to that point, I've found success recently with, especially in presentations that are to a larger group that might not have the same understanding of what I'm presenting, adding a glossary to the front of your slides and then sharing out the slides so people can keep it on that slide. is really awesome for being able to ramp up quick with having the same language or the ubiquitous language for what your presentation needs. So I've done that a couple of times in our availability review. And this was part of the advice of somebody who was doing availability reviews a lot. And it's been really awesome. And I've gotten a lot of good feedback from that. it seems that empathy is that you win when you're empathetic to your audience or to who might be looking at this. So. Empathy is a good first step to telling a good story. All right. Well, we are coming up to time. So let's do our fun segment. I am actually stoked about this. I had AI create a mad libs. So I don't even know what the story is going to be. But it's developer related. And we'll fill it out together. So do we want the great incident response, deployment day drama, new developers first day, or architecture decision meeting? Erika (33:17) decision meeting. Bethany (33:18) Let's do it. All right. So adjective describing importance. Brittany Ellich (33:19) Let's do it. Regal. Erika (33:23) ooo Bethany (33:24) Okay, a noun, like a system component. a cache widget. I like it. I like it. Let's do that. Erika (33:27) widget. Brittany Ellich (33:29) yeah, which it is a good one. Bethany (33:31) Alright, a verb discussing action. Brittany Ellich (33:34) Computing? processing's better. Yeah, let's do processing. Erika (33:34) Processing. Bethany (33:37) Wish I had Erica's songs for SAT vocabulary and I'd be doing a lot better here. How about a large number? Like 40. one million. What about one billion? Yay. Erika (33:41) you Brittany Ellich (33:42) you one million. One billion. Erika (33:50) Yes. Bethany (33:51) All right, a senior developer name. Hmm. Erika (33:54) Britney. Brittany Ellich (33:55) I was trying to think like, ⁓ I was trying to think of something like generic man, man, John or something. Bethany can be the other one. Bethany (33:55) How about another? ⁓ what? Erika (34:04) I'm Bethany (34:05) Alright, the other name will be John or Bethany. We'll do John because he's not here. Make him part of this. Adjective describing disagreement. Erika (34:11) Just for you. Hence. Bethany (34:15) movie. Brittany Ellich (34:16) I bet you did great on the SAT. Bethany (34:16) Technology. Yeah, I know. I'm so jealous right now. Actually, for listeners who might not know this, Erica is a star at Crossword. She does the New York Times Crossword like nothing else. How about a technology framework? What's like technology slash framework? So we could do like Kubernetes or like Next.js. All right, I'll do that. Erika (34:18) you Brittany Ellich (34:25) true. Erika (34:28) you Brittany Ellich (34:37) yeah, Kubernetes. Bethany (34:39) Alright, a different technology. Brittany Ellich (34:41) astro. Bethany (34:42) Yeah. okay, like a noun for a meeting room item. A marker. Brittany Ellich (34:46) Stay Blur. Bethany (34:47) All right, let's do stapler, that's Verb for a decision-making action. excited, selected, nominated. Erika (34:53) finalized? finalize? Bethany (34:55) I like that. All right. An adjective describing outcome. succeeded, no, successful. Erika (35:01) floppy. Bethany (35:03) that's amazing. Do you want floppy or flappy maybe? Like a flappy monitor? All right, finally time period. Erika (35:06) Slap you. Brittany Ellich (35:12) Era. Erika (35:13) Thank Bethany (35:13) I love it. All right, let's generate our tech story. All right. The team gathered for a regal architecture review meeting to discuss our new widget system. We needed to process how to handle 1 billion concurrent users without breaking the bank. Brittany was convinced we should use Kubernetes, while John became tense and insisted that Astro was clearly the superior choice. The debate got so intense that someone threw a stapler across the room. After three hours of Erika (35:43) Definitely John. Bethany (35:44) Oh, man. Yeah, John is definitely the type to throw a stapler. After three hours of passionate discussion, we finally decided to finalize and go with a hybrid approach that made everyone equally flappy. Six era later, we realized we should have just used a simple database and called it a day. But hey, at least our documentation is impressive. Alright, that was fun. That was! You had to like modify for tense live, but we have three more of these so maybe another episode we can come back to it. Erika (36:09) Maybe I'll go first. Yes. ⁓ Brittany Ellich (36:20) fun. Bethany (36:22) All right. Wow. With that, thank you so much for tuning into Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. As a reminder, we are still leading a Looks Good to Me book club, and there is still plenty of time to get involved. It's all async, so please feel free to leave comments on old discussions, new discussions, all that. Check out the show notes for more info. Until next week. Bye. --- ## Episode 22: Gamification | Boost Programmer Productivity & Career Growth - URL: https://overcommitted.dev/gamification-boost-programmer-productivity-career-growth - Published: 2025-08-26 - Topics: Productivity & Learning, Imposter Syndrome & Mental Health, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/107303493/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-7-25%2F406224544-44100-2-aeeada2c1ae1c.mp3 ### Show notes Summary Gamification isn't just for games—it's a career growth and programming best practices catalyst. In this episode, we explore how engineering culture can adopt game mechanics to boost programmer productivity, prevent burnout, and create sustainable learning environments. From leaderboards to achievement systems, discover how top teams are leveling up development through play. Links * Feel good productivity [https://aliabdaal.com/feel-good-productivity/⁠ ] * ⁠⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠Overcommitted Discord⁠⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠⁠⁠⁠Overcommitted.dev [http://overcommitted.dev] * Bethany Janos [https://github.com/bethanyj28] * Brittany Ellich⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠Eggyhead [https://github.com/eggyhead] * ⁠Jonathan Tamsut⁠ [https://infinitely-fallible.bearblog.dev/] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Erika. Join by. Bethany (00:09) Hey, I'm Bethany. Brittany Ellich (00:10) Brittany? Jonathan Tamsut (00:11) John. Erika (00:11) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we are happy you're listening. Today, we are talking about the role of gamification in software development. I first came across this idea reading feel good productivity, which introduces a study conducted by Mark Rober, a NASA trained engineer who recruited 50,000 people to try a new computer challenge. And participants were divided into two groups when they wrote code that didn't work. One group received a generic error message that said, you have failed, please try again. And the other group received the message, you have failed, you've lost five points, you now have 195 points, please try again. And the results are really interesting. The participants in the first group made an average of 12 attempts and had a 68 % success rate. And those in the second group made an average of five attempts and had a 52 % success rate. So the takeaway here is that we are afraid of failure, even when it's arbitrary and left to chance. When he was sharing his findings, Rober posed the question, if we could frame our learning process so that we weren't so concerned with failure, how much more could we learn and how much more could we exceed? So in the book, Ali Abdaal, the author, suggests that we imagine what life would look like if we received five proverbial points for failing rather than losing five, like in the experiment. And so today on the pod, we'll be talking about applying this idea to our professional life as software engineers, including how we currently experience this fear of failure and how to foster a culture and environment where mistakes are seen as opportunities for growth and some potential risks for gamifying a process. So let's start with this idea called the Super Mario Effect. which comes from Mark Roper's research where he discovered that in video games, because dying or failing a level isn't a penalty, the focus is on this end goal of winning the game, not the fear of failure. So that's the opposite of that losing five points. And so my question for all of us, maybe starting with Bethany, as a software engineer, how much... Do feel like your work is about trial and error? Bethany (02:46) Yeah, so at GitHub, think we have a really cool, I don't know what you'd call it, a saying, but it's ship to learn. We're actually encouraged to try to try things out in production and validate our experiments or our thoughts. I think there is definitely a lot of trial and error, but I think that you also can leverage data and metrics and things to understand what you're doing better and gain more criteria on what is success, what is failure. And so I think while there is a lot of that, there is a way to safely introduce these tests and experiments without necessarily making the product worse or making it a bad experience or whatnot. So I think it is interesting to think about how to test your ideas and thoughts in as much of a real world environment as possible, but also being safe about it in a way. But I don't think it's necessarily important to scrutinize over this incidents happen and you can't let fear of an incident. prevent you from actually going and doing cool stuff. Jonathan Tamsut (04:03) Yeah. Erika (04:03) Yeah, so Brittany, John, do you ever find that fear of failure, like introducing a bug or breaking a build, can stifle your creativity or willingness to experiment? Jonathan Tamsut (04:16) You go for any if you want. Brittany Ellich (04:17) I so. think, I mean, sometimes I am really nervous as I'm working in a new area and it takes me a little while to build up the confidence in a new area that the change that I'm making is not going to break something. But I think as I gain more confidence in an area, I feel like that fear of failure tends to go down. think I've noticed throughout my career too about the value, like Bethany said, of experimenting. And I think what I've learned over time is that that trial and error and experimenting, what becomes more important is being able to like put data behind things and show what you predict the change is going to make a difference, make a change as, and what you think that experiment is going to do. And then actually following through and running it sort of like a science experiment instead of just trial and error. So informed trial and error, I guess. Jonathan Tamsut (05:05) Yeah, I feel like the associations I was making when we were talking about fear are like, what it's sort of like maybe, I think like fear comes out maybe when you're like, proposing a solution to a complex problem. Like if you're writing an ADR, I feel like there's sometimes fear about unknowns, if there's a high complexity situation, you know, if you're the... sort of one who's in charge of this and who's sort of at fault if things don't go wrong, I think there can be fear and stress. And I think, you know, part of that is like social, like, you you want your colleagues to think highly of you. Part of that is, you know, I think, you know, I mean, right, it's like, it's funny. I mean, I think in a corporate environment, you know, I mean, there's this, you know, shift to learn saying, I think, Right? To the degree to which that's actually in practice. I think, I question it, right? Don't ship bugs. Be really careful and mistakes are penalized. I think there's also kind of another association I was making with like, I think people, especially people at big tech companies, well, yeah, I'm kind of blasting people at big tech companies, so I apologize. I think people with secure jobs can be afraid of ⁓ risk taking. I saw a quote recently that was one of these silly LinkedIn quotes, it was like, would you do if you wouldn't fail? I've been recently looking for a job and just reimagining my career. I do think there's fear up and down the stack. In terms of trial and error. I don't know. Whenever there's a trial, there's an element of risk. Anyways, those are some general free-form associations I was making. Erika (06:46) Yeah, I think you touched on an important point though, which is that this idea of success or failure happens on different levels in the software development lifecycle. So it can happen at a feature level or it can happen at like an overall level and like anywhere in between that. like, you know, anything, anything from like the success of your company down to a single feature can impact like success or failure and can be seen as like winning or losing depending on your sort of criteria for success. And I also think that sort of what you were saying reminded me that we often don't, or maybe it was something Bethany was saying, like we don't necessarily consider the factors for success or failure. of any given feature or project always at the outset. Sometimes we do, and that's good, but I recently did a pre-mortem for a project, and it was exactly this thought experiment of what does success look like, what does failure look like from a technical level? Because I think the first thing that my mind goes to with failure is, And what I personally experience with the fear of failure is this project doesn't complete on time or this project doesn't complete at all because we take too long and leadership shifts priorities or leadership shifts priorities in the middle of working on it it's going perfectly fine. And how does that reflect on me? Was it because of something I did? And yeah, definitely, like you said, when you're leading a project, you feel like you have a lot of investment in it. And it does feel like a personal, like, yeah, I personally feel it personally when things don't go well. But a lot of times that has to do with sort of like knee-jerk reactions of some comment somebody made on an ADR, like, you know. pointing out constructive criticism of an approach or yeah, like, we set this deadline and we're past that deadline. So I guess there's an opportunity there to say like, hey, know, self, is this constructive criticism bad? Does it mean that I'm failing or does it mean that, you know, this person's engaging? And so that's a positive thing. Like getting feedback in itself is a good thing. And like maybe shifting the mindset of how I respond to that. Yeah, and like, you know, dates slip, like it's kind of a fact of life, but are there other things that are going well that you can focus on and celebrate alongside that to maybe offset the frustration that's happening? Jonathan Tamsut (09:28) Yeah. Brittany Ellich (09:29) I think my biggest fear of failure when it comes to leading a project like that is what if we get to the end and the problem that we were trying to solve isn't solved by the solution. And that's a thing that keeps me up at night is thinking like, okay, but is this all adding up to solving the problem that we wanted to solve in the first place? Jonathan Tamsut (09:47) Yeah. And it really, you know, it's funny, like, I think it's an element of corporate culture and just, I mean, and I think like all companies have this to a certain extent, or at least every company I've worked at, but like, wouldn't it be great if like, I don't know, like, like you obviously need some fear of failure or else to incentivize you, but we sometimes we worry so much about it. And I think the way people talk about failure is, you know, people can be so hard on themselves. and hard on others. Yeah, and it would be, I don't know, I think there's maybe like a happy medium where like expectations are high for yourself or whatever, but like you're not sort of haranguing yourself if you make a mistake. Yeah, there's kind of a tension there. Erika (10:27) you Well, that's it. Jonathan Tamsut (10:28) But the last thing I was gonna say is I do think trial and error though is specifically in tight feedback cycle learning is like super, like the example you gave is like. super, super important. It's sort of like, I think of it like as a sort of a neural network where you're like back propagating along the weights of a neural network and you're adjusting them to get like a, you know, ground-tree representation. And it's like, that's kind of, you know, it's like, think trial and error is just like such a fun way to learn where you're kind of like, oh, I'm going to try this problem. I got it kind of wrong. What did I get wrong? You know, I, and I wish there were more, I've talked about this before, but I wish there were more platforms that taught. Erika (11:04) Yeah, and I guess also related to this, like we're talking about this idea of, so like the end goal and focusing on the end goal or criteria for success and failure as a like personal motivator. But I think in the example that I gave to of starting a project and something going wrong and then being worried about losing funding for the project, that idea of focusing on the end goal can also serve to motivate others and like, you know, having like reiterating like this is the point of doing this. Like we can't quit until we, you know, reach this milestone or this, you know, point of point of decision. like sometimes, yeah, it's your point. Like sometimes you try something and it doesn't work. But yeah, like I think the failure part of that is not the bad thing. The bad thing would be never knowing when you get to the point of like, you know, continuing to sink into a problem and having it not going anywhere, like spinning your wheels. Yeah, so sort of building on that, some suggestions that I've heard for applying gamification to engineering, software engineering include these safe sandbox environments where you can experiment new approaches, or I know we have tooling for deploying feature experiments in production. ⁓ and viewing performance and behavior related metrics or establishing a system where you break down unfamiliar complex topics into quests and levels and use that to motivate achievement. So somewhere that might be familiar somewhere like Code Academy where you have a topic broken down into levels and you you know, check them off and win badges and stuff like that. So have any of you experienced any of these approaches in your work? And if so, how did they impact your motivation? Maybe I'll pass it over to Brittany first. Brittany Ellich (13:12) think I have a direct one-to-one with the levels, but that's often, I think, the feedback that I'm looking for from completing tasks and completing epics, where I'm completing these things that lead up to this big thing that we can close. I feel like I get a lot of the same satisfaction that I get out of completing a level in a video game. I'm just like, ⁓ yes. That to-do list is complete, and I really enjoy that feeling. Jonathan Tamsut (13:21) Thank you. ⁓ Brittany Ellich (13:36) and I maybe I think maybe that was like kind of the reason behind the term epic to begin with I don't know I feel like that's very you know somewhat game related yeah but yeah I would love to see more gamification of those types of things going forward I know at GitHub anyway we don't really do any story pointing I think every team does everything Jonathan Tamsut (13:45) the games. Brittany Ellich (13:57) their own way, but we don't really do any story pointing. But in the past, I've worked on teams where we estimate things and assign story points. And I feel like having those story points, was like, ooh, I want to complete the most story points in this sprint out of my team or something like that. And I feel like that's another sort of way that people kind of gamify getting things done. But obviously, if there's a way to game it, then there's a way to exploit it and make it not totally accurate. Jonathan Tamsut (14:17) Yeah. If I'm being honest, there have been times, like actually like when we were, you know, working on. GitHub stuff as a team, you know, when we were on the same team where I would look at the contributor graph and be like, I got to, I got to climb to number one. And I would like be like, okay, surpass that person's day. Okay. Got to make a couple more commits. And honestly, mean, it was just, it was really motivating to me. And so, yeah, I mean, I, you know, I, I like my gold stars for sure. The other thing I was gonna say, and this is kind of slightly, or maybe this is just an obtuse take, is that like, you know, I've been thinking a lot about fear and how fear guides so much of our choices, and it's like, I really don't wanna have like a boring or unfulfilling career, because I was like too afraid to take a risk. And so I think the part of maybe this gamification is like, you know, kind of push yourself to take risks. and recognize when you're afraid and maybe try to get to the root cause of the fear and deal with it in healthy way. I think that I'm someone who's been guided by fear and worried. I've made a lot of important decisions in my life just because of that. it's like, well, I don't know if that's the life I wanna live. I wanna take risks and make... you know, bold decisions that are in line with my values. And I don't want to always, you know, play it safe. Bethany (15:31) I think it's so interesting how we each kind of interpreted this question in terms of like John with you and career moves and how you're handling those. And Brittany, like I relate so much to the to-do list and getting things done. My mind went in a couple directions. One was when, again, when we were all on actions, there was a point where we were trying to determine how to get people to use their L &D time more because a lot of people had just worked through that and that created a kind of negative cultural implication saying, maybe I shouldn't be using my L &D time. really, I believe that the the reason behind that was because people aren't necessarily rewarded for doing L &D work as much. They were rewarded for doing their regular assigned work, whether it's deadlines or checking off that to-do list. L &D was kind of this amorphous, scary thing that you had to actually do work to even jump into. So it was really interesting how even gamification played there and how we considered rewarding L &D in a way that made people want to do it and want to see it as something that could help their career or help their visibility within the organization. So I that was a really interesting thing to go after in terms of process. Initially, when you said sandbox, I was thinking of different environments that we use to do this trial and error. like local development and staging and production. And there's different risks for doing it in each environment and different pros and cons. And I think with those environments, it's so important to In a way, make it easy to test locally. Make it easy to test in staging before you test in prod or something. Because it's not necessarily bad to test something in prod that you really need to, but it's going to be way less risky and give you a lot more information if you can do it locally and then in staging first and help you have the data behind what you're looking for before you try it in an actual production environment. So that's where my mind went first with this question, but I love the different ways we kind of took it. That's awesome. Erika (17:46) Cool. think, yeah, nothing's nothing no software change is ever going to be risk free. No matter what kind of mitigation strategies you have. But I think what we were talking about before of like focusing on the goal and like what success looks like and like being clear as a developer of what you're looking for in any like change or project. at least helps break out of the cycle of like trial and error going nowhere, like spinning your wheels, which I think is the most demotivating for me. And I'm like hacking at a problem and like don't even know what the end result is supposed to be. And yeah, that mostly is like stopping, figuring out. what the problem actually is, like redefining it and then like moving forward. And I, I admittedly don't play a lot of video games, but I'd imagine that's like a similar approach in video games where you will actually never win the level if you don't figure out why, why you keep dying. Awesome. Well, we already kind of talked a little bit or hinted at this, that there might be some trade-offs to gamifying a process, especially considering that some of these suggestions for gamification can include these external motivators and also in some company cultures, as we've hinted to, the idea of failure in itself is taboo because if we're failing, then we're not winning. And we want to be winning all the time. So how do we respond to those trade-offs, the trade-off of, you know, accepting failure as a part of the process compared with wanting to win overall and then this idea of external versus internal motivation and balancing those two. Maybe I'll pass it over to Brittany because you were the one who were who was talking about the external motivators before. So let's start with that one. How do you how do you balance the external motivation with your internal motivation? Brittany Ellich (19:56) Yeah, I think that this is a very slippery slope that it seems like most teams end up going down if they're doing something like, like if somebody's rewarded for doing, you know, they're recognized for closing so many story points or for putting in all these extra hours after work, people are going to keep doing those things so that they also get those motivations, that they get those rewards. And it's a very dangerous thing to think about how people are being motivated and recognized because that's what you're going to be. reinforcing within your team. I think what you brought up with the intrinsic motivation too is a really interesting point because especially when it comes to things like L &D like Bethany talked about learning and development. The motivation there really is, has to be to learn more, otherwise people aren't going to actually get anything out of it. And if they don't use that time, then that's fine. But I think, you know, making sure that you set aside that time as like, this is specific time for this. If you don't use it, that's great. But don't like try to get ahead on work during this time so that, you know, it's fair to everybody else that is also spending their time doing this. We don't have to expect people to put in a bunch of extra time outside of work to do this. Yeah, I don't know a good solution here. Maybe the good solution is to not do things like pointing stories, which luckily we don't currently. Maybe that is part of the problem. Same thing with, you know, estimating timelines. Like they're never really accurate. So like why even try to estimate? I know somebody needs to know how long something's going to take, but even if I guess at it, it's probably not going to take that long because... of a billion different factors that lead into building software. yeah, lot of trade-offs. Jonathan Tamsut (21:29) Yeah. I think, think, Brady, you brought up so many good points. Like, I think the two that kind of stood out to me were like, one, you know, I think it's important to realize, you know, if you're that, you know, when, when you're playing a game. So I think people, you know, you know, with games, there is a typically a singular or narrowly defined objective that you're optimizing for at the expense of all others, you know, all other sort of things. And so like, You know, I think, you know, you know, that could lead to a bunch of, you know, sort of perverse incentives or, you know, outcomes that aren't necessarily desirable moral hazard. And I think that's like important to know is like, you know, realize you're playing a game, realize you're optimizing for this and realize, I guess realize like, like know when to quit or, you know. And then I think the other thing is like intrinsic versus extrinsic motivation. This is something I've struggled with a lot and like, have talked a lot about with people. And I think, for so much of my life, like doing things to impress people or to spite people, even prove people wrong, has been so much of a motivator. And I've recently been trying to develop more intrinsic reasons for doing things. And I think you ultimately are going to be happier when you're kind of just doing things for the love of the game. Brittany Ellich (22:46) I do have one thing to say related to realizing that you're playing a game. think one thing that comes up really frequently with software development is trying to, like John had said, have the most commits or to like close as many issues or mark off as many as you do items is close as many pull requests. And that can often be a game that people are playing within their team or within their organization to try and say like, look, how good our team is. You should give us all the resources. And one thing that I found recently is I've been looking into my own stats around this. And I think that I found some stats that are a little bit more important to me. And I think identifying like, okay, what are those stats actually mean? Like closing the number of pull requests doesn't necessarily mean anything because like you could have really tiny pull requests that are just updating docs, but like it's still a number. But then I've realized that the number of pull requests I've reviewed, like that's actually a more interesting statistic where I can say, look at my impact across this team or how I've unblocked other members of my team. So recognizing which numbers are actually meaningful to try to gamify because if you're going to gamify something, try to find something that actually means something instead of lines of code, which we all know is a terrible metric to measure anybody by. Erika (23:55) Yeah, that reminds me of the sort of like conversation around AI enabled software engineering and the idea that AI is a superpower or like, you know, LLM assisted coding is a superpower. And it's like, feel like every time I hear this conversation, it's around creating code. And you're like, okay, like. you know, but how long does that code take to get to production? And how many like incidents does that code cause? Like there are so many other questions that are not answered in that one very narrow view that also need to be considered for like effectiveness. Yeah, so I don't know. It's kind of an interesting like related conversation. strictly gamification, but a little bit because, you know, like you said, Jonathan, like, to some extent, it always kind of feels like you're playing some kind of a game, like working for a company, like, yeah, there's there's motivators, intrinsic and extrinsic. you know, a job inherently has external motivation by how much you're paid. And when your payment is related to your performance, like, Yeah, like how well you perform does matter directly to that extrinsic motivator. I think, yeah, it's a tough question maybe for another day of like, you know, how we define success for ourselves. I think that's a topic in and of itself. ⁓ But yeah, at least recognizing Jonathan Tamsut (25:10) Yeah. Yeah, totally. Erika (25:27) that there might be like different goals at play. And I think your point, Brittany, was like defining those goals for myself gives me agency and sort of like takes me out of the hamster wheel of the game that I see being played. So I at least know like I am being successful in these ways regardless, or maybe hopefully in combination with how I'm expected to be successful from the company perspective. Bethany (25:57) I think too, whenever something defines a success criteria or a reward or you're trying to hit certain KPIs or you're trying to hit this many commits or this many XYZ, there's always going to be a set of people that will further game that system. Jonathan Tamsut (26:02) like to say thank you. Bethany (26:20) And so I think that might be another trade-off of gamification, because if you're knowingly saying, I'm going to set a reward for doing that, there's always going to be a subset of people that will be like, OK, well, I'm going to hyperfixate on this exact reward. And you might not get the expected results that you're trying to get for having that reward in the first place. So I think it can definitely be a slippery slope to get. have rewards for behavior you want to reinforce just because it can lead to unexpected consequences of what you're actually trying to achieve. Erika (26:56) Yeah, I think another way to kind of take back power too is like being a good human to people around you. Like, I really appreciate compliments and like celebratory moments. And like anyone can make that happen, right? Like if you see somebody who like, man, they got stuck in a terrible incident and like. you know, they probably feel like this was awful. Like I didn't know how to handle this or, you know, maybe they were stuck in a really tough situation, like celebrating that person for like stepping in, trying, or like trying something new. Like you can be that voice that's like, it's okay. You did a great job. Yeah. Or like on a pull request review, like, Hey, like, you know, this approach needs change, but like, Here's positive feedback as well for trying. ⁓ And I have experienced that and feel like that goes a long way. Jonathan Tamsut (27:48) Well, Erica, think you're doing a great job leading this podcast. celebrate you. Erika (27:51) Thanks. I'm looking for a gold star at the end of this. Jonathan Tamsut (27:55) Yeah, it is funny how some people, yeah, I mean, you you deal with all, you work with all different personalities and some people are more withholding of their praise. Erika (28:03) Well, cool. Thank you all so much for exploring this topic with me. And we're going to move on to our fun segment at the end. So our question for today is, if you could be a character in any video game, what would it be and why? Because we're talking about gamification and inspired by video games. So I can start. And this my answer, I have two answers to this question, which both reveal how long it's been since I've meaningfully played any video games. So the first answer is Street Fighter. I think it's really fun to like live in that grungy universe and like kick ass all the time. So that's my first answer. And then the other complete opposite end of the spectrum is Neopets because everything is so cute. and like fluffy things all the time. Jonathan Tamsut (28:52) Do you still play Neopets? Because I know someone who's actually pretty involved in the Neopets community. ⁓ Erika (28:58) Do you really? I know somebody who like recently revived their account. I have not tried, but yeah, I might. Jonathan Tamsut (29:06) It's a robust community I've learned. I can go. Yeah, I'm also not a huge gamer. mean, growing up, I played video games. But yeah, I'd pick Mario because I like that he's in the trades. He's a plumber. I think working with your hands is kind of cool. He's also like an Italian guy, but he was invented by a Japanese company, which I think is kind of interesting, funny. And I watched the Super Mario Brothers movie. Not with a child, just with my friend. We just went to the theaters and saw it. It was honestly one of the best movie-going experiences that I've had. I recommend the movie. Brittany Ellich (29:44) That's good. That would be a good one to see in theaters. I'm sad that I didn't see that one in theaters. My answer is also reflecting on how long it's been since I've played a lot of video games. I this was one of the earliest ones that I played. I used to play a lot of NMO RPGs, which are like the... Massive multiplayer online games like World of Warcraft and one of my very favorite ones was called Star Wars Galaxies. It was like a really long time ago, but it had one of the best skill trees of any game like I've ever played and it was like the most dynamic and interesting skill trees and ways to like get new skills. And I still think back to it all the time when I'm like, you know, like closing out issues and like trying to knock off things on my checklist. Like I felt like it was a very satisfying way to think about building skills. So I still think about that game a lot. So I think it'd be fun to be in that game world. Plus then you could go to be in Star Wars, could, you know, fly around on... What rockets? No, they're not called rockets. They're called something else in the Star Wars. But yeah, anyway, that's what I would. That's yeah. Yeah, you can be a Jedi. How cool would that be? Like I want Jedi powers. That'd be so cool. Erika (30:39) Yeah. Shit, it's great. I feel like this is making me think of a GitHub feature request that would never actually fly, but maybe we could like crowdsource it as like contribution graph skins. Like if you could create like a Star Wars galaxy skin for your GitHub contributions, relive it. Brittany Ellich (31:07) That would be really cool. Jonathan Tamsut (31:08) We could sell them. Bethany (31:08) I mean, we do, we do change it to spooky theme for Halloween, Erika (31:12) That's true. Brittany Ellich (31:12) Mm-hmm. That's true. But I like that idea of like, okay, if you get so many, you know, commits in a specific repo, then you can, yeah, like that idea. Bethany, which would you be in? Bethany (31:24) I would probably choose like Stardew Valley. it's just such a cute game. I, it's my comfort game. I always go back to it and love it. So you can do so many things. You can just chill or you can go fight monsters in a cave. And I love that the duality, you Erika (31:41) Very you. Monsters and farming. Well, thank you all listeners for tuning in to Overcommitted. If you like what you hear, please follow, subscribe, or do whatever you like to do on the podcast app of your choice. Check us out on Blue Sky, share with your friends. And as a reminder, we are still... doing our Looks Good to Me book club and there's plenty of time to get involved, never too late. So check out the show notes for more information on that and hope to see you there. Until next week, bye. --- ## Episode 21: AI Agents in Software Development | Bridging Automation and Engineering - URL: https://overcommitted.dev/ai-agents-in-software-development-bridging-automation-and-engineering - Published: 2025-08-19 - Topics: AI & Developer Tools, Technical Deep Dives, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/107047151/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-7-19%2F405895532-44100-2-9e865adb22143.mp3 ### Show notes Summary AI agents are reshaping how software engineers work—but what exactly are they? In this episode, we break down AI agents for programmers: what they do, how they fit into your software projects, and why understanding them matters for your career growth. Whether you're worried about automation or excited about the productivity boost, this is the primer you need. Links * ⁠Building effective agents [https://www.anthropic.com/engineering/building-effective-agents] * ⁠Balanced Engineer Newsletter [https://balancedengineer.com/] * Plausible Schemes [https://www.conviction.com/startups.html] * Embedding models [https://python.langchain.com/docs/concepts/embedding_models/] * Obsidian Copilot [https://github.com/logancyang/obsidian-copilot] * ⁠⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * Overcommitted Discord⁠⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠⁠⁠Overcommitted.dev [http://overcommitted.dev] * Brittany Ellich⁠⁠⁠⁠⁠⁠ [https://brittanyellich.com] * Eggyhead⁠ [https://github.com/eggyhead] * Jonathan Tamsut⁠ [https://infinitely-fallible.bearblog.dev/] ### Transcript Jonathan Tamsut (00:00) Hey, what is up? Welcome to the Overcommitted Podcast, where we talk about our code commits, our personal commitments, stuff in between, and just generally have a good time. I'm your host, Jonathan Tamsit. I am joined by... Brittany Ellich (00:14) I'm Brittany. Erika (00:15) And I'm Erica. Jonathan Tamsut (00:17) We are software engineers. initially met as new hires at GitHub and we found a common interest in continuous learning, building interesting projects, and just being a human in the tech world. We continue to meet to talk about stuff we've experienced and discuss our lives in this crazy world called the tech world. whether you're pushing code or taking on new challenges, we're happy you're listening. And today we're gonna talk about a pretty trendy topic, AI agents. So I think this is something that we're all kind of exploring and I think is kind of new to the industry. And yeah, we just wanna kind of, I guess, learn and I think this will maybe be like a learn in public type conversation. And... we'll kind of see where this goes. So I guess to kind of start us off. why are AI agents exciting to you? Why are they interesting to you? I mean, I think there's kind of like the obvious reason I think for me is like, you know, we have these, tools, these large language models, and they're capable of information retrieval and generating text and reasoning. And I think that there's a bunch of jobs that humans do that are boring and that humans don't want to do. And I think it's just interesting to see how can you take these building blocks of AI tooling to develop these you know, ⁓ agents or whatever, these entities that kind of are able to kind of perform these tasks. And I think like, you know, kind of, you know, kind of in my dream, like a lot of these tasks, like it's like human out of loop, like humans aren't involved at all. But yeah, I guess, yeah, like, I don't know. Yeah, why are AI agents interesting to you? Like when you guys hear the word AI agent, kind of what about that excites you? I'm just curious. Kind of a vague question, but. Brittany Ellich (02:15) I can go first. So for full disclosure, the extent of my experience with AI agents is really using tools that are already pre-built for this, like the GitHub Copilot Coding Agent. That one was really nice to use because I can just start using it with a GitHub issue, and that was not outside of my comfort zone in terms of things that I was already doing. But I am very interested in learning how to build my own agent, and I think... I think I find it really interesting because I think it's a new way to think about solving problems. You know, previously it's about like, you're going to build this deterministic route of like this to the API to this, to like gather stuff. But then you're going to have to do a lot of thinking about the data that you get back and decide what to do with it. And the idea is with an AI agent, can theoretically offload some of that thinking. So thinking about this. episode and preparing for it I was thinking about okay what is a practical problem that I could try to solve with an agent and I came up with a whole bunch of them and so now I'm really excited to learn how to build them and learn what to do with them so that I can ⁓ actually partake in this trend. Jonathan Tamsut (03:07) Mmm. Erika (03:19) The thing that interests me the most is the breakdown of the problem. I've similarly only used GitHub Copilot Agent Mode, but I find it really interesting how it breaks down the problem, which is a critical part of building an agent is understanding how to direct the model or the agent to. like take sequential actions and use like outside resources. it's second brain to the like fullest degree where you have to like, like you have to know how you would solve the problem. And sometimes it's not always the same like the way the agent does it and the way that I would do it. So I think that's a, it's an interesting. way of thinking of putting on my computer hat and thinking how I would think about something as a computer. And it's kind of a true truism for all software engineering, but it's a systemized version of it versus individual problems. And like thinking of how you achieve an end goal. Jonathan Tamsut (04:25) you Erika (04:28) versus solve like one specific problem. Jonathan Tamsut (04:31) Yeah, I think, know, so I kind of like proposed the topic of talking about agents. I mean, I think we're all interested in it. But one of the things that was kind of inspiring to me was there's this venture capitalist, name is Sarah Guo. She started a VC firm called Conviction. And she has a list of startups that are like potential ideas and she also gave a talk and I'll link the list of serves and talk and the show notes, but I think great like I think one thing she said was, you know, You know, a few things. One is like, you know, I think that like we have to fundamentally rethink the user experience with agents, right? So I think like software, you know, we have tables and infinite scrolls and there are these like primitives that exist currently with like modern software and you have, you know. You know, the paginated table or the infinite scroll or whatever, and users are clicking buttons and reading things. You know, you have, you know, your 10 blue links, whatever, with Google. And right, like I think with agents, I think that like, and I don't know, I don't know what the, the best interface is, but I think there's a different interface that exists. like, for example, like I was listening to podcasts with the guys who created Cursor. talking and they were saying that you know one of their, you know, in a few views cursor, this actually works really well, they have this feature where when you're done typing it will predict where you would want to add code next and take you there. So it has this, this is like a small UX thing, if you're like typing in a file, you know, let's say you like update a variable name, it'll say okay like now do you want to go to this file and update the variable name. And it's like this like small UX thing. And they were talking about like, you know, they have like a model that basically outputs, you know, it predicts where you're going to go next. And so I think there's just like, I think there's like a different way of us interacting with, you know, technology. mean, another example is like, instead of going on and booking a flight, you know, maybe there'll be an agent where you just describe the kind of constraints you have and it'll go off and do it. Right. And so I think like, Yeah, so Sarah Bow talked about this. The other thing she talked about was like, you know, like we've talked about previously this like dream of artificial general intelligence. And I think like, you know, in the short term, you know, maybe before AGI has reached or if it's ever reached, right, there's gonna there's like, this incredible opportunity for people who are like domain experts in something to build agents that like perfectly solve a problem for a certain type of person. So you can think of like support customer, know, support staff, you know, that's an example. But like, I don't know, if you're like an expert in construction or whatever, like there's, there's, think there's like a ton of start ups, just like we're building the cursor for X, we're building the cursor for construction, we're building the cursor for help, you know, for, nurse skilled nursing facilities, et cetera. And I've like seen a lot of startups that are being funded for this. So I think, I think like, you know, agents, like a fundamentally new paradigm for writing software and a new interface. And I think that's like interesting to explore. It's kind of the TLDR I ramble. Okay, any thoughts or I guess we can, if not, can kind of, I guess talk about, yeah, maybe we can like just define what we mean by an agent and you know, maybe, if there's anything that kind of, you know, sparks your interest there. So I guess, ⁓ kind of just kind of setting some context. so, you know, agent is like, yeah, like in general, an agent is, it's kind of like a term that is, I think, existed in artificial intelligence for a while, but in our context, it's like, there's kind of three things an agent does. It... perceives some input. an agent can either receive text or can make an API call or whatever. It uses that to plan its next action. It acts. And so that action can be calling a tool or firing off, doing something or responding to a user or something. then you kind of have this chain of like, perception, deciding what to do acting, and then kind of like starting over and over again. We've talked about previously agents often have the ability to use tools. And I think agent is kind of an overloaded term. Like the quote unquote agents that I've kind of experimented with have been just like basically continuously calling. you know, the open AI API. like, you know, like I, I, built, I built, I built an agent, you know, or I built like a Python script to get my emails and like help me decide, ⁓ you know, how do, how to like, you know, respond, you know, help sort my emails in terms of, you know, priority items. I also said to myself, like to do items via my emails. I wanted the LLM to like, grab my to-do items, sort them between personal and work, and then list them. And they're sort of unstructured. So I guess, I think one question for you guys is, when you think about an agent, what do you guys think about? Thinking about that definition, what to you as an agent? And I know there's a lot of of definitions here but I'm just curious like what your understanding or opinions or whatever. Brittany Ellich (09:54) My thoughts are that it's just like a programming loop, like you would have for any other thing that has previously existed, but it involves AI at some point or LLMs at some point in the process where one of the steps that it's involves that. I think the... Jonathan Tamsut (09:58) Yeah. Brittany Ellich (10:12) Important thing is that those loops have existed, being able to generate your own loop that will go through and do a task for you has existed for a very long time. And this is just applying that same concept to using LLM tools as part of it. Jonathan Tamsut (10:25) Yeah, yeah, and there's like a bunch of, I think Anthropic has, and I can share another, I came across a while ago, like, yeah, I mean, I think, right, yeah, like fundamental to like core pieces of an agent or like the model, models. One thing we can talk about is, you know, these, like, there's kind of like different layers in which these models, you can inject domain knowledge to like, There's this thing called retrieval augmented ⁓ generation. So you can have, you can kind of give these models a corpus of texts to kind of read and look up. There's these things, you know, and they rely on these things called embeddings, which we can talk about. And then, you know, models also have access to tools. And then another kind of big thing that a lot of the sort of agent frameworks out are like some notion of guard work rails. So like, that they have API primitives for limiting the actions an agent can take. Besides the GitHub coding agent, have you guys used an agent that you've enjoyed or have seen an agent that you've gotten a lot of Erika (11:27) No, I've heard some people talk about their agents and having multi-agent workflows, like having like a test creation agent and like a coding agent and maybe like four or five different agents running in separate terminals. So that. Jonathan Tamsut (11:27) Yeah, okay. Erika (11:48) It sounds fun. I haven't gotten to that point yet. Jonathan Tamsut (11:50) Hehe. Yeah. Yeah, is, it is, yeah, I feel like we're kind of at the beginning and there isn't, you know, yeah, right now, kind of LLM based tools are super useful, but yeah, I haven't found a ton of use outside of like coding. I think like these tools are just kind of still, kind of still. being built out. Brittany Ellich (12:15) Can we like take a use case? I have an idea for a use case. Can we just like walk through how you would take that and like build an agent? Jonathan Tamsut (12:18) Okay. Yes, yes. Yeah, let's do that. That sounds great. Brittany Ellich (12:24) Okay, so I have this idea to build an agent. want this to help me. Right now I write a newsletter where I go through and read a bunch of blog posts written by software developers and sort of categorize them around the Balanced Engineer newsletter every week. Right now I'm really dependent upon RSS feeds and just getting whatever information is pushed to me through those feeds. Jonathan Tamsut (12:48) Mm-hmm. Brittany Ellich (12:48) I would love to build an agent though that could take that list of RSS feeds and like one, go add to that list by finding more RSS feeds from other developers that are doing something similar. And two would like search the entirety of an RSS feed and find which articles are actually the most applicable to look at or most, you know. Jonathan Tamsut (12:59) you Brittany Ellich (13:10) fit those categories to look at and like what are the best ones to look at because a lot of the things that people have written like their most recent thing isn't necessarily the best thing they've written. ⁓ So I'd like to look through the body of work within somebody's blog and say like, all right, how about you read X, Y, and Z post because they seem like the best ones to look at. So how would I build that? Please tell me. Jonathan Tamsut (13:11) Hmm. Mm-hmm. Hmm. Mm-hmm. Yeah. That's... ⁓ Erika (13:33) I think the first step is like defining your categories and your metrics for success, where I'm curious how you come up with the topics that you want to fit these posts or blogs or whatever into, and then how you determine what the best fit is currently. Brittany Ellich (13:55) Yeah, so I actually have a list of different topics that have some examples that go along with them. So for example, one of them is technical excellence, which looks at things like engineering blogs or ADRs or case studies and things that are about actually building skills. And then I have another topic that would be communication and collaboration, where it's more about management and leadership and team dynamics and things like that. And so I have this list of topics already. So I feel like I have that spot taken care of. And I also have an RSS link. Jonathan Tamsut (14:27) Mm-hmm. Brittany Ellich (14:29) a list of RSS feeds that I currently look at. ⁓ I could always add to it. And shout out to anybody who writes things on the internet, please send me your RSS feed and I will include it in my list. ⁓ But it's mostly a list that I've gathered over time and I'm currently subscribed to. But with that comes this very standardized way to look through this list of blog posts through RSS, which should make this theoretically pretty easy because that's already like. Jonathan Tamsut (14:34) Mm-hmm. Hmm. Mm-hmm. Brittany Ellich (14:53) programmatically driven and there's a way that it's set up ⁓ through XML that it should be easy to look through and look through all of the content in each blog post and find which ones are the most relevant to each of those categories. Jonathan Tamsut (15:06) Yeah. You know, it's interesting. So like, right. So you have ⁓ some corpus of particles, right? You know, so you have, and then like, I think there's kind of a few problems here. What is you kind of, you kind of want to cluster articles based on these topics. And I think that's like very doable. You know, I talked about this thing called like an embedding. If you guys, so an embedding model is basically a neural network model that it, what it basically does is you can think of it plotting text in like, in some like hyperdimensional space. You you can think of like 3D space. And then, you know, so there's basically 3D space and there's a of points that correspond to like text. And you can, you know, you can embed tokens. You can also embed like full documents. And what an embedding model does is you can train it so that points that are close to one another are similar to one another. So like if you have, you know, like the word like king and queen will be similar to one another. And then there's also kind of, there's basically like vector math you can do on, so, so, know, each one of these points you can think of as like a vector from like the origin to the point. And then you can do like basic vector math. So you can take like king minus female. or minus male equals queen. So there's kind of vector math you can do for mapping concept semantics from one concept to another. And so embeddings are used for, you can create an embeddings model for a bunch of documents and then you can basically use vector distance to cluster them. But this is to say, I clustering documents on like, is doable. I do think, you mentioned you want to find the highest quality articles. That I don't know how you would do. How do you rank? it how much the article is cited by other articles? Is it its relevance to... ⁓ Brittany Ellich (17:08) I'd say probably like the relevance to the topic. I'd probably have to build up like a list of keywords or something like that. Sort of like a search engine, I suppose, to like try to rank them together to see which one would be the most accurate. But I mean, I don't care about it being like totally accurate. I just want it to help me like parse through these and be like, yeah, this one looks like it's related to that. So. Jonathan Tamsut (17:15) Mm-hmm. Yeah. Erika (17:23) And this seems like This seems like one of those self-training opportunities where you could have it iteratively improve and not necessarily like explicitly define what best is at the beginning, but give it some set of instructions and then as it gives you back input, it will learn what you consider the best. Jonathan Tamsut (17:37) Mm-hmm. Mm-hmm. Yeah. Yeah. And I don't even... ⁓ yeah, no, I was literally about to ask the same question you were about to ask, pretty. Brittany Ellich (17:52) So what tools, sorry, go ahead. Yeah, yeah, what tools exist to do this? Is there, mean, where do you even start with something like this? Jonathan Tamsut (18:02) Yeah, well I know that so there are like embeddings, document embedding APIs that you can use where you basically upload the documents and then you can assign labels to the documents and it'll essentially... create the embedding space. that's kind of like the, it's like a supervised training algorithm. So you have documents, have labels. So when you upload a new document, it'll sort of take that document and give it the kind of label and embedding space. The second thing, yeah, it's like, yeah, like determining the, yeah, I mean, so I think there are like relevance. I mean, I wonder if you could, yeah, I mean. In terms of finding the best article, maybe this is just an embeddings problem where you categorize any article. But you said you want to find the best articles, but you said most relevant. So maybe it still is an embeddings problem where you find essentially the most relevant article. Which I think I would push back on whether that's the best way to do that. That maybe will reduce the likelihood that you'll come across articles with really novel ideas. Brittany Ellich (19:01) That's a good point. Yeah, I mean, I and I don't really necessarily care that it's the best ones. I just want to make sure that like I look through this list of articles and like consider the entire body of something that somebody wrote within their blog instead of just whatever is the newest thing that comes out, ⁓ whether or not it's the best doesn't necessarily matter. But maybe just categorize it into the list of categories that I already have. Jonathan Tamsut (19:14) Yeah. Brittany Ellich (19:22) ⁓ so you're saying that I would need to go through and basically take a bunch of those things and categorize them myself and then feed it into a model to like take that data and get more things and try to categorize it the same way. Is that sort of the way that it works? Jonathan Tamsut (19:34) Yeah, mean, and caveat, don't know what I'm talking about. This is just like, if you're asking me without Googling, that would be my answer. ⁓ I would definitely, like, that seems reasonable. Yeah, like maybe some like embeddings pipeline. Brittany Ellich (19:42) Okay. Erika (19:50) It'd be interesting to see what behavior you get with maybe two or three different approaches or goals in mind. can think of, you've mentioned wanting a diverse set of opinions and viewpoints to get a holistic sense of a topic. We've talked about like best, best articles, like however you view that as like, you know, well written or readable or like interesting and, or like, I think the third thing we talked about was like most cited. Yeah, so I'd be kind of curious to see what output you get with even two different goals in mind, like comparing training goals with what comes out of it. Jonathan Tamsut (20:40) Yeah, there is this like, know, so all these models use like this concept of like RLHF, if you've heard of it, like reinforcement learning through human feedback. And it's basically right, like it's when chat GPT shows you two responses and then asks you like, which one's better, right? So the model is, you know, generating output and then you're telling it which one's better, that's kind of it's like trading loss. It knows, okay, I want to generate answers that are more similar to this. So you could do like an RLHF thing where like, I mean, this is a lot of work, where you essentially begin to rank articles that you really like, or maybe you rank all articles by how high quality they are. And maybe there is some sort of learnable... sort of implicit structure to like what makes a good article versus a bad article. the end. Yeah. But yeah, so yeah, ranking, yeah, ranking, yeah, I feel like, you ranking articles. I mean, it's funny because like, this is kind of just how Google works, Like Google, yeah, Google just like ranks articles and returns them for relevancy. And, you know, I think... Brittany Ellich (21:39) Yeah, it is. Jonathan Tamsut (21:47) There's a bunch of ways relevancy can be scored. This is kind of like the fundamental problem, like information retrieval, like giving a query and a corpus of documents, return the top K documents that are most relevant to, yeah. In which case, Google already exists. I'm not sure an agent is required. But yeah. Brittany Ellich (22:05) No, that's fair, but there's also a lot of downsides, I think, to search engine optimization because a lot of that is really built on the number of keywords that are present in an article. And just because an article is stuffed with a bunch of keywords doesn't necessarily mean it's good. ⁓ Jonathan Tamsut (22:10) Yeah. Yeah. Go tell Brittany Ellich (22:20) It's Jonathan Tamsut (22:20) them. Brittany Ellich (22:21) the same issue where, you know, if you're looking at articles that are pushed to you through something like LinkedIn or some other social platform, you're going to see whatever the most popular one is, not necessarily the one that's like the most relevant to what you're interested in. ⁓ And a lot of times those algorithms end up pushing things that are like the most, you know, the spiciest or the ones that get the most, you know. Jonathan Tamsut (22:26) Yeah. Yeah. Brittany Ellich (22:43) negative feedback or whatever. And that's also not a thing that I really care about personally. I just want to learn from other people and what their experiences are. ⁓ Jonathan Tamsut (22:50) Yeah. Erika (22:52) Yeah, it's definitely very appealing taking back the control of the algorithm. Jonathan Tamsut (22:57) Yeah. Brittany Ellich (22:58) Yeah, that's what I want. I just want my own algorithm. The algorithm. Jonathan Tamsut (23:01) Yeah, that is actually an interesting idea. I mean, Google, I think, customizes per user. I think to an extent, what would an information retrieval system that you could truly customize and really clearly define relevancy mean? Maybe that's our next startup idea. customized, know, customizable search engines. Although I think most people just want the same information. Or don't care. Yeah. Brittany Ellich (23:33) true. Jonathan Tamsut (23:34) Okay, so I don't know if we answered your question, but we did spend a couple of minutes talking about cool stuff. Brittany Ellich (23:39) Yeah, no, I think this is really interesting to think about. This is something that I haven't really spent much time thinking about, like, okay, like, what does that actually mean to build that? And it's a different set of engineering problems that I'm not super used to, but it still seems like the same fundamental building blocks of any other engineering problem. Jonathan Tamsut (23:43) Yeah. Yeah. Erika (23:57) I think you've given me you've given me an idea for an agent to and it's not fully fleshed out, but something that works with my obsidian space to like improve my second brain, like either like suggesting edits for notes based on like, yeah, like a GitHub MCP or like Jonathan Tamsut (24:06) Mmm. Erika (24:16) Yeah, a public publicly available knowledge on the internet, like, I don't know, letting me know when things are like outdated or inaccurate or something like that and suggesting updates for my notes. Could be helpful. Jonathan Tamsut (24:27) Hmm. Yeah. I, I don't know, they're pretty good. Brittany Ellich (24:28) I think there are some, oh, okay. I was gonna say, I think that there are some plugins you can use that have some LLM capabilities built in that you can like feed your entire set of notes to it. But, oh, okay, what is it? Jonathan Tamsut (24:42) I use one. Yeah. It is called, if I can't find it in the next four seconds, then I'm just gonna tell you. It's called Obsidian Copilot. Erika (24:52) Yeah, I've been wary of using any plugins because it's like proprietary data, but I do have my Obsidian in a private GitHub-owned repo, so I can play around with it there. Jonathan Tamsut (24:58) Yeah. Yeah, that's fair. Yeah, this is probably, you know, in violation of some corporate policy to use. But, Brittany Ellich (25:07) that's smart. I think some of them are built on like a local model though, too, which would be, I mean, as long as it's not sending data out to, you know, some server for another company somewhere. Jonathan Tamsut (25:25) Yeah, you could run your own llama server and use that as a backend with this, I think. Brittany Ellich (25:31) I do wonder if the, this is a little bit off that track, but I wonder if like the trend to having a bunch of digital notes or like the permanent knowledge management thing is going to disappear with like the move towards like digital minimalism and like not using as much like, know, data spaces you really, you know, need to use out there in the world. Jonathan Tamsut (25:52) Do you guys feel, do you feel pulse? Cause I don't, I don't feel. Like, is that like an environmental thing where people are like, I don't want to, cause it's like, I don't know, like a megabyte of data, a megabyte of storage is like, fit in like my pinky. I don't know. I feel like my energy consumption is probably worse than my, for the environment that my. Brittany Ellich (26:11) That's true. I just read something on Blue Sky yesterday about how some person in the UK was like, you need to go delete all your old emails to free up data center space or something because it's using too much water to cool these data centers or whatever. I'm curious if that's going to be a problem. Jonathan Tamsut (26:12) Yeah. Yeah. Mm-hmm. Yeah. Brittany Ellich (26:30) one day. It probably isn't. Like if you're going to compare what is going to make the difference, I don't think that my personal old emails are going to make a difference compared to like the massive amount of energy used for ⁓ most corporations. Jonathan Tamsut (26:36) Yeah. Yeah, but I don't know. that is that is there's like a subreddit called like do like I think it's called like they did the math or do the math and it's where people make comments like that and then someone actually does the math. I actually am curious what the math math is like everyone's emails who are older than two years. How many terabytes of storage is that and then like how you know how you know how much carbon had to be you know emitted into the atmosphere to ever ⁓ produce that. I think this is also a subject, but I feel like this is, we're having a wacky podcast episode, I like it. This is another subject change, but it's kind of related to agents. But I actually think one thing that's totally broken is looking for a job. And it's broken for a number of ways. I think the way we interview candidates is is totally dumb. ⁓ I also think that Erika (27:27) you're experiencing this because you're going through it right now. Jonathan Tamsut (27:30) Yeah, yeah, yeah, and not to yet. Yeah, but I mean, I just think, right, you know, asking like a simple algorithm challenge and then spending a few hours with a candidate, asking them standard business questions, I just feel like isn't a good predictor of whether they will be successful in that role. And I think that there's also kind of a related problem of like, I really do believe this of like a human capitalization problem. So I think there's a lot of really smart, capable people that are just not, their skills and their intellect are not being deployed on like problems that really matter. And I think like a... some type of omnipotent job, in the limit, if there existed some type of omnipotent job search engine that would match you with a job that you would A, like and be successful on, and C, would be a good use of your skills for society, would be an incredibly useful tool. It's sort of this social organization tool. And I wish it existed, and... But I don't know, what are your guys' thoughts on that? There's also some maybe downsides to having a centralized thing for that. did I just hit my copy? Brittany Ellich (28:44) I think you just invented communism. Erika (28:46) Yeah, I was gonna say I fall on the complete opposite end of your perspective where I feel like the broken part of like the broken part of hiring is not necessarily like, not necessarily like the automated part. Like it's like, it's like the people skills. Like, I feel like they're, for software engineering jobs, there's definitely like the technical aspect of like, Jonathan Tamsut (28:53) That's it. Erika (29:11) you have these skills, do you know how to do this? And like, there are ways to test for that. But I feel like the most important predictor is your like culture fit and like your personality, like, and that's 100 % not something that can be automated. Like, I think of this and like, like the answer that I would want to ask, like, the answer that I want to find as an interviewer is like, is this person resilient? Will this person grow? Jonathan Tamsut (29:23) Mm-hmm. Erika (29:39) in this role and like, you know, continue to provide value like, and like, that's not in any way something that can be. Jonathan Tamsut (29:45) Mm-hmm. Erika (29:51) answered by a machine because people change and people grow and like you're looking for those like raw human qualities and like, like I said, like the culture fit and the skills fit for the job that you're looking for right now, but you're also looking for the potential of the future. And yeah, I like, I feel like automating that to any degree is is sort of, how do I say this, like looking at the, from my perspective, like looking at the sort of like problem, like that's not the, from my perspective, it's looking at the wrong problem. Jonathan Tamsut (30:31) Yeah. Brittany Ellich (30:31) I think also that would be expecting companies to be able to accurately define what the job is and what their culture is. I don't know if you've, I'm sure you've read some job descriptions lately. A lot of them are very grandiose compared to what the actual work is. And so that also is the other side of that. think it's expecting people to know exactly what a job is is hard, actually. Jonathan Tamsut (30:35) Yeah. Yeah. Yeah. Yeah. Erika (30:47) Mm-hmm. Jonathan Tamsut (30:55) Mm-hmm. Well, I totally agree with everything you said. Employers don't know what they want. think slope matters, then why intercept, basically. do think there's also, are really biased, and there's incredible amount of bias. There's just bias in the interview process, which hurts candidates depending on what the bias is. Erika (31:17) Yeah, I actually, feel like I, I'm sorry, I'm cutting you off. But I think where you might be going is like, that's maybe the problem that we want to solve is like pointing out biased decision making. Jonathan Tamsut (31:21) Okay, go ahead. I don't think it's the problem, but it is a problem. like maybe, maybe, yeah, maybe it's not the most important problem. But it is a problem, I think, ⁓ that's frustrating to experience. Erika (31:41) Mm-hmm. Brittany Ellich (31:42) I think when I think back, sorry, when I think back to my experience too, I think that humans are also biased towards assimilating to whatever environment that they're in too. Most people I've worked with are people that I've really loved working with. I think you hear that from everybody when they leave a company, they're like, it was the people that really made this happen. maybe there's not as much risk of hiring the wrong hire as people. Jonathan Tamsut (31:51) Mm-hmm. Mm-hmm. Mm-hmm. Brittany Ellich (32:07) think there is. It seems like there's a lot of fear of saying like, what if I hire the wrong person? like, usually most people turn out fine. Jonathan Tamsut (32:09) Hmm Well, I've heard the opposite. I've heard I've literally heard people say, you know, we've hired too many B players, you know. So, you know, I think, you know, yeah, I mean, to your point, Brittany, it's like, what is what even is a good person at a company who knows there's not one definition companies don't even know what they want. What should a company even be doing if a company's mission is stupid then it doesn't matter if you hire the best people they're just gonna be working on a stupid thing. I mean there's just like infinite infinite turtles all the way down here but. Erika (32:44) That's true though. Like I do find myself reaching like even as unemployed person for like some kind of answer bank or like way to understand how leadership and like, you know, management is looking at success. Like, and like, I feel like if we're talking about, you know, agents that we would want in the world, like that is something that I would personally find helpful, something I could go to and be like, you know, this is my like, you would do like quarterly self evaluations or whatever, right? Like, you know, stick that into an agent and be like, Hey, like, is this aligning with what my company is valuing? Like, what are some of your pointers? Because so much of our feedback comes filtered. And like, Jonathan Tamsut (33:29) Mm-hmm. Yeah. Mm-hmm. Erika (33:34) I don't know, maybe there's like stuff happening behind the scenes, maybe there's stuff that like people wouldn't want to say to my face, but like, you know, is actually helpful for me and like performing well. So yeah, that could also be something helpful. Jonathan Tamsut (33:43) Yeah. So in my in my dream at well, I'll say in this app idea I had a reverence agent. I think there is a huge career basically a personal tutor for your career thing because I do think the I'm it really excites me the idea of having AI agents as personal tutors that a have like a complete understanding of the knowledge base you want to acquire have a complete understanding of your ability and can kind of like incrementally help you get to where you want to go. And I think it would be cool to have one for your career, like a little career agent that followed you around and was like, hey, John, you want to learn XYZ? Here are some exercises to learn XYZ, I don't know, here are some opportunities to learn XYZ, or John, you could be doing this better. I don't know. I think that would be kind of interesting, although maybe potentially annoying. thanks so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on your podcast to app your choice. Check us out on Blue Sky and share with your friends. Until next week, bye-bye. --- ## Episode 20: Personal Brand for Software Engineers | Career Growth Strategy - URL: https://overcommitted.dev/personal-brand-for-software-engineers-career-growth-strategy - Published: 2025-08-12 - Topics: Career Development, Developer Experience/DevRel, Imposter Syndrome & Mental Health - Audio: https://anchor.fm/s/102586d64/podcast/play/106703093/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-7-11%2F405452396-44100-2-72cefdfb5bee5.mp3 ### Show notes Summary Building a strong personal brand as a software engineer isn't vanity—it's career insurance. In this episode, we explore how programmers can develop authentic visibility and thought leadership to unlock better opportunities, negotiate from strength, and create sustainable growth beyond burnout. Learn the framework top engineers use to stand out. Links * Staff Engineer by Will Larson [https://staffeng.com/book/] * Julia Evans [https://jvns.ca/] * Cassidy Williams [https://cassidoo.co/] * Gergely Orosz [https://www.pragmaticengineer.com/] * Charity Majors [https://charity.wtf/] * ⁠⁠⁠Tech book club Repo⁠⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠⁠⁠⁠ [http://overcommitted.dev] * ⁠⁠⁠⁠⁠Bethany Janos⁠⁠⁠⁠⁠ [https://github.com/bethanyj28] * ⁠⁠⁠⁠⁠Brittany Ellich⁠⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠⁠Eggyhead [https://github.com/eggyhead] * ⁠⁠Jonathan Tamsut⁠ [https://infinitely-fallible.bearblog.dev/] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast where we talk about our commits, our personal commitments, and some stuff in between. I'm your host this week, Brittany. Join, bye. Erika (00:10) Erica? Jonathan Tamsut (00:11) Jonathan? Bethany (00:12) Don't bop any. Brittany Ellich (00:13) We are a group of software engineers who initially met working on the same team a while back, and we found a common interest in continuous learning and building cool things. We continue to meet to share our learning experiences and talk about our lives as developers. So whether you are pushing code or taking on new challenges, we are so happy that you are listening. This week, we're going to talk about building a personal brand as a software developer. And to set the stage a little bit, I thought we might talk about what is a personal brand to start with and what are the things that are usually included in that maybe that you may or may not be doing, ⁓ what comes to mind for you. And I'll pass it over to Erica first. Erika (00:56) I think of personal brand as everything that encompasses your why and your what. So I'm a pretty visual person. I think of this alongside the visual aspect of any kind of corporate brand that you might see. So like... One thing that you think of is a logo, like, you know, maybe Pepsi, right? So they have like a logo that like evokes a certain feeling. They've gone through like, you know, a huge curation process of like doing some testing of like what works, what communicates our, you know, our values. I don't necessarily think that. visual aspect is always applicable to developers and your personal brand, but I kind of use that as my my same thought process for myself of who do I want to portray myself as, who am I, what's important to me, what am I interested in. So yeah, really my driving force, my languages, my stack, how I like to treat others even, how I approach my work. Yeah, so that's how I think of a personal brand as a developer. What about you Bethany? Bethany (02:09) Yeah, I think you really hit the nail on the head, in terms of how I view personal brand as well. Basically just how do I want to be seen or when people think of me, what kinds of things do I want them to associate with me as a person? I think a lot of times people hear, developing a personal brand and they think, grindset, you know? trying to come across as somebody you're not or being inauthentic. And I don't think that's necessarily what it is. I think it's trying to distill what is important to you and what you believe and what you're interested in and value and focusing on the important aspects and what you want other people to think of when they talk about you or think about you. So I know. A lot of this can sound really big scope as well, like, you have to be super in the public eye to have a personal brand. But I don't, I think that your personal brand can come across even just when talking to coworkers or ⁓ choosing which projects you want to focus on. So I don't think it's necessarily something you have to put on blast and be like, this is my personal brand and this is who I am, but rather just a set of guidelines to guide what you. what you do and what you focus on. Jonathan Tamsut (03:28) I think it's interesting, both of you had a pretty broad definition of personal brand that almost to me seemed like identity. Like, I hate the term personal brand, not to be super negative, but like, I guess I just don't like marketing. I feel like marketing is lying. I feel like developing a personal brand, I mean, I get it. I think, you know, Like, I don't know, like, like, I guess I just don't like thinking about me in terms, like my career in terms of that way. Like, I like to think about, like, my interests building, like, just relationships with people and, and like trying to do something of value. And like, And so, I don't know, personal branding just feels like kind of barkety to me. think, and there's, you know, and we just know so many, there's, there's, you go on YouTube and just like everyone has a personal brand and are trying to sell books and courses and stuff. And a lot of it, frankly, it's just like a name. And it's like, okay, cool. Like, you know, this is your livelihood. And I get that. But like, I just, I just don't, I don't want to, that's not for me. Erika (04:27) It's a good point. Like, we're talking about what a personal brand is, but I think it's also important to talk about, like, my personal view of what it isn't. Because I think you're totally right. especially externally on, like, social media, everyone's vying for attention. And, like, I was listening to something this morning about sort of the, like, this is the first time I heard it described this way. Like, the Bethany (04:27) Thanks. Erika (04:51) influencer cadence. like if you listen to lifestyle influencer videos, they all have the same way of speaking where it's like, hey guys, blah, blah, blah, blah, blah, blah, And like they use a certain lexicon and like it's carefully crafted to keep your attention. like past the first five seconds of the video. So like, I agree with you, like that level of sort of like creation and marketing, like that's not something that I am focused on in my view of my personal brand. And my mindset shift is more like... Okay, maybe I don't like, I'm not necessarily trying to compete with other people for attention, but I do think it's valuable to share what I'm excited about with other people. And it doesn't necessarily come naturally to me. Like I am interested in this for me. I would do software engineering like by myself and like not share with anybody and probably be perfectly happy. But I do think it's a bit of like, sharing what I've learned, like sharing what I'm excited about, like believing that I do have positive contributions to bring and like trusting that other people would want to hear about that is why that brand aspect is important. And it's curated only to the point where I want to be like, thoughtful about what I put out there and what I present myself as, but not like over engineered to the point of trying to get so many clicks or, you know, trying to like necessarily, you know, get some specific outcome from it. Brittany Ellich (06:35) I, full disclosure, completely agree that I actually hate the term personal brand. I think that it was just funny because I chose the topic of this episode. Sorry y'all. But I do feel like it sort of has this negative connotation with it of like this like carefully curated online image that you're creating that... really isn't applicable to like most people in general. So I kind of like the idea of thinking of it as like, these are the things that I'm interested in and just sharing that with, you know, even if it's just at the level of your coworkers or something like that. think the thing, especially working remotely, there's... not a lot of opportunities that you have to like be visible to the other people around you. So whether or not you like put thought into the way that you respond in Slack or the things that you share or whatever, whether or not you put thought into that, there is a personal brand that's associated with it. And there's like a way that people think of you at work, regardless of whether or not you're like, I really want to project this specific image or you're just like, I really just want to talk about these video games I'm really into. So. I think it's worth taking the time to think about that image that you portray if you're interested in things like, you know, getting more opportunities or expanding your career or whatever. But I'm also not personally interested in like building a thousand billion followers on Instagram or whatever. We can probably leave those takes out of this because I don't think any of us are there. Erika (08:06) Yeah, and I think it's also like recognizing that some of that is outside of your control. So part of why influencers have to have a certain cadence or use certain tags or words or lexicon is because it drives views, which then drive promotion on the algorithm. And we can't control what the algorithm, you know, promotes or doesn't. So yeah, like I think they're kind of two separate things. Gaining a following is different from building a personal brand. Jonathan Tamsut (08:40) Yeah, and I know we kind of really picked apart or critiqued personal, but building a personal brand is like, it's a really useful thing to have, right? If you write a book, if you have courses, being able to have an audience, I think is super valuable. And I could see why you want to spend time developing and cultivating that audience. Right? Like, totally. You know, I also think we all have quote unquote personal brains, which is, you know, people's subjective experience and perceptions of us. And yeah, and like, yeah, maybe, you know, you know, I really don't like, I just want to be authentic. but like maybe, maybe I should, maybe I should be, maybe I should be, maybe I should, you know, be. you know, maybe it's, you know, especially professionally, it might be advantageous to like cultivate sort of an aura of like expertise or something around you. So like, I get it. Like, I mean, I'm not, I think there are like valid reasons to be like, this is important to me. Bethany (09:37) Yeah, I think too. I don't know if this is others' experience, but I know people will have an opinion of me whether I project something or not, or whether I want to project something or not. And I think also being a woman in STEM or tech or whatnot, I think sometimes they're not the things that I want people to think about me. So a lot of times I, again, whether the word is good or not, I want to be in control of the narrative that people like, or perception that people have of me. So that might be why I'm a little more aggressive about it in a sense. I want people to think I'm technical. I want people to know I really enjoy coding APIs and backend systems and things like that, rather than front end or project management or things like that, that people might typically pigeonhole me into. I think like for me specifically, it might even be less about like, I want to hit this market and make sure that people think this, but it's like, I have goals for my career and I don't want people to assume that I'm not interested in various opportunities because I never said that or portrayed that about myself. So I want there to be like no question about what I'm interested in for my career for people who are managing me or above me or anything like that. so I can be advocated for or helped to get there. Brittany Ellich (11:00) That is kind of an interesting thing that I feel like coming into this, Erica and Bethany and I had like this one opinion about what it is to be personal branding. And John had a different opinion that I wonder how much of that has to do with like differences and how folks like feel like they have to portray themselves at work based on, you know, whatever their identity is. We can cut that part out if we don't want to like get into that or anything. But I think it's interesting. Jonathan Tamsut (11:26) No, ⁓ no, I, yeah, no totally. I mean, don't want to be, the risk of mansplaining, but yeah, mean, yeah, no, totally. I for sure have a, you know, a different outward subjective appearance than y'all. Brittany Ellich (11:41) It makes me think about ⁓ in the Staff Engineer book by Will Larson, he talks, I think it's in that one, he talks about how there's, know, generally there's not for most people, there's not like an advantage to getting, you know, higher. career levels. Like yes, you'll make more money or whatever, but like it doesn't necessarily give you more social capital necessarily. Unless you are, you know, some sort of minority in the tech environment. If you are, you know, a woman in tech, if you are a person of color in tech, how, you know, actually being recognized as a staff engineer is important for building authority in conversations that you wouldn't have otherwise if you don't have that like evidence of a title there. Anyway, that's an aside. ⁓ Erika (12:23) No, mean, I think, yeah, I don't have too much comment on like where the, like where and why some people care about personal brand and why some people don't. But I do think that point about like its value outside of your own work being really interesting to dig into where. I think of people who I want to work with and like projects that I want to work with and usually the projects, usually they like go together. Like either the projects are interesting because they're like solving a technical, really interesting technical problem, or they have like a really interesting use case or application, or the people working on them are people that I enjoy working with. And like both of those things are brand. The people are... who they are, like they're either really smart or like, you know, really great communicators or really great problem solvers and that's all part of their brand and I'm drawn to work with them because of that. So like I think of that from the flip side, like I want that for other people too. I want people to say like, yeah, I've worked with Erica. I enjoy these things about her. Like if she's working on that, like I want to join her. So there's value in like, yeah, bringing a lot of other people alongside you and like making sure that you are that person that you would want to work with. Jonathan Tamsut (13:47) Yeah. That's how you go, Brittany. Brittany Ellich (13:48) I like. I like that a lot and I think something that I've been thinking recently is I've been paying attention to... messages from people leaving the company. It's like, you know, we just hit a vesting period or whatever. So it's normal timing. And every single person always seems to say like it was the people here that made it, you know, fun. Like, yes, I'm interested in the work. I'm interested in blah, blah, blah. But it's always the people that they're tagging and saying, like, I loved working with this person and this person made such a big impact on my life. I think even in a remote environment, you know, the people that you're working with make a huge difference. so, you know, being that person that people like working with, you're probably going to get more opportunities to do cool things. thus building that image of yourself, whether you're doing it like consciously or unconsciously is important. Jonathan Tamsut (14:36) Yeah. And to your kind of point, mean, you know, Brittany and Bethany, like I think as a guy, I, you know, I mean, I don't understand like what it's like to be like a female in a male dominated industry and just have that sort of like bias against you, you know, and I think I am curious if there's like some trend for like, for female developers to want to build personal brand more than male developers because they feel like they have to sort of compensate for biases that they're just up against. That is it. Erika (15:07) Yeah, I'm... to be fair to you though, like I'm not sure if it's so much a gender divide as like... something that at some point you realize that you need or that you want and like... You know, I don't know, maybe that hasn't happened for you and maybe it's like, yeah, it's totally fine too. Like, you know, if you don't think of it this way, but like coming from a music background too, I definitely like, I know plenty of male musicians who are very conscious about their personal brand. So like, yeah, I think that it's a matter of like whether you've decided that it's valuable for yourself or not. Brittany Ellich (15:46) Yeah, sorry to call you out, John. We did not, you're not here just to answer for all men. ⁓ Okay. Jonathan Tamsut (15:51) I didn't feel like all that at all. thought it was sort of an honest discussion about gender dynamics in the tech industry, which I think is like a really interesting topic. Because I've definitely, I mean, I've experienced, not to get aside, but I've experienced what I perceived as men discounting women's intelligence many times before. I mean, both implicitly and through like, you know, comment. I think, I think that, I don't think, you know, it's like, it's like a real thing. And, know, and humans have biases, you know, that's just even the most well-intentioned ones, most well-intentioned humans. Brittany Ellich (16:24) Yeah, so we've set the stage. I feel like we've sort of described what it is at this point. So what are the things that you do to build that brand or that credibility internally or externally? But I guess I think we've already kind of established that the average person is probably more useful internally. So maybe we should. talk about building that internal visibility and how do you make it known what you're interested in and how do you go about building a personal brand. Jonathan Tamsut (16:52) I can, yeah, I don't know if anyone else has stuff to say, but I have stuff to say. I mean, so I'll go and say stuff. So yeah, I mean, I feel like a big thing is, like now that I'm on like, you know, the interviewing is... Yeah, I guess actually this is really not interesting what I'm about to say now that I'm thinking about it more, but it's just like do stuff, which I think it's just so important to be able to point back to stuff you've done and ideally stuff you've finished or have followed through, because I think that just holds a little bit more. know, weight and stuff that's like partially completed. So I think like doing things you're interested in, you know, starting projects, finishing projects. And I think like, I think it's important for all engineers to have a body of work they can point at. And I think that's something that like, I've been thinking more about like, is my body of work? And like, what does it say about me as an engineer? Erika (17:45) Yeah, think the way that I am approaching this now that we're talking about it is maybe using the same framework that I used earlier, which I'm realizing does kind of apply for this aspect of building a brand too, is a few things. First of all, recognizing what your values are. So like you were talking about Bethany, I wanna be technical. I wanna be working in these set of languages for whatever reasons. And for myself, I always wanna be approachable and... ⁓ kind to other people that I work with. So like, those are some things that right off the bat, I think those are very true to myself. I realized that those are values that I hold. So like using like the Pepsi or the Coca-Cola commercial, you know, it's like, we have these colors, we have this product, like, you know, these are kind of our non-negotiables. So I think the approach here, like the way I think about it is similar to how companies build and develop their brands where... You have those values that you identify. like for a company it might be their color palette, their product, like a few key images. For a developer it might be, these are my languages, like this is the personality that I have, I'm maybe really kind and thoughtful, or maybe I'm like more spicy and you know controversial. Like whatever it might be that is true to you, like those are kind of your building blocks, your foundation. And then thinking like it's going to grow and develop over time as your interests develop or as you you know like you said John like as you work on things as you find things that you might gravitate towards and like it's okay to let things go too like maybe you know my color palette needs a refresh maybe I need a rebranding because I'm now like doing something completely different or I've realized that my working style is more entrepreneurial or something like that. It's okay to recognize that what you said or what you did a year ago maybe isn't serving you anymore and it's time to let it go and try something new. I definitely... I'm always trying something a little bit different in how I approach my work. Those like small experiments that we've talked about before, like, and I think that's part of that building phase. Yeah, so those are kind of my thoughts on, on, yeah, building and developing your brand. Bethany (20:22) I both of you have really awesome points, like John, with actually showing what you can do and finishing the job and things like that, and Erica with making sure you align with your values. And I think for me, do both of those very much resonate with me? And I think also I try to align with what I'm already good at. so I've always wanted, there's part of me that wants to be like a super social, like, like, present, like, comedy on tech or something, like something wild like that, but that's just not me, honestly. and so it's for, for when I go about things, I try to, I know I'm level-headed about things or I don't. panic in the case of incidents or things like that. So try to rely on that skill set and push on with that to really submit what I want people to think of me whenever I do things. Brittany Ellich (21:26) I think something that John said really resonated with me a lot, which is, you know, you need to show what you're doing. And I think that there's this assumption among a lot of people that I've worked with that just doing your job well is enough to... you know, to show like, I should be promoted. I'm doing this job really well. But there's like this whole aspect of showing your work and presenting it to the right people and saying like why it's impactful that I think a lot of people miss. And I feel like that is often like the difference between like the people who, you know. do their job well, but like might not get promoted and the people who, you know, do do their job well and then end up getting promoted. And I think it's really uncomfortable to show your work and to sit like, to show off in some like authentic way that like, look at this thing that I've done. Look at this, isn't this cool? Is this gonna help all of our customers do all of these things so much better? But it's also really important and you know, people aren't gonna, everybody's so focused on the thing that they're doing that like they're not gonna take the time to look at the thing that you're doing unless you actually put it in front of them. So making sure that you're showing your work is super important. Jonathan Tamsut (22:29) Yeah, I've always admired companies that don't do any marketing. I think like Rolex doesn't do any marketing or maybe a more spicy example is like Tesla. But it's like these are companies that at least in their eyes make such exceptional products that they don't need to market. And I think, I don't know, there's something about that that appeals to me. But I, you know, yeah, maybe that like lacks realism, because there's also like, obviously, if you want something from someone, you're gonna have to like, tell them, you know, if you want a promotion, you want a job, you're gonna have to explain to people like, this is what I've done. And this idea that like, your exceptional talent will just shine through is maybe slightly delusional. Brittany Ellich (23:11) how do you make sure you maintain your authenticity when you are sharing those things, if you have experience doing that? Jonathan Tamsut (23:18) I guess you're just, yeah, everybody can go. Erika (23:18) I like you have the most experience here, Brittany, so why don't you take this one? Brittany Ellich (23:26) yeah, I talk a lot. Online and at work. yeah, I think for me, I just kind of spit out whatever comes to my mind. I don't know that I recommend that approach, but I feel like it does maintain authenticity because most of it is like only partially filtered. which is probably why I think podcasting is so fun because it's just, you just get to talk. But I think on a more serious note, yeah, just making sure that like if you're doing something, making sure that it does align with your values. Like one thing that I feel really strongly about is, you know, like I, we've talked about multiple times. For example, I'm really passionate about building. the web in a way that is accessible to everybody. That is a really easy thing for me to get behind. Whenever I'm reviewing PRs, I'm always looking at them from the standpoint of how does this impact the accessibility of this product and how do we make it better? And I try to share content that I find interesting related to accessibility to my team. And I feel like that's sort of part of my personal brand at this point is making sure that that's a thing that I'm continuously fighting for and trying to improve. And that doesn't necessarily speak, I guess, to authenticity specifically, but I didn't even answer my own question. Erika (24:36) I think if I'm hearing what you're saying, it's like staying true to what you're interested in and and the more you engage with that then you yeah you will by nature state stay true to yourself. I'm curious like if you have kind of pushed yourself outside of your comfort zone at all and like how that plays into your ⁓ sense of authenticity with your brand. Brittany Ellich (25:04) Yeah. I don't think that sharing what you're doing comes naturally to anybody. So I think just the act of like trying to promote the thing that you're working on. Like for example, one of the things that I work on quite a bit at work is the engineering mentorship program. And it's a thing that, you know, I'm really passionate about mentoring people and teaching, you know, whatever it is that you have to teach to other people. And that means that in order to get people involved, I have to get it in front of a lot of people to get more eyes on it. because you can't really mentor anyone without mentors or mentees. They're both important to that equation. And so yeah, just trying to promote that I think is really hard. I think it's really uncomfortable to go out in front of a group of large people and say like, hey, this is a thing that... I really like and I hope you like it too and if you do come join it. Same thing with the book club I feel like we had to we have to do that a lot to promote it to try to get people to join and you know it's uncomfortable to go and put those things in front of people but if you don't then you're just doing something by yourself and That's fine, I guess, if you want to just do something by yourself, but I don't think it's necessarily going to... If your goal is to, you know, have more people involved, then that's not going to get more people involved. Nobody's just going to come find the thing that you're doing and say, hey, I want to do that thing too. If they don't see it, then they're not going to join it. Jonathan Tamsut (26:21) I like community building. think that's cool. And I think we all need a little bit more community in our lives, I feel like. Brittany Ellich (26:27) Yes, I agree with that. The whole world needs more community. I would say also... Doing stuff online is something that I've never really been super comfortable with and I decided to start doing a lot more of that because I realized if I'm applying to speak at conferences, which is a thing that I feel passionate about doing, nobody's gonna pick me to speak at conferences if they have no idea who I am and put some random person that doesn't do anything else on the internet in front of their audience. So that means putting myself out there online a lot more. And so one thing that I've done I think is finding platforms that I really align with. I know last week we talked with Nick about, you know, Blue Sky and the app protocol and like that's a thing that I can really get behind. There's no, you get to build your own algorithm around it. You're not fighting some algorithm to get visibility. It's all just people sharing other people and what they like ⁓ and I really like that. So I think finding things that fit your values there is also important externally as well as internally. Erika (27:23) Yeah, I think one thing that is tricky for me about putting myself out on the internet and why I think maybe this group and this podcast is a little easier for me than writing a blog post or something like that is that when you post something online, you get zero immediate feedback. And any human interaction, like in person or even like some kind of discussion, you do get that feedback. So, you know, it's a loop of learning what works, what doesn't. And I think that like this question of authenticity, like... What is authentic to me? I mean, it changes any given moment based on like, you know, who I'm talking to, like what I'm doing, how I think they're going to respond. So that's really hard when you're sending something into a void because like, what is authentic is like to your point, like, what do I think is interesting right now? So yeah, it's kind of a different mindset than like, Jonathan Tamsut (28:09) Thank you. Erika (28:25) talking to somebody and having an authentic, real conversation. It really is like pure self-expression at any given moment. And it's hard to really know how that's gonna play. So like I said, I think that's a tough mental block for me. I'm not great at posting things and really engaging. on a website or a blog, it's kind of always been a goal of mine that I have not really followed through on. So, yeah, but recognizing maybe if anybody else is struggling with that, you're not alone. It's hard. Jonathan Tamsut (29:03) I resonate with, you know, it's like I don't even know who I am. So it's like, how do I be authentic? How am I supposed to be authentic? I also, it's funny, I've like, I've posted and deleted multiple times like diarrhea related jokes on Blue Sky and I'm like, I don't, I don't want to be known. I don't know if I bought this out there. But yeah, no, it's, I... You know, I think Bethany is the only person on Blue Sky who likes my Blue Sky posts, and I get a little piece of dopamine hit, and I think I'm saying hilarious things. listeners, if you wanna go read my Blue Sky posts, some of them are kinda funny. Bethany (29:34) I think your blue sky posts are hilarious. I'll just like be scrolling and see it and crack up. So definitely go follow John. Brittany Ellich (29:42) That's amazing. I feel like I'm following too many people to see them. I feel like I miss them because I don't feel like I've ever seen you post on Blue Sky. And that's probably a me problem and not a you problem. So I'll go follow less people and make sure I follow you. Jonathan Tamsut (29:53) They're all, everything I post is pretty dumb. Brittany Ellich (29:55) This is great. If nobody has anything else on this weird meandering episode, maybe we should move on to our fun segment in the interest of time. But I want you to think about somebody, a software developer, hopefully, whose personal brand you most admire. And why do you think that is? What is it about them that, you know, really I'm asking what your personal opinion about their brand is. It might not actually be their brand, but who is a person that is doing some things that you really like and why do you think it is that you like that? Jonathan Tamsut (30:24) Do people need time to think? Because I got one. I really like Julia Evans and I think it's because she is just clearly like just a super nerd, is interested in stuff, wants to understand stuff, like does these things to improve her own understanding and then like you know. So I mean like that I resonate with like you know that's like I think pretty Brittany Ellich (30:24) it. Go for it. Bethany (30:48) I'm mad I didn't think of Julia Evans. That is such a good one. My thoughts went to Cassidy Williams, who actually works at GitHub now, but I've been following her since like before way before GitHub. ⁓ And I just think she's really nailed to the short form content for devs side of things. Like her, her TikToks are hilarious and just are always really funny, but also really accessible and unapproachable. And I just really love that. Erika (31:14) He's not an engineer himself, he's an engineering manager, but Gregory from the Pragmatic Engineer. I've gotten more like tangible outcomes and like things to try from his blog and his books than anyone else I can think of. And I really appreciate that because it's hard. The work we do is hard. It's great to have some tips and tricks that actually work. So I appreciate him being very practical and oriented towards really making all of the work that we do better. Brittany Ellich (31:46) love that. My pick is Charity Majors. I've been following her writing for a really, really long time, and I think that she does a really good job nailing authenticity. And she has gotten me more excited about observability than I think I ever would have been otherwise by reading about what they're doing at Honeycomb. So highly recommend reading her blog if you're interested in it. She's very, very funny. All right. That was fun. I'm gonna go tag each of those people on the internet and hopefully maybe one of them will see it. That would be neat. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends, please. As a reminder, we are still in the early phases of our Looks Good to Me book club, and there is plenty of time still to get involved. So check out the show notes for more info and join the Discord server to talk about it. Until next week, goodbye. --- ## Episode 19: Open Source Protocols: AT Proto, MCP, and Developer Productivity with Nick Gerakines - URL: https://overcommitted.dev/open-source-protocols-at-proto-mcp-and-developer-productivity-with-nick-gerakines - Published: 2025-08-05 - Topics: Technical Deep Dives, Open Source & GitHub - Audio: https://anchor.fm/s/102586d64/podcast/play/106428126/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-7-4%2F405098921-44100-2-1415d395ffec2.mp3 ### Show notes Summary As AI-driven development tools explode, decentralized protocols like AT Proto and MCP are reshaping how software engineers collaborate and maintain ownership of their work. In this episode, we talk with Nick Gerakines about how open source infrastructure fuels better engineering culture, prevents burnout through intentional tooling choices, and positions your career for the future. Discover why understanding these protocols matters for software development in the era of agentic AI. Links * ⁠⁠Connect with Nick Gerakines [https://bsky.app/profile/ngerakines.me] * Why AT Protocol blog post [https://blog.smokesignal.events/posts/3lthgglsdlc2c-why-atprotocol] * Smoke Signal Presentation at ATmosphere Conf [https://www.youtube.com/watch?v=BnOtwX5Ogmw&list=PLyIg0j_mbb2tVegEMBg5ke2Z-1ALksU-I&index=3] * ⁠⁠Tech book club Repo⁠⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠⁠Overcommitted Discord⁠⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠⁠⁠ [http://overcommitted.dev] * ⁠⁠⁠⁠Bethany Janos⁠⁠⁠⁠ [https://github.com/bethanyj28] * ⁠⁠⁠⁠Brittany Ellich⁠⁠⁠⁠ [https://brittanyellich.com] * ⁠Eggyhead [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Bethany, joined by... Erika (00:09) Erica. Brittany Ellich (00:09) and I'm Brittany. Bethany (00:11) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we're happy you're listening. I'm really excited to welcome Nick Gierakinis as our guest this week. Nick is a fellow co-pilot engineer and in his free time has been building an event platform on top of at Proto Network. And I've been following him on Blue Sky and I'm just like, this is so cool, but I don't understand half of it. So I am just really thrilled to finally get to pick your brain. Nick is just truly one of the most intelligent people I've had the honor to work with. So very, very excited. Nick, do you want to introduce yourself and give a high level introduction? Nick Gerakines (he/him) (01:01) Yeah, hey, thank you for the warm welcome. My name is Nick Jerikiannis. I am a software engineer at GitHub. I've been working all over the back end space doing online education, infrastructure, DevOps, a lot of AIML, CS stuff, and video games. Also back in the day, I was doing a lot of web 2.0 things, which is sort of my origin story about how I got to where I am. And I'm very excited about that. Bethany (01:23) Awesome. Well, let's kick it off with what exactly is at Proto. Really just curious the overview and what are the benefits? Why would somebody want to build on top of it? What makes it fun to work on now and if there's any frustrations. Nick Gerakines (he/him) (01:37) Yeah, that's a fun question. A lot of people have been asking what is Ad Protocol, AT Proto, Authenticated Transfer Protocol process. It goes by a few different names, but Ad Protocol is really a set of technologies that center around identity and data. Like a lot of, you know, just decentralized technologies these days. There are a couple of things that make it different and they're worth pointing out though. ⁓ The first is that it uses this thing called a did a decentralized identifier as the core identifier for individuals, organizations, agents, whatever else is operating in the atmosphere. A did is a string that has a structured prefix. So did colon PLC colon data, did colon web, et cetera, that describes a shape of an identifier. So like did method PLC, one of the core did methods used very heavily in the atmosphere, which also I get a kick out of that word atmosphere. Every time I use it, I sort of laugh at myself. has a data portion that is a cryptographic signature of the genesis record used to ⁓ create the identifier. Another did method officially supported in that protocol is did method web, where the data portion of the identifier contains a host name. So the goal of dids is to really create a way to look up a did document. A did document is this JSON structure that has a couple things like this is my ID, it's self-describing. Here are my cryptographic keys called verification methods. And then here are my core identity and data services. So that sort of spills into the next major component. of that protocol and that is the personal data server or PDS is there commonly referred to. A PDS is a host. So it's a web service, right? That is referenced by DIDS and allows for at protocol records to be stored in them, keyed off of the identity, a collection, and then a record key. In fact, those three components make up what is commonly referred to as an ATURI or an at URI. Things like social media posts, interactions like likes or reposts, profile information, or really anything else that's created and used in the app protocol ecosystem. It also stores blobs, so like your images, your video, your other non-record files, PDFs, attachments, etc. that are also associated with records. So The real important thing about app protocol and why these two things are so important is because together they provide for user mobility and data ownership. So when you look at where and how blue sky social, the public benefit corporation formed, it came out of Twitter pre Elon with the goal of creating a better public forum where users have lasting control over their identity and their data. So with that protocol, once you mint a did that data is yours. It's yours forever. Right. you have the keys, like the private keys, which are the counter of the public keys contained in your did document, right? And you can control where your did document points to what server is hosting your data, and you can control the signingness, the validation of the data that's stored in your PDS. Yeah, so if you don't want to host it on one... organization or business, your PDS that is, you can move it. You have the ability to change your geographic homing of data, for example, which is very appealing depending on your interests. Erika (04:58) So one question that first comes to mind. if anyone, well, so how do you access it? First of all, how do you access it and prevent other people from accessing or spoofing your identity? Nick Gerakines (he/him) (05:00) Yeah. Yeah, so everything that you do is central to these verification methods, these keys, right, that are found in your did document. So when you have a data repository, the actual internals of the PDS are such that it's a sort of... self-signed, not encrypted, but cryptographically signed data structure. And it's based around Merkle search trees, MSTs. And the idea is that all of your records, you export a repository, they contain signatures. It's actually kind of structured similar to how a Git hierarchy, like internals, you have a root commit, and then every additional change is an increment thereof. Therefore you have a chain of authenticity of this structured data. So it would be very difficult given modern equipment and practices to fake or break the cryptographic signatures that are associated with your specific records. Erika (06:08) So you technically own your data, but it would be really hard to modify it. Nick Gerakines (he/him) (06:13) Yeah, so. Any operation will it be really hard to modify it without the cryptographic keys, right? So every time you go to change or append information, you're basically saying, hey, here is an action or a transaction that is, you know, replacing or appending additional data. And here's the cryptographic key, like the content identifier, the proof that this chunk of data content change is from me, the owner of this data, and it should be stored. in a way that is alongside all of the other data that it can be verified as well. Yeah, all of this really, all of it is really important to, you know. allowing content to be trusted but verified in this broad way. The relay system, for example, when I have information on my PDS and I create a new post, it actually gets transmitted to a relay and that relay broadcasts not just the record, but also broadcasts the cryptographic signatures and verification. So any consumer can go, hey, I just saw this new record being posted by this user. And there's also a check some next to it, a signature, and knowing the verification method from their DIP document, I can verify that that content is actually from that person specifically, because no one else has access to the keys, thus it's more difficult to spoof it. Yeah. And that relay system in a very broad sense also enables the whole concept of user choice, right? So in the atmosphere, there's this concept of algorithmic choice. It's a really important like key phrase. And what it does is it's the emphasis is on user control and choice. So a user may not have the infrastructure and tooling to download every record as they're coming down the fire hose, right? With almost 40 million users, it's a lot of data, you know? However, services like Graze. social or some of the other feed generators, they have the ability to let people mix and match and create their own feeds, right? So you can view content the way that you want to, not just the way, you know, one of the existing social media providers tells you you should observe and consume like the activity and the data of your network. So that's like a really big thing. The goal of the goal really is like composability and choice labels and the moderation architecture is built with the same mindset. And, I know that there's like a lot to it. but it's been, it's been a lot of fun in some ways. ⁓ Paul, the CEO or the CTO, ⁓ made a comment, post a while ago saying something, something to the effect of every identity is effectively a host name because all users are URLs. And when you think about like where. and how people have this core identity and the ability to move it and change it, I think that makes a lot of sense. And it's very simple, but not simplistic view of the world. Erika (09:02) Yeah, well then. If I'm understanding this correctly, you correct me if I'm totally off the mark here, but I would have control over my identity because I'm the one who generates it. So if I wanted to take myself off, it's my data server, my data that I could then delete instead of expecting Facebook or whoever to respond to my delete request. And who knows if they actually fully delete me out of their database or, ⁓ yeah. keep dangling records around. Nick Gerakines (he/him) (09:30) Yeah. That's exactly right. And I have some notes for later when I talk about smoke signal, but that's really the core of this concept called the credible exit, right? With, you know, a lot of services and tooling like users and their data and their activity are as much as the product as the actual product that the users are using. Right. And, the whole concept of the credible exit is that because everything is open and users have ownership. and mobility of their identity, and then of course control and mobility of their own data, then if they're like, hey, I don't want to use the Blue Sky app view to view feeds, I want to use dear.social or some alternative, then they can do so. And because they have all of their data and the protocol is based on agreed and open standards, they can just start using the next tool, hopefully with minimal ramp up time. Brittany Ellich (10:25) So question about this, because I know very, little about this, but I use Blue Sky an awful lot. So the idea is, is if you're using something like Blue Sky, Blue Sky is built on this protocol, correct? And so if one day Blue Sky falls out of favor, I could take all of the data that I posted to Blue Sky and then move it somewhere else? that? okay, cool. Nick Gerakines (he/him) (10:26) Yeah. Mm-hmm. Yep. That's the idea. Yep. And it provides some really interesting alternatives for other scenarios. Offline and local networks, censored or censorship across regions or businesses, depending on how things go. All of those are real scenarios where if you want to be able to post freely and openly with your community, it allows you to do so. Yeah, I'm gonna put a little pin on that though. That's actually sort of an interesting segue. Bethany (11:10) Awesome. Well, let's since you mentioned it, how did you end up starting to build SmokeSignal and what has the development process been like over the past, it's been a year and it just, I saw things about it turning one recently. Awesome. Nick Gerakines (he/him) (11:26) Yeah, in fact we we just had a little one year anniversary party Partners and I and some friends. Yeah, it's been a lot of fun originally smoke signal Okay, I need to step a little back A long, long time ago, I was in the Web 2.0 scene and worked at Live Journal and then at Yahoo on social search on Delicious, right? So I was sort of steeped in the whole ⁓ Flickr upcoming Fire Eagle Delicious space, working a lot with Yahoo Answers. building some fun stuff. And I think what I really loved about Web 2.0 ⁓ is that it was like that whole movement was really brought. ⁓ It really spoke to me because it was all about social utility. The idea was that, you know, using the product itself wasn't the end game. You weren't just like dooms rolling. You were on there with the intention of extending, building, creating, and discovering connections with other people who wanted to do other things. You know, I shared my bookmarks with you because we have similar interests. I go to upcoming because I want to go to events. I go to Flickr because I want to experience the world from your perspective and so on and so forth, right? There was a lot of really engaging product that was not trying to just control like totally and completely assume consume your attention and energy. So fast forward a while. I had written a book about making Facebook applications. I had made some products and sold some things and got really excited about ⁓ Activity Pub as a spec and what was becoming the whole Fediverse. And I started building this thing called AP Events, Activity Pub Events. And the one thing that felt like a real blocker, an insurmountable challenge was... The fact that your identity within a Mastodon instance or something was pretty fixed, right? You couldn't really authenticate against it and it wasn't really meant for a broad ecosystem of connected applications. It was meant for a broad ecosystem of connected instances. And it became difficult to home your data for events outside of your Mastodon instance or whatever. The whole inbox outbox model is really, ⁓ it's, I think there's a lot to it and it has a lot of merit, but it does have some considerable limitations and it, was hung up on it. So when blue sky and that protocol came around, I was pretty intrigued and I thought that the, the, the way to represent these decentralized identifiers, it, it really, it really stuck out. It felt like a good solution to this problem. So yeah, it came out of my frustration with walled gardens and places like Facebook. Facebook events and meet up. I gave a tech talk at a conference earlier this year where I, I don't really, it wasn't really like railing on it per se, but I definitely do name names and call out the fact that like, you know, these companies are looking at people as the product and they make a lot of money on your attention. And that sucks. Communities should be able to outlive the platforms that they, that they use. And with Facebook, if you decide to stop using it, or if your community is not big enough to pay the meetup fees, the annual fees which are growing year over year, then they end up closing and that sucks. We shouldn't be limiting people and their ability to make connections because of those factors. So it sort of plays off of the whole credible exit thing. Yeah, came out of frustration. I think that's the best way to put it. A little while ago I wrote this blog article called Why At Protocol and it sort of expands on this. So yeah, the past year has been, it's been a lot of fun. And I'm pretty happy with where smoke signal is going. Bethany (14:59) Really cool. And was Smoke Signal your first kind of voyage into the at-proto space, the first thing you built on that? Nick Gerakines (he/him) (15:09) Yep. I was playing around with some code called a white wind, which is like a blogging, like long, long post form content tool. And yeah, it was one of the earlier applications, you know, that people could actually use and do stuff with outside of the core B sky.app, like app view and, and feed viewer. So it's pretty exciting there. Bethany (15:32) That's awesome. Like bleeding edge for sure. What was the learning curve like for getting on learning the app proto ecosystem and especially being one of the first apps on there? Nick Gerakines (he/him) (15:35) Yeah. Yeah, the learning curve isn't too bad. The primitives that make up the protocol ⁓ are all things that a lot of developers are familiar with. DNS, HTTP, JSON, WebSockets. There are a few more advanced concepts and features like content signing and verification, and then of course, OAuth, is ⁓ sort of core of how authentication works within the ecosystem. But... There are a lot of really good libraries and SDKs that help keep those interactions pretty high level so that people don't really have to go too far deep. Bethany (16:17) That's awesome. And since seeing everything, this ecosystem grow and I'm sure flourish since starting SmokeSignal, beyond social media, application categories are you most excited to see built on this protocol? Nick Gerakines (he/him) (16:18) Yeah. So I'm really excited about new forms of social engagement. I think that more and better tooling around groups in communities is where it's at. Because when you look at some communities, right, there's this one large community called Black Sky. And what they're doing is very open but private sort of gated community model where they have a large number of custom feeds, a large number of Custom tooling around label to help people exclude bad actors and to promote and highlight black voices and different clusters of content in those feeds and communities. I think that's really exciting. Feeds are really critical to a lot of how I think the atmosphere is going to both operate currently and succeed. Gray's Social is doing a ton of amazing work making feeds both accessible and feature rich, so like you can create really fascinating customized feeds for books or for the know the NBA draft and NBA championships they recently did and stuff like that. It's pretty cool. Yeah, I think it's also worth pointing out that the developer community has been super open and engaging. I know that there's... some views about the types of people and sort of mindsets that are more... prominent on Blue Sky. And I don't necessarily think that's a bad thing. I think that generally speaking, everyone is really welcoming and kind. There's, you your affordance of engineers of all forms and backgrounds, which does mean that there will always be friction because people have different views and ideas and desires about how to go about things. But what the developers and non-developers coming together and doing is pretty exciting. So, you know, some of the examples that come to mind are Ryan and his organization that's bridging the Fediverse and the atmosphere together with cross post viewing is pretty fascinating. Obviously Rudy and what he's doing with Black Sky and R Sky is pretty cool. And then of course, Boris and Ted in this like at protocol developer community, they've been running conferences and workshops and meetups. And it's been, it's been really, really nice to be a part of it. Erika (18:41) Well, we're going to dig into another topic that you have been working in and have some expertise in that we are going to pick your brain about, which is OAuth for MCP. So starting out with, know, why is OAuth for MCP a topic that might have its own category? What are some of the considerations for OAuth and MCP context compared with traditional web applications. Nick Gerakines (he/him) (19:11) Yeah, so OAuth is a pretty complicated spec. MCP and agentic systems also have their own vast complexity, right? So merging the two together is a really interesting. It's a really interesting process and the experience is tricky. So like when you think about what OAuth does, OAuth is a protocol that allows a user to indicate that an application can verify that they are who they are and then take some actions on their behalf, right? Literally the goal is to say that there's an authorization system like Google, right? For Google flavor to OAuth. And I as a website want to allow you, for example, to come to me where I direct you to Google, get some proof that you are who you are, that you've authenticated, and then with that proof, I can make API calls, review your calendar, display profile information, et cetera. So when you think about what OAuth does at a very high level, it's really user focused, right? It's user focused and user action focused. Users have to click things and do stuff. In the agentic world, the way that you interact with tooling is completely and totally different in every way. Right. When we talk about like LLM and AI browsers and all of these different things that people are doing to like, you know, view and roll through the web and take action. It's not you doing it. It's this entirely different thing that doesn't have the same core user experience components that you're used to doing all that stuff. So when you add on top of it, the idea that you have this separate entity that's not really a website per se, and it's not the authorization service, but it does need to access protected resources like an MCP backend to provide your calendar functionality or your smoke signal events, right? The idea is that those different interfaces have to, they have to come in alignment. So, OAuth, along with dynamic client registration and key components like PAR, pushed access requests, then DPOP, which is distributed proof of possession. All of these things allow for clients to assert themselves as the client that they say they are and provide the prompted interface to allow users to get the credentials and the proof that they need to give to those agents to then make those directed calls. It's a lot of moving parts and a whole lot of places where something can fail and then you've got to bubble up errors, which is also a really tricky spot. Erika (21:43) Cool, thank you for that overview. What are you thinking the sort of like growth or evolution areas are for MCP authentication as the agent ecosystem matures and other technologies advance in this space? Nick Gerakines (he/him) (22:01) Yeah. ⁓ I think that there are some really interesting things that need to be sorted out and I'm excited for the amount of energy and attention that they're getting. Kind of like how, you know, the rapid advancements in solar farms led to enhanced battery, you know, production and discovery. I'm really hoping that AI and LLMs help improve the way that we handle authentication and proofs like this. So like the problems that immediately come to mind when I think of this include, you know, Do I have to refresh my access token every 30 minutes? What happens if I'm automatically logged out? Do agents get proactive pushes or can they perform or do they have to perform checks or heartbeats to see if credentials are still good and then When you talk about really enhancing the capabilities of an agent, you're probably talking more than one set of MCPs for it to interact with, you know, on working with GitHub and Co-Pilot, right? There could be the GitHub MCP that provides repository and some amount of profile or organizational data. You could have an MCP agent that generates commit messages for fun, right? Or another one that is used to generate test data for or the specific types of data that you're working with that's specific to your application, another for infrastructure and staging that of course does not delete your production database. And then, yeah, so it's a lot of different tools. So does that mean that as a user, I need to go to each and every one of them and authenticate and perform those processes? Can we simplify it with some sort of trusted or credentialed token exchange system? If my attributes are similar similar enough for me to say, or the types of data that they're interacting with are similar enough to say there's one signed token that could be shared or used with different audiences in the issuer audience OAuth attribute system or with similar claims to be able to go, hey, I can read calendars for this user regardless of what system this token is being used on and then have the backend tooling with distributed proof of possession perform some sort of additional check or token exchange to get that? don't know. So I hope that those are some of the things that we can sort through because what I absolutely don't want to do is put in half a dozen MCPs that I'm actively working with throughout the day and then have to re-sign in through everything every 45 minutes to two hours. That would just be a bad user experience. Erika (24:22) This is more of a user experience and less of like a deep technical perspective, but I think I would really like to have like before an MCP executes a plan, like a verification of that plan. Like, cause I think the other thing that like kind of freaks me out about like MCP servers active on my behalf is like, if I give them access to a bunch of things and maybe one of those has like, you know, some kind of paywall or like Nick Gerakines (he/him) (24:26) Yeah. Erika (24:48) some kind of like pay like paid access tier and like oopsie I go over that limit like you know or I think it's some of the it's like some of the github Bethany (24:56) Or a way to drop a database. Erika (25:00) things that we see where somebody is like creating like 500 repos at once or something. And I'm like, I kind of think that's a mistake. Like I don't actually know if they're intending to do that, but like they might've accidentally given a bot, you know, an extra zero or something like that, you know? So like, yeah, that for, for my two sons, I would love to be like, yep, yep, yep. Looks good. Like it's going to cost me this much if there's any sort of like pay implications or whatever. Yeah, kind of similar. Yeah. Nick Gerakines (he/him) (25:27) Absolutely. I think there's also a really interesting sort of separate but related, this is more agent than MCP, but how can... either with MCP tooling or with agent tooling or some sort of structured process around them. When you have, you know, a fan out of agents performing tasks, right? How can you provide a stream of context? Like what is your inter agent bus per se look like for cached information or referential information or just contextual feedback, right? So if you are building a web app and you have one system working on the react component it and then one system working on the backend and another spinning up a staging environment or performing some sort of like proactive testing. You know, if you give prompts to two different agents that are working in different languages with different goals, right? Or perhaps even the same goal, but different prompts specific to the model that's best for it and the immediate objective with that language, you could end up with a backend and a front end that has gone off quite a bit, right? Quite a bit of divergence. But if you had a mechanism to allow them to share information. So the back end said, hey, I'm starting to look at this data model. And the front end says, good, I see that you're working with this data model. I'm gonna start crafting the client interactions with it accordingly. I think that would be a really interesting problem to solve. And the way that agents provide both file access and prompt access, I'm sorry, the way that MCPs support file access and prompt access, there could be a solution there that helps. you Erika (27:02) Absolutely. Brittany Ellich (27:02) very cool. ⁓ Yeah, so I'm curious, it sounds like your experience has really been around for a while working in the Web 2.0 space and now in the app proto space. You've been working on this sort of like bleeding edge of where technology is going for a long time. So you've been doing this for a while. What's your approach to building and, you know, finding community within those spaces? Nick Gerakines (he/him) (27:03) Yeah. You Yeah, you know, when I was younger, the advice was like, just be yourself. And everyone's like, no, no one's going to like that. But that's really the truth. You just be yourself openly and publicly. And it's, thank God it's a big web. There's a lot of people that are probably like you. And I'd take a certain comfort in knowing that a lot of my problems are not unique and other people have both dealt with them and gotten through them. telling people what I'm working on and being humble or. trying to come off as humble as best you can in 300 characters or less. Yeah, that has been a big part of it. Openly attending groups and giving people space to talk about what they're working on and listening has been a big part of it. then, you know, just using feed readers aggressively over 15 years to see what's going on in Hacker News and other places to, ⁓ you know. pay attention to discovery. That's been a big part of it as well. I also attribute a lot of interesting technical discovery to the art scene. Artists do wild and weird things and you got to pay attention to the weirdos, don't disrespect, to see what they're coming up with to, you know, go, hey, what was their inspiration for this non implemented but like interactive system or component? What are they, what's the vision that they're trying to represent here? And then to go, what if we, what if we did this and started working toward it. think that there are, I think there's a lot of usefulness and diversity of thought and pure creatives or mostly creatives take us there. Brittany Ellich (28:53) That's cool. I feel like a lot of the advice that I see online is like, find your niche and just stay there. But there's just like so many things out there that the average person finds incredibly interesting. finding community in these different pockets is a nice thought. Nick Gerakines (he/him) (29:06) I mean, I've conflicted opinions about that. think finding your niche is like super important because when you, it takes time and resources, right? Resource and the time being the resource most of the time to get good at something. I don't necessarily believe in the whole like 5,000 hours or 10,000 hours thing. But. You know, just like with spring dance, swing dancing in order to get better, you have to do it and you have to be comfortable being bad at it at first, you know, that said diversity of thought makes a huge difference. am a vastly better engineer than I was before. well, a with therapy, but B with functional programming and the two are not related in any way. fact, one has probably led to the other, functional programming, doing a lot in Erlang has been instrumental because like really getting into the actor model and understanding the Erlang virtual machine and getting into the nitty gritty changed how I thought about procedural and object oriented programming and like really, really big ways. And I don't do a lot of Erlang nowadays. Like it was just sort of a stint, right? But much like when you're a swing dancer, the recommendation is you dance with a lot of different people, go to different dance styles, you experience them, and then you use information to inform what you're doing in other places, think programming is the same way. Brittany Ellich (30:21) I love that. What advice would you give to developers who want to get involved with open source or want to start building on some of these emerging technologies like at Proto? Where do they start and how do they get into it? Nick Gerakines (he/him) (30:33) Yeah, that's a great question. I'm the type of person that learns by doing. So I think example applications or example projects or the example directories in libraries and toolkits are a great place. there are a lot of really good data explorers and because really like one of the, one of the characteristics of well-designed applications is a solid domain of data, playing with data models and exploring what is stored and how, and then reading up on the decisions or trying to get the context of, why, why did they store this as an integer for timestamp instead of this other thing? Or why are they indexing things this way in this backend? or what the hell's going on with this, if it makes no sense at all. And then getting stumped into asking questions and getting that context, super helpful. I also think that onboarding people to open source projects through tests are really helpful because if you can spend some time getting someone to understand why it behaves the way that it is, you can get them to think about what they would do different, especially if they're fresh. So you could start with saying, Hey, this is a low coverage area. Let's write some tests. I'll pair with you, you know, this evening with a beer or something. And they go, well, why are we testing it this way? Or even better, like why? like the tests and the functionality doesn't seem right. What if we did this other thing instead? That's a great opener, right? In conversation and in development to reevaluate what you're doing and see if you can learn from new people. So yeah, be confident and humble, go through example projects, openly ask questions when you don't know what's going on. And then of course, don't be afraid to... you know, look like an idiot, right? Because you're not going to be aware of all of the places that documentation exists and other people have thought about stuff so much that it feels like common sense to them, but not new people. you know, be humble and be proactive. Bethany (32:24) definitely makes sense. I think that's good advice in open source and in life. ⁓ I also love the idea that either Erlang drove you to therapy or therapy drove you to Erlang. I don't know which was which, that was my experience using Erlang for Advent of Code for sure. Nick Gerakines (he/him) (32:30) Yeah. When I was working at Yahoo, I left Yahoo to go work at EA on some game services that were Erlang based and the going away gift from... going to Wege for my team was this wonderful mug that says Erlang is my life and then underneath that it says I don't have a lot going on but thanks y'all. Bethany (33:02) That's amazing. that's great. That's great. Alrighty. So that was a really fun conversation. I feel like I've learned so much in this, what, 40 minutes? I have so many things and so many more questions to look up after this, but we've got to go to our fun segment. So... Nick Gerakines (he/him) (33:02) It was very applicable at the time. Bethany (33:23) I was surprised when I discovered Nick made a site called whatthecommit.com, like a utility for generating commit messages. And I was like, this is genius. So normally, you write the code and then you write the commit, right? So I forget, I figured that we would play a game of commit charades and rather than that, we'll see the commit and then try to imagine what kind of code it goes with. So I'll start just to give an example, but I, the one that came up was last time I said it works, I was kidding. Try this. And to me this evokes when your tests pass locally but they're not passing in CI or there's something nuanced about CI that keeps breaking and you have to like push and push and push code to like actually fix it. So that's kind of what that's evoking to me. So I'm not sure if you all want to generate your own commits or I can generate them and say what you get but. Erika (34:23) I think I need a new one because the first one that popped up for me is to colon write meaningful commit message. Nick Gerakines (he/him) (34:29) You Erika (34:31) Let's see, the next one I get is, it compiles, ship it. Nick Gerakines (he/him) (34:31) Perfect. I just pulled, Erika (34:38) So to me this evokes a typo or a YAML formatting error and you've been banging your head against a wall for two hours on why this thing isn't compiling and none of the error message is helpful and you realize it's a period or a whitespace character that you didn't see. Nick Gerakines (he/him) (34:57) I love the visual here, right? I love the just sobering acknowledgement of everyone just nodding their heads going, yeah, yeah, we've been there. That's, it's very revealing. Let's see, I just got copy and paste to fix previous copy and paste. That is a, no, I can't read that one. Erika (35:03) Yeah. ⁓ Nick Gerakines (he/him) (35:14) So the fun thing about this project is it started, I speaking at OSCON like 10 years ago or something like that. And I was, no, no, I got to be 15. It was back when I was working at Blizzard. Anyway, was a long time ago. And I was making fun of the random commit messages that were in our code base from trying to ship some stuff for Diablo. And ⁓ all of y'all's names are actually in it. So if you look at the source code for it, it's just a big dumb Python file. stuff's there. this is probably, it was a lot of fun to write because there are so many contributions. So for example, this one is a revert, quote, just testing remember to revert, Bethany (35:44) you Nick Gerakines (he/him) (35:55) is the oops I accidentally shipped something to prod with debug code in it and we've got to get that out as quickly as possible hopefully your deploy process is quick and this is a super appropriate one thank God for copilot which is more recent and also thank God for copilot Brittany Ellich (36:13) That's amazing. I got debug line test, which ⁓ it speaks to me because this seems like something that I would do where I would be like committing something to debug it in CI because it's faster than running it on my local machine. That's what a lot of my commit messages look like. Nick Gerakines (he/him) (36:17) you Yeah, shout out to all of the print line debuggers out there. I am one of you. We are us. Bethany (36:38) yes, definitely, All right, well, I guess we will go ahead and wrap up. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. As a reminder, we are still in the early phases of our Looks Good to Me book club. and there is still plenty of time to get involved. It's mostly async, so feel free to contribute. Check out the show notes for more info and until next week, goodbye. --- ## Episode 18: Tech Internships & Mentorship | Career Growth Strategies for Emerging Engineers - URL: https://overcommitted.dev/tech-internships-mentorship-career-growth-strategies-for-emerging-engineers - Published: 2025-07-29 - Topics: Career Development, Leadership & Management, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/106087862/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-6-28%2F404663371-44100-2-cea77884d315c.mp3 ### Show notes Summary Mentorship can make or break your tech career—but how do you actually build it as an intern? In this episode, hosts Alec Breton, Cole Hartman, and Doris Wang explore the real mechanics of mentorship in tech internships: finding the right mentor, navigating career growth conversations, and using relationships to prevent burnout. Learn the programming best practices that matter less than the human connections that actually shape your software engineering path. Links * ⁠Connect with Alec Breton [https://www.linkedin.com/in/alec-breton/] * Connect with [https://www.linkedin.com/in/coleahartman/]Cole Hartman * Connect with Doris Wang [https://www.linkedin.com/in/bdwang/] * ⁠Tech book club Repo⁠⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠⁠Overcommitted Discord⁠⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠⁠ [http://overcommitted.dev] * ⁠⁠⁠Bethany Janos⁠⁠⁠ [https://github.com/bethanyj28] * ⁠⁠⁠Brittany Ellich⁠⁠⁠ [https://brittanyellich.com] * Eggyhead [https://github.com/eggyhead] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host today, Erica. Joined by... Bethany (00:09) Hey, I'm Bethany. Brittany Ellich (00:10) and I'm Brittany Ellich Erika (00:11) you We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we are happy you're listening. This week, we are diving into the crucial topic of mentorship, specifically within the context of a GitHub subber internship. We'll explore what defines a successful internship from ever perspective as well as the technical aspects of mentorship and the vital role of psychological safety and building trust in a mentor-mentee relationship. Plus, we'll share some unconventional advice for aspiring interns and mentors. We are thrilled to welcome our special guests who have had real life experience in this area and have generously agreed to share it with us. Welcome to Alec, Doris and Cole. Would you like to introduce yourselves? Alec (01:10) Sure, I can start. I'm Alec. I'm a senior software engineer on the app team here at GitHub. And yeah. Doris Wang (01:17) Hi everyone, I'm Doris. I'm a student at Carnegie Mellon going into my senior year studying CS and I'm a summer intern on the apps team. Cole (01:27) Hi everybody, I'm Cole. I'm a rising senior at Cal State Long Beach studying CS and I'm also a GitHub summer intern on the App Steam. Erika (01:35) So welcome to the podcast. So glad you're here. So let's start with the definition of success. What, from each of your perspectives, defines a successful internship? Not only from your perspective, but how you see your stakeholders also view it. Doris Wang (01:54) So I think like, from my perspective, a successful internship is something, is an experience where I've like learned a lot and also feel like I've contributed a lot to like the team itself. Not that I've just like worked on a project, but that my project has impact like on the team and just like on the product for the company. So yeah, just like. having a lot of impact and getting a lot out of my experience. Cole (02:25) Yeah, I can add onto that a little bit. I definitely like that point having tangible value definitely feels more impactful through your work. And I think looking from the team, what success looks like for interns is where everybody succeeds and everybody's able to collaborate in a work environment where we feel comfortable to grow as engineers and also ask questions without the fear of failure or criticism. I think everybody just wants the interns to feel successful at the end. And for us, that definitely looks like having a lot of tangible value, getting a lot of good feedback and bad feedback so we can improve our product. And for me personally, I think that finishing all my work is also a big contribution to my satisfaction at the end. Bethany (03:11) I'm curious, how do you, through your internship, how are you measuring this impact? Is it something you're tracking through how many issues you do or how much progress you make towards a bigger project? What are you doing to kind of measure that? Cole (03:28) Yeah, that's something we're actively looking into. One part of it is we can actually see metrics on how many personal access tokens are being created. So if that number goes up, that's generally a good thing. We also staff chipped our feature recently. So we're able to get a lot of feedback from people in our QA and improvements. And we also have our PM who's reaching out to other areas and asking for feedback on this feature that we're working on. we can kind of just congregate all of that and get a good estimate of how much impact we're having. Doris Wang (03:58) Another big part of that is like mindset. feel like knowing like when to ask questions and like feeling comfortable asking questions is like an area of growth that like measures. Success, I guess, and then like just like learning how to be a good developer. I feel like I'm much more comfortable like going into the code base and like making changes by myself and I see that as like a huge success. And just like learning the developer cycle like as someone early in career is like. I think the biggest success for sure. Bethany (04:27) That's awesome to understand it from both the personal side and the also like external side of ⁓ what value are you providing, but not only that, what value you're getting. I realized too before maybe we go on, should we talk about how this internship is structured? Just to clarify to listeners what you're doing for the summer. And just to clarify to listeners how the internship is structured and what interns are expected for the summer and what they're expected to gain, it sounds like you all are doing a single project and then trying to ship an actual feature, but we'd love to maybe give folks some more knowledge around that. Alec (05:04) Sure, yeah. So from the company perspective, I think the main goal of the internship is to give hands-on experience to engineering interns, like getting their hands dirty and making sure they're learning, making an impact. From the apps team perspective, we were specifically working on a page within settings, kind of revamping that. It's been in much need of an uplift recently. I think Colin Doris, added some really good points just now and it's been a great summer. Something that I think is interesting though, from my perspective, just to answer the question of like what makes it a successful internship is from my perspective personally, not necessarily that the project gets done. I think that's the ultimate goal is like we're able to deliver something and say, hey, we got this done. But I would say What makes it most successful is making sure that the interns feel like they're integrated into the team, that they've learned and they've been able to push code. Like that's it from the engineering perspective. I think that's the most important part because sometimes projects don't get done on time. Like that's the real world. Sometimes deadlines get pushed out, but it doesn't mean it wasn't successful. So that's like an interesting thing that. It's potentially debatable. I I don't make the rules. Like maybe there's someone making rules above me saying, no, that is a failure. But if I was the CEO, I would say it's still a successful internship, like regardless of actually rolling something out, like right then and there. But yeah, sorry, that was a long answer, but I just wanted to answer that as well. Brittany Ellich (06:38) Yeah, that sounds great. Can we talk a little bit about mentoring as part of an internship and specifically the hands-on mentoring with relatively new developers and what that looks like in the intern program? Are you doing a lot of pairing? Are you helping people get up to speed? What does that sort of look like? Alec (06:58) Yeah, that's a good question. Because I would say it really depends on the project. And then also, I think the dynamic really changes between who the engineers are. In my career, I have a lot of experience with pair programming. And what I noticed was every single pair had their own dynamic, which was like really a nice thing because you know that if you change your pair, like different days, you're going to have a different experience. And I think that's kind of the beauty of the internship as well. Like each intern, Colin Doris and myself, I think we bring different things to the table. And I think that's important to remember in the mentorship process. It's like we all have our own personalities and ways of doing things. And I think that also creates a successful mentor relationship is like understanding our different strong suits and weaknesses and like how we like to get things done. So that's like really important first things first. And then also just really listening to like. If there's an issue in the code, listening to the interns, ⁓ we have a quick sync every day this summer, which I actually think was a great addition because it gave us a chance to not only talk about the code and fix problems on a daily basis, but we also got to know each other on a more personal level, which I think really helped the progress of the project even. ⁓ Like it wasn't just business all the time. I think like having that friendly nature about us kind of helped things. But I'll let Doris and Gold talk more about that. But that's just my perspective on the summer so far. Cole (08:34) yeah, I guess adding on to kind of how Alec has been mentoring us, think definitely his mentorship as a big contribution to our success. And I think one of the things that he did a very good job of was introducing us to the code base at the beginning. Cause I think that's one of the most daunting things initially is figuring out what to do and where to go. and how things work. So he did a very good job at helping us through that and guiding us. But I'd also like to say that it's kind of a two-way relationship because being a good mentee is also important, knowing when to ask questions and kind of what questions to ask, and also being willing to be in a learning mindset and... For example, you know, show up to these weekly syncs and communicate our project and our progress to ALEC is very important and definitely contributes to the success of the mentorship relationship. Erika (09:27) Am I right in understanding to you that it was a completely new stock for both of you? You were working in React and Rails and those were both new? Doris Wang (09:38) Yeah, just. Erika (09:38) There's all. Alec (09:38) Not just that, was amazed. Correct me if I'm wrong, but it felt like neither of you had touched a line of web design code before, but coming to, at least from a React perspective, for coming to GitHub. I think you might have had some experience, but never pushing professionally to a code base, which is amazing. But yeah. Erika (09:58) Yeah, that's a lot to learn in a short amount of time between the technical onboarding and all the process. Yeah, so definitely kudos to getting up to speed on all that. Cole (10:11) I'd say if anyone's curious what the hardest thing to learn was, I'd definitely say Rails. Rails was very hard for me to learn. took a long time. Brittany Ellich (10:19) I agree. Valid. Bethany (10:20) I feel like I'm still learning Rails. So kudos to you for picking up that. Absolutely. Brittany Ellich (10:22) Yeah. Nice word. Cole (10:24) You never stop. Yeah, you never stop learning. ⁓ Brittany Ellich (10:28) What's helpful to... sorry, go ahead. Erika (10:28) Yeah, I was going to say, I laugh because the whole point of Rails is to give you of sane defaults. literally none of them made sense to me until I looked at the source code, which completely takes the point away of having sane defaults if you're like, no, but this doesn't make sense unless I actually know what it's doing behind the scenes. Stop is how I feel. Brittany Ellich (10:56) I'm curious though for both Doris and Cole, what has been the most helpful thing for you learning this and getting up to speed and pushing code all within this short amount of time? What has been the most helpful thing from your mentor as you're doing that? Doris Wang (11:09) ⁓ I think really helping us understand context and especially towards the beginning when we were fresh to the code base, helping us get up to speed and really giving us that context and his experience working with the code base, I think that helped kind of pave the way for us being comfortable to break off on our own and like... you know, not depending on Alec all the time, like, with making changes. So, I think that's a big thing. I also think that, like, Alec is just, like, kind of always there for us, like, if we need any help. Now that we're more comfortable, a lot of times, like, during our daily syncs, it's more like advice on how do we, like, we have our own idea of how to implement this, or we have some solution, like, what's Alec's advice on like our idea. So I think it's like really transformed into like Now he's like kind of more on the side like assisting us and like in the beginning him like really guiding us. That was super, super helpful. And then like knowing when to be a little bit more hands off and like letting us like kind of take ownership and responsibility. But then also like providing feedback and advice. Like that is, that has been like really instrumental to our success and like just how we feel about this whole internship. Cole (12:30) Yeah, I definitely agree. think I really liked the transition of us kind of becoming more independent in our work and venturing off on our own. that was a really, I think we handled that really well as a team and we kind of very slowly and gradually entered that stage. But also another thing that know, Al kind of did besides helping us understand the code base was helping us understand what even FGPADs are and how organizations and enterprises interact and work together. Because I think it's very good to understand the product before you even look at the code base. So that's a very important and I feel like often overlooked aspect of it. Erika (13:05) Well... Something you were talking about earlier, Alec, made me like brought to mind some pairing sessions where, you know, like I've had experiences that have been really positive and then I've had some that I found mildly traumatizing. And this segues us into the topic of psychological safety and sort of highlighting that it definitely does not come for free. It's not a given. in all development environments. So what were some of the ways that you all established? Maybe I'll start with you, Alec, like how you promoted psychological safety within like your relationship with Doris and Cole. Yeah, how you set the standard and then sort of maintained that throughout the summer. Alec (13:52) Yeah, that's a good question. Because I think psychological safety is very important. And it's funny, you don't realize how important it is until you don't have it. And I've definitely had environments like that where I didn't feel the safety as much. It makes you like really want it. So. I think number one for me, having had that experience, I try to foster those types of environments in some ways in which I try to do that. And I want Doris and Cole to keep me honest here too, because like, if I didn't do it, like I want them to vouch for me on this, because I don't want to just say, I did all these things, ⁓ because they're really the testament to. how well I did as a mentor. I can't just say, I did a great job. But I think first and foremost, I like to make sure we're in a good spot. Like if we get to the end of our materials, for instance, during our daily quick sinks, and maybe, you know, we have some time left over, I'll just kind of ask like, how are we feeling or Honestly, like right away too. I'll just start with the question like, how's it going? I think we've gotten to a point now where I'm like, the time is yours. Like, let me know. Like how you're feeling. I think it's also a gradual process too, to like provide psychological safe safety because there is also an element of like the interns feeling okay to share things. like you can tell them it's okay, but. ⁓ it's really how the situation develops when they need to share something, and how you react to it. So, I would say I tried to like foster an environment where it was okay to like share your thoughts, but, I will let them say otherwise if that's not true, but yeah. Cole (15:38) Yeah, that's definitely true. And I definitely want to point out the fact that you always ask us how we're feeling, not just on the project, but in general. And if we wanted to further talk about it, would spend the entire sync just talking about that. So we felt very cared for. And I think this definitely boils down to kind of relationships. those can look very different in a workplace environment depending on the types of people, the job, the team. So in our situation, I think me and Doris definitely formed like some sort of a friendship with Alec, which made everything very easy and smooth. But, you know, that's just for our situation that might not be the most comfortable for other teams in other situations. So it's definitely just about the dynamic. and how you choose to form it over time. But I think what's most important is being conscious and advocating for that most comfortable environment for everybody. Doris Wang (16:28) Yeah, I definitely agree. And I want to add on, like, I think Alec did a really good job, like, in the first, like, week or two of our internship, like, kind of breaking the ice. And, like, I think it's, like, a little bit difficult for, and I to, like, just start sharing our personal lives. But I think, like, Alec, like, kind of started sharing, like, what his life is like. And then that, like, just made everything, like, very human, I guess. It wasn't just, a professional relationship. And I think that helped build trust. a lot and like as Cole said, like we almost have like a little bit like of a friend dynamic as well, like when we do our sinks. And I think another like another like building trust area that Alec did really well was like being really open to feedback. think like. He kind of challenges us to challenge his ideas sometimes, and I feel unafraid to give feedback on his ideas. I think that back and forth, he's really fostered that environment to be able to have us be comfortable with that back and forth. And I think that also contributes a lot to our learning. So shout out to Alec. You've been a great mentor. Bethany (17:38) That is awesome. I think it's so important in psychology, like to implement psychological safety and just for the success of the team to make sure that everybody, their voices are heard and their opinions matter. So that's awesome that you all had figured out how to really give that feedback and bounce things off each other. That's awesome. So in our podcast, we talk a lot about AI. It's a very much hot topic. So I am really curious just hearing from the perspective of Cole and Doris, people who are very early in career, like... like continuing to learn, how do you balance using AI to go faster or learn more versus actually ingesting that knowledge? What are your strategies for that and how do you balance that? Cole (18:23) I could go first. Yeah, great question. I guess my approach to utilizing AI when I'm coding is using it as a tool to understand the code and what it's doing already because the main job of a software developer that you realize once you become an intern or full time at a bigger company is that most of your job is to just understand what's already happening and to kind of reuse or change that logic there or somewhere else. So. There's a lot of context that AI can help you understand. And I think it's also just good for redundant things. I don't know, rewriting a block of code or just redundant things in the code that you need to do. That can definitely help you with that. But obviously it can be a crutch if you use it to the extent where you tell it to do the work for you. And then you don't take the extra step to understand what it did. And I mean, the age-old story is that it just keeps writing worse and worse code and you get farther and farther away from the solution and you have to spend more time debugging it than you would have if you sell it on your own. So it's all about the balance, really. Doris Wang (19:22) Yeah, I totally agree with what Colt said. I think I use it a lot in understanding context just because we are so new to web dev and also just this new code base. And also because especially this is my first experience with web dev, I don't know the syntax of a lot of stuff. I don't really know the structure of some of these things. But I know the solution in my mind. I just don't know how to implement like in the language or like in this like framework. So I will use like AI a lot of times to like help me write stuff like in the way that I want it to I guess because I just like am not fluent in like Ruby or like JavaScript. So I think that's been really helpful like yeah. So like balancing kind of like critical thinking and problem solving like. by myself and then using AI as a tool to help me express my solutions and actually code it up. I think having it to understand context, using Co-Pilot to really understand context has been a huge time saver. also from ⁓ Alex's side, we need to reach out to him less to like... understand the code base which I think is like also really good but yeah definitely knowing like how much to rely on AI and like making sure that you're not like super reliant and making sure that you know how to like go back and like look at the response and like know what's wrong with it if anything is super important so definitely like yeah as Cole said finding that balance is really important. Bethany (20:58) That's awesome. That makes a lot of sense. I remember as an intern, I was, it was a little jarring going to a private space where in classes you could Google most anything because most things were very transitive and available on the public internet. And then going into a private business, you're like, I can't Google what is this thing because no one will know. So AI is almost like a search engine for your own code, which is awesome. That's really cool. and I love that you all are really thinking about how to balance it helping you but not doing the work for you or taking away those opportunities for you to learn. That's really cool. All right. yeah. Cole (21:39) Yeah. Oh, sorry. If you don't mind me bringing it up, I've never asked Alec how he uses AI because, you know, me and Doris are the new generation of programmers. So I feel like we're both kind of on the same page about how to use Copilot and AI and whatnot. So I'm actually very in the dark about how Alec uses it. So I'm very curious. Alec (21:56) put me on the spot? No, I actually, that's a good question because I was just thinking about what my internship was like a long time ago, like, and how it would have changed what I was doing. And I think it's not, it's not too far off from even when I was an intern because the way in which I develop is still like, diving into code, seeing how it works, learning from it. And it's the same way now than when I started my career. I think it's just I've built certain skill sets that allow me to do things quicker. So I think I use AI very similarly in that. I use it when I'm not sure about something. And that's always going to happen in your career. Like no matter what, you're not going to know everything. It's just maybe there are less moments that I need to use it. So I might use it in the same ways that both of you do just less often. So yeah, I think an amazing part of AI lately, and I could talk about this for an hour, but like Just the way in which AI has caused me not to worry about some code is crazy. Like unit testing is like used to be this whole thing. It used to take me like a day to like write tests for a component, but now you can write tests in like a half an hour and it's crazy. or like I'd be blocked on something for a day. And I have not felt that way since AI like has been really used. I haven't been that blocked since before AI and I think that's crazy. So yeah, I don't know if anyone else feels similarly about AI, but that's been pretty crazy with my experience. Bethany (23:39) Absolutely. I agree. I think it's like chatting with somebody who has... and the knowledge of your specific case and you're able to kind of brainstorm more easily with even if it's like rubber ducking but with kind of an automated interface rather than a person for better or for worse. But it's been very helpful for saying, okay, well, this is how I'm thinking about this but are there other ways to implement it? Is there other things I can do like would this have performance implications? Am I missing something about this code? really cool. Awesome. Erika (24:09) Yeah, I think it's cool that we're talking about this after we talk about some of the team building dynamics and interpersonal relationships too, because I think that's something that's not mentioned in the topic of AI usage, but is something that could also potentially be lost is those discussions of brainstorming and really connecting with people. people kind of talk about like, I have me and my AI and that's all I need. You know, it's like, well, no, if you're working on a team, you do need those other people on your team. Like you do need to still build those relationships. yeah, without. even mentioning it in what you said, like you've clearly also struck a balance between, like using the AI to like help rubber duck or solve problems and also still like, it sounds like you've found some kind of line of like, okay, but now I'm going to still like go to the team or go to, you know, Alec with these questions that like AI can't answer. And that's an opportunity to build relationships and opportunity to, build knowledge. Bethany (25:12) That is such a great point. Asking questions is a huge skill, and I'm sure AI makes it easy to ask the questions to the AI, but you still need to develop that experience with asking questions to people. That's an awesome point, Erica. All right, so to wrap it up, if you have any advice or anything for, or any suggestions for somebody listening who might be considering applying for an internship or becoming a mentor, what is something you'd you tell them or what is something you tell your past self as some advice for stepping into this role? Alec (25:44) I'll let Doris and Cole talk about the internship side, because I have not been an intern for a very long time and I wasn't one at GitHub. But I will say that regarding being a mentor, tips for that would be to picture what it's like to be a mentee. understand the other side and think about what you would like as a mentor. What would you like your mentor to be like? And then try to be that. I think that's the best advice I can give in any leadership role, honestly, because it essentially is about leading. And one of the best quotes or sayings about leading and mentorship is you're still a student as well. Like teachers and students, you're still a student as a teacher and like leaving room for learning as a mentor is really important as well. So I definitely learned a lot this summer. Also Gen Z slang, they taught me a lot of Gen Z slang. So that got me in, in with that, which was, which was good. But I've said enough. Cole (26:44) Yeah, I think to be honest, what's going through everyone's heads as an intern is, am I gonna come back? Like, will I get a return offer? And people do, people try to do the best job and do the most work to get a return offer. So I feel like that's absolutely doing the work for the wrong reason. And you're not going to have fun doing it that way. And you know, I've... We were just in SF talking to other interns and you know, 99 % of the conversations are, what do you think about return offers, return offers? And you can clearly see the stress and the fatigue that people have from thinking about this. But I think if you allow yourself to kind of just not worry about it and do the work for other reasons like self growth and growth mindset and progression in your engineering career in general and your skills, then. you'll have a much greater time and you'll do much, better work and you'll be more fulfilled in the end. So don't worry too much is my advice, guess. Doris Wang (27:40) Yeah, I think in terms of applying for internships, especially when you're going through behavioral interviews, think being your authentic self is like, I mean, I think that's a common advice, but I think it's really important because like, how you will like your experience, it's really related to how you fit, your vibe fits with the company. And I think at least for GitHub, it was really important. The behavioral was really important to kind of scope out the vibe of the interns and like... And I think that our vibe, matching the company culture, is a big part of us enjoying our experience. And I would also say, going into an internship, having an open mindset about, you're not only there to learn technical skills or do a lot of work, you're there to meet a lot of new mentors and understand other engineers' learn just different ways to problem solve from different more senior engineers and also to scope out your career. Even if you're coming in as an engineering intern, I think it's still good to talk to people that are in the PM space, where only customer success and kind of understand just the different career paths that you have and not just lock in and heads down to your code. But yeah, I think like... just being super open-minded and like, yeah, being your authentic self. Cole (29:05) Yeah, I kinda wanna add on to that, cause that's a great point. I think it's very easy to want to try to act like the person that you think they want you to be, and that ties into being your authentic self. And that's definitely not gonna work out for a lot of reasons. And I think a good way to put it that we heard about recently in one of the AMAs is if you are presenting or you're talking to someone that you wanna impress or something, you can be yourself plus 25%. So that means be yourself, amp up your energy. Think about your responses more, but don't try to be someone that you're not. That's just, that's not gonna work out. And ultimately, whether you enjoy or want to come back here, it's all about how you fit into the company culture. Erika (29:45) I feel like I have learned so much from this discussion, not only about your experiences, but all of your thought processes and what an enlightening, enlightening discussion it's been with all of you. We are going to wrap up with a fun segment. Hopefully this is fun for you. And sort of a, can be a non sequitur of like the strict developer focus. but thinking about if you could be mentored by anyone for one month in anything, what would it be and why? And I can start by kicking this off because I've had time to think about this. And I think Alec knows this, but Cole and Doris, might not. I had a previous career as a musician, music teacher. And someone I really admire is ⁓ Dolly Parton, specifically in songwriting. And if I could have a month being mentored by her in songwriting dream right there, would, yeah, I would find that incredibly inspiring. Cole (30:47) I could go next. This is kind of an interesting answer, but I definitely, definitely would love to be mentored by my future self. I can't think about how many times I always bring up to myself, wow, I wish I knew this a week ago, a month ago, a year ago. And yeah, I feel like I could steer myself in the right direction sometimes. Doris Wang (31:06) Yeah, I love Cole's answer, first of all. I was like, I wish I thought of that. But yeah, my answer is like a little bit boring, but it's so like kind of similar to Cole's. Just like anyone that is like currently in the career path that I want to go down. So like someone that's an EM and like cares a lot about developer happiness and is like working on something that they're really passionate about and thinks is really cool. Yeah, just someone who I can imagine. myself to become. Alec (31:36) those are both good answers. Yeah. I, I did with the amount of time I had to think about this, I'll tell you the first person that came to mind. and I think it's valid. ⁓ I would go with the answer that a lot of people would say, but I think Steve jobs would be a really cool mentor. people He was definitely not loved by everyone. He was definitely like a contentious person, but I absolutely love to watch his keynotes on YouTube, like his old ones. They're just like so interesting to me. And I would particularly like to be mentored on just his public speaking ability, like how he's able to like capture an entire room and like really get people onto his vision. Regardless of whether people think he's a good person or not. ⁓ I think that he did some amazing things and I would like that skill. So that's my answer. Bethany (32:26) Everyone has such great answers, my gosh, like big brain answers. I think mine went a little more niche. There's somebody who goes to GopherCon a lot and gives talks and used to be on the Go team, I believe, if not just Google in general, Rebecca Stambler, but she just has such a great way of doing technical storytelling and clearly has such a depth of knowledge. I would love to just even a day pick her brain about her skill set and how she goes about things and thinks through things because I really admire it. and love every talk I've seen from her. So that would be mine. Brittany Ellich (33:02) Love that. I'll round it out. I also have a slightly different take on this. I love everybody's answers so far. I think that if I were to choose anybody, this is probably actually the most achievable of these, but I would pick Sarah Vessels, who is one of the staff engineers here at GitHub. I just recently reread her blog post about code reviews and it was just so good. And she is one of like the smartest humans I've known and the most compassionate code reviewer. And I would love to just, you know, spend more time learning from her. I'm totally going to tell her that I said that too. Erika (33:32) Maybe we can get her on the pod. I don't know, all your gopher con connections too, Brittany, we might be able to get some some big hitters from the space on here. And yeah, well, thank you all so much for this discussion and thank you listeners for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the pod. Brittany Ellich (33:35) That'd be awesome. --- ## Episode 17: Ep. 17 | Empowering Women in Tech with Jennifer Harris - URL: https://overcommitted.dev/ep-17-empowering-women-in-tech-with-jennifer-harris - Published: 2025-07-22 - Topics: Non-traditional Paths to Tech, Leadership & Management, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/105731561/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-6-20%2F404208691-44100-2-cac0b61ee1e15.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, host Jonathan Tamsut and co-hosts Brittany Ellich and Bethany engage in a deep conversation with Jennifer Harris, founder and CEO of Technology Management Concepts. They explore Jennifer's journey into entrepreneurship, the evolution of her role as a CEO, and the unique challenges faced by women in tech. The discussion touches on imposter syndrome, the importance of networking, and the dynamics of gender in the workplace, particularly in relation to AI and technology. Jennifer shares valuable insights and advice for women in tech, emphasizing the need for self-advocacy and the importance of building relationships. The episode concludes with reflections on the future of AI and the opportunities it presents for women in business. Takeaways * Jennifer's journey began with a passion for solutions and technology. * Entrepreneurship requires resilience and adaptability. * Imposter syndrome is a common challenge for folks in leadership. * Women often face unique challenges in the tech workplace. * Self-advocacy is essential for folks in tech. * Building relationships is key to professional growth. Links * Connect with Jennifer Harris [https://www.linkedin.com/in/jharristmc/] * Tech book club Repo⁠⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠⁠Overcommitted Discord⁠⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠⁠Overcommitted.dev⁠⁠⁠⁠ [http://overcommitted.dev] * ⁠⁠Bethany Janos⁠⁠ [https://github.com/bethanyj28] * ⁠⁠Brittany Ellich⁠⁠ [https://brittanyellich.com] * ⁠⁠Jonathan Tamsut [https://infinitely-fallible.bearblog.dev/] ### Transcript Jonathan Tamsut (00:00) Welcome to the Overcommitted Podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host, Jonathan Tamsut, joined by... Brittany Ellich (00:09) I'm Brittany Ellich. Bethany (00:09) Hey, I'm Bethany. Jonathan Tamsut (00:11) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers, whether you're pushing code or taking on new challenges. We're happy you're listening. Today we have a real treat. We are joined by Jennifer Harris, the founder and CEO of Technology Management Concepts, a Microsoft partner. Jennifer is also very interested in diversity in tech and company culture and innovation. And so I'd just like to say welcome, Jennifer to the pod. Jennifer Harris (00:45) Thank you. Thank you for having me. Jonathan Tamsut (00:47) Okay, so we have a couple questions that we want to ask and sort of facilitate conversation. So I think, you this is the first time we've had kind of a business person. And I think that's really cool that we have like a sort of an executive level person. So I think one thing we're kind of all interested in is like, how did you end up where you are? what, how did you, you know, decide to, yeah, how did you decide to start your company? What inspired you to start it? Jennifer Harris (01:09) How did I begin? So I think like probably all of you, I always like solutions, know, I always could see businesses and just like found it. But when I was actually the last year in college, personal computers had come out and it was this idea that you could self do things. I think I always liked the idea that you weren't so committed to having to use mainframes or wait for things. I was a terrible though software developer. I took like one Fortran class, you know. It did inspire me and I went to this boot camp. left college. I went to this boot camp that was like gonna be computers and I moved to California and I got a job at Transamerica and at the time IBM personal computers had just come out and they were shipping this insurance company like everybody had to have a personal computer and I was 22 and my job was to tell actuaries who had been doing it for 20 something years that they didn't have to wait man months that we could use Quattro Pro or you know the precursor to Excel and I would sit there and I would show them how you could you know but I I had just learned it too, like I had learned it the night before type of thing. And I wrote like an access database that a bank, they sent me to a federal credit union in New Jersey. I'd never been on a business trip, you know, to show how a personal computer could, you know, do things. And I was just sort of playing around and my best friend from college had moved here and she was working for GTE, the telephone company. And we were like, we could probably teach people how to use these computers and they would pay us. So we went to her laundry room in her rented house. We had a third partner. He was also doing accounting and we just sort of got a phone and we created a business. had no idea how. So that's how we started and here we are. Jonathan Tamsut (02:49) And what were you, so what were you selling initially? what, how were you, what was your product? Jennifer Harris (02:53) So she had found this, there was accounting software, people were still typing checks, know him typing checks and writing in big ledger books and they would send out their accounting. In fact, one of my part-time jobs before Transamerica was, you know, that's why I see what we do now. There was a woman, I thought she was older, she was probably in her 40s, I don't know, her name was Fern, and we would send out people's financials and it would come back in green bar paper and she would add it on an adding machine every day. And I'm here, I'm 22, and I would it in like an hour. And I would say, what are you doing? And she would say, I'm adding it. I'm like, does it ever add up wrong? And she was like, what's computers? And so that idea, that this is so groundbreaking and AI and everything's going to change everyone's, this has been happening where the trust issues forever. So Brenda and I thought, well, we probably know more than everyone else. at the time, they were like Best Buys. They would sell accounting software and there were ACPAC and Mass 90 and the precursors to what we have now and one of them was called Great Plains and we would go in give our business cards to the guys that Albania sold the software in the stores and say give our card to anyone that you sell it to and they would and someone called us and said can you come out and teach us and we learned it and we would go and just teach them and they paid us and we were just like my god and we went from the laundry room to like a one-room office where we had like a door desk you know like a door a real door. two file cabinets. And we named our company and you know it really was homegrown. We would try to get people to use us and at one point we were like why are we having them use us? Why don't we try to call the people that manufacture the software and have them you know sell it. And we hired a couple salespeople and we had no internet remember so we had every bad business decision you could make. From a salesperson, we tried to collect money. They were paying the salesperson directly, know, those kind of things. Like we had no idea. But by doing it, you know, we went out to clients. We actually went to clients. And you got to learn like how people make everything from dining room tables to, you know, soups to, and that's the coolest part of the job. And I recommend even you guys who make software to go watch Who Uses Your Software. The most fun thing is to go on a manufacturing floor and just see like, recently I saw how shopping carts were made. I was like, It's like, then it all starts to, and then you come back and you see they're using the software you taught them to use. And it's just, you know, really inspiring. for me and that's what Brenda and my partner do. We would see who used the check printing software when they paid us, know, who was doing, who had formatted their checks, that kind of thing. So that was sort of the way we got from being in the laundry room to actually selling it, but it was really truly didn't know any better and just thought we could and we didn't know we were women in tech, didn't know anything. But we knew that we knew something other people didn't. and that we could make their businesses run better and that people will pay for that. So that was sort of the start and I didn't have anything to lose. I wasn't married, I didn't have kids. Jonathan Tamsut (05:52) Yeah, no, that's so cool. I mean, it's pretty cool how like your career has sort of traced sort of the advent of the personal computer and then sort of the growth of software. Yeah, that is pretty cool. Jennifer Harris (05:59) Yeah, followed it. The personal computer, too, I think people forget, like when I say floppy disk, I mean it held almost no data. So imagine we're teaching people how to put their inventory and their financials, and they're having to decide. We're having to like not make it so big because it's not going to fit. And then when they got like 10 megabyte hard drives, they're like, how will we ever, you know. Jonathan Tamsut (06:09) Mm-hmm. No. Thank you. Jennifer Harris (06:24) fill that up. And also people didn't have access to learning, you know, so we would go to phone booths to do support, tech support, literally with a calling card. We'd stop and call people back and say, did you turn on the computer? Did you shut the door to the Fafi disk drive? You know, and so it was like, no one had seen this before. you know, and now you can imagine it. And so, you know, and people were scared. It was their jobs, right? Jonathan Tamsut (06:28) Hmm. Yeah, definitely interesting parallel to today. Jennifer Harris (06:51) Yep. So from there, you you go in and you start talking to CEOs and CFOs and you're 23 and you're 24 and you're 25. So Brenda and I as women, now looking back, we never said we owned the company. And now I realized, you know, maybe we were saying it for different reasons. At the time, we just didn't want, we wanted to be able to escalate a complaint, you know, to somebody. But we rarely said that we were the owners when we went in. And consulting was just consulting. And I really think the world is going back to that a bit. You really were going out and you were talking Jonathan Tamsut (07:08) Hmm. Jennifer Harris (07:19) businesses, you're listening to their problems and you're trying to see how you could, you know, help them and at the same time you're trying to pay your own people and be profitable and, you know, make it and we through the 90s alternated having children so we would be pregnant, you know. Yeah, no we intentionally did that. Jonathan Tamsut (07:34) Did you intentionally do that or was that sort of just, okay. Okay. Wow. Jennifer Harris (07:40) Four years of people seeing us in terrible maternity clothes, because we went out to clients. So we did that, and we were true entrepreneurs. it was really, I never wanted to do anything else, and I never had a plan B. So it was very much what we enjoyed. Bethany (07:56) That's really cool to hear about the trajectory of your company and kind of how your role has evolved. I'm really curious, how has that role changed with you being a CEO over time? ⁓ How has that shifted your focus and what you've been doing? Jennifer Harris (08:08) again. So I never realized the hierarchy that as much as I do today, titles and the sort of separation, because to me, software developers, consultants, financial people, like there wasn't as much of a... you know, title thing. was you were a consultant and if you knew how to do it better, you were just a better consultant. And this today, it is insane, the titles. I hire people, I swear to you, I hire a developer. If I don't put senior, if I forget or I just forget, like, and I put in the welcome email, you know, I hired Bethany, she's a developer and I don't say senior architect, it is just, know. So the CEO thing, is being used and I do see that from the outside now there is quite a different you know respect that goes along with it and that by not using it particularly as women you don't walk in with a certain level of respect so I do understand that. It's also everything you say is looked at and analyzed differently and again as a developer and an entrepreneur like we like to try things just try things. Say things, try things. So as a leader, I'll say, I probably drive you crazy because I have all these developers and project managers. I'm just talking. Like, oh, we tried this or. And then I'll hear, we disappointed you, Jen, or we didn't do what Jen said. I'm like, why did I even say that? So that part is different. I think that most C-level people are entrepreneurs at heart. I think most leadership below are executors. And so there's a definite difference. I think that we all want, everybody that's upset in corporate America, it's because they want to get back to what they love. And they've let sort of the titles and the, you know, the SOPs sort of take it away and away, even though it's the same group that sort of put them in. So it's been interesting for, me, if you're my question, you know, like as the 90s, we had children. And so we were sort of doing it more as a lifestyle business, but that is different than life. Then when people say now they want that balance of, know, what does it I keep I have a mental block because I hate the words on life balance, whatever people say every time you have the interviews. For for Brennan, I it was it was a Jonathan Tamsut (10:19) Work-life balance. Jennifer Harris (10:26) privilege that we had our own business and could have children and you know do what we love. It wasn't that we were going to stop working at four to you know it was more that we didn't have a boss and we were able to be employed and still show up to everything and you know that way but it Jonathan Tamsut (10:35) Mm-hmm. Jennifer Harris (10:43) became like a negative, looked at, you know, lifestyle business. ⁓ so we, as through the 90s, we were growing, but we weren't respected in that way, even though we were doing well. And in 2001, Microsoft bought one of the softwares that we supported, Calcory Plains, and we became a Microsoft partner. And so that sort of changed things a bit for us. Jonathan Tamsut (10:47) Mm. Yeah. So, I mean, you're, so obviously the company just started with like, you know, maybe the three of you and then it's grown. Like, was there ever a period of time where you were like, wow, like I'm in charge of this. I'm a little intimidated. This is overwhelming. Or was it like kind of gradual? Jennifer Harris (11:17) I think for Brendan and I it was not as much as people not understanding that you're in charge of it. I think there's this misnomer, you own your own business, you like you get to do whatever you want. Or people listen to you all the time. It's the exact opposite, honestly. Nobody listens to you, everybody. But. Jonathan Tamsut (11:31) Yes. Jennifer Harris (11:34) No, think John, the biggest thing is that because there wasn't the internet and there wasn't the same way to get information, we would just make things up so much and then you find out you're wrong. And it was such trial and error. I think that I don't wish to not have the information now, but I do think that you don't learn as well as when you're forced to go out and sit in front of a client and sort of screw up and have them fire you or have to live through the rejection and the... Jonathan Tamsut (11:53) Mm-hmm. Hmm. Jennifer Harris (11:58) My very first client, gave a freight business card, our first business card I had, and he called me out on it. He like, that is so, he didn't know it was, because that's so unprofessional. You don't have a crisp business card. Now I remember this 37 years later. And you don't get to have as much of that now, and I think we're not as resilient a bit. But Brendan and I became partners of Microsoft. First we were Great Plains partners. We had to travel to conferences. had listening to you guys. It was so different from in education. It was going and having to meet people. And it's not even networking. It's just being part of a community. So you get the software updates when they come out and you know what to your clients and they refer you clients. you know, you can hire staff and so you had to go to these conferences that we had no idea, you know, what we were doing. Jonathan Tamsut (12:51) So do you see the role of a CEO, is it more, I mean, I guess it varies at companies, is it more, in your experience, company vision or sales or strategy or just all of the above? Jennifer Harris (13:01) People feel safe when you feel good about it, right? When you're authentic. So when you believe what you believe, whether the people think you're Elon Musk and you're, know, whatever, people want to follow people that believe in their vision and right or wrong. And so a CEO that doesn't, shouldn't be a CEO because number one. And number two, you have to the wherewithal to take the risk because you're, You know, I have millions of dollars of payroll every two weeks. You know, I have to sleep at night. And I do. My husband's like, how do you sleep at night? I go, don't know, I just do. And you have to be able to say, make a decision, make a decision, stand by your decision. If it doesn't work, you know, be able to say, okay, let's try this. So I think to be a CEO that either A, hates their job and hates their whatever is not. You really have to believe what you're doing to be successful. And I think people know if you're in it with them. They sort of know, you know, they know if you're authentic. But you can't have a company full of CEOs. You have to have executors and you have to have number twos. And I am so grateful for that. I think people feel like there's a scarcity and everybody has to have the same role. Jonathan Tamsut (13:57) and Mm-hmm. Yeah. That's interesting. I definitely been part of startups where, I mean, every startup I've been part of, I felt like the CEO had a really strong vision. ⁓ Jennifer Harris (14:17) And people have to know, I was not CEO. Brenda was president in Zio, and I was secretary, vice president, and treasurer, because I didn't care about that. And she did. You have to know who cares. You have to know who's that person who... But you also have to know what's good for your startup. And the brightest person might not be the CEO, or the person who even owns the most, you know, of the stock. It's the person people want to follow. Right? Jonathan Tamsut (14:35) Mm-hmm. Mm-hmm. Yeah. Brittany Ellich (14:42) When did that switch for you? Both. Jennifer Harris (14:43) It switched actually recently. So we grew to be about 20 something people. project managers, developers. Now remember, we don't do the tech, we don't even know how, we didn't even know how to do it. So when you start hiring technical people in a technical field, but we were finance people and we knew how to make a business and quite often finance, technical people don't quite often and they don't surround themselves. It's true, know, monetizing yourself. You're so smart in the one area and you do it for free or you work too hard or you don't see if there's a financial gain. We could. When Brenda was the one went going to the conferences, though, she was the outgoing one and I ran consulting and through the 2000s we were probably you know we made two or three four million in revenue we did SOWs we had contracts we were real legit but in 2010 she got cancer and for about nine months she said now you have to go to conferences and I was like no. I'm not, definitely not. She could drink more than me, she could hang with the guys, you know, and I was like, no. And she would just like be on the phone while I was like walking through the streets of Atlanta, because conferences, Microsoft conferences, they don't talk to you. They're clicky. You everybody's great planes, which they bought, the whole culture was to talk to everyone. And then when Microsoft bought them, literally the first conference, like they were talking to each other and not us. And we were like... You know, it's very, very hard. But she passed away in 2011 and Satin and Nadelic came on that same year. And I just saw, was like, oh, this is gonna happen and we have a chance to make something happen. And I was so probably traumatized and I had 27 people who depended on me to make a living. And that's when I sort of had to start. It wasn't just like happening anymore, you know had to raise my gate And I was alone, so that made it different. Also, I had imposter syndrome that 10 years terribly when she died. Jonathan Tamsut (16:27) Yeah, I mean, that's so tough. Yeah. Yeah. I mean, that must be, I mean, yeah, we've, that must be just so difficult being like thrust into, you know, the. ⁓ Jennifer Harris (16:38) Well, the imposter syndrome, you know, I just had to write a book, a chapter about it and I listened to your list too. It's a weird thing you don't know when you're going through it. You don't realize it until later, but when she was alive, you have someone that you go, that you're with. So you sort of don't think about, I good enough or am I enough or, cause they tell you, oh, you were great or oh, you know, that was terrible. But when you're alone, all of those questions in your own head do not answer as confidently. And even when you're complaining like Bethany, can come and say, da, da, da, da, right? And someone might be, poor Bethany. But that's not exactly what you need. You sort of want someone to say, OK, either buck up or go do this or that's terrible or they are awful. But it's hard to find that voice because it has to be someone going through your exact same journey. And that is very unusual. Everybody comes to it with a different. you know, So for me, it was really imposter syndrome. like, can I do this? Am I doing the right thing? And know, a constant people supporting you, but not really. So that trajectory has been, this right now is really fun. I'm like the pimply. short, know, awkward redhead like I was. Twelve-year-old that, you know, grew up and, you know, all of a sudden people want to be your friend, you know, the guy that becomes 6'2 in the football. And it's been very interesting to have people now reaching out that in 2011 were not that. Jonathan Tamsut (18:05) there's so many interesting aspects to it. Like the growth of technology sort of alongside your business. Like obviously you're sort of owning a business with your best friend and then your best friend dying. I mean, that's just such a, you know, interesting. Bethany (18:05) you Jennifer Harris (18:18) think that the thing that I see, there's an Esther Perel statement I talk about all the time where she says you should be married three times in your life if you're lucky to the same person, you know? And it's true with businesses, you know, people used to work at their business forever, right? There was this loyalty thing. Now there's like you have to change. But actually what it is is you have to be where things evolve. Because if you change your job and you do the exact same job. Right? Just a different place. That's not that cool. And if you stay somewhere where they're not evolving, and you're doing the exact same job. But if you can find the right group of people, and they evolve as things change, that's the coolest thing, right? And we were forced to a bit because of the death and technology changing in the world. And I'm really grateful that I took that, that I was able to sort of grow with it. And that's the part that I think is the magic that I was able to do. And you see right now a lot of people thinking it's going to stay how they've done it, and it's not. And that's what's happening. Bethany (19:13) I think too it resonates with just facing imposter syndrome but not almost feeling gaslit by that imposter syndrome. It's like, am I actually feeling this? Yeah. Jennifer Harris (19:20) It is. It's the invisible. Yeah, I am. I was asked to write this chapter in a book called Our Women Still on Mute. And when I read these other women's stories, and they were just like, they came to America. They have these stories, right? And I was like, what am I going to write about? And I did this big transaction this year, and it's 1 % of women. 1 % of women have businesses over a million dollars. 1%. But women, if you look up in any chat, in any research, women are the, they'll say women have most businesses. Women are the biggest, the fastest growing industry. And then you try to get that statistic of how much, how much revenue. You know, it's small, small. And it's nowhere. And then one place I found this statistic. It's like 1 % of women have businesses over a million dollars, so less than 1%. get any investing. And so then I must have asked every tool why that statistic isn't there. It's because it's invisible. Because they don't think women were getting half the investment. So they don't track. And right. so when I was telling people of my experience, this is successful women too. They're like, really? We can't believe that we hear that women we know show, you know, we see women, you know? And so cracking the glass ceiling or having imposter syndrome is dismissed because it's not even looked at. It's an invisible glass ceiling. People don't even talk about it. And that was like a moment where I was like, oh, people are not interested in my story of being a woman doing this. They're interested that I was able to build a company and get huge payout and do things. But when I say this, 1 % of women, even to women in tech and all them, not interested. They don't even know it exists. the numbers are going down, know, of successful women and women in leadership. So it's a... That's been eye-opening for me. Brittany Ellich (21:14) That's really fascinating. think one part of my career, I've always been involved with like the women who code and women in tech groups. the groups often, the folks that actually go and attend them are the folks that are just starting out. And the real retention issues they have are women sticking around five or 10 years into their career instead of, you know, those first, I mean, it's also really hard to get women starting, but. Jennifer Harris (21:35) What do you think? What do you think? Because I've done so many of those and I actually refused to do one this year and because of that it's not helping. The topics aren't good. I have, I think I have, I've been thinking about it, I don't know the right answer, but I have a few. And last year women were crying at a conference, Women in Tech. They were crying, three of us talking about it. And I went up to one of these women and I thought, why are you crying? And they're like, we're badass. We do everything. No one talks about it. They say, because you guys all sit here in this room, 100 of you or more, and you don't talk to the person next to you. It's insane. Brittany Ellich (22:08) It's true. Yeah, I struggle with creating genuine relationships there, I think, than generic tech groups. And I'm not sure exactly why. I also have I'm not currently involved in one. One, a lot of them closed. So a lot of them closed. Jennifer Harris (22:21) So they closed because they were calling it in. what I found, what I think I wish I had had and what you guys, what men do, and John, I'm not calling you out because I sit in these groups, is they naturally don't mind, and John, you're not atypical, but Bethany would end this call, next week she might call me if she was gay. And go, hey, can we get together, have a drink? And then on that drink, say, or you, Bethany, hey, I have this startup that I'm doing, will you invest? Right there. We would never in a million years, right? It's just not done. And so these women in tech groups, they are people sitting around complaining and even talking about mentors and talking about allies, but they're actually not showing people like me that did that. You should only be seeing me and about people that are have done it and are willing to mentor you. and truly teaching some of the things that we didn't get taught. And if I sit on one more Women in Tech call, Microsoft or other, that want to talk about what they want to talk about, and I'm like... No, it's not helping anyone. It literally isn't helping get into the positions that will help. But I don't know the entire answer. I just know that I spent a lot of time on things, and they all got dismantled, so clearly. Brittany Ellich (23:28) Yeah, I certainly... Yeah, yeah, and there doesn't seem to be like anything that has really filled up that vacuum. So what is the advice then that you would give to like a young woman entering a career in tech or even better somebody who's five to 10 years into it debating if they want to stick around? Jennifer Harris (23:45) in. Yeah, I think the first thing I had to learn was not I like to be liked and I like to not talk about my goals in a way that was looked at as maybe too ambitious and I think there's a scarcity. So women are the least supportive of women, successful women, because there's a scarcity I think. I tried to think about this because I hear women say all the time, I like working with the guys. I like working with the guys, you know, and I say. Do you have a best friend? Do you have a mom or a sister? Yeah, I said, then why at work? And it's really because there's this sort of underlying competitive, it's easier to work with a guy. They also sometimes like being the gal, the girl, in male-oriented fields. A lot of the women in software end up being the project managers of the dev team, which I thought was really interesting. a lot, a lot, about four, and this was a year ago before AI was doing it, raised their hand, they're like, so I got a promotion. to run a team of 10 guys. And I end up having to be their therapist a little bit and you know, yeah. And it was, I don't know why I was so surprised. Of course we're running those teams. Of course that's something we would sort of gravitate to. But we don't take advantage of it is what I would say. So you got promoted to be that, right? You need to promote yourself. We tend to talk well about the people below us as managers. We like to, you know, shout out the people below us, our people, our team. We have no problem talking about that. We have a less problem being ambitious for ourselves and you know what? No one's going to invite you. So that's the number one. Get out there. Everything John's doing, I'm sorry, you to do twice as well and twice as much and that's the other thing that's so evident. If he's not networking... have to network. It's not fair, but you do. And that is because there is an implicit bias. You know, just people don't know how to talk to me. They just don't know. They don't know what to say or whatever. So what I would say to young women is stop trying to be liked and have a goal. And if you have a goal, make it happen now. You can't put things off. You can't ask 12 friends. You can't, you know... Do you know that women are adopting AI at half the rate of men in professional life? And do you want know why? What do you think? Because I was fascinated by it. Brittany Ellich (25:55) I didn't Jennifer Harris (25:58) In personal life, no. In our work lives. We don't take risks. We want to know everything. We want to be perfect. We want to tell all the, you know, we're not going to, we're not going to put our jobs on the line. Right? But we have a president or someone will fly the plane that has no idea, but we're not going to. And so that's going to hurt us, right? Cause it's a gender equality AI, you know, and AI is really, right? And so the only thing I could say, I you guys tell me more is that if I said to you right now, hey, come work for me, right this minute, I have a startup, I'm doing it, come work for me. And there was a guy that started, you know, was one of the key members of Snap saying it and reinventing it now. That guy's going to get more play and more ability from even young women. because there's a sense, And because there's not enough people, who else is there? Who women did found these companies that you might want to go work for? And so I'd say take a risk on yourselves and other women too, because the guys aren't going to do it for you. the girls don't either, but some will. Like if I said it, I mean it. Brittany Ellich (27:05) Sounds like the girls aren't either. Jennifer Harris (27:09) Just don't have your own implicit bias, you know? If you are in a women in tech group and you don't call that person when you come in town or you know someone and you're not trying to... know them, you should know each other, actually know each other. That's how opportunities come because that's, it's all relationships. It's not sending your great code to someone. It's not going to be a contest. It's not going to be, you know, it's going to be who you know. And I did not know anyone. That's what I found out. And it was told to me pretty bluntly two years ago. I'm going on stage next week, this is the last story I'll say on that, but I'm going on stage next week because I did not know any of the C levels of the conferences that Microsoft had. I didn't know Microsoft people, and I did not know, and these guys that I'm trying to buy now are doing it who I know have less revenue than me. Okay? And they were getting it. And so in March, I said to someone who was putting on this big copilot conference for Microsoft, was like, I don't know the C level. And they introduced me to the guy last like two months and he's like, you've been doing booths spending hundreds of thousands of dollars with us. And the only thing I knew was I had a feminist as fuck hat that we give out at a woman's day. I wear your hat. And so he talks to me, goes, my God, you have to do the keynote with me in Bellevue. And I say, okay, and I look at the day before and it's all my competitors, which I wasn't invited to, that had already been set up. And so last week I said, hey, there must be an old boys club here because all these guys. And he said, well, you never made yourself known. Nobody knew. And you're the only one that I invited to go on stage and open up. Don't try to compete with them because you missed that. And it was sort of hard to hear. But it's sort of uncomfortable because I would rather have been on the panel. and be just with him, because I'm shy. But I have to do this to show other young women, right? Because all the rest of them are all guys on the day before. And then Microsoft will try to out their woman executive. You know they will. She'll be the first person after me who has no power, by the way. And they'll do their executives. And those women are not role models in that way, right? Because... They're just not sat in them. They're not, you know, and so I guess the thing I would say is meet people, put yourself out there, make sure you're known, and don't complain that you're not known. Like we have to do it and it's so uncomfortable. Brittany Ellich (29:26) Yeah, yeah, it's hard. I think a lot of, you know, women are socialized throughout their life too, to, you know, try to be demure, you know, like try to not be boastful about what they're doing. And it's a very uncomfortable thing. Jennifer Harris (29:33) Right? Well, and it's so, yeah, it's so, I talk about processor syndrome. Someone, some guy said to me like, you're so revved up. I took that as such an insult. Oh yeah. I was like for weeks. I was like, Oh my God, I was too. And it was someone who wasn't even part of our world. Like it was someone who had been coaching us, a coach who wasn't, didn't have a. And this was in January and this guy that I'm going on stage with he's like, I love that you're so revved up. He said, I I love, thank you for saying that. Why did I need that? Why did I need that? Right? That's the, that's the thing. Why did I let someone say those words make me feel? I don't think Steve Bomber killed that everyone was telling him that he was right. Why did I care? I did. And so yeah, it's uncomfortable. It really is. But I guess if your goal is to be self-employed or to have something cool or to do something or, you know, whatever, even the most awkward male founders, Zuckerberg or whatever, they're out there. Brittany Ellich (30:35) They're doing quite well for themselves as well. So yeah. Jennifer Harris (30:36) Right? So awkward. He was so awkward that he got all these college girls to put their picture. You know what I mean? If you think about it and what women founders do you know? Can you look at, do you even say off the top of your head that you would even know their name? Brittany Ellich (30:50) Yeah, that's a point. Jonathan Tamsut (30:51) Yeah, very few. Jennifer Harris (30:52) And if you do, it's the Devil Wears Prada or Martha, you know, like you can't be Oprah. I mean, it has to be somebody, right? know, this was something that's who we know. Like, come on. So that's the, that's the. Jonathan Tamsut (30:55) Mm-hmm. Brittany Ellich (30:58) Mm-hmm. CEO... yeah, the CEO of Blue Sky. That's... I actually don't know her name. Put it forward. Jennifer Harris (31:06) Yes. Let's see, the main, does a person coming out of, you Bethany (31:08) You Jennifer Harris (31:09) don't know her name, and is she doing stuff that's like being quoted in the news? Is she? Jonathan Tamsut (31:14) So time. Brittany Ellich (31:14) Yeah, mean, think part of it, yeah, part of it is that I'm very active on blue sky, so I see a lot of the stuff related to it. But if you weren't. Jennifer Harris (31:18) Right. To think of a kid in school right now, like, or a young professional, would you try to meet up with her, I guess? Brittany Ellich (31:26) I mean probably, but I don't know, maybe not. No? Yeah, that's a point. Jennifer Harris (31:27) Have you? See, we don't like, right? I know. Jonathan Tamsut (31:29) You Jennifer Harris (31:33) I know. It's so like, I hear these stories of these guys, well, I tried to, you I went and tried to meet so and so and had a meeting and like, really? How'd you do that? I cold called him. Jonathan Tamsut (31:42) Yeah. Brittany Ellich (31:43) Wow, yeah, that sounds terrifying. Jennifer Harris (31:44) So that's the journey I'm trying to pay forward now, you know, is like I'm talking to people. Jonathan Tamsut (31:44) Yeah. Jennifer Harris (31:48) There's no benefit to me. People think I'm trying to do this brand. I've even had some people say that, you know, even in my own company. And what I'm trying to do is sort of show I started in a laundry room and I'm here, but it was against all odds it really was. And you can do it too. Everybody has this opportunity, but only a few people are gonna do it because you have to believe in yourself and you have to really feel like you have value in what you're doing. so used to before the thing about being a CEO is you can't blame anyone. I can't blame the leadership and I can't blame the you know the world and the economy and and the politics are terrible and I want to move out of the US and you know everything because I have people depending on me and so it really creates a situation that most people if you think of your life think of a day in your life and don't blame anyone. for your situation, for anything that you do all day long. It's all your choice. That's like, you know, the other side of that, there's very few times that we do that where we really have that self-awareness to say, I could get out of the game, I don't have to do this. But we all sort of have that agency, right? We could all quit. I said that to John, was like, could all quit. You hated so much, quit. And we don't, and so that's sort of the main thing that I found in as women we do, we wanna sort of collaborate and find a better way and we'll just wait and we'll stay in a situation longer than we need to. And so it's been. The joy of my life that I'm able to now talk to people and tell my story and hopefully inspire one person or two people. It's also a different challenge now. So I don't know if John told you, so I did a big transaction at the end of December. And when I did it, I met 80 men in finance, 80 young men between 30 and 40 telling me, trying to do this deal. There were no women in private equity, none. And so I'm in this position now where I'm working by choice and I love AI and I think that if you guys, I hear your podcasts and I hear your pessimism and this, but you're doing it from a place that you're already there and I don't think you understand that. Like the rest of the world, industry, the people using it. You're so far ahead that when you have fears and you're saying about adoption, you're already adopting it to a point that you can't even imagine that the rest of the world doesn't see. And they're gonna lose their jobs. They are gonna lose their jobs. Because they literally don't think it's here at all. It's like not thinking computers are here. And honestly, you know, and so, you know, I go in these companies and I hear people and they've you know, 20 people in accounting and 20 people in marketing and they're still doing a development of an app that's coming out in two years. And you guys are already so far, so far ahead of that, that you losing your jobs, you're gonna be employable. Them losing their jobs, they're not. And they're not. And it's going to really, that's what's gonna change the world. It's not gonna be the AI itself. It's gonna be all these people, all these people trying to figure out. So I'm in a position now where I can sort of talk about that and have some credibility. And unfortunately, it took getting a lot of money and a bunch of men believing in me for me to lose my imposter syndrome. So what I would say is lose it, lose it now. You're smart. You're you. You guys are doing this. It's cool. I listened to all your podcasts. I only understood a tenth, but I tried. So that was my story. Jonathan Tamsut (35:04) Okay, so shall we move on to the fun segment? Does anyone have anything else? Okay, so I guess we can move on to the quote unquote fun segment. yeah, that was, you're right, this entire podcast was one big fun segment. Jennifer Harris (35:12) I thought that was fun, Okay. John's listening to what he should have known, but he probably never heard all these years that I listened to. He lives it. Jonathan Tamsut (35:22) No, it's, yeah, I'm, no, it's nice to have like a dedicated hour to actually talk about these things. Jennifer Harris (35:29) When I went through this deal, by the way, I went to my family and I was like, I could do something that could set us up for the rest of our life or whatever. They're all like, so what does that mean? Cause I'm a mom. And I said all along, like they would say like, I hope you're not so stressed, Jen, or you should take time for yourself. And if there was a guy going through a huge deal. Jonathan Tamsut (35:37) Okay. Jennifer Harris (35:49) Can you imagine being told you should really go to the spa and not close, you know, at $40, $50 million? No, we just think that it's way too much stress for you, So the sexism that I experienced wasn't just from inside, it was outside. John, you were supportive. Brittany Ellich (35:59) That's such a great point. Johnson are very rare position right now where he is in a group of women in tech. Jonathan Tamsut (36:05) Hahaha Jennifer Harris (36:06) But he lived it and he could see right not from a bad place He could see that it's looked at in this weird way. Wasn't it sort of what do you think? He was good. I'm not saying my kids are great But just in general the way our friends or people thought I was just busy Jonathan Tamsut (36:14) Yeah, I... Yeah, I mean, you know, we all, know, we all, for the listener, Jennifer Harris is my mother-in-law. ⁓ We all, yeah, we all love you, Jen. We wanted you to be happy, but... Jennifer Harris (36:25) So you could cut this. See, see? I don't think a man, John, I don't think, well you ladies tell me, do you think that if this was a guy doing a big case, and you can cut this, a big case or the biggest deal and they were getting $50 million something that their children would be like, we just want you to be happy, Dad or daughter or father. Jonathan Tamsut (36:31) Yeah, I don't know. Brittany Ellich (36:48) No, absolutely not. Bethany (36:50) we? Should we ask them how they're doing? Jonathan Tamsut (36:52) Men need to be happy too. Jennifer Harris (36:52) Well, I the thing Brittany Ellich (36:53) ⁓ Jennifer Harris (36:55) is that like it's setting up the whole family for life and it's like taking the stress off the dad or the mom and it's like generational. So yeah, you want you to be happy, but to spend a year to do something like that. Yeah, no. Or you want the dad or mom just to work forever. and be like, you know, and so it's like, people don't, women get this though, we just get like, you wanna be happy, we just don't want you to be stressed, but go ahead and work and support everyone forever, you know? That's the... Brittany Ellich (37:21) both in the house and at work. Jennifer Harris (37:23) Yes, and do both jobs and be in charge, yeah. So that was the biggest takeaway for women is we don't get celebrated when we're working hard with something. We don't get like, if you were doing a project and you were gonna work 24 seven, but it was like the joy of your life, you were creating something, you were so excited. We don't get the support from our... that if a guy was like, I'm going to school or I'm doing a startup or I'm doing something or a deal, the whole family would be like, let dad work right now. We should just give him space or John's got this big deal and I'm just like, want him to get through his finals or whatever. It's very different and that was actually my stress. That was my biggest stress of the whole thing. That's why I I wasn't calling you out in general, but it was that. was it's really gendered and it's because no one has seen a woman do it. We don't see women do it so we don't know what to say, you know, to it. So now you can do the fun part. You can cut that, John. I wasn't calling you out in particular but it was so obvious that's what I got. Bethany (38:20) you Jonathan Tamsut (38:25) No, it's, yeah. No, I mean, you we all have cognitive biases and for sure there's, you know, you have people think of a picture of a CEO, it's probably gonna be a man. Jennifer Harris (38:35) It's advice, I think we just, we're gendered. We just are, we have how women are supposed to be and how moms and you know, and we're trying to fight them, right? I think it's a lot easier for a guy to say, I don't wanna be looked at anymore as the, know, having to make the money and the provider. Jonathan Tamsut (38:43) Mm-hmm. Jennifer Harris (38:53) So now the fun start. John's like, okay. Do you see I made him a cute girl? Jonathan Tamsut (38:55) But no, know this has been a great episode. This has been interesting. think this is a really cool perspective, but let's. Jennifer Harris (39:02) You know I love him more than anything, so it's okay. Okay. Okay. I'm talk to you guys separate. Anyway. Jonathan Tamsut (39:04) Let's do the fun part now that I've been put on blast. ⁓ Okay, yeah, basically we're just gonna... ⁓ Yeah, so we're all gonna go around and talk about a tool, a website, just something that we use that really makes our life easier or is more interesting. Jennifer Harris (39:16) Okay. Jonathan Tamsut (39:28) Cool, yeah, you, Brittany, do you wanna start? Or? Brittany Ellich (39:30) Sure, yeah, yeah, I have something in mind. Yes, so I have been on first responder this week, which just basically means for my team if something goes wrong. uh-oh. Jennifer Harris (39:32) you I can hear, something went with the sound. Jonathan Tamsut (39:41) yeah, there is like some background noise. I believe we have the ability to remove that in the edit. Brittany Ellich (39:46) Yeah, Jennifer Harris (39:47) Okay. Jonathan Tamsut (39:48) Yeah, so if you hear some background noise, don't worry about it, Jen. Brittany Ellich (39:51) Yeah, yeah, it'll be all cleaned up. Yes, tools. Yes. So I've been on first responder this week, which means that if something goes wrong for my team, then I get to deal with it and respond to it first, ideally. And something that I've been working with actually all week is trying to figure out there's a bunch of different Slack channels that I've been a part of. And I'm trying to find some automations and some AI tools that will help me bring it all into one spot and be able to triage it better and resolve these issues faster. So I've been using the Slack workflows for doing things like adding emojis to something to have it like go to a list and then there's another other workflows where like if you send a message then you can you know have something change in that list and stuff and yeah just exploring those. think Slack workflows is my shout out tool right now that I've been really enjoying. Bethany (40:40) Mine is kind of lame. Not lame, but it'll sound like I'm very biased. honestly, this week I've been using CoViolet like nothing else, just between giving updates, making sure my language is clear for different audiences. But also I've been doing a lot of dashboarding and we're using Azure Data Explorer, which has its own query language called Custo query language or KQL. And I've just never been big in KQL or been able to wrap my mind around it with all the other types of query languages there are. But Copilot has been amazing for just saying, I want to do this thing, please translate it in KQL. And that would be amazing. And it's just, it's done it pretty well. And if it's, if it's off, I'll say, tweak this and it'll do that. It's been, made my life a lot easier this week. Jonathan Tamsut (41:32) Cool, yeah, my tool that I actually just set up two days ago is a plugin, is an Obsidian plugin called, I think it's called Obsidian Copilot. And basically it allows you to turn your Obsidian Vault, which Obsidian is like a note taking vault, into basically like your own personal LLM powered Wiki. So it's pretty cool, I recommend you check it out. Jennifer Harris (41:55) Am I unmuted? Yeah. Actually, Copilot, so I preach to use whatever's out that week, whatever's good, even though we sell Copilot, right? But Copilot has all these new stuff now. And so what I've been doing, it's a tool, but taking the transcripts from different calls and not the recap, the transcripts, and then putting it back in to say, what was the call about? What did we really ask? Who was talking too much? What didn't we ask? tell us in deep research, using the research, the new research tool. And it's really been my favorite thing right now because so often we think we've asked, we think we're saying something we're not and the feedback. is so you're not defensive so it's it's been really great and and i will say that i was using only claude then i was really into perplexity and now i'm back to copilot this week did all these new features come out this last three weeks or something that i'm that are now there i think they did okay so that's been mine Jonathan Tamsut (42:50) Yeah, there's just so much. Jennifer Harris (42:51) We don't use Flac, we use Teams, by the way. Jonathan Tamsut (42:53) Of Okay, I'm going to read the sort of closing script, so I think we're gonna wrap this up. So, Jennifer, thanks so much for joining us today and sharing your insights. It was really a pleasure hearing your perspective. To our listeners, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye-bye. Jennifer Harris (43:20) Thank you guys, that was great. --- ## Episode 16: Ep. 16 | Understanding Software Availability with Ross Brodbeck - URL: https://overcommitted.dev/ep-16-understanding-software-availability-with-ross-brodbeck - Published: 2025-07-15 - Topics: Technical Deep Dives, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/105383359/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-6-11%2F403761602-44100-2-35fd8d2bb995b.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, Brittany Ellich and her co-hosts engage with Ross Brodbeck, a software engineer at GitHub, to explore the critical topic of software availability. They discuss the definitions of availability, reliability, and uptime, and delve into frameworks for improving availability in software systems. The conversation covers proactive versus reactive approaches to availability, the business impact of availability, and the hidden costs associated with downtime. Ross shares insights on creating effective availability programs, the role of incident commanders, and emerging technologies that may shape the future of availability in software engineering. The episode concludes with book recommendations for software engineers looking to deepen their understanding of the field. Takeaways * Availability is subjective and varies by organization. * Observability is crucial for understanding production behavior. * Proactive measures can help prevent availability issues. * On-call burnout is a significant cost to organizations. * Understanding business needs is key to defining availability. * SLOs help in measuring and reporting availability effectively. * Incident commanders play a vital role in managing incidents. * Game days and playbooks are essential for preparedness. * Hidden costs of downtime include loss of customer trust. * Emerging technologies like AI may change availability management. Links * Ross’s Blog [https://hross.substack.com/archive] * Google SRE Book [https://sre.google/sre-book/table-of-contents/] * https://sreweekly.com/ [https://sreweekly.com/] * https://uptime.is/ [https://uptime.is/] * Catchpoint SRE Report [https://resources.catchpoint.com/hubfs/Website%20Assets%20-%20Briefs%2c%20EBooks%2c%20etc/The%20SRE%20Report%202025%20Catchpoint.pdf?_gl=1*i7o00n*_gcl_au*NjU5MTk3NDU3LjE3NTE4ODA2NTQ.] * Software engineer’s guidebook [https://www.engguidebook.com/] * Designing data-intensive applications [https://dataintensive.net/] * Thinking in systems [https://www.chelseagreen.com/product/thinking-in-systems/?srsltid=AfmBOoo3JlXzaDxuVl9oCRtGoq5dMSpPR-pWdM8pzFocHiaXu_cBXbdu] * The best software writing one - Joel on Software  [https://www.joelonsoftware.com/2005/06/20/introduction-to-best-software-writing-i/] * Algorithms to live by [https://algorithmstoliveby.com/] * The Staff Engineer [https://staffeng.com/book/] * Clean Code [https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882] * Pragmatic Engineer Podcast - Thomas Dhomke interview [https://newsletter.pragmaticengineer.com/p/github] * Distributed systems by Martin van Steen [https://www.amazon.com/Distributed-Systems-Maarten-van-Steen/dp/1543057381] * Practical object-oriented design in Ruby [https://www.poodr.com/] * Looks Good To Me [https://www.manning.com/books/looks-good-to-me] * Tech book club Repo⁠ [https://github.com/overcommitted-dev/tech-book-club] * ⁠Overcommitted Discord⁠ [https://discord.gg/d9gZyYuqKd] Hosts * ⁠Overcommitted.dev⁠⁠⁠ [http://overcommitted.dev] * ⁠Bethany Janos⁠ [https://github.com/bethanyj28] * ⁠Brittany Ellich⁠ [https://brittanyellich.com] * ⁠Eggyhead⁠ [https://github.com/eggyhead] * ⁠Jonathan Tamsut [https://infinitely-fallible.bearblog.dev/] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments and some stuff in between. I am your host today, Brittany Ellich and we are joined by... Jonathan Tamsut (00:11) Hi, I'm John. Bethany (00:12) Hey, I'm Bethany. Erika (00:13) And I'm Erica. Brittany Ellich (00:14) We are a group of software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building cool things. We continue to meet and share our learning experiences and talk about our lives as developers. Whether you are pushing code or taking on new challenges, we are so happy you're listening. Today's episode has a special guest. Our second special guest podcast we've done, Ross Brodbeck. Ross, would you like to introduce yourself? Ross (00:40) Third thing, my name is Ross, Ross Brodbeck. I work for GitHub in the Reliability Organization, which you could think of for the purposes of this podcast as SRE. I've been doing that for a number of years now, and I've been working in developer tools for a number of years even more. I worked at GitHub and Microsoft before that in developer tools, and I've been around the software industry for many, many years. Brittany Ellich (01:03) That's great. Thank you. Yes, we were just saying how Ross is internally famous for availability. So he seems like a really great person to talk to about availability, which is our topic today. We want to talk about software availability, what it is, how it's measured, and how do you make sure you're handling it correctly. So we're going to start out by just talking about. What is availability to set the scene for anybody who isn't familiar with the term? Ross, how do you define availability and what's the difference between availability, reliability and uptime? Because a lot of those are used synonymously a lot of the time. Ross (01:38) So availability is a little bit of a squishy term because you get to find availability in a lot of different ways. I would think of it at a very basic level as something like what the Google SRE book talks about when we talk about errors and latency and whether or not your application is actually working. So does the application work for users? It doesn't necessarily mean, and this goes to the second part of your question about, doesn't mean that The application is fully functional. Like it could just be around and doing some things, but it may be degraded. Reliable is more about does the application do everything that you think it should do and are your user actually happy with it? I mean, that's a very vague definition of those terms, but basically that's how you, I would think of availability versus reliability. And again, not to get too like nerdy about the Google SRE book, but there is a section in the Google SRE book that talks about like, correctness and whether or not you would measure correctness. So there's even some overlap there about availability being correctness. And I would think of a lot of availability in general, just like this whole topic, as being very subjective based on your needs as an organization and also just based on your actual business, which I think is sometimes not talked about very much in a lot of the literature, but I think it's very much defined by product. So there's some products that maybe don't really need to be that available. Maybe they would define availability differently than other products, like banking software, for example. Uptime. And then uptime is kind of like a way to measure availability, if you will. That's how I would think about it. Brittany Ellich (03:05) Gotcha. Makes sense. Jonathan Tamsut (03:06) Okay, I have a question next. So I guess, you you have a lot of experience working on availability in the context of GitHub and maybe other places. So for people who are, you know, working on their own systems, you know, at their whatever companies, sort of, yeah, like what are sort of some like transferable knowledge or skills that you've... learned, you know, what are some sort of hard-won lessons that you've learned that you think sort of are more widely applicable to like availability in general. And I think it's like also like interesting as sort of a follow-up question, or you can answer these questions in any order, is like, what is sort of like your mental model or like framework for like approaching availability problems in general? Like if you were to, if I were to say, hey, I have an app that is down and not meeting user requests, like what are some things you would think about first? So yeah. Ross (03:58) OK, yeah, so you're going to have to remind me about the second question. But the first question, let's definitely talk about framework for approaching availability. So I mean, there's a lot of things you can do to level up your availability knowledge, I guess. And some of them are pretty extreme. I mean, the SRE world, I already mentioned the Google SRE book. That's kind of like the canonical reference. I would caveat it with there's a lot of. information in there and it's really good and it describes a very specific approach to availability, but I wouldn't read that book, you know, if I'm talking to a bunch of different software engineers and say, this is how we should do it. This is how we should approach it. This is exactly what to do because I think that has a little bit of a reputation in the industry for people kind of like waving it around and saying like, this is what you should do. So caveat with that is a great reference and you should totally go read it because it's free and it's on the web. But if you just Google, Google SRE book, you'll totally find it and has like everything you would ever want to know about the baseline of measuring availability and thinking about availability and what you consider. Why would it be this way? think, especially once you're running an application, especially one that has high traffic, I think that book is a good way to go back and check how you're actually doing things because it's hard to jump into availability if you're just doing things like running a toy application or writing a utility. I don't think that's something that you learn enough. Part of it is doing. And so you mentioned what kind of skills and things. And so one thing that makes me think about that I think is the most important thing you can do if you're a software developer in this space is go into production. And I don't mean log into production and do things. I actually don't advocate that you do that ever. But what I do advocate that you do is go look at your production stack and use whatever observability you have. mean, step one, if you don't have observability. would be like you need some observability in order to find out what's going on in production. And my experience has been that you can learn a lot about your application behavior and how to debug things and how to think about availability just by going and looking at the applications that you have in production today, looking at your telemetry and looking at the current problems that you see. And you can frame it in something like the Google SRE book, but participating in that way is the best way to learn, in my opinion. And I think there's a lot of... not easy to learn skills about debugging and how to understand performance and what's happening in an application that you really, I think it's very hard to write a book to tell you how to do that. It's something that you kind of have to learn on the fly. And I'll extend that to what I think is maybe the most extreme example of that. And I wouldn't advocate that you go do this tomorrow if you've never done it, but the most extreme example of that is go participate in a bunch of live site incidents. Go actually. be around when the application is down, especially if it's an important application. Because that's when the rubber really meets the road in terms of trying to figure things out. we do a bunch of game days across many teams where we have fake availability incidents and fake availability response and all that kind of thing. And that works to an extent, but it's always kind of a controlled scenario that feels very on rails almost, because I think there's always an answer. But when you're in production and there's a database query that doesn't work right and nobody knows where it is or how it works, and let's say the original person that wrote it is gone because it's 10 years old, that's the kind of time when you're really going to learn, do I know how to use these tools? You're going to be put to the test. And I think that's when you learn a lot about debugging those types of incidents and what should I do in this situation? Jonathan Tamsut (07:17) So a follow up question to that is like, what are your thoughts on sort of like proactive versus reactive sort of availability? So, you know, I think like a lot of companies have bad issues, you bad availability incidences that kind of triggers a response and in an ideal world that that same incident wouldn't happen again. But like, do you think it's even possible in sort of a... comprehensive way to have proactive availability, to sort of proactively patch the availability holes and prevent these incidences from happening. How do you think about that? Ross (07:49) Yeah, okay, so that's a great question that I could talk about for like literally this entire podcast probably. So let me see if I can like try to break it down in a way that I don't just take over this whole conversation. So the first thing that I think about when you say, you know, that you have problems with availability goes back to what I said at the beginning of the podcast, which I think is the most important thing you can take away, which is the business is gonna determine how available and what those scenarios are. And so for example, I can plug my blog, you can go read my blog. I wrote a blog article about this. basically, like the way I think about this now is different. So one thing that I feel very lucky to be a GitHub because when I randomly linked in other engineers at other companies, sometimes they answer me because I think because I work at GitHub, not because I'm like special at all. But since I, my name has GitHub attached, they'll sometimes respond to me. And so. A couple of years ago, I went and did exactly that. And I asked a bunch of SREs and people who were in the industry a lot of questions because I was starting to build this availability program at GitHub. I was, you I'm famous for talking about this stuff. And I was wondering like, well, what are other companies doing? like, you know, and what I learned is that there is a big difference between different companies on how they measure availability and what they care about. So just as an example, like a, you know, banking company is going to care about a lot of regulatory compliance things. And they're probably going to have very strict standards for most of their applications that handle money, do anything important. That's going to be a very strict environment. They're going to have really good measures because they have to. Whereas, let's say, a company that sells airline tickets on the web, you just Google, I want to buy an airline ticket, and you go to one of those websites. I don't want to say which ones because I don't want accidentally talking about somebody I talked to, but any of those, the only thing that a lot of them seem to care about is their funnel, which I think totally makes sense. If people can come and buy airline tickets, that's how they make money, then they don't necessarily care if the button in the settings page doesn't work. No one cares to measure that. It doesn't make any sense to spend a lot of developer effort to fix that because it's not doing anything for any of the customers. Customers don't even care about it. And then you have a company like GitHub where I think that one thing that I feel like I learned is that we have a pretty high challenge because we are a developer tools company where we ship product for developers and a lot of our customers need our stuff to be up all the time. And it's not just one feature. It's like, okay, if you're a marketing company, maybe you're like marketing landing page needs to be up, but you don't care if the marketing landing page and the settings page and the blah, blah, blah, blah, blah, to be up. We care. mean, like, if actions doesn't work, people are really unhappy. If pull requests don't work, know, people are really unhappy. If issues doesn't work, like there's a whole slew of things I can go down that happen at GitHub that we have to measure and be responsible for. And that surface is very high. So I think that that's like the first thing to think about. I already lost track of your question. I apologize. But I think it goes back to like, then you have to define those frameworks around those scenarios. Right. So. You're talking about applications and whether or not you care. So first you have to define that. Then you have to go into how are you going to measure availability in the scenarios that you care about. And again, different types of applications have different measurements. So there are standards, kind of. If you go, again, Google SRE book, they'll talk about the golden signals, like saturation, latency, error rate. I forgot the other one. So hopefully not too many people watch this podcast. But then you'll have to measure those, but you may measure other things that your customers really care about as well, or you may measure less because they don't. And then once you're measuring those, then I think you can dive more specifically into the application itself to figure out what is actually successful. And again, I lost track of the question, but I think the most important part of that whole analysis is when it comes to evangelizing availability of a company is to make sure that you're evangelizing the right things because And I can say this about myself. I worked at other companies, not developer tools companies like marketing company, I worked at like the old days, like web portal software and stuff. And I used to care. I always have cared very much about like error rate in the application. And you know, this thing is breaking, like we got to it. And what I've learned over time is that like some of those times that I cared about that stuff, it really didn't matter. It didn't matter to the business. It didn't matter to anybody else. And by pushing on something that doesn't matter. all you're really doing is like taking away from the things that do matter. And so I think understanding what matters and measuring that and then pushing that at the business is the most important thing that you can do to focus the efforts that you're going to have on those types of things. Because at the end of the day, whether or not I personally want it to be this way, availability is generally like a cost center in my mind. It's something that costs money, but it doesn't ship a new product feature. from a... capitalist standpoint, we're not measuring on the balance sheet as being like a net new feature that's making money for the company. We're always going to be measuring it as like a loss, a cost center. So that's always going to be something that's going to have to be something you have to think about as a developer of like, how much is it worth to do this? And how can I convince the business that it's worth it? Now, sometimes the business knows and they care, but if you care, then you're going to have to think about that mindset. Because sometimes you may push on something and realize like, know what? It doesn't matter at all. because of this reason. Jonathan Tamsut (12:54) so you've identified what's important for availability. Like, how do you preempt availability issues and prevent them from happening? I think like, you know, that's probably like a system design, like good system design. and maybe some like load testing game days type stuff. Ross (13:09) Yeah, I think, OK, so yeah, so that's where I guess I was going here is that to preempt those types of issues, you definitely need to know what it is you actually want to preempt and what's OK to let go. All so you're not going to measure everything. And so I do think that there are a number of things you can do. I it depends on your application. Obviously, guess planning for failover and doing it if you can is the best thing you can do. not that's not always going to be something that you can support or something that is even like maybe desired because of the cost based on whatever application you have. Again, if you have like a marketing site that you don't care about, why are you going to build, you know, five nines of availability for that to go down? You know, if, like a region goes down, do you have to fail over or can you just wait till it recovers? Like maybe that business requirements, not that hot. So that is a big kind of dependency on like what you would actually do, I think. And then the other thing is game days. Absolutely. I mean, Playbooks and game days are the two things that I guess I could advocate for regardless of the application is that you always, and it's hard, that's another one that's like, it's even a cost center I think for developers. Like I don't think typically people want to write playbooks or run game days. It's not always like the most fun or it takes planning and work and you know, all that kind of thing. But it does help a lot. And when there is an incident, because if you don't have that type of knowledge written down, it becomes a game of Let's page the one person who knows because they wrote the code, right? And that's never any fun for anybody. Erika (14:33) Yeah, you mentioned also spending time in production and like getting familiar with your own telemetry and monitoring. And it makes me think of like the times when I'm implementing a new feature and, you know, I don't look at the logs for that method or that, you know, slice beforehand. And afterwards, when I look at it and I'm looking for errors, I see all these errors, but then I go back and look at how long they've been going on for and they've actually always been around and it's, you know, a two-year-old error and so it's nothing that I changed but, you know, it's working enough that nobody's reported it but if I'm looking to see if my changes broke anything or made anything worse it's really hard if you can't piece apart what was an error before versus what's sort of new. So yeah, it's a good reminder to check the logs, check the behavior before you do anything to change it to know what your baseline is. Because it might not always be as picture perfect as you might expect it. Ross (15:39) Yeah, absolutely. think there is a big, I don't know, there's always the tension of should we fix everything or not? Like as you mentioned, errors versus like, are these real errors or not? Like exceptions in production is a big, like hot topic, I guess. Maybe it's not, I don't know if people in the industry talk about it, but I know it's a hot topic around here and I know it's a hot topic at other places where, you know, should we be tracking exceptions that happen if they don't have end user impact? I mean, I mean, just sort of maybe, but this is where like SLOs and burn rate kind of come into play, where it's more like, OK, let's measure the behavior that we care about, compare it to baseline, and then look at whether or not it's getting worse and how quickly it's getting worse so that we don't have to watch every single exception. But I think there's a fine line there because I know at GitHub, one of the things we have is automated rollback if your application can support that and we can do any kind of query. really that we want, and we want to compare a Canary rollout to full production, if Canary shows up with a new error, ideally you're not going to watch that at all. As a developer, shouldn't ideally watch that. You should just get a notification that something happened and it should automatically roll back. Because I think once you get to a certain scale, watching things in production gets really painful and really hard. And it's error prone. It's not fair to expect somebody to do that. Bethany (16:54) Yeah, absolutely. I have really loved the tooling that we've gotten around, having safer deployments, relying on just knowing which pages to have open, for sure. I know we've been talking a lot about what availability is and then also availability as a cost center. But I am curious what your thoughts are around Besides the obvious revenue loss of the incident, what are the hidden costs of downtime that organizations often overlook? Ross (17:20) I think there's definitely a few. I mean, we talked about some of them for sure. So like one of them is just on-call burnout. And I think that's a pretty well-known thing in the industry. So I don't know. I don't know if I would call that like quote unquote hidden. I don't know if, you know, if all organizations think about that or not, but certainly people being on call and getting paged all the time in the middle of the night is a huge cost to an organization. Number one, it's a cost mentally and to their personal lives, which is, which is something that can. absolutely get people to eventually leave jobs. And then number two, there's also just the cost of people not doing the work that you want them to do that's not availability work. If you're getting paged all the time and you have to go research why is this thing broken and what's going on, then you're not shipping new features or doing the cool stuff. Maybe I don't think that's cool, but some people do, doing the cool work. And so that's a huge cost. And if you don't have a good handle on tracking that. then I think it could be one of those things where people talk about debt and like, I have a big application that's really old. And maybe that application's fine if you don't have to maintain it or do anything to it. But if that application's old and it pages people in the middle of the night every night, because nobody knows how it works and it has errors, then that's the debt that really needs to be paid down. So there's that. mean, there's also just the customer trust factor, which is very hard to quantify. And I think this, again, goes back to industry. is like how much your customers need your product and what parts of the product do they need and how much do they have invested in it? And I guess we all work for GitHub, so I don't want this to sound like braggy, but I do feel very happy to work in developer tools because I think that the industry in general is held to a high standard by other people. Like the things that we work on, developers look at and say like, I could do a better job than this, right? And I think that's good because you feel a lot of personal, I don't know, desire to make things good because you know that people are looking at it from the lens that you're looking at it from. So I think industry is, you know, it may matter. Like there may be more tolerance in other industries. Certainly there's more tolerance if you're writing marketing stuff or whatever. I don't want to slander marketing all the time. I feel like I keep saying marketing, but like whatever. What other industries, there's definitely other tons. And there's some that there's like no tolerance, right? If you're writing software for a nuclear power plant, there's no tolerance for failure. So, you know, it depends. Brittany Ellich (19:37) you Classic, classic, it depends answer. Yeah, so I think we talked a little bit about, you know, making sure that you are choosing the amount of availability that makes sense for your organization instead of just arbitrarily saying like, we need to be as available as possible. And I think those are some really good examples of, you know, places that maybe availability isn't the most important and the most important thing to invest in and examples of where it is actually incredibly important. So I'm curious how, in your opinion, you would quantify the value of improving availability in places that are. availability is really important and critical. I think we talked a little bit about up time and that's often measured in the nines or 99.9 % to four nines, 99.99 % available. I'm curious, is it worth it to just pick the maximum amount of nines and just continuously work towards getting more nines or? What does that investment look like? Ross (20:31) I'm going to try not to ramble on this subject, but it's going to be really hard. So again, I apologize in advance, but I will try to stay on the question. so I think, well, so to answer your question, like in a, a very succinct way, I do not think that picking a number of nines and just trying to iterate to it is probably the right way to go. And that goes back to the example I gave of like marketing site that you're fine with being down, right? The application architecture is going to change fairly significantly depending on how many nines you're trying to achieve. And maybe I'll just back up and say, OK, so what are nines? One thing you can do to make this pretty simple is just go to Uptime.is, which is a website that calculates SLAs and SLOs. I think it says SLA is on there, but whatever. You can use it for whatever. And you just can type in a percentage, and it will tell you how many minutes of a given time frame mapped to that percentage. And I really like that, because there's a lot of ways to measure nines, which I'm going to probably get into, and this is why this subject could be super long. But one way to measure it is just how many minutes have we been down? So if you're operating a website as a simple example and the website is completely inaccessible for some period of minutes, then you can take that and divide it out over the total number of minutes in a day, a month, a year, whatever. And that'll give you a nines number. It'll give you the percentage of time that your website was up. And so. You know, if you look at those nines, like the way I mentally translate it right now is three nines, which is common to hear is 43 minutes of downtime every month. So that means like in a month, you have less than an hour to be down, whatever you're measuring. It doesn't matter. And then if you go for four nines, it's 4.3 minutes per month. So that's why I say like the application architecture rate, and if it's five nines, like it's, four seconds. like application architecture there is huge. If you write an application, that's only going to be three nines available. And then you try to make it, you know, four nines. think this is where I don't remember what the people talk about or whatever, but there's this concept of like every so many years you're going to rewrite your whole architecture. And to me, this is like a good example of that where you're going to find out real quick, like, man, we got to just rewrite the whole thing because it's never going to work this way. Right. Like maybe we didn't design it to be regional, regional fail over. Maybe we didn't design microservices that could be replaced or maybe the database can't go down or whatever. then you're going to have to go and change all that architecture or else you're never going to reach the 9s goal that you would have. So I think you do have to do that. And I think the other key here is to, this goes to SLOs. like uptime is measured as a service level objective. There's a lot of like stuff to talk about there, but the way I would simply explain it is that a service level objective is basically an objective for a availability number and an objective that relates to time. So we want to be, let's just define it simply and say, we want to not have more than, I don't know, 5 % error rate over the entire month. That's the service level objective. It has to have a time component and a measurement component. And there's a lot of ways to define that type of SLO. This is where I feel there's a lot of like, You can go read my blog. I wrote a lot of stuff about looking at SLAs for different companies, for example, and it varies so much. And how you define that number changes how many nines you can even have. So just as an example, you can measure just success rate, like good, bad success rate, or you can even measure, can you ping my website? Or is my website's, I don't know, health check thing up? Don't check the actual site, just check the health check. If that's up, then that counts, we're good. You can hit that 1,000 times every minute. Then because you have so many hits and it's up all the time, as long as you don't have any major problem, you could say your nines are crazy good. But if you have that website, same website, and you start measuring, let's say it's in React, did the React components load within half a second or what? Like, all of a sudden, the nines capability that you had goes way down. And let's say you have 100 React components. Now you're doing probability math. Each one of those has to be up. And if you're going to combine them, now we're getting into, how do you combine them? Like, do they all have to be up every minute? Or can half of them be down and half of them be up? So depending on how strict you are with your definition, you can totally just, I mean, I'll say it kind of evilly. You could like, evilly manipulate your nines however you want. If someone tells me they have five nines, my first question to them is like, well, how are you measuring that? Because I want to know because I think there's a lot of like variance in how you can decide how many nines you have. Erika (24:47) Yeah, it's interesting. We're going through some SLO revisiting on my team. And we usually have the opposite problem where some of our SLOs are too granular and they're looking at specific pages. And it's not helpful for the alerting aspect because you get a bunch of alerts maybe because the page doesn't get. like enough requests to create like a meaningful baseline. And so you get, yeah, like alerted on it when there's not actually a problem. So yeah, like to your point, like there is that sweet spot of sort of like how granular versus like overarching do you get and like also like how much of the application do you take into account? Like, are you... like are you yeah are all do all is the only thing you care about like the networking aspect do you only care about the data use aspect or do you care about it like all up like which layers are you taking into consideration and like which dependencies because they can be meaningful for different reasons like one can kind of help you point out like where the problem is but Yeah, it may not actually indicate end customer impact. so, yeah, you have to be thoughtful about what you're using as an SLO or a monitor. Ross (25:59) Yeah, absolutely. Brittany Ellich (25:59) Yeah, that makes sense. Yeah, agreed. It's very hard to determine, too. I think it's hard to measure necessarily what... One thing, if the entire website is down, then it's easy to say, okay, we're unavailable right now, but most likely the scenario is like one service is down or one thing is not working. And like, does that mean that you're still available or not? Very hard to measure for sure. So now think we're gonna talk a little bit about how to create a good availability program. And what are the important things within that? Bethany, do want to kick us off on that one? Bethany (26:28) Yeah, no, I know we've been talking a little about important parts of an availability program like monitoring and alerting, but I'm curious what your thoughts are on the essential components there. Ross (26:39) Yep, these are all questions that I can talk about probably too long. So I will try to again keep my responses as brief as I can but Or remind me of the original question when I go way off topic here but so this is this is to me one of the most interesting things that you can talk about from a company-wide perspective and I'll go back to like some of the differences and I'll reference my blog article again. So like there's there's differences between companies here. I think there is the there's one idea of like what industry or And okay, that's one type of company that you're thinking about. How are we developing for them? But the other type of company that I think about is how big is your organization? Because if you are in a startup and you're just trying to get your, you know, site up and do the thing, like you don't need an availability program, just to be honest, like there's no reason for it. Just do the thing. and so there's some minimum level of things you should do, but I could not recommend to anybody that's running a small organization or a very, I'll say like immature, but I don't mean like bad. just mean. young organization to like set up some big program. Because I think you're probably wasting a lot of time that you could just spend developing your product. And I think when your product gets to a certain maturity level, and when you have a certain customer base that is large, is when you need to start considering that you need to have an availability program. Because now you have customers who, you know, this goes back to like, what's the value of an incident or whatever is that if you have a lot of incidents, and you have a lot of customers, you don't want to lose them. If you have no customers, then incidents don't really matter to you. So I think that's a big important caveat to availability programs and how much effort you put into them. Because if you read the Google SRE book again and you just do what they say, you might be wasting a lot of your time if you're three people just coding a website. Don't worry about it. At the GitHub level, with the amount of people we have and services we have, though, I do think there's some key components. And I think It's interesting because I think monitoring and alerting is good and you need it, but I think it's often confused with SLOs in particular with reporting. And so I want to differentiate number one that I think you need, you do need monitoring and alerting and alerting on SLOs is great. You should check out burn rate and look at how to alert based on burn rate if you're going to alert based on SLOs because I think that's a key way of avoiding some of the alert fatigue that you can find. But it's really hard to see it by the way. mean, Low hit rate service, example, like synthetic traffic is a way to fix that. And there's like all this stuff you can do. But ultimately monitoring is great. But I think the key component to like a large organization and making sure that's a sustainable availability program is actually reporting. And how you do the reporting, I don't know that there's a right answer. I can say that there's some things that I feel like I've learned that are interesting about humans that have nothing to do with computers that I think are good ways to think about availability program. So number one, like alerting is good, but I think the teams need to own the alerting and they decide what to do alert on. I don't think you can mandate alerting or tell people what they should alert on. You can give them guidance, but they may not use the guidance. Like, you we talked about applications that are noisy. Like if you have a noisy application and the errors aren't real, then the team themselves are going to know like what the signals are for alerting. But I also think you can do things like reporting. So SLOs for me are a good reporting tool. And now that's a little bit of like a weird way of using the word SLO because SLO is an objective. And so like by the letter of the law, I guess an objective is something that the team sets for themselves. It's not something that they report out to their management chain and say, here's what we're going to do. But that would be an SLA. It's an agreement. Right. Like, hey, we agree we're going to do this. But I think in practice, it's too hard to do that because then you have to maintain two different numbers and you have to like do all this work and tooling and like maybe if you have a very homogenous platform and all the work is done for you, could do that. But I think in practice, it's easier to just say, yeah, we have this SLO and yeah, we're responsible for it. And like, yeah, it's a little bit of both and like, it's not ideal, but it is what it is. And that is what we do at GitHub. So think having that means that you can then report on that number to your management chain or to the product owners, ideally if it's in concert with your product owners. And that's really important. And I think this is one of the things that I like that we do at GitHub is we compare daily incidence to the numbers for availability. And the reason why I think that's important, which I mentioned the human aspect is like, maybe it's just me and I'm not very good at math. not, mean, I'm like fine at math. I I went to like engineering college and I had to do engineering math, but still when it comes down to like burn rate and numbers and all that, I really don't want to sit and try to calculate like, okay, well how long was this thing down? And like, what's the number? And so looking at daily numbers and having a daily SLO that compares to an incident helps me look at like a big table and just say like, okay, on January 4th, was there an incident? If the answer is yes, then this number should be low. And if the answer is no, then the answer should be high. And so I think that's a very powerful tool from a reporting perspective. Doesn't mean you should alert every day that it's down, but it does mean that if you wanna know, and this goes to like operations review, so. At a larger company, think from a director level, you want to have an operations review where you review with your teams, hey, what were the numbers last week? How did we do? And that's where I think that type of accountability is really important. It doesn't have to be mean. It's just a check on, hey, we had an incident. Our customers told us. This can happen. Your customers filed a bunch of customer reports, and you had the status publicly and say, hey, this is broken. Well, if that happened and the SLO didn't dip, then the SLO must be wrong. Your customers are telling you the SLO is wrong. Even if you're like, yeah, I don't care about that, right? But the customers clearly do. So I think that's a really important check and balance for an availability program. And customers might not even be your public customers because, inside of a large organization, you're going to have platform teams. You're going to have a hierarchy of teams that are building on top of all these other things. So I don't just mean, hey, you're a customer-facing team. You need to have an SLO. I mean, you could be the database team or the network team or whatever team, the platform team, and you should have an SLO. if you're hearing from your customers, like, hey, our application's not working, that is a sign that whatever you're measuring, you either need to communicate to your customers that this is the objective that we have, or you need to figure out what you're missing in your measurements so that you can match that expectation with reality for your consuming teams. Those are your customers. So having that, think, is super, super important. And then the last tiller to this, I think, is incident review and incident response, which there's tons of stuff written on and whatever. you need to train people on that. We talked about game days and playbooks. And we have incident commanders at GitHub. If you have a large organization, I think you need some type of role like that. And ideally, it's not a centralized role with like a classical SRE team might be, where it's like four people or 10 people that are always on call. because I already mentioned like that's like burnout. That's huge burnout. So yeah. Bethany (33:11) And for those who aren't aware, could you explain what an incident commander is? Or what that role entails? ⁓ Ross (33:16) Yes, ⁓ an incident commander is somebody who gets paged into an incident whenever it happens. And so usually these are like alerts that go off that are, you know, high confidence that, we have a problem. They're not always though, like someone could just declare an incident and then an incident commander gets pulled in and their job is to basically coordinate the incident. So usually that means finding the right people, making sure we're working towards mitigation. By the way, that's like my favorite thing to say is like mitigate first, root cause second. So, you know, that's a key thing is like, it doesn't matter. exactly what the problem is. It matters that we fix it. So our first step is to go find out what changed and try to revert it, even if we don't know if that will fix the problem, as long as we're sure it's not going to make things worse. So that's kind of the job of the incident commanders to run that type of incident. And usually the incident commanders have had a lot of experience in incidents, which it turns out is really necessary because sometimes you might need to be pushy or you might need to empower someone to page or you might have to page another team. And there's a lot of social friction. I guess obviously to aging someone in the middle of the night unless you're really, really sure. like having someone there to help support that and make sure like, yes, it's okay. This is broken. We need to do it. It makes those types of things go a lot faster and make sure that like everybody does, you know, the thing. Then there's communication, but yeah, that's, that's what an incident commander is. Erika (34:28) So I get to ask a really fun question, looking forward to the future and pick your brain a little bit on any emerging technologies or practices that you think will change how we approach availability in the next five years. Ross (34:41) I know, I know I'm probably supposed to say AI and I think AI has its place. We just talked about incident commanders. I AI to me is probably a good place for that. and I know there's some products that do that kind of thing because I guess I'm thinking of AI as something that can understand a large corpus of material and then, you know, translate that experience into, can do the thing. so incident commander is a good role where like, it's pretty well understood. There's a lot of like literature and like examples for that. So I think you could probably train an AI pretty well. go do this thing. I think where it gets a little more dicey with AI in emerging technology is the investigation piece of this. And I know there's companies trying to do this with MCP servers and whatever, but I guess I feel a little more pessimistic about that because I'm not sure if there is enough prior art that's the same in order to train something to say, investigate this. you can probably hit the basic scenarios, but I don't know. Maybe they will. mean, great if they can do investigations without us having to do it. But I don't know. That seems like less likely. in terms of technologies that are upcoming, I I would say I'll paint a more pessimistic picture. And I'll say that there is this report called the SRE report that Catchpoint publishes every year. And so I would highly recommend, if you're interested in these topics, to go check it out. And they just published it for 2025. Maybe, actually. quite a months ago probably, but I just discovered that they published it. But in that report, one of the things that they talked about was they survey everybody and get, it's a lot of sentiment survey, but one of the surveys was like, how much of your time do you spend on toil? And it was interesting, this is the first year of that survey where they said that toil went up instead of going down. So I'm painting that pessimistic, because when you tell me that, like I just read that survey not too long ago, so it's still stuck in my Like I was really surprised to see that like, wow, toil went up, right? You have all these technologies, all this observability, all these things. And I think maybe, I don't know, like are we at the tipping point where we have so many tools that that's enough tools? we, we, would be easier to consolidate the tools and have fewer and do some of the human work than it would be to continue having more tools. I don't know the answer. you know, maybe it's things can fail over more and AI can actually operate. I haven't. even thought about that, that would be kind an interesting world to explore too. Erika (36:54) very interesting like psychological rabbit hole where I almost wonder if like AI and introduction of AI is making the perception of toil greater where like because we have the ability to automate so many things with AI the things that used to be sort of mundane and like you know taken for granted that you have to do manually or like now seen as toil I have no idea but that can be another take behind the data Ross (37:19) Yeah, it's a good question. And I feel a little bit in a bubble about AI maybe because we all work at GitHub. I don't know if you all feel this way. I was just at Fourth of July barbecue with my neighbors who work in tech and some of them are like, yeah, I'm using AI but I'm just kind of doing this thing, right? And we're all, you know, obviously using all the tools that were given basically for free that we're developing every day. And so like my perception of what are people doing every day might be skewed based on my own. industry versus like, you know, I don't know if you're in finance or one of those banking or something. Like, I feel like some of those areas, they're not, you know, they're not there yet in terms of what we're doing, at least. Again, not to slander that. I just think that obviously those areas need more and things catch up. We're like competing in that arena. yeah. Brittany Ellich (38:04) Love it. I have learned so much today. I've taken so many notes just for myself, not even just, you know, for the actual, for the podcast. This has been great. But we do need to wrap up a little bit here. And so what we're going to do is move on to our fun segment, which today is going to be our top software book. recommendations where you pick one to three. mean, obviously more if you really need to, but this isn't necessarily one you've read recently, but it's like your top, like somebody is just entering the industry and this is your best recommendation for them. What you think, what you think those are. So I'm going to go first to give you all a little bit of a time to think about what those are. So my top three recommendations are, The first one is the software engineers guidebook as like a career level recommendation. That's like one of the best ones, I think that goes through every single career level. Highly recommend that one. and the second one would be designing data intensive applications. If you're interested in how data intensive applications work or anything at a company that's larger than, you know, 10 engineers, this is, it's a really great resource. and then my. Third one is going to be thinking in systems. These are all ones from our book club fairly recently. but yeah, if you're interested in learning about how to think, that's a great, that's a really great one. Ross, do you want to go next? Do you have? Okay. Ross (39:24) I'll go next. This is a hard one. I will say, I don't read very many software books. I read articles and stuff, but there is one book that I really like that I have not read in a while, so I don't know. This is probably gonna date me, so whatever. But there's this book called The Best Software Writing One, which is selected and introduced by Joel Walspolsky, I think he's saying his name, Joel on software. So that's why I say it might date me, because he used to be a very prolific blogger. And he collected all these like software writings from a bunch of different very famous authors and they're like papers, you know, like there's the one about painters and hackers or whatever by the open source guy. See, I don't even remember his name, but like there's tons in there and I'm not sure how much is still fully applicable, but it's a much more like soft book where I think you can get a lot out of people's thoughts rather than specific technical stuff. So I would recommend that one. think it's pretty cool. Bethany (40:17) I think my recommendations would be, I, whenever I have a mentee that's like graduating this program I volunteer for, I always get them algorithms to live by just because I think it is a really good way to break down these seemingly complex algorithms into stuff you can see and attribute physical... nature to the algorithms and see how they work and how people are thinking of them. And I think that is a great one. I also really love The Staff Engineer by Will Larsen. I think that one is just a really good book if you have any interest in going the IC path. It really helped me align. with what I wanted to do even though I'm not at the staff level, I am able to see what that entails and if it's something I'm interested in and so I thought that was a very influential book for me. And then finally, I probably would say, I hesitate to say this, but reading Clean Code when I was earlier in my career really helped with imposter syndrome in a way because it was so about how to write code that is obvious what it's about, maintainable, and I thought it helped me really change my perspective. It's not about writing the snazziest one-liners possible or anything like that. I really, I wouldn't say I agree with a lot of the stuff in the book, but I think it's a good way to start forming your opinions and how you think about software. Erika (41:35) I will heavy plus the software engineers guidebook and the podcast. Yeah, he actually interviewed Thomas Domke recently, which was a pretty good listen for any GitHub fans. Yeah, so I will say that book changed my approach to my career and my day to day. John, I think you're last. Jonathan Tamsut (41:53) Yeah, so I kind of think about availability. I think sort of the platonic ideal is to write perfect rock solid distributed systems that never go down, that don't even need monitoring. Obviously, that's impossible. But I think if you want to build, an availability program is sort of a symptom of the fact that mistakes happen, like systems break, a large collection of people make mistakes, a system becomes overly complex. So I think like a textbook on distributed systems, there's like one, I think there's this Dutch guy, I believe he's Dutch, it's available online. I think it's just called Distributed Systems by Martin Van Steen. I've read, you can just read the PDF of it, I think is... Good. I also think like there's this book called the principles of object oriented design in Ruby. Pooder is the acronym. I think that's a good book on like how do you write code? I mean, it's specific to Ruby, but like how do you write code that's like well organized? And I think I'd recommend that book. I think that book was like helpful for like thinking about how do you write software that is maintainable? and that will hopefully not go down. But yeah, there's sort of two dimensions to availability, sort of the underlying hardware, the code organization, so. Brittany Ellich (43:10) Love it. I've got some new ones on my list now. Thank you so much, Ross. This was great. I know you mentioned your blog and we will absolutely be linking to that. But if people want to hear more about you or from you, where should they go? Ross (43:23) Unfortunately that's all I got. My blog is on Substack and you can put it in the show notes or whatever and check it out if you're interested for sure. I really appreciate y'all having me on here though. It was really great. Brittany Ellich (43:33) Yeah, this has been great. Excellent. With that, that wraps up. what we've been talking about. So I just want to plug a little book club reminder. I know we talked about it in our last episode, but our book club is kicking off. I believe today will be the day that this is released will be the very first chapter that we go through. We're going to be doing looks good to me by Adrian Braganza and join us in our GitHub repo. that's overcommitted dash dev slash tech dash book dash club. And the link will also be in the show notes. We recently spun up a discord server as well to chat through that. which is exciting. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or whatever it is you're supposed to do on the podcast app of your choice. Check us out on Blue Sky and Discord and share with your friends. Until next week. --- ## Episode 15: Ep. 15 | Q2 Goals Retrospective - URL: https://overcommitted.dev/ep-15-q2-goals-retrospective - Published: 2025-07-08 - Topics: Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/105018747/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-6-4%2F403296191-44100-2-69ba2f5d134ad.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany, Jonathan, Brittany, and Erika reflect on their goals for the second quarter, sharing successes and challenges. They discuss lessons learned, personal growth, and strategies for improvement. The conversation also touches on their personal interests and hobbies, culminating in an exciting announcement about the launch of the new tech book club. Takeaways * Setting specific goals can lead to increased productivity. * Tracking progress helps in achieving reading goals. * Adapting to life changes is crucial for maintaining focus. * Defending personal boundaries is important for mental health. * Finding joy in productivity can enhance overall satisfaction. * Engaging in community activities can foster personal growth. * Exploring new hobbies can lead to unexpected interests. * Creating a routine can help in managing commitments. * Reflecting on past goals can provide insights for future planning. * Collaboration and discussion can enhance learning experiences. Links * Feel good productivity book [https://aliabdaal.com/feel-good-productivity/] * Sam Who.Dev [https://bsky.app/profile/samwho.dev] * The Mind Illuminated [https://www.goodreads.com/book/show/25942786-the-mind-illuminated] * Tech book club Repo [https://github.com/overcommitted-dev/tech-book-club] * Overcommitted Discord [https://discord.gg/d9gZyYuqKd] Hosts * Overcommitted.dev⁠⁠ [http://overcommitted.dev] * Bethany Janos [https://github.com/bethanyj28] * Brittany Ellich [https://brittanyellich.com] * Eggyhead [https://github.com/eggyhead] * Jonathan Tamsut [https://infinitely-fallible.bearblog.dev/] ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host, Bethany, joined by... Jonathan Tamsut (00:08) Johnathan. Erika (00:10) Erica Brittany Ellich (00:11) And I'm Brittany. Bethany (00:12) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we're happy you're listening. All right, so I looked at the calendar. Can't believe it's already July. We're halfway through the year. Jonathan Tamsut (00:26) Thank you. Bethany (00:35) New fiscal year if you're at a company that counts fiscal years that way. And I know we kind of started this as an accountability group as we mentioned the last time we did this. So I thought we would do another retrospective for Q2. So let's start off with what were some high level goals that you had for this quarter? And whether you felt like you achieved them or if there was any unexpected wins that weren't originally on your list. Jonathan Tamsut (01:00) I just want to say I hope everyone had a good fiscal quarter. And I guess I can start goals. So Yeah, what were some of my goals? think, yeah, so one of my goals this year was to read more. And I actually upped my amount of books I wanted to read. think I'm at like, I think my goal is maybe 24 books. Actually, wait, sorry, let me check on Goodreads. I should have had this prepared, but podcasting is, you know. Anyway, so there's some number of books I wanted to read. I actually just finished a book yesterday. Okay, yeah, so 24 books is my goal. I've read eight. And what I will say is having a reading goal has made me read more books. Other things I've learned is I really like books about military history, and I like I've discovered the genre I really like, which is historical fiction. I just read a book called Munich by Robert Harris, which is a book about it's like Hitler and Chamberlain and all those sort of leaders right before World War II signed an agreement to not go to war. And it's about this like fictional character. Obviously Hitler broke that agreement. Anyway, so reading's going well. One of my other goals was to spend a lot more time studying machine learning. And I'm tracking my hours and that I've been doing a lot of. I think that At the beginning of my quarter, was, at the beginning of the quarter, my goal was like 80 hours week of studying. And, you know, since I'm not working, I just could very easily surpass that. I think I've done like, let's see, I think I'm almost at like 200 hours of just machine learning since the beginning of the year. And one thing that has helped me is I've been tracking my time. And so it's less about like, you know, getting specific things done and more just like, I want my five hours of machine learning studying done today, which I could do because I have nothing else to do. And yeah, so that's been going well and I've seen marked improvements in my math skills and my machine learning skills. I have written some blog posts. I have some tutorials coming out. I'm working on a tutorial. that I wanted to film on YouTube where I build a neural network library and train it to classify handwritten digits from scratch. So anyways, that was long-winded, but goals are going all right. I yield my time. Brittany Ellich (03:15) That's great. had to go back and look through my notes to remember what my Q1 goals were. So I haven't clearly been doing a very good job of actually tracking those. think one of them was to do my newsletter, which I managed to keep up with the balancedengineer.com. You should subscribe. And Yeah. So I managed to send one of those each month or each week. And I actually ended up revamping the over the setup for it recently, which was really fun to start thinking about what do I really want to work on? and you know, create a new, a new setup for that. The other thing was to do the talks that I had planned. So I did a talk at Boise code camp, which was awesome. And I talk at go for con EU, which was also awesome. I don't have a ton planned for Q. What is this Q? three I guess so probably not going to include that on my on my goals for this next quarter and yeah I think Q1 Q2 went pretty well overall Erika (04:07) I think we're entering Q2. Yeah, I think this is... This is the end of Q2? Brittany Ellich (04:10) Wait, no, this is the end of Q2. Bethany (04:14) So it depends if you're tracking fiscal year or the regular year. We're entering Q3 of the regular year. We're entering Q1 of the fiscal year. Jonathan Tamsut (04:18) Bye. But doesn't Microsoft have its own unique way of doing this? That's not... Yeah. Brittany Ellich (04:27) Yeah, so that's a very much, yeah, that's Bethany (04:27) That is the unique way, yeah. Brittany Ellich (04:29) the Microsoft-ism. It's probably not relevant to anybody who does not work for a Microsoft company. ⁓ Jonathan Tamsut (04:33) Yeah. Erika (04:34) Okay, yeah, whatever. Some quarter of some year, I guess. Brittany Ellich (04:41) A quarter ended and a new one is beginning. Erika (04:43) Ha! Yeah, my goals were very broad and it had mostly to do with like increased number of pull requests merged and I sort of added PR reviews to that as well, like sort of fuzzy goal of like increasing my impact on the team. And... I've not looked at my numbers in a while or like trends, but I feel like I'm making more impact. And vibes are good. And I think like similar to your sort of like, I'm gonna like, you know, set aside like five hours instead of like trying to do these certain tasks. I've kind of like, sorry. like set aside some like again fuzzy goals of like improving my pull requests overall like time to merge like improving like how I open them, how I describe them, how I see them through and like each PR I try to find like one small thing to improve on. So I think that's where I'm feeling that that. satisfaction is that looking over my PRs for like this past quarter they look more polished, they look more thought out. There's like plenty of discussion on some of them but it's all really good positive discussion like about like tricky parts and performance and stuff so yeah I think I think I am Improving there, we're gonna talk about lessons learned in a bit, but yeah, I do have something that I'm currently working on for my reviews, which I'll bring up then. Bethany (06:18) I that we have kind of the whole scale of working on goals here. I personally barely remember the goals I set. I think there was something around throwing more parties. I have not thrown any parties. I also have not... I made progress towards the beginning of the quarter in the design course, but... That kinda, I just fell off of it after a while. I think the one that I have been pretty good about keeping up is maybe the public speaking one or trying to get a talk in. I have been applying to talks. Haven't gotten into any yet, which is fine. I mean, it's all about the experience of learning how to craft a CFP really well. So I think it's been still very valuable and I'm trying to get into. the speaker bureau that we have at work that might help also with just becoming a better speaker and learning some better tricks and getting some opportunities there. So that's the biggest one I think I have been keeping up with, but I've really fallen off a lot of my goals just with how busy it's been with, I feel I had a lot of travel over the past few months and that just threw me off with the routine and stuff. Definitely want to talk more about how to get back on track and get back on the horse, so to speak. But like Erica mentioned, taking all of this, let's talk about lessons that we've learned and any surprises that happened. Erica, you want to kick us off? Erika (07:46) Yeah, I realized after our episode on reviewing, like pull request reviews, that I think I've been doing them wrong in some ways of like only looking at the diff. And we were talking about this a little bit with the UI of what it shows you and like how it leads you to focus on the code that's changed. And like that's really not great way to like review what is actually changing like you have to zoom out and look at the end-to-end code path and Yeah, I also Realized this in like a recent review and I think I kind of like led somebody astray like somebody didn't have all the like Context in this area that we were working on and I made some like comments about the changes but didn't put them in the context of what was happening overall. And this PR has been open for like over a week because this person, like, to be fair, like it's like a bunch of domain contacts that like, they're like, I don't, I don't have that. And yeah, like I think. part of this is like, I'm commenting on this one piece of code, but not at all telling you how it fits in the context overall. So that's something that I'm going to maybe take as a room for improvement for next quarter. Brittany Ellich (09:03) For what it's worth, I just grabbed our episode transcript and fed it into Claude to tell us what our goals were, if you wanted to reflect on those from last year, or from last time we did this. Mine weren't too far off. I think we're talking about lessons learned and surprises, right? I think, yeah, I didn't really have a ton of big goals last quarter. I think I wanted to run three times per week, which got really hard with traveling, but I've been doing it because I have a race in September that I'm preparing for, and I'm definitely going to try to keep that goal going. And I spent an hour each week on talk preparation and polishing, which was pretty good. I think it was... I think this next quarter I want to be a little bit more explicit about what my goals are going to be and do a better job tracking them. think things kind of fell apart when we were like, hey, let's start a podcast. you know, life got busy, but I think I'm ready to, you know, refocus and feeling the new year vibes, quote unquote, with our new fiscal year, but is only relevant to us. and I'm ready to get started and refocused. Jonathan Tamsut (10:03) I think, yeah, think, sorry, we're talking about lessons learned. Yeah, I mean, I think big lesson, I mean, I guess this isn't a lesson I really learned, but just an experience I had is that life changes, life comes at you fast. So you gotta be able to adapt your goals. I also think I like, you know, I think, You know, prioritizing is important. I think I often have too many goals, but prioritizing is also like the hardest because it requires you to like think of your values and think like, well, what do I want to spend all this time doing? And that's sort of like strategic thinking. It's just like scarier, harder, especially in sort of like a job career switch search context. Yeah, mean, think, yeah, like having focus is important. And I think that's something that, you know, I can do better. I think, you know, I'm looking at my quarter two goal achievement plan and I had three goals and... I actually accomplished technically two out of the three. One of the ones I did not accomplish was spend 10 minutes stretching every day. That was just totally unrealistic. I was never gonna do that. But yeah, I think having a habit's important. And yeah, I don't know how to get myself to stretch more. I need to do it, but I just really don't want to if you guys have any tips on how I can force myself to do it. Let me know. Erika (11:20) So I think we're also gonna talk about like start, stop, continue. But one of the books that I read recently was something called Feel Good Productivity. And... It's definitely shifted my mindset on things that I don't particularly want to do, but maybe need to do. So like the approach of this book is like a bunch of like experiments you can try. And some of the ones that I've tried recently that have really helped are like adopt a persona. And like. Like I do this with like my workouts now of like, who do I want to be when I'm like doing this? was thinking of myself as like an athlete or something like that, like imagining that person doing this activity and then kind of pretending to be that person. And then the other thing is asking yourself, how can I make this fun? So that's like, will like... have like a piece of candy after I stretch for 10 minutes or like, you know, I'll like listen to my favorite song or like something like that where you like try to find some way to sort of sweeten the activity that you don't particularly want to do. Those have both been super helpful for me. Yeah, especially in like work settings, but like I said. exercise too can definitely be a drag. Jonathan Tamsut (12:41) I'm curious to hear what your workout persona is. Are you just pretending you're Arnold as you're pumping iron? Erika (12:47) Okay, this is gonna be like super dumb, but the one that I found that works the best for me is like imagining myself in like the Triwizard Tournament and like I want to be the winner and like everything I do I'm like, what would make me like the winner of the Triwizard Tournament? Brittany Ellich (13:04) That's amazing. I love that. Erika (13:05) Yeah, that's Jonathan Tamsut (13:07) glad I asked. I'm so glad I asked. Brittany Ellich (13:10) For what it's worth, the thing... sorry. Erika (13:12) No, it's now public information, my inner monologue. Brittany Ellich (13:16) I always think about being on a show like Survivor or The Amazing Race and like that's my motivation for running more. And when I'm like, I need to run like, what if I finally get called to go be on Survivor? Like I need to have these skills. And so, you know, whatever it takes to get that going. I love it. That's awesome. Jonathan Tamsut (13:35) I was really into Lance Armstrong when I was a kid before he was exposed as a doper. And I still do it now where I pretend I'm on the Tour de France and I'm on the spin bike. I'm leading the peloton, 100 meters left, got a sprint, I want the yellow jersey. Erika (13:51) Yeah, I get it though. There's not that like endorphin high with stretching. Bethany (13:51) you Jonathan Tamsut (13:55) Yeah, it just hurts and I'm just super stiff. Who's mom? I think one of our moms gave some advice. I should do it while watching TV. I think that's actually good advice. Thanks, thanks mom. Erika (13:58) Yeah. Brittany Ellich (14:04) Yeah. Yeah, that was my mom. Thanks, mom. Jonathan Tamsut (14:09) Thanks, thanks, Brittany's mom. Bethany (14:10) Shout out to our moms for listening to this and providing comments on our videos and such. I'm learning a lot too. guess one of my goals going forward is definitely I'm trying to think how to get more exercise in so I'm taking notes as well. This is great. I think... For me, the biggest lesson learned is that I'm just a creature of routine. I need a routine, but I also am a big people pleaser and will blow through my boundaries or my routine if it means I hang out with people that I haven't seen in a while or I get dinner and drinks with my coworkers at an offsite or whatnot. So... I think I need to defend those boundaries a little better for what I truly value. If that is social time, then I think that's great, but I also need to readjust and be realistic with the energy I have available and not expecting to do everything. So I definitely think that that was a big lesson that just came at me this quarter. I also think my priorities did shift a bit. towards the beginning of this quarter I was definitely eager to start talking in places and get that blog up and things like that and I still do want to do those things. I think right now though my priorities have just been regaining the energy that traveling and work events and such have I've lost through that so I've kind of taken a step back to just take more breaks, be more in the moment and relaxing. And so I think that's been my biggest priority, but I am definitely excited to get back to doing the things that I was excited about at the beginning of this quarter. Which, like Erica mentions, brings us to a little round of start, stop, and continue. I thought this would be a good way to kind of sum up what our thoughts were for this. this quarter before we talk about what our next goals are. So for those who haven't done this exercise before, it's basically we list three things. One is stop, which is what habits, practices, or commitments should we leave behind? The other is start. What new things do we want to try in Q3? And continue. So what's working well that we want to maintain? Erika (16:22) I can start. I was sort of mentioning before that one of the things that I'm doing this quarter is covering some extra management responsibilities. And with that comes meetings. And as an introvert, I don't typically enjoy meetings. And I have a lot more of them now. And so... I realized with sort of an onslaught of extra meetings that this feeling of almost dread or really not wanting to go to these meetings is pervasive but also pretty harmful. for my own mental health, I'm like, if there's that thing that I really dread doing, like... Like that's going to be harmful for my happiness overall. So I'm kind of adopting this. I guess this goes into the starting. Like I'm sort of the stopping part is I'm committing to stopping like meeting dread, meeting angst. And yeah, the starting is sort of I'm what I found that has been working for me is like this sort of like persona adoption and also like viewing meetings as an opportunity to I'm using my three C's. So connect, communicate, and clarify, which I think are the main points of like in in person or like virtual meetings, like what you can do that you can't do over a Slack message is like look face to face, talk, make those personal connections, and talk things out that might be confusing. So I'm trying to trying to start viewing them as more of an opportunity and less of a drag or dredge on my time. Yeah, I For the record, always look forward to this meeting and meetings with you, which has always been the exception to my distaste of meetings. But yeah, I'm trying to adopt that more for all of the meetings that I attend. Brittany Ellich (18:20) I love that so much. My stop is, it's really not necessarily stopping, but I want to spend less time on it. I think this year I decided that I wanted to do more creating of things and just sort of threw a bunch of stuff at the wall. I've been writing a bunch of blog posts and... writing the newsletter, and I think I want to spend more time reading and less time creating things, which I know is contrary, I think, to a lot of the advice that you see consume more or create more than you consume or whatever, but I'm ready to consume more. I think I've gone through a lot of the things that I'm really passionate about and want to focus on, you know, higher quality writing and more learning from other people. So that's why I've sort of pivoted my newsletter to be sharing posts from other people. And I am hoping to read more, which we'll get to. Spoiler. Yeah. And just trying to share more. yeah, that is my goal. Jonathan Tamsut (19:13) Yeah, things I want to stop. I think I want to like get out of the house and do work more. I think I'm just always more productive when I go to a coffee shop and like do work. think that's kind of my big stop. Stop working from home so much. Get out. Bethany (19:26) Yeah, I definitely feel that a lot. I've been in my house a lot too. I think I have trouble framing with framing the stop sometimes because it's like, it almost sounds like a start in some ways. But in terms of habits that I'm trying to leave behind or not that are maybe holding me back. I'd like to stop feeling, well, not feeling tired after work, but basically stop using all my energy in one place so that I have energy to do things outside of work. And I think I, there are times where you have to give a lot of energy to work and that's fine, but when it's a consistent, it definitely can hold you back and also prevent. your longevity within being able to work at the same quality. So I definitely want to make sure that I am pacing myself a little better there and not basically keeping good boundaries. For starting, I really want to start getting in a habit of being active in whatever way that makes sense. I used to run a lot and do weights, but it might look more like just doing an exercise class for while starting out again, but definitely want to get more active. And hopefully that would also help with feeling more energetic and things I want to continue. Definitely want to continue getting interacting with in the public space. So we do have something to talk about later, which also spoiling. But definitely, I love doing this podcast with you all and chatting with you all every week. Wanna continue trying to do talks and yeah, yeah. Alrighty, so moving on, if you all had to sum up your quarter three goals, what would they be and what does success look like there? Erika (21:15) So the meeting dread, I think adopting a positive mindset for maybe I'll say 80 % of my meetings. I won't go for 100, but I'll go for a solid majority. And then this poll request review, like really... doing a code path focused pull request review as opposed to a diff focused process. And then I'm not sure what this looks like, but I really do need to continue deepening my understanding of Ruby. And I have not been spending dedicated time to that. And I really do think I need to. I've been doing it more like as I work, but I think I need to dedicate like an hour, two, three a week to really like advance my skills there. Brittany Ellich (22:11) I my more concrete goals for this quarter, I'm planning to continue the goals that I had from last quarter where I'm gonna be doing my newsletter every week and running three times per week. But I don't really have as many talks that I need to practice for over the next quarter. So I'm gonna drop that one. I am gonna try to read six books. That would be, you know, for one quarter, I think that would be 24 per year on average, which seems doable. And I'm currently drawing once per week, but I think I want to do a month where I try to do one drawing per weekday and just like really focus on that, because that's one of my favorite things I've been doing this year is just drawing silly memes and cartoons. And yeah, so keeping up with reading, making, drawing and then running. Bethany (22:52) I've loved your drawings. I support this goal of trying to keep those up. Brittany Ellich (22:57) I have a million ideas and I can't wait to actually spend time focusing on them. think August I don't really have anything scheduled so I'm just going to do like a full month where I'm like every weekday make something and I think that'll be really helpful. Jonathan Tamsut (23:09) I've been trying, I'm curious what your approach is, or what your tooling is, because I want to have a bunch of cool drawings for this blog post I'm working on. I want to animate some neural network stuff. And I've just been doing it on a piece of paper and taking a picture of it and uploading the picture to my blog, but I wonder if there's a better way Brittany Ellich (23:29) Almost certainly. There's actually somebody that I follow on blue sky that does really, really well. I need to look up exactly what his handle is. Bear with me. Jonathan Tamsut (23:30) Yeah. Brittany Ellich (23:38) Sam Rose, samwho.dev. And he does absolutely incredible animations. They're just like absurdly good. Everyone is very detailed. So I highly recommend looking at whatever he's doing because he, yeah, he does some really, really cool animations that I would look into what he's doing. I use a tool on my surface. Jonathan Tamsut (23:57) Mm. Brittany Ellich (23:57) It's good for drawing, but I don't think it would be great for animating. Jonathan Tamsut (24:00) Yeah. Yeah, I've thought about messing around with three blue, one brown. This guy makes math videos. He has a library called Manum that does math visualizations. But anyways, yeah, my goals. so this is good. This is kind of my first time really thinking about them. Brittany Ellich (24:11) Soon. Jonathan Tamsut (24:20) you know, since last quarter. So yeah, mean, one of my goals was, so I did VO2 max testing, which is kind of a measure of your aerobic capacity. And one of my concrete fitness goals was to improve my VO2 max. Like VO2 max, like there's a lot of research that correlates it highly with like longevity. So I'm just trying to have like good VO2 max. So yeah, I want to improve that. And I kind of have like a training regimen that I just, I need to follow. that's based on heart rates. I got a heart rate monitor and I've been doing that. In terms of blogging, I've really been trying to publish a blog a month. So if that's three months, that's 12 blog posts. think, or sorry, blog post a week. That's 12 blog posts. So I think, yeah, maybe, yeah, I'll say 12 blog posts. I think that's very doable. unless I'm working full time, in which case that all gets thrown out the window. Yeah, I want to read. guess, yeah, like if I'm reading 24 books, or yeah, 24 books, that's six books a quarter, so guess six books, and then, you know, continue. doing like machine learning setting. Like right now I'm kind of focusing on like math and I'm just trying to like build things from the ground up. I'm like, depending on job stuff, I may finish my grad school program next quarter, which for the viewer, I'm doing a master's in machine learning. But if I do get a job, then I won't do that. So no claps. And yeah, so those were kind of my goals. I think fitness. I also really want to get into meditation. think I kind of went through this two week span where I was convinced I had ADHD. And I was like, yeah, I have ADHD. like. started reading about it. I think a lot of people have attention issues now just due to the nature of our world. I don't know if I have diagnosable ADHD, but I definitely do think that being able to quiet my mind is something I want to get better at. I actually got a really good book on meditation, the title of the book I forgot, but I will... post it in the show notes and send it to you all. But it's basically, it's supposed to be like the best intro to meditation for like Westerners. kind of is this like, I think it's like this like doctor. kind of, you know, kind of guides you through meditation. So yeah, I think getting into meditation would be cool this quarter. Bethany (26:34) I think that's awesome. I feel like meditation has always been so difficult to prioritize, but it's so important to just take time to just be. So, really excited to see, maybe take a look at that book for sure. For me, I would like to get back into creating the blog that I was doing, I might do a little less on the design course, because I did end up making a design for the blog that I feel happy with, so I think I'll just iterate on that. I feel like I've been talking about it so much and then I'll put it out and everyone will say all that for just that, but I think as somebody who's not artistically minded, it takes a while to just kind of feel out how how I want this to look. So it's been really good. I've learned a ton from that design course, but I think I might just try to push on iterating and then getting back to that when I have more time. I do want to read a decent amount. I read, I think, 15 books this past quarter. And for the people who said that short books did not count, there was no short books this time. They all were greater than 100 pages. um, but, uh, yeah, I definitely want to continue with that, but it's been more of a relaxation thing. So I think that's been less of a, uh, something that I've had to stretch for recently. Um, and then I would like to integrate movement into my routine, uh, however that looks, but I would like to. least get some significant movement in three days a week I think would be a good target goal. But less pressure on myself for what that looks like. Yeah. So I think with that we can go on to our fun thing. So I thought while we were reflecting on the quarter I thought maybe we could talk about some of our favorite things that we've really found enjoyment with. So just Talking about something you've really been into lately, it could be just an item, a food, a habit, or a book or whatnot, but just want to hear what y'all are into at this given time. Jonathan Tamsut (28:38) I've been into matcha. It's a new development in my life. It's very exciting to me. I got a little sifter. I got a little thing that spins, know, so you can whisk or whatever your matcha. And I drink it every morning. It doesn't make me feel as jittery as coffee, and I like the taste. So that's me. Bethany (28:59) Do you do it like with milk or do you just have it straight? Jonathan Tamsut (29:03) I kind of just like it's dependent depending on yeah I have these like I have this like I'd like liquid stevia that you can buy from Trader Joe's and Sometimes I pull droplets of that sometimes they put almond milk sometimes they put Oat milk just I don't know just kind of you know it's it's whatever whatever I'm feeling that morning Like to get like to keep it fresh Bethany (29:21) That sounds lovely. Brittany Ellich (29:23) I've been really into E Ink tablets. I got my Kindle out and I've been reading on my Kindle instead of on my phone and it's so nice to not have the distractions that come with my phone. So I've been, you know, whenever I read an article, I usually send it over there, but I've also been researching some of the E Ink tablets that you can use to like write and draw on. And I just ordered one. So I've been really into researching them and finally ordered one from, I think, supernote yesterday. So we'll see. I'll let you all know how it is once I actually get it, but I'm hoping it'll make it easier to have something readily available to write notes on the things that I'm reading or just to write things down instead of typing everything. Erika (30:06) you I've been super into these feel good productivity experiments. The one that I haven't mentioned is one called the Wheel of Life. And he didn't come up with this one himself, but it's like an exercise that you do where you have these, like the categories are set and they're generally like people, work, and like body or like physical environment. And so like the idea is like you fill in the circles of like how you feel, how fulfilled you feel in those areas of your life currently, and then how like what your ideal state would be. And it's been super helpful for me to be present in the times that I'm like the times that I'm in. like. I felt like I was sort of stuck in this rut. Like honestly, ever since I had Isabel, like always feeling like I'm never doing the right thing. Like I'm always like, you know, either spending my time like not being enough of a parent or like not being enough of a employee or whatever. And like, I feel like this has been really freeing for me to be like, even if all I'm doing is like. watching her ride her little bike outside. Like, okay, I'm like filling my like outdoor physical environment bubble. I'm like filling my family time bubble and like kind of using that framework to embrace like the things that do matter to me. So yeah, highly recommend that book. We'll link it. But yeah, and it may not be everyone's cup of tea, but for me it's been super helpful in like having a more positive outlook on myself and the things that I do. Bethany (31:41) I love that. I feel like so many productivity strategies depend on making you feel bad about yourself, so I love that this one really flips it on its head and is a positive thing because after all, it's your life. You get to spend it however you want and it should be a positive experience. So that's really cool. Erika (31:58) now. Bethany (31:58) For me, I've been very into keyboards recently. So I always go in and out of keyboard obsession, but I've never really gotten into customizing the switches and things like that. So I recently got, if you're watching this, it's in that corner right there, a keyboard for gaming called the Rainy 75. And it is a linear key, so it doesn't have a bump when you're pressing down. And it sounds and feels incredible. So I really wanted that with my Moonlander, which I use for my everyday work. So I bought a key or like a switch tester, which I have some right here. I didn't end up getting anything from this, but it helped me learn what I liked in a switch. So I ended up getting Wano Sakuras. And they came yesterday and I put them into my keyboard and that sounds amazing and they're pink so my keyboard glows pink now So it's it's been really cool, and I've been reading out about that a lot It's funny though because I am NOT a fast typer whatsoever. I'm very slow like under 70 words per minute typing Luckily I'm not paid by the word thankfully but Erika (33:11) ⁓ Quality over quantity. Bethany (33:13) Yes, exactly, exactly. I also have a lot of wrist issues, so going to the linear switches has been nice because it's, well, it's been a day, so I don't know. I'll report back. But it theoretically takes less exertion to type, so I'm hoping it's better for my wrists in the long run. We'll see. Maybe it just was an excuse I'm making to get more switches. Brittany Ellich (33:34) I love that. I need to pay you to like build me a keyboard because I don't personally care about them, but I love the custom ones. So yeah, it seems like a really fun hobby. Bethany (33:34) Alright. let me know. I will, I will do it for you. Okay, well, now is the time that, it's an announcement time. So Brittany, I don't know, do you wanna, do you wanna take on the announcement? Brittany Ellich (33:52) yeah, I guess so. Yeah. So we, have been talking a little bit on blue sky about launching a tech book club, kind of similar to what we do internally at GitHub, but as you know, an over-committed book club. So when this episode comes out, that will be officially launching. We're going to dive into our first read, which is looks good to me by Adrienne Braganza. I'm so sorry if I mispronounce that, but, she actually reached out and mentioned but if we get this going, she wants to see how it's going and be a part of it. So I'm hoping we can do a synchronous meeting with her. So the book club is gonna run asynchronously through GitHub discussions and I will post the repo in the show notes. And we will start, like I said, we'll have a kickoff introduction discussion on July 8th when this one, when this episode releases and then start our weekly chapter discussions on July 15th. There will be a Discord community where you can connect with fellow readers throughout the journey and we will plan a synchronous wrap-up discussion at the very end, hopefully with the author, which would be super cool. So that is the plan. Excited about it. Bethany (34:57) So excited. It's definitely in line with our goals of trying to read more and be more present in the community and I think this would be, this will be awesome. I'm excited to really kick this off. Alrighty, so with that, thank you so much for tuning in to Overcommit It. If you like what you hear, please do follow, subscribe, or do whatever it is you'd like to do on the podcast app of your choice. Check us out on Blue Sky and now Discord and share with your friends. Until next week. --- ## Episode 14: Ep. 14 | Mastering pull requests - URL: https://overcommitted.dev/ep-14-mastering-pull-requests - Published: 2025-07-01 - Topics: Technical Deep Dives, Productivity & Learning, Open Source & GitHub - Audio: https://anchor.fm/s/102586d64/podcast/play/104748173/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-5-28%2F402949328-44100-2-eb393c998b091.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, the hosts discuss the intricacies of pull requests, focusing on the reviewer mindset, crafting effective pull requests, and managing the review workflow. They share insights from Brittany's recent conference experience and delve into best practices for both reviewing and creating pull requests. The conversation highlights the importance of communication within teams, the impact of reviews, and the balance between thoroughness and efficiency in the review process. The episode concludes with a light-hearted discussion on pet peeves and positive aspects of PR reviews. Takeaways * The impact of a review is more important than personal preferences. * As a reviewer, focus on unblocking colleagues and improving code quality. * Automate style checks with CI to streamline the review process. * PRs should be as small as possible to reduce cognitive load. * Include context in PRs to aid understanding for reviewers. * Set clear expectations with your team regarding review timelines. * Use PRs as a learning opportunity for both reviewers and contributors. * Document decisions and discussions within PRs for future reference. * Encourage a blameless culture around PR approvals. * Positive feedback in reviews fosters a supportive team environment. Links * The Balanced Engineer Newsletter: Code reviews - A how to guide: https://archives.balancedengineer.com/archive/code-reviews-a-how-to-guide/ [https://archives.balancedengineer.com/archive/code-reviews-a-how-to-guide/]  * The Balanced Engineer Newsletter: Code reviews - Writing good PRs: https://archives.balancedengineer.com/archive/code-reviews-writing-good-prs/ [https://archives.balancedengineer.com/archive/code-reviews-writing-good-prs/] * The Balanced Engineer Newsletter: Code reviews - Managing review workload: https://archives.balancedengineer.com/archive/code-reviews-managing-review-workload/ [https://archives.balancedengineer.com/archive/code-reviews-managing-review-workload/]  * Erika’s PR Template: https://github.com/eggyhead/obsidian-public/blob/main/templates/pr-review-note.md [https://github.com/eggyhead/obsidian-public/blob/main/templates/pr-review-note.md]  * Ben Balter: How I manage GitHub notifications: https://ben.balter.com/2020/08/25/how-i-manage-github-notifications/ [https://ben.balter.com/2020/08/25/how-i-manage-github-notifications/]  Hosts * ⁠Overcommitted.dev⁠ [http://overcommitted.dev] * Bethany Janos: ⁠https://github.com/bethanyj28⁠ [https://github.com/bethanyj28]  * Brittany Ellich: ⁠https://brittanyellich.com⁠ [https://brittanyellich.com]  * Eggyhead: ⁠https://github.com/eggyhead⁠ [https://github.com/eggyhead] * Jonathan Tamsut: ⁠https://infinitely-fallible.bearblog.dev/⁠ [https://infinitely-fallible.bearblog.dev/] ### Transcript Erika (00:00) Welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host, Erica, joined by... Jonathan Tamsut (00:09) Hi, I'm John. Bethany (00:10) Hey, I'm Bethany. Brittany Ellich (00:11) and I'm Brittany. Erika (00:13) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We can even meet to share our learning experiences and discuss our lives as developers. So whether you're pushing code or taking on new challenges, we are happy you are listening. Today's episode focuses on pull requests, covering reviewer mindset, crafting effective pull requests, and managing the sometimes overwhelming review workflow. But before we do that, we want to do a quick recap of Brittany's trip to Berlin last week. Last episode, we talked about conferences and we are so excited to hear about how your experience was, Brittany. Brittany Ellich (00:56) Awesome. Thank you. Yeah, I think it will have been two weeks ago by the time this episode airs But yes, we I went to Berlin for gophercon EU. It was a great conference met a ton of people This was the first like large ish conference I was talking to people at and I was presenting at and there was I think around 300 attendees plus people online and It was great. It was honestly a really great experience. It's very exhilarating slash terrifying to talk to that many people at once, but I really enjoyed it and I met a ton of great people. Highly recommend speaking at conferences even if it is scary to do. Erika (01:36) weird. Jonathan Tamsut (01:36) If the listener wants to go watch her talk, how would they do that? Brittany Ellich (01:40) I don't think that the recording link is out yet, but if this is the future, I will definitely be linking it from my website. So BrittanyEllick.com. It'll be there. And I'll try to share it in the show notes if it's available by the time this episode is out, but probably not. I think it'll be like a month or so. Erika (01:58) Well, happy to have you back and excited to see all of the amazing things that you're doing speaking at conferences. Also, today's theme very much picks up on some of your recent blog content and we're going to talk about some of the same topics. you've made some great blog posts about pull request reviews starting with your mindset and Talking about how impact on pull request of you is really the most important thing to focus on. It's sort of easy to let your ego get in the way or even if you don't intend it to, some of your stylistic preferences. to sort of hold up a pull request. But you mentioned. always asking yourself when you're reviewing, what impact is this having? Am I unblocking my colleague? Am I making the code better by providing this suggestion or this review? And you mentioned going through four phases, which I really like, of a review. You think about the big picture, thinking about whether the code is actually even solving the problem. You think through the logic of the application, is there any loopholes or misses in the logic? And then you think about maintainability. So how is the naming? How is the testing? Will I understand this in six months to a year to two weeks from now? And then also remembering that any pull request is. sort of a digital diary where if you have any questions, the pull request is the perfect place to ask them because it's always a place that you could refer back to. And that's sort of a way to capture those decisions and yeah, any clarifications that need to happen for the changes. So I kind of wanted to open it up to the rest of the group and Brittany if you want to add anything to that of our review processes and what we tend to do as far as start to finish reviewing pull requests and things that we think about. Jonathan Tamsut (04:04) So, you know, one thing pattern I've like observed in my career is like, you know, I think developers often have feedback, but can't really explain or give reasons why. So like maybe something aesthetically isn't good or, you know. your code's not organized, but you can't really, like, know, oftentimes, you know, I've received feedback that's like, I don't really like this, especially earlier in my career. And I think that one of my rules is like, unless I can really say like, hey, this is my reason why I'm going to explain to you why I try not to. give feedback. mean, there's instances where maybe things are a little ugly or just like, I don't know, it's kind of just like an accepted best practice. So I think that's a big thing. And I think oftentimes, know, and I think, that's like a good learning experience and oftentimes engineers just have a tough time really putting it towards why. something should be different. the best code reviewers I've seen are great at this, are like, yeah, actually, like there's a standard library method that's faster and blah blah, you whatever. And those are like the code reviews that I've appreciated most. Bethany (05:10) Yeah, I completely agree. And I love this concept of impact is what you're looking towards for your benefit of reviewing a PR. And I think to the point like John's making about having points that you can explain or maybe consistent things that you comment or things that your team just agrees on is better. I think it's the best thing to try to offload as much of those to CI as possible. So if you have something consistently that you want to make sure is done, such as, for instance, my team does comments above all public exported functions, that's part of our linting rules. So we don't have to go in and say, hey, can you add a comment to this? Can you add a comment to this? But rather, CI grabs it. And so I think anything you can delegate to CI is awesome. And so your true impact is determining if the code changes are correct and if they're maintainable. So I really like that thought process of what is your impact in this review process? Jonathan Tamsut (06:12) I just want to say I really, really, really like what Bethany just said. think automating that stuff with CI is like something probably more of us should think about. Brittany Ellich (06:21) Yeah, I think that if there's anything that is important enough stylistically to comment on, then it should be a linting rule for your team and not something that you necessarily have to think about ideally. I think that there are also valid cases, particularly in my case, I had to learn both Ruby and Go working at GitHub. I hadn't used either of them and there's definitely ways to do things better in Ruby since it's, you know, there's just a million ways to do everything. And I really appreciate when people reach out and say, like actually doing it this way is, you know, faster or more efficient or whatever. Because I know that I'm just never going to be able to take the time to learn it that deeply and I appreciate those. But if it's just a stylistic thing, I don't think it's worth mentioning unless there's an actual tangible value from it. Erika (07:03) I'm curious, Brittany, do you have a PR review template or something that you use personally to keep track of your thoughts through these stages? Brittany Ellich (07:13) Not really. I add comments as I go. I'll do, you know, like I said, investigate the PR description and make sure that, you know, I have like a big picture understanding of what's happening. And then just as I go, I'll just add comments. And so my comments will be sort of all over the place as reviewing a PR, but maybe I should make one. That's a great idea. Erika (07:34) Yeah, I'm impressed you can keep that all in your head at the same time. I definitely use a template to keep track of my reviews because otherwise I think it's really easy to gloss over things. I think hearing about your like sort of four-stage approach is helpful in like thinking of the layers. But I, yeah, I typically go through the same questions, but sort of like, yeah, through a template that I take notes on. And the other thing I look at is like, sort of along the lines of like the PR is documentation where like the PR description sometimes isn't even accurate to what is going on and like we typically expect to see observability or feature flags or anything described in the PR. description, but honestly a lot of times I don't see that and a lot of times the description gets really outdated with additional feedback. yeah, it's a it's sort of an underutilized documentation aspect, I think. Jonathan Tamsut (08:51) Eric, I'm curious what's in your template. Erika (08:53) Yeah, I mean, I'm happy to share it out in the show notes too. It's a lot of these same questions, like, you know, what is this code doing? Sort of like, is the logic sound? Are there any potential performance or like security impacts? And then like, how do I test this or monitor it? So those are kinds of the kind of questions that I ask. Brittany Ellich (09:13) Yeah, we should definitely share that. I would love to see it. Erika (09:16) Yeah, for sure. Bethany (09:17) I, before we move on, I also think that oftentimes reviewing PRs aren't necessarily just for stamping a PR, for saying, this is okay, but also for learning. If you're new to a code base, think reading PRs is one of the most helpful things you can do to learn about. how others on your team review your code, what kind of style they prefer, what's happening in the code, and things like that. And I think, at least in the start of my career, I was always scared to review or ask questions because I would think, I'm not qualified to review this PR, or I'm not, I don't know what's happening, so I'm not well-suited for this PR. But in reality, asking questions is one of the best ways you can learn and also flag things that might not be understandable that the PR is introducing. So it only helps the PR author and yourself and your team with that documentation to ask questions and just try to understand what's going on and point out things where it might not make sense. Erika (10:19) Yeah. Jonathan Tamsut (10:20) There. I'm sorry, where'd go? Erika (10:22) say the flip side of it is too I wish that I could claim that I've never had ego in reviewing a pull request but I recognize it in myself when I go to a pull request and I don't have any feedback and I always have this voice in my head where I ask myself like what am I even doing if I don't have any feedback on this PR like if all I'm doing is giving it a check mark like am I a valuable reviewer but some some pull requests Like that is all they need. Like all they need is a stamp and it's okay to like give it that and move on with your life. Yeah, you don't have to like always have feedback on everything. Jonathan Tamsut (10:58) Well, I've seen PRs and I've been, you know, unfortunately like had my PRs reviewed where they just get beaten to death. Like I think there are some people who are very thorough, but who are kind of reluctant. You know, I mean, we all have different, you know, personalities, whatever. And like some people are really reluctant to give you the stamp, especially if they're a domain expert and there's like, there can be like, you know, 30 back and forths. In which case I think, you know, like. doing something synchronous is better. But yeah, think like, know, where you stand kind of matters because sometimes you don't have anything to say. Sometimes you have always like one more thing you could say. And I think it's, you know, I think impact as Brittany put it is important. Like you don't wanna hold someone back, you know, nothing's ever gonna be perfect. Your code base is constantly gonna evolve. So yeah. Erika (11:45) Yeah, Brittany kind of mentions this as well in one of her posts of your job as a reviewer is not to catch every bug or potential problem, but to be a thoughtful safety net. And I think that's a really great description of the job of a reviewer. And it also like calls to attention sort of like what you mentioned, Bethany, about sort of this fear of reviewing or what you were talking about of like, you know, people being really reluctant to approve of PR. I think it's also dependent on the culture of your team and I've unfortunately heard people sort of... tribute blame to a PR reviewer for something that didn't go well, like a PR that went through and, you know, it's like, well, this person approved it. And so it's like partially their fault that it caused this problem or this incident or something. And like, you know, in a good team culture, like it's blameless and we all share the responsibility. So, you know, that kind of stuff doesn't happen. But unfortunately, I have heard that. And so in some places, yeah, you are kind of thought of as a responsible individual when you approve a PR. Brittany Ellich (12:54) Which is not how it should be. At all. Yeah. Yeah, that sucks. Erika (12:55) Right. Well, awesome. So let's move on to the act of creating a pull request. So on the side of the code contributor. How do we make sure that our PRs are easily reviewed? And why would we even care about this? We sort of talked about this as the reviewer side, but having a PR that's ready to review and that sort of meets these checklist guidelines that we've been talking about can help reduce that back and forth and get your PR through faster. some of the things that Brittany mentions, which I definitely do and try to do in my PRs, is answering the questions. What problem does this solve? How did we solve it? And then calling to attention anything that our viewers focus on. And you also call out test steps, which is great and important for that documentation and also for viewers. So any other thoughts from the group on checklists that you do for your own PR? What kind of thought process you go through when you're something for review? Bethany (14:06) I always like to, one, make sure that all the CI has passed, there's no red or anything like that because I think that's often kind of, it's not the worst thing as a reviewer but it means that you'll need to probably re-approve it or re-review it in the future so I want to make sure it's always as complete as possible. I'll also definitely give a read-through of the PR, but also using copilot is super helpful to give a different perspective. Even it's automated, so it can catch a lot of those very small things that you might have missed or you might have braced past. So that's something that I've been really, really liking. I also will comment on my own PR if there's something that might be confusing or that I'm not sure of or I want to invite discussion. for, so I'll leave a comment saying, hey, this is why I chose this. If you have any other thoughts or suggestions, please tap in or leave anything below. And I find that a lot easier of introducing maybe pros and cons in those discussions rather than including it in the description of the PR itself. Brittany Ellich (15:10) Agree on all those points. really like having, making sure, I guess you already mentioned the things that I like to have in a PR description, but particularly if there's a PR that has a lot of back and forth, I find that those can also get outdated pretty quickly. So making sure that before you merge that if there's anything large that changes about the logic that it's reflected in the PR description, I think is helpful. And then definitely plus one on doing like a pre-review before actually submitting it for review. Erika (15:10) together. Brittany Ellich (15:37) I think that has saved me a lot of time, think, in finding really obvious things if I'm looking at it through the lens of if this was not my code, what would I say about it, or what areas would I be confused about, and adding a comment there. I've found that that's really helpful. Jonathan Tamsut (15:52) I think when you're writing a PR, even before you write code, I think the goal of a PR should be, one goal should be obviously to solve whatever problem, you should do it in a way that reduces the cognitive load of the developer. So think a huge thing is your PR should be as small as possible. I think that's a philosophy. The smallest code change you can make, And like even if it's, I think sometimes it's annoying to like solve a problem over three PRs, but I think that's always better or... most of the time better. So I think making your PR small and then yeah, like you all have been saying, if there's a little bit of logic that's complicated, either think how could you make it simpler or if it's as simple as you can reasonably make it. Add comments, add documentation, links in your code review, add links to issues that give context. I think all those things are. Thanks. Erika (16:43) Yeah, sorry for feeling your thunder, of reading through your post, but they're really good. starting phase. Brittany Ellich (16:43) So I agree. Thank you. Yeah, this is great content. Cross pollination here. I agree with John in theory, making small pull requests is great, but I find myself in practice. really depends on how long it takes to merge something. if I think that there's like an optimal ratio, how long it takes, how much pain there is with getting something over the line and how large those PRs get, which is probably a good sign to, you know, invest in the developer. experience of your CI process, but you know if it's a long process to land something then I find myself sneaking more things into PRs just because I can make one change instead of multiple. Erika (17:28) Yeah. Bethany (17:28) Whenever that happens, I'll sometimes stack my PRs to still logically break it up into separate things, but maybe merge the last one into the other one and continue on with that. sometimes it's... solves that problem in a way that you can break down that complexity for any reviewers, but still get it in in one go for if that's your deploy process. But in practice, do I do that? Well, not really. Erika (17:56) Yeah, think thinking through what to include in the description too, or what to call out, I think that sort of calling out sort of the meta of the implementation, so like really zooming up and like talking through how it's actually used is super helpful because I kind of try to think of Somebody reviewing this who has zero context. Somebody from a different domain area who has no constant context on the project or the problem I'm trying to solve. What would they need to know to understand the change and the implications? But then also those detail things like if I'm updating a query, what... are the performance implications of that update or if I'm changing some logic, what's the impact of that on its downstream dependencies? So I think that that's, yeah, we think of. the pull requests for the reviewers and that's obviously important but also like anyone else looking at this change because there are also references when something goes wrong you know when incidents happen we look through the changelog and look at the PRs that may have been submitted recently that could have caused some kind of problem. And a lot of times the PRs are nothing that I have worked on or have any context on. So yeah, being super clear about where this fits in the overall picture I think is... something I try to do, I may not be perfect at it, because I think sometimes you have so much context that it's hard to zoom out. But Copilot can be helpful there, sort of as that rubber duck and being like, hey, what could be confusing? What would somebody need to know looking at this who has never approached this code before or something like that, like that sort of external voice? we can move on to our last topic then of the review workflow and how to manage all of the review requests that come in. yeah, Brittany, you mentioned sort of senior engineers. PR review workflow often taking 20 to 30 % of the time, your working time, which is a lot. That's almost a third. So how do we manage all of the review requests that come in? yeah, what are the notification strategies or systems that... we use. Brittany, you mentioned three really great suggestions in your post. Would you like to go over them this time? Brittany Ellich (20:30) yeah, I need to think back to what exactly those were. I think the one that has worked the best for any team that I've been on is having a specific Slack channel for review requests. I feel like I come back to that on almost every team because I think every team has this struggle of, you know, making sure that things are reviewed in a timely manner. and I think having a Slack channel is fantastic. I think that a lot of the notifications, particularly from GitHub, if that is your PR reviewing tool, can be really overwhelming, particularly, you know, working there. There's even more that are, that you get. You get just like endless notifications. And there's a really great article that I shared from Ben Balter on how he manages his GitHub notifications that I always refer back to. whenever somebody's asking for, you know, tips on it, that's a really great resource. But... I think that, yeah, the dedicated Slack channel has been the most successful for me and just having folks reach out when they're blocked. I'm never bothered by somebody DMing me and saying, hey, can you look at this again? Because it's a lot easier than trying to keep track of every single thing that your team needs to review. Jonathan Tamsut (21:35) And I find reviewing PRs is like, especially if it's a problem or code base you're not familiar with, is really difficult. It's like a high cognitive effort task. You're like reading something. There's also like, I also, you know, I wonder if like the UX of PRs on GitHub, like. could be improved. Or one thing that I think I often end up doing is like, and maybe there's just a simple way for me to change the settings here, I'll read the, it shows the diff, but sometimes it doesn't always show the surrounding code. So I'll have to open up the surrounding code either locally or wherever and look at stuff if you wanna understand the logic. But I think, I actually really like the idea of blocking out PR time. Because I think that A, helps you just maintain focus and then B, of gets you in the mindset of, I have my coffee, I'm gonna think really hard, gonna really, what are the implications here to the various parts of the system? Because I find PR reviewing, I mean, I can spend hours PR reviewing and it's just really hard. You can spend a lot of time on one PR if you really drill down. Erika (22:43) Yeah, it's always more draining than I think it's going to be. I always think of it as kind of like a low effort task, but it honestly takes almost as much, if not more, like you said, cognitive effort, depending on the PR and your familiarity with the space, but. Yeah, it can be really draining and not always the most enjoyable task. yeah, definitely sort of blocking out some time is a way to make sure that you get the reviews done that you need to. Another strategy you mentioned, Brittany, is to set expectations with your team. like letting them know your capacity at any given moment if you might get to it in the next 24 hours or you need somebody else to jump in and help. Because yeah, sometimes as the contributor you might be looking for a review really quickly or... you you might be kind of left hanging and you don't know why. so having that communication back and forth of, hey, I can't get to this, can somebody else jump in? Or yeah, specifically asking certain people for reviews can be helpful. Brittany Ellich (23:56) Yeah, one thing I found really helpful there is to include a little bit of context when I'm posting a PR for review in our dedicated Slack channel on the size of it. So if it's something really small, then I'll say, hey, this is, you know, a text change PR just so people know going into it, like, okay, this isn't going to take a ton of time. can. do this really quickly and unblock her. Versus if it's something that requires a lot of effort, then I'll also post this as a chonker. Like, take some time to review this one. I think that that's really helpful. Bethany (24:23) I think two things that help me. Sometimes it is easier to just talk things out, especially if it's a complex PR. So sometimes comments get long or there's context or empathy that's lost in translation through just text. So a lot of times I'll review via like a Zoom meeting or something similar. And of course it's important to document anything that happened in between there in your PR, but sometimes it's a little more effective to get your point or your intentions across or hear what somebody had in mind. Additionally, I like to state PRs as part of my work, mean, like we're talking about right now, but in standup updates, if... spend a significant chunk of time reviewing PRs, I'll say that, because that's part of the job. And you're not just graded on how you code or how much you code, but also your impact for the team. So I think that's still a measurable thing. And if there's a PR that you've reviewed that you're proud of, adding it to your Bragg docs too is really nice for future reflection and demonstration of your impact. Brittany Ellich (25:30) Yeah, I think it's also really helpful just related to this, um, in terms of setting those expectations to remember that the thing that you're, the thing that is most important here is getting the work out the door and over the line. so, you know, sometimes that expectation is also, Hey, I'm going to fix this in a follow-up PR instead of, you know, fixing it in this case. Um, and I think that that's something that if you have, a big fan of team agreements and I feel like that is something that is good to talk about as team and have a team agreement. Like if something's not going to break something, being okay with, you know, refactoring and making something more readable in a follow-up PR or, you know, changing the way that we're logging something in a follow-up PR. Same with having team agreements on how, what the expectations are and how long it takes to get a review so that you know when it's a good time to start bugging people. And, you know, if you just post something and it's only been a couple hours, you know, you might have to wait unless it is really urgent and you need some to approve it right away. Erika (26:27) Bethany, it's really cool hearing you talk about your approach to pull requests now compared to what you were describing with your early in career mindset of like the confidence and pride that you have in your pull request reviews. So that is a, I think a very cool illustration of progress and development and yeah, what a cool journey. Bethany (26:47) that's so kind, thank you. Erika (26:48) Yeah, awesome. Well, Let's move on to our final segment. So today, since we're talking about pull requests, it's a big part of the job. And I know that we all have some pet peeves and things that we really appreciate in a pull request. So we're going to go around and state what our pet peeves are, either Well, I guess when reviewing a PR, yeah, things that really bug you. But you have to follow it up with something that you always love to see, either in a review or in a PR. Any volunteers to go first? Bethany (27:30) I can go. Okay, my biggest pet peeve is when somebody requests changes with like no... Okay, so when you request a change, if nobody has done this on GitHub before, it basically blocks the PR from going through until the same person re-approves it. And so it's not necessarily that I think you should always... approve PRs, but just if you press request changes either I think that's only necessary when either the PR is going to go out unless you press that button and block it or there's something severely wrong that you need to make sure is fixed beforehand and you concretely describe what those changes are. So I would say that's that's my biggest pet peeve. And then When something's just readable and thoughtfully documented and crafts the story, I feel like a lot of times we're just kind of throwing out PRs there and I really love when there's something that's very, like you tie the value to it very concretely. So that would be my praise. Brittany Ellich (28:33) Bye. Okay, I think my biggest pet peeve is when I open a PR and see like a ton of reviewers, know, like six plus reviewers and 30 plus comments already on something. I feel like that occurs when something's just been. you know, lingering too long. And I think that the more people piling onto it, probably the less, the less helpful it will be to get that thing over the line. But I do really appreciate when that does happen. Cause I've been in that position before where I'm just like, please just everybody like, appreciate the feedback, but please let me get this out the door. I appreciate when the author then, you know, sets up a synchronous meeting to get everybody on the same page and says, you know, identify as much things are actually critical. in which things could be moved off to another change in the future. Getting things over the line is something I appreciate. Jonathan Tamsut (29:22) My peeve is large PRs. I actually have like kind of a horror story where at a company I worked at previously, Not GitHub, we like hired this person who was supposed to be like, you know, a coding guru who was gonna, he was like our director of engineering who's gonna like elevate all of our code. And he spent like three months on a refactor on some branch and... and then ended up like not really communicating to us what he was doing. And then he was just like, okay, I have this PR and it was just like, you know, this monstrosity of a PR. And we're just like, okay, like this fundamentally changes our data model. Like we're not even sure if this works. Like, so yeah, definitely don't do that. And then praise, you know, I like it when people say, knit when they specify this is a knit, know, or this is, you know, and so what that means is like, hey, you know, when people say this is just my opinion, I would do this differently. You don't have to listen to me. This is just, I don't know, you know, it's my oftentimes my like OCD is triggered and I just like have to comment, but I totally get it that you're you're trying to do your job. You're trying to get something over the line. You don't have to listen to me if you don't want to. Erika (30:26) My pet peeve is when CI is broken and somebody requests for review without any additional context because I start to go in and debug why the CI is failing and it's time that I don't need to spend but I always end up doing it anyway. And my... One of my favorite things is when people sort of like compliment or give positive feedback on a PR. Like if there's something that's especially good, they'll call it out in addition to any suggestions. And I always think that's a way to spread positivity and encourage the right things. Cool, thank you all so much for sharing and for the discussion. To recap sort of what we've talked about, when you're reviewing a PR, think through the impact that your review will have and recognize that it's an important thing to block off time for and really be thoughtful about, but you're never gonna catch everything, so don't try to stress out about being a... a perfectionist in your PR reviews. And when you're creating a PR, be thoughtful and architect it to not only be easy for the reviewer, but also as a document for anyone who might be looking at your code or your changes in the future to reference what's going on and the impact it might have. So thank you all so much for tuning in to Overcommitted. If you like what you're here, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week, bye bye. --- ## Episode 13: Ep. 13 | AI 2027: Will AI take my job? - URL: https://overcommitted.dev/ep-13-ai-2027-will-ai-take-my-job - Published: 2025-06-24 - Topics: AI & Developer Tools, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/104544191/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-5-23%2F402687384-44100-2-b1a4ad1aac379.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Jonathan Tamsut, Brittany Ellich, Bethany, and Erika delve into the predictions made by the AI Futures Project regarding the future of artificial intelligence by 2027. They discuss the potential for AI to self-improve, the implications of an AI arms race, and the importance of regulation in ensuring safe AI development. The conversation also touches on the risks of AI misalignment with human values, the future of work in an AI-driven world, and the influence of corporate interests on AI regulation. The hosts conclude by assessing the probability of existential risks posed by AI, known as P-Doom, and the need for a code of ethics in the tech industry. Takeaways * The AI Futures Project predicts significant advancements in AI by 2027. * AI models may train themselves, leading to recursive self-improvement. * Regulation is crucial to prevent potential risks associated with AI. * Misalignment of AI with human values poses serious risks. * The future of work may shift towards managing AI agents rather than coding. * Corporate interests may hinder the safe development of AI technologies. * The concept of P-Doom assesses the existential risks of AI. * A code of ethics for software developers could be more effective than government regulation. * The conversation highlights skepticism towards aggressive AI predictions. * The hosts express concerns about the implications of AI on society.  Links * AI 2027 [https://ai-2027.com/] * Scaling laws for neural language models [https://arxiv.org/abs/2001.08361] * P doom website [https://pauseai.info/pdoom] * The next big idea podcast [https://open.spotify.com/episode/5covw5yaGYbpvGfzawn3rG?si=ins0h0n5TGi5N_fqtuts9g] * The illusion of thinking paper [https://machinelearning.apple.com/research/illusion-of-thinking] Hosts * Overcommitted.dev [http://overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28]  * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com]  * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] * Jonathan Tamsut: https://infinitely-fallible.bearblog.dev/ [https://infinitely-fallible.bearblog.dev/] ### Transcript Jonathan Tamsut (00:00) Hey everyone, welcome to the overcommitted podcast, the number one podcast in the world according to our moms. We discuss code commits, our personal commits and some stuff in between. I'm your host, Jonathan Tamsut, joined by... Brittany Ellich (00:14) I'm Brittany Ellich. Bethany (00:15) Hey, I'm Bethany. Erika (00:16) and I'm Erica. Jonathan Tamsut (00:17) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet and share our learning experiences and discuss our lives as developers, whether you're pushing code or taking on new challenges, we're happy you're listening. Today's episode focuses on AI 2027, a scenario prediction published by a nonprofit called the AI Futures Project. Our goal today is just to discuss the document and talk about the progress of AI and our fears and sort of predictions for it. So as I mentioned, we're gonna be talking about a article that was published I think earlier this year called AI 2027. Before we begin, I just wanna kind of summarize it. So. As I mentioned before, it was published by a nonprofit research group called the AI Futures Project. It was the people who published it were former employees at OpenAI. There's also someone who has experience forecasting. And they make some pretty bold predictions. So we'll throw a link to the article in the show notes, but. Basically, the gist of it is that they believe that we're going to, or I guess they predict with some probability, that there's just going to be a takeoff in AI progress. And I think what's cool about this article is they actually walk you through it sort of step by step. So kind of the key ingredients that they think are important here are know, we're gonna scale AI compute. And so we'll talk about sort of the role of compute in these models. And they believe that the way we're gonna get to this sort of artificial super intelligence, ASI, is through training AI models that act as AI researchers. So there's this sort of recursive self-improvement that occurs. There's some war gaming in this article. So they talk a lot about an AI arms race with China. So, you know, the United States and China are going to be in this, in this report are going to be competing to develop artificial super intelligence. That's sort of not too surprising considering, I think AI could definitely be used as an instrument of war. There's One other, I think, interesting thing about this is they break down AI progress into sort of two parts. One is compute, so just getting bigger computers, training bigger models. And then they also talk about sort of algorithmic improvements. So how can sort of the underlying algorithms improve the performance of these models? We'll talk a little bit about, I'm sure we'll mention the history of sort of algorithmic improvements and stuff like that. And they also, another huge sort of strain or topic in this article is alignment. We'll talk about that. But how do you get an AI to share our values? And there's two endings and I won't, maybe we'll spoil them later, but there's two endings of the slowdown and the race. And basically they sort of describe two different scenarios and one in which. we kind of slow down our AI progress and focus on safety, the second in which we kind of carry on and try to out-compete China. develop a superintelligence that may or may not. So with that, hopefully that gives you little taste of what we're going to talk about. Very lighthearted, fun topics today. So I guess I'll start off. Was there anything that stood out to you guys in this article that you found particularly interesting or anything that when you reading, your mind was blown that you hadn't really thought about before? Bethany (03:38) I think personally it was interesting them coming at it at an angle of these agents are models are training themselves and they're really coming at it from that perspective of a researcher and making the ideal researcher. And then through those parameters, these models that are training could have differing goals from future models or from the humans that are behind it. So I did think that was an interesting prediction or strategy that AI research might take. One thing I did notice was there was a, they mentioned AI models generating content to train other models on, which I feel like is just a big. no-no in AI like training. So I was interested in that there were kind of a little blase about it, Kevin, the expertise in the group that wrote this, but maybe I missed something around that. Erika (04:28) Yeah, I think I'm always very skeptical of any future predictions. But I did find this a valuable read for understanding some of the potential risks. this is kind of like a worst case scenario. They do give. You know, they say like, you the predictions that we make have been supported by like research and, you know, they're not like coming out of nowhere, like they're all possible, but it's a very aggressive timeline. And it's also like dependent on a lot of things happening. I think the most important takeaway of this for me is, well, two things. One, how important it is for regulation in the AI space. A lot of the worst case outcomes here, specifically around the AI intentionally misleading or having nefarious goals. which apparently is already shown to be happening in some models. That was described as something that's an outcome of prioritizing speed of development over safety. So kind of what you were saying, Bethany, adopting some of these not so great practices and maybe they wouldn't do that, but there's nothing stopping somebody else from doing that. Yeah, I mean, you can train your model however you want these days. You can pull data from really anywhere and who's going to stop you. And what's to say, like, you have to prove, you know, how you got that data or like what the training or what the intent is. So, yeah, I mean, honestly, like, I, kind of think that like the AI industry needs to be regulated to a similar degree of financial industry where you have to be able to prove every transaction, prove every, like, you know, every inference, maybe not like to that exact degree, but like, you know, I want to see the intent, I want to see the inputs, I want to see the like thinking, because yeah, I think this is, like this is something that could happen if we don't take steps now to ensure that we're developing this safely. I think the exciting part is like, wow, this stuff is actually possible. This is super cool on a theoretical level if you have this doing the right things, like these sort of like... They call it like geniuses in a data center. Like how cool is that to like have that brain power if it's doing the right thing. But yeah, it's also like super important to regulate it and like make sure that it's progressing in the right direction and that we're like valuing the right things as we go along. And then one more thing. Sort of like on the exciting part, like it also got me thinking of like you know, this idea of like, is AI gonna take my job? Which I think we're gonna talk about a little bit more later, but, you know, they kind of describe like, yes, there will be job loss of like, of in the software engineer world, like writing the actual code, but will become more like managers of agents. And like, I was thinking, I was like, well, it's like a little bit sad because I do like writing code. But mostly I want to be involved in the process and I want to be building things and building cool things. And I don't think that part's going to go away. yeah, I'm trying to adopt that sort of mindset shift of like, OK, it's OK if what I'm physically doing in my job is different as long as the outcome is still the same. So kind of coming to terms with that. Brittany Ellich (08:08) I had a lot of thoughts. reading this as well. There's, I feel like this could be like a four hour long podcast episode of us talking about this. so much. but just briefly, the things that I think are the most interesting from reading this is the idea that we're going to be training models that will train the next generation of models. I don't know if this is, I'm not really, I'm not an AI researcher. I don't know this is already how things work where you train a model and that model is used to train the next level of models. But it seems like it's somewhat of an of an inevitability that eventually we will get to a point where we are building models that are smarter than humans and indeed smarter than like even the smartest of smart humans, which is really interesting. But I also think that there's a lot of hubris associating all of these human traits with these models that we don't have the capability to understand. Like there's this big understanding that they're going to be just as selfish and like self-interested as humans. And so they're going to want to try to, you know, break down the entire world. to build paper clips or whatever it is that they've been given as a goal. And I'm curious. I think that that is, you know, I think that's a big assumption that it's worth ascribing because we can't necessarily, we don't know what they're going to do, obviously. This is a future prediction, but I think that, you know, we're saying that this is going to be, they're going to be very human-like. And I don't know that we can necessarily say that for sure. Bethany (09:25) I think... Jonathan Tamsut (09:25) Yeah. Bethany (09:26) I think those are really, really interesting points. And it got me thinking that like, like the idea of goals. Initially, when I heard about this paper, I was like, I, like, I cannot envision a computer system having goals or having like the desire to go after something. But I do think like to kind of call out to our podcast about thinking in systems, like It is a system, so a system will have goals, whether that's something that is explicitly wanted by the individuals within the system or is given to the system. I think that's kind of where the nuance comes from. But it is a really interesting way of looking at this prediction in paper. But I think really interesting thoughts on the paper as a whole. Jonathan Tamsut (10:11) And I'm, to kind of respond to what all of you said, I mean, I think, so, you know, I think one interesting point that was made is like, training these models is like training a dog, right? I think they drew that analogy because like, you're kind of looking at the output behavior, but you don't truly know what it's thinking. And... they introduced this term called like mechanistic interpretability, right? And so this is something we don't currently have and like no one knows how to do this. So this is the idea of like, you know, can you go into these models and understand them truly like from a step-by-step point? And like there's just, that's like an unsolved research problem, which is pretty scary because, you know, they talk about these models becoming smart, potentially smarter than us, and they can lie and they can manipulate. And that's pretty terrifying. I think, yeah, think the fact that these models have goals is just, I mean, it's, I think it's like sort of a, kind of a deep mystery in the field, right? You know, have these, these transformer, you know, these models are based off this like neural network architecture called transformers that do like next token prediction. And that's sort of the loss that they're trained on. And like from that emergent property, you get these. you know, these goals and this sort of like deeper understanding. So I think that's like really interesting. I'm like, frankly, just pretty pessimistic about, if this, you know, I think, you know, in this article, I think a big unknown is like, there has to be like pretty significant technological advances in order for these agents. I mean, at least, you know, A lot of the research at these research labs at OpenAI and Anthropic is not public for safety and competition reasons. it does feel like we're far away from this. Obviously, this article claims that this is all going to be around in 2027. So guess, who knows? But there does seem to be a little bit of technological handwaving. The other thing I do want to mention, and we'll people posted in the show notes is, know, one thing that this is sort of predicated on is there's a paper published in 2020 by some open AI researchers about scaling laws. And basically there's this like observation that the training loss, so basically like the model performance just improves the more parameters these models have. So basically these models get better the bigger they are. And people think that this is gonna go on indefinitely, you know, there's no reason to believe that this won't stop. And so there's this kind of idea in the field that's talked about, it's talked about in this paper and talked about elsewhere that like, we actually have the knowledge to build artificial superintelligence now, we just need to get bigger models, which is interesting and we'll see. And I think that's sort of been disproven a little bit with chain of thought, but that's sort of an interesting idea here. Erika (12:48) Yeah, I guess the other thought that I have related to what you said is like these technologies only have as much power as we allow them. Like it's similar to like, you know, allowing human power or human intervention. So like giving someone access, elevating them to a place of power or leadership. You know, that needs to be something that we agree on and that we allow. But like once you do, you you have to deal with whatever the consequences are. So like, we're sort of in this transition period of like crazy growth within the AI industry. And we're sort of like giving it access to everything. Like I think of like MCP, which is super cool. But like, Also, it's very permissive and like not really locked down at all. So some of this stuff like, yeah, giving it access to, you know, a system or a network or something like, yeah, if you kind of like carte blanche, give it access to everything. Okay. Then you have to deal with the consequences. but again, like if you take maybe a more conservative approach or, know, like give it access to a more limited scope or take a sort of more skeptical approach of like, okay, well, you know, yeah, like I know that it has this potential, but like, you know, I wanna like think through the consequences and potential implications of like using it in this maybe potentially like high risk scenario. Like, yeah, I think that. we need to also like think through that. But it's, in my mind, it's not really any different than like electing somebody to a political position or like elevating someone to a position of power within a company. Like you're giving them power and like that, that's a choice. And yeah, so like, but like you can also take it away and not saying you're gonna be in the same place you were before you did that, but. Like there are actions, corrective actions you can take on the back end if you end up making a mistake too. Jonathan Tamsut (14:47) Hmm. Bethany (14:48) And I think a lot of that assumes like people purposely putting AI into various experiences. So like, knowingly setting up MCP servers or whatnot. I think there is something to be said to you though about, I mean, even prior to AI, there's computer worms that will like infect your network, infect your devices and stuff. And they're, they're not intelligent at all, but they can spread like nothing else. And so if you add some intelligence to that, I wonder if that. adds complexity to the situation as well and makes it harder to reverse. Erika (15:17) Yeah, that's very true. like, I feel like with any technological development, you have to think of what will happen if this gets into the hands of bad actors. Jonathan Tamsut (15:26) Yeah. And to your prayer, know, one question I think I do have, and you know, I think this is like, no one knows the answer to this is like, is this reversible? I mean, if there is sort of this sentient superhuman system that is far smarter than any human can coordinate with sort of infinite clones of itself. Like, you know, who's in charge at that point? If this has, if this has goals that are distinct from human goals, like You know, if this is out in the wild, maybe, you know, it has some type of physical embodiment. It's in a robot. mean, it's like, well, at that point, I don't know if humans will be able to be like, okay, AI, like go back into the data center. You know, it might be like, no, I don't want to. So I think, I think that is, I mean, I think that is scary. Hopefully far fetched, but I mean, this is, this paper is terrifying. This paper is absolutely terrifying. I don't know if you guys felt terrified reading this. But it's pretty scary. Brittany Ellich (16:19) Okay, I do think that there's an aspect of it that is very scary, for sure. Especially if you take it at face value and you're like, these things are potentially gonna happen. But I mean, you could write that about anything. could be, Yellowstone could blow up tomorrow. And you could write an equally fear-mongering paper about that. Not that I'm saying that this is just fear-mongering, but there are a couple things in the paper that give me a little bit of pause. Like for example, the discussion about the... political implications on the slowdown side where they say, whoever is vice president in 2027 is automatically going to be elected to president in 2028 because of their impact on AI. I'm like, OK, we already know who this person is. This was released two months ago. We know who like this elephant in the room vice president is. We know this person already has a lot of ties to like large tech companies. And it makes me, tried to Google like, okay, who is funding AI Future Project? Like, is there something else going on here to where? Somebody might be trying to put this out there into the world as some sort of like political maneuvering stunt as well. So. Erika (17:23) Did you find anything? Brittany Ellich (17:25) No, I couldn't find anything worthwhile. think it looks like it's mostly funded by Google, but yeah, TBD. But I feel like that in particular gave me a little bit of pause. I'm like, okay, who is trying to scare everybody into thinking that the government is gonna need to step into AI? Yeah. Erika (17:43) Hmm. Jonathan Tamsut (17:44) I should note, JD Vance did publicly claim he read this paper. Brittany Ellich (17:47) Wow. Jonathan Tamsut (17:48) Yeah, mean, you know, it is, yeah, the political aspect of it is pretty fascinating, right? Because, I mean, this is such a powerful technology will become nationalized. has the, you know, it'll, I mean, if it sort of bears out in any way that is similar to what's outlined in this paper, it'll have just profound implications to, you know. our society. I mean, I think even like when you think about software, like I don't even know. I mean, if this pans out, I don't even know if software will exist in its like current form. Like maybe we won't have user interfaces. It'll just be like the single, we'll have like an agent that can book us flights and do everything we do sort of, know, kind of manually. Yeah, so it's pretty. Brittany Ellich (18:37) Yeah, the other thing that I thought was interesting is how the average person's life was described through this and how most people are still gonna be using AI for entertainment. There's gonna be some sort of UBI situation because I mean. You know, there would have to be something, I guess, if there's nobody that's working. Maybe not necessarily. I think there was also a mention that like the Dow would be at one million, which just to me screams of like hyperinflation and like major economic problems. But yeah, think one thing that was mentioned was like, yeah, you'll be able to create like a AAA game with agents in a month or something like that. That's like highly customized to you and all this stuff. like, it sounds like the idea is that like people are, I guess, are just going to be entertained by AI and by like all of the technology and we'll just be chilling, not working, which is also kind of an odd perspective. Bethany (19:33) Sounds like someone watched WALL-E. Erika (19:35) Yeah, I know and like I feel like a little bit of that aspect is misunderstanding how humans work fundamentally. I really have a hard time believing that like we as humans will operate fundamentally differently. I do believe that there's like more potential unlocked by AI. Like I see this as like, you know, sort of logical next step of electronic technology from the internet, Like news consumption as a single viewpoint, right? Like 50 years ago versus today, there's so much more news that you can consume on a second by second basis. And like AI... It's kind of a silly application of that, but yes, AI may unlock even more potential for more information, more content. But at the end of the day, how much news can one person consume? We are still a limiting factor of, I can only read so much, I can only take in so much information. And I also just really have a hard time believing that we can all sit around and be idle and be happy and functioning. Like I truly believe that like we need to be like working. I don't know if that means like we all turn into gardeners or what, like I don't know. Like maybe we all find something more like close to the earth that we do as opposed to like working on technology. But yeah, I really don't, I don't believe that that's going to happen. Yeah, and I kind of feel like the claims that that will happen are sort of misunderstanding how humans work fundamentally. Brittany Ellich (21:26) I think it's basically every software engineer's dream that they want to go live in the woods though and start a farm. So maybe this is finally going to become a reality for some people. I think the news aspect is a very good point though that you bring up. We already know that the media can manipulate people. And when we have AI controlling the media, it can control a narrative and control the way that people act. so you think you can just unplug it, but... If AI is also controlling the perspective people have of AI, then we wouldn't. Bethany (21:58) Yeah, and I think that's, I mean, all of this has been happening for years just due to social media and like various algorithms posing different or like skewing viewpoints and such. So I don't think this is necessarily anything new. It's just more automated. So I guess it makes it easier to do. Jonathan Tamsut (22:17) And to, well, Bethany, to your point, read an, Sam Altman wrote an article that came out on this blog and he said, we already have a great example of a misaligned AI. That's your social media algorithm, right? It is, you know, meant to, you know, engage viewers and get people upset. Erika (22:17) Yeah, and like, sorry. Yeah. Well, and like with the news aspect too, like I'm already very distrustful of like human based news reporters. And like, I take a very critical eye to like any claims or any arguments or any opinions. And like, I basically don't, don't put any credence in like AI generated news as Bethany (22:37) so good. Erika (22:58) as much as I can, you know, spot it or whatever. So like, yeah, I mean, I don't know how many people are the same and how many people are that critical. And not to say that I can't be duped or fooled. I'm sure I'm absolutely fallible, but I'm also like very distrustful of the technology. And I don't think that unless, like you said, there's some... major shift in transparency that that will ever change for me either. It can do amazing things, but until I can ask it and believe what it says when it's telling me where it got this information or why it thinks the way that it does, then I'm gonna be inherently skeptical of the output. Brittany Ellich (23:41) One comment there, and then I swear we can move on. But one thing that I think is interesting is there's also been this shift recently in the last couple years towards video. Like everybody wants to see video. Like even when we were starting this podcast, we were doing some research and everybody was like, everybody wants a video podcast. So I wonder if that part of that is because of that like authenticity you get from seeing like actual people talking. And that's part of like, you people don't want to just read something or listen to something because that's easier to fake than video. Not like you can't fake video. But I'm curious if like, you know, looking for that authenticity has some sort of impact there too. Jonathan Tamsut (24:14) I also think one kind of disheartening thing, at least in the short term, business leaders are already sort of eager to replace humans with AI. This is something like Mark Zuckerberg claimed that 33 or something percent of code at Facebook is gonna be written by AI. If this does sort of pan out, I think there's certainly gonna be a period of like... you know, this awkward period, hopefully a short awkward period of like upheaval where, you know, capitalists are using this superhuman labor. Human labor is obsolete, at least in totally or partially. And we need to figure out like, well, what, you know, how do we, how do we align our species, our society to sort of, you know, give everyone, you know, the ability to live a, you know, fulfilled life and meet their basic material needs. It is going to be interesting to see how this pans out. I'm not super encouraged by the speed at which government adapts to changes, and I hope there's not going to be a lot of pain and unrest. Erika (25:17) Yeah, well, that's that is also a point that's not captured in this article is or article but the report the summary is the is the factor of like corporate greed and corporate interests. It's only really mentioned as like a slowdown aspect of like, well, like corporations might not be able to adapt to the speed of AI research. It's like Okay, no, but there's also a side of it where currently we're seeing, like you said, a lot of tech leaders, lot of corporations stoke the fire and hype this up for the sake of sales or shareholder values or do layoffs because they claim that this is proof of the speed and the progress of AI. And yeah, they didn't talk about that at all in this, but at least currently, it's a major factor in the speed and the growth and the progress. Jonathan Tamsut (26:10) Yeah. And you know, we've already seen it. I mean, I mean, right. There's waymo's driving in Los Angeles that are taking jobs away from from Uber's. And so, you know, I don't know at what point the government is going to have to step in. You know, maybe they'll have to be 10 percent unemployment or whatever. I mean, this is, you know, potentially going to be a massive upheaval that, you know, I hope policymakers are watching and I hope we can sort of navigate. Bethany (26:34) Yeah, I kind of think of the FDA in terms of regulation. At some point in history people were just making drugs and giving them out until there was a regulatory board to say, okay, you have to go through this specific process to make medicine and it has to pass these tests and have to be validated by this board and things like that. I almost wonder if tech is going to go through something similar where more and more technology is vetted through regulatory agencies and things like that. So I think it is an interesting point we're at where there's really not much oversight from the government. And that's helped made a ton of progress, but also at what cost. I think it's a really interesting period and it'll be interesting to see how this kind of causes ripples throughout. history and technology to come. Erika (27:25) Yeah. Brittany Ellich (27:26) I'm pretty skeptical that the government is gonna be capable of keeping up with things just based on what we've seen so far. We already have so much evidence about how harmful things like social media are to the mental health of children, just as an example. There's so much evidence that supports that it is really, really bad for kids' mental health. And I mean, you still have people doing basically nothing about it. And so I think that this is a very interesting topic. I've heard the idea floated around a little bit about a code of ethics for software technologists. And I think that would be more successful than relying on. the government to step in. Like I think that there is a really fantastic opportunity here for people who build software to come together and regulate ourselves in some sort of meaningful way, kind of like, you know, like doctors have like the Hippocratic oath that they have to, you know, meet. I feel like that is gonna, that's not necessarily more likely, but probably gonna be more successful than relying on the government for regulation, because it just moves too slow. Erika (28:25) Yeah, I think that's fair. And you also have to think of the motivations. Like, okay, why has there not been any social media policy enforced? We've seen Mark Zuckerberg on the steps of the Capitol. We've seen lobbyists, they're putting money into this to prevent it. Until that stops or until somebody steps in with more money to... fund the opposite side, it's not gonna happen. yeah, think you're right that we've seen great success in open source communities. It always blows my mind that there's some of these amazing groups within technology that sort of self-form to, yeah, to... to enforce certain standards on their own. And I think you're right. I think that's a probably better place to put our focus because otherwise we're probably gonna be kind of shouting into the void and yeah, hoping on something that's like not gonna happen. Yeah. Cause I mean for, yeah, for, both reasons, like you said, like on the one hand, a lot of these like legislative bodies don't even know how to regulate these technologies. And that's not to say that it's an easy question to answer. Like, you know, it's also hard for me to even say like, what would regulation look like outside of sort of some of those transparency aspects. But yeah, I think the researchers themselves or the technology community are gonna have a better idea of that. also, yeah, it sounds a little altruistic, but probably have purer motivations outside of whatever's motivating Washington these days, which is probably money and lobbying and... power and self-interest. I wouldn't necessarily, Zan's very sort of skeptical of me, but I wouldn't necessarily think that anybody would be motivated to do that, but we've seen it in aspects of technology, especially web technology, so I do believe that it's possible. Jonathan Tamsut (30:36) I don't know if you guys ever, sometimes I like going on YouTube and watching mashups of these tech CEOs at congressional hearings and having, just seeing Congress people ask them totally nonsensical questions, it's really funny. And then you kind of just see their response. It's also like maybe, I think it is heartening and I think it is a good thing that there are multiple companies doing this. I mean, if this was just Google, so hopefully these companies can... kind of counterbalance one another in some way. But I guess sort of the converse to that is now they're sort of incentivized to compete with one another and race towards market dominance, which may have a deprioritized safety. Okay, well I think it's time for our fun segment. And I thought for our fun segment, we can all go around and we can talk about our P-Doom. So P-Doom is a term in AI safety that refers to the probability of existentially catastrophic outcomes as a result of artificial intelligence. So basically, what is the probability of AI basically killing us all. So it's the number between zero and one. There's actually a website, we can link it in the show notes with sort famous AI researchers listing their PDOOM. So you can provide a number or you can provide a range and maybe an explanation. I can start. Yeah, I'm really, this is totally not super well informed, but I'll say my PDOOM is between point. 1.5 and 0.25. I think maybe, you know, I think there's, it's possible we're in a hype cycle and there's gonna be difficulties employing this technology. think that's probably, you know, until I'm proven wrong where I stand, but definitely if these, you know, these sort of technological advances come to fruition, that's pretty scary. Erika (32:18) Sorry, I thought you said from zero to one. Jonathan Tamsut (32:20) Yes, so from 0 to 1, so I said 0.15 to 0.25. Erika (32:21) Sorry. got it, okay. My brain was filling in the numbers wrong. From zero to one. Yeah, I haven't thought about this very much, but... I think I'd probably land around like 0.2. Yeah, like I think it's possible, but I think that there's a lot of mitigating factors and I don't necessarily think it's likely. Bethany (32:44) I'm gonna say for me it's probably like more like .01. Like I... We've survived this long. I'm not confident that AI is gonna be our downfall. Call me a hater, I don't know. I... Like never say never, which is why I would say .01, but I highly doubt this is gonna be our downfall. But yeah. Hopefully the world does not prove me wrong there. Brittany Ellich (33:06) Yeah, I would say I'm probably at about a .05 to .1, maybe a little bit less confident than Bethany. But, you know, I think... These, it's gonna evolve and there's the possibility that it'll go crazy, but that's also, you know, assuming that we aren't able to make changes along the way if we see things heading that direction. And I feel pretty strongly that humans want to continue living. So just like as a collective species, typically. So I think that if something big does come up, then we'll prevent it. I think it's also important to say that one of the guys that wrote this article, his P-Doom is 0.7. which is also good perspective under which you read the entire thing. Bethany (33:47) think we can guess which outcome he chose to hire in the reading. Erika (33:51) Yeah, I'm also curious what podcast you listen Jonathan Tamsut (33:53) Yes, well I hope he's happy. Erika (33:55) Brittany was saying that she listened to some podcast interviews and stuff like that with the authors. And, I'd be curious, maybe you can link those out to, to, hear some of those and find out more of their perspective. Brittany Ellich (34:07) Yeah, I'll share the next next big idea podcast. And I'm also going to share in the show notes the Apple paper that just recently came out. We can probably do another talk about that because I've heard it's sort of like a counterpoint to this. That's a little bit more. Not balanced necessarily, but the different viewpoint of I think it's called the illusion of thinking, so I'll share that as well. Jonathan Tamsut (34:27) I read that paper yesterday and I have a lot of thoughts on it. Yeah, I think that would be an interesting idea. I mean, there's kind of the question of like, do these models actually reason, have like generalizable reasoning skills? And there's kind of controversy there. But yeah, pretty fascinating stuff. Thank you all for the great discussion. It's always nice to hear your perspectives and I appreciate that. So without further ado, I thank you listener for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky. and share with your friends. Until next week, bye bye. --- ## Episode 12: Ep. 12 | Maximizing time at tech conferences and events - URL: https://overcommitted.dev/ep-12-maximizing-time-at-tech-conferences-and-events - Published: 2025-06-18 - Topics: Developer Experience/DevRel, Career Development, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/104149543/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-5-15%2F402185733-44100-2-5904f2d76d2c.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Brittany Ellich, Jonathan Tamsut, Bethany Janos, and Erika discuss their experiences with tech events, including how to choose which events to attend, strategies for networking, maximizing time at conferences, and the value of speaking and volunteering. They share personal anecdotes and tips for making the most out of these opportunities while also addressing the challenges of social anxiety and the importance of setting boundaries. The conversation wraps up with some light-hearted unpopular opinions about tech events. Links * ⁠Gophercon [https://www.gophercon.com/] * Microsoft build [https://build.microsoft.com/en-US/home] * All things open [https://allthingsopen.org/] * Defcon [https://defcon.org/] * Epic Web Conf [https://www.epicweb.dev/conf/2025] * GopherconEU [https://www.gophercon.eu/#/speakers?lang=en] Takeaways * Choosing the right tech events is crucial for personal growth. * Networking can be approached with prepared questions to ease anxiety. * It's important to recognize that everyone at events wants to connect. * Setting boundaries at conferences can help manage social fatigue. * Leaving a talk that isn't engaging is perfectly acceptable. * Collecting swag is a fun part of attending conferences. * Speaking at events can provide unique opportunities for travel and learning. * Volunteering at conferences offers valuable insights into customer perspectives. * Finding a balance between attending talks and networking is key. * Enjoying yourself at events should be a priority. Hosts * overcommitted.dev [overcommitted.dev] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] * Jonathan Tamsut: https://infinitely-fallible.bearblog.dev/ [https://infinitely-fallible.bearblog.dev/] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments, and some stuff in between. I'm your host this week, Brittany Ellich, joined by... Jonathan Tamsut (00:10) Jonathan Tamsit? Bethany (00:11) Hey, I'm Bethany Janos. Erika (00:12) And I'm Erica. Brittany Ellich (00:13) We are software engineers who initially met as a new hire group at GitHub and found a common interest in continuous learning and building interesting projects. We continue to meet and share our learning experiences and discuss our lives as developers. So whether you are pushing code or taking on new challenges, we are happy you are listening. Today's episode focuses on tech events, how to decide on which to attend, what our experience has been at them, and how to maximize your time at them. And as a bonus, we'll also talk a little bit about speaking or volunteering at these events. So these events, just as an aside, include things like conferences, but also meetups with your own team. If you are a remote company and you sometimes go to an offsite, then that, I feel like, falls into this category. And then also just general meetups in your area. So let's start. by talking about how you decide which events are worth your time and that you want to go to. Erica, do you want to go first? Erika (01:08) Sure, this has been top of mind for me because I am deciding whether or not to go to GopherCon. It switches coasts every year and this year it's on the East Coast and I'm based on the West Coast. So it's a long way to go, but I really did enjoy it the last time I went and... I'm trying to decide whether the benefits primarily in networking and what I would get out of the conference sessions would be worth it. I am interested in getting involved in Go Open Source, but I also know that so much of Networking happens online and in slack and I definitely don't need to go to a conference to get involved in open source so that it's the benefit of having a good time and Being in New York and seeing people and meeting people in real life So those are kind of the trade-offs and the way I think about What's worth my time and not I I also thought about going virtually, but it's almost equally hard to make time for attending virtual sessions. Something about being there, you block off the time and really feels like you're making a commitment versus trying to sort of tune in on the side or something. So that's generally how I think about. how to spend my time at tech events. Jonathan Tamsut (02:32) So this may be just the most programmer introvert question, but how do you guys network? Because I was recently at a conference and I'm like, I don't think I'm an introverted person or extremely introverted. I'm like, how do I network? Do I just go up and talk to people? Which I guess I feel comfortable with. I don't know if you guys have strategies or mindsets. It can feel sort of just like kind of random. Like you're just kind of randomly bumping into people and chatting. But I don't know, do you guys have any like mindsets when networking or strategies? I also just don't like the idea of fully transactional interactions. Sometimes I just want to talk to people and maybe you can get nothing out of it, maybe just get to know someone. I don't know, what are your guys' thoughts on our approaches to networking? Erika (03:21) I try to avoid the small talk questions of like, where do you work? Where are you from? Cause I feel like those don't build as much connection versus trying to connect about things that we might both be interested in. So if I go to a conference or an event, like say I go to GopherCon, like I more likely ask people like, so how do you use Go? Or like, what are you interested in? Like, what are you here for? what are you hoping to get out of the conference? Those kinds of questions. But yeah, generally I am more on the introverted side. So clearly I think ahead and have questions prepared instead of vibing it out. Jonathan Tamsut (03:57) See ya. So good to have canned questions. Brittany Ellich (04:03) I usually do stick with some of those. small talk type questions. And I think one of the things that really helped me is understanding that every single other person there also is down to talk. Like nobody would show up to a conference or a meetup or anything if they're like, I don't want to talk to anybody. So knowing that everybody else probably wants to start a conversation too, I think is really helpful. So yeah, I usually just go up to anybody who doesn't look like they've been talking to anyone and say, hi, I'm Brittany. Who are you? Why are you here? And then, you know. Go from there. And it's worked pretty well for me in the past. Bethany (04:32) I struggle a lot with social anxiety so I relate to this question so hard, And I still very much struggle with just approaching people randomly. Like if there's an inn, I I staffed a booth at Build for GitHub this past month actually. And that was fine because there was an inn already. Like people were approaching me and I'm great when that happens. But I am bad at approaching other people. So, okay, I struggle with it. I shouldn't say I'm bad at it. I'm working on it. One thing, my husband, shout out Bobby. Jonathan Tamsut (04:52) Thank you. Bethany (05:02) would, told me, or gave me an advice on at, I think I was at All Things Open a couple years ago. And he was like, well, why don't you just go up to the vendors? It's their job literally to talk to you. And so I'm like, what if they think I'm dumb or stupid? it's, but they're kind of there to push their products on you. I mean, what, how dumb could you really be? And that's a new idea. So. I found that helpful as like a warm up almost of getting used to talking to people or going up to people. And definitely applied that at DEF CON last year, that was really helpful. So looking forward to doing that at other conferences for sure. Erika (05:37) you I also sort of yeah, make it a point to like have number of connections as like a metric for my own success at a conference. Like if I don't tell myself like I need to exchange LinkedIn information or like, you know, contact information with like at least, you know, fill in the number, like depending on how ambitious I'm feeling, like three to four people for the day. Like I am absolutely one of those people who would like show up to a conference and not talk to anybody. So, yeah, that's another way to sort of like force myself into that mindset. Bethany (06:13) I think one thing to also call out, because I was the same way kind of during the copilot offsite in terms of like, want to meet everybody, want to collect everybody's like information and get to know people. And it was great, but I got so tired after the first two days and like the last two days I was a shell of a person. So I think it is important also to set boundaries. It's okay to... sit in your hotel room for an hour and not talk to anyone. It's okay to just be in a corner and just be. That's okay as well. So I think it definitely goes both ways, but I'm definitely taking that tip of having little metrics for yourself to encourage yourself to get out of your comfort zone. That's awesome. Erika (06:54) Yeah, well, guess it works the other way too, where you can say like, hey, I've talked to, you know, three people. I don't have to talk to anybody else now. So, I guess it works for the boundary setting too. Jonathan Tamsut (07:04) I'm just kind of laughing at this mental image I have of you, Erica. Just like walking up to someone and then like kind of looking down at like maybe like a piece of paper and just asking them like a really detailed, inorganic question. You know, that's like obviously been scripted. Bethany (07:17) Okay, maybe I'm over-engineering this, but I'm like, you can have a QR code that people can scan and you can track metrics. ⁓ Brittany Ellich (07:18) Checking a box. Jonathan Tamsut (07:19) Yeah. Yeah. Brittany Ellich (07:28) I think there are whole businesses built around that, about like, lead gen and stuff, but that might come off a little bit less genuine. Erika (07:35) Yeah, I'd like to think I have a little more tact than that and hopefully, yeah, usually it goes pretty well when I start with my questions, but you can also tell if somebody's wholly not interested and then you stop and talk to someone else. Jonathan Tamsut (07:38) Yeah. Brittany Ellich (07:50) I think it really depends on the event too. I think that there are some events that are just much better for going to go meet people at. Like for example, I've gone to a few conferences now. I went to Epic WebConf in March this year and I have never had a better time like talking to people. That was a great conference to go to meet a ton of people that were all down to talk. So that was great. think also when it comes to like local meetups, I've started going to the PDX code and coffee and I think having something that is less, I don't know, less, there's less stuff going on. Like it's not like you're going to see a talk or something like that. Everybody's just meeting to hang out and it's super casual. think those are way better events for meeting people than if you go and sit at a talk and then sit at a talk for 45 minutes and then everybody's like, well, all right, we're gonna go for the day. It's nice to see you all. So I think that the type of event, if you're trying to meet people is really important. Jonathan Tamsut (08:41) And to answer your original question, Brittany, I think you asked like what conferences are you interested in going to? I think one conference I have my eye on is Norex, which is like maybe a little bit more of like a researchy conference, but I think like, I think I would learn a lot. And I think I'd just be exposed to a lot of like ML research. I mean, it's basically like a, you know, ML research. conference where people are presenting research, lot of deep learning stuff. I think that be cool to go to. That's a conference where I think in terms of learning, that would be really cool. I imagine there would be cool people to meet. it is interesting to think there's some conferences that are maybe more social oriented. There's some that where the focus is more on learning some kind of better combination. Brittany Ellich (09:29) agreed the type is very important. So we already sorry go ahead. ⁓ Bethany (09:32) I think. sorry. I think you all kind of covered the general basis of how to choose conferences or whatnot. It's usually kind of a mix of applicability to your field and whether talks sound interesting or the people there might be interesting to network with. I will say a lot of having a partner in tech, a lot of times I'll just will choose it based on, you're going to this conference, sure, I'll join you. Which is how I ended up going to DEF CON. last year, I'm not a security engineer by any means or a hacker, but it was so much fun. I was so surprised by that. There was so many opportunities to like hack on things, even though I didn't have previous experience. Lots of really cool groups, like there was a little women's meetup that was fun to attend and we made friendship bracelets, which was really fun. So I think. Sometimes I'm surprised by how much I like a conference that I wasn't expecting to like, just purely because I'm like, yeah, I'll tag along to this conference and it ends up being an absolute joy to go to. Brittany Ellich (10:35) That's cool. I don't think that my husband would be very interested in going to the conferences that I go to. Maybe. So we already sort of talked about the networking side of things, but how do you maximize your time at these events? Are there any other tips or anything that you recommend to anybody who's going? Jonathan Tamsut (10:54) This is maybe sort of a negative thing, but I do think you should allow yourself to leave talks. Like if you're sitting in a talk and maybe you feel like it's not, you know, it's not really like worth your time. I do think that very politely and discreetly leaving, I think is okay. You know, as I mean, I guess if it's like a really small talk, maybe you're stuck there because you don't want to, you don't want make the the speaker feel bad. Or maybe, I don't know, maybe you don't care. That's kind of up to your individual discretion, but I think in sort of these big conference rooms you should be able to... Erika (11:22) I totally agree. Because I think there's like an idea of like really engaging with any talk that you are attending. And I think especially when you get to that point and you're tired and maybe like overstimulated or something like that, like it's really easy to tune out and I think at that point you are wasting your time and it's better to like step away, take a break, go get some water, get a snack, get some swag, whatever you need to do to kind of like refresh and then come back. Because yeah, ideally at least conferences I feel like... the talks are a big part of the draw and like I like taking notes during the talks, not like exhaustive notes, but you know, sort of like active listening notes to make sure that I remember the key points and stuff like that. Yeah, and then it's also like a good opportunity to talk to people afterwards about what you listen to or about the different talks if you found them engaging and that's another networking opportunity. Yeah, I guess also... Sometimes people who do the talks also are interested in having follow-up conversations. So if you found somebody's talk particularly interesting, you can always go up to the speaker too and talk to them about what they talked about. And that's a great opportunity to make a new connection and also maybe learn something more that they didn't include. Jonathan Tamsut (12:55) I think Erica also made a really vital vital point. Conferences are often about collecting swag. I love free stuff, I'm sure you do too, listener. So just make sure you visit every booth, get every swag item. I think some people feel shame or bashfulness, but it's there for you. Get the socks, get the hoodies, get it all. That's something you should not miss out on. Bethany (13:18) I can confirm as somebody who's staffed a booth, we are trying to get rid of these things, so definitely don't feel ashamed doing that. But yeah, I feel like for me, I do like taking a look at the schedule. I think like some people are very anti going to talks. like, I'm just about the hallway track. And then some people think, you have to go to the talks, which is also not necessarily true. So I think it's a mix of both and really like balancing your time. I think one thing that's important is Are these going to be recorded and posted? If there's something that you're kind of interested in and it's going to be recorded, then I'd say you can feel freedom to skip that. Or if you're just about to go into a talk and you're like, I don't know if I have the mental energy to do this, if it's recorded, then you can give your elic- give yourself grace, like allow yourself to tune out a little or come back to it later when you're feeling more up to it. So I think that's always good to keep track of. If it's not gonna be recorded or it's more like small group interactive, I think I'll definitely spend more time or prioritize it a little better. But I think it's all about kind of balance and what truly will benefit your attendance. with the energy and time you have. Brittany Ellich (14:33) Yeah, I almost always try to plan ahead a talk that I'm planning to skip, especially if it's recorded, and then go back to the hotel if possible and take a nap. Especially if it's a really long day with a ton of talks and then there's like some social event in the evening, which a lot of them will have, having time, especially like usually like right at that after lunch spot is just the perfect time to go power nap and just like decompress a little bit and be alone. That said, I'm also preparing for GopherCon EU next week, and I I have the first talk on the first day that's right after lunch, so don't skip that one. But, just kidding, you can't, it'll probably be recorded. But, you know, I think that's usually a good time to like take a breather, and that's really helpful for me. Jonathan Tamsut (15:11) I also think one other thing is like, you know, there's different conferences. I think conferences that are held by companies, I mean, what is the value proposition for a company? It's sales, right? They're selling you stuff, whether it's their software or cloud services, et cetera. I think that I naturally just don't like being sold to. It kind of grinds in my gears. And so, know, I think, right, like, keep that in mind, you know, there's, maybe the talks will be less interesting. I don't know, you know, and, you know, maybe they're going to be going over sort of, you know, the minutia and small features of their product line in order to sort of, you know, that, that would be interesting for maybe a potential customer, but like not for you. So I think like the distinction between conferences that are, you know, run by corporations and are basically meant as ways to generate. revenue for the company and interest for their products versus conferences that are just about a topic and they're not trying to sell you anything per se. It's just people who are interested and maybe they're trying to further community building and stuff like that. So I think that's a really important distinction. Erika (16:23) And like, you bring up a point that made me think of how we started this conversation of how you decide to even go to a conference or not. And the thing that I mentioned was fun, having fun. And I think that that is a way to judge whether or not you are. using your time effectively at a conference. The question of, I enjoying myself? Am I having fun? Or whatever it is that's your goal at that conference. Maybe your goal is to get a job or really learn as much as you can about something. But yeah, whatever that is, connecting with that throughout your time I think is a way to make sure you're staying aligned. Brittany Ellich (17:01) Agreed. Yeah, and so Erica, you kind of touched on this a little bit earlier about with taking notes, but how do you approach turning the learnings into action when you return if you're listening to a bunch of talks in one day? Erika (17:15) I feel like I always get itchy when I'm at a conference and I want to do everything and hack on everything when I'm there. So it's true. You have to be there when you're there and then follow up after. And yeah, I think having those notes... is helpful in prioritizing what you want to learn more about or follow up on and then having some kind of practical application for it, whether it's a project or a blog post or something, something that caught your attention and you want to dig into it a little bit more. Yeah, like maybe choosing a few things that you really want to focus on and then applying that to something that you do after. Jonathan Tamsut (17:58) think here, conference choice is a key aspect. Like, I, we, had a coworker, uh, Rob, and I remember he went to GopherCon and learned about, test containers. And that was, like, directly relevant to, you know, we we were all Go developers building a Go service, trying to make our tests better, more robust. And, you know, he came back and was like, Hey, like, I learned about this thing. This is helpful. We like, you know, implemented it and, you know, we added it to our code base. And so I think, like, you know, go to a conference that is related to what you're currently working on is one way of just integrating the knowledge. Bethany (18:33) Yeah, I agree completely. think there's always going to be things that spark your interest and you should definitely write those down in the moment, at least like if in the case of test containers, like, this could do this and that would be a good idea to go off to. I know my husband, we went to All Things Open and he was learning about Othel and he ended up taking that with him to his company to like kind of start seeing if they could integrate into Othel. And this might be a little less relevant relevant to big conferences and more relevant to like the offsites and the meetups, but I think also relationships can be a tangible outcome from these events. I know with the past couple events I've been doing like my copilot offsite and Microsoft build, I actually got to spend so much time with people that I don't tend to work with very often or didn't know at a personal level. And that made things so much easier to approach them in the future and built some really solid friendships as well. I think also just making sure you're keeping up connection with people that you meet at these conferences who you really want to build a connection with. I think that's also really valuable. Brittany Ellich (19:38) I love that. All right, and then I also wanted to talk just a little bit about speaking and volunteering for conferences or events and what your experience is with it and do you recommend it, which ways are there to do that to get involved? Erika (19:51) feel like you have the most experience speaking. Brittany Ellich (19:53) Fair, can talk a little bit about speaking. I actually haven't done a ton of speaking events, but I will say that speaking is a really fantastic way to get to go to conferences that you might not get to go to otherwise. I was on Bill Kennedy's podcast earlier this year, and he's the one who actually recommended, I told him, my brother's in Berlin, I'd love to go check that out. And he was like, hey, you're in to go, go for Connie, he's gonna be in Berlin, you should check that out. And so. I like, yeah, that's actually great. So I applied and ended up getting chosen to speak at it. So that's how I'm going to get to go to Berlin next week, which is really cool. So it's a great way to travel if that's something that you're interested in. Bethany (20:26) I think from a volunteering perspective, it's probably a little different than speaking and your attendance is probably a little different than a regular conference attendee because you do have to staff a booth for a certain amount of hours and be available for people to approach you. I do recommend it. I think personally, it was great to chat with customers and get their insights and feelings around Copilot. And it was really exciting to just understand their perspectives. And as an engineer, I think that's super valuable. We don't often get face-to-face interaction with customers. So I thought that was really cool. I will say it was a lot, especially as an introvert. I was very drained most days. And it's not like you can really attend if you're depending on your schedule. You can't attend like a bunch of talks or whatnot. So that's a downside. But I think the person, like being able to interact with people aspect was so valuable. So I do recommend it. think you should understand if you want to benefit more as an attendee or volunteer definitely before you necessarily sign up for that if you're planning on going as an attendee. It's a very different experience. So definitely understand that about yourself, but definitely recommend. Jonathan Tamsut (21:32) I also like the idea, I've never volunteered at a conference, nor have I given a talk. But I do like the idea of giving a talk in that you kind of like, like in an ideal world, you get to think really deeply about a topic and then like present it, present your perspective and to like a wide range of people. And then like maybe like attract people who are also interested in what you said or it resonated with them in some way. So it's kind of a way of just like meeting people who have similar interests or even have like interesting thoughts on topics that you also have. So I think that's cool. Erika (22:09) Yeah, I theoretically love the idea of speaking, but I also know that public speaking is scary to me. But the flip side of that is I know that it only gets better the more you practice. So it is a goal of mine to do that more and get out there and get more. get more practice, get more comfortable with it. But yeah, I haven't. Outside of like internal presentations, I haven't done any talks. So I'm inspired. Brittany Ellich (22:41) Finally, this has been a really good conversation. It's fun to hear about everybody's different experience with different events. That's been great. So let's move on to our fun thing of the day. And I have been... listening to a ton of Go Time recently, old Go Time episodes, and I have been really enjoying it and miss it, wish that they were still doing it. And so I thought that it would be fun to do some un-pops at the end of this one because you know what? That was one of the best parts was everybody's unpopular opinions. So you can have an unpopular opinion about, you know, about conferences specifically or about, you know, about anything. And I'll start so that you all have a moment to think about something. But my unpopular opinion about tech events is that I don't really like... At conferences, I enjoy going to talks, but I hate meetups that have talks. I think both as somebody who's previously organized them, because it's extremely difficult to continuously organize meetups with talks at them, but also as... somebody who goes there and wants to meet people, it's a terrible way to meet people, to go to a talk. Maybe if somebody really interesting is there, but it's just, it's really hard. So that's my unpopular opinion and I just don't go to those anymore as a result. Bethany (24:01) So mine is that stickers are dumb. Stop handing out stickers, please. I think this is an unpopular opinion because people at Microsoft build love the stickers and I was just like, why? Where are you going to put them? They feel like waste of paper. Like if I put it on my laptop, it's there forever. So I just can't do stickers. Yeah. Yeah, I actually did get a case for my laptop. was like, maybe I'll be a sticker girly one day, but I still have not stuck anything on it because I can't commit to anything. So, yeah, that's my unpopular opinion. Erika (24:33) Yeah, that's gonna be hate mail inducing, I think. Jonathan Tamsut (24:34) Bye. Yeah, Bethany (24:40) I did, Jonathan Tamsut (24:41) we just lost half of our listenership right there. Bethany (24:44) so we have like two people now. Just our parents again, man. Brittany Ellich (24:46) Ouch. Bethany (24:49) I will say, I like, this is a little embarrassing, but I did come up with that a long time ago because I was like, if I'm ever on GoTime, I need an unpopular opinion to have, so I'm glad I finally got to use that one. Jonathan Tamsut (25:03) I would say, yeah, I am a related one. I don't like kind of low quality swag. It feels overly consumeristic, if that's a word. Like, you're just kind of, know, like, this, you know, this is probably gonna end up in a landfill, like choking a sea turtle, you know, maybe, maybe. you know, less swag, but higher quality things that people will use. And yeah, I mean, stickers on a laptop, I think it's just hideous. I also, stickers on a car, like sometimes when people have a lot of bumpers, even if they're funny, like sometimes I look at, think that I've seen actually a lot of funny bumper stickers recently, this just isn't a side. But I think when you have too many, it's like, you're just trying to, like, you know, you're just like, what are you trying to communicate? Like, who are you? Like, are you just trying to show off who you are to everyone? It's like in traffic. I don't know. Yeah, I'm not. It's kind of a peep. Erika (25:52) Well, Isabelle's definitely going through a sticker phase, so anything that you don't want, can send to me and I will give to her. She'll put them on her hands, face, whatever, doesn't matter. toddlers are another use case for stickers. I'm not sure if this is unpopular or like something that everyone holds or something that is gonna make me sound like a bad person, but I'm gonna use this that I think at any meetup I've been to there's always been like one person that I like really don't want to talk to ever again. I think especially when I go to more tech meetups instead of software developer meetups. But even still, I've had this experience pretty consistently where I'll have a fairly enjoyable to like... very enjoyable conversation with like a majority of the people and then there's like one person in the room that I'm like I actually don't want to talk to you ever again like please stop talking about blockchain and like please never contact me. Brittany Ellich (26:56) It's very valid. Now every meetup you go to, somebody is going to be wondering if they are that one person. Jonathan Tamsut (26:57) I Erika (27:00) Is there that Jonathan Tamsut (27:02) I do especially dislike the person who feels like their sole goal in conversing with you is to show off how smart they are. It's like this isn't really relating, like cool, but this is not a real human relationship. Just yeah, you know, there's, yeah. Brittany Ellich (27:15) Like people who don't ask you questions in return, I feel like that's a really, it's very easy to like have a conversation. So if you ask somebody a question, they ask you a question, but then there's a lot of people that you interact with that you just like ask them questions and then they answer and they're just like, you get nothing. So. Erika (27:29) Yep. Brittany Ellich (27:30) Also a tip on how to talk to humans. Erika (27:33) I want to talk to you. Jonathan Tamsut (27:34) which surprisingly, I'm sorry, I was just gonna say, a surprisingly large number of people have struggled with. I feel like not to be more controversial, but I feel like maybe at a tech conference, sometimes it feels like there's a lot of people who are not great at that. Brittany Ellich (27:34) Well, this is... Erika (27:49) Fair. Brittany Ellich (27:49) The remote tech world, I am also guilty of that. am extremely awkward in person. Who isn't though? Everybody feels like that. Well, this has been great. Definitely if you have a favorite event, tag us in it online because I'd love to hear about it because you know obviously we're all looking for more events to go to. Thank you so much for tuning in to Overcommitted. If you like what you hear please do follow, 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. --- ## Episode 11: Ep. 11 | Thinking in Systems - Book Club Recap - URL: https://overcommitted.dev/ep-11-thinking-in-systems---book-club-recap - Published: 2025-06-10 - Topics: Productivity & Learning, Technical Deep Dives, Leadership & Management - Audio: https://anchor.fm/s/102586d64/podcast/play/103777870/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-5-6%2F401723611-44100-2-dc0bbc7de16e.mp3 ### Show notes Summary In this episode of the Overcommitted Podcast, hosts Bethany, Brittany, and Erika discuss their experiences with the book 'Thinking in Systems' by Donella Meadows. They explore the concepts of systems thinking and its applications in software engineering, team dynamics, and societal issues. The conversation delves into the importance of feedback loops, user experience, and the impact of organizational structures on individual performance. The hosts also reflect on their book club experience, sharing insights on how to foster engaging discussions and learning opportunities. Links * Thinking in Systems⁠ [https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557] * ⁠The point of the system is what it does - Anil Dash⁠ [https://www.anildash.com/2024/05/29/systems-the-purpose-of-a-system/] * Just for fun⁠ [https://www.amazon.com/Just-Fun-Story-Accidental-Revolutionary/dp/0066620732] * Changelog episode about COBOL⁠ [https://open.spotify.com/episode/3ufxSsBV1SuffrHrXbXBoS?si=784b9e403f2040fa] Takeaways * The book 'Thinking in Systems' is approachable and easy to read. * Systems thinking can be applied to various fields, not just software engineering. * Feedback loops are crucial in understanding how systems function. * Understanding the goals of a system can help identify problems. * Organizational systems can be challenging to change compared to software systems. * The book club format enhances learning and engagement. * It's important to recognize the motivations within a system. * Technical discussions can be enriched by diverse perspectives. Hosts * overcommitted.dev * Bethany Janos: https://github.com/bethanyj28 * Brittany Ellich: https://brittanyellich.com * Eggyhead: https://github.com/eggyhead ### Transcript Bethany (00:00) Welcome to the Overcommitted Podcast, where we talk about our commits, our commitments, and some stuff in between. I'm your host, Bethany. Join this week by my fellow code enthusiasts. Brittany Ellich (00:09) I'm Brittany. Erika (00:09) And I'm Erica. Bethany (00:10) We're a crew of software engineers. We first connected as an onboarding group on the same team in GitHub Actions and quickly discovered our shared passion for learning and building cool stuff. Even though we've scattered across different teams now, we still come together regularly to geek out about technology, share what we're learning, and explore our life as developers. So whether you're committing to code or committing to new challenges, we're glad you're here. Let's dive in. So at GitHub, we've been doing a book club for basically since we started, I feel. So for about three years now. And we've recently wrapped up the book, Thinking in Systems by Danello Meadows. And I thought it might be fun to do a little recap on the show. So really excited that Erica and Brittany were able to join today because they helped host this book club. I think actually it was maybe... Erica's idea? Or Brittany's idea? I can't remember. Anyways, let's first get some general thoughts of the book. So like, what did you like? Was there anything you disliked? Maybe how it might impact your day to day or if there were any surprises. Brittany Ellich (01:10) What? One thing I really liked about this book is how approachable it was. I think that this was a very easy to read book and I have transitioned to mostly listening to audiobooks for any technical books that I'm going through and I was able to listen to this really easily and keep up with it. So it's a really great approachable book for anybody who, you know, might not love the idea of going through technical books but wants to keep up to date on something. Erika (01:36) I had a similar thought. and specifically, I really liked how the book gave really concrete examples of every concept that she talked about. And this was not a purely like technical book about software engineering, but it was explained so clearly that you could easily apply it to software engineering. And all the concepts were, really applicable across a variety of a variety of spaces so it was really fun. digging into everything from distributed systems to team processes to social applications and politics. You could take one of the concepts that she talked about and fit it into a bunch of different scenarios and it still held true. So that was really fun to... build a new mental model using the concepts that she introduces in the book. Brittany Ellich (02:34) I think the only thing that I might have disliked about it is I felt like there, I feel like I've seen this recommended a ton for software engineers, but there are very few times that she actually does provide any technical software engineering related examples. And I don't know if maybe that's, I know that I think she has a software engineering background and it was supposed to be like a, you know, a book to support technical systems. could have used Zarr. But then we had the book club to talk about it, so it wasn't really, you know, it wasn't a huge miss. Bethany (03:01) that's interesting. I would not have imagined that there was any software ties to it. I thought the same going in, like that it was a book on systems within the context of software. So I agree that definitely surprised me that it was not really about that at all. But I thought in a way it was really cool to map these general systems concepts to software in a way. So there was a lot of I feel connection between how systems operate and, for example, like a distributed system for how it self heals or how it delegates tasks and such. So I thought that was really interesting that clearly this methodology transcends just like social communication or like social groups and really does impact or is like a success. for software as well or how to design effective software systems, which was really, really cool to see. Erika (03:55) Yeah, I agree that it would be fun to have a follow-up to this book that is specifically about software because I could apply it to the concepts that I did know about, but some of the concepts that I don't necessarily know about, like I'm thinking like lower level things like CPU constraints, like memory constraints, like it'd be really fun to like have somebody who really understands like bare metal software and like computer systems to, you know. like give their perspective on some of these systems, designs, concepts, and the traps that you can fall into. Yeah, I think for me it was like, I agree, was like learning about how to build a mental model of a system and like in some ways it's good to have that skill as well because... part of software design is understanding how to apply or like represent real world concepts in code. But as far as like really improving my engineering chops, I'm not sure this book necessarily was helpful there. Aside from like being able to break down problems, which is kind of an answer to your question of how it's impacting me, because I now think of systems whenever I approach something that I don't understand. So some of the concepts that she introduces in the book are stocks, which are your resources, and then flows. which is how those resources are changed or exchanged, feedback loops, which are self-reinforcing flows in either direction, and then system goals. And I find the goals to be probably the most informative in my day-to-day because that drives the... whole system, and it's easy to identify kind of like, yeah, the the why of a system and often that's where the problem lies, like everything kind of falls from there. Like if the goal of a system is misaligned with what you intend for it to be, then like everything else will follow. And yeah, I find that to be a really informative concept. Like I said, whenever you come across something, you're like, this isn't working as I expected, or this is surprising, or this is wrong. Often now the first question I ask myself is like, what is the system? What are the goals of the system? And then also kind of that basic level of like, what are the stocks here? What are the pieces at play? yeah, because, and then like, how are they being exchanged? Bethany (06:31) Yeah, I completely agree. And I think those are really good points and almost reminds me of a article I read recently that was a belief titled, The Point of the System is What It Does. And it's true, systems are just doing what they're meant to do. Whether that's good or bad isn't a concern of the system because it's implemented to do what it does. So when bugs often arise in the system, I mean, doing what it's intended, it's a system that's broken, so. Yeah, I think that's a really interesting thing to apply to day-to-day life, especially when problem-solving or figuring out bugs and all that. Interestingly, I feel like I've less... applied this to the technical side of my work, but honestly a lot to the human elements of work, so like team structures and dynamics. because I mean when for instance when an incident happens or when something goes wrong it's not necessarily that I'd say like 99 % of the time it's not because anybody's trying to do something wrong or trying to do a bad job it's because the system like allowed something like this to happen so I think it's really interesting to solve those problems at less of a pointing fingers level this isn't really a hot take I feel like everybody talks about blameless retos, but I think it's interesting coming at it from a perspective of, how can we adjust the parameters we have in our control to prevent this in the future? And I think those are far more interesting problems than anything any individual is doing. I think this also came up a year ago when I was still in actions, we were talking a lot about how to incentivize devise L &D more. And that's another instance of the system kind of governing what people are doing with their day to day. And so it's of course more rewarded to do work than L &D. And so people would gravitate towards work or it's seen as like, this is what we need to do. And so people would would do that. So it was interesting looking at those problems from a systems level rather than anything anybody is doing wrong level. Brittany Ellich (08:38) One thing, my prior career was in occupational health and safety and there are lot of parallels between incident response and what happens in the occupational health and safety world. And I think that that is a world in which people do approach. safety related problems from more of a systems perspective than we do necessarily in incident response when it comes to a software incident, which kind of makes sense. I mean, when somebody gets hurt at work, they, you know, you don't want to blame the person, be like, well, they wanted to get hurt. Like, obviously that's not the case. So maybe it's a little bit easier to think about from that perspective. But I do think that they do a much better job in the health and safety world of separating the person out from, you know, and addressing the systems issues. And I think that that is something that I've personally tried to apply a little bit more at the software level, but I think there's still a lot of learning to be done there. The other thing thinking of the team structures and dynamics, one thing I've been thinking about a lot recently is identifying what in a system people are rewarded for or to see, you know, what their motivations are. Like a company might say, Hey, we really care about L and D, but then if people, you know, take the time to do L and D work, and that means that they're not, you know, shipping code or something like that, like clearly they're rewarded more for shipping code. And that's clearly what. you know, what the system is actually rewarding versus what people are saying that they're rewarding. So I think as we are currently in this review season cycle, I'm thinking about that a lot as well. Yeah. Erika (10:09) Yeah, organizational systems are definitely really interesting. And I think it's also like something that we maybe feel the pain of a lot because it's not something we can easily change in software. If you want to run an experiment, if you want to change a line of code, you usually have the agency as a software engineer to do that. But organizational change has a lot of like push back a lot of time and you often like run into things like, you know, no, we're not gonna do that for X, Y, Z reason or like, you know, it comes from the top of, you know, why some organizational decision has been made. Yeah, so I definitely agree that this is a... This is a good way to think about those systems in sort of a more, what's the word, when you're like not emotional about it, like a more sort of analytical lens, as opposed to like getting upset about why something is a certain way. Yeah, so I think. I definitely, I can see why this might come up more in the people scenarios. Bethany (11:19) Absolutely. And this kind of ties into another question that I thought would be interesting to discuss around feedback and how feedback is very core to how a system functions and continues functioning. So like Brittany, you mentioned the rewards and Erica, you were talking about the stocks earlier. But I was curious if you all have noticed any examples of feedback in a software system and then also maybe contrasting that from feedback we've seen in societal systems. Erika (11:46) Yeah, one thing that comes immediately to mind is like panics in Go Code and we recently ran into something. I learned that concurrent map access causes a panic at runtime in Go. And so there was a thread that, or like two Go routines that were trying to access the same map and that was causing panics and then container shutdowns. And so, yeah, that's sort of like playing out the feedback loop. Like when you have the error and then the container shutdowns, like you end up having a lot of like churn of your containers and overall your, you know, system health is not as good. So that's like a sort of recurring feedback loop that comes to mind immediately. Brittany Ellich (12:33) I know Erica... I already mentioned the stocks and one of the examples from the book that I thought was the most useful for me to wrap my head around systems thinking and the basics of like stocks was the bathtub example where you can increase the stock or the amount of water in a bathtub by turning the water on, you know, and plugging it. And then, you know, if you were to unplug the bathtub, it would drain hopefully at a rate less than you're filling it if you're trying to fill it or you could turn it, you know. Anyway. That does for a great example. And that always brings me back to the only concrete software example that I keep coming back to when it comes to that is... is queues and workers and you know the amount of work that is going through or the stock of work that is going through this queue is impacted by the number of workers that are pulling things off the queue. So that's one way to reduce the overall stock or the queue size but then it's also you know the amount of things that you're putting on that queue is another way to reduce the amount of stuff that's sitting and waiting in the queue to be processed. And then that you know as you're zooming out from that lens to look at other things usually there's not a queue just a nice Usually it's a queue with probably other queues and different things that are occurring within the system. So maybe there's other ways to reduce the stock if that's what you're trying to optimize for or to keep it at a certain level to, you know, auto scale the number of workers based on, you know, the number of stuff being added to the queue or something along those lines. Erika (13:56) I know in a previous episode we talked about things that we want to learn more about and you mentioned Kubernetes, Brittany, yeah, similar to the container behavior, I definitely want to learn more about the GitHub Kubernetes implementation. Also Kubernetes in general, but I feel like there's a lot of feedback loops within distributed systems and like... Kubernetes environments that, again, I'm not as familiar with the concept, so I can't speak to how feedback loops necessarily apply in detail, but I generally know that they're there, and containers will get killed or restarted based on different system feedback. So yeah, that's another example. Brittany Ellich (14:41) And one of the examples to speak to the societal system that came up pretty frequently in the book, I think was drug addiction, right? That was like a really common example of like, you know, it's not just availability of drugs necessarily. It's, you know, the amount of poverty in an area and, you know, what, you know, the ability to get access to things like healthcare and, you know, a lot of other things related to that. And I think that was really helpful to not trying to, you know, get political or anything. but to think about the results that we have, an increase in drug usage, isn't necessarily just because of drug availability. It's because of all of these other things within the system that contribute towards more addiction availability. Erika (15:21) Yeah, sort of at the intersection of humans and software development and web systems too is like user interactions. And you only have so much attention from a user. And I've seen some stats where the page load time is directly correlated with like number of users on a page or something like that. that's another thing to think about is like, yeah, why UI or UX is so important because... that user attention and user interaction is a stock in and of itself. Like they're either going to use your site or they're going to use someone else's. So if you want them to stay, have to reinforce it with, I guess, fast page loads and easy to use UI. Bethany (16:12) Yeah, it's really wild how when you think about... the internet as a whole. mean, it is basically a system, its success on the internet has been almost determined by ranking higher in search results. mean, SEO, that field is entirely about how to rank higher on Google or whatever search engine you use. And so it's interesting that the rewards that Google almost determined is necessary for ranking pages higher or lower has turned into rewards for these systems. So I think that's a really interesting point on user experience, not even just from like having the user views perspective, but also like from the rewards that the system is giving. It's like, okay, since you implemented it this way, we'll give you more views for your user. So really, really good point. Erika (17:02) Yeah, and then along the same lines as social media and like being aware of what the goals of that system that you're interacting with are and how they're presenting rewards and yeah, it's always crazy to like know what the dopamine hits in your brain are like when you get like a like from someone or something like that. yeah, it's crazy thinking like it's the same reward structure in your brain as like, I don't know, drinking alcohol or something. Like I heard like a long list of things and it was like, yeah, like all these things here, like, wait, really? That's what's happening to my brain when I see my post get upvoted or something like that. Yeah, that's unsurprisingly a very sticky system that you have to be careful with. Bethany (17:57) Yeah, to that like social media system even going up a level, systems all the way down, right? But... Brittany Ellich (17:57) Everything is distance. Bethany (18:06) That's why you'll see rage bait on social media a lot because even though people don't like what they see in the video, it's intentionally meant to be controversial or get people mad because it makes people comment on the post or interact with the post and engage in the post and then that will then inflate the post's importance in the whatever social media algorithm so then it gets broadcast to more people. systems all the way down. It's wild. Erika (18:33) Yeah, and the goals, right? Like the algorithm has certain goals. And so like, if you know what those are, you can sort of like meaningfully interact with it and, you know, not necessarily take whatever is suggested. But if you're unaware that this algorithm is feeding off of those like clickbait hype posts, then you might think like, everyone else is liking this and like, yeah, this is Bethany (18:34) Alright, yeah. Erika (19:01) This is the top post for sure. Like why would I continue looking? Like why wouldn't I watch this video? Brittany Ellich (19:08) I think another software related example too is A-B testing, which is really designed to like game systems as much as possible because you're trying to see like, if we put this button in this spot, does it make people more likely to purchase this thing? And it's the same thing with a lot of those social media companies that, you know, create these apps to see, does this capture users attention longer, longer so that we can, you know, improve ad revenue. And it's very interesting how over time, has naturally resulted in a system like any other system where it is rewarding the dopamine structures in your brain. Bethany (19:42) Absolutely. Well, are there any final thoughts on the book? Alright. Brittany Ellich (19:47) This is top five book for me, think, in terms of like books I will recommend for software engineers. It's really good. Had some really great conversations that came out of it. It was great. Erika (19:57) Yeah, I think the most meaningful chapter for me, aside from the mental modeling, was her capturing of interventions in a system. And it... sort of gave me a more nuanced perspective of like when to act and when not to act and she ranks them in ease of use basically where like she starts with like the hardest intervention to implement and then down to like the easiest and like I'd never thought of interventions in that way and you kind of think of like action result right and like I hadn't thought of like are there alternative actions I could take that might get the same result but are maybe easier like she talks about like information hiding like is is this a problem that can actually be solved by like making this information available. And I don't actually have to change anything about the system other than making this more obvious. Or like she talks about metadata, you know, as like the easiest thing to change, like saying, like, like changing the title of something. can be an intervention and like that's the easiest thing to do and sometimes that's all that's needed is to be like, nope, this is what it is now, like rebrand. Yeah, but I think it also cautioned me from taking action in certain circumstances because she talks a lot about like delay of feedback. where sometimes you'll take an action and then it'll take a significant amount of time to actually see the result of your action and it can have consequences like ripple effects outside of what you intend. I think I didn't think about that as much before reading this book. Like sometimes the best thing to do is wait and observe and... yeah, I think that's also really empowering because you're like, I want to do all the things. I want to make this better. And then like sometimes you need to take a deep breath and step back and realize, okay, let's actually see what's going on here. Let's observe how, how this is working. And then, yeah, you can make a more informed decision. So, yeah, those were. Those are some super helpful insights for me. Bethany (22:24) That's really awesome. Totally agree with both of you. Like, Brittany, I've recommended this to so many people. I feel like both technical and non-technical because it's been, I think it's just one of those things that it's not a hard read and it does kind of change your worldview in a way. And Erica, I totally agree with you too. Like it's easy to see you're in a system, but I think... understanding what control you have in the system or what inputs and outputs are actually governing it is definitely almost a superpower in a way and I think is definitely the interesting part of these systems stacking onto each other. So awesome, thanks for chatting through this with me. As always, valuable discussion. I did mention that we've been doing this for a book club. And so I kind of wanted to step back and just kind of talk about the meta of doing a technical book club. Like, what did we do well this time? What could we have done better? Any advice we have for anyone who wants to maybe start a book club of their own? Erika (23:24) I think since you put the date of when we started our book club, it made me think of that first book that we read and we read, don't remember the name of the book now, but it was the biography about Linus Torvalds. Just for fun, that's the one. And I mean, we had a great time reading it, but mostly because we were like sort of Bethany (23:39) just for fun. ⁓ Erika (23:47) ripping on the book. And yeah, I think the first thing to come to mind for me was from then to now we've massively improved our book selection. So I think that's helped with a lot of the engagement and value of the book club. Brittany Ellich (24:02) Yeah, I think the book club is one of my favorite things about work. So shout out to Bethany for originally putting it together. I think going out on a limb to start something like that is really hard. But, you know, there's been a lot of times where we'll meet in the book club meeting and it's just us three and that's still fine. You know, we still we still get to talk and, you know, learn a lot more than we would learn from the book. The biggest thing for me is it motivates me to actually finish the books. which I definitely would not do otherwise. And even then, I mostly, I don't often finish them still. But you know, I get like 80 % of the way through, which is better than I do for a book if I was just reading it on my own. So I think that's been really good. And I've just, you know, I love getting to hear how somebody else read the same chapter and here's how they perceived it or here's what they picked up from it versus what I did. And I think I get a lot more out of books doing it that way. Erika (24:52) We've also gotten a lot more engagement now that we're doing async discussion posts. It forces us to prepare for our discussions by writing down what we read in the chapter and preparing some questions ahead of time. And it also lowers the barrier of entry for anybody who's interested because they can read the discussion instead of reading the chapter. And then... Bethany (24:52) I can't put. Erika (25:15) Like pre-planning the cadence too is really helpful of saying we're gonna do this amount for each week. Yeah, and then staying like on schedule. Like I don't think we really reschedule all that often. Like sometimes if something really crazy comes up, but we're pretty reliable. Bethany (25:33) Yeah, I totally agree. think, What's really helped recently is kind of having that empathy that everybody's busy, everybody's got stuff going on, and it's been good to provide other ways to interact with the book club, whether you can make the meeting or not, or even whether you have done the reading or not. And I think that has really improved just having folks to talk with. I think the past couple books we've had have been really good for also that kind of discussion because it's been pretty applicable without needing to really deep dive into it so I think that's been a really really good time but I think definitely with starting a book club it's about kind of being humble especially if you're doing a weekly cadence for like we're reading this many chapters per week. Sometimes people just can't come and you gotta not be like, okay, nobody likes this, I'm gonna stop this. You kinda have to be like, all right, well, what worked? What didn't work? Let's move on, try to make it easier. And so I think there's definitely been a lot of dry technical books that we've chosen that... haven't been the best for discussions like this, but I definitely appreciate having you all there to talk through these things and be able to still discuss even if it wasn't a good general book for a large audience. Erika (26:56) We've also gotten really lucky of who's joined the book club and everyone's been really thoughtful and insightful and in non-technical book clubs I've been a part of, there's sometimes one person who shows up and takes over the whole discussion. And we haven't had that yet. Not saying it won't happen at some point, but we've been really lucky of having good. equal discussion across everybody and sharing the floor and that's made it really fun. Bethany (27:24) completely agree. Yeah, we've had a really good group and it's, I've learned so much through this book club so I think it helps so much to just not have an ego with these things because I think this actually was a big part of my imposter syndrome and it's like, I feel nervous to talk about something this deeply technical with people who are smarter than me but it's been kind of interesting to flip that and be like, okay, I get to learn a lot about people who are smarter than me. So it's been a really good experience to be able to pick people's brains and we have people from all over the company join and so just having all these different revelations while reading the book or reviewing the discussion and applying it to their day-to-day, it's been really cool. All right, well, if there's no other thoughts, we'll move on to our fun portion. So today I decided to take some results from the May 2024 Stack Overflow Developer Survey and come up with some trivia questions on that. yeah, I think I have like six or seven questions, so we'll get started. But the first question is... which technology factor makes 75 % of developers more likely to endorse a technology. So I think what kind of product provide that makes developers more excited to use or recommend using something. Brittany Ellich (28:52) Open source? Maybe. Bethany (28:53) Interesting. Erika (28:54) I have no idea. An API? Brittany Ellich (28:56) documentation. Bethany (28:57) Erica got it! Ding ding ding! It's API access! ⁓ Yeah, so making sure that back-end developers can use your product too is a good way to get endorsements. But yes, documentation and open source definitely were on the list as well, so really good guesses. All right, moving on. What web framework? Erika (28:59) ⁓ cool. Bethany (29:18) has the highest developer retention rate with 73 % of people wanting to continue using it. Brittany Ellich (29:24) want to say React, but I don't know that React developers are that dedicated to React. So I'm going to say View. I feel like most View people I know are more excited about sticking with View. Erika (29:35) I 70 % is a lot. I'm gonna say Linux. Bethany (29:37) Yeah. Brittany Ellich (29:39) That would be 100%. Bethany (29:41) That's true. It is actually, it was close to view, says Svelte has the highest, yeah. So I guess small market share but like passionate developers. Yeah. Oh, right. So. Erika (29:47) ⁓ Brittany Ellich (29:53) Love it. Bethany (29:56) This one, this one might be a giveaway, but which programming language has maintained its dominance as the most used language? Brittany Ellich (30:03) JavaScript. ⁓ Erika (30:03) honestly. Bethany (30:05) Yep, it's JavaScript. Yeah, I was surprised. Apparently JavaScript has always been voted the most used language except in 2013 and 2014 when SQL was voted the most used language. Yeah, exactly. Dethrone JavaScript. Erika (30:18) You go, Sequel. Brittany Ellich (30:22) going on with databases in 2013 and 2014 that not many people needed to write SQL. Erika (30:25) I know. Bethany (30:27) Right? It's like all the backend developers just got together and be like, all right, we can't agree on a language. Let's, let's try to take over JavaScript in some way. Erika (30:35) Make all your queries three times as long. Bethany (30:38) Exactly. Okay, so flipping it, what programming language holds the title of most admired for the second consecutive year? Erika (30:46) This is from 2024. Bethany (30:47) Yes, about a year ago. Erika (30:49) I'm gonna say rust. Brittany Ellich (30:50) That's a good one. I was gonna say Python. Bethany (30:52) It was Rust. Yup. Yeah, it had a like absurd, like an absurdly high score for admired language, like not a very high desire ability to use, but I think it had like 83 % or something of people said they admire it. So really interesting, but all right. Yeah. Speaking of databases, what? Erika (30:53) Mmm. Brittany Ellich (30:54) Makes sense. Erika (31:03) Thank Bethany (31:15) database has become the most popular choice in 2024. Brittany Ellich (31:19) I guess Postgres. Erika (31:20) I'm gonna get a sequel light. Bethany (31:21) It was Postgres, yep. Apparently it used to be my sequel, like for a long time. And then recently Postgres overtook it. But ⁓ Sequel Light's a really good one to guess because I've seen so much hype about Sequel Light recently especially. So I think that's a really good guess as well. Erika (31:23) Huh? Brittany Ellich (31:32) Yeah. Yeah, I hear a lot of really great things coming out of the Postgres team and people that are using it. Bethany (31:46) Yeah, it's like what if databases had UX concept, what a concept, right? Okay, so what percentage of professional developers do not perceive AI as a threat to their job? Erika (31:58) and Bethany (31:59) All right. Brittany Ellich (31:59) I was gonna guess 60%. Bethany (32:01) Alright, if we add those together it would be the number 70 % Brittany Ellich (32:05) Okay, nice. Erika (32:07) Do not see AI as... Bethany (32:09) Now keep in mind this was a year ago. I think we've had a lot of wild improvements with agents in the past year to make it maybe a little more interesting or divisive, but at least in May of last year, people felt pretty secure in their jobs. Brittany Ellich (32:11) Mm-hmm. Erika (32:12) Okay, great. Brittany Ellich (32:26) That sense. That makes sense. Yeah. I feel like if anything, that number is probably just going to go up. Cause I think most people that are using it are like, yeah, like people are very involved as it turns out in this, but who knows what the future holds. Bethany (32:39) I I think it's most successful when it's used as a tool. I am biased. But I do think that that's... I don't think any of our jobs are going to be taken anytime soon by it, but it is very helpful tool. All right, last question. Which programming language developers reported the highest median salary in 2024? Brittany Ellich (33:01) I'm say Python, because of all the AI stuff. feel like that's probably common. Erika (33:06) pretty good guess. My mind definitely went somewhere like low level. This is like a super random thing, but I was gonna say Cobalt only because I've listened to an episode about like Cobalt development developers being super in demand for like legacy systems. But I have no idea if there's enough of those to even make it on the map. Brittany Ellich (33:15) Mmm. Bethany (33:25) That's so true. Wasn't that a changelog episode? Yeah, we'll have to link that. It was a good one. My mind would have gone low level too, but it was actually Erlang developers. Yeah, wild. But so maybe we got to learn some Erlang. Erika (33:29) Yeah, yeah. What? Okay. Brittany Ellich (33:42) Alright. Yeah, apparently. Erika (33:44) I know. Bethany (33:45) I tried doing Elixir for Advent of Code once and it was interesting. I liked it. But yeah, I would be intrigued to see what Erlang's being used for in this day and age. I guess it's not that old of a language, but functional programming throws me off. All right, well, those are all the questions I had. So I guess we will go ahead and sign off. Thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on your podcast app of choice. Check us out on Blue Sky, our social media app of choice. Most of all, share with your friends. Until next week. --- ## Episode 10: Ep.10 | Collaborating with product with Hirsch Singhal - URL: https://overcommitted.dev/ep10-collaborating-with-product-with-hirsch-singhal - Published: 2025-06-03 - Topics: Product & Engineering Collaboration, Leadership & Management, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/103446985/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-4-30%2F401303955-44100-2-b6524e5abfd4a.mp3 ### Show notes This week the crew chats with Hirsch Singhal, Staff Product Manager at GitHub, about effective collaboration between product and engineering. Links * Hirsch Singhal's Bluesky: https://bsky.app/profile/hpsin.net [https://bsky.app/profile/hpsin.net] * Hirsch Singhal's LinkedIn: https://www.linkedin.com/in/hirsch-singhal/ [https://www.linkedin.com/in/hirsch-singhal/] * Domain-Driven Design: https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 [https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215 ] Hosts * ⁠⁠⁠⁠Overcommitted.dev⁠⁠⁠⁠ [https://overcommitted.dev/] * Bethany Janos: ⁠⁠⁠⁠https://github.com/bethanyj28⁠⁠⁠⁠ [https://github.com/bethanyj28] * Brittany Ellich: ⁠⁠⁠⁠https://brittanyellich.com⁠⁠⁠⁠ [https://brittanyellich.com] * Eggyhead: ⁠⁠⁠⁠https://github.com/eggyhead⁠⁠⁠ [https://github.com/eggyhead] * Jonathan Tamsut: ⁠⁠https://jtamsut.substack.com⁠⁠ [https://jtamsut.substack.com] ### Transcript Erika (00:00) Welcome to the Overcommitted podcast where we talk about our commits, our commitments, and everything in between. I'm Erica, your host today, and I'm joined by Bethany, Brittany, and John. We're a group of software engineers who first connected working on the same team at GitHub and quickly discovered our shared passion for learning and building. Even though we're scattered to different teams and companies now, we still come together regularly to talk about technology we're interested in, share what we're learning, and explore our lives as developers. So whether you're committing code or committing to new challenges, we are glad you're here. Let's dive in. Today's episode is about healthy collaboration between product and engineering. And we are thrilled to welcome our special guest, Hirsh, on experienced and skilled product. manager at GitHub. So we will start by having you introduce yourself Hirsh. Tell us a little bit about yourself and what drew you to product management. Hirsch Singhal (00:57) gosh, so yeah, I've been a product manager for my entire professional career, effectively. I was paid to be a dishwasher and a dev for a hot second, but basically since leaving college, I've been a product manager the whole time. I got into it because during my first internship interview, know, Microsoft was on campus asking people to interview. And I was saying, you know, don't, I don't know if I want to be a PM or an engineer. can sort of do both. And halfway through, maybe not even halfway, a quarter of the way through the interview, my interviewer said, okay, yeah, you're going to be a PM. I don't know if it was a compliment. He was himself a PM. So we'll see. But that was sort of where I started. Thankfully, having a strong engineering background, you I went to school for computer engineering, I think helped a little bit. But the fact that Microsoft still had that ability to bring in like early in career PM really helped make that possible. Erika (01:55) So, well, great. So now that you are where you are, what is your favorite part about working with software engineers to create a product? And what is your least favorite part? Hirsch Singhal (02:07) gosh, probably one in the same thing. My favorite engineering product management experiences are the one where we're vibing effectively and kind of building on, yes, and in the ideas from each side. I think. Sometimes engineers don't get enough credit for understanding the systems that they're building and understanding the capabilities of them. so I've got patents on the shelf and stuff that all came from basically, okay, we've got a really hard problem to solve. You know what's possible. know most of what's possible, but also kind of... the full picture of what we're trying to solve, let's go at it and figure it out. And those moments are fantastic, because they feel like you're flying. The hardest part is the don't touch the keyboard rule that you kind of, or discipline that you have to have sometimes. where it's like, I know how to do this. I'm just going to get in there and roll up my sleeves. And it's like, no, you don't. You don't actually fully understand what is going on here. I might have probably the second or third highest contribution count amongst PMs at GitHub, but that doesn't mean anything. You cannot actually do that. And it can be very frustrating looking from the sidelines being like, just. And then like, hey, reminding yourself that you don't actually know what you're talking about. shut up. Bethany (03:23) That's super interesting. I wonder how you separate that like engineering part of your brain with the product part of your brain, or if it's not even a separation, is it something that you kind of use in tandem? Hirsch Singhal (03:32) Definitely in tandem and a lot of that has to do with picking the right teams to work on and with. I've only ever worked on developer tooling or developer facing things my entire life. So I started off in Windows working on developer tooling. I owned like the F12 tools for Internet Explorer. And then I went to the developer facing protocols for identity. And now I'm here, which like, especially Erica's team is. 100 % thinking about developer and the engineering uses here ⁓ is critical. And so it's like... Erika (04:01) you Hirsch Singhal (04:04) using that as intuition, but not as like here, I'm going to write a spec for you that says how it, how the code should work. Stay back. Erika (04:11) As somebody who does work with you pretty closely, I can vouch for your engineering brain being very useful in these product, like collaborative discussions where like you understand. at least conceptually what it takes to implement the feature. So going into a discussion of scope or technical requirements, you're already kind of thinking about like the implementation level versus like purely theoretical. And you also like do jump in with like a really strong knowledge of the limitations of the system because you're so familiar with where those choke points and technical debt areas are, which help us out a lot depending on the level of experience of an engineer on our team. You bring that brain, which is super helpful for us overall. Hirsch Singhal (05:07) Glad to hear it. I think it can be a bit of a crutch at times though, because it It reduces the amount of space that people innately want to think about whenever they're approaching a problem too. which means that, you know, I worry about this one a lot is, How do we make sure that these engineers with all their talent and insight into even broader systems, even deeper problems, not in the same vein as a thought-terminating cliche, but if I put too much on paper, are we missing out on a chance to do more by thinking broader? And there's a trade-off there that I always worry about. Jonathan Tamsut (05:43) Yeah, that's interesting. I guess, like I think with developer tools, it's interesting to be a product manager because in a sense, developers are like uniquely positioned and experienced to build developer tools and have opinions on them as opposed to like some other product that developers don't really know a lot about. like. What do you see as kind of the responsibilities of a product manager? What do see, like what do you think the sort of product responsibilities of an engineer are? Especially in the context of like building developer tools. Hirsch Singhal (06:14) So it's interesting because what Eric and I work on isn't for developers, right? It's something that actually a lot of engineers here try to stay as far away from as possible. like, just, I don't want to deal with identity and authorization and all the bits that make, like, that let me do my job. I want to focus on, you know, opening a PR. I want to write some code. I want to run tests. Like what we're working on is Jonathan Tamsut (06:19) Mm-hmm. Hirsch Singhal (06:37) targeted mostly at administrator personas, not just the developer persona. obviously, a product manager's responsibility is to bring that broader view into the room and be able to explain, like, hey, this is why it's important for an admin to be able to understand who all can see the repo. Here's why that's a really critical job for them because that intuition that makes developers really great at building developer tools isn't necessarily there in that scenario. For more... on the line developer tooling. I think that that's a place where PMs should a, if you can't, like, Thomas said this during an all hands a couple of months ago, like, if you're a PM and you can't code. you're not somehow writing code, even if that just means using like copilot and saying, go work on something. What are you doing? Because you can't build empathy for your customers. And I think there's a bad habit sometimes in PM of like, yeah, I work at the widget factory and I ask the customers what color widget they want the box. or what color box they want the widgets to come in. And then I tell the team to put the widgets in the box. I don't know what the widgets do, like whatever. like, you're just a conveyor belt. And I don't think there's a lot of value provided there. So doing what your customers do and building that empathy and then having a broader vision over... not just what the product itself is doing, but like what is the entire ecosystem doing? So, you know, Tim Rogers, right? He's a PM for the Copilot Coding Agent. You know for sure he is sitting there and testing out every single product on the market that does that thing to actually build that context and bring it back to the team and say, like, here's what works. So that not every person on the team has to go do that themselves. So. I think that's the PM's responsibility. Erika (08:26) I've heard like a version of that that you mentioned that Thomas said with coding, but drawing it out to either coding design or sales background and those being prerequisites for some kind of product management role where like you're bringing that experience to, like you said, bring a... be a connector and have that empathy for the end user, whether your end user is a developer. And then from the design perspective, you build that skill of reviewing designs. if you've created design before, you're going to know what goes into that to bring that to your dev teams and give them a wider perspective. Yeah, it's an interesting take for sure and definitely highlights the need of product managers to give that wider vision and be that connector. Jonathan Tamsut (09:29) And I think one interesting thing, like from my experience is, you I worked at a company that built, like, it was like a fintech tool for bankruptcy, Chapter 11 bankruptcy, you know, processes. It basically allowed people to buy and sell bankruptcy claims. And, and Chapter, you know, bankruptcies are like incredibly complicated legal processes and The entire time I was at that company, there was just so much I didn't know. I I learned a lot about bankruptcies, but it was like, there were so often the case where we would come to sort of some decision juncture and I would hear like, well, this is a product decision. Like we need to, you know, go consult products. So I think it's like, it's interesting. Like the inverse is also true, right? I mean, you know, with developer tools, obviously developers have unique expertise, but. Pretty commonly, it's like developers don't have the context to really make product decisions and should developers, should it be incumbent on developers to kind of educate themselves more? I to an extent that's maybe not really feasible, but. Hirsch Singhal (10:26) A little bit. mean, the best engineering teams I've worked with, when I talk about like that flying feeling, is where they themselves are subject matter experts. And again, that's a lot easier on like... being in the weeds of the scenarios that are being solved. So when I think about my, one of the teams I worked with at Microsoft, they owned the core token issuance engine for Azure AD. So anytime you signed into anything, it routed through them and they were responsible for the linchpin kind of, of every single connection between every single user and app and resource in the system. And so that meant that they had tons of experience looking at all the different ways that you could connect things together and like having strong opinions about the right way to do those things. And I think it's that last bit there that was the most impactful is like, I understand the goals and requirements of the platform that I own and can continue to represent them over time instead of having to in a sense, like be reminded of them at every juncture. And so being able to ingest the... Erika (11:23) you Hirsch Singhal (11:27) the reason for your product to exist is, I think, critical to being a strong engineer on product that you're not innately familiar with. Erika (11:36) Thanks. Bethany (11:36) I agree with that a lot. I think it reminds me a lot of a book we read, Domain Driven Design, on that collaboration or that understanding even what you're working on. I think throughout my career, it's always been like, oh, you provide the code, and that's the most amount of contributions you have to this product. But what I really liked about the book, and I feel this at GitHub as well, is that engineers should intimately know what their writing for, what they're coding for. And that code almost serves as the language to talk about the product so that everyone shares a shared understanding and language for what they're building. And also not shielding product or non-technical folks from the code either, because that only serves to silo certain knowledge. So I appreciate that take on kind of the engineers. role in the product portion as well. Hirsch Singhal (12:30) I like that about not shielding PM from the code. If you're not adding your PMs to your pull requests, come on. And sometimes that just looks like, hey, fix the wording. you know how to add a commit to my PR? Let's go. We do not need to round trip this through a Google Doc. Be comfortable with understanding how this works. and why you can't just ask for, you know, 18 different ways of putting this phrasing together. Erika (12:55) Yeah, we're kind of already touching on some of these things of like characteristics of a healthy collaborative working relationship between product and engineering and also some of these like flip side elements of what the breakdown looks like. I know I've had similar experiences to what you were talking about, John, of the sort of... throwing it over the wall to product and then having products throw it back. yeah, like, I feel like it can be a really lazy way to... outsourced decision making from an engineering perspective and say, hey, not my problem, product, tell me what to do. And then come back and like, okay, well, I'm going to implement exactly what you say and only that. And if it's not what you want, then it's your fault because you told me wrong. Yeah, and like what we're talking about here is a more like integrated approach of like, okay, together we're going to like describe the model, describe what we want to see, have a shared vocabulary, have a shared language, and like share some understanding of what it takes to get there too between product and engineering. Yeah, but to your point, Hirsch, it requires including product in those discussions, from a design perspective, and then also engineering taking responsibility of understanding the wider context. Hirsch Singhal (14:19) Yeah, there've definitely been some times where you get to the end of the epic, you get to the end of the initiative, and you go to click around and you just go, my, why would you ever do this? And it's like. Okay, you can either start the blame game or be like, okay, well, clearly something didn't get communicated. And generally that looks like something didn't get communicated from product to engineering. Sometimes it's the other way around, right? Like, we had to build it this way because of how the system works. And obviously when you told us X and Y, like this would be the outcome, right? But, and usually it's the other way around in my opinion. product hasn't done enough to bring engineering on the journey so that they understand the implicit. expectations. And sometimes that even just looks like, again, Erica kind of using our area, for example. You know, I asked one of my teams to go work on something that Erica's team is building and built previously. And I didn't explain how what Erica's team built works. And I didn't explain how the back end works. I didn't explain how the front end works. I didn't explain like, okay, yeah, because like, this word has a defined meaning and all of the implications of that you should just know. That's not a reasonable expectation perhaps. And so they invented a whole bunch of extra requirements that didn't need to be there because like, again, yeah, that full picture wasn't brought over. Jonathan Tamsut (15:31) I've also been in situations where, you I think sometimes people try to justify the existence of their jobs and there's also maybe like power struggles that emerge. So product really does view engineering as sort of like a widget factory resource. they're sort of, you know, product is sort of the arbiter of like what gets built, how. And yeah, that generally doesn't feel good. And I don't think it's like sort of maximizing the potential of the team. And I think like, you know, I've also seen engineers, like the product is what matters, right? The code is sort of incidental or, you know, I like the quote, code is not an asset, it's a liability. Like, I mean, the code exists to sort of help the customer do something. And I think some engineers, can get really lost in sort of the technical details and forget about or excited about the technical details and forget about sort of the reason why this exists is to serve. Brittany Ellich (16:26) Speaking of that, have you seen any good methods of creating more trust and psychological safety between the product and engineering side of Teams? Have you seen anything that works really well or anything alternatively that works very poorly? Hirsch Singhal (16:39) I was hoping somebody else might have something. That's a hard one. Overcommunication is a big one. It's not very much in my nature, but I know a lot of successful PMs that are sort of the cheerleader slash news correspondent from the front, in a sense, of like, hey, you did all this great work and let me bring you the report. saying how impactful it was, how great it was, know, major customer cited your feature as one of the reasons they signed a deal with us. You know, here's the VP of sales saying, all right, like we landed this deal because we finally unblocked them after your work got done. And I think that does two things. It like, again, it attaches engineering to the actual outcomes. because they actually get to learn about them. But also in a sense, I think that does help prop up the credibility of the PM to their team and is like, hey, remember this thing I asked you to work on and we did this thing and like, yeah, see it worked. Yeah, it's something honestly I need to get better at. Erika (17:38) Yeah, I feel like another area of like trust breakdown that we haven't talked about is timelines. And this can come from both directions where engineers have this like inane habit tendency, I don't know what it is to underestimate timelines. And then like I have also worked with product teams who don't really ask or consider the implementation scope when setting timelines. So I feel like that is a vector of the product life cycle where trust can really break down and having a... having a sort of go-to strategy for addressing blockers, addressing timeline estimations, not assuming from either side that the timeline is fixed, but continually addressing it as it goes and being as upfront and honest about what's going on at each stage. I think is a helpful thing to keep in mind. Hirsch Singhal (18:43) Yeah, I think the biggest one there is always coming back to the fact that like, we are a team. It's not the engineering team in the PM. Like it is, but it's collectively we are a team and we are trying to deliver this work. And when are we going to get it done? That's not a single person. question ever. Yeah, nothing nothing breaks trust more like, yeah, I said a bunch of stuff on your behalf. I wrote checks that you have to cash. Absolutely not. And you know, the flip side is like, there's a king mattress of padding in there somewhere. Okay, so Do you actually know how long this will take? Like, what can we do to get more confidence in these dates? And again, that needs to be like, you know, I hear a lot like, you know, if I give you an estimate, like you're basically gonna try and fire me if I don't meet it. And it's like, no, like the point of the estimate is so that the docs team doesn't. get spun up on something six weeks before they actually needed to. Other teams need to know when this work will get done so that they can then build on top of it. It's so that we can just coordinate amongst ourselves. That's it, but that requires high trust to believe. That's organizational as well. Erika (19:53) Well, and there's one other actor too that you connect with the engineering teams with, is leadership and upper management. And you are that go between a lot of times, in addition to engineering managers at GitHub, but you communicate with them about priorities and then bring that back down to the engineering team. So how do you like see that role for yourself and how you manage the flow of communication upwards and downwards? Hirsch Singhal (20:24) depends on what. the overall culture of the company looks like. I know that, you when I worked at Microsoft, like I got told what I was working on. There is none of this like PM led. you know, I, a subject matter expert in my area, you know, this is, I've talked to my customers and I know, no, let's be clear. Accenture or JP Morgan or somebody with more money than God. like has gone to my CVP and told him, you need to build this and I'm gonna pitch a fit if you don't, right? And it's negotiation, but okay, that's what we're working on. And in those situations, I think it's about. trying to explain that situation to the team and try to mitigate as much whiplash and like, you know, if you can get your CVP to say no, like, and that's a tall cliff to climb because it's whiplash, it's chaos, it makes everybody lose faith in the rest of the system. Like what was the point of having a roadmap if anybody with a C in their title can? from any company that is our customer can basically disrupt it at any time. Did that mean that LT doesn't have faith in our roadmap? Do they know what we do? Like it brings a lot of really insidious questions. And if you can explain like, no, no, this one's really important. It can help maybe. Otherwise, yeah, it's about representing the work and the challenges of the team upwards to try and, you know, get additional funding. if I can't explain adequately, like, it's really important that authorization works correctly. then we don't get more headcount to make sure that it continues to work correctly and trying to attach the, trying to help LT connect the dots between like, hey, you asked for a bunch of stuff and we have this much to deliver it with. Highlighting those challenges to LT in a way that they understand and believe is probably the biggest thing there. And we can't do that without understanding what it is that you do. Erika (22:10) Yeah, for sure. Well, I'm going to ask one more question before we wrap up to our fun section. My last question is, if you could give one piece of advice to any software engineer you work with, what would it be? Jonathan Tamsut (22:11) ⁓ Hirsch Singhal (22:24) try to talk to customers. Like, we don't do this enough. You know, every so often we'll bring in a customer to like an all hands and they'll talk at really high level about what it is to like use GitHub. But you know, I've got admins that want nothing more than to go talk to the API team specifically about like, why is this returning a 403 instead of a 429? Listen to the pain in my voice and like, actually getting that empathy across and even building those relationships. like it creates touchstones and serious actual understanding of, know, the reason of the product, which I think can help you empathize with the PM and also like, hey, wait a minute, didn't this other thing and you get to start drawing the dots yourself. And I think that can be a real level up. Erika (23:10) in the face. All right, so our fun section today, we've done a version of this before with web acronyms, but there are a lot of acronyms in the product management space, and we don't always know what they are. Some of these I didn't know, so we're all gonna jump in on this and take a guess at what these acronyms mean. So... I'm going to start with Britney. There is an acronym AARRR. What do you think that stands for? Brittany Ellich (23:40) A A R R R I feel like one of the Rs has to be for revenue. But I just keep immediately thinking of AARP, which is probably not the same at all. So I'll need to phone a friend on this one. Erika (23:52) Does anyone else know? Jonathan Tamsut (23:53) A? So two A's followed by three R's. Erika (23:56) Yes, and it is pronounced R. Jonathan Tamsut (24:00) Arrrr. Okay. Is it pirate related? Hirsch Singhal (24:02) I was gonna say, is that Erika (24:02) It refers to, in full context, it's the R-Pyrometrics framework. But it does stand for something. Jonathan Tamsut (24:11) the R pirate metrics framework. That's fun. Hirsch Singhal (24:13) That ruined my entire guess. Erika (24:15) All right, I'll give it away. It stands for Acquisition, Activation, Retention, Referral, and Revenue. And it is a framework for user behavior metrics that product-led businesses are tracking. R. Y'all revenue, yes. All right, this one I'll kick over to Brittany Ellich (24:29) I got the revenue part. 20%. Hirsch Singhal (24:30) Yeah, that's Yeah, it's your funnel. Erika (24:40) Bethany, QFD. Bethany (24:43) Okay, QFD, I'm going to say... I don't know. So I'm gonna take a random guess and do queries for data. Erika (24:52) I like it. It's wrong, but. Jonathan Tamsut (24:54) Bethany is really good at this game. I remember last time we played you got them all Bethany. Bethany (24:58) I think I cut, I pulled all of them. Erika (25:00) Yeah, cheat code. ⁓ So it stands for quality function deployment. And it is a model for product development popularized in Japan in the 1960s, which translates customer needs and expectations into technical requirements by listening to the voice of the customer. You can tell how familiar I am with these acronyms by the attention to detail I need in reading the definitions. Hirsch Singhal (25:04) Bye. Erika (25:27) Alright, Jonathan, I'm going to give you this one, which is not an acronym, but describe the concept captured by this phrase in product development. The user is drunk. Jonathan Tamsut (25:39) The user's drunk, interesting. I'm gonna say... I'm gonna say it is in reference to the fact that the interface and the user experience should be so simple and push them into a pit of success that they could in theory be drunk and still be able to effectively use your software. Okay, cool. Erika (26:00) That is exactly right. Hirsch Singhal (26:02) Nice Erika (26:03) All right, and the last one I'm gonna give to Hirsch, NPS. Hirsch Singhal (26:09) Net promoter score. He gave me the easy one. We actually use that one here. Erika (26:13) Yeah, I feel like I should give you another one. I feel like that was kind of a soft a softball. Uh, ASD? Hirsch Singhal (26:20) I I only know the one about spicy brains. see. Yeah, something something design ASD. Jonathan Tamsut (26:23) Wait, can you? Can you elaborate on spicy brains? What is... Okay. Erika (26:27) Yeah. Hirsch Singhal (26:28) ⁓ Autism Spectrum Disorder Erika (26:30) ⁓ yes. Hirsch Singhal (26:31) is ASD. Which probably not related to PM. Yeah, I got nothing on ASD. Erika (26:38) So this is an outgrowth of RAD. which is rapid application development. And then AASD stands for adaptive software development, which are both agile frameworks that respond to customer needs. Yeah. Hirsch Singhal (26:43) Okay. There you go. Erika (26:53) Yeah. Brittany Ellich (26:54) Classic, nobody knows what agile means anyway, so it's... Erika (26:57) It's true. It's true. Hirsch Singhal (26:59) I was gonna say, like which of these is not involved in Agile? Scrum stories, Kanban and something. Erika (27:02) Yeah. I know. Yeah, I feel like there's a whole host of spicy acronyms that I did not plumb the depths for for this. So we might have to do a take two where I find some more exciting sounding acronyms. But R was good. Drunk users. Hirsch Singhal (27:20) R was pretty good. I like that one. Erika (27:23) Well, with that, we're going to wrap up for today. And thank you all so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky or your social media app of choice. And most of all, share with your friends. And until next week, bye-bye. --- ## Episode 9: Ep. 9 | Learning how to learn - URL: https://overcommitted.dev/ep-9-learning-how-to-learn - Published: 2025-05-27 - Topics: Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/102785355/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-4-17%2F400448359-44100-2-569a27773b704.mp3 ### Show notes The crew chat about what we're learning right now and how we learn. Links * PARA: https://fortelabs.com/blog/para/ * The Art of Visual Design: https://www.artofvisualdesign.com/ * Math Academy: https://www.mathacademy.com/ * Deep Learning from scratch: https://www.oreilly.com/library/view/deep-learning-from/9781492041405/ * Kaggle competitions: https://www.kaggle.com/ * A Philosophy of Software Design: https://blog.pragmaticengineer.com/a-philosophy-of-software-design-review/ * The Feynman Technique: https://fs.blog/feynman-technique/ * The Bradfield School: csprimer.com [http://csprimer.com/] * Execute program: https://www.executeprogram.com/ * NotebookLM from Google: https://notebooklm.google.com/ * The Software Engineer's Guidebook: https://www.engguidebook.com/ * Pachinko: https://www.goodreads.com/book/show/34051011-pachinko * Piranesi: https://www.goodreads.com/book/show/50202953-piranesi * Thinking in Systems: https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X * Algorithms to live by: https://algorithmstoliveby.com/ * The Chaos Machine: https://www.goodreads.com/book/show/58950736-the-chaos-machine * Cosmos by Carl Sagan: https://www.goodreads.com/book/show/55030.Cosmos * How to Solve it: https://www.goodreads.com/book/show/192221.How_to_Solve_It * The little book of aliens: https://www.goodreads.com/book/show/123018903-the-little-book-of-aliens * Designing Data Intensive Applications: https://www.goodreads.com/book/show/23463279-designing-data-intensive-applications Hosts * ⁠⁠⁠Overcommitted.dev⁠⁠⁠ [https://overcommitted.dev/] * Bethany Janos: ⁠⁠⁠https://github.com/bethanyj28⁠⁠⁠ [https://github.com/bethanyj28] * Brittany Ellich: ⁠⁠⁠https://brittanyellich.com⁠⁠⁠ [https://brittanyellich.com] * Eggyhead: ⁠⁠⁠https://github.com/eggyhead⁠⁠ [https://github.com/eggyhead] * Jonathan Tamsut: ⁠https://jtamsut.substack.com⁠ [https://jtamsut.substack.com] ### Transcript Jon (00:00) Hey everyone, welcome to the Overcommitted Podcast where we discuss our code commits, our personal commitments and other related topics. Your host today, John, is joined by Bethany, Erica and Brittany. We are software engineers who initially met as a new hire group at GitHub. However, we found a common interest in continuous learning and building interesting projects and we decided to start this pod together. We continue to meet to share our learning experiences and discuss our lives as developers. Whether you're pushing code or taking on new challenges, we're happy you're listening. Today's episode focuses on learning. We're going to discuss things we want to learn, what we're learning now, how that fits into our careers, and different strategies and tools we have. That sound good. Okay, so I guess we can start off with, know, this is actually a topic I'm excited to talk about. Like, what are our topics we want to learn for each kind of short, medium, and long term? like, how do you all prioritize what these topics are? And like, yeah, I'm really curious to know, like, why do you want to learn X? Erika (01:00) Yeah, I don't think I had... really explicitly thought of my learning topics in short, medium, and long term before, but I realized that I do naturally prioritize things that are more pressing and relevant to my job and my day to day. So right now that's, like I try to think of like, am I weakest in? What do I really need to learn to be better at my job? And right now that's Ruby on Rails. So I'm I've done Ruby learning in the past, but I feel like I'm at that cusp of intermediate to expert. So I'm really trying to push past the intermediate level and dig deeper. So I'm doing that because I'm developing a lot in Ruby on Rails, and I want to be faster. I want to be more proficient and bright. better code. But then long term, I think of all sorts of things that I want to learn about, computer science fundamentals. And then I've always loved robotics and hardware, but I never make time to do it, invest in it, purchase anything. But I have this dream that I'll have some kind of robotics. lab in my garage at some point and it interests me so that's why I want to learn about that at some point. Yeah, but maybe when I have a little less going on in my day-to-day work. Jon (02:25) Yeah, so I'm doing an online master's at Georgia Tech and there's seminars that are offered. And I took one in robotics. And I don't really know a ton about robotics. was like every week we would, someone would present the robotics research. we had this person, she was like, she worked at JPL and she did like, she focused on like. She was like a roboticist, like a scientist, and she focused on like the wheels of like the Mars rovers and how they interact with like Martian sand. We had like someone from Nvidia come and Nvidia is all about like using, you know, basically neural networks to train, use like reinforcement learning to train robotics. And yeah, there's, I like really didn't know what people were talking about most of the time. And there's a ton of robotics stuff I wanna learn, but yeah, it is, it does feel like. Robotics is the future. And no, that's cool. I'm similar. Like, it would be cool to build a robot and program a robot. That's been on my to-do list. Brittany (03:17) So I usually am a lot more organized about what I want to learn. One thing that I do is I follow the, para, para. areas, resources, archive to organize all of my notes and whenever I get new information, there's just so much information out there. I dump it into a file that's related to it so that when I am ready to go learn about something, then I have a list of all of the things that people are like, hey, you should check out this resource on that thing. Right now, what I'm really interested in learning are... Prompt engineering, I know, I'm sorry to be that, that person, I know that's really overdone right now, but I have quite a few resources related to prompt engineering that I have saved that I feel like it's time for me to learn more about. Um, and also Kubernetes, I think that that's an area that I'm super weak on and just like managing infrastructure in general. That's something that I know that I would like to get better at. Uh, so that's something that I'm hoping to focus on. Jon (04:18) Bethany do you want to talk about? Bethany (04:20) Yeah, I am jealous of you all because I have zero prioritization with what I learn. feel like I will go after whatever is the first thing in my brain. So this forced me to kind of try to figure out how I would prioritize it if I had priorities. But I would say that I definitely split it into like work and non-work learning. So I would say for not work, I've mentioned this a couple times I think on the podcast, but I've been, I really want to make a blog, but I want to design it and build it myself. Like I don't know why I have this strong urge to just make something that feels unique to myself. But I am very not artistic, just was not gifted with artistic traits at all for at least visual art. And so I was initially taking like a React course, which was great, but I realized that I just had no idea how to design a webpage. And so I ended up signing up for this course called the Art of Visual Design. And so far it's been really helpful for actually putting a process down for... design, which is helpful for my brain. I need a process to go down because it's one of those things where I feel like I know good design when I see it, but I can't just pull it out of thin air. So it's been very helpful for that. And I'm starting to, I think, get ideas for how I want to design my blog. And I think it actually will make the React part easier. because I've been learning how to design in Figma and that really helps with figuring out what CSS elements I need and everything. So highly recommend that course. And on the work side, as I mentioned, I work on Co-Pilot API, which is actually fairly decoupled from the actual prompting part or the LLM actual inference part. and so I just love to learn more about both of those sides of the equation. we recently had an offsite where there was some, like a prompting workshop and that was really fun to learn about and learn what users of our application, like what their interaction is. and I really want to learn more about the infrastructure part of LLMs because I would love to just understand how to make a better service for. for everyone who uses our platform. Jon (06:39) I feel like we have, yeah, we definitely have a lot of overlap. I mean, I wanna learn basically all the things you guys are trying to learn. It's hard. There's so much I feel that I wanna learn. Prioritizing is difficult. I think, yeah, I've kind of, with my sort of newfound free time, I'm trying to really think about things that I can learn. So I think one thing is there's this website called Math Academy. I think I mentioned it to you. Pretty cool website. It kind of uses spaced repetition and chunked learning, are just learning research. And it has a semantic graph of mathematical knowledge, because math is really pre-rec based. You have to master addition before you can do calculus. And so I want to go through. They have a machine, math machine learning track. I want to go through that. As I mentioned, I'm doing a master's program and I'm of accelerating that. I'm taking a natural language processing course, is kind of basically just going to be like, it's starting next week. I think it's going to be a lot of like classical NLP, and then just like older neural net, like recurrent neural nets, and then like LLM stuff, like transformer architecture stuff. So I think that stuff I want to spend. I want to focus on machine learning. think that's where my masters has been. I'm also taking a seminar on LLMs that's on the human computer interaction of LLMs. I actually signed up for that yesterday because I was like, hey, got some time. Might as well add another. There's a few books. I have a book called Deep Learning from Scratch, which just builds neural network primitives using NumPy. which has been something I want to do really just like, think, think built like, like, I think the two things I want to do are like, write some of these neural network permit, like algorithms from scratch, like back propagation and like implement like Gaussian mixture model and naive Bayes, like just using, just using like NumPy. And then I've, I've been saying, I've, I've, I've want to do this for like a long time, but just like do Kaggle competitions, even like archived ones that aren't live. Cause I think that's how people really. kind of learn machine learning. But yeah, so that's me. And I think when I was at GitHub, and I might continue this as like, just like database stuff, I think there's just like infinite knowledge with databases. might, if I sort of decide to kind of continue down the database world, I might try to. you know, maybe read a book on relational database internals or something. Erika (08:57) Yeah, what you were saying too kind of made me think of like one other aspect of prioritization is not only like timing, but like the depth that you go in to each subject. like sometimes you might prioritize like a short term subject and only learn like. certain level of knowledge or you'll kind of say I need to skill up in this particular area like for Ruby or for Ruby on Rails as an example like okay I'm gonna do a lot of like active record work I need to learn specifically about active record and like these are the questions that I need to be able to answer and like I don't need to learn everything but this like one specific topic this one scope and you can go from everything to like getting a summary and knowing general high level down to reading the source code and running it yourself or contributing. There's all sorts of levels that you can take in whatever you're learning. yeah, I think what you were talking about is very descriptive of the topic overall and different ways you can approach it and different layers of approaching. what you're learning, which is cool to kind of hear about as somebody who doesn't know anything about machine learning. Jon (10:13) Yeah, and I think that segway is kind of into the next part, next thing we're gonna talk about, like strategies for effective learning. like, you know, I think, totally, like there's kind of, you know, I think when you're in school, you try to learn everything, or at least when I was in school, I was kind of a learning maximalist. Like I wanted to learn everything, but like you kind of, it's just kind of just impossible. I mean, it just is impossible when you enter, you know, there's... There are people who spend their entire lives studying a small sliver of computer networking, whatever. And I definitely struggle with, I feel like I get greedy and I wanna learn everything and then, I struggle with just focus. So yeah, so what are some, guess, you guys learn or used to learn? Yeah, and kind of like how do you, like what things have worked well for you and what things do you think work well in general? I can start. But yeah, I think having a problem in project-based learning has just proven to be absolutely works well for me. I also feel like I learn way better when it's social, like when I'm learning with other people. Or even when I'm in a class, even if I'm not interacting with any other people, there's just a... you know, a social aspect to it that I think makes me feel like A, the topic is like, kind of validates that the topic is like useful and important and B, keeps me accountable. What about you all? Erika (11:35) kind of like sort of meta. strategy description, but and it also like shows how how lazy I am, but like I need like like I need time boxing and I need motivation at the end of the time box. Like I have to put my phone away and I have to like know that at the end of whatever time I spend absolutely focused on something that like I will get a reward. I don't know what that is. Like sometimes it's chocolate. Sometimes it's like walking around going outside. But yeah, think like to be fair to myself, I think learning is by nature uncomfortable because you're dipping your toe into something that you don't know. And it's so easy to pull back because that feeling of discomfort makes you want to leave. And I think that's kind of a human thing. So yeah, I think. Like the meta part of this is like recognizing that like it's okay to feel uncomfortable and you know, give yourself some, give yourself some room and take breaks as you need to keep going. Brittany (12:39) Yeah, one thing that I've noticed is I really like having a lot of different mediums to learn from. So like, I like having like a book and then a video and a course and all of these different ways. And I feel like having things explained to me multiple times through different mediums is very helpful. And I think one of the things that has helped me the most there in that space is accepting when I have gotten like the bulk of the information from something and then like saying goodbye to that resource without feeling like I have to be a completionist and be like, no, I'm going to go through every single video in this course, or I'm going to read every single page of this book. I think I previously felt really guilty if I didn't finish something all the way through, and now I'm like, you know what? I'm not getting as much out of this book, so I'm just going to put it down and move on to the next thing. And I think that's been also really useful too. Jon (13:27) And I think that... Erika (13:27) It'll still be there if you come back to it. Brittany (13:30) Yeah. Jon (13:30) And I think it speaks to this idea, like, I think learning is like an iterative process where like, kind of, like, you know, we have this idea that you kind of learn something and then you move on. But like, you know, memories fade, you come back to material and with different experiences, different contexts, and you learn it in a different light. It can be applied to different set of problems. You can, yeah, just learn things deeper as time goes on. So I think that's like, I think that's really true. And I think that's something that like has definitely... know, just a phenomenon I've seen. mean, I've learned, there's like five things that I've just learned, you know, I've come back to so many times and I've either forgotten about it or like had a deeper understanding of it. Brittany (14:06) Yeah, I'm laughing because we just started a new book club within our book club and I realized I went to go buy the book and I realized not only did I already own it, but I'd already read over half of it in the past at some point and I have no recollection of it. apparently I did it. I highlighted it and everything, made notes. But yeah, it is an iterative process and something that I apparently need to repeat. Erika (14:32) Yeah, or that feeling that you get when you read a page of information and at the end of it you have absolutely no idea what you just read. Bethany (14:33) That is too funny. Yeah, definitely. No, I had the same experience. Well, I haven't read the book we're doing for book club, but I definitely already owned it and I attempted to buy it again via Kindle and it was like, you already own this book. So that was fun. But I mean, to like. loop in book club. think book club has been such a great way to learn things because you're talking with other people, you're discussing this thing. A lot of things that I wouldn't have otherwise like retained or learned I feel like have stuck with me more just because we have that book club to look back on or look back on those conversations, which I think, Brittany, to your point, might also be the different mediums as well. Like you read something and then you discuss it out loud. I also would say something that helps me is teaching other people. So trying to break out of the imposter syndrome of, I don't know this, I have no authority to teach someone this, and actually just try to teach someone with what knowledge I have is super helpful. So I get a lot out of, like personally out of mentoring and just relaying things back to other people that I've learned recently. think that's technically called the Feynman Technique or something like that. Jon (15:52) I was just about to mention the Feynman method. For things I wanna learn well, it's like, start with a blank piece of paper and just explain it step by step to yourself. And I think I've told you this. I used to work at a coding, I was a teacher at a coding boot camp for like a year, or yeah, I think a year, maybe over a year. Anyways, but I got hired and we taught Rails, I didn't know Rails. And... I basically learned Rails by students asking me questions and me Googling the answers. And by the end of, I taught a three month class seven times. So just the same, and by the end of it, I definitely knew Rails pretty well and could answer all students' questions. So yeah, teaching, mean teaching definitely, especially when you're teaching the same thing over and over again, which most teachers do. Erika (16:42) Yeah, I mean another thing that happens too when you like, and I think what we're talking about is like talking with somebody discussing it, like teaching either like in video or like in person, something like that. I think the other thing that happens is like when you say it out loud, like A, your brain makes additional connections and like you're thinking on like a deeper level. And then also, you hear yourself say it out loud. So it cements it from an auditory perspective, too. Because there is that idea of different learning senses of tactile, auditory, visual. And I think a lot of times, I only go with the visual. Although when you do actually code something, you do get that tactile. tactile memory too, but I mean I think even if you don't have somebody to teach like you could like read your notes out loud or like teach yourself like you I do this sometimes when I'm like preparing for a presentation and I always hate it but it's always super helpful of speaking my notes out loud or talking to myself in the mirror and yeah I think it's a it's a very powerful way to add an extra channel in your brain for that information. Jon (17:57) Yeah, I have a friend who he, know, there's sometimes I'll get like really excited about a topic and I want to explain stuff to him. And you know, it's, it's, um, this is just kind of his personality, but he'll always find a question and ask me the question. I'll be like, damn, I guess I don't really understand this. And it's, it's, could be, you know, sometimes it's kind of, you know, there's a little, humbles you. Um, but it's, it's, it's, it's always nice to like, I think with students or just with other people, um, you can kind of. convince yourself you understand something when, and I guess that's just like the role of assessment in general, but I think having like shame or some social currency tied to you not understanding things like seems to stick with me more. Brittany (18:37) If I learned anything while being a consultant, it's that the answer to that is always, I don't know, but I'll get back to you. Works for basically every situation when you have those questions come up. Jon (18:43) Yeah. yeah, so. Yeah, I guess we talked about sort of study techniques. You all want to talk about kind of resources we find useful. I think like one thing I'm very interested to hear is have you used LLMs at all to learn and how do you use them to learn? So yeah, I guess we can start with any like books or... that have like really explained a topic well or online courses or YouTube channels, cetera, podcasts that just have provided like really good pedagogical value. I can start, I think one shout out is there's a school called the Bradfield School, started by this guy named Oz Nova. And he used to teach in, I think it used to be in person, then it was online. And now he has this. website, I believe it's called csprimer.com and I don't think it's finished yet, but I think he does a really good job of explaining CS concepts to engineers and like, you know, a lot of it is like project focused, like you'll build, I don't know, like you'll implement, you know, like the Redis protocol to learn more about databases or you'll build a B-tree or something. So yeah, I think that's like, if you're interested in learning, More about computer science fundamentals. I think that's a pretty good resource. Erika (19:59) I am a member of CS Primer and can definitely vouch for all the content being incredibly valuable and helpful from learning it through doing. Because I think as somebody who didn't study computer science, a lot of the textbooks or learning materials approach it from a mathematical angle, which can be intimidating and nonsensical if you don't understand what all the math symbols mean. But approaching it from a coding perspective makes a lot more sense to me. Yeah, using logic principles and software principles. So agree that it's a very practical and useful resource for learning those concepts and fundamentals. And there's a lot of content on there. Yeah, I think he is still working on it, but there's a ton there to go through. So yeah, I think that's a great call out. Jon (20:55) Another platform that I think just models how technology can be used to teach people is called Execute Program. There's courses on TypeScript, SQL, I think Python. It's sort of like gamifies learning and you kind of do little challenges in the browser, like little programming challenges. it uses chunked learning and spaced repetition where you'll cover a topic and then the next day you'll be quizzed on it. And there's this exponential back off of being reminded about something. And I just think more tools like that that use education research, like gamify learning. teach things in chunks like should exist and are really useful and are fun to go through. So that's like one that I think kind of models how I wish more tools or more educational tools were like. Erika (21:44) Yeah, for sure. Going back to the motivation too. If something's more fun, it's probably going to be something you're going to do more. Brittany (21:51) Bye. a resources that came to mind. think the first one is having a group that you can learn with, which is kind of a meta thing as well, because that's essentially what we have formed here and have done for almost three years now. I was actually, you were mentioning the Ruby course and I was realizing that, or the Rails course, and I was realizing that my set of Rails notes is almost completely built on a backbone of notes that I made from John's teaching me how to use Rails. So having a group of folks that that are also interested in learning, that even if you're not learning the same things, to try to teach each other back and forth is incredibly useful, I think. I also have this LLM prompt from a podcaster that I listened to. His name is Dan Coe. He shared it that he found on Twitter or X or whatever it's called now. And it's kind of useful. It's a little bit... I'll share the prompt with you all. It's about just like basically putting together a learning program, which I thought was really interesting. And I think one thing I like about it is that it pulls from multiple mediums, use like multiple YouTube videos and then a book and then whatever else. And I think that there's a lot of value that can be gained from using LLMs to put together like a curriculum that's like, personalized to things that work really well for you. And then the last thing, the book, I feel like that I got the most out of within my career thus far. A lot of the things that I like to learn are not necessarily like the really technical things that go along with the career. But I like learning about like how to, you know, what do you need to do to get promoted? What sort of things do you, you know, how do you build visibility within your organization? How do you write for software engineers so that it's something that they actually want to read? And one of the books that I think has been the best is the Software Engineers Guidebook, which was one of our, It was one of our book club books in the past by George Lee Urose. It's really good. Highly recommend it if you're looking for like a book on software engineering and all of those extra things that are not just like the hard skills that come with it. It's a really good one. Bethany (23:45) I think you all definitely vocalized all of my thoughts. Basically, especially the social aspect, I think that's what I miss most from college is just learning with other people. So I'm happy to have found something similar with you all. Yeah, I think I definitely learn a lot through reading. try to read at least one technical book and one non-technical book at a time. lots of books I've learned from. And I love YouTube videos because I'm usually scrolling through YouTube anyways, so it's kind of like, this isn't like work. This isn't tedious. So it tricks my brain into learning. Tech podcasts too are a lot of fun because I think you can do it while you're doing other things. It's like passive learning. I will share one thing I haven't done, so I don't know how it works, but something I'm thinking about implementing next time I need to learn a concept or want to like really do a deep dive into something is Notebook LLM from Google. Apparently it's really good about taking like a paper or a bunch of resources and distilling it into learning materials. sometimes you can, think I've seen people make podcasts from this learning material or flashcards from it, or like reworded in a blog post or something. And I really love this part of LLMs and AI is that for so long, especially when I was beginning, I would read through things like I have zero idea what this is saying. I, I feel so dumb. And so I love that there's this opportunity to take things and really rephrase it and work with it to help you understand it in a way that is more natural to you, like having a personalized teacher with you to explain things. So genuinely looking forward to that aspect of LLMs. Jon (25:36) Yeah. Erika (25:37) Yeah, I will say I the flip side of that for me is like, like I think they're super valuable for like rephrasing, reformatting information, like giving you, yeah, like almost like that discussion group, like the other way of thinking about things or like the different perspective that like unlocks it for you. But I think the caution, I don't think, I think I'm preaching to the choir here, but you hear about people using LLMs to cheat on tests or bypass certain learning steps. And it's not going to do the learning for you. You have to still know what you're trying to get out of it. And I think it's most valuable when you're aware of your own learning style and what you're trying to get out of it. So yeah, I mean, think that's awesome. I'm definitely going to try out Notebook LLM too. I haven't thought about it, thought about using it. But yeah, think the flip side of that is like, don't expect it to learn everything for you. And also, it's still not a personal teacher. It's only as good as the sort of. direction that you give it. Bethany (26:44) Absolutely. think that's a really good call out that you have to have a genuine desire to learn. I mean, I think after school, that's kind of true in general. You probably won't learn anything unless there's that genuine curiosity. But yes, it's no substitution for actually learning and digesting this information yourself. And I think really for me, the enticing part is I have always struggled with like academic papers. Erica, I think you were mentioning this too. A lot of the math symbols and such are really complicated. And I even was in PhD for computer science for a year and I still struggle so much with them. So I am looking forward to having like ways to break those down in a way that. makes more sense to me and maybe can explain like, what do these mean for somebody who's not used to seeing these equations or might not have taken courses around that. Jon (27:39) Yeah, and I think related to that is LLMs are good at helping you get unstuck. If you're working through a problem and you... I've said to it, don't tell me the answer, but this isn't working, this code's broken, or I need help. with this next step of this derivation, can you help me? And I think LLMs are really good at, in my experience, kind of getting you unstuck. But yeah, it is interesting. like, this kind of relates to like, do we need to, like what is knowledge? Like what's the value of knowledge if like we have these LLMs? What can we just like delegate to tasking an LLM to do versus what should like we have a mental model of or have a working understanding of? I think it's different for obviously different topics. Okay. Well, great. is, I mean, this is like, this conversation is perfectly timed for me. Okay, so we're gonna go around and talk about Book Rex, maybe give a little intro to the book. It can be a book you've read, maybe even a book you haven't read, but I think it is cool, Anyone want to give this a go? Bethany (28:45) Is this tech books or any book? Jon (28:49) I will say any book. Bethany (28:50) Okay, then I would say currently I'm reading Pachinko, so I don't know how it ends. No spoilers, but it is so good. Like, I don't want it to end. It's very, very good. So I think I'm just gonna wholeheartedly recommend that. My favorite fiction book is probably Piranesi. I don't think many people have heard about it and do not search anything about it going blind and it is such a cool book to kind of... it's a vibe. You'll see. For tech books, we recently read one with Book Club called Thinking and Systems and I'm hoping to do a recap on the pod soon, but it was so interesting. I feel like less technical... than I was expecting, not really because it was less technical, but just because it applies to so many aspects of life and especially with situations we're in now. It was fantastic. And if you are beginning in tech, one book that really changed my view on like more algorithms is Algorithms to Live By. I feel like it just really breaks down a lot of things that people try to overcomplicate into stuff that you can really relate to in real life and such. And I recommend it to anyone who's starting out, anyone who has any desire to understand algorithms who may not be in tech. It's a great read. Jon (30:09) Great. And I just want to say, think fiction books can help you in work because I think in fiction you're sort of learning about people and a lot of work in the tech industry, just in general. And just life is dealing with people and interpersonal dynamics. Erika (30:24) Sort of similar to what Brittany was talking about with the software engineer's guidebook. I I find books really valuable that sort of help build mental models. I think they're great as references, but super technical books where you're learning about a specific concept, it's... I don't know, like the exercises are more valuable than the book itself. So like I've gone through some books and they're only as valuable as the exercises. So I don't even think of them necessarily as a book. I think of it as like a workbook or something like that. But I think the one that's sort of up next for me is one called How to Solve It. And it's sort of specifically building that problem solving muscle and yeah, kind of learning how to like crack any puzzle. So that's yeah, that's the one that I'm interested in picking up next. Let you know how it goes. Brittany (31:20) I already mentioned the Software Engineers Guidebook, which I said was like a really great guide. think for anybody who's getting into software engineering and just wants like a career guide, that's a really good one. think one of the other ones that is really high on my list of like books that I feel like I think about a lot is The Chaos Machine. I think Erica, you're the one who actually recommended it to me initially. But if you're at all interested in algorithms, particularly social media algorithms, I think that that's a book that pretty much every software engineer should read at some point because a lot of the things we build are changing the world and it has a good way of showing how that world has changed. And the last book I'm reading right now and is incredibly good is called Cosmos by Carl Sagan. I know that's like actually an older book because it was written in the seventies. But I've been reading that pretty much every night for the last week or so. And it's been kind of therapeutic in a way to like remember like, yes, we are on this earth that is spinning in space and like the universe is vast and there's a lot going on out there outside of things that feel really, really big right here. So that's been good. And also, I don't know, it's healthy, I think sometimes to remember the reality of the universe. It's also just been really good. It's been really interesting. Jon (32:34) Yeah, next. So I read a book called The Little Book of Aliens earlier this year, and it made me want to go... So it's about like, it's this astrophysicist talking about human search for aliens. And then it me want to go look at the stars. So in two weeks, Nikki and I are going to Joshua Tree when there's a new moon. I believe that's the name for it. Well, basically when the moon's not in the sky. And then we found this guy with a telescope and we're going to go look at... stuff. So hopefully we'll see stars and planets. But yeah, space really puts in perspective. But yeah, in my book, Rec, I'll say is Designing Data Intensive Applications. that the title? Anyways, this book was like my first time really like, I read this, don't know. Wow, maybe five years ago or some... But I come back to it all the time. just, it was my first time like really interacting with distributed systems and like it's practical and it does a great job of explaining kind of the different problems, like the main problem. And think having a good mental, especially working in distributed systems, having a good mental model of just like, this can happen, know, clocks can drift and. know, machines could fail and consensus needs to be maintained and all this stuff is like pretty, pretty useful, cool. Okay. Well, with that, I want to say thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, and do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, our social media app of choice. Most of all, share with your friends. Until next week. Bye. --- ## Episode 8: Ep. 8 | Technical Debt Prioritization - URL: https://overcommitted.dev/ep-8-technical-debt-prioritization - Published: 2025-05-20 - Topics: Technical Deep Dives, Leadership & Management, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/102614271/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-4-13%2F400204298-44100-2-dc7add09d8926.mp3 ### Show notes The crew chat about what tech debt is and how we have prioritized it in the past. Hosts * ⁠⁠⁠Overcommitted.dev⁠⁠⁠ [https://overcommitted.dev/] * Bethany Janos: ⁠⁠⁠https://github.com/bethanyj28⁠⁠⁠ [https://github.com/bethanyj28] * Brittany Ellich: ⁠⁠⁠https://brittanyellich.com⁠⁠⁠ [https://brittanyellich.com] * Eggyhead: ⁠⁠⁠https://github.com/eggyhead⁠⁠ [https://github.com/eggyhead] ### Transcript Brittany (00:00) Welcome to the Overcommitted Podcast, where we talk about our commits, our commitments, and some stuff in between. I'm your host, Brittany, joined today by Bethany and Erika We are a crew of software engineers that met at GitHub. We first connected as an onboarding group on the same team and have since scattered elsewhere. But we discovered our shared passion of learning and building cool stuff. So we still like to come together and share what we're learning and explore our life as developers. Whether you are committing code or committing to new challenges, we are glad you're here. Let's dive in. Today's episode is going to be about technical debt. And we're going to talk a little bit about how we prioritize it, how we decide what is worth prioritizing, and how our opinions of it have changed over time. So let's set the stage first and describe what technical debt is or tech debt. Really it is a classification of work that doesn't necessarily work towards a specific feature, but is decisions that you have to make typically while building out features, often while building something very quickly that you accumulate over time like a debt that needs to eventually be either repaid or somehow offset. So for example, if you choose to write really quickly without any unit tests, eventually that technical debt is going to come back to bite you when you don't have adequate testing as an example. So let's talk for a little bit first about how we prioritize technical debt repayment against new feature development. Erika, did you want to talk first? Erika (01:34) Sure, yeah, I'm super excited about this topic because it feels very present in a lot of the work that we do and is kind of this unspoken or spoken like monster in the closet in a lot of development projects that it's always there and it's... like never in my experience like directly addressed. So prioritizing it in the scope of a project typically has to serve some purpose of the project, which, you know, to be fair, makes sense. Like if there's some kind of tech debt that's blocking you from developing the feature or will... unlock the feature development in some way, then that's prioritized as a part of the project work. Some recent examples, we had some feature flagging framework changes that we needed to implement for one of our projects. And it was blocking the ability to roll out those features safely. We tackled it as part of the project work. But unless we had that active pressing need, we probably would have pushed it off. So that's been my experience of addressing tech debt. Otherwise, it comes in through customer support requests. And if it's of a certain severity level, and causing some kind of problem or a part of some kind of problem for a customer experience, it'll get picked up as a part of some kind of first responder or shield rotation. But a lot of times, those tend to happen very quickly. It has to be completed within the span of a few days. So tech debt usually sits around for longer. What about you, Bethany? Bethany (03:18) Yeah, so I was recently at an offsite with my organization and they did it kind of conference style, so our VP gave a keynote on the second day and I thought she had a really interesting take on this with explaining how there's, I believe she called it polarities, whereas in some phases of growth, you've got to focus on really pushing the needle at all costs. And sometimes this is building up that tech debt and like building up that debt. But then at other times, you really need to focus on that reliability aspect and paying down that tech debt. And there's like phases of your development cycle where you're actively focused on that side of things. I think that With prioritizing technical debt, if it was up to engineers, that's probably all we would prioritize. It's really about, Erika, to your point, leadership buy-in and product buy-in. Because if doing something isn't going to meaningfully push your product in a certain direction, then it likely won't ever be prioritized by the business. So you either have to find out how it will impact your product in a good way. convince your product team or leadership team of that, or maybe advocate for gardening weeks or something like that where engineers can kind of go after things that have been bothering them and have a time boxed section where they can just go after things that they're interested in fixing. Brittany (04:48) I like that phases approach because I feel like it kind of speaks more to the debt word as like leverage where, you know, you're really leveraging that tech debt so that you can move faster. And theoretically, you know, pay that off at some point in the future. Although I have yet to see a really solid example of how to do that other than like fixing something that's directly causing a Otherwise it can be really hard to. really hard to prioritize those things. And honestly, think also, I think as engineers, like you said, we would continuously prioritize that over anything else if we could. And I think that we kind of overvalue like the cleanliness of code. You know, I think a lot of people are like, Hey, I think that if I, if we clean this up and refactor this, we'll be able to move so much faster. But I feel like I haven't actually seen that like in practice translate to people actually moving faster because they always end up accumulating. more tech debt in some other area to be able to do that. So, wow. Erika (05:43) Yeah, definitely it always feels like the engineers are like requesting buy-in for paying off the technical debt. But I did recently, and maybe you both already know about this, read about like, I think it was Jeff Bezos when he was... on, well, he made some kind of mandate at Amazon about a modularization approach. And it was a top-down mandate that every team needed to modularize their service area, or otherwise they would get fired. And it really struck me as something, I mean. questionable approach to leadership, you know, it struck me as the opposite of what I've a lot of times experienced where the reason for modularization is often this like circular dependencies and you know, like that affects availability and code maintainability. And so like to me that was, yeah. like addressing the tech debt from a top-down perspective saying, look, we're not actually going to be able to maintain this code base or this site if we don't fix this issue. And yeah, so I guess sometimes there are experiences where it does happen in the opposite direction. Yeah, but it has to be serving a higher purpose. side availability or, you know, maintainability over the longer term. Brittany (07:14) That's really interesting. I've never heard of a mandate from a CEO at that level for something like that. And I think there's probably value there for having everybody pushing in one direction. think in a lot of the roles that I've worked in, a lot of people are a little bit afraid to tell engineers how to solve a problem. And sometimes I think having a little bit more direction that the entire company is focused towards isn't probably a bad thing. Like everything in software, it depends. What approaches have you found effective for preventing tech debt instead of just paying it off? Is there a way that you can just not accumulate this in the first place? Bethany (07:48) so product managers close your ears for just a second. I personally find that, whenever I'm asked to engineer something or like asked for an estimate for how long something will take, I'll actually go 20 % more to 50 % more. I mean, one for being able to like handle, unknowns and such. But also, was during a project I was working on within my past company, and me and the other engineer working on it decided that we were going to allocate 20 % of our time to table stakes, we called it. And so this was like unit tests, like making sure everything made sense, like thorough code reviews. load testing, things like that, that really made the difference for cleaning up that tech debt before it could really aggregate, especially for like a greenfield project where we're starting out from scratch. And so I really like those kinds of approaches for like factoring in technical debt to the actual estimation. And if things need to be cut down, then it can be a discussion from there. But if you're just asked for an estimation, include the stuff that you think is important in that estimation. Erika (08:59) think I'm with you. I'm terrible at adding estimations or adding on to estimations because I always get nervous that somebody's gonna like question me even though I don't think anyone ever has. But yeah, I think sort of what we've been saying like I also like the idea that like Maybe the better approach is not to not introduce any tech debt, like minimize the amount that you introduce with the understanding that like, if you have a little bit of tech debt that you carry over into the next project, you can find time to address it. cause yeah, the only way I've ever found it, not introduced any tech debt is to not write any code or move it such a slow pace that nothing ever gets really completed. Bethany (09:47) Yeah, I totally agree. think tech debt is the most effective when you are intentionally choosing to take on that tech debt. So, I mean, similar with real debt, there's good debt and bad debt. Bad debt tends to be the unexpected debt that comes. And then good debt is things like build your credit score or buying a house or something that brings you value. get a house in exchange for debt, I guess. So I think the same goes for software. That flagging tech debt as it's happening, saying, okay, make sure we're all aligned. We are choosing to not do this in favor of going fast or getting to market sooner or X, Y, Z and making sure there's buy-in across all. product and design and whatnot on that decision because it should be explicit what the trade-offs are. Brittany (10:39) I like that. Have you, switching gears a little bit, have you ever inherited a code base with significant technical debt that you didn't create? And how did you go about approaching that? Bethany (10:52) rewrite the service. I know. I think whenever you inherit a code base and it is nearly impossible to work in without having the context of the people who initially built it, I all code serves a purpose and even if it's messier, has a lot of tech debt, it got you this far. But if the choice is that you inherit that code base and you cannot properly operate in it, then sometimes it's just easier starting from scratch rather than trying to get all that context back or all that, clean up all that tech debt that you're not even aware of or that you know of. Erika (11:35) Yeah, I think I've been pretty lucky. Like, I haven't necessarily worked in too many code bases that are geriatric and unwieldy. So yeah, I feel like I know, I've like read about this, of like how to address tech debt and like sort of the guidance is like start somewhere. Yeah, like you can't fix everything all at once, like make meaningful changes where you have to work and then like eventually you'll pay off the, pay off the debt. yeah, but thankfully I haven't had too many experiences personally working that way. How about you, Brittany? Brittany (12:13) the name geriatric code bases. think I'm going to use that from now on. I love that. Yeah, this also doesn't happen very often for me. think the case where this is probably going to come up is if you are inheriting a code base that isn't like... actively being worked on because most of the things that are actively being worked on are things that, you know, people are using regularly. And I don't know. I have strong opinions. This kind of gets to the next question. I have strong opinions about review rates in general that continuously get stronger over time and I feel like I've never been a part of one that was truly successful in the sense that net we saved more time than we would have spent trying to slowly refactor this code base and get it into a spot where we can add all the new features that we want. And so. I think of that as like the engineer in me really wants to reach for that, but then the person who cares about like product and like serving customer features is like, no, don't rewrite it. Don't, don't, don't. lean towards that because it's going to take longer than you think. And like I said, I think that people kind of overvalue the cleanliness of code in terms of getting things done and the amount of bug fixes and band-aids on an existing code base that like, they might be band-aid fixes, but like they fixed an actual bug that people are going to use. like you still have to deal with probably that same bug when you rewrite it because it's just the nature of how your service works. So. Yeah, I think, my approach... is yeah, to just do iterative changes and also just accept that some things are going to be hard and like, it's never going to make sense to rewrite it. You know, some things work perfectly fine, even if you don't really want to touch them. and I've definitely come across those before where it's like, man, it really sucks to make changes in this space. And it'd be so much nicer if we could just go through and redo it all. But like that would be a multiple month project just to give feature parity to customers that could spent doing something like delivering a new feature or something along those lines. ⁓ Erika (14:10) Yeah, I also think with like free writing, it's hard to communicate the value unless you have a really clear vision of what needs to happen. So like we did actually do something in my org recently that was addressing a major area of tech debt. And we had like this process like I work on the authorization team. So a process of setting up a token for authorization for a user or an application, and the process of creating a new token for any service owner was lengthy, complicated. It took multiple days, spanned multiple pull requests. And again, we had this big initiative coming up that we were saying like, we don't actually think that this is going to get completed unless we address this process and make it easier. And this had been a pain point for a really, long time. And several engineers on the team had a really clear idea of what to do, get rid of the database transition, make these in memory. You know, those were kind of the major changes and then, you know, put it all in a central location, and improve the documentation. Like, I think those were basically the biggest things that we changed and it was super successful. but I think if we hadn't felt that pain for so long and we hadn't, well, I don't know if like length of time is necessary, but if we, if we didn't have that design of this is what is really wrong with this system and this is how we're going to change it. I don't think it would have been nearly as successful in the redesign. And it actually didn't take that long. It took a few months. But yeah, so I agree with you that sometimes it's better to rewrite it, start from scratch, but I think only if you know you're going to make it better and like, how you're gonna track, like what is going to be better about it. In this case, it was like time to create a token. Bethany (16:08) really love that, like, making sure you have data on what specifically you are looking to improve or what you're looking to do. To, I guess, go back to the house analogy or even a car analogy. If your car has enough damage that it's not worth it to fix it, you buy a new car. You don't continue trying to fix a car. that it's just not worth it to fix. Same with the house. Sometimes you've gotta, there's so many changes that you wanna make to the house that it's as worthwhile to rebuild it from the ground up. Sometimes you do that, but a lot of times you also don't wanna do that. You wanna just make smaller changes. So it very much depends, and I agree with that. people do reach for rebuilds a little too much or think, this will solve all our problems when in fact it's just going to create a class of new problems. But if you are very aligned on what you're trying to fix and what your goals are, I think it can be very successful and very good to know what the cost is of choosing a rebuild over continuing to just build on top of this. other service or adding incremental changes. Erika (17:21) because I've also been a part of some tech deck conversations that feel like you're, what is it, like moving the deck chairs on a sinking ship or something, like you're like, okay, we're doing this thing, but like, what is it actually accomplishing? Like, or, you know, we're like changing this color arbitrarily. Like I prefer yellow over green. Okay, like it's not really worth doing. So. Yeah, tracking the outcome is definitely important. Brittany (17:50) Yeah, I think the other thing that I really like about that example, other than having the clear goals, which I agree is super important before approaching a rebuild, is the time that you spent to think about the solution. know you said that you don't necessarily, there's not like a set amount of time, but I think that also gives you more time to digest what the actual problem is and come up with a plan that is very clear and straightforward to implement and that you'll be able to know in advance is going to actually fix the problem. Yeah, taking time to stop and really think about what the goals are that you're trying to achieve and also what is like the right solution is good. We are approaching time. So I would like to ask if there are any other hot takes or changes that you've had over your career when it comes to thinking about technical debt. Is there anything that you think, you know? is really key. think one thing that comes to my mind is I think that tech debt is probably the most exciting area when it comes to AI agents right now, where I think that that's going to get me a lot more excited to try out AI agents. if I can have it address tech debt, I think that that's something that I'm pretty excited about and actively looking into. Any other thoughts on the future or how tech debt is changing over time? Bethany (19:07) Mine would be that I guess when I was starting my career, I very much interpreted Tech Debt as only technical improvements or like technical setbacks. So like not including tests or having a monolith, which is a bad example, but was an example from a past job. But I think there's also another level of Tech Debt in that. like how the code was created or how understandable code is. I think maintainability absolutely is a concern of technical debt or a trade-off of going faster or whatnot. If you're rushing to create a feature and you don't have time to go back and make it not as complex or not as hard to understand. then I think that's absolutely a side of tech debt as well. If people are afraid to go into your code, that's a sign that you've got some tech debt. Erika (19:59) Yeah, I think similarly, like I had a more narrow view of TechDat when I first started. like, I almost think of it now as like drift from the like ideal representation of your model. And yeah, that's more conceptual than practical, but I think like, Like you were saying, Bethany, like ideal state is that your code represents your model, like system model, business model perfectly. But you're not going to get there probably ever. So the best thing you can do is recognize the places where there's a drift, where there's a mismatch. And yeah, those are your areas of technical debt. Brittany (20:40) Nice. All right. With that, we are going to go to our fun segment. And here is what I have prepared for today. So we are going to do a word association. What I'm going to do is I'm going to call on a person and say a tech or corporate-y buzzword. And you have to say the first thing that comes to mind in like a single sentence. And we'll see how that goes. So I'll start. with sorry go ahead Erika (21:05) Is this like, so this is like free associating? Okay, cool. I can do that. Brittany (21:08) Yep. Yep. I mean, it doesn't have to be tech related either, but the words that I'm choosing are all like tech buzzwords. ⁓ Yeah, I'll start with Bethany. Okay, the first term is tech debt. Erika (21:16) you Bethany (21:23) a clean up or garbage collection. Yeah. Yeah. Brittany (21:28) I like that. I like the term garbage collection applied to tech debt, actually. Bethany (21:33) I feel I used to listen to Go Time all the time, RIP, I still wish it was here. But there was an episode where they were talking about Tech Det and they were like, some people just loved working on Tech Det only and should be like, like some people love being garbage, garbage collectors and stuff and it's like interesting association there but. Brittany (21:54) Yeah, it's like a garbage collector for your projects. Bethany (21:56) Yeah, valuable position and some people do just love it. Brittany (21:58) true. All right, Erika, your word is synergy. You don't even need to say a word, just the face was enough. Erika (22:04) face is saying at all. Like corporate. I've never heard anyone use that word in like a personal context. It's always been like some gross, like, sorry, corporate corporate like buzz speak to be like enhancing synergy. Brittany (22:07) Makes sense. really? Yeah, I feel like it's along the same lines as like flywheel. I feel like you only hear that in... Okay, Bethany. Blockchain. Erika (22:23) Yeah. Bethany (22:28) meme coins, I would say. It's so unfortunate. Blockchain's very good technology that got so, so abused. Brittany (22:37) I agree. Erika, cloud computing. Erika (22:40) Hmm. expansive? Yeah, like I feel like the clouds are super cool. super cool development in computer technology that like really unlocked a lot of potential. Brittany (22:50) Yeah, I agree. Bethany? AI? Bethany (22:52) Google I.O. Do y'all remember that like a video of Sundar Panchayi that was like AI AI AI AI? Brittany (22:59) No, actually I do. Yeah, somebody cut together all the different times in their keynote that they said the word AI. Bethany (23:04) Yeah, it was all that, which is sad. I work on an AI product, but that's still what I think about that meme. That's so funny. Brittany (23:09) Mm-hmm. Yeah. Erika, pair programming. Erika (23:16) Ooh, rubber ducky. Brittany (23:18) it. Bethany, here's the last one. Design. Bethany (23:21) not something I do a lot. I'm a back end. So I guess it's more like architecture than is my design process than like UI UX designers. But I am taking that design course and I'm learning. I'm learning. Yes. ⁓ Brittany (23:34) Ooh, that's awesome. Erika (23:34) Woo! Brittany (23:36) Nice. All right. Well, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or whatever it is that you do on your podcast app of choice. I know they're all different. Check us out on Blue Sky, and most of all, share with your friends. Until next week, thanks for joining us, and stay committed. --- ## Episode 7: Ep. 7 | Decision making - URL: https://overcommitted.dev/ep-7-decision-making - Published: 2025-05-13 - Topics: Leadership & Management, Product & Engineering Collaboration, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/102561642/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-4-12%2F400118107-44100-2-e5192e0629e19.mp3 ### Show notes The crew chat about how we make decisions and prioritize things as software engineers. Links * ⁠Clean Architecture [https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164] * One-way vs. Two-way door decisions [https://medium.com/one-to-n/one-way-two-way-door-decisions-a0e29029e200] * Sam Altman: "The most important thing is deciding what to work on" * Architecture Decision Records [https://adr.github.io/] * MoSCoW Prioritization [https://www.productplan.com/glossary/moscow-prioritization/] Hosts * ⁠⁠Overcommitted.dev⁠⁠ [https://overcommitted.dev/] * Bethany Janos: ⁠⁠https://github.com/bethanyj28⁠⁠ [https://github.com/bethanyj28] * Brittany Ellich: ⁠⁠https://brittanyellich.com⁠⁠ [https://brittanyellich.com] * Eggyhead: ⁠⁠https://github.com/eggyhead⁠ [https://github.com/eggyhead] * Jonathan Tamsut: https://jtamsut.substack.com [https://jtamsut.substack.com] ### Transcript Erika (00:00) Hey everybody. Welcome to the Overcommitted podcast where we talk about our commits and our commitments and some stuff in between. I'm your host Erica and I'm joined by my fellow code enthusiasts, Brittany, Bethany and John. We are a crew of software engineers at GitHub. and we first connected as an onboarding group in the same team and quickly discovered our shared passion for learning and building cool stuff. So even though we've scattered across different teams, we still come together regularly and geek out about technology and share what we're learning and explore our life as developers. So for you, whether you're committing code or... Committing to new challenges, we are so glad you're here. So let's dive into today's topic, which is decision-making as an individual and a team. We know that in the world of software, making smart choices is super important. It touches everything from how we work together to what we tackle first, prioritization or how we build things in our architecture, how we deal with bumps along the road, risk management, or keeping everyone in the loop, those stakeholders and stakeholder management. And we also know that getting these areas right means smoother workflows and the feeling of focusing on what's really mattering most, building solid foundations for our systems and staying ahead of potential problems. But given the pace and pressure of development, the number of decisions we make on a daily basis can feel absolutely overwhelming. So one way to Think about decision making is to introduce some models or frameworks. And we're going to talk about some of those today and how we might use them, where they might be appropriate, where they might be better left to the side. So these models and frameworks vary based on the level of team involvement, the speed that you're operating at, your data reliance or availability of your data and also the roles and the clarity of roles on your team. And can include anything from choosing a leader to decide, requiring absolute consensus or gathering conclusive, comprehensive data to support a direction or delegating the decision to a separate team. So the first question for the group is to describe any decision-making models that you use or that your team uses to help you in your work. Jonathan Tamsut (02:29) I can start. So I think that maybe this is a good baseline. think very often I feel overwhelmed and maybe a little I panic or just feel like, you know, there's just so many available options and I can convince myself that it doesn't really matter. You know, I'm trying to think of an example like, you know, if I'm working on a project. what I start first, you know, and I can just feel overwhelmed and I sort of arbitrarily choose and, you know, that's kind of just a response to just feeling totally overwhelmed. So I think, you said, there's, you know, there's definitely information fatigue. There's a cost to even grappling with decisions. And I think, yeah, that's definitely something I have in my back pocket. Just make a choice arbitrarily. And as long as it's... You know, you can back out of it if it's just absolutely the wrong thing. You can just, you know, you just get going. Erika (03:26) I could identify with that. Like the choices, choose a direction and see where it takes you. Yeah. And you mentioned some of the reasons for that, feeling fatigued or overwhelmed or like a lot of times we have these time pressures and like we're getting a lot of... Jonathan Tamsut (03:27) Hehe. Erika (03:43) messaging from our stakeholders that needs to be done yesterday and so make this decision as fast as possible. So yeah, there's definitely that inclination to make any decision. And I guess sort of the model in that scenario could be described as the leader decides model where you're delegating yourself as the leader and Jonathan Tamsut (04:05) Mm-hmm. Erika (04:07) You make a decision, you see where it goes, and it's totally valid. Jonathan Tamsut (04:11) I also think sometimes people delude themselves into thinking they're making a really well-informed, thoughtful decision, but it's like, there's so much complexity here. It's like, is it really even possible to really, everything, I think one thing is like an engineering, everything is trade-offs. it's like, often I think people who, I think to an extent, or I've seen this, is people who have quote unquote good decision making are just people who make decisions and then kind of advocate for their decisions. And then people who are perceived as having bad decision making will make a decision and then like openly question whether that was a good decision and be intellectually honest. So yeah. Bethany (04:49) I am very much an indecisive person. And so I always really struggled with this. you're just, mean, going back to our conversation on imposter syndromes felt almost like, like I was like, well, what if I make the wrong decision? And so hung up over that. And so one thing that actually helped me was when I read Clean Architecture, there was, a big message there about trying to postpone any technical decisions or choices to the very last minute possible. But it was helpful to be like, OK, prioritize focusing on core business requirements and then decide on the technical things later. As engineers, love bike shedding, as they call it, on a lot of small things that don't actually meaningfully move the product in a great direction anyways. And so that always helped me with how to decide or like when to decide, make decisions. And the second thing is that I always try to optimize for reversal. So what is the easiest decision to like go back out of, which I think John, you kind of mentioned in your decision making process, which I definitely resonate with. I think final two is that there are a few like, Context of decision-making so like you can make slow decisions or fast decisions effectively. So My decision-making I think is different in say an incident response situation versus a I'm writing an ADR or I am working on a feature that has more time because in a In a incident situation, you have to kind of make fast decisions to meaningfully move get out of that situation. So It's all about kind of evaluating what our options are in that scenario and what we need to do. So I think there it's helpful to just like list out literally all the knowns and then try to say, okay, we haven't done this. This will help us the most now. And so go after that. Brittany Ellich (06:38) Yeah, one thing that comes to mind, speaking of... just making the decision is the concept that I learned of. think it's from Amazon. They do the one way versus two way door decisions where a one way door decision is really hard to reverse. And so those ones you want to try to avoid that type of a decision if you can. But if it's a two way door decision, just like make a decision and move forward with it and you can adjust as needed because you know, it's easy to reverse and easy to undo. And sometimes just getting the decision out the door and starting to act on it is more important than waffling back and forth if you don't really have much to compare the options. Erika (07:14) Yeah, think another element here is having that data and knowing what you're comparing against or knowing what you're going for. And it's a little bit freeing for me to think that you can make a decision without having all of the data. I definitely fall prey to the analysis paralysis and like... I can't take any action until I know everything that there is to know. And sometimes it's like frankly not available or it's going to take more time to get to the point of fully understanding the problem before try something, see if it works. So yeah, think like knowing that about myself is probably helpful in my own decision-making process. When I approached Decisions as a team, you were kind of mentioning this to Bethany with the incident commands and the incident decision-making. And we were talking about that a previous week about collaboration on incidents versus collaboration in project work and how it's a really sneaky way to really reflect the dev lifecycle and a really condensed experience. And yeah, it calls to mind too, this sort of like undervaluation, I think, of clearly defined roles in team decision making. And when I've been on incident calls that have gone really well, people know what they're doing. They know who's making the final decision. People know who's investigating, who's supporting. know, so I think that that can then... be taken back into project work or project planning and like used in those sort of slower decision contexts too of let's take the time to identify who's who. If we are using a leader to decide who's that leader and then what is everyone else doing aside from commenting on your architecture decision review, you know, like if you need support like. identify those people and what they're doing. So I think that's a really good call out. Cool, so another very specific use case for decisions is prioritization. And so let's talk about that for a little bit. When you are prioritizing work, what do you use to decide what's the most important and what to leave behind? Jonathan Tamsut (09:31) So I worked at a startup and we failed. By fail, I mean we basically ran out of funding and had to fire everyone. And it's interesting because I feel like prioritization is a lot easier when you know what to do, what's most important. Oftentimes it's kind of just difficult to even answer that first question. Like what are the tools I'm using to evaluate the importance of something? So like in the context of this startup, like we just didn't really know what customers wanted and we never found product market fit. And we had ideas and we tried to validate what had just never happened. And maybe it's possible that like there just wasn't ever gonna be product market fit in sort of the space we were working in. Yeah, I mean, I think prioritization is super, super important. And I think when you work at a big tech company where There are just so many competing interests. You learn the importance of prioritization and what it gives you is focus, which is just so important. Erika (10:28) So I did look up some frameworks that teams do use for prioritization because I also feel the same way. One of the frameworks that I have used before most often was on this list and that's the must have, should have, could have and won't have, where you look at a list of features and tag them as things that... are required for ship, nice to haves or like cut line. But I've always found that to be very subjective and arbitrary. And I almost feel like I need like a pre framework to get to that point. So some other frameworks that people use are this idea of reach, impact, confidence and effort. understanding for each item, like how many users will it affect? Will they even notice? Will it meaningfully impact their experience? How confident are you in the delivery? And then what's the level of effort for that feature? There's something called the, I don't know if I'm going to say this right, the Kano model, Kano, K-A-N-O, which... like you were saying, specifically focuses on customer satisfaction. There's cost of delay, which is focused on the economic impact of prioritizing or deprioritizing a feature and uses return on investment metrics. And then there's value versus effort, which uses a two by two matrix where one matrix, one. Axis is value, the other is effort, and you place items along that matrix using those two guiding principles. And then there's also weighted scoring, where you identify your own criteria and then assign weights to different issues. So yeah. Jonathan Tamsut (12:09) And I think, know, like, there's no, like, I feel like there's a, like, I always end up in the sort of a philosophical sort of hole where I try, I mean, I try not to because I think if you get too philosophical, you won't be productive. But it's like, you know, same, same ultimate as a quote, it's like the most important thing is deciding what to work on because, you know, it's like the startup, like if you're working on a set of features, really, really hard and you're executing really, really well, but they're just not features customers want, you'll fail. it's sort of like, know, yeah, I do agree. Like, you know, I think, right, in hierarchical corporate structures, sort of these deeper questions get handed down, like priorities get handed down, but like, you know, it's like central to decision making. I'm always just like, well, why are we even working on this? Like, how do we want to shape the world? What world do we want to live in? And I think... I think those are the questions that are just interesting to me, but also I don't know the answers to. Erika (13:04) I'm laughing because I'm not at all shocked that you fall into philosophical rabbit hole all the time. Brittany Ellich (13:10) Very classic, John. ⁓ I like the idea of exploring some of those other models that you talked about, Erica. I also use, I think I've called it the Moscow. Erika (13:12) Yeah. Brittany Ellich (13:21) ones in the past, must, should, could, won't, but that doesn't necessarily take into account things like the effort to complete things. I have found, especially at GitHub, one of the things that I was a little bit frustrated on early on at GitHub is I feel like we don't have a ton of process and that's... part of the magic of why things happen. Like it's very low process and there's a lot of trust put in engineers, you know, to prioritize things. And early on I found that really frustrating and now I think I've finally found the groove maybe just with, you know, with the team that I'm on. I think I've got some really good. product managers to let me know, like, okay, these are the things that customers care about. So think that helps a lot. But I still use that must should could won't matrix now. I think I saw Belinda using it and she did a great job on a project that I was on and I was like, wow, this is perfect. But I find most of the time we can only really prioritize the musts and some of the shoulds. And usually the must is like, what do you need to have to like get through this critical path of this feature? get to a should but could and won't just means that they're probably not going to end up happening. So I think that you know keeping in mind that that effort is probably helpful because I feel like that's missing from that matrix but is helpful. Erika (14:32) Yeah, I feel the same way. think the Moscow method is very helpful as a communication tool, but maybe sometimes lacks, like I said, the... like the information that goes into it. And sometimes it's a product decision that'll say, like you said, the customer needs these. These are the features that we won't ship with or ship without. But sometimes you as an engineer are asked to prioritize. And in that case, you have to take in mind some of those other factors. So yeah, I'm also interested in especially the... Reach, the acronym is RICE, the Reach Impact, I can't remember the rest of the letters now. Reach Impact Conference Effort, thank you. That one, and then the two by two matrix with effort and value. So I think I might try out some of those in my prioritization. Jonathan Tamsut (15:12) Effort. ⁓ Confidence effort. And well, this, I find this interesting, but this may be derailing the topic. Feel free to bat me down here. But I feel like the social dynamics of decision-making is also just really interesting. You know, a lot of times in a hierarchy, people's opinions and input is not weighted equally. And for a variety of reasons. And I think I always find that interesting. There's also, and you know, people get incredibly emotional in the process of decision making. There's, you know, I would argue maybe we all do, right? We all want some level of validation. And it's also just like hard. It's, it is hard just proposing something and then having people in a totally like respectful and objective way just be like. I know, no, no, this is wrong, this is wrong, this is wrong, and make valid points. There always is a part of me that's like, God, this hurts. And I know I shouldn't be, because it's just like, this is sort of like civil discourse. But yeah, think that's, and you know, people's egos certainly are involved in a lot of these decision-making processes. Erika (16:32) Yeah, it calls to mind something else I was hearing about, like the use of AI in software development and the idea that, like... One thing that's really important in this phase of AI adoption is recognizing your own role in using the AI assistants and recognizing that your taste is actually really a valuable piece of the puzzle. And if you're using AI assistant, like, It's kind of a coworker, it's kind of a collaborator, but like, I mean, people have wonderful, wonderfully creative descriptions of the personality traits of AI coding assistants. yeah, like knowing how to respond, like, do I reject or accept this? Like, how do I respond to you? Yeah, it's not exactly what you're talking about. I think you're also talking about like hierarchy, but like... Co-pilot doesn't, co-pilot for example, like doesn't even have a role on the team. And like maybe the point to this discussion is like, don't elevate co-pilot to the, you know, level of CTO in your own life. Like recognize that like, okay, like I am still like in charge here and my role in that development life cycle is to like give you more guidance or like. Jonathan Tamsut (17:42) Hmm. Erika (17:53) make sure that I'm still thinking about like the output that you're creating. Jonathan Tamsut (17:57) Yeah, I also do. Yeah, I mean, and I think that's actually really interesting. And like, certainly it's like, it's like, you know, what is AI good at? What is, what are humans good at? And I wonder if AI is just better at making objective decisions when, when given a collection of evidence. You know, it's like, I haven't really used AI for like decision making. Like here's, here's, here are all the countering points. Tell me what is best and, you know, and explain why. And I do wonder if like, sort of a benevolent AI overlord decision maker is something that we'll see more of and that'll be useful. Brittany Ellich (18:29) I think that kind of goes to what you were saying earlier, where sometimes it's easier to just make a decision. And if you're using an AI tool or just asking a friend, like, hey, which one of these would you choose? Either way, just having the decision made and then committing to it is usually the most difficult part, even if you already know all of the weight going into the different options. Jonathan Tamsut (18:33) Mm-hmm. Erika (18:47) Sure. Well, I have one more question for the group before we move on to the ending segment. And this is about a very specific decision. context, but it seems pretty relevant in a lot of projects, a lot of engineering teams use architecture decision records or ADRs. And I'm curious what our experience has been with those. Have you found them helpful? If so, in what contexts? And yeah, what... what do you find most valuable in that process, if anything? Bethany (19:21) I think at GitHub, I mean actually not just GitHub, I think every company I've worked at has used ADRs not quite correctly. It's very interesting, I feel like ADRs often get turned into... not necessarily a decision record, but a pre-decision record where you're actually architect, like mapping out the architecture of what you're actually wanting to build and getting consensus around that and then committing that as your like decision record. But in general, I love ADRs. makes me, it's almost like writing a pro con list for developing, I think. So thinking of all the... solutions to solving a thing or architecting a thing and then just putting it on paper trying to defend each one as much as possible and then choosing what seems best or has the least impact or whatnot. So I really enjoy them. I do think as part of a process for engineering it's been a little difficult to insert into like a team flow because it's like does this require an ADR or does it not require an ADR? And then you get a bunch of opinions on that or ADRs that are just kind of stalled because there's not consensus on what is being decided and stuff. So I'm interested to hear your takes on ADRs as well. Jonathan Tamsut (20:38) And Bethany, so you said people use them incorrectly. do you just mean that they should be more like showing the decision making process as opposed to just like an artifact of the final conclusion? that what you basically meant? Bethany (20:54) yes, and I guess I didn't mean incorrectly. I don't think there's necessarily a correct versus incorrect, but I think, at the end of the day, an ADR should just serve to say, Hey, this is why we made a decision. And here is the context around that decision. If anybody is coming back and saying, why was, this happen? But to be honest, I don't notice many people go back to ADRs. Most of the Jonathan Tamsut (20:58) Okay. Bethany (21:16) activity around an ADR seems to be like before it's merged. And I think that's the interesting part that it doesn't seem to really, at least in my experience, serve as something to reflect on, but rather it's something, it's like an architecture design pretty much. And so I know on my team, there's been a lot of suggestions for switching over to maybe an RFC, which is a request for comments prior to making an ADR or even getting to the ADR stage. So it's really nuanced because it's just like a change of acronym it feels like, but it almost prioritizes, hey, this is just in the planning phases and I want people's thoughts around this rather than, hey, I've decided this so I want to merge this, which I think, John, to your point about people feeling very emotional about decisions, it's easier to say, hey, I want. your comments on this or your feedback on this to make folks feel involved in that over ending decision rather than, I've made this decision and now I need your approval on it effectively. Jonathan Tamsut (22:16) Yeah, and I feel like one concrete example of where this tension arises is ADR addendums. There's been times where during the project you realize your approach won't work. Do you write an addendum? And sometimes it feels silly because you're like, we all kind of understand what we're going to do, but maybe to a future reader, having that addendum will be useful. Erika (22:37) Yeah, I definitely don't share your love of writing ADRs. And I'm probably part of the problem of people who like want to get started and would rather write code than write documents. But I definitely agree that I think given the right scope and the right like purpose, they can be super helpful. I think in my mind like something else that I've seen to sort of like support ADRs as something like a pre-retro, like thinking of all the things that could go wrong as an outcome and then like going back and architecting for those. Because yeah, I think like a lot of times you want to capture what's known and that's actually not the most interesting part. Like the most interesting thing that you can capture is like, Okay, but how are we handling these edge cases and what is still unknown? what are, yeah, it's like valid to call out. These are actually things that we still need to figure out. So recognizing those as well. Jonathan Tamsut (23:33) By the should we define what an ADR is to people? Brittany Ellich (23:38) Probably Erika (23:38) Would Brittany Ellich (23:38) a good call. Erika (23:43) you like to do that, John? Jonathan Tamsut (23:44) Yes, so an ADR stands for architecture decision record and I mean as we've kind of discussed maybe there's not a concrete definition but it's essentially a document that is iteratively created before sort of the initial phases of a project that outline the architecture of the project and it could have multiple possible architectures and kind of compare and contrast them and ultimately make a decision on what architecture is the best and list other things like context and mitigating circumstances and observability, et cetera. And they're kind of just like the bedrock of how projects, engineering projects are trying to get hub. For large engineering projects, we typically started with creating an ADR and there's a feedback process and then it's finalized. Brittany Ellich (24:28) I think too this might be a... Artifact of the fact that like we don't have a ton of process at github is it I think it sounds like a lot of teams use them for different things like For my team usually we create an ADR with a couple of different options and then we use that as a starting point for Hey, let's talk about this and figure out what decision we should make so it's really great for things where you're trying to weigh the different options and decide on a decision and then folks comment on the document and then you know, save the the document and What decision came out? of the discussion around it into that ADR. And I actually refer back to them pretty frequently just because I feel like they're pretty helpful for seeing, okay, yes, this is why we made this decision and why we opted against this other option. And I think that is a really great background usually because just like gathering the background knowledge of like where the system is today and making sure that that's present in the document is helpful. I also feel like this is just one of the areas where engineers are. like most likely to actually document things. Which, you know, everything's pretty, you know, comically under-documented in general, pretty much everywhere I've always worked. So having something is usually better than nothing, better than trying to just, you know, struggle through reading the code base and figuring out where things are at. So I personally like them. Bethany (25:49) I'm curious, how do you just read through all the ADRs that you know of, or how do you map a decision to maybe some code you have questions about, or does your team have a process for that? Brittany Ellich (26:02) Yeah, so if I'm researching a new space, I'll usually search our shared repository or use our knowledge base. Knowledge bases are our thing, right, Bethany? Yeah, they're, okay, cool. Yeah, we have a shared repo where we keep all of our docs for like all of our team and we have a knowledge base. So I'll go in and ask. copilot and attach the knowledge base and be like, hey, what are all the relevant documents related to this? And it usually also turns up some ADRs. So if I'm curious about why something exists, then usually I'm only doing that if I'm trying to figure out a new space. They're not necessarily as useful otherwise, but I think it's really helpful for getting onboarded and getting up to speed in a new area of the code base or on a new team. Bethany (26:46) Yeah, I can definitely see AI being really good for searching through ADRs and kind of parsing through those and showing, flagging the relevant ADRs. That's cool. Thanks. Jonathan Tamsut (26:56) Yeah. Erika (26:57) but also somewhat dangerous if you're getting outdated information and it doesn't tag it as something that's been overwritten. Brittany Ellich (27:03) Yeah, mean, that pays, that I think exists regardless of whether or not there is an AI tool being used. I think you always have to read any documentation with, you know, a mind on when was this written and is this still accurate? You know, if it's two years old, then, you know, read it with some heavy skepticism, but there's usually still some relevant information, hopefully. If there isn't, then you're probably working in an area that changes very quickly. Erika (27:15) Yeah. Brittany Ellich (27:27) So good luck documenting anything. Jonathan Tamsut (27:29) Hmm. Erika (27:30) Thank you all so much for sharing your thoughts and experiences and opinions. To wrap us up today, I have some developer jokes, which are most often found in written form on the internet. But I'm going to read them out loud today in my best comedic voice. And I'm expecting some serious groans, but I... Jonathan Tamsut (27:47) Am I allowed to audibly groan? that... Erika (27:54) I think they're fun anyway. I know it was Mother's Day yesterday, but these are kind of dad joke, dad joke adjacent. All right, and we'll see if anybody can get the answers to these. All right, the first one is, what's the second movie about a database engineer called? Jonathan? Jonathan Tamsut (28:09) Yeah, as the database engineer, I should get this. Erika (28:11) It's called the sequel. Jonathan Tamsut (28:14) Oh, that's great. I'm going to I'm going to take I'm going to bring that to my team. Brittany Ellich (28:15) Ugh. Erika (28:18) It's okay, I've got another one for you to redeem yourself. Why did the SQL developer leave the no SQL bar? Bethany (28:27) because there was no tables. Jonathan Tamsut (28:28) ⁓ Erika (28:29) Yeah! Jonathan Tamsut (28:30) that's so good! Erika (28:33) Okay, okay. Why did the computer keep sneezing? Jonathan Tamsut (28:33) You Brittany Ellich (28:37) Is that a virus? Nice. Bethany (28:37) virus? Erika (28:38) Yeah. Jonathan Tamsut (28:39) and Erika (28:43) Okay. And Brittany, this one's for you. What did the proud React component say to its child? Brittany Ellich (28:48) I don't know. Erika (28:49) I've got to give you props. Brittany Ellich (28:50) I like that one. That was good. Erika (28:52) That's all I've got for now. Jonathan Tamsut (28:54) I- Brittany Ellich (28:54) I am Bethany (28:54) Does Brittany Ellich (28:55) so grateful. Bethany (28:55) your network? I sure hope it does. Erika (28:57) If you've got any good jokes, listeners, send them in and we can include them in a future episode. Jonathan Tamsut (29:03) Yeah, was, Nikki and I were trying to come up with a term for like our fans, like what our fan name, fan name should be. And we, yeah, just our parents. But our parents are Brittany Ellich (29:11) I think it's just our parents. Erika (29:12) Yeah, at this point. Bethany (29:15) Shout out mom, shout out dad. Erika (29:17) Well, for all you fans, thank you so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, our social media app of choice, and most of all, share with your friends. Until next week, bye-bye. --- ## Episode 6: Ep. 6 | How we build things - tools, tips, and tricks - URL: https://overcommitted.dev/ep-6-how-we-build-things---tools-tips-and-tricks - Published: 2025-05-06 - Topics: Technical Deep Dives, Developer Experience/DevRel, Productivity & Learning - Audio: https://anchor.fm/s/102586d64/podcast/play/101801614/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-3-26%2F399110704-44100-2-0f3fba16d12f.mp3 ### Show notes The crew chat about our current toolset for building things as software engineers. Tips and tricks for staying on track and building things with our teams! Links * Jaeger [https://www.jaegertracing.io/] * Visual Studio Live Share [https://visualstudio.microsoft.com/services/live-share/] * ⁠Overcommitted on Bluesky⁠ [https://bsky.app/profile/overcommitted.dev] Hosts * ⁠Overcommitted.dev⁠ [https://overcommitted.dev/] * Bethany Janos: ⁠https://github.com/bethanyj28⁠ [https://github.com/bethanyj28] * Brittany Ellich: ⁠https://brittanyellich.com⁠ [https://brittanyellich.com] * Eggyhead: ⁠https://github.com/eggyhead⁠ [https://github.com/eggyhead] ### Transcript Bethany (00:00) Welcome to the Overcommitted podcast, where we talk about our commits, our commitments, and some stuff in between. I'm your host Bethany, joined by my friends and colleagues, Erica and Brittany. We're a crew of software engineers at GitHub. We first connected as an onboarding group on the same team in GitHub Actions and quickly discovered our shared passion for learning and building cool stuff. Even though we've scattered across different teams now, we still come together regularly to geek out about technology, share what we're learning, and explore our lives as developers. So whether you're committing code or committing to new challenges, we're glad you're here. Let's dive in. So I love a bit of shop talk, and I think it never gets old hearing what others are using in their day-to-day development flow. So I thought... It might be fun to chat about our tooling since I feel like we haven't done that in a while. And I recently learned about some new dev tools that I'm really excited about and just want to hear what you all are using these days. So I figured we'd get started with kind of talking about what is your dev flow? Like what editor do you use? Any plugins or extensions? And then we'll go from there. Erika (01:06) Yeah, I feel like I'm pretty boring and I'm really excited to learn more from the two of you and what you're using or anybody who's like gonna comment on this podcast or provide any other suggestions or inputs. I currently use VS Code. I use basically language plugins. That's about it. I use Copilot now, but... don't have a ton in there. Yeah, debuggers. There's like rdebug in an rdebug plugin that you need to run some like debugger workflows and same for going when I'm working in a Go repository. There's like some Go plugins, language plugins that I use, but. Yeah, that's pretty much it. I'm pretty basic. What about you, Brittany? Brittany Ellich (01:53) say that I'm actually fairly basic as well. I also use VS Code. I'm using Codespaces because that's... any special extensions that I install. I know I always have Live Share installed just for when I am pair programming with somebody. Sometimes I have the GitHub Actions extension installed because that's really useful. I'm a logger instead of a debugger, which I know is shameful potentially, but I prefer to do logging instead of actually debugging and walking through something. depending on what it is. I feel like it takes less time to set up, usually, but maybe I'm just convincing myself of that so that I feel less bad about that decision. Erika (02:32) I can see the value there, because spinning up a separate debug server, a separate debug process can sometimes, I don't know, spawn some weird threads and stuff that you then have to manage. So if you're running logs, it's all running on the same track. you Brittany Ellich (02:58) Yeah, it's just another thing that can go wrong. So yeah, I usually don't use DeepBegger, but. Bethany (03:04) Yeah, I definitely think a debugger is super nice when you really know what you're doing or if you're very acquainted with the code paths and where your breakpoints are. But I feel like the bigger your app is, the more skill your app has, the harder it is to trace through it and just be like, step over, step over, step over. And so sometimes that's what I get myself into whenever I try to debug that. And I feel like I have to debug my debugger every time I try to debug. So I just end up logging anyways. Erika (03:38) I will say I find debugging really useful in unit tests if you can have, because it's like such a granular level that you don't have all those like middleware layers usually. So like if you're working on a hyper localized area or even in like some integration tests, but those you start to get into the like, oh, I have to like step over all this middleware and like this is not relevant. But like, yeah. Like if you're trying to figure out like why is this one specific method not working and like why am I getting a failure output in this unit task that I'm not expecting? Like I do find debugging useful there. And then you're also less susceptible to like application timeouts and stuff like that that tend to get kind of annoying. Bethany (04:23) That is such a good point. And something I haven't really thought about. Also, I feel like running a debugger for a test is way easier than trying to attach to a running process or anything like that. So that's a really good tip. Recently, which made me think of this idea for the episode, a coworker showed me Jaeger. Have you all heard of this? So effectively, it's like tracing. So it's like your Datadog APM, or if you use new relic tracing, or anything like that. It hooks into, if you're using Othel, it hooks directly in with barely any configuration. And so this past week, I've been debugging a really tricky problem. And it's just been so helpful to view the traces that we already have and the spans we already have in like, from what I'm running locally and it has been a game changer for doing that, which I think I'll definitely start reaching for that a lot more. Erika (05:20) So that, so Jaeger's like the server, right? And then, like how do you run it? Is it in production? Is it locally? Brittany Ellich (05:20) That's cool. Bethany (05:30) Yeah, great question. So, Jaeger, I believe, is just processing and displaying the spans. And so it is a Docker image that you just pull down and run. And as long as you're sending your hotel metrics to a predictable place, it just works. Erika (05:47) That's cool, I'll definitely have to check that out. Bethany (05:50) I don't know if for those who aren't familiar, O-Tel is a game changer. It can be a lot, but O-Tel is basically short for open telemetry, but it allows you to decouple your telemetry, what you're actually using to display your telemetry with how you're representing it in code so that if you end up having to switch, from like, I was talking to a friend recently who was switching from New Relic to Datadog and they were able to use Othel to seamlessly run that migration and stuff. So it's a little extra effort, but if you can do it, it's really nice for just ease of your telemetry stack. Erika (06:32) Yeah, I know we do have some instrumentation already set up for Datadog Application Monitor or APM, which is that tracing that you were mentioning. I'm curious what Jaeger gives you that's different from APM if you've used both now. Brittany Ellich (06:32) That's cool. Bethany (06:50) Yeah, absolutely. So I think first off, it's just nice you can run it locally because you can't run Datadog APM locally as far as I know. Maybe if you did something hacky with like pointing your endpoints somewhere, that would be doable. Second, at least at GitHub, only sample spans at like a one to 3 % rate. So it's actually a real toss up if you get even what you're looking for in your APM. So it's good for general trends and seeing generalized performance, or if there's an outlier that happens to flag catching that. But if you know what you're looking for, it's a little harder to find relevant traces for that. So I was able to replicate what I was looking for locally, so it was so nice to be able to just run. in my code space and then go and see what the trace looked like. Erika (07:42) Okay, well that's, yeah, good to know. Another tool in the tool belt. Bethany (07:46) I feel like I've been a Jaeger apologist this entire week since learning about it. ⁓ Erika (07:50) Yeah, and the one I get why we have to do the 1 % sampling, but it is really limiting. Yeah, I'm always like looking at APM and being like, how is this helpful? Bethany (07:56) Yeah. ⁓ Agreed. Yeah, and I think it just goes to show that there's not necessarily a right tool set for everybody. I think it just depends on what the problem is and what you're looking for. And I think it just depends on the engineer or how you prefer to work and investigate and debug. Which speaking of individual engineers, I'm curious, how do you all start the process of coding? Like what does that look like for you? Is there a general routine you have when you're getting started? Do you do TDD or pseudo code or draw it out on a whiteboard? What's your process there? Brittany Ellich (08:35) I can go. Yeah. So I feel like I always, if it's available, I always try to start from the front end and work my way back for any changes. Because I think that's just how I organize those thoughts in my head. So if there's a front end or even if there's logs or something that I can work from, anything that I can see visually, then I'll try to trace back all the way through the stack to see which changes need to be made. just to make sure I have the mental model of the changes and then yeah, then just try to iteratively make changes one step at a time. I've done TDD in the past as well and it's something that I would like to do more of, but I often forget or feel like TDD works really well if you're like adding something new, but when you're changing something that might not already have tests set up for it, then it's just so much overhead to get started that I often skip it. Erika (09:27) I've been building that muscle too of like, working in more what I've been calling vertical slices of really looking at a feature and looking at how it's used, trying to find logs, trying to find metrics. Yeah, if it's existing code, if it's new, then sometimes TDD and like, you know. Like I might have a slightly different approach, but if I'm like modifying something that's already existing, I've really been trying to force myself to think about like, like I said, like what are the, what are the layers that are a part of this? like, how, how will I show that this is working? And how is it working currently? So like, yeah. And I think that's been helpful. because it's helped me prioritize my thinking about problems more and figuring out, OK, what do I need to fix now versus what can be deferred to a different PR? And then also, yeah, thinking kind of production first. How will I make sure that this is deployed successfully? Because, yeah, often, too often that comes last and then your PR takes double the amount of time because you didn't consider the most important thing of how it's actually going to behave in a production environment. Bethany (10:45) Yeah, bet especially for you, Erica, where the team you work on kind of everything depends on at GitHub. But I feel like your team's fairly stable with your code and stuff, so that's awesome. From the rest of GitHub, thank you. Erika (10:58) I'm going to this. Bethany (11:00) So, one thing that I was always curious, like when I was starting in the industry, and then I kind of just copied what everyone else was doing, but... How do you name your git branches? Do you have like a certain pattern you follow or does your team come up with the pattern? What, how do you do that? Brittany Ellich (11:18) I usually try and follow whatever the existing pattern is. I think right now that's my GitHub handle slash whatever the feature is. And it seems to be what most people do here. So I try to just follow that existing pattern whenever possible. Erika (11:32) Yeah, I always think about doing like the number of the issue that it's tagged to, but I tend to do some kind of short description of the feature that I'm doing and that feels more right to me. Bethany (11:47) Yeah, I agree. I don't believe I ever namespaced prior to coming to GitHub. I think I learned that from here, like adding your handle as the first part and then slash whatever the feature is. But it really makes sense when you think about it. It helps for searching for branches. You're like, I can't really remember what this branch is called, but I know it if I see it. So you just type in your username in the bar and then it just pops up. So I kind of really like that. namespacing trick. I wish I had the discipline to do issue numbers because that would solve all my problems, but I would never know what something would be a part of if I just looked at it. So I'm with y'all with doing the just a short description as much as possible. Brittany Ellich (12:34) I feel like that's a... Okay. Erika (12:34) I think it's also helpful for anyone looking at a production timeline because you don't have to then go track down whatever issue it might be linked to and depending on permission structures, the person looking at it might not have access to the repo where the issue is hosted. So I don't know. I think that could be an argument for human-readable text descriptions. Brittany Ellich (13:00) Yeah, think I've also used past companies. I've used JIRA. And I think when you like use the code there, it like links it automatically to the issue or ticket or whatever, whatever the JIRA terminology is. So I've seen that. I think that might be, you know. something from that. feel like most of the time though, most of my issue numbers are just more difficult to keep track of than like the actual name of the feature. So, so I usually just use the feature name. Bethany (13:28) Definitely agree. Okay, so after being stuck in this problem I was solving, I just was curious, how do you all get unstuck whenever you find yourself in a place where you're drawing blanks or you're just going in circles? What do you do? Is there anything specific? Brittany Ellich (13:48) feel like my, this process is usually always changing depending on what I find most useful. One spot that I always try to search is in Slack. That seems to be, especially if it's an error message or something like that that I'm coming across that I'm like, this might be related to more than just my team. Then I'll look in Slack and see if anybody else has pasted it. And then I always try to like paste my own error messages in Slack too and like what the resolution is so that other folks can find it. Other than that, what I've been using a lot of recently is the GitHub Copilot, specifically the website, unless I can use it, I can also use it within VS Code, but depending on what it is, I might look at the website if it's a general, how do I write this thing in Ruby, where I don't necessarily need all of the context of the existing code that I'm working on and. feel like that moving more towards AI tools for debugging has been really helpful and I feel like I'm getting unstuck a lot faster now with that. Erika (14:41) Yeah, definitely. I mean, we've talked about like co-pilot usage, but it's a very helpful rubber duck. And oftentimes that is all I need is somebody to talk to. And I end up finding like discovering the answer myself by saying what's wrong, how loud. Yeah, I also try to like maybe like think about the problem a different way. Like, I think being truly stuck is very frustrating. And a lot of times it comes from like kind of focusing on the wrong thing or like having that like one piece that you don't know. And so like I think trying to like look at the problem, not in like a super hyper focused way, but as like maybe a part of a larger context and figuring out like, what is it that I don't know that I can. solve for? Like, is it a language thing? Is it an infrastructure thing? Is it a networking thing? Is it like a tooling thing? Like, where is the problem for me? Because yeah, if it's like a specific error message, and it's like super cryptic or something, like you often have to like kind of look at it in the context and then like... put some of the pieces around it together to actually solve the problem that you're seeing. Yeah, it's something that Copilot is not great at. I was sticking it in an error trace the other day and it kept going back and forth and telling me opposite ways of solving the problem because it didn't really understand the other factors that were going on. But that's okay. It's doing its best and yeah, I figured it out eventually. Bethany (16:30) Yeah, I very much resonate with both of those perspectives. I think search is just so valuable, and AI has only made it easier to interact with large volumes of information that you need to of grok and understand. So I agree that Slack is, at least our Slack is very helpful for finding issues, especially if it's something that just cropped up. I also, if it's something new that I'm implementing and I'm kind of like, hmm, I have an idea of where I want to start, but I'm not sure. It's really nice to just search code bases in our organization and see how other people have implemented something in the past. I would love to see Copilot do more of that to be like, hey, I'm looking for this in the Sorg. Is there any examples of this implementation? Because right now it's kind of like just. my mind being like, oh, I think I saw this in some random code base. So definitely agree. And Erica, your process of just kind of focusing on one thing or one part of the problem rather than the entire problem. I feel like lately I've been doing that a lot, just writing down, OK, what do I know? What are the facts here? And then what is actually wrong? there might be like a bunch of things being thrown at you like, this is wrong and this is wrong. And a lot of people will try to be so helpful and say, I think the issue is here. But it's like, well, I need to kind of like, you gave me what the is happening, which is super helpful. And so I can take that and kind of like use my knowledge of the code base to go from there. I think it's helpful to just lay out those facts and go from there. Erika (18:03) Yeah, I know. And people, again, with the best of intentions will sometimes use their prior experience, but that is not always applicable. Yeah, sometimes it sounds like it's related, but it's not. And then you go down these rabbit holes. So yeah, finding out, like, OK, what are the actual behaviors? What's the data? How will I know that this is fixed? Yeah, those are generally. good things to focus on. Brittany Ellich (18:28) One thing I've found too is I don't know if you both have run into this issue before, but speaking of searching, I often end up using the code search on github.com more frequently, at least for very, very large repositories, more than I use like the VS code search, because sometimes I find that it's actually just faster to use the .com code search than the VS code one. I think part of that is the fact that I spent a lot of time working in this like 17 year old Ruby on Rails monolith that is extremely large and sometimes, you know, sometimes the things like some of the built-in stuff doesn't keep up as well. But the code search, every time I use it, I am just amazed at how fast it is and how well it works. Bethany (19:11) I'm so happy you said that because I definitely use code search a lot, that's, I guess I never mentioned it, but I use NeoVim as my regular development tooling or IDE, guess. And it does have great search actually. I've improved it a lot over the years, but still it... The github.com search is always so nice and I've always wondered like, am I missing out on this really good search experience with VS code? So that's good to know that not quite there. I'm not quite missing out yet. That's good to know, but awesome. Another thing that really helps me when I get stuck is just talking with people or like, Brittany Ellich (19:40) You are missing nothing. Bethany (19:49) Erica, think you mentioned this, like rubber ducking in a way, like just talking it out. But that kind of brought me to my next question or groups of questions that I was curious about. does anything about your flow change when you're pair programming? Erika (20:01) I always think of pair programming as a collaborative exercise. think, like, I tend to go into pair programming sessions with more of like an open mind and like looking to like solicit collaboration more than when I like... code by myself. So yeah, I I feel like my guide to pair programming for myself is like constantly be narrating, like constantly be having a dialogue. And like sometimes I have that with myself or with copilot, but yeah, definitely not to the same degree as when I'm pairing. Brittany Ellich (20:42) I really like, since I use VS code, really like using the live share extension because you can, it's super easy. You like click a button and then you automatically have a link you can share with somebody else and they can open the same exact VS code like instance that you were running. So assuming that they are also a VS code user, then I find that really helpful for pairing. One thing that we recently changed on my team, which I think is really cool is I felt like we weren't doing enough pairing. Especially when you're working remotely, it's really easy to just everybody go off and do your own thing. So we recently created a channel that folks can opt into and we pair people up. for pair programming once a week. And so like you just have a meeting for, you know, 30 minutes or an hour once a week to pair on whatever it is either of you are working on. And I found that like just for general knowledge sharing and like sharing tooling and stuff like that, that's super helpful, especially cause I have a pretty large team. Like my team is, you know, really like four different teams that often work together on things. So it's a lot of knowledge sharing to do. Bethany (21:42) That is such a great idea and I might steal that. Just a warning. With credit of course. Wow, that is so smart. Okay, I am very curious though. With Live Share, how does that experience go specifically? Like is one person leading and one person's following or is it kind of both people are working on kind of tangential things or is there a specific flow there? Brittany Ellich (21:46) Do it. I think it just makes it so that I think we usually still like talk about, talk through something the same way. But then instead of somebody being like, there's a typo there, they can just go in and make the change, which is a little bit like less of a frictiony experience. I feel like compared to saying, I always feel really nervous when I'm on zoom or something and be like, no, should I correct their typo? Do they know that it's there? Like, do I, what do I do? Yeah. So yeah, it makes it easier for that case. You can also go and open other files, which is usually nice if you're trying to reference another method or something and you're like, I wanna look this up before I say that we can use this. Then it makes it so that you can more easily go and open other files and stuff, which is kinda nice too. Bethany (22:47) No, that's definitely a really cool process. And it still has the structure of there being somebody leading or showing the code and then somebody following. But it gives a little more flexibility for the folks following. That's awesome. Now, this was a hot topic. maybe a few years ago. I haven't seen it much lately, but I remember there were so many podcast episodes about this, but how do you all feel about mob pairing? Have you ever done it? Has it ever worked? What are the vibes? Erika (23:22) paired, more mob programmed before GitHub. And to be honest, I find it chaotic. And I don't think I've had one experience that has been helpful in the collaborative sense. I have seen some mob pair mob programming sessions where it's like basically watching one person live code and like that's fine. Like if it's like a learning session and like everyone's kind of like you know watching somebody do their thing then that's cool. But yeah any other time it gets to be too many cooks in the kitchen and like everyone's yelling out and suggesting and trying to help but it ends up going nowhere in my experience. Yeah, truly like two people maximum is my preference. Brittany Ellich (24:09) So yeah, I agree that it is often more difficult, but there's actually, this is another thing that my team implemented recently where I think it's every other week now we do what's called a code jam where anybody who wants to join can and anybody can add an issue to the board and it's more of like our like. architecture type decision, like if there's something that we're like, if somebody wants to change something, we bring it there and talk it through as a team while we're implementing it and then. you know, go through and do the, least the initial implementation together. And I've actually found that to be really beneficial. can, cause one, it gives us that dedicated time to talk about those things, which are really easy to put off otherwise. And two, then if you're trying to implement some new practice, like you're implementing it for everybody and everybody is like aware of what that is going to be. So, I think that's the most successful I've seen mob pairing. Erika (25:00) I can see that, the brainstorming and ideation phase and discussions. And yeah, guess if that counts as mom pairing, then I have had experiences where that works. But the pen to paper part where you're actually writing the code. I guess we did have one, I do remember one mob pairing session that you and I did, Brittany, for our accessibility learning group. And it was like you, me, Beth, and Josh, and we got three issues done in 30 minutes. like was a result of us like the other side of it where like we all kind of knew what needed to happen and so it was less of like us figuring it out and more like again like one person typing and the rest of us being like yep go here go here so I guess maybe that's the other side of things it's that like large in between area where you're like actually trying to solve a problem but Yeah, I have had more negative experiences than positive. What about you, Bethany? Bethany (26:00) That's incredible. Yeah, I've had some helpful mob pairing sessions. I do think, I'm agreeing with everything you all are saying that boundaries are so important, especially the more people are involved. You kind of have to have. different jobs for each person. like when I've done like large debugging sessions, it's helpful to be like, all right, you're doing this, you're doing this, you're doing this and kind of coming together, working together on that. it sounds like my pairing and with life boundaries are important. Who would have thought? Erika (26:34) I guess that makes me think like for like incidents, like live incidents, like those are almost mob pairing sessions. yeah, I mean, I have also seen those go poorly or well, depending on the like guidance of, and like, like you said, like boundaries and like roles assigned to each person. Like, Yeah, like there are some incident calls where you're like sitting there and nobody knows what's happening. Nothing's moving forward because nobody's looking into anything. But if you like, everyone has a job and it's really clear like what people are doing, then yeah, those are more successful. So that's kind of a good takeaway from my mind. Thank you for that light bulb moment. Bethany (27:16) no, that's a great tie in. I never would have thought incidents like mob pairing, but it is so true that it is a bunch of people coming together to solve a urgent problem, which is like all the factors that can lead to chaos. But if you have the right structures in place, it can be really beneficial and helpful. So awesome. All right. Any other thoughts that we didn't go over around tooling and your dev flow? Alright, are you ready for a game? Erika (27:42) Yes, so ready. Bethany (27:44) Okay, so you know how everybody loves acronyms, right? You know, every, that's just something everybody loves. They love when you throw out a name and then you're like, wow, I have no clue what this means. And this is great, right? Right? This is a shared experience. Brittany Ellich (27:49) Yeah. Erika (28:01) Absolutely. Say it with confidence. You can't be wrong. Bethany (28:04) Yeah, well I thought we'd do a little quiz on common, well some common, some maybe not as common acronyms. Yay! Erika (28:13) boy. Brittany Ellich (28:14) I'm gonna do terrible. Erika (28:15) self up. Bethany (28:16) Okay, some of them I learned recently, so if it'll make you feel better, I'll flag the ones that I had to Google. And it's been a lot of them, so yes. All right. Erika (28:24) and I will put it out there that I will not lie. Bethany (28:29) yes. No life Googling, but I love guesses at any of them. Like even if they're wrong, I love it. Okay. We'll start off easy. So, okay. First one is HTML. Erika (28:40) hypertext markdown language. Bethany (28:43) Close. Yeah! Woo! Good pair programming there. Okay, good, good. I did not have to Google that one. Okay, rest. Brittany Ellich (28:43) up language. Erika (28:45) Markup. I'm sorry. Brittany Ellich (28:49) Yeah! Nice. Erika (28:56) Presentative. State transfer. Something state transfer. Bethany (29:00) You're so close. You're so close. Brittany Ellich (29:03) I have absolutely no idea. I know what it talks about, but yeah, no. What does it stand for? Bethany (29:09) It's fine, because my spicy opinion is nobody implements rest, at least not the right way. representational state transfer, so, Erica, you were so close. Erika (29:17) ⁓ why does, so it was RE? Bethany (29:19) Yep, it's like combined. Yeah, it's a sneaky one. There's a couple of sneaky guns in here, just a warning. Erika (29:23) Bye. Brittany Ellich (29:25) That's not even a real acronym. Erika (29:27) I was like, external? Like, let's see! Bethany (29:32) It just goes to show, rest was a mistake, so... Can't wait for people to fight me on that one. At me at blue sky and we'll have a conversation. Tell me why I'm wrong. alright, next one is URL. Erika (29:35) Yeah you you Bethany (29:45) I will say, I had to Google this one. Erika (29:47) never thought about this before. I think I always thought of it as like a word in and of itself, like meme, like URL. I didn't realize... What do you think? Bethany (29:56) Yeah. Brittany Ellich (29:56) I bet it's like you. Universal. Bethany (29:59) Actually, no. Brittany Ellich (29:59) Reference link? No, universal reference link is what I'm going with. Final answer. Bethany (30:04) Okay, okay. It's Uniform Resource Locator. Brittany Ellich (30:08) Not even close, okay. Erika (30:09) Now Bethany (30:10) Um, well, this one may be helpful then. URI. Oh. Hang on. Erika (30:16) Uniform resource indicator. Bethany (30:18) Close. Identify. Erika (30:19) Bye. Bethany (30:19) Yeah, fun fact, also Googled this one. I was like, okay, honestly, what is the difference between URL and URI? Because I've heard both of them and I feel like I've Googled it before but never maintained it in my head. And it turns out that all URLs are URIs. yeah, the more you know. Claude roasted me for asking about that. Erika (30:44) Wow. Bethany (30:44) because I asked, I was like, what's the difference between URL and URI? And I was like, you should work with URLs and URIs a lot with your work as a Go developer, because I added that in my profile. So I got roasted for that one, I deserved it, but yeah. All right, all right, this is a fun one. There's two potential, I'll give you a hint, there's two potential answers and I'll take both of them. YAML. Brittany Ellich (30:58) Rude. yet another markup language. Bethany (31:09) That's one of them. Erika (31:10) Mmm. your awesome markup language. Bethany (31:15) I like it, that's what it should be, honestly. So I learned, I also, I knew the yet another markup language, that's what I knew it as, and then I Googled it and learned some lore about this. Now, oh, I'm sorry. Erika (31:15) I'm not gonna be able to... Does it actually have to do with yams? Bethany (31:34) It does not, no yams. No yams were harmed in the making of this acronym, but it's yaml ain't markup language. So basically when yaml started, they were like, yes, we're a markup language. And then they were like, no, we're actually not a markup language. We want to be like this data transfer, like, like layer. And so they were like, they renamed it to yaml ain't markup language. So. Erika (31:58) green branded. Bethany (31:58) more, you know. Yeah, right? I think they should go with yours, Erica. But you're awesome, Markup Language. Brittany Ellich (32:01) very conscious. Erika (32:04) I think they should go with nyamal. Bethany (32:06) Not yet another markup language. I agree. I agree. Erika (32:09) Yeah, that would make it much more clear. Brittany Ellich (32:14) Yeah, those are for two very contradictory meetings, meanings. I feel like that was probably like a fight in a meeting somewhere at some point where they're like, but it's not a markup language. Erika (32:18) Yeah. Yeah. Bethany (32:24) don't want to see the GitHub issue where that debate happened. The email thread. Okay, next one is GRPC. Brittany Ellich (32:27) Absolutely, yeah. Erika (32:33) Glo- Protection. I feel like G is global. Brittany Ellich (32:37) I think the P is gonna be protocol. Erika (32:38) Production... consumer? No. Brittany Ellich (32:40) I bet the G is Google, isn't it? Right by Google? Bethany (32:42) It is made by Google. Brittany Ellich (32:44) Google Resource Protocol. Erika (32:46) Is it proto-calls? Bethany (32:48) heard him call. Brittany Ellich (32:49) Where the C is, Bethany (32:51) Okay, so it's actually funny. A lot of people think the G is Google. It's not though, it's a recursive acronym. So GRPC stands for GRPC Remote Procedure Call. Brittany Ellich (33:02) my gosh, we need to stop letting software engineers be in charge of acronyms because I don't think we understand the rules. Bethany (33:08) It's true, it's true. And we definitely don't have any more of those coming up. We're on the final two, final two. Okay, and these are the longest ones, so this will be fun. Okay, whizzy wig. I can spell that out if you need. Yay! Brittany Ellich (33:14) Okay. What you see is what you get. Erika (33:24) That was fast. Brittany Ellich (33:25) Yeah, I've got that one, clearly. Erika (33:27) I thought that was what they made in the Oompa Loompa factory. Bethany (33:32) What? Is it? Erika (33:33) Fizzy wig? No. That's Harry Potter. What am I thinking of? Bethany (33:37) Maybe. I feel like that was a Harry Potter thing. Erika (33:37) general. Yeah, okay. I'll look that up later. Bethany (33:42) We'll put it in the show notes. Erika (33:44) Yeah, something that's not even relevant. Bethany (33:46) Okay, final one. I'm probably the one that... Okay, I did not know this, so... But I see it nearly constantly, and it's CAPTCHA. Brittany Ellich (33:55) I know that H is for human. Erika (33:56) Ow. ⁓ authentication. Bethany (33:58) It is, yes. Erika (34:00) No. Brittany Ellich (34:01) It's like test for human. Bethany (34:02) Very close. Brittany Ellich (34:03) Yeah. Bethany (34:04) I'll just give it to you because that's closer than I ever would have gotten. I had zero idea it even meant something. Like that wasn't even something that occurred to me. But I laughed when I saw this. It's completely automated public Turing tests to tell computers and humans apart. Erika (34:04) Access. Yeah. ⁓ Brittany Ellich (34:09) Yeah. Erika (34:14) Yeah, we got it. Yeah. Brittany Ellich (34:21) Literally, yeah. Bethany (34:23) And that's why that was the last one, because it was the hardest one. Awesome. Brittany Ellich (34:27) That's good. Yeah, I've seen that. I also heard recently that apparently some folks are making these captures where you're like, identify the busts in these pictures. And they're actually taking that and training AIs on people's responses to help image identification. Fun fact. Yeah. Well, I mean, it's a very cheap way to do it, I guess. yeah. Bethany (34:44) Rude. I hate that. Erika (34:49) Yeah, it's one of those things where I like anytime people talk about autonomous vehicles and I'm like, yeah, but like literally 90 % of the captures I've ever done in my life are like identifying buses. Like how are we trusting driverless cars when we don't trust them to like figure out which squares have a bus in them? Like, something's not adding up here for me. Bethany (34:51) ⁓ One thing I learned, I was mind blown when I learned that those boxes, it's not necessarily the ticking the box that determines whether you're not a robot or not, it's your mouse movement to the box. Yeah, it's so crazy, yeah. Brittany Ellich (35:24) Mm-hmm. I've heard that too. Erika (35:29) Okay, well that makes me feel a little bit better. Bethany (35:32) But maybe a self-driving car still could satisfy that because it would go, woo. Have you seen those stories about people getting stuck in Waymo's? Erika (35:40) Yes. Yeah, terrifying. Brittany Ellich (35:40) I have, yeah. Bethany (35:42) All they would have to do is do that like a bunch of times and then be like, yeah, not a robot. Erika (35:47) Yeah. you Bethany (35:48) Alright, well thank you for playing this game and humoring me. And just for anyone listening, think twice before you put an acronym to something, because even popular ones, we are hard to remember. Alright, so I guess with that, let's sign off. Thank you so much for tuning into Overcommitted. Erika (35:57) you Bethany (36:06) If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky, our social media app of choice, and most of all, share with your friends. Until next week. --- ## Episode 5: Ep. 5 | The ethics of AI for software engineers - URL: https://overcommitted.dev/ep-5-the-ethics-of-ai-for-software-engineers - Published: 2025-04-29 - Topics: AI & Developer Tools, Career Development, Imposter Syndrome & Mental Health - Audio: https://anchor.fm/s/102586d64/podcast/play/101801162/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-3-26%2F399110029-44100-2-a674b693d5adf.mp3 ### Show notes The crew gets philosophical about the ethics of building Artificial Intelligence systems. Are software engineers going to be replaced? Is it ethical to build AI systems? Links * ⁠Superintelligence [http://elenacross7.medium.com/%EF%B8%8F-the-s-in-mcp-stands-for-security-91407b33ed6b] * Blog: Less Wrong [https://www.lesswrong.com/] * Zizian cult [https://en.wikipedia.org/wiki/Zizians] * Thinking in Systems [https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557] * Dwarkesh Patel pod [https://www.dwarkesh.com/] * ChatGPT Medical Diagnosis Study [https://newsroom.uvahealth.com/2024/11/13/does-ai-improve-doctors-diagnoses-study-finds-out/] * MCP Server Claude Desktop Tutorial [https://modelcontextprotocol.io/quickstart/server] * MCP Podcast [https://www.latent.space/p/mcp] * ⁠Overcommitted on Bluesky⁠ [https://bsky.app/profile/overcommitted.dev] Hosts * ⁠Overcommitted.dev⁠ [https://overcommitted.dev/] * Brittany Ellich: ⁠https://brittanyellich.com⁠ [https://brittanyellich.com] * Eggyhead: ⁠https://github.com/eggyhead⁠ [https://github.com/eggyhead] * Jonathan Tamsut: ⁠https://jtamsut.substack.com⁠ [https://jtamsut.substack.com] ### Transcript Jonathan Tamsut (00:00) Welcome to the Overcommitted Podcast, where we talk about our commits, our commitments, and some stuff in between. I'm your host, Jonathan Tamsut joined by my fellow code enthusiasts, Bethany, Erika, and Brittany. We're a crew of software engineers at GitHub. We first connected as an onboarding group on the same team in GitHub Actions and quickly discovered our shared passion for learning and building cool stuff. Even though we're scattered across the country, we still come together regularly to talk about tech, share what we're learning, and just talk about our lives. So whether you're committing code or committing to new challenges, we're glad you're here. Let's dive in to our topic today. AI ethics. So I can tee this up for us. So yeah, so you know, This is kind of a hot topic today. think there's a lot of voices in this space, a lot of people talking about sort of the existential risks. think one thing that probably doesn't get talked about enough is the impacts of our technology. I think we're all sort of techno solution oriented. I think one thing that I want to think more about is, you know, How are these technologies being used by people? What are their impacts? And I think that's something as a society, I hope there's more sort of conversation and thought. So to kind of focus the conversation today, we're going to kind of get a little existential, get a little abstract and philosophical. Hopefully we don't lose you listener. But we're going to focus on kind of three questions and kind of see where they take us. one of the questions that a lot of people have is, do humans do when we're replaced by AI? So the other day I took a Waymo, which is a self-driving car in lieu of taking an Uber. So yeah, are the implications there? Another huge question that people talk about is, is the development of or the pursuit of AGI an existential risk to the human species? We'll talk about that. And then lastly, for the software engineers listening or just the technology builders, what responsibilities do we have as the builders of this technology? Okay, so I guess we can dive into our first question. Does that sound good to you all? Okay, so yeah, so you know, it's funny people, you know, my mom was telling me not too long ago that, you know, she's worried that AI is going to replace all of our jobs. And I think, right, as like people in the field, we know that sort of Not entirely true. Humans are still sort of required in a lot of roles. But it is interesting to think, you know, there certainly is job displacement. I think we see it with Waymo. So like, what do humans do? How is our society shaped as AI plays an increasingly greater role in our economy? Do you guys have any thoughts there? Erika (02:40) Yeah, so I have a couple of thoughts. One is that like, this is not a new problem, right? like, AI is the new wave of technology, but like, massive shifts in technology happen, you know, cyclically. like, the last probably major one was like the internet. And then before that, like the invention of the personal computer. So like there come these like major technological improvements and waves and like that fundamentally changes the way that we work. I'm still not entirely convinced that like AI is that level of shift, but you know, if we're assuming that it is having that power and that effect, like I think the biggest thing is that people need to adapt and train and like learn how to use this technology. Whenever you talk about education and training, there's always the question of access. So some people do have access to this and some people don't. A lot of the training or the prompting is in a certain language. So that affects who can and cannot. Like use this effectively, but again, that's not necessarily a new problem like You know computers cost money the internet's not available everywhere. So Yeah, I mean the the biggest problem in my mind is not necessarily like can we adapt but like who will be able to adapt through like training and education and unfortunately like Yeah, it's probably Also not a new answer to that question. Jonathan Tamsut (04:18) Yeah, know, was, you know, it's interesting. Like I was talking to a family friend, he's a lawyer and he was saying he doesn't use AI at all. And I was thinking like, yeah, you know, he probably doesn't need to until like, you know, it's possible that some law firm, some competitor to him will use AI and they'll start winning cases. Maybe they'll get rid of a few lawyers and cut costs and start charging less. that's sort of a competitive advantage. And so it's like, you know, I think these tools are powerful and people using them will have a competitive advantage. But yeah, I agree with you that in the short term, I don't see, you know, human labor becoming completely obsolete, right? Brittany Ellich (04:55) have some thoughts here as well. I agree that I don't think that human labor is likely to become obsolete. I think that this period of time might potentially be considered like an industrial revolution type event, assuming AI actually, like an AI revolution, assuming AI does all the things that it is currently hyped up to do. There is, I am not a psychologist, but there is a... psychological theory called the end of history illusion, where there's this bias that people think that they've experienced this like significant growth within their lifetime, but underestimate the amount of future change that they are likely to experience. And I feel like that's probably part of what's going on here is like, there's a lot of folks that look at AI and they're like, this is it, this is the end, you know? And that's just, that's not likely to be the case. I think that Like the industrial revolution where we went from lot of folks, you know, like twisting, twisting screws and stuff on an assembly line, we might be able to create some sort of manufacturing that. dramatically increases the speed at which people can work, but it's not like people stopped working after that. It just like adjusted to other things. So I think it's pretty likely I can already tell within my own day-to-day job that, you know, AI makes a lot of things go faster. And that... doesn't necessarily mean that we're not gonna have software engineers in the future. We're just gonna be solving different levels of problems and different types of problems and able to get work done at a higher rate. And anybody who has ever been on a team that has any backlog, I feel like, knows that there's no endless, there's an endless amount of work that can and will be done. So I think we're likely going to see like... fewer items going to the backlog to die forever and being able to like accomplish things much faster, but not necessarily like we're not going to stop doing them necessarily. Erika (06:42) Yeah, I think there's also the potential for quality of life improvements. I heard about this study about doctors using generative AI to help solve or help diagnose patients. And granted, this was a med school case study. So like, the comparison was between doctors, you know, any number of years out of med school, diagnosing symptoms versus like AI. think, I don't know, I don't remember which model they used, but it might've been like chat GPT, like diagnosing the same description of symptoms. And like the LLM did better. It was like, you know, accurate and like, I know, was something crazy, like 80 to 90 % of the diagnoses. And like compared to the doctors also did better, even though the doctors were allowed to use AI, like the same tooling, and they would get the response, you know, with the correct diagnosis, and then they would... say, no, that's not true, like I know better, and like discount whatever the model gave them, which is fair. Like I think it's totally valid to be skeptical of these technologies before they're like fully vetted. But, you know, I think that in my mind, that's an example of like, hey, like, you know, are doctors going away? No, but. Could we enable our doctors to be more effective in their diagnoses by, again, including this as a part of the training or use AI-assisted surgery to make it more accurate? I see potentially lifesaving use cases there. Yeah, so even outside of software, I can see improvements. but not necessarily a replacement in all cases. Yeah, I think you're right. In my mind, it's probably more the mechanical things that we can automate. yeah, I mean, think also, I'm sure there are doctors out there who like those tough cases, but I don't think anybody likes being wrong. Like backlog cleanup, like, you know, these tough diagnoses. Like, I think if we see it as a way to like enable us to do better, yeah, it makes your job that much better. Brittany Ellich (09:19) Yeah, my favorite way to look at AI is really as a quality of life improvement, like you said, Erika, because what you can do is use it to do all of the things that you don't necessarily want to do or don't love doing. Like, for example, I love writing. I hate editing. So I have AI do a lot of my editing for me, which is awesome. I like writing code. I hate writing tests. And so now I use AI to write all those tests. And it's amazing how much faster I can move to get things done and not get in by those things that I don't love doing as much that I can offload to AI, which is cool. Jonathan Tamsut (09:51) Yeah, and I think there's like so much here because, you I think we're inherently threatened by this thing that can come in and replace us, right? And I think when people have resistance to AI, I suspect that's part of the reason. The other thing is, right, you know, obviously, like, you know, I have like a materialist view of the brain. I think that eventually we will have an AI that is just capable of everything we're capable of. And in that regime, it's like, what even is work? Because then human labor is obsolete. So then what do we do with our time? And I think, who knows how close that is? It definitely doesn't feel close. The other day I asked how many Rs are in the word strawberry to chat GPT and I got it wrong. So yeah, there seems to be... limitations, but these models do... I mean, the pace at which these models have beat benchmarks is crazy. yeah, do wonder how much job displacement there'll be in the short term. It might just be totally overblown, people talking about it. It's be sort of a catastrophic class realignment, I don't know. Erika (10:55) Yeah, I also think that it's a bit of a language, like vocabulary difference between maybe how we as technologists understand it and how like non technologists understand like AI artificial intelligence, because I think as technologists, we understand that there is a limitation. And like, Because we've peeled back, we look behind the curtain, right? Like, you know, once you look at a model, once you kind of look at like what training data looks like, like how to improve on these things, you know, not to say that I like fully understand how these things work, but like, I at least know that it's not magic. But like, I think the use of the word, like artificial intelligence implies that it's like boundless. And like, Like you said, like it still makes a lot of mistakes. And yeah, I actually really dislike that term and kind of try to not use it as much as I can. like, instead try to use things like, you know, generative, generative models, like LLMs, that kind of stuff that's a little more specific and accurate, do I think what it's actually doing. Brittany Ellich (12:03) You learn it's all just math. It's just math all the way down. Erika (12:06) Yeah. Jonathan Tamsut (12:07) Yeah, a couple years, like maybe this was last year, I was listening to like Francois Chalet, who's this like, I think he was involved in the creation of TensorFlow, I think. He's an AI researcher and he was talking about the Arc AGI Prize, which is this like benchmark prize that has been created to try to really push, test the bounds of our current models. And, you know, He was talking about, so there's been different versions of the Arc AGI prize. I think the most, one of the versions has been sort of beaten by an AI model. Maybe like 03 beat it. It was able to basically score better than any human. And it's sort of like, if you look at the challenges that they're posting online, they're just like moving blocks around and noticing patterns. And you know, It's like, it is weird because, you know, yeah, these LLMs, like they're doing matrix multiplication and they're kind of complex, you know, they're finding complex associations, but it's like, really begs the question, like, what is intelligence then? Because there are times when you use these models and you're like, wow, like this is, that was really smart. I'm like really surprised. And then there's times where, you the opposite is true. And, I think that's a really interesting question and one that I want to explore more. I don't think anyone really knows the answer. Are these models just compressing large amounts of information? What is true understanding? I think the most recent version of Arc AGI is not. I think frontier models are getting low single digits in it, so it'll be interesting to see if that's beaten. this year or next. But yeah, maybe we just need UBI, which stands for universal basic income. Brittany Ellich (13:43) You'd be okay with that. What would you be doing if you were not a software engineer? That's your dream job. Jonathan Tamsut (13:47) Yeah. Dream job? Probably just a life of leisure, a man of leisure. I would be, you know, pursuing hobbies and then getting bored of them after three months and traveling the world. That's probably what I'd be doing. Brittany Ellich (14:01) sounds incredible. I think I would open a plant store. I want to learn about plants. ⁓ And I just never have the time because there's a million other things that you can learn when you can learn things that actually like make you money. So what about you Erika? Jonathan Tamsut (14:06) cool. Erika (14:16) I have so many answers to this question. There's so many things that I'd want to do. I feel like I still code though. Like I feel like I might still write like open source software. Like even if I don't get paid for it. Now. Brittany Ellich (14:31) Makes sense. This is why we're overcommitted. It's because we're just... Erika (14:33) Yeah. Jonathan Tamsut (14:34) Mm-hmm. Erika (14:36) Hmm? Jonathan Tamsut (14:37) Kind of, yeah, this is, I actually have recently wanted to get into sewing and like garment making. And like, I wanna like hem my own pants and make my own clothes. That's something that I... I would definitely learn that if I had unlimited free time. Erika (14:50) This is kind of funny because it's making me think of like the, you've seen like the, the, like the tropes of like, you know, software engineers wanting to like become farmers. It's like, like tend towards like, like, if I'm not like writing code, like I'm going to do something very manual, like sewing, gardening, like, but not things that could be done by AI. so there you go. Jonathan Tamsut (14:59) Mm-hmm. Erika (15:14) return to the earth. Well, that sounds morbid. Jonathan Tamsut (15:15) I have returned Erika (15:18) Not in that way. Salt of the earth. That's probably more what I meant. Brittany Ellich (15:20) you Makes sense. Jonathan Tamsut (15:24) I mean, it's like this paradox, right? Where you have these models that can do like PhD level mathematics, but like couldn't bake a cake or, Yeah, so it's, it isn't, it is interesting. Brittany Ellich (15:34) Yeah. Makes me think of Interstellar, where they got to that point where they're like, we don't need any more engineers, we need more farmers. And they were like trying to get their kids to go into farming instead of. Erika (15:46) Yeah. You know where like a weird area for me is, like, is this idea of introducing AI in education. And I was telling you guys that I saw like the co-founder of OpenAI. Am I going to get this right? Yeah, the co-founder of OpenAI at a conference a couple of weeks ago, and she was in conversation. part of the conversation was about using Claude as a teacher. Oh, the idea was actually AI will help. with access to education because anybody can get on a computer and like use like Claude as a teacher, as a tutor, and it'll like tailor make the tutoring to you. Which, you know, I do use assisted LLM technology to learn things and I find it very valuable. But I don't think that teaching is necessarily a science that can be quantified or like. you know, directed in that way. And I also think that like part of teaching is like teaching you how to be a good human. And like, I don't think that AI can do that. Like, I'm not going to like put a robot in a classroom and be like, okay, cool. Now like all the kids are gonna learn their ABCs and like. We're good, stepping away now. Like, no, part of that is like, you also have to learn social skills and how to interact with people. And like, I really don't think that that's a place that like AI technology can replace. Jonathan Tamsut (17:35) It's absolutely destroyed computer science assessment because I I think about all my assignments in undergrad, all my CS assignments. AI could do them perfectly. But I also wonder, as people who are parenting small children, are you at all worried about the careers of your, the future careers of your children or how, you know? or even how education is going to sort Maybe this is just like a perennial concern and none of us know what the future holds, so. Brittany Ellich (18:07) I feel like that's thing, yeah, that most parents at some point worry about for their kids, regardless of what period of time you're in. I do, I am a little worried because I think that I'm likely to push my kids towards, know, my kids towards like software engineering or something like that. And I don't know what that's going to look like by then, but, and yeah, the concern about like how much education is going to change. You know, I think there's a lot of stuff that has to be reinvented now. Like you said, like assessments in general don't really make as much sense anymore. Writing essays is a very different thing than it was when I was a kid. yeah, worried, but I mean, there's a million other things to worry about too. So, there's other things that are higher on my list right now, I think. Yeah, yeah. Jonathan Tamsut (18:44) Hmm. Yeah, you gotta pick your battles, yeah. Erika (18:51) Yeah, I don't think I'm worried about like there being jobs available for my daughter when she grows up. I think it's more this idea that like, like I'm gonna, again, like I'm gonna give all the kids an iPad and they're gonna like learn from AI instead of like having an actual teacher. Like that worries me. And yeah, I mean, I think partially for the social skills side of it, and then also because I don't think that AI is accurate enough to like teach our children. So yeah, I think that that part of the education system, I mean, I have no idea, like I'm removed enough from the school system now to like not know. if AI is being used in classrooms and how much and how currently. But I think also my philosophy as a parent is like, school is only part of what you learn and like a lot of what you have to do is teach your kids at home. So. Brittany Ellich (19:49) think there's a lot of excitement too around the ability, the capabilities of like introducing AI in the classroom too. Cause our current, or at least when I was growing up, the methodology was very much a one size fits all approach. You've got 30 kids in a class and this is how we're going to teach this curriculum. Whereas I think that, you know, if you have AI guiding things, maybe there's ability to customize things a little bit more than a teacher would be able to do. You don't have a teacher lead. this overall curriculum, then customize the content for a way that the kids understand things, which I think would be, I think that's kind of exciting and maybe, you know, depends on the direction that things go. This could either be really terrible or not. And it's probably gonna be somewhere in the middle. Erika (20:30) Yeah, I guess I also worry a little bit about the loss of critical thinking where like, I think we talked about this last week with like part of this, part of being a responsible user of AI is recognizing that like you have an agent role as like still doing the thinking. But like that comes from years of like not having AI. So, like, we've always had to do the thinking. But I think, like, there's a risk there where, like, if things become too easy and, you're always given the answer, like, you don't have that muscle to be like, but is this answer right? So, yeah, that also does worry me a little bit. But I think my... My personal offset is like probably teaching her about some of these limits. And like, you know, as long as she'll listen to me being like, you know, don't trust it, question everything, be critical. Brittany Ellich (21:26) models too we can apply to this that for existing things too where technology has improved dramatically in one spot and you you still have to understand like the underlying building blocks. The example I always come back to right now when looking at AI is graphing calculators like if you just hand somebody a graphing calculator and you're like here do some calculus that's not I mean they could do it but they probably can't explain it don't know how to like apply it to things or it's the same thing with like programming and AI. You know, you can hand somebody, co-pile it and say, here, go do this. And yeah, they could build it, but like, could they, you know, infer differences about it? Like if they don't understand like the underlying building blocks of it, could they change it? Could they fix bugs? I don't, probably not as well as somebody who does have those building blocks that they've built up of understanding programming. Jonathan Tamsut (22:12) Yeah, is. mean, know, vibe coding is just so seductive sometimes. You just don't want to think. You just want to like throw things at an LLM, run it, see if it works and just kind of iterate on that until all the tests go green. You know, it is interesting, you know, to see how that changes. mean, and you know, I think, right, you know, it's, I think there was a psychological thing where like you're like, relying on this tool now and you're pushing more and more thought into this tool and I think naturally the more answers it gives you that are correct the more you trust it. And so yeah what are what are what are sort of the drawbacks there? I mean like sometimes it's good to go the hard way and like figure things out but yeah. Brittany Ellich (22:49) I have a prediction there. I think that there's like two types of software engineers. There's the people that are vibe coding and just like hitting the tab key and just getting through stuff. And then there are people that are using it and like making themselves more productive and like implementing it in their workflows and still like thinking critically about the changes that they're solving. And like my prediction is that one of those sets is going to continue to be a software engineer. Jonathan Tamsut (22:54) Mm-hmm. Mm-hmm. Brittany Ellich (23:13) in the future, whereas the others might not be. They might be doing something else. Maybe they will be, but maybe that's a spicy opinion. Erika (23:17) Yeah. No, Jonathan Tamsut (23:20) Hmm Erika (23:20) I think you're spot on. And I think this is true even without AI. Like so many of the answers to like, how do I fill in the blank for any like software engineering question have been readily available like through Google for so long. But like I have seen, like you said, two different types of people who will accept the answer without trying to understand it. or the other side, really dig deep, like understand the tooling, look up the rough, look up the code, like understand how things are working. And yeah, I think you're totally right. think, you know, I think there will probably always be like a place for the people who kind of want to vibe it out and like do the least amount of required work. But yeah, I think that the people who will continue pushing technology forward in a meaningful and probably professional way are the second type who still are the drivers who really understand how to get the most out of this. Jonathan Tamsut (24:22) Yeah, it is kind of depressing in a dystopian way to just think of people who are just hitting tab. wow, that, And yeah, think, right, mean, I think, right, a lot of what we do is frankly not, is kind of uninteresting, right? Doing glue code or just boilerplate. There's not, sometimes there's just not a ton that's interesting to understand, but like. There's maybe a kernel of like interesting business logic or optimization that you can focus on that AI maybe couldn't do or maybe it can do, but you just want to do it yourself. one question people ask is, does AI pose? existential risk to the human species. And I think, you know, there's guys like Eliezer, Yudekowski, there's a lot of people talk about like alignment. And I think that the existential part is interesting and honestly like maybe we should be thinking about it because like, I guess if there's like a 1 % chance that AI, you know, creates some sort of mass genocide, we should definitely try to... to not let that happen. I do think, right, like, you know, if we remove the word existential, like what type of risks does AI have? We all know AI systems, you know, are difficult to explain. There's bias in them. There's now an ability to create realistic looking content, both text, video and image that can be used to polarize. an electorate in our population, there's an environmental cost to training these models. I guess, yeah, you know, we so rarely talk about, you know, how we can mitigate these negative consequences. So I figured this would be a good time to talk about that. So is there any question in particular? I think the alignment question to me is interesting, but was there any question in particular that sort of stood out to you all. Erika (26:12) Could you give a brief description of what alignment is? Jonathan Tamsut (26:15) Totally. So, um... Yeah, basically, how do you train these models to be aligned with human values? And one kind of anecdote that you'll hear a lot of people talk about, like Nick Bostrom wrote this book called Superintelligence, and in it he talked about this theoretical example where you tell an AI to build as many paper clips. as it can, that's a relatively innocuous ask. But eventually the AI realizes that humans are consuming resources that could otherwise be used to build paper clips, so it exterminates the human homo sapiens. And so I think there's two interesting questions there. It's like, what are our values? And then how do you actually encode them? And guess maybe the third question is, do you tell? know, test that our values are actually encoded in these AI systems. You know, right now there's, you know, bias in all of these AI systems. I mean, all data sort of, I think inherently has a bias. And so, yeah, like how, yeah, how do we deal with that? don't know if this is an interesting topic to you all. Brittany Ellich (27:25) really solving the world's problems here. Jonathan Tamsut (27:26) Yeah, it's really tough. I think there's a lot of people at Anthropic and all these companies who are researching this. Erika (27:32) So I guess, like, I may be oversimplifying this. But like, I think like in order for AI to pose an existential threat, like it has to be in the place to do that. So like, we have to somehow enable it to take those kinds of actions. Like, to... Yeah, be lethal in some way. like, again, I'm probably oversimplifying this, but I kind of think of it a similar way of like, like, are we weaponizing AI? Like, you know, and if so, then like, we do need to put safeties in place, but like, you're never going to make it entirely safe if you use AI as a weapon, right? Like, it's like, if you're making a gun, You put safeties on the gun, you put the gun in a box. Those are things that you can do to make it more safe, but at the end of the day, it's a weapon. It can kill people. So I think the only way that we can make AI not kill people is to not put it in that place, not give it those abilities. But I feel like I'm probably missing something of like... you know, maybe it already is, and maybe there's like a doorway for it to, like, I guess the edge case is like, I don't know, using, like right now I'm thinking, like all I'm thinking is just like LLMs, words don't necessarily kill people unless it's like, like I, there are like those edge cases, but I think. Jonathan Tamsut (29:00) Mm-hmm Erika (29:06) Yeah, that's maybe a different rabbit hole. Brittany Ellich (29:09) Yeah, this is tough. think, I don't think it would be possible to build any AI model without any bias because humans are inherently biased and it's being trained on human generated text mostly. So I think you have to assume that these are all biased things. And I think, you know, with obvious exceptions of somehow integrating it into a weapon system. There's a lot of ways that it can still have a huge impact on the world. Like if people are like, well, we're going to start use AI as a judge. like, if the judge is already trained on, you know, years and years of human bias, we already know that there's a lot of bias in our judicial system. And that could have a pretty tangible impact on people. And I don't know. I think it's... I think it's easy for software engineers to talk ourselves out of how these things can have real world impacts, because we're just like, I'm just building this API. Look at this API do. And then how people are using it could be very different. I don't know how to fix that. Luckily, I don't do anything like that, I say. But, you know, yeah, that's a hard problem. It's a hard thing to think about how it's being actually applied. Jonathan Tamsut (30:23) Yeah, I mean, this is a difficult concept. And I do just want to point out, I appreciate us just coming here and just trying to grapple with this topic. And I have no idea what I'm talking about. And it's kind fun to be... So one example I hear is like, okay, let's say you program an AI. And so there's this idea of super intelligence. So the idea like, okay, we create an AI that has human level intelligence. In theory, if it's just like code and hardware, and I'm being very hand wavy here, it should be able to just be like infinitely more intelligent. Because I don't know, you sort of like, you you don't have to buy this argument, but like the argument is like, we can just like horizontally scale intelligence. So we'll have a system that's like way smarter than us. Already, LLMs have cognitive capabilities we don't have just by the very nature of like, they can remember all of the internet. You know, we're, you know, quote him. quote unquote, remember. So it's like, okay, so let's say we created an AI that was way smarter than us and could therefore manipulate us in subtle ways that we don't even imagine. Yeah, maybe initially it's just software running on a computer, but it could just lie dormant, subtly manipulate us, get us to give it some physical embodiment, and then game over. So there are interesting... edge cases. I mean, there are people like Eliezer Yudekowski, he writes this blog, Less Wrong, who are really focused on this. There's also like, have you guys heard of the Zizian cult? You guys hear about them in the news? They're like this like tech, San Francisco tech cult. They ended up like murdering a few people. But they, think like one of their central beliefs was that like, AI poses an existential risk to us. Definitely now, that feels far-fetched. It feels like you're basically running a Python program that multiplies matrices together, and then it terminates. But yeah, think the bias question is interesting. I think the surveillance question is also interesting. think these AI tools allow you to surveil your, allow governments to surveil at levels that are just unprecedented. So yeah, that's it. Erika (32:29) Yeah, I honestly think, yeah, in my mind it comes down to like, I'm less worried about the AI itself and more worried about like the humans in charge of the AI. ⁓ Jonathan Tamsut (32:39) Yeah. Brittany Ellich (32:40) I do feel like there needs to be, at some point in the near future, there needs to be some sort of moral or ethical code for software engineers. I mean, we have the same thing for doctors where they have to follow this oath to say, I will not harm people. And I feel like we might eventually need that for software engineers too, because... Erika (32:48) Mm. Brittany Ellich (32:58) We're doing stuff that has a huge impact on the world. I know that's probably a really unpopular idea for any employer out there and I might never get hired anywhere else ever again after saying that publicly. But I think that, you know, there's a responsibility that we do have to take for the systems that we're building that have a real impact on human lives. Jonathan Tamsut (33:17) Yeah. Erika (33:17) 100 % agree with that. And yeah, I will be the first one to advocate for more tech regulations too, as annoying as it is to build for GDPR. I feel like it's good pain to feel because yeah, it's like, this is important. Data sovereignty is important. And like... Yeah, we need to put protections in place because the technology itself is open, right? Like you can't prevent people from using it in a certain way, but you can regulate how it's built. Yeah, so I think that's a very good point. Jonathan Tamsut (33:54) And I think one thing that I really struggle with is what are my values? I think there are obvious things like I think people deserve a right to privacy. I don't think there should be discriminatory bias. We shouldn't be killing people. But I think there are other more hairy questions. I'm not even sure where I stand. And I think this is a topic that is... I want to spend more time thinking about. it's also, you know, I mean, it's difficult, right, in our sort of capitalist system. You know, there's this idea of moral hazard where corporations don't have to, they don't internalize the negative consequences of their actions and therefore they aren't incentivized to prevent them. At least not directly, maybe years down the road there'll be some congressional hearing where they'll get outed, but I don't even know if they care about that. So yeah, I do think it's good that people are talking about this more. I think it's something that I want to form more of an opinion on. Brittany Ellich (34:53) think we should continue talking about this also in future episodes. I'd love to talk about what a guideline would look like if you were to write one. It's probably different for every single person that writes some sort of oath or something like that. It'd be hard to come to an agreement on one, but. Jonathan Tamsut (34:56) Yeah. Yeah. Erika (35:07) I feel like I need to read more science fiction to get into this mindset that AI is going to take over the world. Brittany Ellich (35:12) Yeah, same. Yeah, it feels very science fiction. And now I really want to go read super intelligence. So. Erika (35:19) iRobot all of the Isaac Asimov back catalog Jonathan Tamsut (35:23) Yeah. Okay. ⁓ Now for the sort of canned segment part of the podcast. We're gonna go around and talk about a learning resource, book, article, course, et cetera, that we have consumed or interact. with recently that we really liked. So, Brittany, do you wanna start us off? Popcorn Brittany. Brittany Ellich (35:45) Yes, I'm glad that I get to go first because I was wondering if Erika's was going to be the same one since we're both in the same book club. But my recommendation right now is the Thinking in Systems book, which I just recently finished and is easily one of the top five books I will. continue recommending for everybody that is a software engineer going forward because it's very approachable. You don't even have to be a software engineer. You can really be in any field because it's actually not super technical, which I did not expect going into it. But it's a good way to sort of open your mind up to thinking about, you know, thinking about systems, be they software or otherwise in different ways. And I really enjoyed it and I'm looking forward to, you know, recapping it further on the internet, most likely. Erika, do you want to go next? Erika (36:32) Well, definitely plus one to thinking in systems. I will share another resource that I have found fun recently is last week I was doing some like learning about copilot and how to use it and specifically like how to use an MCP server and So did some kind of like tutorials on like building your own MCP server and I thought those were really fun because I think like at the Yeah, sort of start of last week. I was like, I like heard of this concept and don't really know what's inside of it, yeah, Claude Desktop has a tutorial on building an MCP server. And then I also listen to a podcast, I think it's Latent Space, I don't listen to this podcast regularly, but they had the co-founders of the MCP, I was gonna say MCP protocol, but that's redundant. The co-creators of MCP. on as guests and it was fun hearing their inspiration and how they built it so that's also a rec. Jonathan Tamsut (37:51) Yeah, no, that's what you're saying. Cool, yeah, my recommendation is kind of similar to Erika's. So there's this podcast called, I think it's called the Dworkesh Patel podcast. That might not be the name, but Dworkesh Patel is the host and he wrote a book called, I think it's called like The Scaling Era. And it's kind of just him synthesizing a... things he's talked about on the podcast. I haven't finished the book, but it's good to talk about a lot of stuff we talked about, like what an LLM is, how they're evaluated, different benchmarks, AI safety and alignment. So yeah, it's pretty interesting if you're interested in that topic, I recommend. Okay, so thank you all for tuning in to Overcommitted. If you like what you hear, please do follow us, subscribe, or do whatever you like to do on the podcast app of your choice. Check us out on Blue Sky, our social media app of choice. Most of all, share with your friends. Until next week. --- ## Episode 4: Ep. 4 | How we use AI as software engineers - URL: https://overcommitted.dev/ep-4-how-we-use-ai-as-software-engineers - Published: 2025-04-22 - Topics: AI & Developer Tools, Productivity & Learning, Technical Deep Dives - Audio: https://anchor.fm/s/102586d64/podcast/play/101401293/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-3-17%2F398539837-44100-2-c2cf5a378e45c.mp3 ### Show notes The crew chat about our experience using AI right now as software engineers (which is subject to change even by the time this episode airs). Including an overview of our current thoughts on the AI landscape, what tools we use for which tasks, and our thoughts on what we are excited about for the future! Links * The S in MCP Stands for Security [http://elenacross7.medium.com/%EF%B8%8F-the-s-in-mcp-stands-for-security-91407b33ed6b] * Book: The Scaling Era [https://press.stripe.com/scaling] * Overcommitted on Bluesky [https://bsky.app/profile/overcommitted.dev] Hosts * Overcommitted.dev [https://overcommitted.dev/] * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] * Jonathan Tamsut: https://jtamsut.substack.com [https://jtamsut.substack.com] ### Transcript Brittany Ellich (00:00) Welcome to the Overcommitted Podcast where we talk about our commits, our commitments, and some stuff in between. I'm your host today, Brittany Ellick, joined by my fellow code enthusiasts, Bethany, Erica, and John. We're a crew of software engineers at GitHub. We first connected as an onboarding group on the same team in GitHub Actions and quickly discovered our shared passion for learning and building cool stuff. Even though we're scattered across different teams now, we still come together regularly to geek out about technology, share what we're learning, and explore our life as developers. So whether you're committing code or committing to new challenges, we're glad you're here. Let's dive in. Today's episode is about how AI has transformed your work as a software engineer. Obviously, this is an evolving thing and subject to change even by next week. when this actually airs. But I thought it would be a good opportunity to talk about what we're doing now with AI and what our thoughts are for the future of it. So to open up the conversation, I thought we could talk about what your current thoughts are about the AI landscape, just generally. John, do want to go first? Jonathan Tamsut (01:10) Yes, I can go. Wow, what a great question. What an interesting time to be alive. Today my mom was telling me how she used AI to solve a plumbing issue. But yeah, mean, you know, it's interesting. I think right like, I think when, you know, my first use of chat GPT, and I think maybe a lot of people felt this way, was like, initially it was sort of just like a better interface for information retrieval, sort of like a better Google, like instead of returning, you know, 15, 12 blue links that you had to go click through, it kind of synthesized information and gave you more specific answers to the questions you had. I think now, right, You know, now there's tools like GitHub Copilot that, you know, can, you know, I can write tests for you. I think, yeah, I mean, there's so much to say here. I mean, I use it every day. I'm sort of an AI maximalist. I'm like just constantly trying to see how much can I use AI to sort of automate my job and improve. my efficiency, there's certainly limitations to this model as I'm sure we'll get to. I think one thing that I'm curious to hear what you guys have to say is there's also this idea of where do humans really fit within AI tooling? when you generate code with AI, the human still has to read it and validate it. these things to hallucinate, they get things wrong. And it's interesting because it's like in 10 years, you if you think, if you sort of like think out 10 years ahead, it's like, and you know, if you're using these AI tools every day, what sort of what skills are you losing? What perspectives are you losing? I mean, I think all of us, you know, we're used to coding every day, keeping those tools sharp. So that's kind of just like a specific interesting thing I've been thinking about. are we all just gonna forget how to code? But I think right now I'm definitely an AI maximalist and I'm just really interested in the upper bound of these tools, what they're capable of. Erika (03:06) Yeah, I think I'm in like a transition phase in my usage of AI where like, I think I was, so yeah, our organization is actually like providing us a dedicated week to like try out a bunch of things with AI, specifically co-pilot and really like upscale, which is. important because like any tool you have to learn how to use it in order to get really any value from it. And I think the more that I do use it and the more I learn about it, you know, the more I feel confident in its use cases and applying it applying it correctly. But yeah, I think something overarching that I feel is that the hard part will never go away, which is thinking through the problem. And even though when I'm using AI at its best, I feel like it turbocharges whatever I'm doing, the thinking part will never go away. For me, it's still... my brain doing the hard work and then like telling AI, you know, giving a direction like, yeah, like I definitely don't see a world in which I'm going to offload that part. But it can be sort of like a second brain. Yeah. And like I said, kind of sometimes it feels like it's really. Yeah, making my life a whole lot easier, making the things that I do a whole lot more efficient when I'm using it well. Bethany (04:30) Yeah, I definitely agree with all those points. I have found it the most useful to almost help with sorting through large volumes of information. So I find it super helpful for search. So anything that I would have gone to Google or Stack Overflow for, oftentimes I'll now go to like Copilot on GitHub.com. and ask it that based on a repo or based on some documentation or a website or whatnot. So it can kind of be a more conversational approach to searching, which I really, really enjoy and feel like I learn things deeper when I can truly understand it. and it meets me at whatever level of understanding I'm at, whether I'm a beginner or more advanced. So I really think that's a huge. pro to AI. I agree that I don't envision it ever fully taking over coding. I mean, after all, at some point an engineer or a person does have to support the code that's being deployed. Coding is only a fraction of the effort. But I do think AI can really help out with a lot of those issues, whether it's like finding where bugs might be or understanding code if you're new to a language or a code base, like we talked about last week. And I think it's super helpful with that. And I think thinking of using AI tooling for coding as like analogous to pair programming is kind of how I go about it because I mean, you don't lose your coding experiences by pair programming with somebody but. You rather, you know what you have in mind and you're mentoring and coaching them to that end product. And so that's kind of how I like to envision any coding sessions with AI going is, okay, I know what I want and I will like try to coach it through that, which I think there is some level of skill and that goes into from my experience before AI. Jonathan Tamsut (06:26) I think what Erica said actually was like super interesting. You're like the hard part is thinking and coming up with a solution. And it's like, you know, right? Like I think like large language models just like technically have a problem with like context and like sort of like thinking sort of like longer term thinking like with longer time horizons where there's like multiple steps. But it is, I am interested in trying to use these tools and bringing in context and trying to get it to come up with end-to-end solutions. mean, just the other day I had it right. I had it refactor some tests and it got it right first time. I was using Claude, Sonnet 3.7. The test passed, I looked at them, they made sense to me. And so like, yeah, it is interesting. Yeah. Like, sort of there's a gradient between like, I'm using, I'm using AI to kind of figure out an API call to I'm pair programming to I'm giving it, I'm telling it to write tests to like some agentic, you know, I think dream where like you're, you give it a JIRA ticket or a copilot, you know, or a GitHub issue or whatever. And it can bring in multiple sources of information, maybe ask clarifying questions and just like implement it end end. Erika (07:45) Yeah, think like the way I think about it too is like I need to have a mental model of whatever I'm doing in order to be effective in that space, which is kind of something we talked about last week too with the... like learning a new repository or a new problem space. And like, you have to be able to like hold that in your mind to know if like any of the output you're getting from the AI is even applicable. Like you said, like the tests made sense and they have to make sense compared to what you're expecting in your mind, right? But yeah, I think like we've probably all had this experience where like, One of the most frustrating things as a software engineer is not when you're in the flow and coding, but when you have that one issue that takes you five hours that could have taken you five minutes. And like, those are the things that I feel like AI is so good for, where it... immediately sees like you have this dumb typo, you have this thing that's not passing in your tests and you're like that was so obvious but like for some reason my you know eyes didn't catch it so yeah those are those are huge productivity wins. Brittany Ellich (08:53) Yeah, for sure. I, I found, think I started out as like, not quite an enthusiast. Like I'm pretty slow on the adoption curve for AI in the last month or two. I've started realizing like, wow, this is going, this is improving a lot faster than technologies normally do. and now trying to really rethink how to add this to my workflow. And I'm thinking about it a lot because your entire workflow really does change. If you're used to going to Stack Overflow for, or Google or something like that, like that. process is different now when writing code so it's a very fun time and also like a slightly uncomfortable time while we're trying to like relearn how to work. Love what you all have said and I feel like we have like a good range from an AI maximalist down to you know I haven't used it ton and I feel like I'm starting to now and it's it's been really interesting. So let's talk about tools that you are using for AI at work and the ones that we can talk about given that we all work at a company that makes AI tools. I think we have to be a little bit general about some stuff, but we can talk about using Copilot and stuff like that. let's start first with documentation and writing. What tools are you using for that specifically? Bethany (10:05) I will a lot of times use Claude for documentation and writing. I recently got a Claude. subscription because I was, as mentioned in a previous episode, I was trying to draft a bunch of proposals for GopherCon and was just looking for help to make sure that I was drafting it in a way that matched what they were expecting based on the resources they provided. And I thought the projects space was really cool to be able to add any documentation or frameworks or whatever you're looking to use as context and be able to chat within those parameters. And I think OpenAI has its own version of that as well. And so I find that really helpful for just kind of brainstorming and getting ideas. For writing documentation in general, I'll usually write a loose rough draft of what I'm looking for if I already know what I want to say. And I often will check it against like cloud or if it's more technical against co-pilot in in github.com to like make sure it makes sense, it flows well. And I'm conveying those my thoughts the way that other people can understand them. And I find it super helpful for just making sure that what I'm saying makes sense because sometimes it's tough if you have a lot of knowledge on something and you're just brain dump. People are like, I don't understand any of this. So I really appreciate that. Erika (11:35) Yesterday, for the first time, I used the, I think it's slash doc command in Copilot Chat, which will generate documentation, code comments for a certain set of methods or the whole, all of the methods in a file. And that... is really nice for anyone who's reading your code or even if you're looking at a method that you wrote and trying to make sure it makes sense, like inputs and outputs. that's, I think that's a nice feature that's built in now. Jonathan Tamsut (12:11) Yeah, that's super cool. I actually haven't used that. So I will check that out. Yeah, I mean, I feel like I use tools. like, you know, I use like, I like a Copilot Pro and Cloud Pro account. And I use them a lot for like editing. I'll paste in something I wrote, like for personal project, like a blog post. I'll paste in a blog post and say, can you edit this for clarity? I've used Notebook LLM, which is Google's open source tool, which I think you get similar functionality using Claude. I'll upload it. I wanted to write a paper, or I wanted to write a blog post on a paper. So I uploaded the paper, and I had Notebook LLM summarize the paper for me. And then I asked it to write me a little blog post, kind of rough draft. Yeah, so I think, you know, I'm actually, I'm not sure if this is released yet, but I mean, the other thing I use a lot, sorry, sorry for making your editing job life harder. But I know like Copilot also generates PR comments, which sometimes when I generate those, that's nice. Or sorry, yeah, like. PR descriptions. And then yeah, yeah. Sorry, I gone. Erika (13:16) Yeah. And merge commit messages. Those are so nice. Jonathan Tamsut (13:21) Yes. Totally. And it's kind of like, I, you know, it's funny, like I write pretty poor merge commit messages. And it is kind of nice like having that automated. Are they always the best? No. Are they a little wordy? But you know, you can also tune that, you know, you could tune that. And then yeah, like Gemini, Gemini is pretty useful and like the G Suite. You know, I'll just reach for that. One thing I've really gotten into is I like generating header images for my Google Docs. So you can generate a picture of databases and then flames, and you can have a fun header image. So yeah. Brittany Ellich (14:02) Is that like a good database paper or a bad database paper if it's on fire? Jonathan Tamsut (14:06) No, no, that's like that's like when I'm when I'm writing like an availability review postmortem. Yeah. Brittany Ellich (14:12) Gotcha. That makes sense. Yeah, I go back and forth between Claude and ChatGPT right now. I heard a really funny joke the other day where folks were talking about how they're spending more right now on their AI subscriptions for different things than they are on their streaming service subscriptions, which might just be the state of where we're at. I haven't committed to one just yet to subscribe to, but I'm getting there. I really want the project's functionality, which I think I have to subscribe to Claude or to open it, or to ChatGPT to be able to get, so. Still waiting to see which one wins between those two. I've also been like a googling what's on our public docs while we're talking about this to see like what has been released because we do get to you know do a lot of dog fooding and try stuff out before it gets its public so I think we're good on PR descriptions. My brother just mentioned it the other day so I think we're safe there. Nice. What about for code? Obviously, you know, is there a different workflow for code? We're all obviously using a lot of copilot. But is there anything that you want to talk about there in terms of, you know, different things that you're using? Jonathan Tamsut (15:12) Well, so I listened to this podcaster, Lex Friedman, shout out Lex Friedman. He interviews people and he had the cursor team on. And you know, it's these four like MIT graduates and they spent a lot of time talking about sort of like the UX of these coding tools, these AI coding tools. And you know, it's like, I think, I don't think the user experience is exactly like, I don't think it's where I would want it to be. And I think one thing that I think about a lot is, I used to use NeoVim and Vim, and now I have Vim bindings. And one of the nice things about that is if you use it a lot, you eventually get to a point where editing a document, you're not using brain cycles for that. instead you can think about the code you're trying to write. And I think like, you know, some type of seamless integration with my text editor would be nice. I think like sometimes, you know, auto completions can feel a little aggressive, you know. So I think something that would like really almost like, almost like predict what I wanna do and really just allow me to like, you know, seamlessly edit things very quickly and kind of. Yeah, almost like predict where I'm gonna miss something would be nice. And yeah, you don't want auto completes that are aggressive or incorrect, sometimes I accidentally hit tab and then I have to go and delete four lines of code, which is kind of frustrating. So I think there's, I mean, obviously we're early days with these tools and I think that eventually there'll be better UX. really kind of augments human behavior in a more seamless way. Erika (16:45) Yeah, I mean, I'm excited because I think working on the GitHub monolith is a lot of discovery, discovery of style, best practices, discovery of tooling. there's a lot to grok before you get to a point where you're writing one line of code. And again, that to me has always been the harder part. And like we said, that's something that I think that AI is really good at is crunching large amounts of information. I haven't gotten to the point where I've set up enough customization and context to really get a ton out of it, so I'm still in the kind of like playing and experimenting phase with like different prompts and all that, but I think there's a ton of potential there. And then I've also seen some really cool experiments this week around using MCP servers to pull like Sentry and Splunk and Datadog. metrics and help troubleshoot different problem areas in the code, which is super cool and something that also takes a lot of time. It's like digging through all of those errors to try to find the problem area. So again, I have not tested out a ton of that myself, but those are kind of the things that I'm excited about potentially incorporating into my workflow. I'll keep you posted on. How it Bethany (18:20) I personally use Vim, like new Vim, a lot. So I do rely on completions a ton for helping out there. And if I need to ask a question or about code, then I'll go to github.com. I do use VS Code a lot though to triage Copilot API, which I work on. So... I am really excited to actually learn more about the agent mode and how to actually prompt it in a useful way to get to get a good outcome. But I've heard a lot of really good stories about that. So very excited about that. And also definitely want to echo Erica that MCP, it's still early days, but lots of exciting things coming from that. And a lot of really interesting. use cases for it to really make a cool AI experience that can leverage your tools and almost like read your mind and be like, okay, these are the tools I would use go, go do what I would typically do, but in less time. very excited for that. Jonathan Tamsut (19:19) Yeah, and to your point, Erica, I think kind of the next level is having an AI have context across a variety of information silos. So not just your code, but your code running in production, the different telemetry. I think that'll help with triaging, that'll help sort of connecting what you're seeing. Was your code running under load in production to the code you're writing now that'll help discover bugs? I think that's something that definitely seems like an area of growth and pretty exciting. If you could ask, hey, I have this query and the AI knows about your database, the load it's under, different metrics about your database, knows telemetry. You could say, is this query going to perform well under load? And it can answer questions like that. That'd be pretty neat. Erika (20:10) Yeah, and it's something that I feel like that specifically we reach a lot for linters, which are a very imperfect tool because linters are basically like pattern string matching. But like if we can turbocharge that and say like, hey, these are like certain code patterns that we've noticed have caused like availability incidents in the past, like, you know, like that's so much more powerful than saying like, your code matching this one specific thing that we have now thought of, any sort of predictive error analysis, not necessarily to prevent it, but to flag it and say, hey, have you thought about this? Batching might be a good idea here. Something like that. So yeah, I think that be really cool. Jonathan Tamsut (20:55) There has to be startups doing this, but some agent that's listening to your telemetry, ingesting it, knows is aware of your code base, is aware of the infrastructure your code runs on, and then can propose solutions like, you've had this exception happen 3,000 times in the last month, here's how to fix it. mean, that would be incredibly useful. Erika (21:14) Yeah, I almost wonder about what the output there would be. Would that be code, or would it be a rule set? And how you would apply that. So I'm not sure. Something interesting to think about. Brittany Ellich (21:27) I feel like this is a topic we're going to have to continuously revisit as things change because it is changing so fast and it's fun to kind of hear some of these ideas and predictions about the future. Is there anything like what is the thing right now that you're most excited about seeing develop further? Erika (21:44) Well, I think the flip side of my excitement about MCP is a lot of the security vulnerabilities that have been brought up. So I guess this is an excitement of the potential of those getting fixed, but also a fair warning that. I read something this morning that over 43 % of MCP server implementations have unsafe shell calls. Yeah, and they're like a major potential vector for supply chain attacks. you know, it's like, beware, be cautious of these things. But I think like, you know, it's not impossible to harden them and make them. better. So like, I'm excited to see that and I'm, yeah, like I'm sure it'll, it'll, it'll get better. Jonathan Tamsut (22:31) And for me, I'm excited about, you know, sort of agents, I mean, that's kind of where everything is going right now. you know, what level of human involvement will be required? There's a lot of tasks that are trivial, that take time, that take brain space. It would be nice to just tell, you know, go change this config here. It would be nice, you know, I think like one thing that I've been wanting to try is like, automate testing, right? I mean, I think like, I think AI could do a good job testing, you know, if you tell framework, you can say, you know, as I'm typing, generate tests, run the tests, even if you could automate testing, like, sort of like in a more sort of procedural way, like SSH into this, into this box, run this command, and tell me what the output is. These are all kind of just like, boring tasks that I would love to have an AI do for me. Brittany Ellich (23:18) I see this. is the new A.I. TDD from Jonathan Tamsut A new paradigm around writing tests. Jonathan Tamsut (23:25) Yeah, for sure. I've seen them. I have a bunch of blog posts bookmarked where people are integrating open APIs into their testing. So I think a nice framework around that would be nice. Bethany (23:38) I think for me, I am really excited that a lot of new models that we're seeing are getting more and more efficient, which will just make things one, more friendly for the environment and two, more sustainable because when LLMs first came out, they definitely were not sustainable and capacity was very difficult to get and costly. So I'm super excited about that. we're going in the direction where they've become so much more efficient and energy friendly. Additionally, I'm super excited that reasoning models seem to be the new norm now. So previously there would be models that, like a lightweight model such as like 3.5 turbo or 4.0 mini and then like a heavier model like GPT-4, GPT-4.0. But a lot of times, now they're pushing reasoning models where you could optionally provide reasoning parameters. So you can really use the same model, but tell it how hard to think on a problem, which I think is a really interesting way to think through leveraging these models and LLMs. That's really interesting. Jonathan Tamsut (24:43) Yeah, like the think deeply. It's like, yeah, it's like how much do I sort of care about a problem is how much I'll ask the AI to think about it. Yeah, that's cool angle. Bethany (24:54) Real quickly, I wonder if it would be beneficial to define MCP and give a quick overview for any, listening, that might not have a good understanding of Brittany Ellich (25:02) Gosh, yes please. Please, please do. Cause I still, I've tried to like address this so many times, like, okay, I kind of get it, but please from the expert, tell me what is MCP. Bethany (25:12) Am I the expert here? Brittany Ellich (25:13) You're like the closest to AI, I feel like. Jonathan Tamsut (25:15) Yeah, you work on copilot. You're the expert. Yeah. Brittany Ellich (25:19) Yeah. Bethany (25:21) Well, my understanding of MCP, MCP means Model Context Protocol, and it is basically an API to provide a LLM so that it knows what tools it can use for its processing. if it comes to a answer or a question that it's not sure about, it can see what's in its toolset, which MCP describes, and it can go out and then fetch what it needs to actually answer a question. So you'll see a lot of, like GitHub just announced an MCP, which has like a lot of GitHub functions that you can provide. And Erica was mentioning a lot of really cool implementations with like spunk, I think, and sentry. And then even I saw one for Obsidian, which I'm really excited to tinker with and see what I can do with that. But it's still very much early days, so I think it's very much evolving still. But a good analogy to it that I've heard is like LSPs. So I think that's language server protocols. If anyone, if it's otherwise, correct me. where... people can define what language structure is and then IDEs can pull that and be able to show the nice colors and underline errors and things like that. it's meant to kind of be like that except for LLM tooling. Brittany Ellich (26:47) So just to, so it's kind of like you're giving it all of these extra things that it can pull context on if it needs it. Okay, so it's like extra API is that it has available to it to get more context if it thinks that it needs to know more about something. Bethany (27:01) And it's kind of nice because previously, so with agents, for instance, if you have multiple agents in the same conversation, there could be crosstalk between different things. take the sentry and splunk example, for instance. If you ask splunk for something and it pulls logs and then sends that to sentry, that could be not great for data crossover. So MCP, I believe, should be a little better about keeping things client side so that it's a lot of the context isn't going to these other tools and rather keeping separate. Jonathan Tamsut (27:35) Yeah, that's interesting. I think, Bethany, was helpful. I think like one question I do have is like, you know, so like you're using some like base foundation model that knows, has sort of a general amount of knowledge, was trained on some general corpus, but like I wonder how MCP works with like ingesting splunk logs. Like I guess like maybe the underlying model has knowledge about what a log is, but how does it necessarily know what a Splunk log is or how to reason through these? Because is there some post-training task you can do on top of MCP to make it work better with a specific tool? I wonder how that works. I don't know if anyone has an answer to that. That's just a question I have. Bethany (28:17) That's probably the boundary of my knowledge in terms of how it's actually used in practice. But I do know with regular tool calls, which I assume it would end up being something similar to this, you provide a description for what a tool call is and does and then kind of the parameters it needs so that it gives your LLM more of an understanding for how to use that tool. And so I think there's a level of skill in prompting that correctly and making sure that it knows when it should be using those tooling calls effectively. Jonathan Tamsut (28:49) Yeah, and plug for that book by Dorkesh Patel that I linked yesterday. Actually, I'm forgetting the title of the book. Maybe we'll put the title in the show notes. Maybe not. If it's there, then you'll see it. Dorkesh Patel is pretty cool. If you haven't listened to him, he has a podcast. He interviews people, and a lot of them are... AI people and so his book was a pretty good like I started reading it was like a pretty good overview of like sort of like philosophical topics and LLMs and then just also taught like more practical stuff like how to recommended. Brittany Ellich (29:19) That's cool. I definitely feel a little bit more pressure now from the industry in general to learn more about this and, you know, see where the future of this goes. This was great. Thank you all. This feels like our normal sessions where we're just sharing things that we've learned about, which is fun. I'm sure we'll come back to AI in the future, like we have talked about AI a lot in the past. How about we start wrapping things up and talk about one app idea if you are not already committed, something that you would be exploring right now with AI if you are not already committed, over committed. Erika (29:53) So speaking of like knowledge bases, I use Slack a lot as a knowledge base. And I do have Slack AI enabled, which is nice. And when I search for something, it provides suggestions or like, you know, a variety of results. But I have found it. pretty limited. And I think something that I would love to build is a more complete search result page for Slack, including like suggested keywords, like suggested alternate searches, ranking by relevance or like time. And then also I have this like idea of like a visualization or there's like some kind of like heat map by channel of like how often something is mentioned. Yeah. So that's what I would be building is like a supercharged Slack search interface. My dream world. Jonathan Tamsut (30:55) And I love that idea and one of my dreams is to kind of like sort of to piggyback off that is like you know there's information silos and like you know you work at a company there's just so many so much time you're just searching for stuff and so some yeah some type of like LLM interface that you know integrates your internal docs or your code issues PRs everything in slack I mean That would be super useful. So, you don't know, you know, that's a pretty ambitious app, but like, I think that like, with LLMs, training on sort of the total sum of internal documents that you'd be interested in would just be incredible. Brittany Ellich (31:30) To build on that, think I would build, I wanted to experiment with some of the Obsidian LLM stuff and I feel like if there was some connection, if we could just merge all the things together in the world, all of the knowledge, then that would be great, obviously. But if there was some sort of a connection between the notes I've taken as well as the internal documentation, maybe that's just a sign that I need to write more internal documentation so that it can all be included in that. yeah, I really would like to expand experiment more with the obsidian stuff. Erika (31:59) that would be like especially cool if there was some kind of like push functionality where like it would like suggest things in your notes like it was like searching things and being like I found this potential inaccuracy or like I found this related post that like might update whatever information you had. Yeah, again, dream world. Bethany (32:17) I think you, all should just quit your day jobs and build these things for me because I want all of these amazing ideas. My idea, well, so last week I pitched my idea and John had a solution to it. So maybe it'll happen this week if I pitch this other idea. But every Christmas my family does Christmas lists. for like what they want and stuff and without fail we- so they only talk with each other on Snapchat. So without fail we have a bunch of sub-Snapchat groups with just everyone but one person say, okay what are you getting, what are you getting, what are you getting? I would like to create an app that is basically a wedding registry except for just- Christmas or birthdays or whatever holidays and then other people can see what other people are like committing to and then the person who made the list doesn't see it. But that would be my dream. Erika (33:15) I'm like commenting on everybody's ideas, but like I think one fun alternate to that is like an evil alternative, right? Where it's like, it like sees what you get and like gets you the opposite, like suggests like... Yeah, yeah, exactly. Brittany Ellich (33:30) Like a white elephant one version of it. Yeah, the gag gift version. That would be good. Yeah, I like that idea. I like that idea a lot of I'm terrible at picking out gifts. So and I think about it way too much. So I would definitely use that. Bethany (33:44) Well, maybe I'll vibe code it one of these days. It's like just, it's simple enough where I'm like, I maybe could do it, but complicated enough in terms of you'd have to have users and like a server that it's, I haven't set aside the time to do it yet. Brittany Ellich (33:47) There you go. Yeah, well maybe next hackathon we can work on that. That would be fun. Awesome! Well, thank you all for tuning in to Overcommitted. This has been a really fun conversation. I love talking about the state of things as it relates to AI, especially because it's changing so quickly, like weekly almost. I don't think I heard of MCP before like two weeks ago and now it's like literally everywhere. So I'm glad that I finally have a definition. If you like what you hear, please do follow or subscribe or whatever it is you're supposed to do on whatever your podcast app of choice is. also now on Blue Sky which is our social media app of choice. I unilaterally made that decision because that's the one that I use the most and made everybody else make an account so we're all there now. Most of all I think the most important thing is just share with your friends until next week we are over committed and thank you for hanging out. --- ## Episode 3: Learning a New Codebase: Strategies for Software Engineers | Onboarding Tips - URL: https://overcommitted.dev/learning-a-new-codebase-strategies-for-software-engineers-onboarding-tips - Published: 2025-04-15 - Topics: Productivity & Learning, AI & Developer Tools, Technical Deep Dives - Audio: https://anchor.fm/s/102586d64/podcast/play/101123132/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-3-10%2F398184927-44100-2-7bcdb6e1d3ea.mp3 ### Show notes Join Erika, Bethany, Jonathan, and Brittany for a deep dive into one of every developer's most common challenges: learning a new codebase. Based on Brittany's popular GitHub blog post, this episode shares battle-tested strategies for getting up to speed quickly—whether you're joining a new team, switching projects, or contributing to open source. Working on large-scale systems at GitHub has taught these engineers that you'll never understand everything, and that's okay. The key is knowing where to start and how to build knowledge efficiently while staying productive. Practical strategies discussed: * Starting with a single issue to avoid overwhelm * Creating personal documentation as you learn * Using pair programming to accelerate onboarding * Leveraging GitHub Copilot for code explanation and documentation * Reading telemetry and Sentry alerts to understand system behavior * Using debuggers to trace code execution paths * Setting up 1:1s with engineers, PMs, and designers for domain knowledge * Finding good first issues in large codebases * Generating entity relationship diagrams from database schemas Key mindset shifts: * Getting comfortable with not knowing everything at scale * Understanding abstraction boundaries through hands-on work * Distinguishing between lack of experience vs. understanding * Recognizing your contribution's place in the larger system Spicy hot takes segment: The hosts share their biggest code base pet peeves, including outdated README files that don't work, stale TODO comments from years ago, unhelpful PR templates with required fields, and distributed systems that won't run locally. Whether you're onboarding to a new team, exploring an unfamiliar microservice, or diving into an open source project, this episode offers actionable advice for confident, efficient code base learning. Links * https://github.blog/developer-skills/application-development/how-github-engineers-learn-new-codebases/ [https://github.blog/developer-skills/application-development/how-github-engineers-learn-new-codebases/] Hosts * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] * Jonathan Tamsut: https://jtamsut.substack.com/ [https://jtamsut.substack.com/] ### Transcript Erika (00:00) Hey everyone, I'm Erica and welcome to this week's installment of the Overcommitted Podcast. We are a group of developers talking about the work that we do and how we get better every day at doing it. And I'm joined today by Bethany and Jonathan and Brittany. And the topic today is learning a new code base. Brittany recently wrote a GitHub blog post on this subject, which was inspired by her joining a new team at GitHub and onboarding to all the new code and the domain knowledge required there. But we figured this is a relevant topic for really any day to day of a software developer since part of the job is constantly learning new things, getting up to speed, staying up to date on new technologies and having to do that quickly. So we are going to start our discussion by going through talking about some of our strategies. So... Brittany, I don't know if you want to kick us off with kind of your overview on what you found on some helpful approaches and strategies and tools. Brittany Ellich (01:13) Yeah, for sure. So this blog post, was originally an internal post, I think early last year that I put together after talking to, getting input from a bunch of different engineers at including you three. So thank you all for your input on this. But yeah, so the goal was just to reach out to as many people as possible and figure out, hey, how do you get up to speed quickly? Especially since we work remotely, everybody's doing things a different way. So it was kind of nice to bring everything together. One of the things that I found the most useful for me was documenting and going through and, you know, I put together a high level document that I just threw everything into as I was researching this new base that I was getting on board onto. And then having that reference was super helpful. And it was also really helpful for working on the documentation of that code base later on. That was one of my hackathon projects once I, you know. started getting into it was to actually revamp our documentation as well. So it was helpful for multiple people in multiple cases. Erika (02:14) Well, that's great. I know that documentation can be amazingly helpful when it's up to date and accurate, but also a pain point when it is not. When it's either outdated or not there. yeah, paying it forward, using that knowledge to help others and help yourself is amazing. Jonathan, Bethany, do you have any thoughts on your initial approaches when faced with the new code base? Like, go to starting points and does it differ depending on the code base or the language? Bethany (02:50) For me, I'm very much a person that thrives by just having something to run with. So a starting issue, a problem or whatnot. When I started on Copilot API, I actually dove into our sentry alerts and trying to figure out where a lot of our exceptions were coming from and figuring out how to fix them or how they work and stuff and that kind of helped me start off strong with understanding what metrics we care about, where we're getting errors, how they populate through this, propagate through the system and whatnot. But I really love just having an issue or something that I understand the value of doing and then figuring it out from there. So that was definitely very helpful when I was starting. Additionally, pair programming was really helpful. Loved being able to work with people who were used to the system, who understood how it worked and its quirks and all that. And so that was very helpful while starting out as well. Jonathan Tamsut (03:53) Yeah, and you know, it's kind of it's interesting because there's you know code bases that you know vary in size and vary, you know Among a bunch of different dimensions. I think when I joined github there are like a lot of large code bases and I sometimes feel the pull to like Redocumentation and spend a bunch of time doing an overview and I found myself actually coming, you know to the point where I was like well Why don't I take an issue and let me try to finish this issue and understand as little as possible. And like about the code base. And I think that's kind of an interesting principle because it's like you're forced to like, A, it kind of solves like I'm totally being overwhelmed. B, I think just like diving in and doing things is super, super useful in like just how I learn. And C, like It also kind of teaches you maybe a little bit about the abstraction boundaries in a code base. Hopefully you can work on this little module, understand it, change it, and there's this tangled mess reaching out into far off reaches of the code base that you can change. And if there are, well, you'll learn about it when you either run it locally or test it or, case scenario, ship it and things break. So I think that was helpful. Yeah, I think... Yeah, pair programming is certainly helpful. think like architectural diagrams are like if there's like a strong architectural philosophy to code base, which I think like generally good code bases, there's a little bit of forethought into like, this is how we're organizing things. These are sort of our guiding principles. I think those are really powerful and kind of just like universally applicable through a code base, hopefully. Erika (05:21) you mentioned in your blog post, Brittany, the importance of having some good first issues tagged as the maintainer of a code base. And I think that definitely touches on what Jonathan is saying of, you know, like having a large code base can sometimes be overwhelming. And sometimes the smallest things can take the longest time if you're if you don't have the basics of running the code base and getting everything set up. yeah, those are often really good places for initial contributors to jump in. Brittany Ellich (05:50) sure. think one thing too that Jonathan said that really resonates with me is when I working at GitHub is the first time I've worked at a big tech company. And one of the things that I had to learn was to learn to be uncomfortable with not or get used to the discomfort of not knowing everything where previously I've worked in a place where, you know, I could see end to end where everything was. GitHub and a GitHub scale, that's just not possible. You know, I worked in actions, we all worked in actions for two years and I still at the end of that I was like, I'm not really sure how this works. you know, like there's, yeah, it's a different scale and you have to really be, accept the fact that you're not gonna know everything, which is hard. Erika (06:32) Yeah, I think that also highlights the importance of knowing where your contributions fit in into the wider scale. So even if you don't understand how everything fits together, if you know where your piece is being used and how it potentially relates to other parts of the code base. that's helpful. Like, for example, like Bethany was talking about with using telemetry, like, is this a hot path? Is it very error prone? Like, do we get rate limited? Does this have existing issues? Like, how is this performing now? So that when you look at it, you know, in production, like, did I make it worse? Did I make it better? Yeah, so that's also... Yeah, a good place to start with kind of understanding the context of your change or your contribution without boiling the ocean and having to understand every single layer of the application. Jonathan Tamsut (07:33) One other thing that came to mind is using a debugger. I know there are members of our community who are anti-debugger, but I think just putting a debugger and walking through your code has definitely been helpful to me. it's sort of similar to like, if you're using a distributed tracing system, right? It's like that, but just locally. Erika (07:52) Yeah, another tool that you brought up, Brittany, was using Copilot. And I have to admit that since I read your post, I have been using some of the prompts that you suggest around asking Copilot for specific input-output scenarios or to explain in plain text what a method is doing. And I have found it super helpful. for jumping into parts of the code that I'm not as familiar with. So thank you for providing those suggestions. And anything else that you've found since writing that or Jonathan, Bethany, any experiences you've had with using Copilot for jumping into a code base? Jonathan Tamsut (08:34) I used copilot yesterday actually to, I was reading a file and it was actually a relatively straightforward file but I don't know, was just, there's something about it that wasn't parsing and I just asked copilot just questions like, know, what happens when this flag's not set? Does this line get called? Et cetera, et cetera. And it did a pretty good job, I think, right, like with cross file stuff. copilot can maybe struggle, I think I mean generally my general philosophy with copilot and and maybe I should make it more sophisticated I just ask it questions in You know that I would ask any human or that I just organically have but I'm sure I could be prompting it better Erika (09:12) But one other use case I've used it for is creating documentation from database schemas. So having Copilot create like an entity relationship diagram from a schema or something if that's not available. It's actually done a pretty good job. It'll generate like a mermaid diagram. So yeah, that's kind of a nice thing to have. Brittany Ellich (09:35) Something I came across recently is I've kind of accepted that I'm just not ever going to be a good Ruby on Rails developer. And so I've really offloaded a lot of that to a lot of that logic to copilot. There was something yesterday where I was like, why is this? You know, I was trying to just do a Boolean check and for some reason, like the bang before the like different ans. Anyway, I can't explain it with words. but I could not figure out why it wasn't, you know, equating to what I thought it was. And I gave it to Copilot and it was like, oh, you just have to do this because this, you know, in Ruby, this is going to be evaluated before that. I'm like, there's no way I would have ever known that, that that was the reason that that was the issue. So I'm happy that that exists. Erika (10:11) Yeah Bethany (10:15) Yeah, I agree. I think I always struggled with writing in Rails because it was very magic to me. And so I really appreciated that, like, you can look up documentation for anything. I could say, yeah, how do I do this in Rails online? But it's harder to understand how to do something idiomatically in these, like, very opinionated languages. Like, I feel both Go and Erika (10:15) them. Bethany (10:41) are very opinionated but in opposite directions and so it was really helpful to say, hey, I want to do this, how do I do this but idiomatic grails then it would... tell me and I was like, OK, that makes sense and walk me through exactly what's happening in the code snippet so I would understand for the future. I do just really love that it almost turns your code base into your own personal Stack Overflow. So you can go in and ask a question like you would in Google and have references and examples and stuff from your code base, which is just really cool, I think. Erika (11:15) It is cool with the caveat that as with Stack Overflow, it's dependent on the quality of the previously written code. So if you've written a quality code base, then you're going to get quality answers. Something that we have... all mentioned as a helpful communication tool or practice for getting up to speed is pairing. And this is a way to get tips from coworkers, colleagues, expertise from people who've worked in the co-base previously. But something that I know I've had is varying degrees of success with. with pair programming, sometimes for reasons of the person that I'm pairing with, but sometimes also for myself and holding back any questions I have because as a newcomer, sometimes I don't want to like I'm asking too basic of a question or something like that. So is this something that any of you have struggled with and maybe have you? overcome it by, yeah, like knowing what questions to ask or, yeah, making pairing successful. Jonathan Tamsut (12:25) Shout out to episode 1 on imposter syndrome. Bethany (12:28) Yeah. I think with pairing, you have to kind of treat it like an investment of some sort. Like, you're probably not going to be, no individual is going to be as productive in terms of output of work because you're not necessarily just purely working, you're having conversations. It's more of an investment in understanding the code and having this shared knowledge and shared collaboration experience. So I think it's beneficial in ways that aren't related to maybe like how long it takes to code something. Because it'll nearly always be quicker to just like pump out code, at least if you're familiar with the code base and whatnot. So I don't think, I think it's important to not be scared to ask questions because that's kind of the... purpose of pair programming is to have that outlet and that way to understand better. At least when I pair program with people or especially people who are newer, I always can tell when they're holding back just because I'm like, okay, I understand what I'm saying doesn't make sense, but I can't really. unless I know how it doesn't make sense or how I can rephrase. I really think the sessions with just a lot of questions are the most fun and the most productive in a way. Jonathan Tamsut (13:47) Yeah. And I think, you know, it's interesting, you know, I don't like, like what makes a good pair programmer. think right. Like, I think if, if you're, if it's sort of like a teacher, you know, there's kind of different ways you can pair program. Like sometimes I'm just like, there's like something that I'm stuck with, but like, I just, like, I could solve it, but I don't have sort of the right mental configuration. So it's not like, it's not necessarily that I'm like missing facts. I just need someone who has like a different perspective. And then there's pair programming where like, yeah, one person is teaching another. I think it's like, when I try to do that, I try to be as like selfless as possible, know, sort of, you know, really, really try to focus on like their experience. I think like they should lead if you're trying to teach someone and like you should kind of be there to, but it, you know, to guide them, but it requires like patience. And I know, you know, that's hard. And I think also people, I think people in general, especially people who are more experienced forget how difficult things were when they started and forget that they struggled too. you know, there can be frustration there. Erika (14:43) I also find that sometimes when you're working with somebody who has worked on the code base before, sometimes they'll apologize or qualify that the code that they've written as sort of a cover-up scenario. you know, code is code. It's written. If it's done, it's there. Like, it's really okay. You don't need to qualify it. Sometimes it's a good learning opportunity to say, this is an area that could be improved. I know that this is somewhere with a lot of tech debt that we could invest in at some point. But yeah, I've found that to take tangents often in these sort of teacher-student scenarios. And I found that like going in even as a student in these like initial onboarding. programming pair programming sessions with a plan and like a set of questions and things that I want to know Maybe it's like, you know, what what are your workflows? Like what are the tips and obviously like giving room depending on who you're pairing with and like how focused they are like how good of a communicator they are but like Often having like key points that you're trying to get away from the session That you know will be helpful for you in the future has helped me stay on track. Yeah. And then also like reminding myself that it's okay to ask even the most basic questions and none of this is magic. If it's not clear to me, it's probably not clear. Brittany Ellich (16:05) One thing I've noticed working with more and more senior engineers is like the most senior people that I've worked with don't apologize for asking any questions. And they all also ask like the most basic of questions without, know, nobody else is out there saying like, wow, this person's really dumb. How do they not know this? I don't think I've ever had anybody at least say that to me. Maybe they're thinking it, but I think the further I've... When I was starting out, was like so apologetic, like, no, I'm so sorry. I have so many questions. And now I'm realizing ask them all earlier because the faster you understand things and the faster you get on board, the faster you can actually contribute. people on your team wants you to ask lots of questions because it not only helps get you up to speed, but it also helps them solidify their understanding. And maybe they'll learn something by trying to answer those questions too. So it's a win win for everybody to ask, ask lots of questions. and continue to do it. Erika (16:56) Yeah, that's a great point. Jonathan Tamsut (16:57) And I think maybe this is a defense mechanism, but to me, there's the distinction, least, I'm just being dumb, which what does dumb even mean? We can have a whole podcast on that. Versus just you not having that experience, right? And so you can't really fault yourself for not having had experience. mean, you are where are. Some people who were just born before you started in this career earlier got switched to a team earlier. There's kind of, yeah, there's like, feel less bad about that and more bad about, know, maybe I should have known this had I just thought harder. But yeah. Erika (17:33) Another thing that you call out in your post-Brittany that I think is very perceptive is not only asking other engineers on your team for input or for clarification, but also product owners and members of other teams, other dependencies, any domain experts that can help you understand the problem area that you're working in. is a way to get up to speed quickly. Brittany Ellich (18:03) Yeah, absolutely. One of the first things that I do anytime I join a new team is I set up one-on-one with every single engineer on the team, but also every single product manager that I know I'm going to be working with and everybody in design or like anybody somewhat adjacent to it because I found like having that their context and their knowledge is super helpful. Erika (18:22) Yeah, that's a great idea. All right. Jonathan Tamsut (18:24) And it's, one more thing on that. It's also interesting in a larger company, the wildly different perspectives or even goals that people in different positions have. And so yeah, I think it's always interesting getting those different perspectives. Erika (18:38) The last thing we're going to talk about is our spicy hot take topic. Because we've, I'm sure all had the experience of running across things in a new code base that drive us absolutely nuts. So we are going to voice those grievances in this section of what drives us crazy when you're spelunking or. And I can kick us off. We mentioned documentation at the top of this podcast and it drives me absolutely crazy when I follow the Read Me and dutifully do the setup steps and it doesn't work. And for me, the Read Me is your entry point. And if you're going to keep anything up to date with your instructions for new people, you've got to keep that up to date. but I can't even count on one hand the number of times I have done that and everything falls flat on the floor. So for me, that is my absolute pet peeve. Please keep your read me up to date. Brittany Ellich (19:33) I like that one. I'll go next. My only real pet peeve, I think, is when I see like to-do comments that are like, we're going to fix this later. And it was like two years ago. I've just stopped writing comments like that because I know like we'll fix it when we need to, you know, well, it'll, I'll file an issue for it and, you know, get to it when we need to. But otherwise, if you're going through there and like, why, why were you going to fix this? What's wrong with it? Is it still broken? Is it, you know, is it still out of date? That's probably. That's probably mine. Jonathan Tamsut (20:02) Bethany, you want to give yours? I can give mine if you don't want. Bethany (20:03) Yes. No, I can give mine. I would say for me it's maybe PR templates that aren't very helpful or I don't see the purpose of all the information. Jonathan Tamsut (20:12) Mmm. Bethany (20:17) I know at GitHub at least we use PR templates heavily, but I don't think I've ever seen one that has necessarily made me think more about the PR I was making or made it easier as a reviewer to file through that information. So I think I like PR templates that tell you how to deploy, how to... merge your change in and what you need for getting approvals, but I think past that it's being overly prescriptive is just not necessarily helpful or conducive to making it easy to contribute. Jonathan Tamsut (20:51) Yeah, it's funny. I was kind of gonna, you know, get on my high horse and say like, I have empathy for all these developers committing these pet peeves because I've done them all and it would be hypocrisy. But I will say issue templates or PR templates that have like required fields are super annoying. And to do's are super annoying and yeah, bad readme's are super annoying. I've done them all, though. I've committed them all. So I feel, so I was, know, maybe they're pet peeves, but I understand the human who made them, who did the peeve. mean, I've worked on, like, before here, I've worked on terrible code bases where, like, I was, like, a consultant, and, like, sometimes we'd be hired to, like, kind of... Brittany Ellich (21:12) Same, yeah. Jonathan Tamsut (21:31) like replace the like like we were hired by this company to replace their foreign dev team and they were just like openly antagonistic to us and they just like gave us the code base and like like a compressed like a tar file and it just like didn't even run and So, yeah, happy having a code base that doesn't run locally Or is really difficult to run in some local environment has driven me. I mean, I know we've all experiences of you'd have has driven me crazy And you just want to test one little thing and you want this thing to run and it just can't run and especially when it's like a big complex distributed system. You're just losing life hours trying to get this thing to a point where it Erika (22:11) Yeah, it takes longer to get the thing up and running than to make the change. That's a painful day of development. Great. Well, thank you all so much for your time and your contributions to this discussion. We will definitely link the article, the blog post in our show notes and Please stay tuned for more episodes from Overcommitted about becoming a better engineer, one committed at a time. Thank you all, talk to you later. --- ## Episode 2: Quarterly Goal Setting for Software Engineers: Q1 Retrospective | The 12 Week Year Method - URL: https://overcommitted.dev/quarterly-goal-setting-for-software-engineers-q1-retrospective-the-12-week-year-method - Published: 2025-04-08 - Topics: Productivity & Learning, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/100859158/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-3-4%2F397847344-44100-2-8dc9ea6cf203b.mp3 ### Show notes Join Bethany, Brittany, and Jonathan as they reflect on their first quarter using the 12 Week Year goal-setting framework. This candid retrospective reveals what actually works (and what doesn't) when trying to balance ambitious career goals with the demanding life of a software engineer. Inspired by Brian Moran's "The 12 Week Year" and Ali Abdaal's productivity strategies, the hosts formed an accountability group to track quarterly goals—from newsletter writing and conference talk submissions to fitness and reading habits. Now, three months in, they're sharing their wins, failures, and lessons learned. What you'll learn: * How to apply the 12 Week Year methodology to tech career goals * Why quarterly goal setting works better than annual resolutions for developers * Creating accountability groups that actually stick * Balancing personal development with demanding engineering roles * How to reframe "failure" when you don't hit your targets * The value of setting goals even when you over-commit Quarterly highlights discussed: * Publishing The Balanced Engineer newsletter weekly (Brittany's journey) * Submitting conference talks to GopherCon * Reading goals (including Gödel, Escher, Bach) * Building consistent workout and stretching habits * Learning design fundamentals as a backend engineer * Writing technical blog posts Bonus segment: The hosts share app ideas they'll never have time to build, including Friend OS (a CRM for personal relationships), a customizable standing desk timer, and alternatives to Facebook Events for casual event planning. Whether you're crushing your goals or struggling to start, this episode offers honest insights into sustainable personal growth for busy engineers. Join Bethany, Brittany, and Jonathan as they reflect on their first quarter using the 12 Week Year goal-setting framework. This candid retrospective reveals what actually works (and what doesn't) when trying to balance ambitious career goals with the demanding life of a software engineer. Inspired by Brian Moran's "The 12 Week Year" and Ali Abdaal's productivity strategies, the hosts formed an accountability group to track quarterly goals—from newsletter writing and conference talk submissions to fitness and reading habits. Now, three months in, they're sharing their wins, failures, and lessons learned. What you'll learn: * How to apply the 12 Week Year methodology to tech career goals * Why quarterly goal setting works better than annual resolutions for developers * Creating accountability groups that actually stick * Balancing personal development with demanding engineering roles * How to reframe "failure" when you don't hit your targets * The value of setting goals even when you over-commit Quarterly highlights discussed: * Publishing The Balanced Engineer newsletter weekly (Brittany's journey) * Submitting conference talks to GopherCon * Reading goals (including Gödel, Escher, Bach) * Building consistent workout and stretching habits * Learning design fundamentals as a backend engineer * Writing technical blog posts Bonus segment: The hosts share app ideas they'll never have time to build, including Friend OS (a CRM for personal relationships), a customizable standing desk timer, and alternatives to Facebook Events for casual event planning. Whether you're crushing your goals or struggling to start, this episode offers honest insights into sustainable personal growth for busy engineers. Links * 12 week year [https://12weekyear.com/] * Atomic habits [https://jamesclear.com/atomic-habits] * Habit kit [https://www.habitkit.app/] * Obsidian template [https://github.com/brittanyellich/obsidian-templates] * Godel Escher Bock [https://www.amazon.com/G%C3%B6del-Escher-Bach-Eternal-Golden/dp/0465026567] * Thinking in Systems [https://www.amazon.com/s?k=thinking+in+systems&hvadid=713539923775&hvdev=c&hvlocphy=9033616&hvnetw=g&hvqmt=e&hvrand=13390567732106859148&hvtargid=kwd-10973470127&hydadcr=22538_13730679&mcid=af18f80568d93583843d5b81f649bc54&tag=googhydr-20&ref=pd_sl_55e6twjxw4_e] * Partiful [https://partiful.com/] Hosts * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com [https://brittanyellich.com] * Jonathan Tamsut: https://jtamsut.substack.com [https://jtamsut.substack.com] ### Transcript Bethany (00:01) Welcome to the Overcommitted Podcast, where we talk about our commits, our commitments, and some stuff in between. My name is Bethany. I'll be your host today. Today we have Brittany and John on the panel for a retrospective on how our quarterly goals are coming along, since we're already coming up to the end of quarter one, which is wild. So we, at the beginning of this year, We started an accountability group to start tracking our goals based on a book that Brittany read. Brittany, I don't know if you want to describe this book that we're basing all of our goal settings on, but that would be great. Brittany Ellich (00:42) Yes, I read the 12 week year by Brian Moran and the entire idea is just to break your goals down into 12 weeks at a time and try to have a lot of focus and clarity on those goals during those 12 weeks. Jonathan Tamsut (00:59) Nice. I know we talked about the accountability group at the beginning of the year. And I think one thing that inspired me was a tweet that I read at the end of last year. It's weird. feel like I don't use Twitter anymore, but I feel weird saying that it's a bad thing to be using Twitter. But anywho, so I read a tweet, I think Tim Urban, he's an author, and he wrote something, he tweeted at beginning of December 2024, he's like, what is one thing you could focus on for the rest of the month and make focused, demonstrable improvement that you'll sort of be proud of at the end of the year? And I was like, wow, that's... That was like a powerful tweet. like, I should just do that the entire year. And I haven't really set explicit goals. And so I thought, why don't I try to think a little bit more about where I want to go and make a plan to get there. Bethany (01:59) Yeah, I love that. It's really funny you all mention this because I was watching a lot of Ali Abdaal videos on YouTube. I don't know if you all have seen him, but definitely I get aggressively targeted for his videos. a lot of it is a little... Jonathan Tamsut (02:10) ⁓ yes. Bethany (02:17) over kill for me personally, but I was thinking like, man, I wish I had more goals and stuff. And he talked a lot about quarterly goals and stuff. it really aligned when we just started talking about what we wanted to accomplish this year. And it's good we have this group to really focus on things like that and hold each other accountable. So I guess we'll take a bit of a... pause right here and I'm curious, how did you all handle goal setting in the past? Have you tried different strategies before that might have worked or not worked? Jonathan Tamsut (02:48) Yeah, you can go Brittany Brittany Ellich (02:48) So, yeah, okay. Yeah, so I have done sort of a quarterly approach in the past, but that was mostly for personal goals, not necessarily like career related goals. But if I was getting ready to do a run or something like that, I'd be like, okay, for the next three months, I'm gonna focus on running. And then the next three months after that, I'm gonna add in yoga or something like that. And I think doing that has... been more useful to me than trying to start everything at once. So this is the first time I'm really applying it to work and career related goals. And I'm really excited. I don't know. I never really thought about doing it in that way in the past. And the accountability group, actually, that idea came from the book as well. I was very nervous to reach out to you all at the end of last year and be like, hey, do you want to do this thing where we all just like meet and talk about the things we're working on? But I mean, you all were. open to it, which is awesome. And it's been good so Jonathan Tamsut (03:39) Yeah, and I think at actually the end of last year, Ali Abidal has like an accountability group service that you can like pay for or something. And I was like looking into potentially doing that. So I'm glad you guys saved me like 70 bucks. But I feel like, goal, yeah, you know, I feel like a lot of my life, the kind of goal has been kind of obvious, like in high school, super focused on getting into college. That was, you know, that was sort of like almost seemed predestined. There wasn't really anything else, you know, in college focused on getting good grades, right? Early in my career, it was just like getting jobs and like growing. And I think like, I feel like in the last couple of years, I've reached a point where it's not as obvious, right? There's sort of like an expanse in front of me and I'm like, well, what, what do I want to be doing? So I think, I think like part of goal setting for me was also just like thinking about values, thinking about like where I wanna go. And I think the last couple of years, you know, I just haven't really had a set direction. It's kinda, I've just, you know, I've been kinda taking things as they come. So I wanted to be a little bit more deliberate about like, how am I spending my time? And like, what do I wanna do with my life? Bethany (04:44) That is very relatable. Yeah, and I think it's been similar with me for, like through college, I would set semester goals or whatnot, like this semester I'm going to aim to do this or this semester I'm going to do this. like you all are saying, it was extremely structured in a way of like what your goals were for the position you were in. And since getting into a career, it's felt pretty aimless and always admire other people that do really big things in their free time and just wonder how do you have time or energy and stuff? And it's been really helpful personally to just set a goal so I have things to choose in my free time when I feel, of course rest is important, but like things to be like, okay, this will meaningfully put me in a direction that I wanna go in. Yeah, so it's been a really good experience. okay, let's get down to the meat of it. What did you all achieve this quarter? What are you proud of? Brittany Ellich (05:40) So my primary goal for the quarter was to write a newsletter once per week. And I did it. I wrote it once per week. And I feel like I learned a lot throughout that process. I'm planning to continue that for the rest of the year and just layer on new goals as I go. But yeah, it was a lot of fun. Everybody should subscribe. So the Balanced Engineer newsletter is what it's called. What about you, John? Jonathan Tamsut (06:01) Yeah, so I just brought up my goal sheet and I guess like, you know, by the strict, strictest definition of goal achievement, I resoundingly failed. But I mean, so I mean, the way I kind of did my goals this year was like, I had kind of like year long goal and maybe this doesn't even make sense and maybe this is like, you know, a good. good retrospective, but you know I had like year-long goals, maybe 10 goals, and then like this first quarter I focused on three. One was to publish three blog posts, and I published one, which is more blog posts than I published in the last couple of years. The other kind of big goal was stretching, which yeah never really developed the habit of doing. So I also have that as a goal this quarter. I actually, yesterday I stretched and I kind of decided that I'd need to like really make it as atomic, as short as possible. And so I kind of made that goal a little bit clearer. But in terms of my goals that like maybe I didn't specifically prioritize for this quarter, I actually did. you know, achieved some of those. I read, you know, I read four books, which is, I think that some total of books I read last year. So that was great. I also like worked out a bunch. I wanted to work out 45 times. I worked out 43 times. And there were certainly times where like, I didn't want to work out. And then I thought, well, you know what? This is like a goal. So I want to, you know, so that was like sort of a good motivator. There were times where I had like free time and I thought, What should I do in my free time? Why don't I do something that's sort of in line with my goals, which was helpful. So I guess my spiel is even if you totally fail at your explicitly stated goals, they can still have value. Bethany (07:42) Definitely agree. Yeah, I'm in a similar position. I think I over-committed to what I wanted to do this quarter. I did accomplish some goals, but others I definitely did not fully accomplish. But it did give me a trajectory or a direction to go in. And I did make meaningful progress that I haven't made previously on. things that I want to do. mainly the goals I accomplished was I submitted a talk for GopherCon, which, fingers crossed, really excited about, really excited about just putting in the proposal because I've never done that before, so it will make the next time less scary and less unknown. I finished Godel Escher Bach, which I have been trying to do for years at this point. So it was good to be like, all right, this is my goal to finish this book. And it was very meaningful and a great book to read. I also ended up setting goals with reading every other book that I decided to read. So not just technical books, but also like fiction and stuff, just filling my time with a hobby that I enjoy rather than. spending hours on YouTube, which I tend to do if left to my own devices. also, I really want to make a blog and I'm definitely overthinking this whole strategy, but I really just want to design something that feels like me and I don't, I've never been much of a front end affiliated engineer. I've mostly been back end. So, I decided to start by learning more about design and being more thoughtful about design. So I purchased a course called The Art of Visual Design, which has been so far very good. And my goal was to make it to module five, and I am nearly done with module four. So I'm going to consider that accomplished. And so I... I will say I also was hoping to make progress in running a 5K and that did not happen. So definitely some goals kind of fell by the wayside, but I think that was because I was a little confident at the start of the year. So for you all, what worked well with respect to setting and achieving or making progress in your goals? Jonathan Tamsut (09:57) Yeah, I mean, one huge thing is... making it super specific. like, know, goal, want to be more flexible. Do this stretch for five minutes at this time every day. And I think that's been super helpful. Like make it measurable, which is, know, obviously like excuse you towards goals that are like quantifiable, which, you know, has flaws. But I think that's a big thing. And I'm like, I'm a big like... I'm incentivized by getting gold stars basically, getting streak calendars really work on me. Brittany Ellich (10:29) Yeah, think what worked best for me was having, yeah, just one very achievable goal. was something that I knew I could get, but I think having that momentum will make it easier later in the year as I start adding more things to it. Jonathan Tamsut (10:41) Yeah. And I think, I think like looking back on last quarter, I mean, you know, I certainly had time, I think to achieve, you know, like I could have written two more blog posts. I think, I think like, you know, and I couldn't, you know, stretching right, you know, so, so I think, I think it's like, like part of me is like, I should, I should pair back. the amount of goals, but I also think there's like habit formation, right? Like if you write every day or you stretch every day and it's difficult to form more than one habit. So I think like intuitively, try to limit the amount of goals you're working on. mean, definitely two to three. Maybe I just need to do one at a time. Brittany Ellich (11:15) Yeah, this is a little bit of a spoiler, but I know that I'm planning to do more running in this next quarter. And for me, one of the things that I learned from reading Atomic Habits is when you want to build a habit like that, to just show up and do it every time. So I'm not setting like a minimum amount of time that I have to run each time. I'm just saying, hey, I'm gonna run three times a week, which means that if I show up and I run for five minutes, I'm checking that box. And, you know, to help build the habit of. Jonathan Tamsut (11:35) Mm-hmm. Yeah. Brittany Ellich (11:42) hopefully in the future running more. Bethany (11:44) Yeah, that part of Atomic Habits definitely stuck with me. That book, honestly, was just one of the most influential books I've ever read. 100 % worth it. It is, I think, a big thing, good to give yourself grace. And especially where... not necessarily new to setting habits, but it's not like we've been doing this for a while. So I don't know about you all, but I definitely, it was growing a muscle just setting a goal and trying to commit to that goal. And so I think there was a sort of meta goal in all of this of just building a habit of setting goals and being goal-minded of how I spend my time. So I think it was a really good experience of just thinking in that way. I know after we decided, okay, we're going to goal set and do an accountability group. I think my goals changed like at least five times in the time period of January. So it definitely was a skill to just kind of figure out how to even set goals. And I agree, Brittany, I was definitely. setting some goals that I knew I could achieve, like with reading books, that's what I do in my free time, but I was like, you know what, it was something I didn't do as much last year and I wanna make sure I'm keeping up with, so. Yeah, I definitely agree with you all that it's really about habits and I ended up using an app called Habit Kit to track what I was doing and so I... It basically formats your habits like your commit graph in GitHub. And John, I think you were mentioning getting a gold star and stuff. I'm very much the same way as we talked about last episode with Sparkle, sparkles and all that. So it was, it was nice to have that. And then I also tried to leverage my to-do list a little more. use things three, but I don't think it super matters. As long as you just write down what you're wanting to do, and it forces me to look at that and be like, okay, this is what I have set out today, and if I end up feeling tired or burnt out or anything like that, I have to explicitly cancel what I was planning on doing, rather than just being like, eh, I don't feel like it. So I think this quarter was a lot about trading my to-do list a lot more seriously than I have in the past. Jonathan Tamsut (13:50) Yeah, that's, yeah, that's, mean, that's can be a whole nother topic like to do list optimization. think, yeah. And I think like for me, this is kind of an aside, but like, you know, being realistic. And I think, I think like, you know, this quarter, I definitely want to be a little bit, you know, I want to be like realistic about what I can achieve while still sort of pushing myself. Bethany (14:09) That actually leads into my next question pretty nicely, but what are you all thinking about improving for next quarter in terms of how you're doing your goals or what you're setting out to do? Brittany Ellich (14:26) yeah, so I'm planning to continue writing the newsletter as a base goal for sure. And I'll probably still track that the way that I've been tracking the rest of them, which I've been using an Obsidian template. I can probably post it on GitHub or something just in case anybody wants to leverage that. But I am planning to do that. And then I'm also planning to run three times per week, like I already said. And I was really impressed with one of John's goals last time, which was about tracking the hours of machine learning knowledge. And so I want to do something similar to quantify something that I'm working towards. So I've submitted a few different proposals for talks this year, and I am a horrible procrastinator. And I know that if I don't, you know, go about having some sort of structure in the way that I prepare, then I will be preparing on the flight over to where I'm doing the talk. So I'm not going to do that. Instead, I am going to spend one hour per week working on my talks so that they're a little bit more polished. I just went to a really great conference last week, which was the Epic WebConf and every single talk was just so well done and so well polished. So now I'm like, man, I've got a fire lit under me to do something good. Jonathan Tamsut (15:37) That's I mean, that's awesome. Like yeah the the social prep. mean sink seeing people do things that you want to do really well is super motivating and How you know just having gone to the off-site so for Listeners I last week I went to an off-site and got to hang out with some my co-workers Which is unusual at github because we're fully remote company But just seeing how smart everyone is and how knowledgeable really did kind of inspire me I think for this quarter, think one of the biggest goals I have, maybe my number one goal is improving my mobility. And I'm super stiff, I don't like stretching, it's not fun. And so I'm still kind of figuring out how can I really get myself to do it. I used to have a timer at six o'clock would go off and tell me to do it, but I didn't. So I think doing it more during the morning, I like, have a streak calendar app. And I think like, you know, maybe I think one thing is like rewarding myself afterwards. I think it's like, you know, tying it to a reward and like doing it earlier in the morning is something I'm gonna try. But, you know, I'll keep you all posted. Bethany (16:37) For my goals this quarter, am, I've got to go to my list, I am hoping to read 30 books. I got close this past quarter, so hoping to get that this next quarter. And then I also, for my blog, I'd like to continue on with the design course. I... want to start a design, like a Figma design for my blog and finish that by the end of the quarter and then also just get in the scaffolding code so no styles just literally the bones for what I want my blog to be but not worry about making it fancy quite yet. So I definitely want to make progress there. I would like to submit another conference proposal. Submitting the GopherCon one was a lot of fun thinking about what what I'd want to share with the world and what I'd want to talk about. So I'd like to submit more and see what other conferences look interesting and align with things that I'm knowledgeable on or would like to be knowledgeable on. And then finally, kind of a fun one, but I want to host a party, like a fun party. And so I like, I hang out with small number of friends and like very group in like groups. I would really just like to. Jonathan Tamsut (17:37) You Bethany (17:47) do something fun to host a bunch of friends. So those are what I'm aiming to do this quarter. I think, did I mention I also want to run a 5k? I don't care how slow it is, but I want to do it. So yeah, I will probably try to at least build up some endurance there, starting out small with the 1 % better, like Atomic Habit says. see how that goes and we'll report back for sure. I think, John, what you're saying about timing is so, like, aligns with what I need to get better about too. Like a lot of these things I can do in the evening when I'm like after work, I can... hammer out a conference proposal or do some research for that or do the design course or read a book. But with working out, I overthink it every time. I'm like, I'll get sweaty and then I need to take a shower and when should I take a shower? it's just, I overthink it. I overcomplicate it every time. I think just putting it in my calendar and doing the thing is kind of what I need to do and reporting back on how that goes to our accountability group for sure. Jonathan Tamsut (18:48) I'm sad that we live across the country from one another or else I would definitely go to your party. Not that I've officially received an invite, but... Bethany (18:55) Oh, I would totally invite you all to a party. Maybe we'll have an end of year bash when we achieve all our goals. Jonathan Tamsut (19:04) I like that. Brittany Ellich (19:04) That's great. I like the idea too of a social goal as a goal. I'm a very, obviously very goal oriented human being. And I feel like I'm still sort of stuck in a rut from the pandemic years where I haven't been as social as I have in the past. So I feel like I should come up with a social goal now too. It would be nice to make a friend or something, know, see humans. Bethany (19:27) Yeah, yes. And it's like low stakes too because it's, I mean at the end of the day you're talking to friends or people who you know like appreciate you and love you and stuff so yeah. Brittany Ellich (19:40) Mm-hmm. I also want to go back to something that you said. I'm sorry. Did you read 30 books last quarter? Jonathan Tamsut (19:44) Oh, yeah, you got to talk about that. OK, then I need to know when you read. Bethany (19:50) Oh, okay, so this is actually a blog post I want to write, we'll do a little teaser. So yes, I read actually, it's probably going to be 28 books. I'm counting the end of this week as the end of the quarter. But I, well, one, I just read for fun. It's like something I enjoy doing. And it is something that's just comforting. I also realized that, so I figure if Godel, Escher, and Bach, which is like 780 pages, counts as one book, I can count like tiny books as, or short stories as one book too. So I read a lot of like shorter stories. So we went to London a few weeks ago and at the British Museum, we just picked up a bunch of like these little small books on some of the big. exhibits and so I ended up reading those. There was like six of them and there were maybe a hundred pages and they just were really interesting and something I wouldn't otherwise spend time learning about and it was really cool. And then also like reading fun stuff as well, like things that aren't necessarily for your intellectual like gain but are just like fun. So I've been trying to be more okay with reading things that isn't like high brow or a tech book or anything like that and that's helped keep like sustain the streak and stuff. But like last year I didn't, I think I read like 24 books over the whole year so it was actually, I looked back and I was like whoa I did not expect to read this much in this first quarter so it was really cool. So hoping to actually hit that 30 number next quarter. Brittany Ellich (21:24) That is incredibly impressive. I think... Oh, go ahead. Jonathan Tamsut (21:26) It is. Bethany (21:26) thank you. Jonathan Tamsut (21:29) I was just gonna say, and you read Godel Escherbach, which is a book I've started like seven times and it's just brutal. It's a brutal read. Really interesting, but brutal. Bethany (21:37) It is. Yeah, for that one specifically, think you just have to like power through not understanding things. Also, I found some outlines or summaries that were really helpful, so I would end up reading a chapter and being like, all right, this is a little too big brain for me, and then reading a summary of that chapter to kind of get the big points across and being like, OK, OK, I'm set for the next chapter now. But it was a really good book. We're reading now Thinking and Systems, and I'm shocked by how much I reflect back on Go! Dallas or Bach based on reading this Thinking and Systems book. which is also a really great read. Highly recommend for anyone who's looking for a tech-adjacent book. Brittany Ellich (22:17) Yeah, I really like that one. I do all of my reading on the treadmill. I run and read at the same time, usually right after bedtime, because that is my only time with three young children to do anything. So I have to combine my goals together. Bethany (22:31) That makes sense. Yeah, I think as I like kind of reach more for reading, I need to pair my reading with my exercise goals as well, because it ends up I just lay on this couch for all night reading a book. Yeah. Brittany Ellich (22:46) It's amazing. Bethany (22:46) All right, well, I think this kind of concludes our retrospective. Looking forward to quarter two and seeing what we achieve and accomplish and the things that we have to talk about for our goals. So for our fun thing today, this idea was inspired by Brittany. So shout out to Sparkles to Brittany. But. I was thinking that we would talk about, do a little round robin about an app idea or like a website idea that you've had, but you don't have time to build because you're already over committed. Jonathan Tamsut (23:17) Hmm I I actually so the the one app idea I've had for a while and I'm like, know, it's so, you know I've I've had trouble like keeping in contact with people like remembering birthdays even like, you know, keeping in contact with like friends actually It's funny this last week when I was in New York. I saw a friend from college that I last saw like ten years ago and so I wanted to create what I call Friend OS, like an operating system for friends. And I still think it would be useful. It would be something that help you keep in contact, set up reminders. Maybe you could even automate initiating messages to people. It would remember people's birthdays and stuff. I know Facebook and... other social media apps do this, but I don't use Facebook and I kind of wanted it to be something tiny and simple. And also, this sounds kind of creepy, but you could keep track of stuff. Maybe if a friend mentioned that they want a gift or something or want something, you can keep track of it so when it's their birthday you can remember to buy it for them and stuff like that. That's probably the app idea I think about most often. That'd be cool to have. Bethany (24:31) I will be your beta tester if you end up doing that. That sounds like everything I would love in an app. Brittany Ellich (24:38) Yes, please give up your habits for this quarter and go build that instead, please and thank you. Mine, the one that I've been thinking about recently is it sounds like really boring, but I feel like it'd be really helpful is a standing desk timer. And I say this because I know these exist, but I just haven't found one that you can like adjust the time appropriately and like track over time how much you're standing. I have a standing desk. I never stand up ever. I think a lot of people are in the same boat. Jonathan Tamsut (24:42) Yes. Brittany Ellich (25:03) You're Bethany, you're standing right now, right? Like, okay, I'm impressed. I never use mine. Okay. Yeah, yeah. So I would like to have one that is a little bit more customizable and, you know, one that I can be like, okay, I'm going to work up to standing, you know, 30 minutes, an hour or something like that. And I don't have the time to do this. I'm a little over committed. you know, yeah. Bethany (25:06) Probably the first time this quarter I've been standing so. Jonathan Tamsut (25:25) I love the tie-in. I love the tie-in. Brittany Ellich (25:28) What about you, Bethany? Bethany (25:28) Okay, I have, I might give two, so if anyone's looking to steal some ideas, please program these for me. I would say the first one, I also don't use Facebook anymore, and I despise logging into Facebook every day. Like I have Facebook for Marketplace or my neighborhood Facebook group, but usually I just try to avoid it at all costs. But one thing I miss is Facebook events, and I think people just don't like, use this very much anymore. But I miss having a space where you could say, hey, I'm having this event and I'm inviting these people. And they can invite other people or they can invite other people or it's private or it's public or whatnot. And you can post pictures there afterwards if like you took pictures and you might not know everyone, you could see the people who were there. So you could find them or like chat with them after. And so I just feel like there's such a gap in casual event planning apps nowadays. So I'd love something like that. And then the second one is my family is a big Christmas list family, like at Christmas time. We all like make our lists and like hand them out. And every time I have to create groups with everyone else. besides one family member to be like, all right, what are you all getting each other? So I'd love an app that just automates that or like says, hey, this gift is claimed. Basically like a wedding registry for regular events that aren't weddings. Jonathan Tamsut (26:50) Have you heard of a party fool? Bethany (26:53) No, does this already exist? Jonathan Tamsut (26:55) Well, so yeah, so my sort of friends have been using and you know, I should say Partiful not a sponsor if you want to sponsor us, contact. Yeah, we're open. Actually, Partiful is a sponsor I could get behind. I don't think they're doing any evil in the world. And yeah, but it's kind of fun. I don't know if it has all the features you asked for, but it's like, it's kind of just like a silly fun app that and it's like the UX is or the UI is very fun that my friends use to. Brittany Ellich (27:01) We are open to be sold. Jonathan Tamsut (27:22) parties. Bethany (27:23) That's amazing. I am looking it up right after this because that is all I want is something fun, nice to use and isn't annoying or like you have to sign up to use this or whatnot. So. Brittany Ellich (27:23) That's Jonathan Tamsut (27:38) You can use it for your party. Bethany (27:39) Okay, I'll report back on the experience and let y'all know how it goes. All right. Well, I think that's our time for this week. Thank you all for listening in to us chatting about our goals this quarter. Hopefully it inspired you to think about your goals this past quarter and what you might look for next quarter. But till then, keep committing. Brittany Ellich (27:39) There you go. Jonathan Tamsut (28:01) Bye. I do. --- ## Episode 1: Imposter Syndrome in Software Engineering - URL: https://overcommitted.dev/imposter-syndrome-in-software-engineering - Published: 2025-03-25 - Topics: Imposter Syndrome & Mental Health, Non-traditional Paths to Tech, Career Development - Audio: https://anchor.fm/s/102586d64/podcast/play/100155826/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-2-20%2F396954575-44100-2-fa12df640ace7.mp3 ### Show notes Join GitHub software engineers Jonathan Tamsut, Brittany Ellich, Erika Egemeyer, and Bethany Janos as they break down one of tech's most common yet rarely discussed challenges: imposter syndrome. In this inaugural episode, four career-changers share their personal experiences with feeling like frauds despite proven success. Drawing from the foundational 1978 research by Pauline Clance and Suzanne Imes, the hosts explore why so many engineers—regardless of background—struggle with self-doubt and fear of being "exposed." Topics covered: * The myth of the "basement programmer" and how industry stereotypes fuel imposter syndrome * Why career changers (from chemistry, biomedical engineering, and other fields) often feel they don't belong * The problematic "10x developer" narrative and why team collaboration matters more * How to measure your own success beyond technical prowess * Creating psychologically safe team environments where asking for help is normalized * Practical strategies for combating imposter syndrome and building confidence * The importance of inclusive language and accessible code Whether you're a seasoned engineer or just starting your career, this honest conversation offers validation and actionable insights for anyone who's ever wondered if they're "technical enough" to be in tech. Links * https://howwefeel.org/ [https://howwefeel.org/] * https://www.everywoman.com/my-development/quiz-there-are-5-kinds-imposter-syndrome-which-one-yours/ [https://www.everywoman.com/my-development/quiz-there-are-5-kinds-imposter-syndrome-which-one-yours/ ] Hosts * Bethany Janos: https://github.com/bethanyj28 [https://github.com/bethanyj28] * Brittany Ellich: https://brittanyellich.com/ [https://brittanyellich.com/] * Eggyhead: https://github.com/eggyhead [https://github.com/eggyhead] * Jonathan Tamsut: https://jtamsut.substack.com/ [https://jtamsut.substack.com/] ### Transcript Jonathan Tamsut (00:00) Welcome to the overcommitted podcast where we talk about our commits, our commitments and some stuff in between. Hello everyone. I'm your host, Jonathan Tamsut joined by my fellow hosts, Brittany Ellich, Erika Eggemeyer and Bethany Janos. If I mispronounced any of those. Hopefully I'll get it right next episode. We're all software engineers at GitHub and we thank you for joining. Today our topic is imposter syndrome. We're gonna talk about imposter syndrome. It's a very common ailment. A lot of software engineers suffer, but it's rarely discussed. So we're gonna talk about our feelings and hopefully get in deep. So... Yeah, so you guys want to go around and just introduce ourselves and give a little background on who we are, why we're worth listening to? Erika, you want to start? Eggyhead (00:50) I'm Erika. I am a software engineer on the authorization team at GitHub. I am a career changer. Software engineering is not my first pursuit in life. So for a long time, I've chalked up my imposter syndrome to that, but I've learned a little bit more about it and know that it is not. There can be many reasons, many causes, and yeah, there's also good news, things you can do about it. Jonathan Tamsut (01:20) Britney do you want to go Brittany Ellich (01:21) Sure, yeah. Hi, I'm Brittany Ellich. I am an engineer at GitHub on the billing team. And I was also a career changer into tech. I've been working in tech for seven years now, I think. And I did something completely different beforehand. And I think that's probably where my source of imposter syndrome comes from, although it sounds like everybody has it. So maybe it's not unique to that situation. Yeah. Bethany? Bethany (01:46) Yeah, my name is Bethany. I am also a software engineer at GitHub. I work on the Co-Pilot API team. I, in college, majored in biomedical engineering and then through some happy coincidences ended up discovering my love of programming. But definitely always felt imposter syndrome not feeling like I belonged in the tech world. I, was technical enough to be there. And so it's been quite the journey getting over that fear and that those perceptions of what people think of me. So excited to dive in. Jonathan Tamsut (02:21) Yeah, and yeah, I'm, as I said before, I'm, my name is Jonathan, people call me John. Yeah, I'm just maybe generally a neurotic and anxious person. So I think, you know, imposter syndrome has definitely been something I've faced. Yeah, I kind of came into the tech industry after, you know, after college, I majored in chemistry. So yeah, it wasn't sort your traditional like computer science to tech path. And yeah, I definitely had a lot of imposter syndrome early in my career and even to this day. So I think I'm just someone who's become a little bit more aware of, you know, those feelings and have tried to sort of grapple with them in a more kind of like honest and open way. Cool. So thank you everyone. So I guess before we begin, And you know what's funny? I'm having imposter syndrome right now. I'm not a podcaster. So I guess before we begin, we did a little background research and it turns out imposter syndrome is sort of something that's been studied for a while. in 1978, Pauline Clance and Suzanne Imes, apologize if I mispronounce those names. They published a paper and it's widely regarded to be sort of the first use of the term imposter syndrome. And their basic definition of imposter syndrome was a psychological pattern where individuals doubt their accomplishments and fear being exposed as a fraud. And one thing that was interesting is so this this paper that they published in 1978, they initially studied high achieving women. And what was interesting is, you know, a lot of these women described, and I quote, feeling an internal experience of intellectual phoniness, even though they all had some concrete evidence of success and. had concrete evidence that they deserved to be there. So kind of other sort of things that came out of the study that I think we all kind of have experience with is people with imposter syndrome tend to attribute to their achievements to external factors like luck or timing or just mistakes rather than their talent or effort. I think that's something we can all kind of resonate with. and live with a persistent fear of being exposed as a fraud. Yeah, so does anyone want to go around and talk about kind of a specific time they felt in posture syndrome and how they dealt with it? I know, you know, in sort of this highly technical field, there's a lot of like intellectual posturing that happens, whether intentional or unintentional, there's a lot of, you know, there's just Classic trope, know, I think we can all relate to where like people are like, yeah, I started programming when I was 11 on my PDP 11 machine and as you know, this, you you go on Hacker News, you'll see a bunch of those posts. And I think initially you can kind of buy into that and think, wow, I'm so behind. And I know that's something I initially felt. What about you guys? Eggyhead (05:19) Yeah, definitely that. then like a lot of the initial like studies and white papers and sort of like industry history of computer science came from a lot of like mathematicians, know, academics, lot of white men. So I think, yeah, there's there's sort of this like history, culture of like a certain stereotypical like software engineer personality or background coming from like a math background. Yeah, like you said, like having done this since I was five years old or like never wanting to leave my basement. Like those are all kinds of things that like I find myself comparing myself to and being like, I'm not that. So am I really a software engineer? Brittany Ellich (06:03) Yeah, one thing I think about a lot is I've heard this before about doctors, how like originally doctors were, they put a lot of effort into like marketing the term doctors to make it sound like, you know, it didn't use to sound as important as it does now. And I feel like some of that, maybe there's a little bit of that in engineering too, especially software engineering, where sometimes it feels like trying to build more than we necessarily are. Not that we're not building things that are incredibly important because a lot of the world runs on software now, but yeah. Bethany (06:32) Yeah, I definitely agree. And I think after recently we read a book called Domain Driven Design and things like that, and I know starting off, the language was such a big thing and is such a big way of making folks feel welcome and accepted. And so whenever I would read something or encounter something I didn't understand, I immediately would feel like I... didn't belong there or that was not a place for me or I was dumb. And I think there was through reading a lot of books and listening to podcasts, I realized, well, that's not necessarily the case. If somebody's saying something that you don't understand, that's kind of a failing of that language or that code or whatnot that. people can't come in and understand it and not necessarily a failing on your part. I mean, of course there's some things where you have to like learn languages and have questions about how languages work, but I think in all it's so important to make sure our language that we're using and day to day is just something that's welcoming for other people and accessible for folks to understand even if they're new, if they've been in this career for a while. but just making sure it's a friendly place for your folks. Jonathan Tamsut (07:44) Yeah. And I find, know, I, you know, this is something I struggle with, but like this idea of like binary thinking, like you're either a software engineer or you're not, but like the reality is like a lot more nuanced and varied, right? People have different expertise. I mean, you could have been programming since you were, you know, five years old, but maybe you don't know React, right? Which is like, you know, a tool that, you know, you may need to use in your job. So I think, right, like, There's also, you know, I think this idea that like there's a rock star programmer who knows who knows everything is, you know, you could poke a lot of holes in there. mean, at the end of the day, we're building tools for people to make, you know, hopefully improve their lives. And your pure technical acumen is not the only useful thing, right? Your ability to like empathize with the user, your ability to like work with others, your knowledge of the domain. You're you know how much you you care to make a product like accessible and available to but so there's like all these things that I that that really matter and I think certainly early in my career I kind of glorified these like geniuses who like you know knew the Linux kernel back to front and I think as you as I've just grown, know, there's there's a bunch of different types of programmers that are useful and good in their own ways and this idea that you know, some people are real software engineers and others aren't. It's just kind of a silly sort of dichotomy that doesn't really exist. Brittany Ellich (09:05) Yeah, for sure. think the software engineering industry as a whole, there's been a lot of talk about 10 X developers or the developers who are just, you know, rock stars and really good at what they do. But I've found so much more satisfaction within my own career. I mean, those people are really great to learn from, but when I'm on a team that is able to accomplish a lot of things, that's just so much more valuable. I feel like then, you know, relying on a single person, if a single person leaves, then that company is, you know, Jonathan Tamsut (09:11) Mm-hmm. Brittany Ellich (09:32) that as a load-bearing person that everything will crumble around. Whereas if you have a team that everybody is capable of doing those things, then I think I find that a lot more beneficial to work with too. Jonathan Tamsut (09:43) Yeah. Eggyhead (09:45) Yeah, it's also, I was gonna say, it's, like, also important to, like, identify for yourself, like, what your measures of success are. And this is kind of like moving ahead to, like, how do you, like, how do you combat imposter syndrome? And, like, I think one thing that always eats away at me is, like, like, am I doing a good job? And being able to measure that for myself and then also to communicate to others is really important because... you know, it's like I can put a lot of like pull requests together. I can do a lot of work, but like, am I doing the right work? Like, am I developing things that people will actually use? Like, am I developing things that won't break? And yeah, and also like, am I being a supportive teammate? Am I like building relationships with people? So yeah, but like, to sort of like draw this to like software engineering as a whole. Like I've always been a little bit surprised that there's no like, like there are certifications and stuff like that in software engineering, but like, it's not like we have to like pass a bar or like, you know, get some kind of like, you can come at software engineering from like any background. And so like as an industry, we've kind of come up with these like random, like generic. success metrics, one of which is like, you know, seemingly this like cultural icon of like, you know, the basement programmer who like never takes, you know, your eyes off a screen or something like that. So yeah, like really distancing myself from that and being like, no, that's not like I'm rejecting that as you know, what I see as valuable or like good. Jonathan Tamsut (11:26) Yeah. And I think another thing I've struggled with is like, kind of related to what you said, Erika, like disentangling my self-worth, like even as just like an intelligent, competent person from like achieving goals at work. Like I think there've been so many times I've just have had really harsh negative thoughts about myself because I wrote a bug or, you know, took longer than I wanted to on an issue. And I think, right, like Yeah, they're like, and I think I'm still like grappling with this. Like how do I, how do I hold a high bar for myself, but also like, you know, still feel like I have worked when I, when I don't, you know, sort of achieve what I want or when I make a mistake or, um, and I think, right, like in a competitive environment, you know, I think software engineering, um, you know, I think it's certain, certain environments can feel competitive. Um, right. It's. you're kind of incentivized to like appear knowledgeable. mean, right? know, no, no one, you know, I think, I think there's kind of this idea that like, no one wants to show up to work and be like, I don't actually don't know what I'm doing. And it's like, you know, I think the reality is like, to an extent, we all don't know what we're doing. And I think, I think it's important to like create a culture where like people are okay, talking about what they don't know and talking about their weaknesses and don't feel like they're going to be penalized for like needing help. Bethany (12:39) Totally agree. And I think that was one thing that... pivoted in my brain when I was really struggling with imposter syndrome at the beginning of my career is kind of accepting that my job as a software engineer isn't to know everything, but it's to be able to figure it out and get that help, get that, like read those resources and stuff. And I think once I took the pressure off of myself for being perfect or just being knowledgeable on everything and was okay saying, you know, I don't know, but I'm going to figure it out and accepting that that's an acceptable thing to say. It really changed a lot of my perception on my work and my abilities. Brittany Ellich (13:20) That's a really good point. I think that's the biggest change between when I was just starting out and now is like, I know that if I bang my head against a problem for long enough, I will eventually solve it. Whether that's by getting more help from somebody or anything, maybe that's misguided confidence, but I know that I'll eventually figure it out. And I think that is really helpful for overcoming that. Can't say that I don't feel imposter syndrome anymore, but it's helpful. Jonathan Tamsut (13:44) Yeah, no, totally. I feel the same way. It's like, you know, through chat GPT, my friends, internet, I'll be able to figure stuff out. You know, feel like I have a good enough mental model of most things to be able to like know what the right questions to ask are. Yeah. Eggyhead (13:59) curious Jonathan did you happen to see any like more recent studies of like imposter syndrome? Like I'm kind of curious like what we know now versus like what we first knew from like a psychology perspective. Jonathan Tamsut (14:13) Yeah, so I actually I used them. I think chat GPT deep research to look for studies there. There have been more recent studies I did find. It was funny when you know, I think I mentioned this to you before, but one study was like, you know, and imposter syndrome is also found in men, which I thought was was funny. Eggyhead (14:30) Yeah. Jonathan Tamsut (14:32) I don't recall exactly what these newer studies, but yeah, that would be interesting to like double click into. mean, yeah, I mean, especially with how the software engineering has evolved, I think it's become, you know, more diverse, certainly than it was, you But yeah, it's, I wonder what sort of these like changing dynamics, more diversity, there's been, you know, I think. I feel like lot of tech companies have had, I mean, a lot of tech companies have pretty unforgiving culture, it also seems like generally there's been a shift to be a little more thoughtful about how people interact and unconscious biases and stuff like that. But yeah, good question. Brittany Ellich (15:14) think it's probably something that would be really hard to measure too, right? Cause I mean, my own level of imposter syndrome goes up and down during the day, depending on what I'm working on. And if I've recently fixed something, so it's probably like company culture, which is just really difficult to measure. I would think. Eggyhead (15:14) Yeah. Jonathan Tamsut (15:22) Yeah. Yeah. Yeah, it is sad or, you know, it's funny slash sad how much like my own self worth is a function of just like, did I just figure something out? It feels so good to figure something out no matter how trivial, but it feels not fun when you're like, man, I should be able to, you know, do this. Brittany Ellich (15:42) Mm-hmm. Eggyhead (15:50) I know we all took that quiz, which I thought was kind of insightful and also like more evidence for this idea that like imposter syndrome is like mostly something that affects women because I found the quiz on like, I don't know, womenscareerdaly.com or something like that. And it was like a quiz of like different types of imposter syndrome. And yeah, I feel like that helped me kind of look at it. Jonathan Tamsut (15:53) Mm. Eggyhead (16:16) Maybe like I said, I used to attribute my imposter syndrome to being a career changer and I kept thinking like, if I had only started when I was five, I wouldn't be feeling this way. But like this quiz kind of had you self-evaluate on a bunch of different situations of like how you respond. And I think my persona type came back as like. someone who's always seeking more knowledge. Like I never feel like I know enough. I was like, actually, I think that that's true. And like, have felt this my entire life, not only in software engineering, like I've felt this in everything that I've tried to do. Like I'm always chasing that next, like that next level of expertise. Jonathan Tamsut (16:58) Yeah. Brittany Ellich (16:59) Yeah, and just to speak to that quiz, we'll share it in the show notes, but I think it was, are five kinds of imposter syndrome, which one is yours? Yeah, I ended up, I took that and I got the Superwoman, which again, I think it's on everywoman.com. I'm sure that it applies to both, to everybody equally, but. Yeah, so the superwoman is most likely to show up through a preoccupation with the need to take on multiple roles and excel in all of them, which definitely resonates with me. I think when I feel like I'm not doing well, then I just do more things and see if that fixes it. And it never does, but it makes me feel like I'm doing something. So yeah. Jonathan Tamsut (17:35) Yeah, yeah, this, I think this quiz was intended for women, but I took it. And I got a perfectionist, which, you know, I don't know if I fully resonate with that. I know Bethany, you also got perfectionist. I feel like you're, you know, not to throw you under the bus. I feel like you're maybe more of a perfectionist than I am. But yeah. Yeah. Brittany Ellich (17:54) You're a perfectionist at being a perfectionist. Bethany (17:56) No, I think I did resonate with that. And actually it was very funny. I saw it was the most common one and I was like, wait, I want to be an uncommon one. I want to be the perfect kind of imposter. It was my first thought, but no, it is absolutely true. could, a lot of times I struggle with that activation energy of doing things just because I know I want to make it as perfect as possible. Brittany Ellich (18:09) That's funny. Bethany (18:21) So sometimes I struggle just so hard with starting because I just, I put so much on what I'm doing that it's difficult. Brittany Ellich (18:29) I find it kind of hilarious that John has imposter syndrome about his imposter syndrome. Bethany (18:33) Haha. Jonathan Tamsut (18:34) And it's, you know, I think like one thing that interests me about this and you know, this is, is like, like, you know, we all have different backgrounds, different childhoods and stuff. And it's just, it's like, you know, I, I've spent a lot of time in the last couple of years, like unpacking how like my childhood, my relationship with my parents, et cetera, kind of like, you know, you know, shapes my, my attitudes and feelings towards work. and it's, yeah, it's like, you know, I think, I think for me, you know, kind of like, like this desire to be special, or this like, and I didn't think like being remote, working remote, you know, sort of exacerbates that. Like this desire to like, kind of be seen as special in the eyes of others, kind of is related and adds to this. and you know, when you, I think one thing I've really struggled with is like, you know, like I want to be seen as exceptional. And, you know, how do you, how do you sort of, you know, you know, go about your day and, you know, not let that sort of, you know, kind of guide everything you're doing and just, you know, not make you sort of extra competitive. So I think these are, I feel like these are things I've like dealt with more recently in my career is like, kind of these like, maybe deeper core, like little T traumas. But I think it does kind of tie into imposter syndrome because a lot of it is about like managing perceptions of others. And I think, you know, at some point, just realizing that, realizing that like, you know, most people aren't judging you as harshly as you're judging yourself. And a lot of these like drives are just like, totally internal, was kind of an important realization for me. Bethany (20:05) I completely resonate with like all of that. Like the thriving on praise, I totally do that. For those who aren't internal to GitHub, have a system called sparkles, where you can sparkle people for doing stuff. It's like kudos, like kudos to so and so for helping out with this. And I gamified that from the first like minute here. I'm like, I'm going to get the most sparkles. Jonathan Tamsut (20:10) Yeah. Mm-hmm. Bethany (20:29) I'm afraid to say I have not gotten the most sparkles, but it's definitely sparkle-driven development for me. But John, I think that was such a good point on how your childhood, how your life has influenced you and these things. And I think I certainly have talked about this so often in therapy, where I would come and- And she's like, how's your mood? And I'm like, I feel horrible because this person thinks I'm dumb. And she's like, well, why do you think they think you're dumb? And you have to explain it that it's like, okay, they probably don't think I'm dumb, but I feel dumb for having to say this or ask this or be wrong about this. I think going to therapy has been so helpful for just understanding like those, like when I'm mind reading or when I'm like assuming I Jonathan Tamsut (21:00) Thank and Bethany (21:20) know what people are thinking about me. And it's really not in my hands. It's not something I know. I can't mind read. I think it is so intertwined with your mental health and your mental well-being. And it's so important to keep check on that as a whole to influence your happiness in your career and make sure you can mitigate those occurrences of imposter syndrome even better. Jonathan Tamsut (21:43) Yeah. And you know, we work in this like hierarchy of people and you know, people think engineering is this like, you know, objective field where all just there's right answers to everything, but we all know that's not true. this is, there's sort of this like dynamic where people's personalities collide. And so yeah, I, you know, we've all worked with people who are just. really difficult to work with. And it's like, well, you know, they're probably compensating for something or insecure, et cetera. And I really, you you wonder like, if everyone at the company, you know, you know, had to attend therapy or like, people were more open about their emotions, you know, what would that lead to? Brittany Ellich (22:20) I think if everybody in the world attended therapy, that would be a good starting point for sure, for a lot of things. I think one thing that I realized is when I entered my thirties, I feel like, I don't know if it's just like brain development or what, but I feel like I have so much better ability to like step out and like see things from a broader perspective now than I ever had growing up. And I think a lot of that is like, you know, as a teenager and in your twenties and stuff, you're so focused on yourself that it... Jonathan Tamsut (22:25) Hmph. Brittany Ellich (22:48) it's like blinding to everything else. And I feel like as I've gotten older, like I've just gotten so much more perspective on things and I'm like, nobody's paying attention to what I'm doing. Nobody has any idea what I'm doing because I have no idea what everybody else is doing. Cause you know, and I think that has been really helpful too. And unfortunately I feel like that's something you just get with time or maybe with maybe with mental health, taking care of that. it's not. Eggyhead (23:08) Yeah, I mean, definitely like not everyone can attend therapy. Like it's like, you know, some people like it's cost prohibitive. It is expensive. But like, yeah, I mean, being able to like share out what we've learned and like help others like develop that mental toolbox. And yeah, like I've definitely found great success. with the approach of when a negative thought enters my mind, inspecting it, like stop stopping, taking a breath, inspecting it, like asking myself like, where is this coming from? Is this true? Yeah. And like, if so, why? If not, like I can forget it. I can leave it at the door and like not worry about it anymore. And yeah, and also kind of like that toolbox of like, okay, are there patterns that like feed into, you know, what makes me feel this way? And yeah, I mean, for me, it's like, always thinking that I'm not going to know something and thinking that like, oh, if I don't know something, everyone thinks I'm I'm like learning how to like track my own knowledge. for myself and like proving to myself that no, I do know these things or like if I don't then like this is how I can find it out. And like I've learned a ton from all of you of like toolboxes, like mental modeling, mental mapping and stuff like that. So yeah, I've been very lucky to learn from you all on how to track my knowledge too. Yeah. But yeah, I mean the point of like, even like get rid of imposter syndrome? in my mind, it's not to become like a better worker bee, you know? It's like, because it like reduces my mental toil. Like when I come to work every day, because I'm, you know, unless I quit my job, like I'm gonna keep coming to work. And like, yeah, am I gonna be happy throughout my day or am I gonna be like upset and like sad? And I feel like this is one of those things where like, when you kind of learn how to deal with it a little bit better, your mental toil, like at least like the emotional side of work is a little bit lighter. Because you're not so worried about, yeah, like am I a fraud? Jonathan Tamsut (25:23) Yeah. And I think like, you know, hopefully there's like one aspect of, or more of this job we all like, you know, whether it's the social. And I think for me, like one thing that's helped me is like, you know, I like solving puzzles. I like problems. and so focusing on that and being less like evaluative of myself and just like kind of immersing myself in the enjoyment of like, hey, this, actually like this job and, you know, there is like inherently struggle because we're solving problems that are like unknown. And so I think that's I also, I also think, you know, it's funny, like, you know, kind of taking a step back, I, for me at least, like having emotions, you know, or like, not having emotions, we all have emotions, acknowledging my emotions and being consciously aware of them is actually a relatively new phenomenon to me. think growing up, having emotions were bad. I was like, why are you sad? Or stop being so emotional. And I think just the simple realization that every human being is guided by emotions. access your conscious emotions. I also sort of believe in the subconscious and sort of that background processing, which is less accessible, but like you can at least access your conscious emotions and like, you know, kind of reason through them and understand them, which I think is helpful. Bethany (26:42) to that point, I... actually discovered a app recently called How We Feel. I'm not sure if any of you have heard of this, but it is actually one of the most beautiful apps I've seen ever. It's just gorgeous and so intuitive, but it's, I've only done it for a couple of days now, but it's really nice to, it notifies you and you're like, okay, I'm going to pause and try to name what I'm feeling right now. And there's like, it starts with four categories and then they can go like more broad from there. And I think it's really cool to just like pause, be like, like, okay, what am I feeling right now? What is happening? What's going on? And go from there. But anyways, it was a great app. figure since we're talking tech, was, it's just a good example of good technology. It doesn't make you sign in or anything, which is really cool. Right? Yes. Brittany Ellich (27:26) Amazing. That's the best part. Jonathan Tamsut (27:27) Thank Brittany Ellich (27:29) Nice. Yeah, I think if I were to boil down like what has really fixed my imposter syndrome too, I think sort of like John was saying is like accepting that there are things that I'm good at and reminding myself like, I know that I'm good at these things and trying to focus on those when I realize like there are things that I'm just not good at. And I also accept that there are things that I'm not good at and there are things that I don't really care to get better at. You know, like they're I would rather go to somebody who is an expert in this thing than actually learn it myself. And I feel like that's actually pretty valuable than compared to, you know, trying to get through a book that I don't care about or, you know, try to force myself to learn more things because it's impossible to learn everything. So I think accepting sort of what I'm good at and what I'm not good at has been really helpful. Jonathan Tamsut (28:14) I also think one other thing I I think I've seen like all of us do this, not to acute, but like kind of downplaying your accomplishments, right? Like you do something, you're like, oh, that was easy. But it wasn't, like you spent a lot of time developing skill, context on the problem and solving it. And I do this so much where I'm like, yeah, but this thing I did, that was easy. It's not that impressive. And I think... That's something I still do to this day and probably should do less of. Brittany Ellich (28:43) Yeah, you don't see all of the work that was underlying to build up to that skill. It's like, think I see this often when people are complaining about how much people charge for being a photographer or something like that. And it's like, well, you don't see all of the work that they put in to get to this point. Yeah, they might only be spending an hour with you and a few hours editing afterwards, but all of the work that they put in to learn this skill is also really important. And that's also what you're paying for. Jonathan Tamsut (29:09) I also kind of one note I had in the research or the prep for this was, know, we live in, you I think the technology field is like, there's a lot of hype and new technology and there is kind of this pressure I felt to like spend extra hours like learning weekends, you know. And I think that kind of ties into like the sort of the competitive nature. of all this. And like, there are times where I've, you know, really felt like I needed to kind of work on the weekends to learn a new technology. I think, you know, sure, like that's helped and that's been nice. And there's been times I've done that and I've enjoyed it. But I think now I definitely value like work-life balance. And, you know, I think there's sort of like limited utility to that. I also just like, I need rest. Like I'm so much more productive when I've, you know, had it kind of, you know, gotten away from the work. Brittany Ellich (30:03) Absolutely. In the interest of time, we should probably, I think we could probably talk about this for forever. But is there anything, any remaining last things that anybody wanted to bring up related to? Jonathan Tamsut (30:11) Mm-hmm. I feel like you know this is you know, if like we were just having a conversation on like there's this like weird added pressure when you know it's being recorded for a podcast. Brittany Ellich (30:26) Yeah. Well, I feel like this is one thing that, you know, we've been meeting since we all started here, basically. And we've had these discussions, which is why, you know, I think we all felt like, this would be good to share with other people potentially. Because I think we have, you know, maybe this is cocky or whatever, but like, I think we have like pretty insightful, interesting discussions that I learned a lot from all of you. So it is definitely a lot more pressure, when we just got to pretend it's not for time. We're just on Zoom. Jonathan Tamsut (30:30) Yeah. Eggyhead (30:50) Yeah, I feel like the only thing I've filtered is like, I've made sure to mute myself when there's noise in the background, which I can't guarantee if my dogs freak out about something. And then like making sure that I don't talk over people because I definitely do do that. But Brittany Ellich (31:00) That's fine. Do we wanna talk about, okay, I'll let John, since you're commanding this episode, I'll let you. Jonathan Tamsut (31:12) So we're gonna do the guess the commit. Brittany Ellich (31:14) Yeah, we just need to like tail off of the imposter syndrome and move on to guess the commit. Jonathan Tamsut (31:19) I don't have a... So it's gonna be, you're gonna show us a commit, we're gonna have to guess what it's about or... Eggyhead (31:26) all I'm going to give you is the commit message. Jonathan Tamsut (31:28) Okay. And then, and then what do we, what's the game? What do have to do? Eggyhead (31:31) guess what was actually committed. Brittany Ellich (31:34) Okay, guess the changes were based on the commit message. Jonathan Tamsut (31:36) Okay, Eggyhead (31:36) Yeah. Jonathan Tamsut (31:36) awesome. Okay. Okay, well, that was a great topic or conversation on imposter syndrome. I appreciate you all for sharing. We're gonna now move into our sort of canned or our reoccurring segment called Guess the Commit, where we are shown a commit message and have to... guess what sort of the code was about that corresponds to the commit message. So, Erika, do you want to? Eggyhead (32:04) All right, so was telling my co-hosts a little bit before that this was my idea. I thought it would be fun. And then I started looking for commit messages in the GitHub repository and a lot of them are like merging the master branch. So it took me a while to find something that was even mildly entertaining and I will continue to search for. other repositories that might have spicier commit histories. But the one that I have chosen to bring to this segment today, the commit message is OMG, it actually works. What do you think was committed with this message? Bethany (32:43) ⁓ I feel like I know who made this one actually. Eggyhead (32:47) What? Jonathan Tamsut (32:48) Wait, and this was in the GitHub repository? Okay. Eggyhead (32:53) ⁓ huh. And I think I searched for the last six months. I think that was like... Brittany Ellich (32:58) That's good, good context. Bethany (32:58) I'm gonna say co-pilot. Eggyhead (33:00) Okay yeah, committed five days ago. Bethany (33:02) Co-pilot policies. That's my guess. Eggyhead (33:04) Okay, any other guesses? Jonathan Tamsut (33:06) I mean, this sounds, sorry, gone. I mean, this sounds like most of my commit messages, which. Brittany Ellich (33:06) This could. Jonathan Tamsut (33:11) I don't know. Something, yeah, something, I mean, really could be anything. I'm gonna guess copilot policies. Bethany (33:18) Hey. Eggyhead (33:18) Our original love you Brittany Ellich (33:19) I, yeah, this could be anything. It's probably something that is somebody surprised that it actually worked. And yeah, I don't know. I don't know. Jonathan Tamsut (33:27) You Brittany Ellich (33:30) You can, tell me. Eggyhead (33:31) All right, so this change modifies the deployment button logic and cleans up unnecessary code in the header component. Jonathan Tamsut (33:40) Mmm... U-I. Bethany (33:40) Wow. Eggyhead (33:41) Yeah. You are. Yeah. Brittany Ellich (33:43) Hmm. Yeah, that's a good one. I'm going to start thinking harder about what all my commit messages are now to try to make them funnier. Jonathan Tamsut (33:49) Yeah. Bethany (33:50) I'm gonna try to encode a song or something in the string of them. Eggyhead (33:55) Excellent. I figured this is another, sorry. I figured this is another way to maybe search some other repositories that are kind of fun, like some open source repositories that are fun and interesting, because yeah, I'm always curious about other repositories outside of GitHub. Yeah. Jonathan Tamsut (33:57) I, I still play it. I don't even know how to. Brittany Ellich (34:13) Open source ones would probably be good. Bethany (34:15) Yeah, I was gonna actually, maybe like, this is maybe a cut thing. Is it okay to actually talk about like the GitHub repository in a public format? Is my question, but. Jonathan Tamsut (34:23) Hmm. Yeah, maybe we shouldn't. Eggyhead (34:27) Yeah, I was also wondering, I was like, if the person who committed this listens to this podcast, they Jonathan Tamsut (34:28) Is that a security? Yeah, Brittany Ellich (34:33) no! Bethany (34:33) Yeah, Jonathan Tamsut (34:34) because Bethany (34:34) yeah. Jonathan Tamsut (34:34) that is kind of an embarrassing commit. But yeah, maybe it should be open source projects. I think that's actually a good call. Eggyhead (34:36) Yeah. I don't know. Brittany Ellich (34:37) ⁓ Eggyhead (34:42) Okay. Brittany Ellich (34:42) Yeah, we can start that with the next one too, that's fine. Eggyhead (34:45) Sounds good. Bethany (34:45) Okay, cool. That was fun though. I liked playing that. Yeah. Brittany Ellich (34:47) Mm-hmm. I like the idea. Jonathan Tamsut (34:47) Yeah. Eggyhead (34:49) Okay, yay! Not a total dead. Jonathan Tamsut (34:53) I can prepare a script, you know, intro-ing the segment so it's not me just like stumbling over. I will say, sometimes I like when I'm feeling really silly. I sometimes like posting or having a funny commit message in hopes that someone reads it and chucks. Eggyhead (35:05) Wow, maybe that'll be my, yeah. Brittany Ellich (35:06) Erika Reidson. Jonathan Tamsut (35:07) Eric reads the... Bethany (35:09) And then you squash and merge. Nobody will ever see it. Jonathan Tamsut (35:12) Thanks for tuning in to Overcommitted. We hope today's episode provided some insight into imposter syndrome and reminded you that you're not alone in these feelings. For more discussions on the real world experiences of software engineers, make sure to subscribe to our podcast wherever you get your podcasts. I'm Jonathan Tamsut, and along with Brittany, Erika, and Bethany, we're signing off. Keep committed and see you next time. Bye bye. Eggyhead (35:36) Bye. Bethany (35:37) Yay!