Bethany Janos 
Brittany Ellich 
Eggyhead 
Jonathan Tamsut 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.