11: Ep. 11 | Thinking in Systems - Book Club Recap

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.