May Book Club - Tidy First? by Kent Beck

Transcript

Mandi Walls: Welcome to Page It to The Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve the system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me at LNXCHK on Twitter.

Mandi Walls: Alright folks, welcome back. This is our May Book Club episode of Page to the Limit. This month we’re going to talk about Tidy First? by Kent Beck. There’s a link in the show notes where you can find it in your favorite format. This is recently published, came out last year so you can get it in eBooks. It’s also available on O’Reilly’s learning platform, for folks who have accounts there. My co-host today is Tom. Welcome. Tom, would you like to tell folks a little about yourself?

Tom Hart: Sure, Mandi, so my name’s Tom. I’ve been a senior software developer at PagerDuty for just over two years now. Prior to that I’ve worked in a few different segments, computer security, iot, I’ve worked with database internals before. Very happy to be at PagerDuty, working with a great team here.

Mandi Walls: Awesome, that’s great. You’ll have lots of good insights on the things that are in this book then. So the book that we chose this month, Tidy First?, is by Kent Beck, if that name sounds familiar. Hopefully it does. He is known for a number of different things. He was the creator of Extreme programming, so if you were around back in the day when that was a thing, that was him. He was one of the original signers of the Agile manifesto. He calls it rediscovering, but he’s kind of the modern rediscover instigator of test driven development. So if you’ve had any experience with any of those practices, maybe you’ve heard Kent’s name. He’s written a number of books. This one I think is his 10th book or something like that, but he hasn’t written anything about 15 years. Fortunately, this one is the first of what he says is going to be a series about empirical software design, so looking forward to see what else comes out in the series.

So tidying is the whole purpose of this book and it’s adorable At the same time I’m like, oh, this is really good information set in a very cute kind of name. His first sort of explanation of tidying is like tidying are a subset of refactorings. They’re the cute fuzzy little refactorings that nobody could possibly hate on.

Tom Hart: That’s a very domain specific statement he made there too, but I think so.

Mandi Walls: Yeah, right. I’m like, I’m not sure I’ve met a set of software engineers who can’t hate on absolutely everything for some reason.

Tom Hart: I mean this is true, but I was thinking even in terms of for different domains, you’re subject to different constraints that can make these sorts of tidings either very easy to do or very difficult. I haven’t done mobile app development, but I know that for iOS there’s something like a two week period where apple’s got to approve your builds and that pretty reasonably makes a lot of mobile developers a lot more risk sensitive than you would be in backend or fronted web. Anything where your code’s deployed on a server and if something goes wrong provided you are watching your dashboards or whatever metrics right after you push, you can just go, oh, revert and where it’s very easy to go whatever is in your main branches, what’s running in production. But yeah, you’re subject to different risk tolerances in different domains.

Mandi Walls: Well, yeah, I think anything that’s edge compute or is with the customer, the actual device, which as many releases as you want to man, but they’re not going to download all that stuff.

Tom Hart: Yeah, IOT is difficult. You can on the server side be releasing updates frequently. I mean to be clear, I haven’t worked on the firmware for any IoT device, but depending on what your business model is, you could have to support client software that’s installed on a device that was sitting on store shelves for a period of years before being turned on for the first time. So you’re always stuck with the I must at all costs support if a five-year-old client connected to me right now, and that can be difficult if that’s a long enough time that say there’s no overlapping list of ciphers between what’s considered safe now versus what was available when the client came out or anything like that.

Mandi Walls: Yeah, lots of stuff in there.

Tom Hart: Yeah, there’s a different set of little constraints like that that I’ve seen in every industry. I’ve done software and so his claim, these are changes that no one could possibly hate on and maybe changes. No one in the domains you are familiar with could hit on.

Mandi Walls: For the folks out there who are working at a domain where this kind of stuff works, the book itself is divided into three pieces. The first part is the actual tidyings that he kind of goes into and classifies. The book is kind of set up interesting, and they’re each an individual chapter, so there’s 16 or 17 of them. Then it’s really just a page or two at a time of these little vignettes really about things that you can change and he’s talking about specifically changing the structure of the code versus changing any of its behavior. And then the second part goes into managing that and the third part gets into theory and there’s a little side quest into the time cost of money and some other things that we’ll get into later.

Tom Hart: That side quest was interesting. Yeah, yeah.

Mandi Walls: Some interesting stuff in part three, but yeah, in part one, all these little individual tidyings that he’s classified for us, they’re kind of all over the place. Some of them are pretty obvious like dead code. Yeah, man, delete that stuff. You’ve got it all saved in your version control, so it’s there for posterity.

Tom Hart: It’s one of those things that it feels bad, but it’s more often the correct thing to do than not. How many times has someone gone through code going, I’ve got to update these call sites or take these cases into effect and then you spend hours or days looking at a case that’s actually dead code, it’s not called anywhere, but then you’re putting all this effort into making sure it’s not called anywhere. Maybe you’re even adding new metrics and monitoring them for months to make sure this code never gets called, et cetera, et cetera. At the flip side, this is one case where I have seen a refactoring like that go awry product I worked in, it was written in Java, the main engine, but there was also a scripting language embedded in it. Yeah, actually I’ve seen that twice. One in which you could call from JavaScript another from another language that I’m not going to be specific. I don’t want to anonymize products I’ve worked on, but someone went with one of them deleting a bunch of code because his IDA showed it wasn’t called from anywhere, but it wasn’t following into the scripting language because that scripting language is presumably using reflection shenanigans in order to call it and make it look like a regular call to the coder in that scripting language, but then that broke something.

Mandi Walls: Oh yeah, because you’re not,

Tom Hart: Yeah, this is where it’s like I said, I mean there’ve been multiple products at different companies that have some sort of scripting language calling in that have worked on, so I agree, eliminate dead code, but be sure that you or your tool knows what’s actually dead code. I guess it’s almost like with AI now you’re still responsible for if you act on the answers and AI gives you, if you’ve got an IDE doing dead code elimination, yes, you’re still responsible for the result of your dead code elimination, even if it was called through reflection or you’ve got a dynamic language and something’s constructing a string dynamically that becomes the name of a function call or something. Something something.

Mandi Walls: Yeah.

Tom Hart: Also, I can hardly think of any case in which doing that would be a good idea, but

Mandi Walls: Stranger things have happened, right?

Tom Hart: Yes. I’ve been a decade and a half something like that working as a professional developer. I’ve been in different industries. I’ve seen slightly different weird things happen at every company I’ve been at. I guess part of this tidy first is minimize those strange things because they slow you down, but at the same time, yeah, you’ve got to take the constraints you are in your industry into account.

Mandi Walls: Yep, definitely. So some of the other pieces in the first part are I thought were really just about making the code more readable to humans. There’s a lot of stuff in here about, it feels like CS 1 0 1 almost put your variables together and how you declare things and making things super readable and it’s

Tom Hart: Almost linting plus plus. Yeah, and to that extent, I agree with him a lot because I think 10 years ago how much of code reviews was typically spent on people arguing about this would look better, this would better this

Mandi Walls: Tabs versus spaces.

Tom Hart: I still say, I don’t care if you use tabs versus spaces, but if you mix tabs versus spaces, then that’s absolutely horrible.

Mandi Walls: Totally.

Tom Hart: That you’ve got. It’s readable on my computer

Mandi Walls: Of course,

Tom Hart: But once linter has became so ubiquitous, code reviews became quicker because you’re never spending any time on this would look better like this. You can just tell someone, okay, if you can change the linter so that that’s enforced, go ahead, I’ll do it. Otherwise stop wasting my time with this, and we all agreed, okay, that’s a good trade off. And then code reviews became cheaper,

Mandi Walls: Especially when you can give the linter configuration set up for your specific team and your particular set of styles, especially for Ruby has a really good one that will fit together. That way you can just kind of define the things you care about and ignore the other rules that you don’t, and then everybody puts their code through the same and then you can’t argue about that part.

Tom Hart: And a lot of the newer languages that come out, they’ll just ship with a linter. Yeah,

Mandi Walls: It’s just in there.

Tom Hart: Yeah, like for Java, sorry, I’m Canadian. I say Java, not Java, Java. They back the linter onto it and that was good with go there was just go format.

Mandi Walls: It’s just there

Tom Hart: In the language from day one and that’s a good thing. If I were making new language now, I would consider ship with a linter, just one of those minimum viable product things.

Mandi Walls: Yeah, absolutely. Even Terraform has its fmt.

Tom Hart: Yeah, Terraform format. Exactly.

Mandi Walls: Yeah, so there’s a whole bunch of chapters on that stuff as far as explaining variables, explaining content constants, chunking your statements together, all those kinds of formatting things that are, it’s easy to see how that stuff gets out of hand when you have a lot of cooks in the kitchen. You have a lot of folks that touch code, especially over its entire lifetime that things kind of get out of hand or somebody goes rushed and they try to jam something in there and as long as it doesn’t a break, it just lives in there in a weird place and then you go back and you find it later and you’re finding this weird artifact from the past in your little archeological dig.

It goes into a whole bunch of that kind of stuff. And then when we get into the second part of the book is called managing and this is where he gets into, there was a lot of theory about code review in here and organizing your pull requests and that kind of thing. That was kind of interesting from a standpoint of he’s been at this a very long time and from that perspective just kind of seeing his thought process for putting changes together and organizing things and when do you actually do these kinds of changes and behavioral versus structural changes and all that kind of stuff. From my standpoint, it was kind of interesting just to see how he was thinking about that.

Tom Hart: Yeah, I know I’ve been guilty of making poll requests where there’s 30 lines changed and I put in a comment and I say this one line is the functional change, and they certainly reviewed little requests like that and yeah, it slows the developer down to break that up. No argument there. Often if you’ve been hacking at something, particularly if it’s an annoying bug, you could be at the point where you just want to push your changes up to GitHub and then say they’re away from me. But that’s thinking you’ve got a good point about that. One of the things that I’ve had to coach junior developers about is this trap. You can get in that. I remember getting into this where since you don’t have responsibility other than coding, reviewing testing at the start of your career in terms of you’re not in a bunch of design meetings constantly, typically it’s very easy to fall into a trap of, especially if you’re trying to work quickly prove yourself, you get something done, you put it in ready for review, ready for testing, whatever your workflow is, you move on to another one and you end up with three or four things queued up waiting on someone else, and then one by one someone finds an issue with each of them and they’re knocked back and then you’re thrashing between three different tasks because you got so ahead of yourself.

And what that demonstrates is the importance for you, the developer of making your code easy to review and easy to test, and as much as it’s hard to break up those functional versus behavioral changes, again, I’ll say not all the time, it depends on the constraints you’re under, but assuming you are pushing code that lives on a server, whether it’s downloaded into a client’s browser or not, but either way is easy to just ship is to change. It makes a lot of sense to make those cleanup prs different from the behavior change prs. Yeah. I’ve worked on code where the ethos was optimized for your individual change being as small as possible. Okay. Think of it as this is not your code, it’s the customer’s code. You’re touching it and trying to make as small change as possible and that led over time to messy code when you keep doing it that way.

But at the same time, depending on how quickly you can deploy what the cost of retesting is, et cetera, et cetera, et cetera, that might be a better trade off than it sounds like it is. And it gets into some of these things a bit in parts two and three of the book in terms of sometimes doing a refactoring or tidying just does not make economic sense and that was a very important thing for him to say because you almost get this sort of craft person sense as a software developer where I want to change this so that it is good, which would be fine if you were doing this for a hobby, but we’re being paid a lot of money to write software that makes money, so to a certain extent do things in a way that doesn’t make everyone who looks at it absolutely hate it. It’s fine. He says You are worth a little bit of care that at the same time you can’t be working just on refactoring for a week straight just to make things neat and tidy. Yeah, absolutely. And yeah, I did like the discussion of when to do it when not to, and the one thing that I found really interesting was how this idea of doing tidying, this has corollaries for policy. I mean, like I said, in some companies it’s going to be politically hard to make non-functional changes.

Mandi Walls: Yeah, absolutely.

Tom Hart: And also in code that does stuff like effects of billing for example, then you can have a more strict change management process around it because what are the consequences If you ship something that’s wrong and a customer gets overbilled for one day or something, sure you can revert it, but can you retroactively calculate the correct bill? Are they going to believe you at that point? What’s the reputational harm to your company? Et cetera, et cetera. But that goes right back to I guess my thesis of today, which is this makes sense provided your satisfying constraints of your particular domain.

Mandi Walls: Yeah, absolutely.

Tom Hart: I’m realizing I’m sounding like a broken record I guess. No, it’s totally cool. Maybe it’s apparent.

Mandi Walls: Well, I think there’s some lenses that are maybe missing in this book, and for one, it’s only 125 pages, so it’s very short and I felt like

Tom Hart: It’s even quicker than that because so many of them are blank pages,

Mandi Walls: So many of them are just one page and they’re blank on the other side or whatever. It’s just one or two sentences, but it’s, it’s very, very short from that perspective. So getting through it, if you’re looking for a book like this, it’s going to be super easy if you’re just looking for some tips. The couple things that I felt were maybe missing were, and what want to ask you about too, you mentioned about your practices as you’re a newbie software developer, your first four or five years as a software developer is you’re just kind of learning how to actually do it in a non-academic standpoint, all that. I think the lens that’s missing for this particular book is like, who is this for in their career path? It feels like it’s very much for mid career to senior sort of folks who are really thinking about in a very methodical way the design of the software that they’re putting together and not maybe as much for the newbies that haven’t maybe seen enough to really get a feel for how many of the practices that they’re currently sort of moving themselves off of are actually going to harm them or be detrimental.

Tom Hart: Also not have the confidence to say, absolutely this should be clearer.

Mandi Walls: Yeah,

Tom Hart: I know I’ve had juniors who I work with who have been like, oh, how can I review Tom’s code? And then I think back, I remember in my first job someone who was very senior, he’d previously been a manager, then went back to a peer technology role. He said, I really need a peer review here. I remember saying, I don’t know if I can give you a peer review, maybe a petty minion review!

Mandi Walls: Depending on your definition of peer. Yes, yeah,

Tom Hart: Peer review for some definition of peer. But what I remind people of which is something I learned when I was junior, two things. If you review the code, that’s one way of learning the code. And one thing that’s important is even if you are the senior developer who’s been at the same company for 10 years and knows everything, where all the skeletons and the clause are, et cetera, et cetera, you’ve got to write code that can be modified by someone who’s a new developer or a new hire or anything like that. And if your code is gibberish to anyone who doesn’t have all the context that you’ve got, then you need to fix that. And that’s a perspective that the juniors can always bring. You could say, hi Tom, hi other senior developer. I’m the junior dev on your team and I cannot read this code. I’m not going to be able to fix it. Can you make it more clear? And I’ll tell you, I am highly motivated to make it more clear because otherwise I’m the only one who can work with it and I do not want that.

Mandi Walls: Absolutely. And there’s one quote in this book, and at one point I just was getting to the point where I was just highlighting tasty little bits and he says at one point, software design is an exercise in humor and relationships, and that’s super important. I still feel like we get too many folks in the industry who feel like software development is a solitary practice and you’re just going to be you and your computer and your keyboard and you’re going to be cowboying away, and that’s not how you build software Now for the scale that we need it to be, in most cases you can get away with building some stuff as an individual developer, but for a lot of the stuff that’s actually going to create value, you’re going to get to a point where you need team and team and team and lots of other folks that are there to help you. And that whole part of the discussion of your relationship with your peers for your code review, making the code more readable, not just for yourself in the future, but for anybody who has to touch it and decoupling some of the weird clever things that people tend to do because they saw a post somewhere or learned about a new function and anybody uses tertiary functions. I’m like, did you really need to do that?

Tom Hart: Yeah, I’ve read code that I’ve written a year or two ago and I go, I know what I was thinking. I was trying to be too clever by half, and I’ve also maintained code where I was very certain that the original author’s motivation was to prove how smart they were. And I’ll tell you, everyone else hated working with that code.

Mandi Walls: Absolutely. And we’ve all been there, right? I feel like everybody who’s had that, you open the file and you’re just like, what garbage is this? Oh my God, just what the heck man? So yeah,

Tom Hart: Of course what garbage is this could be that’s the garbage that got the company through a six round of seed funding and you’ll not be here if no one has written out.

Mandi Walls: The cog in the wheel, the money machine right there, man. And that just makes me more afraid to touch that sucker.

Tom Hart: Now it’s your job to make it better now that this company’s growing up a bit.

Mandi Walls: Absolutely. There’s a lot of that stuff out there.

Tom Hart: All comes down to the constraints you’re under again.

Mandi Walls: Yep, definitely. So the third part of this book was actually, I kept reading and I’m just kind of laughing, it’s theory, but there’s also a lot of other stuff in here. There’s a lot of chatter about the time value of money actually getting into doing the economics of when you take the time to make some of these changes and

Tom Hart: Funny because it’s theory, but it’s not quantified theory. Yes, it’s hand wavy theory.

Mandi Walls: It’s a little bit hand wavy. Chapter 25 is called A dollar today is greater than a dollar tomorrow and then kind of goes off into options trading and stuff like that. It’s very strange.

Tom Hart: I actually found that except for the fact that it was not quantifiable, which means it’s the Beck hypothesis as opposed to the Beck theory. It made a lot of sense because, so rolling back for people who haven’t read the book is saying that in economic terms, what you’re doing when you refactor the code, you’re making it easier to change. You are lowering the cost of making future changes. That is in economic terms like buying commodity options, you’re making the cost of doing a bunch of future things cheaper so that you’ve got more uncertainty. You don’t know what features will be ahead in the market. Doing each of those possible things is cheaper so that the more uncertainty there is in your domain, the more you should be biased in favor of clean code. That’s a very cool argument I thought even though it’s not quantified at all, and that’s really almost the inverse of the tech debt metaphor, and I know that metaphor has come under a lot of criticism lately. I’m sorry, I’m rephrasing my sentences halfway through because I’m not rehearsed, but the idea of tech debt is I can do something to get this out quicker with the consequence that every future change until I clean this coat up is going to be more expensive heart to grok. I think a lot of that is we as developers do a terrible job explaining that’s what I mean by tech debt and aren’t consistent about making sure that’s what we actually mean and not meaning tech debt as ew ugly. I don’t want to see it. But I think that options metaphor is it’s something that I’d be comfortable talking to a product manager. Maybe I’ve been spoiled because I’ve been working with good ones here, but I’m saying, look, there’s no immediate customer value to doing this, but it means that whatever it turns out we need to do in the future around this, it’s cheaper to do that. I know I’ve seen, I’m putting on my don’t be specific filter. I know I’ve seen cases where we put one thing out, we’ve got an idea of what the follow ons are, but then once it’s in customer’s hands, there’s a bunch of other things that are more important or the things that we’ve thought we should optimize for are not what we should optimize for. I’ve seen the ladder at multiple jobs. Absolutely. And when it turns out that there’s some deep architectural thing where you optimized for something that ends up being the equivalent of you can make mud pies really well and the customer says, well, I don’t want to make mud pies. I don’t care how quickly you can be able to make mud pies, then that becomes a difficult talk. Yeah, I don’t know. I think that’s where people sort of miss the point of agile when agile becomes this magical pixie dust that sprinkle over everything because know that’s everything. Every company I’ve worked for, even when the development practices were waterfall, even when they were waterfall for a good reason said agile, agile. And I’ve done enough things that I just want to say that word means something. It means you’re optimizing for a feedback cycle. Do you actually have feedback cycle? Are you doing short cycles? Is it possible to have a feedback cycle with where you are? One place I’ve seen you can’t be as agile as you’d like to be is if you are doing prototypes that involve a mobile app because of the long upgrade cycles, then you can be in beta and have trouble changing your APIs because you can’t break this mobile app that’s out. But you want to be very adaptable there. And something that I think we don’t take into account enough in this industry is the extent to which an API is part of your products ui. Definitely, yeah. It’s like I think about all the rigor that I see people who are good UI developers or UX developers do around what gooey should be, and I go, that’s awesome. And I wish we had that level of practice for how to make a good API. Yes.

Mandi Walls: Oh, absolutely.

Tom Hart: Sorry, that was 100% a hobby horse tangent there.

Mandi Walls: No, it’s totally fine. It gets into the last little bit where he talks about coupling and cohesion and things like that and it actually talks about you’ve got new versions of some code and old versions of other code and decoupling some of these things. And to the extent where that kind of stuff comes in, if you’ve taken, especially if you’ve taken object oriented programming classes where they talk a lot more about that stuff, but actually pulling those pieces apart and allowing them to flex independently. I think as we’ve moved into microservices architectures, I think people are maybe feeling better about how they do that kind of stuff. I think it’s easier to be very messy with coupling if you’re in a monolith and you can just jam stuff in together and it sits together in the monolith anyhow.

Tom Hart: Don’t even notice what domains are coupled because it’s exactly,

Mandi Walls: It’s just there.

Tom Hart: Easy. Yeah, you could have hibernate or whatever be obstructing your object relationships for you because they’re done data layer.

Mandi Walls: Yeah, nobody even needs to notice. So there’s some pretty good discussion I thought in that sort of a modern equivalent of decoupling that sort of updates what the thinking on coupling was maybe 15 years ago, which I thought was pretty interesting. So that was worth it in the end there. So yeah, overall I learned some stuff in here. It’s been a long time since I’ve really sat down and thought about software design as a practice, but I’m definitely looking forward to see what else he puts out in this series if it ends up being the whole six or seven books that he’s threatening us with on it. Well, we’ll see if that comes across.

Tom Hart: I mean thickness, the books something like half centimeter.

Mandi Walls: Yeah, it’s itty bitty.

Tom Hart: I dunno if that’s like a quarter inch or whatever in US measures, but when I saw how thin it was, I kind of had low expectations and then I saw how quickly I got through it and what the density of idea to time was. I felt like, okay, if you’re working in this industry, your time is probably more valuable than the 40 or 50 bucks that this book cost. Think of it as like a magazine article plus plus.

Mandi Walls: Yes, that’s a good way to do it.

Tom Hart: It’s got a few practices. You can quickly put in some caveats around them and some ways to phrase this in terms of thinking of do something where you go, ah, that’s a little messy If you are doing it taking on the tech debt, you are trying to get information quicker or make money quicker and then move the now, make it nice later. Okay, that makes sense. If you are refactoring, you’re not just doing it because it feels good, you are reducing the cost of future changes. That makes sense. And I thought that was a good way to think about it in economic terms in order to make preferences and it’s important to have that trust between different stakeholders breaking it down. That makes sense. Especially sometimes you’ll want to do a hack to get it out quicker, but that’s a high trust statement that has the corollary that a software developer, you can do that and the business will let you take the amount of time that you would’ve taken upfront to clean it up after. And I know I’ve worked in places where there isn’t that trust and people just make it as nice as you can because we’ll never be able to clean it up later.

Mandi Walls: Yeah, absolutely.

Tom Hart: And comes down to people comes down to trust and understanding maybe this cashflow and options metaphor will succeed better than the tech debt metaphor because that’s just become okay, the developers want to do something that’s not going to make money.

Mandi Walls: Yeah, yeah, absolutely. I think the point you made earlier about talking to the product managers about it too, it’s like that’s an important discussion for anybody to have. I think it gets overlooked a lot, especially just in general practice as far as discussions that people are having. This isn’t necessarily just a topic for your software developers. It actually could be very helpful for people who are product managers to think about, yes, we want this flexibility in the future. We need to be able to implement these future features. We cannot do that if we’ve constrained ourselves to this legacy scaffolding in a bad way.

Tom Hart: And that’s where you’re working with a good product manager when they’re on board with something where part of the reason we’re doing this will let us do X, Y, Z in the future. It’s like, okay, they’re having the discussions with the technical stakeholders if they’re not using that commodities options, analogies saying we’re doing this so that we can do something else that’s implicitly just like a rephrasing of the same kind of thinking we’re buying the option to do future features.

Mandi Walls: So super interesting. So yeah, very good. Overall, I think I would recommend this for folks, especially career software developers and even I think mid-career product managers. I think they would get a bit out of this. The second and third sections, maybe not so much little code, but yeah.

Tom Hart: I wouldn’t say it’s one of the top two or three software books I’ve read. I definitely wouldn’t say it’s one of the bottom ones. I dunno, it’s a B+ with a low investment.

Mandi Walls: Yeah, that’s true. Absolutely. It doesn’t take long. It’s right in there if you just want to skip all the stuff in the first part because you’ve probably been through most of those practices before. I’d say read the third part, the option stuff I’m talking about optionality and those things to get a grip on that metaphor and I’ll be able to use that with your folks too. Awesome. Well thank you so much joining me today on this discussion. It was a super interesting little book. So we’ll see what else Kent has for us in the future with the rest of these as they come out.

Tom Hart: Yeah, I would definitely read the next one in the series after this. I know it’s going to give me some value with a low investment. Awesome. Yes, and as a working developer and a parent, that’s a strong value proposition for you. That’s important. Thank you for having me here, Mandi.

Mandi Walls: Absolutely. Alright, so we’ll be back in a couple of weeks with another episode and we’ll have another book club in June if you’d like to be a guest or if you have a book recommendation, you can let us know at community-team@pagerduty.com and we’ll be scheduling episodes over the summer. So we’ll be right back at you in a couple of weeks. So in the meantime, we’ll wish everybody an uneventful day

Mandi Walls: That does it for another installment of Pager to the Limit. We’d like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pager to the limit.com and you can reach us on Twitter at page it to the limit using the number two. Thank you so much for joining us and remember, uneventful days are beautiful days.