The Changelog: Software Development, Open Source - ONE MORE thing every dev should know (Interview)

Episode Date: March 11, 2022

The incomparable Jessica Kerr is back with another grab-bag of amazing topics. We talk about her journey to Honeycomb, devs getting satisfaction from the code they write, why step one for her is "get that new project into production" and step two is observe it, her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design can translate to how we skill up and level up our teams, and so much more.

Welcome back. This is the Change Law. Thank you for tuning in. If you're a longtime listener, thanks for coming back. If you're brand new to the show or newer to the show, hey, subscribe at changelog.fm. We appreciate you. If you haven't heard yet, we have a membership, changelog++, because, hey, we increment things. Check it out at ChangeLog.com slash plus plus. You get to skip the ads, directly support us, and get closer to the metal. Once again, Jared and I are joined by Jessica Kerr with another grab bag of amazing topics. She shares her journey to Honeycomb, helping devs get satisfaction from the code they write, why step one for her is get that new project into production,

and step two is observe it. Her angst for the context switching around pull requests, some awesome book recommendations, how game theory and design translate to how we skill up and level up our teams, and so much more. It's always a pleasure having Jessica on the show, so I hope you enjoy the show as much as Jared and I enjoy recording it. Big thanks to our friends and our partners at Fastly for having our back. Our CDN back, that is.

Bandwidth for Change Log is provided by Fastly. You can check them out at Fastly.com. This episode is brought to you by our friends at Influx Data, Act in Time, Build on InfluxDB. This is the platform developers use to build time series applications. And to them, joined by Barbara Nelson, VP of Application Engineering. Barbara, we're working together to share some behind the scenes there at Influx Data. And one of the things you've shared time and time again is this idea of meeting developers where they are. What do you mean by that? This is really important to us that we're not expecting developers to make wholesale changes to their product or application to try and leverage the

power of our platform. So it's a mindset, both in terms of the capabilities of what we deliver and how we deliver them. So why do we have the client API in 12 different languages? Because we're meeting developers where they are in 12 different languages. We're not going to tell them, if you want to use our platform, you have to use Python. If you're using C Sharp, you use our platform in C sharp. Um, that mindset of meet the developers where they are means we sometimes end up building multiple versions of the same thing, but for different target audiences. So a lot of the capabilities that we expose in our web UI, we also expose in our VS code plugin. Some developers are spending all their time in VS

code. So they want a solution that works where they are today. Okay, you heard it here first. Meet developers where they are. That's the mindset of Influx Data. How they build, how they ship, how they think about DX in terms of you using this platform to build your next time series application. Bring your preferred languages. InfluxDB integrates with 13 client libraries, C Sharp, Go, Ruby, of course, JavaScript, and so many more. Learn more and get started today at influxdata.com slash changelog. Again, influxdata back to the changelog we're happy to have you i'm happy to be here again.

Yes. We had a lot of fun last time you were on. In fact, I thought it was just last summer, but then I went back and looked and lo and behold, it was like two years ago. Too long ago. Too long. Well, it was still in the pandemic, so it's all one big soup, right? It is. Yes. It was early days of the pandemic. Yes.

May of 2020. Back when we still had hope. And you had just set up a Rails 6 application with Avdi. And you had just installed Honeycomb on it. And you're like, this is cool, Honeycomb. Oh, that's right. Yeah. Which I thought's interesting because you're there now.

Right, right, right. Because first thing I was like, how will we know people are using this? And yeah, now I work at Honeycomb, which is fantastic. How'd that come to pass? Well, Charity Majors is the CTO, Mipsy Tipsy on Twitter. She called me. I was like, hey, we're looking for like a very senior dev rel who could speak to developers because they have Liz Fong Jones. I get to work with Liz Fong Jones. Nice. I get to work with Liz Fong Jones, who's like the original SRE. And I get to come at observability from more of the developer side, which is awesome because I am very excited about it. As developers, I want people to get satisfaction from people actually using the code they write as opposed to check the boxes, close the ticket. And observability gives us a way to find out whether the code we wrote weeks or months ago, or yesterday, if we're really quick with deploys, is being useful. I think we've all been on those projects where you code, code, code,

code, maybe you do something else, and you code some more, and maybe a month or three months or six months goes along, and then it gets like canceled or never shipped or right isn't that the worst i mean sure you get paid and you worked hard and so there's that feeling but then you're like no one's using my code it's never gonna it's never gonna benefit anybody it doesn't feel quite so good right right i don't like working on greenfield projects for that reason i don't want to work on anything that's not in production which is why back in may of 2020 when Avdi and I were like, let's make a Rails app. Step one is get it online. Get it up at a domain. Even if it doesn't do anything yet. Right, right. It doesn't do anything. Still doesn't do anything, but that's fine. It's a toy app. Step two is find out whether anybody's

hitting it. When people start to hit this, how will I know? I have to be able to answer that question before I make it do anything. So hence introducing Honeycomb really early. And then we can see whether people hit the site. I love being, I love that, that like, if I go to the site, I can see that. And if I interact with it,

I can see that in Honeycomb in this case. And that's just, I just feel like I've made something real in the world. Yeah. What's interesting about Honeycomb is how I can let you dig. You can see the traffic, so to speak, but then you can also dig into the details. We've done that on a recent episode of Ship It, Kaizen. Oh, nice. We do a Kaizen episode.

Every 10 episodes, we talk about ourselves basically and how we're using certain tooling and how we're building on our infrastructure and honeycomb is a piece of our infrastructure nice and in particular we're hunting down and have been hunting down like this are we holding the cdn wrong essentially even with like our s3 bucket and caching and like we're constantly digging into the the details of that and the unknown unknowns we could dig into as well as just simply website traffic. Like it's such a powerful tool. Yay. I agree.

Yeah, it is pretty cool. And actually what you're saying there very much resonates with what Gerhard Lezu, who's the host of Ship It and an RSRE on changeable.com says all the time, which is like, ship it as soon as possible, get it out there. And then you'll see if it really works or how it changes the world. Yeah, because because software up until then, you're just guessing, right? You are just guessing it works on my box is like your own little bubble. And our job as developers, I don't want to think of it as writing software, I think of

it as changing software. Because that extends forever into the future. So step one, get it out there. Step two, change it. Step three through infinity, change it. That's awesome. That's exactly why Gerhard had a little bit of a trouble with the name Ship It as the show's name. Because he says once you ship it, it's like that's the start.

That's not the end goal. Yeah. A lot of us treat that as the end goal. Like I've written this thing. Now I need to deploy it or ship it. And that's the last thing I do. He's like, no, no, no, no. That's like one of the first things you do, which is exactly what you did with that Rail 6 app.

Right. And I do it with a lot of things. I've got like a little intro to observability course, mostly up on graceful.dev now, which is Avdi's site for episodes and courses now, formerly Ruby tapas. And I mean, the first thing I did was make a course and put a little bit of text in there. And it's it's public, I don't know who's gonna look at it. I mean, right now, it's actually useful. But to start with, it's a place. And then I start adding to it and adding to it. Is there like a minimal viable concept in there? Or is it just literally like I have a fresh skeleton of an app.

I'm going to put it out there and then start building it in public. Or is it worth building like feature one and then going? Or do you sounds like you literally go as soon as possible. I literally go as soon as possible. Now, I'm not going to advertise it until I have something I actually want people to do there. Right. And if you think about it, I mean, the web is a big place. And if you have a site up at a domain, what did we put ours at? Changewith.me, something like that. Yeah. That doesn't bring anybody there. You know, it's not like opening a storefront on a street where people

are walking around. Yeah. I mean, hypothetically, Google could put in their index and somebody could find it, but they probably have to be pretty darn specific because your Google ranking depends on how many people link there. Nobody links there. It's just like there's degrees of public. There's like it's technically out there and someone could find it if they tried versus it's technically out there and someone could find it if they tried versus it's being advertised. And to honeycomb in DevRel, I'm in the marketing department, which I mean, DevRel is who knows where to put it.

Nobody does. The marketing people drawing lines between stuff the engineers make, either code or posts that we write or content that we make. The marketing people are out there drawing lines between people who might need to see it. We've got SDRs, sales development reps out there emailing people who showed interest in Honeycomb being like, hey, this resource might be interesting to you. And we've got Google ads, and we've got LinkedIn ads and social media, and all this stuff just draws the line between people who might actually use it and the stuff you've made. And I don't think most developers appreciate that if you put something out there, you might as well not have, approximately, other than that you can go test it and feel good about it. Right. Until we draw those lines.

I think a lot of us do appreciate that with some of our blogs, at least. I put it out there and no one's reading it. I think that we have some experience with that. But you're absolutely right. That inclination of like, if it's public, it will be exposed. And everyone's going to come rushing and judging. Michael Rogers had a similar sentiment. He codes in public, a lot of open source stuff. And like, it's open source from day one, right? Commit one.

And he's just out there toiling on in the public. And I was like, Michael, this thing that I'm looking at is nowhere near ready or finished. He's like, yeah, I know. I'm like, why don't you just write the thing and then keep it private and then open it? He's like, no one's watching. Like it's just, it's public, but it's like, I'm like, dude, I'm watching. He's like, well, you're the one. Well, that's your problem. Maybe there's like 10 people watching, but they understand me. They know what I'm doing. Like, he's like, you know me, you know what I'm doing here. This is not. And I was like, oh, that's interesting. Cause a lot of us like to hold our cards close to the chest and then make a big proclamation, which you you can still you still got to make the proclamation at a certain point right that's like

right making the proclamation is a separate thing from making it public right and you can even launch again too like there's in this in the marketing sense too you know like with product oh yeah you can launch once sure and you can launch again you know there's no and launch is not deploy launch is that advertising blitz. Right. That is emailing your mailing list and, yeah, announcing it is a press release sometimes. And so launch is like, I mean, it needs to come after a deploy. Sure.

Right. Hopefully. Engineering doesn't launch features. Marketing launches features. Right. That's how you get vaporware, though, is the launch comes before any sort of deploy. And there never is a deploy. When you get your system out there initially, though, so let's say if you want to use this Rails 6 app as the example,

the consensus you want to use that as an example, is when you get it out there initially, what are some of the early things you begin to learn about the system you're putting out there? What's the point of getting it out there early? What are some of the things that you're grokking from, it being in production? Is it the server? Is it how the server responds to the code you're deploying?

Is it the literal state of production and how it operates? Because at that point, it's not CPU load and it's not traffic because there is none. What are you learning at that point, it's not CPU load and it's not traffic because there is none. Like, what are you learning at that point? Well, one thing is, can I deploy it? And that's kind of a big thing. It gets you, it gets you in the mindset early of if I can't get this into production, then I haven't, I haven't done it of, of how will I do this? How will I migrate this? I mean, at that stage, the answer to how will I migrate this can be, I migrate this? I mean, at that stage, the answer to how will I

migrate this can be, I will take the app down, wipe out the database, and it'll just be down for a few minutes. But it gets you thinking about that transition of every change that I make is not just about the end state. It's always how do we get from here to there? And then the more customers you have, the more painful that is. Because eventually if you have a real site, not like our toy, if you have a real product, people are going to notice

if you take it down for a few minutes and they're sure as heck going to notice if you wipe out the database. So you have to think about migrations. You have to think about transitions. And that's what serious production development is about in the sense that usually that part is harder than just making it work to your point of changing software i just thought about this as you were saying that is each deploy to a production application is

simply changing code like you've written the code locally you know this idea of like you're not writing code necessarily you're changing code i think that deploy practice is a is an artifact of that like when you put new code out there to your application you're just simply changing it right you're taking written code and you're changing the application so it just reinforces this idea of like you're just simply changing code yeah changing existing code out there evolving it yeah and when when you when you used to that, then it helps you think of your work less as this high modernist, I must take this perfect vision in my head and make it real in the world. And I must boss all the developers around to make sure my architecture vision is perfectly implemented, which is not possible. The developers have to make sure my architecture vision is perfectly implemented, which is not possible. The developers have to make decisions.

And more into, okay, how do I take the world as it is and nudge it toward what I want it to be? And then you start feeling like really antsy when you've had a branch open too long. For some people, that's a week. For some people, that's an hour. But when you get used to working on working really close to production in the sense of you feel that the loop is incomplete until

you've seen it in production and seen that affect your traces in honeycomb it i don't know it's a different way of conceiving our role in the world as as less of a someone who implements our vision and more of someone who works within an environment to change both of us. Yeah. How far do you take that with regards to our source code? So I'm starting to think about Fossil. We just did a show about Git reset and how to manage your Git local changes and present them to your team for a pull request. And then we have Fossil, which is an SCM written by Richard Hiff from SQLite. And it kind of works different than Git insofar as you make a commit, it's shared to your whole team who's on that project.

It's immediately out there. The whole presenting even your code to your teammates isn't really a thing. He's just like, no, every change, everything you do, mistakes and all, whatever it is, it should be shared immediately and always. And there's some people that really love that model. I'm not sure if you've tried writing code that way. I've never done it.

I've used Git pretty much only. And I'm very much shy away from that. I feel like it's like getting dressed in the morning, like at a certain point I want to prepare before I enter the world. But I do see there's value. One of the values is your code is immediately shared. You never have that whole in case of fire, you know,

get push and then run out of the building. It's already. And you never have merge conflicts. Yeah, exactly. So there's like tactical benefits. But conceptually, what do you think about that? Like every chain, you know, every line of code, every keystroke, just go public with it.

So it's like live coding together. I mean, if you share a workspace in VS Code, I was doing that the other day, sharing a workspace in VS Code. And oops, we both changed that file. Oh, yeah, sorry I broke you there. Your main doesn't work because I created another main in the same directory. Let me move that out of your way. How rare is that, though? Is that pretty rare?

Yeah. I mean, it's not something that I've, even that was a toy project that I've done on a large team and I can see it being a problem on a team with a lot of workflows. On the other hand, if you're an ensemble working, well, that just goes away because everybody's sharing one typist. Right. I like the part where it just makes any conflicts really tiny because you find out about them right away. On the other hand, sometimes you need privacy. And I love branches for that in particular. I love to branch explicitly like I'm just going to try something. Yes. And no one else is going to see it.

It's going to be on my computer because you don't want this garbage. Right. I do that quite often. So that's why I'm shy away from conceptually. But, you know, we can have both. Yeah, exactly. I'm not saying I have to choose one true way. I'm just curious if you try that other direction. Yeah, because if you want to change to stick, you've got to get it integrated. And I do find excruciating the pull request process. How so? Next week I start a rotation on the Honeycomb product engineering team. And I'm like, what can I do to prep? And there's, of course, install stuff on your laptop.

And then there's this read this document about the pull request. I hate pull requests so much. I hate them. Just because of the ceremony? or what do you hate specifically? The context switching. The part where, okay, I've got this as far as I can. And now I have to wait for someone else to look at it. And then I'm going to have to come back to it.

Somebody pinged me the other day about a pull request that I made to our infrastructure repository months ago. And I'm like, did you forget about this? I like yeah I forgot about this because why the f should I remember I mean it was just like giving myself permissions to something so I merged it months later and it doesn't matter it was very specific but the more common case with a pull request that's been open for months is delete that. Yeah. So in a lot of senses, what I hate about pull request process is just a real, like unavoidable coordination costs of working with the team of getting a change into the code. I'm not just changing code here. We already talked about we're also changing running software that's going to impact users. But the thing is, I'm also changing a shared piece of knowledge that belongs to the whole team. And so part of that transition process is not just how is this going to transition

for users? How are they going to have a smooth experience? And how are they going to find out about it, which involves marketing and blah, blah, blah, blah. It's also a transition for the rest of the team because this code base that we're like mentally integrated with, we have a shared, hopefully overlapping anyway. We have a mental model of how this code works and that's how we're able to work in it. And that is affected by every change that I make. And that's one of the things we're trying to do with pull requests is I have to see what this code is going to do, but also other people need to see what this code is going to do. And they need to know why it works the way it does so that they can make the good decisions

later so that it continues to do that, et cetera, et cetera. It's almost like your own little marketing channel for your changes to your team. Like this is me announcing what I'm doing. Yeah. Because I could just push this code up and it would be in there. I know I do that on our project a lot. And Adam's like, hey, this doesn't work like it used to. It just has an end user. I'm like, yeah, I changed it. And he's like, oh, here's your announcement. It's different now. Oh, that's cool. We don't do marketing very well with each other. But a pull request, and maybe that's why we hate it because it's like ceremony and formalization and it's all the stuff that is hard for us to do. And we just want to keep making progress. It almost feels like an impediment, impedance, I don't know the word.

Compared to working alone, it is. Yeah. But it's what lets us work together smoothly. Because otherwise, yeah, Adam trips over your thing and he's thrown off. Or he breaks it completely because he's expecting it to work like it used to. The alternative to this work of coordination, this coordination of joint activity is what it is, is stumbling and tripping and unexpected problems. So how do you then, are you trying to fix the pull requests? Is it that you don't like the time sink involved necessarily or just the slowdown for you? If I had my druthers, we would do ensemble working and we would all work at the same time and there would be no conflicts and no merge requests and no broadcast because we're all right there.

Not all. There's a rotation of not everybody's there every day. But when you have enough overlap in your work, those little bumps stay little. So I much prefer pairing. And better than pairing is ensemble working. Let's just everyone who works on this piece of the code base works together on it. But you got to keep that kind of small. I mean, it's all tradeoffs.

Most people prefer to be able to make progress by themselves. And even I like some time of, let me just futz around with this for a while and learn something. That's the only way I know to avoid it. It seems like some of the things you prefer might be a rigid system in terms of everybody together means like, well, if my kid has to get picked up and it's kind of challenging to be there when you need me to be there kind of thing. Like, is that what you mean? Where it's sort of like the togetherness is good, but it seems rigid. Whereas if I can't show up when you need me to be there kind of thing like is that is that what you mean where it's sort of like the togetherness is good but it seems rigid whereas if i can't show up when you can show up jessica then you're not showing up the same way you could that day or that few hours for

example so so in ensemble working i mean the ideal is the whole team works together and say a team is five people and occasionally like other people float float into like designers or product people who contribute. But say there's a core team of five with different expertise that maintain the same piece of code. A typical ensemble is going to be four. It's just whoever's there that day for the six hours or whatever that you try to overlap. And some days it'll be three. And some days it'll be seven because you have guests. And the point is that when somebody goes to the bathroom, the group attention continues. There's like this focus that's more resilient than an individual

focus because you don't need everybody there every single minute. You need each person there most of the time. And then the direct working together is the best way we know to share expertise and have that flow between people when they can immediately say, wait, wait, that code looks weird to me. Oh yeah, we changed that an hour ago. The limitation of our work on software is not time. It's not clock time. It's not how much we can type. It's knowledge. It's how much we can know. It's all the different contexts that needs to go into the decisions of how are the people using this now? What is it supposed to do? How has this changed in the past? Why does this code look like this? Oh, it's an old style guide.

There's just so much knowledge. How does this interact with the other systems that it interfaces with? What do they even do? How does Fossil work? How does our deployment pipeline work? Is this going to break the documentation? Oh my gosh, there's so much to consider. And we try to accommodate all of those considerations by putting sections in our pull request template. And honestly, I don't want to

have to be the only person thinking about all this stuff and getting it all together. I really like working in a team. I certainly, I've never done this. So I've done pairing. I've never done more than two. I certainly understand the advantage of having different brains on the same problem with slightly different perspectives and expertise. Like, well, I know exactly how Fossil works, so I'll help you out there. Like you don't have to go ask George or whatever, like, Hey, why, you know, that will deal, it will be great. Do you find if you're not the typist, there's maybe there's four people in an ensemble. do you find it harder as just a person who's there to think and to talk and to collaborate, maintaining focus and not being distracted because there's very little movement that you're doing? It just seems like it's easy to check out in a larger group.

Yeah, of course it's easier in person because we do this shared attention thing really well in person. Right. One thing I find is that pair programming tires me out faster than programming by myself because I maintain focus better, because there's someone else to maintain my focus. And I'm not like, ah, Twitter. But when there's four of you, you can still be like, Twitter, and then somebody else is talking. Yeah, yeah. But actually, one, I'm less likely to check Twitter

because someone else is talking than I am individually. But I'm much more likely to check Twitter or more constructively go look up the thing that we were talking about and find the API docs for it. It's okay for one of the four people to have their attention wandering at any given time. Sure, because they're getting picked up by the other people. Yeah, yeah. And it's much easier to bring your attention back into a conversation

than it is like the other person typing or talking or whatever. So I actually find it much more natural to focus together. I find it requires less intense focus and it's just much easier to bring my focus back. Is this actually a thing though? Like you're seeing ensemble programming working together. Is this a real thing? What is this?

Right, right. So this is the practice formerly known as mob programming. Woody Sewell came up with the term mob programming for this several years ago. And it gained a lot of popularity under that. But there's also a lot of people going, ugh, mobs. I hear especially in Europe that there's nothing positive about the word mob. So Emily Bosch came up with the phrase ensemble working because ensemble is just nicer. It's still a group of people coordinating together.

And it's more than programming. I mean, a lot of it is programming, but, you know, we do other things. We write documentations. We fill out timesheets. Whatever it is we need to do together. Is it like in simple terms, let me see if I can just grok this without even knowing the definition of it. Is it just simply coordinating working as like, say, four or more at a particular time for a certain sustained period on a problem set? Is that what it is? It's like just coordinating times of that way.

Like I'm not working at my time zone. And in my time frame, I put two hours in and I quit. And then you come and put it's together. Right. Ensemble means together. It means together. Right. Right. Not necessarily in the same room, but together in the same problem. Right. Right. Because we have to do it remotely now, of course. It's much better in the same room, but it means one screen, one person is typing at a time and the other people are making the decisions about what to type. The person typing is a very smart data entry person.

So you take turns, right? Three to 10 minutes typing. And then sometimes you have one person in charge, again, taking turns of telling the person what to type. In a more experienced group, you don't need that. And just the rest of the group is making the decisions. This has the property that all decisions are voiced so that the whole group at least has the opportunity. I mean, maybe sometimes I'm checking Twitter, but overall I'm keeping up. And yeah, that's about it. So that there's one path of change happening in the code, not four. And that change has everyone's knowledge in it already.

And it's affected because, yeah, because of that last point, because everybody's knowledge is in it. I mean, is it typically four people? It does. Some people have six. I view a pair as a degenerate mob. Gotcha. Or a mini ensemble. Yeah.

Okay. Yeah. I'm just thinking like, because there's a lot of pushback against meetings even, right? Like, oh gosh, do all these expensive engineers need to be at this meeting? I just wonder if there's a similar sentiment. But we're working. Right. Meetings feel unproductive because we're not working.

Here we're working. We're working as effectively as we possibly can. It reminds me of that movie, Tom Cruise, Oblivion something, Oblivion Horizon. There's a narrator, I suppose, with this voice in the void that asked this team, Tom Cruise and his co-star, are you an effective team? That's the question that the AI or something keeps asking them, like, are you an effective team? And it's this response of like, yes, we're effective. And if they're not an effective team, then the voice helps them be effective. So it's like,

that's the question you all are asking yourselves is like, are we an effective team in this movement? Yeah. Not, are we an efficient team? The efficiency comes from being effective. It comes from making fewer mistakes. It comes from not having to context switch to the pull request or merge conflict or getting tripped up by not knowing everything that's going on. It's about maximizing effectiveness. When you say every decision is vocalized, do you mean down to the we're going to write an if statement right here. Oh, oh, oh. Okay, so this actually works out to be kind of cool. Because say you have like a designer is one of the team members. They take a turn at the keyboard too. They're also going to type. When the designer is at the keyboard, you're probably going to have to say at one point.

So you'll start with the overall goal of we want to check for errors. And then you'll be like, okay, we need to say if error is nil or if error is not nil. And then you'll be like, okay, type if space, E-R-R space does not equal. And so you kind of like start as you're saying what you want to do. You typically start at a high level. And then as the person at the keyboard looks at you like, you want me to what? Right. You get more and more detailed.

But then when you've got one of the developers who's fluent in this programming language up there, you'll be like, check for errors. And they'll type. If error does not equal nil, throw, blah-de-blah, close curly brace. So you get different people are like different levels of smart input devices. Gotcha. And over time, even that designer is going to know. You get good at it. Yeah, yeah.

You get to where you have to say less and less to get the intention that you're describing expressed in the code. So being effective in tandem as the team is one thing, but is it an effective and proven way to program? Obviously, it's got a name. It's got even a formerly known as name. Right. I mean, plenty of people do it. Is it accepted as effective?

Does it help your team do a better job by ensembling, so to speak? CorgiBytes is a company that ensembles almost exclusively. They're famous for their specialty in scary legacy code bases. Legacy code rocks. Yeah. Exactly. Yeah. Exactly.

I forget where Leonard works. There are other companies and teams within companies that work this way exclusively. I mean, not everybody wants to work this way and not every team is going to, but it is effective for the teams that choose it. Right. I asked you that question not so much to get you to confirm yes or no, more or less, but more so for our listeners. Like, you know know when we uncover these i would call this a hidden gem i had no idea it existed i've heard of pair programming before i haven't heard of ensemble programming nor have i heard the formerly known as version of it either

and what the details are around and i think like when we uncover these things and we have people like you on who are just super knowledgeable about things that jared and i maybe we just we're just imposters to some degree like Jared's less than I am but maybe me for sure more. Dude you can't know about everything. But like I want to uncover these details. That's what podcasts are for. Exactly that's why you're here Jessica we're learning we're here to learn. That's right you know I want you to help our listeners really understand why you all choose this practice and how it works for your team and if it truly what is it that makes it effective for you you know that's why i ask

those questions right right i haven't got to work yet for i've got to work on a team on a real piece of software doing ensemble programming um yeah i mean i'm prettyverell now. So I do a lot of toys, a lot of experiments, a lot of figuring out how to work with something. But next week I get to work on a real team. But they don't pair ensemble very much. So that's okay. It's just, it'll still be fun. this episode is brought to you by our friends at Sentry. Build better software faster, diagnose, fix, and optimize the performance of your code. Over 1 million developers

and 68,000 organizations already use Sentry. That number includes us. Here's the absolute easiest way to trust Sentry right now. You don't have to do anything. Just go to try.sentry-demo.com. That is an open sandbox with data that refreshes every time you refresh or every 10 minutes, something like that.

But long story short, that's the easiest way to try Sentry right now. No installation, no whatsoever. That dashboard is the exact dashboard we see every time we log into Sentry. And of course, our listeners get a deal. They get the team plan for free for three months. All you gotta do is go to Sentry.io and use the code changelog when you sign up.

Again, Sentry.io and use the code changelog. so speaking of things that people do together games oh games okay that's something i've done a lot more of since the pandemic started right i think we think we all have. Yeah. But I'm really, I've been fascinated by like the theory of games for a little while. Ever since I read James Carr's Infinite Games, Finite and Infinite Games, that's the name of the book, that the way humans play games says something interesting about us that is something we don't really understand about ourselves. And now from this latest book, which is called Games, Agency is Art, I finally found the connection that I'm looking for to software development. Okay. Tell us.

You know, I would like to gamify things're like, we'll set an OKR, and whoever increases the time spent on site the most will get a $5 gift certificate to Starbucks. Exactly. Right, right. Is this legitimate, or is this a... Oh, yeah. Well, $5 might be a little bit underselling.

Right, I'm exaggerating. Okay. Definitely legitimate happens, though. Yeah. But typically, they're trying to just tap into people's competitive nature. Sure. And it'll be fun because it's competitive. And that makes it a game.

And then what you get is a bunch of dark web tricks that just make it harder for people to navigate the page so that they stay on it longer. I mean, among other things. Sometimes you defeat your objective by aiming too focusedly on the key result. Right. The close button moves when you try to hover over it kind of thing. It's like, I cannot catch the close button. That's the, yeah, the smash the monkey. Remember the old ad, smash the monkey? If we make it not work the first time, they'll click it twice as much. Exactly.

Double your click-through rate right there. It's like double the points. That's also an exaggeration. But in marketing, this can be like, okay, we want more product signups. Let's offer a t-shirt to everyone who signs up. And then you get a bunch of garbage signups. Yeah.

And you give out a bunch of t-shirts to people who could care less about your product. And you have, you actually, it's a negative to have those signups in the product. This is garbage data. Not to mention the carbon footprint of like shipping those t-shirts to people who don't even want them or produce the shirt in the product. This is garbage data. Not to mention the carbon footprint of shipping those t-shirts to people who don't even want them or produce the shirt in the first place. Or at least, or not the people you want to have them. Yeah, it seems such a wasteful activity.

Exactly. Fabrication, really. If in marketing, because we talk about this at Honeycomb, should we offer swag for this? I think it'll attract the wrong audience. How do we attract the right audience? Because while we have OKRs and we care about product signups, that's as part of people getting value out of the product. And so we don't maximize

product signups. We work to increase product signups. That's different. So gamification, as it's usually described, is a way to like add achievements and points and give people a dopamine rush of, oh, you got an achievement of, I don't know, you deleted 10 lines of code today. Woo. Don't like incentivize me to do something non-optimal. Anyway. Also, I don't like the competitive instinct, the focus on competitiveness, because that's not what I want on this team. That's not where I want people to be in their brains. And yet, and yet there is total value in making work more like a game, not with points, not with competition. But this book finally described it for me.

When you look at games, the major magic that brings a lot of us to play them is the experience that we get from being able to solve problems that we have the ability to solve, but they're not super easy. So the example that it lists is like Super Mario Brothers. In Super Mario Brothers, the game designer gives you a few abilities. You can walk, run, and jump. And like, that's it. You can walk, run, and jump. And like, that's it. You can walk, run, and jump. Right.

But then you're presented with a world full of chasms to jump over and monsters to jump upon. And flower power. And your jump is like just far enough to get over that chasm, right? And sometimes you need to run and jump, but not at the beginning. It lets you develop that skill. Yeah. So the problems in your abilities are both set by the game designer, right?

The game designer gets to set the goal. And then as players, we choose to adopt that goal. We have the goal of reaching the flag at the end because, and we adopt it over and over and over, because we like the experience of running and jumping and getting just barely across the chasm, chasm, hole, whatever.

The gap. Yeah. Yeah. So when I look at that as one of the core qualities of a game, and then I look at my software teams. And I mean, in the real world, our ends are a lot messier. And we're never going to get the slickness of a game of I've reached the flag. I'm done with the level. Even when you deploy the software, you still need to go back and check in. Is it still working?

That flag falls down on its own. But can we come closer to setting goals, whether for a quarter or a sprint or an hour, and having the abilities that we need to reach them? It made me think about DevOps and automating deploy work, for instance, if you have a bunch of people who've been doing manual deploys and they consider that, maybe they're ops people, and they consider that a significant part of their job, well, they have the ability to accomplish the problem set them by the end of the day.

But when you automate those deploys and you give them different problems of now your job is to maintain this automation. You've taken away the problem that they know how to solve and given them one that they don't have the ability currently to solve. And some people are going to be like, ooh, now we get to learn this and that and the other. And they're going to be okay because they're excited about bringing their ability up to that level. Right. And then you give them the space for that and it works out.

But other people don't have those abilities and maybe aren't excited about getting them. And then you've broken the game for them. And work becomes a different experience. There might be a similar chasm between engineering and management. You know, like you have, it's the old Peter principle, you get promoted to the level of your incompetence or something like that. Right. Before that, you're able to bump up the problem as your skill level increases. And now you're just allowed to keep jumping in that hole over and over. It's a whole different game, right? Like, oh, now you're playing a brand new game and none of your skills transfer.

I mean, some of them do, but that can be problematic as well or challenging at least some people love that challenge and other ones are like i'm gonna go back to being a what do they call them individual contributor ic yeah yeah yeah ironic because the higher level you get as an ic the less individual your work is especially if you're doing ensemble programming. Yeah. So this book has really opened your eyes to ways to use or to not use the gamification ideas in work scenarios. Yeah, to completely rethink what we mean by gamification. Gotcha.

Can we make our work more like an effective game? Can we scale the goals of an hour, a day, a sprint, a quarter to something people can achieve? Can we give them the abilities that they need to achieve that? Automation can help with this. Automation can make things easier. I like to think about observability, for instance, giving people the ability to make useful software, as opposed to right now, the only feedback mechanism we have is, I don't know, the Jira ticket's done. So can we set a different goal? Something maybe more satisfying than close the Jira ticket. Although the close the Jira ticket can be a sub goal. I mean, you've got games within games, within games, a little puzzle games within the, the MMOs and there's right. So we can, we can do that, but can we,

can we look at our work and notice the friction? Where are our goals too easy? Where are they too hard? Where are our abilities not suited for them? And maybe that means hiring someone with that knowledge and then ensemble working with them to spread it around the rest of the team or something. That's what I love about the Mario game, honestly. And you mentioned that because I think his name is Shigeru Miyamoto. He's the one of the original. He is the original Mario game designer. And I actually got into this kick where we got into the Nintendo switch and my,

I'd kind of gotten out of like playing games, particularly like Mario games or Nintendo games. We had a Nintendo way back in the day. And then obviously we had a Wii and then we finally got the switch when my son was old enough to play and kind of got back into the, the details of like the making of these games. There's some really interesting YouTube videos out there, like of documentaries on like this game in particular,

you know, where Super Mario Brothers came from, where Mario 3 came from and like how it came to be and why Mario 2 is so different than the other games. You know, why is it so different? I've always wondered that. Well,

you have to watch the documentary, Jared. It's a whole, it's a whole podcast episode. Look for the show notes. I'll give you a cliff, a real super TLDR. So It's a whole podcast episode. Look for the show notes. I'll give you a cliff real super TLDR. So there was a Thank you. The Nintendo folks were

commissioned to make a separate game for a different company for like an unveiling of a product. And they did it. They made a whole separate game. And then they just translated those characters to Mario 2 characters. Kept similar traits in terms of their abilities that's why

princess could like jump and float a little bit and then fall right and they so it was a non-Mario game that they translated to Mario and I don't know why the details why they actually stuck but that's why it was so different because it was so foreign they wanted to you know grab things and throw things but there was always this characteristic of all the Mario games pretty much, even to this day, where level one wasn't necessarily easy. Right. But it was the basic skills you needed to learn to get to level two. And then once you got to level two or different scenarios, you learn things in level one that translated to level two that you added upon. And you got new powers and new abilities and you can fly further and jump higher right you know like luigi jumps higher than mario for example and all the characters have

their own traits and that's that's part of the game mechanics i love that about that because if you can kind of translate some of that to the way you translate skills in a team you know how can i give you level one here that builds on level two kind of ideas? And they were genius with the design of Mario. Like from a literal game standpoint and the actual way you learn how to play it. Because you play, you learn how to play by playing the game. And that's kind of really interesting. Yeah, yeah, yeah. And can we be deliberate about that in our teams?

Like maybe we don't have enough knowledge on Ansible because we've got this legacy system that's deployed in that. What goal can we choose to take on that will increase our skill in Ansible? And maybe it's make the small change to the deployment process. So some goals you choose to take on, not because they're the most critical thing in your customers by a feature list, but because they're going to give you the skills that you need to have the flexibility to do much more interesting things at level three and four. So that's another way. And I can call that gamification. This episode is brought to you by our friends at Retool.

Retool is the low-code platform for developers to build internal tools some of the best teams out there trust retool brex coinbase plaid doordash legal genius amazon all birds peloton and so many more the developers at these teams trust retool as the platform to build their internal tools and that means you can too it's free to try so head to retool.com slash changelog. Again, retool.com slash changelog. And also by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. MongoDB Atlas provides an integrated suite of data services centered around a cloud database designed to accelerate and simplify how you build with data. Ditch the columns, the rows once and for all, and switch to the database loved by millions

of developers for its intuitive document data model and query API that maps to how you think and code when you're ready to launch. Atlas automatically layers on production grade resilience, performance and security features. So you can confidently scale your app from sandbox to customer facing application as a truly multi cloud database. Atlas enables you to deploy your data across multiple regions on AWS, Azure and Google Cloud simultaneously. You heard that right. You can distribute your data across multiple cloud providers at the same time with a click of a button. And the next step is try it today for free. They have a free forever tier, so you can prove to yourself and to your team that the platform has everything you need. Head to mongodb.com slash changelog.

Again, mongodb.com slash changelog. so who's the shigeru miyamoto of our career game? Kent Beck. Oh, Kent Beck. Too easy? Easy one. Just an easy one. Okay. We should just go ask him what to do next, I guess. Go ask Kent. Just have a website where you ask Kent things. Yeah, I mean, it's incentivizing, really. That's the same thing with gamification.

How can I give you a rush? How can I incentivize you to do something? How can I motivate you to do something? How can we as a team adhere to... Is that a bad word? See, I hate the word incentivize or to do something? How can I motivate you to do something? How can we as a team adhere to, is that a bad word? See, I hate the word incentivize or motivate. Why? Here's an important part about games, also from the book. Not the only reason, the only way we play games. Sometimes we actually play because we care about winning.

Sure. There are people who care about winning. Or some people, you know, are professionals and get paid to win and so they care about money. But a lot of us take on the goals of the game in order to have the experience of playing. I currently play Genshin Impact. The real reason I play Genshin Impact is because my kids do, and I want to connect with them. But in order to have fun at the game, I choose to take on the goal of leveling up my character or defeating these monsters or solving the silly side quest. And I choose to take on the goals in order to have the experience of striving play, in

order to have a thrill of defeating the monsters in this domain or getting killed by them. And then that failure is its own kind of thrill of, oh no. And you get to tell the story to your friends. That's not the kind of thrill that I like, but keep going. But it adds to the next win, if nothing else. It does. Yeah. It raises the stakes. Yeah. So we don't have to be incentivized to take on these goals. We don't have to take on the goal of users spend more time on the page in order to, we don't have to be incentivized to take on that goal. We can take

on that goal for its own purposes, which is because it helps us make useful decisions about what change to make next. And when we're in the code, we can think about, ooh, if I add this piece of information, will people spend more time on the page? And maybe, yeah, maybe it'll draw their attention to something that really interests them. But I won't choose to maliciously make them spend more time on the page. I would totally joke about that. Well, we could make the button not work the first time in the ensemble, but we wouldn't actually do that because we've taken on this goal deliberately in order to guide our decisions in the game we're playing today. And you don't have to incentivize it because incentivize it messes it up because, oh,

but if I, but, but if I, it would be easier to make the button not work. And if I do that, then I'll win. And that's the competitive spirit and I'll beat the other people or I'll get the $5 Starbucks gift card. Sure. I think we'll get into a semantic debate around what incentivize means, but it seems like to me that you're talking about intrinsic motivation versus extrinsic motivation. Like it almost Yeah, it's intrinsic motivation when we choose to take on the goal. Yeah, right. And it's extrinsic motivation when you're like, well, but we'll give you a gift card. Right.

No, no. You don't want the people who are signing up for your product to get the swag. Well, they want certain skill sets, though, right? So you identify what skills the team has. And I guess in the context of incentivize there, I was thinking, okay, if you took your ensemble and you said, okay, well, this person needs to or could leverage more knowledge on, say, Docker and containers and what scared of Docker. I didn't really understand it. I didn't understand the difference between that and Docker Compose. And I didn't understand why YAML, the Docker Compose YAML file had various versions for the YAML. No one understands why YAML. It didn't make any sense to me until I dug in and learned.

And now once I learned it, my incentive was, okay, now I want to orchestrate some services here at my home. And I mainly use Docker in what I call home lab production, really. Like it's production for me, but if it dies, no big deal, because it's just my pie hole's not working. Technically, my internet stops working because it is my DNS provider. Hey, that's production right there. Oh, that matters. That does matter. So, I mean, that is production there.

But, you know, my pie hole is a Docker image. My Plex is a Docker image. You know, that's so for me, when you look at a team, you can say, okay, who needs to learn more about this? How can we incentivize and motivate them to want to learn more about that? Because now the team can now be more full in terms of a skill set. That was the context for me using incentivize and motivate. Or what goal can we ask them to take on that will have the effect of teaching them about Docker? What happens when you give them that goal?

Yeah, when you give them that goal. They're incentivized. See, that's what I said. We're going to get into a semantic debate. I would say they incentivize themselves. Sure. Sure. But it does happen.

What happens when they aren't incentivized, though? So that's where I think the Amazon gift card comes in. It's like, well, we tried that whole thing where you should want to go on the journey or you should want to better the thing. And it's not working. And now that's usually where these silly and often backfiring systems get put in place. Because with knowledge work, those external motivations do not work. Our job is making decisions, and we can make decisions that will reach that number and also hurt the company. And when we choose to adopt a goal like winning in a game,

we choose to adopt it for a period of time. And we always have in the back of our heads, also, I need to go to bed. As adults, anyway, the kids struggle with this, but we don't adopt it universally. It doesn't consume us. If you tell people they're going to lose their job if they don't X, you're going to get people who are consumed with X because they have to be in a way that's not healthy for the company in a way that doesn't lead to the best decisions. If you're asking people to like, I don't know, deliver packages on foot, I'm sure there's also problems with this, but there's a delivery person outside right now asking people to deliver packages on foot and you want them to go faster and you give them a prize for being faster. Maybe, maybe that might help. They'll probably just do it wrong because you've twisted their

incentives again. But if it's like physical activity you know maybe you can get people to go faster spend more energy on it and there's always a possibility of of an a good intentioned incentive going wrong right in the hands of the the incentivee i guess i don't know like the incentivizer slash incentivee, like whoever receives this incentive can skew and malign the goal set, you know, the process to get to the goal. Which is why I like the concept of games as a goal, an end that we choose to take on. Because then we still have the perspective of we chose to take this on within this context. And there's also a wider context. Right. I think that's the beauty of the title of the book that you're reading, though.

The agency. What is it? The agency of games. Is that right? Games, agency as art. Because let me share some psychological prowess that I've learned through osmosis from my co-host on Brain Science. And it's simply that when we are involved in making the choice, we're far more going to be aligned to the outcome of that choice. Whereas if Jared chooses something for me and I have no agency, to use the word of the book, no control, no possibility to input my own desires into this choice, then I'm not going to be aligned with

that outcome because I have no agency, no control, no ability to choose that thing. It's the same reason why people make or don't break habits or have certain things happen to them, you know, some sort of activities in their life because they haven't chosen to stop the pain, haven't chosen to make the change. And if you can't put that choice into place, then you can't. Like for me, even with Docker, I spent years not really understanding deeply how I can leverage it myself personally. I've always understood it philosophically and how it's used in production, of course, and how people use it in software development. But me personally, I never understood how I could personally use it in my own scenarios. And I only learned it because I chose to want to have a pie hole or to run my Plex in a

different way that made more sense for me and my storage and my ZFS and all this different stuff. Right. And you chose to set those goals. You didn't have to. Right. Exactly. There's other ways to accomplish a local file server or whatever

you want to have at home. Yeah. It's only after I've lost data so many times I'm like, I need something more robust. I need ZFS. There's your motivation right there. I'm sick of losing my data. So yeah, I mean, that's certainly, I mean, I've been literally iterating towards the current scenario, which is like

it's perfect right now. I never have to touch it. I mean, if it weren't for an update to the, to the image, you jinx it. Yeah. It's going down right now. No, it, I mean, it literally doesn't like it's so well tested. I did lose data in the past, but it's so perfect now that it's kind of boring. I told, I told Matt Aaron's the, one of the co-creators of ZFS. I'm like, it's so boring to run ZFS because it just is that great of software.

Nice. It doesn't need much administration, at least from- File systems should be boring once you set them up, right? It should be, sure. But even Plex, too, and Docker. But only because I finally chose to get more serious about running those services here locally, did I then understand what it would take to buckle down and really understand Docker, how I can use Docker Compose and all those fun things to really fully understand my system. And then you find those, I imagine you find that knowledge

useful elsewhere. Yeah. Yeah. I'm telling you about it right now. That's my usefulness. There you go. That totally matters. And my kids love watching our plex. I mean, that's the ultimate daily dose of usefulness, man. Yeah, but you chose to take on the restriction of I'm going to do this locally. Yeah. In order to have the experience of doing it locally. And also there's some other benefits of whatever excuse you have for doing it locally. Well, it's local to the network.

That's why it's local. Yeah. And that's handy. If the external internet goes down, it might still work. Production would be, I guess, non, so it is deployed. It is deployed locally, but it is accessible externally too, which does require some talking through firewalls and certain things like port forwarding and stuff like that. I won't tell you which ports I'm using because you might try and get into my network. But there are certain things that in certain ways you can get in from the outside that are done well, basically.

So it is production. It is deployed, basically. It's just deployed to a local network because that's where it lives. My Pi hole would not be a Pi hole on the actual internet by the way pie hole is a raspberry pi based firewall software it's not a euphemism for your mouth it's not your mouth p-i-h-o-l-e i like to disclaimer that so people are like what why is he talking about his mouth in this weird way it's amazing and plex is a home media server, basically. And so I've got a Linux box with massive amounts of storage, running ZFS as a file system with a Docker container that runs Plex.

There you go. See, the outcome of an accomplishment like that is not just the running software or hardware configuration that you have. It's also the next version of you. It's how you are different. And I think that's a really important part when we're thinking about sociotechnical systems. The output of each change to the software is, yes, a difference in how the software runs. But it's also the next version of the team and the code. Is the code more or less maintainable? A lot of that has to do with its relationship to

the team and whether everyone on the team looked at the pull request and knows what's going on now. But when we look at the next version of us that comes out of taking on a particular end and accomplishing it, then the means matter a lot more. If we worked on this feature together in an ensemble, we will be a different set of people. And probably the code will be a little different, but certainly our relationship with it will. Then if one person implemented it and another person approved the pull request.

That's pretty deep, Jessica. We change the software and the software changes us. Yeah, and us changing the software changes us. And we learn about Docker or whatever. Yeah. It reminds me a little bit of quantum computing, Jared. Like we're in that realm or at least in the quantum realm where with like a particular particle it's changed because you observed it right right and so to observe it is to change it there you go and so you can't like nakedly observe it without changing it it's a change because you observed it yeah

yeah yeah oh can i make another book recommendation yeah please sure i've recently finished Amanda Geffner's book. It's called Trespassing on Einstein's Lawn. Good title. And it's about cosmology. It's about how she became a science writer in order to talk to prominent physicists about their theories of how the universe began because she and her dad were fascinated by the question and a big part of the answers that she she comes to i don't think this is a spoiler is that there is no observer independence and it also really matters that there's more than one observer the universe wouldn't exist if nobody looked at it kind of thing which is why i like to deploy my software and hook it up to honeycomb because it doesn't really exist if i can't observe

when somebody hits it full circle going full circle there you go observability and ensemble gotta have more than one person so all the nuggets in one sentence. That's awesome. I like even this aspect because I can imagine one day, I don't know when, but I can imagine one day my fascination with, I love sci-fi books. I'm going to put

this on my list because I think this is probably in that wheelhouse at least. I love plausible sci-fi. That's what I call it at least. I like that it's that it's not real but it could be real given certain known knowns of theorizing physics of today cosmology etc and there's one particular book series that i'm reading now that like just really pushes the ai perspective really really good and i, I can't recall the actual author's name this very moment, but I'm going to pull it up here in a second. Cause his name is Dennis E.

Taylor. Yes. Dennis, you know, I've been, I've been talking to you on Twitter DM. We're going to get you on some podcasts at some point, but he's written a book series called, it's called the Bobaverse book series. But I love this idea because he was a programmer and he's a snowboarder, mountain biker, lives in the Pacific Northwest, retired programmer who now writes plausible sci-fi books really, really well. And I can imagine similar to Amanda, like this is – these are fictitious stories, of course. They're not real. But he could be on a panel with like known physicists, you know, because of how well he writes in this realm. And I'm sure he does some deep knowledge and some deep reading on actual

physics. And I'm sure he's probably taking classes and I have no idea about the guy's knowledge base, nor do I know of Amanda's either, but I imagine that they're coming from the outside in, so to speak. They're not physicists. They write these books with their deep knowledge.

But what they are doing is grasping the physics and explaining it to us. Right. Yeah. Or making it real to us one way or another. Right. Precisely. Yeah. And that's such a cool way to like get access, I would say, to like because otherwise, how would you do it?

Right. Would you just write, you know, Einstein's theory? Would you, you know, would you write the three laws to get into that club so to speak no not necessarily this is like a different vector of attack so to speak to get into that into that sphere into those knowledge bases and access to those people yeah you do have to do the work to understand it yeah to be able to have a conversation with the people who are at the forefront of physics in this case and and i my 14 year old daughter has picked up this book now i handed this book to them and they actually

started reading it and they've actually read like half of it which doesn't happen very often with a paper book well they mostly read fan fiction um And they like the way it makes them think. Very cool. We'll definitely link out to all those books. I don't have any book recommends, but I do want to give a quick recommend that is related to the gamification topic that we just touched on. And a shout out to a certain degree to Quincy Larson and our friends at Free Code Camp. When Quincy was last on the show, he said he wants to gamify education. And they have been working on that for a while.

I'm not sure if you guys saw or not, but they have a learn to code RPG now. I did see that, yeah. Which we will link to on our show notes. It's hours of gameplay. It's very much original art and music. It's super cool. You can play this role playing game while you're learning computer science, quizzes and questions. And so a little bit of a tie-in there i'm not sure if you get a free amazon gift card at the end or not but

i just wanted to mention that because it's a very cool accomplishment as well for him it's been a something he's been working towards for a very long time is they're very much their first try at games with education and definitely relevant to what we have to say today. Jessica, this has been a blast. Anything, any final words? You've already blown our minds in a couple of different ways, but if you have any other words of wisdom before we call it a show, please do share. Oh, I just want to give you a few links. Okay. I recommend my introduction observability course at graceful.dev, which I will link in the show notes. And sign up for a free Honeycomb account because that will improve my OKR.

Honeycomb.io. Awesome. She will get something from that because she's been incentivized. See, what the OKR does is make me think about closing the loop for something I've already created of how do I draw the line back to a call to action. Well played. You win today's game. I'll add that, too. It's been a while since we've talked to Avdi, and I didn't know about this transition from Ruby Tapas to Graceful.dev. He would love to talk to you about that.

That's really cool. And I've been a fan of his for many years, obviously. Always appreciate the knowledge he puts out there, both free and paid. He's amazing. Yeah. And this is super cool that Ruby Tapas has evolved into this. Now, you can put some stuff there, too, and it's more than just Avdi. I'm looking into it, of course, but that's cool.

Yeah, yeah. He's aiming for more creators. Still very, very handpicked. This is not going to be a platform. Yeah, yeah. I mean, it's his platform, but it is not a generic platform. Right, right, right. It's not like a post your thing here, publish it immediately kind of thing.

No. Yeah, exactly. Exactly. Like it says, tasteful software development training with Avdi Grim and friends. Yes. So I have been back channeling with Avdi a little bit over the winter break about his – he's been writing this cool lemonade stand series. I'm sure you're aware of it. Oh, the banana stand.

Lemonade stand. Yeah, the banana stand from Arrested Development. I'm sure you're aware of it. Oh, the banana stand. The banana, lemonade stand. Yeah, the banana stand from Arrested Development. I'm not sure why I said lemonade. Same concept, last month. The money's in the banana stand, though,

not in the lemonade stand. Anyways, been trying to get him on the show, so stay tuned for that. I'm sure we can get Avdi on to talk about both topics. Cool. I'd love to have Avdi back on.

It's been a while. It's been two, you know, actually closing one other loop. The last time I think we talked to him was about pair programming. Oh, wow. I mean, that was forever ago. I think that might have been like in its upcoming new renaissance.

I don't know how many times it's came and gone, but it was in the resurgence the last time pair programming was. It was definitely back in the Ruby Rogues days, which was a long time ago. That was a long time ago. That was a long time ago. Yeah. So cool. Well, Jessica, Hey,

it's always fun catching up with you. My, my favorite thing about you as a, as a closing part is just to the, the sheer willingness to share your wisdom. I love that. Whether it's, it's left field or not,

you somehow find a way to loop it all in. And I love that about you. So I always, I always love having you on the show, put it in public, then maybe make it good later. That's what I love about you though I always love having you on the show. Put it in public, then maybe make it good later. That's what I love about you. I appreciate you coming on the show.

I always learn something new every time you come on the show. So hopefully our audience feels the same. And your shows tend to be high listen. So I think maybe that's what it does too. Our audience loves you. People like it. Thanks for coming back. Appreciate you.

Thank you so much. Have a great afternoon. See you next time. Yes. You're welcome back anytime. For you so much. Have a great afternoon. See you next time. Yes. You're welcome back anytime. For sure. Thanks. That's the show.

Thanks for tuning in. Thanks again to Jessica for coming back and sharing all of her wisdom with us and with you. We really appreciate you, Jessica. If you have any thoughts, any feedback, any desires, any questions, any whatever for Jessica, for me, for Jared, hit us up in the comments. Links are in the show notes. And one of the questions we get all the time from listeners is how can we help? How can we support? And honestly, the best way is to just share our shows with your friends.

If you love the show with Jessica or other shows on the Change Law Network, share them with your friends. That is the best way. Of course, we also have Change Law Plus Plus. That is our membership. You get no ads, you get closer to the middle, and you get to directly support us. That is one way, but honestly, the best way really is just to share our shows with your friends. But if Change Law Plus++ sounds interesting to you, check it out at changelog.com slash plus plus. As you know, bandwidth for ChangeLog is provided by our friends and our partners at Fastly. Check them out. Support them.

Use their awesome edge network. Check them out at fastly.com. And of course, thank you to BreakMessageZlander for making all of our awesome beats. And last but not least, thank you to you for tuning in to our podcasts every single week. We really appreciate you. Thank you. Thank you. That's it for this week. We'll see you again next week. Game on.