The Shifting Role of Software Engineering - Frictionless by Nicole Forsgren and Abi Noda

Carter Morgan (00:00)

if you are...

an engineering leader tasked with implementing DevEx initiatives at a ⁓ scale up, right? Then great, like this is the book for you.

Nathan Toups (00:08)

at a scale up, right?

Carter Morgan (00:21)

Hey there, welcome to Book Overflows, podcast for software engineers by software engineers where every week we read one of the best technical books in the world in an effort to improve our craft. I'm Carter Morgan. I'm joined here as always by my cohost, Nathan Toops. How you doing, Nathan?

Nathan Toups (00:32)

Hey everybody.

Carter Morgan (00:34)

Well, thanks for tuning in everyone. Like, comment, subscribe, leave a five star review, all that good stuff. You can join our discord. It's in the comments. You can also book time with us on Leland in the comments. And just a note about advertising last week. We mentioned we're starting to do advertisements on our audio platforms via Spotify. We had gotten some feedback that there were some weird ads like gambling, which we do not want to make money off of. And Nathan, you found the setting to turn that off, right?

Nathan Toups (00:58)

Yeah, I turned off the

stuff that we knew that we did not want, specifically gambling, pharmaceuticals, stuff like that. This is not even topical for our audience.

Carter Morgan (01:05)

Right, right. I know,

right. I don't know if many of you are needing pharmaceuticals recommended to you, but I think our median age is like 35. So we're all probably pretty good here. Anyhow, so we got that sorted out. Let us know if you hear anything weird. And we want the advertisements to be roughly in line with our values. And yeah, with that, let's talk about the book today, Frictionless.

We read the first half last week, read in the second half this week. Let me give you the author introduction and the book introduction. This written by Nicole Forsgren and Abhi Noda. Nicole Forsgren, she is an expert in DevEx, DevOps, and decision making and is the lead author of the Shingo Publication Award winning book, Accelerate, the Science of Lean Software and DevOps. Her work on technical practices and development has been published in industry and academic journals and is used to guide organizational transformations around the world. And we have Abhi Noda. is the co-founder and CEO of DevEx, or DX, sorry.

where he leads the company's strategic direction in R &D efforts. His work focuses on helping leaders measure and improve developer experience. Before joining DX, Noda held engineering leadership roles at several companies and was the founder and CEO of Pole Panda, which was acquired by GitHub in 2019. For the book introduction, have AI can generate code in minutes, so why does shipping software still take forever? The answer is friction. Invisible barriers that turn quick wins into endless delays.

Let your competitors ship daily updates, your developers burn out fighting broken tools instead of solving real problems. In frictionless, developers experience experts. Nicole Forsgren and Avi Noder reveal why eliminating friction isn't just about developer happiness. It's about business survival. Drawing from research with hundreds of software teams, they provide a complete seven-step methodology to identify bottlenecks, measure impact, and systematically remove barriers at slow innovation. Whether your teams use AI coding assistance or established workflows, this book shows you

how to unlock your engineering organization's full potential. You'll discover how companies like LinkedIn tackle developer friction and transform their business as a result. Okay, so we finished the book. We're at the second half this week. Nathan, give me your thoughts on it.

Nathan Toups (03:10)

So I don't know if this is the fault of the book or if this is where my headspace is, but I just wasn't feeling the second half of this book. Like was ready for it to be finished. it pains me to say this because like I really respect the two authors. I think you had mentioned last week that it felt like it was it could have been shorter. I was like, maybe I'm like fully in that camp now. Like I feel like a good editor could have probably gotten this down to.

Carter Morgan (03:30)

Yeah.

Nathan Toups (03:39)

I don't know, 175 pages. It would have been a page turner. It would have been, you know, because there's a lot of wisdom in here. really enjoyed, like I didn't look at anything and go, oh, this is wrong, that's wrong. Like everything in this book's like really good. It's just, I don't know, I don't know. But it also, I've got a lot of stuff going on with work, which is good, but it just didn't, the vibe was off, I don't know.

Carter Morgan (03:42)

Right, right.

100%.

Yeah, you know, I think about one of our favorite books, A Philosophy of Software Design, and it's short. It's like 120, 130 pages. And I think that book could have all the exact same content and be two and a half times as long, and it wouldn't be nearly as well received by the general software engineering community. I think there's a little bit of that going on here, because I agree with you. The book, all the ideas in it make a lot of sense to me. And I think another...

Nathan Toups (04:22)

Great.

Carter Morgan (04:35)

I never want to criticize books based on like this book was written for an audience that I'm not part of ⁓ because sometimes books are just written for other people. But I will say that like when you write a software engineering book, you want to capture a decent amount of people that could be interested in your book. you know, I'm a software engineer, like I'm a lead software engineer at a startup. Like there's there's a lot of kind of within the various Venn diagrams of

the software engineering community, like I have a lot of overlap with those areas, right? And so sometimes when I come across a book where I'm like, huh, this really isn't resonating with me. like, well then who is it resonating with? Like I always joke that like, I love Taco Bell and I love in particular Baja Blast, but I don't drink, know, the Mountain Dew Baja Blast, right? I don't drink the sugared version. I drink the diet version, but I like just a little bit.

of the sugared version in it. So I usually put like a splash in it, right? And then I also wish I could drink it at night, but it's caffeinated and it'll keep me up, right? And so ⁓ I'm always saying like, want like a 15 calorie caffeine-free Baja blast. And I'm like, I'm sure they could make that. And I would be the only person in the world who would buy it regularly, right? There's a little bit of that going on with this book where it's like, hey, if you are...

Nathan Toups (05:52)

Wow.

Carter Morgan (06:03)

an engineering leader tasked with implementing DevEx initiatives at a ⁓ scale up, right? Then great, like this is the book for you. For everyone

Nathan Toups (06:09)

at a scale up, right?

Carter Morgan (06:17)

yeah, there's just, there's so much in this book about like the process of leading these initiatives. When I was hoping this would be a little more about ⁓ the actual DevEx experience and

improvements that they've seen happen at other teams that were really transformative, right?

Nathan Toups (06:37)

That's really good feedback, I would say there's these little sections in the book that had these little gray boxes, and it was little case studies. And I loved those, but they were like, those parts were too short. they didn't have, and again, they didn't really show the, they had the same problem that the DevOps handbook had, which is they were always the success stories. There wasn't this, I really would love to see, because they would even have chapters that were like, ⁓ here's what,

Carter Morgan (06:46)

Yeah, yeah.

Exactly, right.

Right, right.

Nathan Toups (07:06)

can happen if you don't get the right buy-in or you're actually building the wrong product, right? the things I love in this book is they do kind of, they make DevOps folks think about a product that they're building and that the product and the customer is the other engineers in the company. And I think it's a beautiful forward-thinking way of looking at this. But I wish that there was more cautionary tales. And maybe it's just because companies don't want to admit when they really screwed up.

I would love to know if Dropbox had three false starts, getting a DevEx initiative going, and the third strategy is what actually worked, and here's why the first two failed. I would be so happy with just that.

Carter Morgan (07:40)

Right, right.

And especially because in like, and I mentioned this last week and I think having read the whole book now, I feel a little more confident in saying this, that like, they wrote this book about DevEx kind of before AI and then AI came along and then they kind of, they latched onto something really true, which is, and I believe this, which is that companies with good developer experience operations are going to succeed.

Like it has become even more leverage in the age of AI because, you know, good developer experience leads to fast iteration cycles and, you know, kind of a good gatekeeping around making bad changes and all of that. If you're unleashing autonomous agents on your code base is super valuable today. ⁓ And so I thought like, great, like a book that's tackling that. And then it just kind of always came across as bit more of an afterthought ⁓ because I'm of the belief.

Nathan Toups (08:19)

Yes.

Carter Morgan (08:46)

that engineers are going software engineering as a profession is going to look more and more like platform engineering has in the past, right? Or I think companies are going to become more and more comfortable with non-technical people creating pull requests on the code base, which I actually think is great because I, you know, I hate when I get a ticket that's like adjust this copy, right?

or fix this padding or the color is wrong. I'm just like, do you know how much you pay me? Like you're paying me to fix that. And so I think if you can kind of farm out some of that lower level work to designers and product managers, like that's fantastic. But then what becomes the role of software engineers? It's how do you construct a code base where all those proper guard rails are in place and where it's easy to contribute to. And so I think we're all going to be kind of like enabled in engineers to some degree.

someone needs to write that book about what engineering organizations might look like. I thought that would be this book. And it just, it wasn't quite, it was much more focused on like, how do I as a VP get buy in and implement and conduct DevEx improvement initiatives.

Nathan Toups (09:59)

Great. Yeah, super astute observations.

Carter Morgan (10:01)

Well.

Well, we got a lot of stuff to talk about today. We're gonna talk about all of it. So we're gonna take a quick break and we'll be right back.

All right, let's get into this. I want to start off with something I just found funny. Like, and again, like this book will kind of like throw a bone to be like, and if you're at a startup, this is good too. But then it's a little like, ⁓ this, you can tell this book is just clearly written for like a scale up or a thing or something like that because

Chapter 36 is like share your progress right and it's like how often should you share your progress? I just thought it was funny. I just highlighted this put lol executive stakeholders twice yearly and I was just like I was like so the most executive stakeholder is John our CEO who sits two desks down from me and I was just cracking up this idea that like twice a year I'd let John know how things are going right?

Nathan Toups (10:42)

Great.

Yeah.

we will say, like the whole Forrest Grendan works with the biggest, successful tech companies, a bunch of Fortune 500 companies. Abhi is a CEO of DX, which of course got acquired by Atlassian, and their target audience are literally these, you know, scale ups to the big companies. And so, you know, I get it. He has a book. He's

Carter Morgan (11:02)

Right, right.

Right, right.

Nathan Toups (11:20)

gonna do the speaking circuit, he's gonna talk about this stuff, visit the core audience of potential customers for DX. And despite all of that, there's still so many good nuggets of wisdom. And I wish the same thing, and maybe it's just because the audience isn't there, maybe there's the reason that there's no books. we read the web scalability for startups book.

Carter Morgan (11:32)

Right, right.

Yeah, by Arturo

Edgman.

Nathan Toups (11:47)

Yes, and I would love a DX for startups, there would be a really, yeah, maybe this will be the first book overflow book that we write.

Carter Morgan (11:51)

Yeah, yeah, that's a good idea.

Yeah.

Yeah, like, because it is just so critical. It's so critical these days, right? but

Nathan Toups (12:05)

Yeah. And

they make this fantastic argument, and they do. Again, they throw a bone to these things, and they're like, hey, these patterns and these ideas are not just for the bigger companies, because the companies that reduce friction are going to run circles around the companies that don't. And I think there's this overarching theme, which is like, if your build pipeline takes a minute, and in that one minute, you're also running all your test suite, and you're doing all these other things, you have the super optimized thing.

Carter Morgan (12:22)

Right.

Nathan Toups (12:34)

The friction is so low for anyone to contribute and get direct feedback that wouldn't you want to live in that world? And you don't wait until you have 300 engineers to do that. This is something that's actually least painful to do if you just do it up front. If you do it up front when you have five engineers and you are like pedantic about a build pipeline that you all understand, that it's not flaky, that works the way it should, right? It's not wasted effort. And I think that this is a powerful idea in here that isn't as emphasized as I wish it was, right?

Carter Morgan (12:44)

Right, right.

Yes.

Yeah. And I think, I don't know, like, especially in an AI age, I think a lot of those kind of like, DevEx improvements, like, I just know like the kind of classic startup thing is like, well, we can't worry about DevEx because we just got to ship and do, you know, and, and we're building the product out and like, there's truth to that, but it's also like a lot of these kinds of basic things, especially at a startup level, don't take that long.

to figure out, right? And like, I just remember like when I joined my startup and my first day there, someone said like, hey, is the site down? Someone was like, yeah, I'm just doing a deploy. I'm like, what the freak is going on? Right? And then like, and so that was the first thing I was like, we gotta fix that. Like we can't go down every time we deploy. ⁓

Nathan Toups (13:42)

Right.

Exactly. It's the frog in the boiling water piece. And I'll even

bring it back to something that's not brought up in the book, but I think is useful to think about is ⁓ if you're in a Michelin rated restaurant and you've got all these people coming in, your kitchen is going to be super organized. How you do prep, how you source the food, the processes and procedures for getting food out in a timely fashion so that it's presented beautifully and all these things. You can think of this as similar to a mature DevEx org.

Yes, you came to the restaurant to have a delicious meal that's plated in front of you and, you know, meets all your criteria. But the way that you structure the kitchen, the way that the chef engages with all the stuff, that's the dev ex part, right? You make the kitchen as easy as possible to flow as smoothly as possible, deal with these surprises that come in, deal with, you know, mistakes and all this other stuff. That's dev ex. Those rules still apply if you have a food truck, right? If you have a food truck and there's two people,

Carter Morgan (14:47)

Right.

Nathan Toups (14:49)

You still need to do meal prep. You still need to lay your kitchen out in a way that's useful. And I will tell you that the food trucks that are super disorganized are going to lose against the food truck that's super organized. You're some taco truck that can't get your act together, and it takes 15 minutes to make two tacos, or you have the taco truck that takes like three minutes to get your tacos. You're going to be much more successful. You'll be able to do all this stuff. And so I.

Carter Morgan (15:05)

Right, right.

Nathan Toups (15:16)

I do think that it's the same sort of idea. like, yeah, even if you're this tiny little idea of a business versus some big thing, all along the way, you have to follow the success with how you structure your work.

Carter Morgan (15:29)

Well, so I want to ask you a question from your experience because you've worked at kind of like series C startups, right? Just you know a little bit a couple hundred engineers. Whereas I've kind of only like I've worked at little like series a startups and I've worked at big tech companies and so Because there's just and again they this book will kind of just throw out like an interesting idea like wait Wait, talk about that a little more right where this idea of almost like peer leadership and like

Nathan Toups (15:36)

Mm-hmm.

Right?

Carter Morgan (15:58)

starting out on your own team because it's a little like, if you're at a really small place, like there's no one to talk to about DevEx. Like you have a team, there's maybe two or three teams, like talk to the two or three other engineers who matter and kind of get your act together and figure this stuff out. ⁓ And then at the really big companies, it's a little like, you can't even begin if you're like a kind of like a lead software engineer because you're often using these.

giant, like, for example, if you're like Amazon, like they have their whole kind of proprietary build pipelines, right? And so it's hard to like, as a team, be like, we're going to make our process better because you're often relying on like these big, there's like these big infrastructure teams who kind of control that whole process, right? But what about the middle ground where you're using like standard tooling, you're on like GitHub actions, right? But it is a little bigger than

Nathan Toups (16:47)

Yeah.

Carter Morgan (16:54)

your own team and so there isn't there is a need to enable other teams to move faster. I mean, what does DevEx look like at that scale?

Nathan Toups (17:03)

Yeah,

so this has been interesting because I actually am in the middle of, I feel very lucky. I finally have gotten enough critical mass for Rojo Roboto. And I've got some long-term work where we're working on some deep platform engineering processes at a company that's ready to take this to the next level. And then I also am working with some early stage startups that they've already kind of found a tangled mess, right? There's some tangled messes where they're trying to untangle it. They're realizing that there's this

Carter Morgan (17:26)

Right.

Nathan Toups (17:31)

I guess we talked about in fundamental software architecture, it's the last responsible moment. We maybe have exceeded the last responsible moment. It's maybe a little bit irresponsible at this point, but they're correcting course. I think it's sort of like, how do you teach a kid math? There's a maturity level, right? So at one level, you need to get them to get the fundamentals of adding and subtracting and multiplying and dividing. A perfect example of this is my daughter is 10.

Carter Morgan (17:39)

Yeah.

Nathan Toups (17:58)

And she had a bunch of homework that we took during a long break. The summer is the winter in Costa Rica. So they had a long break, and they had some stuff. And I was looking at this. I'm like, this is multivariable algebra, where you're having to simplify things in terms of one variable and get a number, and then you plug it back in. I was like, why are they teaching this to a 10-year-old? This is kind of insane. And I'm looking at it. And so I would sit down, and I'm just like, hey, I'm going have to teach you the fundamentals of algebra.

Carter Morgan (18:03)

Right, right.

Mm-hmm.

Right.

Nathan Toups (18:26)

And of course, she's horrified at first. And then we spend a little bit of

time, and she gets it. And now she can't be stopped. Well, it turns out I was out of line. This was seventh grade math. My daughter's in fifth grade math. And they were just teaching pre-algebra concepts. And there was some shortcuts and context I didn't have on how you can use little blocks and kind of hack your way around it. But I taught her actual algebra. And so I would say that you can prematurely optimize.

Carter Morgan (18:44)

Right, right.

Nathan Toups (18:53)

you know, this wasn't cargo colting. And she was able to, in about a one-month period, learn the fundamentals of algebra. And she's going to be able to take that with her. That's great. Most startups should not do that. And what I mean is that, like, your maturity level is use the hack that kind of gets you kind of there, good enough to get you to the next level. And as long as you're directionally in the right idea, like, OK, I can introduce a couple of concepts of algebra, but we're not doing full-blown.

Carter Morgan (18:59)

It's nice.

Nathan Toups (19:19)

multivariable algebra. not going to get into calculus. We're not going to get into all these other geometry and all these other abstract concepts. And so I think that there's a maturity level piece, which is like, we're doing push-based deploy and pray ⁓ deployments with our CI pipeline. We have something basic here. We want to introduce pull-based. We want to introduce this idea that CI is going to be separate from CD. You can introduce this concept without having to go all the way down

Carter Morgan (19:45)

Right.

Nathan Toups (19:48)

Hermetic builds and Argo CD and all these like crazy cool tools. But when there's five people in your startup and it's not a core competency, you still maybe just introduce a new concept and you do it to reduce toil, you do it to reduce friction. ⁓ And understanding the right boundary for that is not easy, right? It's giving yourself the grace, I should say, to say this idea was serving us well when we were this size.

we have stress cracks on it, have to reimagine it. ⁓ I wish there was a book for this. Again, I get back to this idea of like, it would be really nice to be like, our company is at this level, here's the maturity checklist of, you these are like, you must have this by this size, or, and then you should need to kind of like think about these kinds of things coming up. Because I think that that's the idea is like, if you're on this growth trajectory as a startup, and you're getting funding,

Carter Morgan (20:31)

Right.

Nathan Toups (20:47)

we need to have that, think what Kent Beck calls the optionality stuff, right? Which is build the systems that I know that I'm gonna introduce this thing later, but right now we don't quite need it. And right, if you sit two desks away from your CEO and you're probably on Slack all the time and you're probably deeply collaborative, it is comical to say, here's how you present the two major updates twice a year that you're gonna talk to him about.

Carter Morgan (20:52)

Right, right.

Right, right.

Right. And there is a lot of value. This book does talk about like, how are you selling to executive leadership? you know, like you, again, the things we care about as engineers, even if someone has to have a bad job translating those into what a business cares about, right? Like we want to say we should be faster because that'll make our job more fun. When you need to be saying we should be faster because then we can iterate quickly and in a startup finding

what works and what doesn't. Like my boss says this all the time, right? Which I remember like when I joined a startup, when I joined, like I was just very used to like, again, kind of like the big tech cadence. And we had this feature we wanted to push out and ⁓ we all, but it wasn't like, we're not a B2B startup. So it's not like we had committed to the client that we would have this done. This was just a feature that we thought would be helpful. like, and so we had.

And we had committed to get it done that month and then the month is coming to an end and it wasn't done. And so we had the whole team swarm on it and kind of like really hustle and crank it out. And, know, like I was a little like, to me, I hadn't done something like that in a long time, especially when it didn't seem like it was motivated by any sort of extraneous deadline. And so I asked him, said, like, why did we do that? Like, why, why didn't we just like push it out a week and say like, well, it'll just get done next week. And he said, he's like, you know what, we're just at a startup and

are like we say all the time at my company, like startups are dead by default and you like you just need, you need more at bats. You need more swings because it's not guaranteed that every swing is going to be a home run. Right. And so just the more swings we can take the better odds that we will, you know, ⁓ that will, we'll find something that works and we can take more swings and we move faster and you can move faster if you have good dev X.

Nathan Toups (22:46)

Great.

Exactly and you know this gets all the way back to things like accelerate in the other parts, which is that there's a real? I'm a recovering ⁓ Recovering I would call it a PR hoarder or something where I'm like I mean if I just had a little bit more time This pair is gonna be perfect Then I'm not gonna waste people's time and the better thing to do is to figure out how to break up a bigger problem the smaller ones that don't have side effects faster right so is there a way for me

Carter Morgan (23:30)

Right, right.

Nathan Toups (23:32)

One way to increase your velocity is to break your problem up into smaller pieces and think about the no side effect portion of it and ship those things faster and get feedback faster. ⁓ Faster does not just mean, ⁓ I have this 10,000 line of code change, and how do I get that 10,000 line of code change faster? It is probably not a good idea. would be like, well, is there a way that I can just preempt what I know I need for the auth module, make that

update so that when I have this other piece and ship that, have it reviewed, the team that cares about auth, it like, cool, this is cool, this will be neat, this new feature that you need for auth so that I can build this thing next. And just ship that thing, show that it has no side effects, have it deploy out, even if it is behind a feature flag if you have to, ⁓ and then build the next feature that you have that gets to use the new auth module. Well, the auth module is not going to break in this deploy because it already went out. It is like

Carter Morgan (24:28)

Right, right.

Nathan Toups (24:30)

it starts changing on how do I keep this velocity of just shipping incremental value. It reduces the risk of you stepping on toes from other people. It makes it easier for you to ⁓ adjust if you realize three days in that the CEO's focus has changed where you're like, that's no big deal. I still ship these other valuable pieces. I can just change my focus for this downstream stuff. And yeah, again, I think it's...

thinking about a problem will never go out of fashion. And so I think that, and actually, so where we're picking up in the book, the book is, we were pretty far into part four, which is the seven step process. And I'll kind of mention the seven steps real quick. And we start off this week with six and seven. So we'll leave that to the audience to have their kids chime in on six, seven. ⁓

Carter Morgan (25:03)

Right.

Nathan Toups (25:26)

So step one is start your DevEx journey. It's like how do you even get started, right? Then you start small and get quick wins. They give you a bunch of strategies on this. Use data to optimize your own DevEx work. Step four is decide strategy and priority. Step five is sell your strategy. And that's where we left off, selling your strategy, which again, excellent advice for any scale. I would say even if you're not doing DevEx, this is like just good career management, you know?

business advice that is just generally applicable with the lens of sort of a platform dev, dev ex kind of person. step six and step seven, I think we can talk about together, which is drive change at your scale and yours in parentheses. And they didn't, they threw us a bone. There's like some mentioning of different types of businesses. And then step seven is evaluate your process, sorry, evaluate your progress and show value. So yeah, I.

Carter Morgan (25:58)

Right, right.

Nathan Toups (26:27)

Did anything in step six and seven stick out to you here?

Carter Morgan (26:33)

Again, I think maybe some things would have a little more if it were, it's very clearly written for very big organizations. did like, I guess this is in step six and seven. Is it step six and seven? I'm trying to, I'm looking at part five. Okay, I see what you're saying, yes. Yeah, go ahead.

Nathan Toups (26:50)

Well, I will say chapter. Yeah, yeah, no, and one of the things that stuck, yeah, go ahead, go ahead.

Carter Morgan (26:57)

I just, you know, there's a lot of like collecting data and analyzing data and like, get it. That sounds very important. If you are a VP at a big company leading this initiative, and I'm just cracking up at the idea of me trying to like collect data from my nine teammates, right? Like the data is just, okay.

Nathan Toups (27:15)

This is good, though. I'll push back in the sense that

there are, so for maturity level, and again, I think that you have to frame it in this, if you had the goal of our build pipeline has five minutes of downtime every time we deploy, the data there, and the only data that you would need is how much downtime do you have after your updates, right? And if you get that down to zero, because you had zero downtime deployments,

Carter Morgan (27:37)

Right.

Nathan Toups (27:43)

I mean, you don't have to measure this on some Power BI dashboard, but you are gathering this up that you can actually say, ⁓ we got it down to three minutes. We got down to two minutes. We got down to zero because we now have a blue-green, or we have a proper Canary deploy process. Measuring that thing that we don't regress, that when we do a change management, it should always stay at zero, is useful. And then that part becomes useful because it's just an uptime measurement. ⁓

Carter Morgan (28:05)

Yeah, right.

Right.

Nathan Toups (28:13)

If I just start measuring uptime, the old system would show that I have, you know, I'm only doing, you know, 99.5 % uptime or whatever because we have these five-minute deploys, or probably way worse, might be like 93 % uptime or whatever. And then you show that, you know what, since doing Canary builds, we've got a 99, we've got four nines of uptime and availability on our front end for the end user facing piece. Like, it's a useful metric.

It shows that we can't have regression. It's actually, it's something you would want to measure even that early on. And I have a buddy who worked at, ⁓ who was it? Favour, are you familiar with the company called Favour? Okay, so Favour was like a delivery service that got acquired by a ⁓ Texas ⁓ grocery chain. So maybe it was just an Austin, Texas thing that we took on. But they do a bunch of logistics for delivery of groceries and things.

Carter Morgan (28:57)

not familiar with favor.

Okay, cool.

Right, right.

Nathan Toups (29:11)

⁓

And they went from, I think they had some sort of internal regression that went from like, you know, five nines to like four nines and a half, right, or something. And it was a big deal, right? It was like a big deal internally. And they had a whole post mortem on how did they get to four nines and a half? Because this one service, was like mission critical, right? Like the way that this works.

Carter Morgan (29:23)

Yeah.

Wow.

Right.

Nathan Toups (29:36)

And I loved that sort of engineering maturity, right? Where they were like, hey, this is not okay. We're not gonna get used to this, we're not gonna adjust to this. What did we do? What did we change ⁓ that would allow this to happen? We're so proud of our five nines. And you could only do that if you're measuring in some consistent way.

Carter Morgan (29:56)

Okay, so that brings up an interesting point and taps into the zeitgeist a little bit because, this book is about AI. I think, like GitHub, it's been funny, I think GitHub had put out some press releases about how all their code is AI generated now, or their engineers are so AI-powered. Someone quote tweeted it and just showed GitHub's uptime in the past six weeks or whatever, and they're at 99.1%, which is crazy for GitHub.

Nathan Toups (30:24)

Yeah, no

bueno.

Carter Morgan (30:27)

And

I think, you know, we've talked about AI and we're genuine believers in how it's transforming the workflow. I'll give a special sneak peek for our listeners. Carl Brown, Internet of Bugs, we actually just yesterday recorded another interview with him. ⁓ And I thought it, I'm still thinking about a lot of the stuff we said there. ⁓ But ⁓ he had a lot of thoughts on AI and just kind of like how the...

we're moving up another layer of abstraction, but it's still important to understand the layer beneath that abstraction. yeah, lots of interesting stuff, but I think you and I are convinced that software engineering as a profession is here to stay, right? What the exact impact of that looks like, we're still unsure, but we also believe that AI has kind of very fundamentally transformed our workflows. But so you look at the company like GitHub.

where they're seeing uptime problems. And I think SaaS stocks have really cratered. Because the big question is, could you run Calendly with 20 % of the workforce? And we talked about this with Karl Brown, where I'm like, I don't think anyone's going to disrupt Walmart because they vibe code a better Walmart. There's just too many other competencies Walmart has baked in that are not software related. But these SaaS companies,

Could you make a version of Calendly that would you run with 20 % of the workforce if you are kind of totally all in on AI and then you can offer Calendly at a lower margin? I think one, give me your thoughts on like, is that even true? Do you even think that hypothesis holds? And two, could you even do that and maintain engineering quality? Or do you see something like GitHub where you're not even at five nines, you're at two nines these days, right?

Nathan Toups (32:01)

was...

Yeah, no, this is interesting. I think that there is a, there's a few things which I've heard expressed pretty, pretty well, which was, you know,

SaaS stocks are given a price to earnings ratio. It's so many multiples of their annual revenue, typically, if they're publicly traded. And the idea is how big the moat is, how much we can project into the future that the value of this company is there. That's a very liberal investor-centric way of looking at it. So if you're doing 10x or 25x price to earnings ratio, some really high number.

Carter Morgan (32:41)

Right.

Nathan Toups (32:56)

you really, it's kind of the marketing saying, hey, there's 10 years or 25 years of certainty around the fact that this is bringing disproportionate value and it will continue to increase in its value over time. And that to build a replacement for it would cost 25x annual revenue, right, or whatever. So I'm kind of reducing these ideas. So two things, number one is have we been consistently overvaluing these SaaS companies? And number two is,

Carter Morgan (33:15)

Right, right.

Nathan Toups (33:24)

is the cost of actually replacing them gone down? And I will say, I agree with the Walmart piece, logistically it's just so complex, but is there a worse is better competitor to Calendly that could be coded with team of talented engineers and a good skill set ⁓ that gets you most of the way there? And I actually, do think that companies like that are at risk because

Carter Morgan (33:38)

Right.

Nathan Toups (33:52)

Though I'm guarantee that I can't just straight up replace Calendly, could I make a tool that has a basic amount of scheduling conflict resolution, a signup form, and some other stuff, and you think about it you're like, I think that this is actually possible, and the market would adjust that. So if they were doing seven times price to earnings ratio, maybe it goes down to three. The idea being that with the equivalent of three years of revenue,

could you make a viable, good enough replacement for a decent number of people in that market? And I think that that's an interesting way of framing it. Whether that's really true or not, I'm not an investor. I'm just trying to, like this is my sort of barstool argument. I think that, I don't think SaaS is dead, but I do think that the idea that SaaS can basically charge whatever they want, because it's just too logistically difficult to get the 5 % of features that you actually want out of it.

Carter Morgan (34:35)

for Brian Rime.

Braaay.

Nathan Toups (34:52)

hit that, that's changed. I'll say this with, Book Overflow is a good example. ⁓ I've made a really crappy content management system for Book Overflow, if you think of it in the sense of a generalized content management system. But I've made a really nice purpose-built content management system for exactly what Book Overflow needs. Like, we have this concept of episodes, we have the concept of series of episodes, we have the concept of guests, and...

Carter Morgan (35:08)

right.

Nathan Toups (35:21)

people in a book versus people in an episode, I have this very clean relational database based off of these things. I can generally just add content in there now. It's really easy for us to share links. All the things I would traditionally probably just like built on top of some generic content management system. And I didn't need that. so like, and I was able to do, and again, I'm not a normal person. Like I'm a software engineer who's, you know, worked in a lot of spaces around this, but.

Carter Morgan (35:40)

Right, right.

Nathan Toups (35:49)

I use it as an experiment to vibe code a few things. It's good enough. Maybe I'll get twisted up and detect that or something. But I don't think so because I have a really clear idea and I'm not leaning on some generic fix all version of a content management system to try to solve a short term problem. And so I think that, you know, I think a world in which we can build purpose built software for very specific needs is going to make it.

a lot easier, which means that the baseline subscriber base that's kind of overfitting on what a software as a service does isn't great anymore. And this gets back into lots of stuff, right? Like, I think that people are gonna start self-hosting more things that just make sense for them. And then, you know, use Work OS or use, you know, other big linear or these other tools that are super high value, right? They're gonna just have to double down on being so good at being sort of the

Carter Morgan (36:24)

Right, right.

Right.

Nathan Toups (36:47)

know, nerve core of a more complex system that they really become even more valuable, right? I think certain SaaS companies are just gonna become more valuable and then a lot of them are gonna go by the wayside.

Carter Morgan (36:59)

Yeah. And I'm with you like SAS is a category is not dead. Like I'm very skeptical of like Susan from accounting is going to vibe code quick books on our lunch break. Right. Like, and companies do not want to maintain this software, but we keep using Calendly. don't even think Calendly is public. I hope Calendly is not public. What are we doing?

Nathan Toups (37:08)

No.

And also,

I will say, I'm not gonna vibe code a replacement for Calendly. I like Calendly. Yeah, it's great. We're picking on them because it's something I can wrap my head around.

Carter Morgan (37:24)

Yeah, yeah, we use Calendly,

And like, we're never going to, I'm with you, we're never going to vibe code a replacement. Like we like Calendly, but could a company 20 % the size of Calendly come along and vibe code their own Calendly. And then that puts pressure on Calendly. Now they've got to do layoffs. They got to thin their organization. I don't know. And so like, I think these kinds of purpose-built tools are always going to exist and people will still continue to subscribe to them. Will they just get cheaper? Which is good for the consumer, right? Like if, if SaaS gets cheaper, like

Some SaaS is exorbitantly expensive, but from a software engineer, obviously a decent number of us are employed by these SaaS or SaaS-adjacent companies. ⁓ But then I think we're talking about this because we're talking about in the context of frictionless, it's like if you wanted to kind of take on, if you wanted to be the challenger and say, I'm gonna do what you do, but way leaner, right? I actually think that's it.

That to me sounds like a very, very interesting software engineering challenge. keep thinking like, I have never read Dune. I've only seen the movies, but I know enough about Dune. And I know that in Dune, that the spice that they get on the planet Dune is really valuable because the only way to navigate like interstellarly in the Dune universe is that like you have to have a human navigator do it, but there's so many kind of like components.

going on with the interstellar navigation that you need to manage. They have to consume this spice to be like, you know, have like superhuman instinct and comprehension or whatever, right? And so that's why the spice is so powerful. And I just keep thinking back to that and I'm like, is that the future of software engineering? Right? That like, I just have like 20 agents and I'm just like, like super locked in, like managing them all. And I don't know, right? Like there's still enough that.

I do where having a human in the loop seems really valuable. I don't know, maybe that's what software engineers are gonna be.

Nathan Toups (39:25)

Yeah.

But I also think that it could be that we ended up having these little microagents that are more like Unix daemon processes, right? Where they're just kind of doing a lot of little bitty tight feedback loop, very tightly scoped maintenance pieces. This actually reminded me of something that came up from a Google report years ago, where I think it was, I mean, this probably was a decade ago, I can't quite remember. Google was talking about their version control system, which is not yet.

Carter Morgan (39:39)

Right, right.

Nathan Toups (39:58)

They have some much more complex thing, and you can just check out parts of the code base that you're working on. But Google is famous for having this monorepo. It's like billions of lines of code or something. But more machines make changes to the code than humans do. And it has been like that for very long time. And again, lot of it's deterministic stuff. It's not large language models doing it. But they had systems that were enforcing correctness and doing these things.

Carter Morgan (40:15)

Interesting.

Nathan Toups (40:28)

⁓ could refactor or do fixes or do all kinds of stuff. Humans were still in the loop, I'm pretty sure, at least back when I was reading this report. I'm sure a lot of this is outdated. But it struck me that I think it was something like two to one or something. I'm going to roast me in the comments. the idea was Google had already gotten to a point in which ⁓ humans were obviously guiding everything and there's still a tremendous amount of software engineering happening. But there's a lot of minutiae.

that it doesn't really need to be done by humans and that the relationship between what we allow to be autonomous and go through these quality gates and do these things safely and what needs to be, know, a software engineer sits down and does it themselves, those lines are getting blurred more and more. And I think they were living in the future and this has kind of become more widely disseminated. ⁓

Yeah, I think that there's lots of, and I've been in different projects. I was in a project not too long ago where they used ⁓ Cloud Code. They had like a Cloud Code bot in GitHub that was a code review bot, right? It just sat there and just like whatever code I wrote, it would kind of do like a code review as a senior software engineer and like just bring up stuff and be like, hey, this isn't consistent or do this or that. And it was actually like, sometimes I would ignore the feedback.

Carter Morgan (41:35)

Right, right.

Nathan Toups (41:49)

Or sometimes I'd be like, oh, you know what? That's a really good point. I really actually need to incorporate this before I actually ask another human to do the code review. it made my PRs just better. And I actually really appreciated it, even if sometimes it would hallucinate really hilarious things. And this is a few months back. But I would love it if there was this like, you can imagine these little agents that have

very narrow scope like your security audit agent and these other ones that kind of help me just move things faster. again, if I could get an agent to give me a quicker feedback loop so that my code review is better for the human, that reduces friction, right? This is a way for me to not waste other people's time, have a coding buddy who's kind of taking a fresh set of eyes, which is what a large language model does every time. ⁓

And so yeah, think this is one of the things I love. In chapter 35, they talk about this, and this gets back to DevOps Handbook. say, communicating your results, right? Communicating your results should really come down to data that supports things like time savings, reducing toil, and improving focus time, right? Like, this is just some examples of some stuff. those are three that actually I end up bringing up a lot because improving focus time is just...

Focus is a superpower. I tell my daughter this all the time. It's like, focus is a superpower. And we're in a world that's constantly distracting us, right? You really have to fight to have focus time. And focus time also is there for aha moments. Like we were just talking about this at breakfast this morning. And I was like, you can't schedule an aha moment. You have to like work on something. And you have to have a regular cadence to show up and work on the thing. But the aha moment happens when an aha moment happens, right?

You don't know when a breakthrough is going to be there. You don't know when something's going to click. You don't know when the design finally gets to the right spot that solves the problem at work. And so if that only happens when you're focused and you're constantly distracted, it means you're missing out on aha moments all the time. And that's where the deeper part of this book I think is really powerful. Again, I wish it was more succinct. I wish that they'd maybe consulted with John Osterhout and learned how to make a 120 page book. ⁓ But yeah, I think.

Carter Morgan (43:57)

Right, right.

Nathan Toups (44:12)

There's such powerful ideas in here that I don't want to gloss over. It's really cool.

Carter Morgan (44:18)

Yeah, it's a, why you say there are ideas you don't want to gloss over. mean, are you talking about just what you mentioned there or are there other things that you wanted to make sure we got to?

Nathan Toups (44:29)

Yeah, yeah, yeah. one of the things I thought was really good, and this is hard, I will tell you that maybe at an early stage start of it doesn't feel like that much of a focus. You can really lose credibility, but it's like, how do I tie an initiative back to cost savings? Or how do I tie it to moving the needle on revenue that comes in? If I say, oh, we did this thing, and we have this many engineers, and now we've got, you

Carter Morgan (44:46)

Yeah.

Nathan Toups (44:57)

a million dollars in our pocket because we've saved so much time. ⁓ If you come up with some grandiose number, you better be able to defend it. If you say, yeah, you heard a five-person engineering team, and you say, we've saved $5 million of engineering time, you're like, you didn't. But if you said, you know what, we've unblocked. ⁓ We found that because of the friction on our build pipelines that ⁓

Carter Morgan (45:05)

subscribe.

Yeah.

Right, right.

Nathan Toups (45:25)

for engineers to stay busy, they had to context switch three times every day because of being blocked in their continuous flow, and that we've realized that it slowed down feature development by 20%. And if you have real data behind this and you say, so we did this thing, and we actually have this many meaningful feature, we're going 20 % faster. And we've actually reduced the number of rollbacks that we've had to do because of the focus time really.

shows that if you can make this case, hey, you basically have like, you've actually hired an extra, you know, if you have five engineers and you get 20 % time back, you've actually hired a sixth engineer in the amount of time you got back, right? Without having to hire one, right? You virtually hired one. ⁓ And so these are the kind of things that if you learn how to measure yourself and you learn how to tie it into the impact that you're driving in the company, ⁓

this kind of gives you this nice feedback loop to figure out like, it's not just, oh, can I impress my boss or can I impress the CEO? It's like, hey, Carter's solving real categorical problems here. He identified that we could be 20 % faster, which for us is a huge deal. And he figured out a way to do this and he pushed his way through even when it didn't make a lot of sense to me. But you can't argue with the numbers, like that's amazing. And I love it that we get to get features out the door faster, right?

Carter Morgan (46:34)

right.

Nathan Toups (46:50)

I'm not saying that this is easy, but again, this book does a good job of being like, don't make up numbers, have real things to back it up. if you can do this, sometimes you get super lucky ⁓ and you realize that you've found some order of magnitude improvement in some system that you're building. of course you should brag about it if you find that.

Carter Morgan (47:16)

And it reminds me of like ⁓ Staff Engineer by Will Larson where it one of the big lessons from Staff Engineer is like you really have to pick your battles and you have to make sure you're working on high impact stuff and you know a book like this could be helpful for someone who has been has been tasked with making some big improvements across DevEx at a large organization where they are looking for cost savings probably on the mag you know on the order of like five million dollars something like that and it can be

tough. mean, have I, I'm sure I've told this story on the podcast before, but I remember, did I tell this last week about when I had to implement a feature at one of my companies that took longer than I thought it would? Did I?

Nathan Toups (48:00)

It might have been last week, but it was recently, yeah.

Carter Morgan (48:02)

Okay.

Okay. Yeah. I just remember, I won't give the whole thing. uh, just be, I just remember we had a feature, we had to implement it. It was supposed to take like three months. It wound up taking more like seven, not all the way through, but just like, uh, it was probably like four months of active work and then three months of kind of like waiting on other people and things like that. When it was done, I was really excited that we got it done. And my manager was just like, if I had known it would take that long, we wouldn't have done it in the first place. And that was like a real gut punch and a learning moment to me to be like,

It's not just about getting the work done. It's about making sure that you're getting the work done in a way that justifies the investment. And so, you know, if you are running a DevX initiative and you're like, good news, all teams now have linters. Like, isn't that great? You know, as an executive might be like, well, why do I care about linting? Right. ⁓ and so, you know, the book mentions like, you should start small. should get some quick wins, right? That helps you kind of, that works, gets your flywheel spinning faster. You, get trust with organizations, right?

Nathan Toups (49:00)

And I'm just gonna

riff on this one. Why would a linter, and why would as a platform engineer would I go and say, you know what, it's linters, right? Like that's my thesis. So if I was gonna be like, you know what? I did my qualitative and quantitative analysis, I talked to the engineers. The number of nitpicks in a code review is driving them crazy. We looked at what the nits were. it's just coding style.

Carter Morgan (49:07)

Exactly. Right.

Right, right, yeah, you know.

Nathan Toups (49:24)

for certain types of things. man, a linter could fix all of these things. And half the feedback is, hey, did you run the linter before you did the thing? We stuck it in the CI. It fails before humans even involved. Or we even put it in a pre-push hook or whatever. And then all of sudden, PR review time decreased by 50%. Bam. All of a sudden, now you have a real number that your CEO would care about. You're like, hey, I helped reduce PR review time.

Carter Morgan (49:51)

Yeah.

Nathan Toups (49:55)

complain that we have these features sitting there in review but not being done. And this was one of the biggest friction points, and now people are happy to do a code review.

Carter Morgan (50:04)

Yeah, you know what, like, I think, yeah, you know what, I'll take it back. Maybe Lenting, maybe there is a scenario where, yeah. Yes, yes, right.

Nathan Toups (50:09)

No, no, but doing it just because that's the right thing to do is the

bad idea. Like you have to tie it back to some value. And it could be, hey, we thought that the linter would make a difference and it actually didn't. Oops, like how do I qualify this better next time? Like these are, but again, it's patterns over tools. think I'm a huge, I've said this in the past. I'm a big advocate for it here. And this actually ties in, I think it was the end of one of the chapters that said the ultimate goal isn't building the perfect bet.

DevEx team, but creating an organization where developer experience is valued, measured, and continuously improved. And this ties into DevOps in general, which is this idea that, hey, DevEx is just part of the process. Are we struggling with something? Maybe we should look at the DevEx portion of this and see, you know what? The new person that we hired, ⁓ how many days did it take them to do their first code commit? Meaningful code commit. man, it takes

a week? Why does it take a week for a new engineer to do their first commit? What could we do to make it fun and incentivize and not scary so as soon as they have access to the systems, we can encourage them to open their first PR, right? Even if it's just a baby PR. Because I think I've seen this friction of like, I don't even know where to get started. I don't even know the right way to do this or am I going to break something? And getting them over that hurdle is like an excellent sort of like, and any size startup can do that.

Right? You can do this when you've got interns, and it's the first time they've ever used Git or something.

Carter Morgan (51:45)

Well, before we wrap up, think I just like to mention chapter 60. It's one of the final chapters, maintain your metrics like any product. A shout out for that, even if you are not involved in any sort of DevEx experiment or experience initiative. Yeah, like your metrics are everything. Your metrics are what are giving you a clear insight into the health of any system, right? And the moment you can't trust your metrics, they're useless. so I think ⁓ metrics do need to be maintained. I found an issue.

a of weeks ago where we were failing to export about a quarter of our metrics. So our traffic just looked a lot lower than it actually was. And I need to be better about setting up some sort of automated alarms so we know when that happens. But at any rate, the moment you can't trust your metrics, you're flying blind. So big shout out for keeping good clean metrics on any product you're working on.

Nathan Toups (52:38)

Yeah, I think another thing that stood out to me, think there was a section, there was a few chapters before the one you just talked about, but it was about tool standardization. And I would say tool standardization may be a bit premature for early stage startup, or it's just implied because you only have a couple tools. But the idea behind tool standardization is you end up getting these things called like scorecards in bigger organizations. You might have something that's like gold tier, silver tier, bronze tier.

Carter Morgan (52:55)

Bye-bye.

Nathan Toups (53:06)

You may have read this chapter and thought, man, this is way overkill. But the idea behind it is that golden paths are the blessed paths. So if you do this, it's something that maybe the DevEx team or whoever's thinking about it, you're like, hey, this will just work. You don't have to think about it. This is the way that we set up pipelines. There's zero maintenance. It's the golden path. But we need to support alternate paths.

Carter Morgan (53:16)

Right,

Nathan Toups (53:34)

Silver tier or bronze tier is this idea that bronze tier would be approved experiments. Maybe your team has a hypothesis that CircleCI is better than GitHub Actions, and that your microservice that you're working on, whatever you're having to do coordinating GitHub Actions is just slowing you down. We want permission that CircleCI is okay to use, and let's say it gets approved. Then you make this case like,

Circle-C is one thing that fits our cycles really well, we think that actually the whole organization should go to it. I like to cultivate environments in which those experiments, those focused experiments are fine as long as they don't negatively impact the rest of the tools. ⁓ But you need to still have constraints around that. I think Adobe, had a case study here, Adobe said that gold technologies aren't just winners. They basically, they think of them as like

venture capital firm who's put a bunch of resources in certain startups and certain startups start blowing up, it's that gold is a description of ⁓ concentrating resources on things that have the greatest impact. So something becomes a gold path for your DevEx initiatives when you go, every dollar that we invest in this thing, we get 5x return. Or every time that we do this thing, ⁓

Carter Morgan (54:58)

Right, right.

Nathan Toups (55:00)

has this huge impact. And so that you should basically fund the winners. That's kind of like how you think of it is it's, ⁓ you know, and if you as an engineer think about how can I build golden path DevEx tools or how can I build things that disproportionately positively impact the organization? I think it's like a fun way of thinking about how you build stuff.

Carter Morgan (55:23)

Well, why don't we wrap up with some of our hot takes and I think listeners, sometimes we'll do this hot take section and we'll just kind of reiterate things we've said throughout the episode. You might say like, why don't they even have this section at the end if they're just gonna reiterate? But I actually find this is a good forcing function for Nathan and I when we are like reading a book to, we read a book a while back which we were fairly critical of and we were a little nervous, like, ah, our audience is not gonna like it and.

And you guys were like, we love it. We love when you guys are honest and give us your opinions. We're like, okay, great. We wanna try to do that more throughout regular episodes. So I mentioned that because my hot take is what we've talked about this whole time. This book is just too long. this, and I think it's one thing to say that like a 300 page book could probably be 270 pages or could probably be 260 pages, right? Like I'm like, ⁓ who cares? Like, you you're nitpicking here. This book could be half,

the length and it would be better for it. And so I'm not exactly sure what happened to the editing process to make this book so long. yeah, just, I wish, someone needs to write the book that's like, these are the effective DevEx patterns you should leverage to make AI operate effectively on your code base. I understand if this book isn't that, although I do think that the framing around how it's built is interesting.

Nathan Toups (56:21)

Yep.

Carter Morgan (56:49)

⁓ but just this book as it stands, if you gave it a different title and it was just like improving dev ex at large organizations or something like that, it could still be half the length. And, I think it would be better for it.

Nathan Toups (56:54)

you

Yeah, this gets back to the less is more idea. I'm the same, but I feel weird being this critical, but I also am, you we want to be, we want to honor our audience. want, you know, we think that this podcast really is, should I read this book, right? You know, these guys are discussing this, they're software engineers, they care about the craft, should I read this book? And I...

Carter Morgan (57:05)

Yeah, yeah.

Right.

Nathan Toups (57:29)

The ideas in this book are so good, I wish it was more succinct. I really do, like, they're, and maybe we can, get into this on like, who do we recommend this to, right?

Carter Morgan (57:38)

Well,

we can swap it up a bit as far as who we recommend it to. look, anyone who, yeah, if you are an engineering leader tasked with improving DevEx at a scale up or large Silicon Valley style tech company, this is the book for you. This is like the handbook. This is how you should do it. can tell that it's a lot of Nicole Forsgren and I've noticed a wreck experience is in this book. I mean, it's a fantastic book for you.

I think there's probably 500 of those people in the world, right? So, you know, do you write a book that only 500 people are gonna get a ton of value out of? mean, personally, I wouldn't, ⁓ but you know, if that is you, hey, that's great. This is a fantastic.

Nathan Toups (58:14)

Great.

Yeah, I agree. I think that the audience that we get cover to cover value out of this is pretty small. ⁓ That being said, I think the ideas in here are super powerful. I think if you are into like Pokemon, gotta catch them all, DevOps books. ⁓ Yeah, like, and I think I said the same thing. said, this is specifically for platform engineer and DevEx-focused leadership, right? Like this is exactly the target audience. ⁓

Carter Morgan (58:41)

Right, right.

Nathan Toups (58:54)

glad I read the book, I probably would have put it down after reading the first half or so and skimmed the rest of it, right? Like I, yeah.

Carter Morgan (59:05)

Here's

also say with book overflow and like, you know, we've been honest about this the past many of the books we read I never would have finished if we did not have the podcast as a forcing function to make us read them, which isn't because the information is in them isn't great, but just because you know, it's challenging to read technical books. And I will say maybe this is, ⁓ you know, death by faint praise, but like we didn't quit reading this book and we have done that in the past.

Not only have we done that with a book that we actually did an episode on but there have been books where we have started reading them and we've said like We're not gonna we're not even gonna go further with this and we just don't even produce an episode on it. So

Nathan Toups (59:44)

Yeah.

And I will

tell you, if you like the ideas in this book, first of all, ⁓ pragmatic engineer, ⁓ Gerge is a huge fan of DX, of Abhi. Abhi's done guest write posts and things. Also, Abhi has his own sub stack called engineering enablement. It's like part of the DX ecosystem. If you like the ideas from this, I would highly recommend checking that out. I think he just had one on like how Dropbox does certain stuff.

Carter Morgan (59:55)

Yes.

nice.

Nathan Toups (1:00:18)

And it's really good. I read every one of his newsletters. They're super, super good. And so if you want to get 80 % of the value and also have it overlaid with topical, breaking news, academic papers on DevEx that come out and things like this, and his thoughts on it, that's where I would spend my time, right? Unless you're actually...

implementing a DevEx initiative from scratch or trying to recover from a failed set of attempts and you've joined an organization and you really need the heavy hitters insights on DevEx specifically, I think you can pass on this book. again, I say that with somebody who has the deepest of regards for these two authors.

Carter Morgan (1:01:02)

Right, right. Well, so with that, ⁓ I guess, yeah, we swapped up a bit. I mean, as far as what you're gonna do differently in your career, because you've read this book, what are you thinking, Nathan?

Nathan Toups (1:01:14)

You know, this book just kind of a prime, it just primed me for this, is ⁓ improving the techniques around focus time in the lens of DevEx is something I need to bring to the table. A lot of times I get into architecture and CI CD optimizations, but making sure that I'm also helping organizations solve for improving focus time. ⁓

is something that it really drove at home, that this should be part of my consulting practice as well. ⁓ For engineering, the health of the organization is, focus time is big part of that.

Carter Morgan (1:01:48)

Right.

Yeah, for me, I was already planning on doing this, but as a good reminder, we are moving to a mono repo at my company. And ⁓ we've had a front-end mono repo for a bit, but we're reading the backend and like our Terraform and a lot of other stuff in there. And I just really want to lock in our mono repo, DevEx experience. I just want to make sure that, you know, we're not running, we don't have like overly burdensome Git commit checks. And that when we do, we're not linting the entire mono repo every time we commit, right? I just want to.

⁓ be good about that. ⁓ So yeah, good books are good reminder. And that wraps us up for this week, folks. That is Frictionless by Abhi Noda and Nicole Forsgren. Nathan, what are we reading next? It's on our, it's on our, ⁓ yeah, Crafting Engineering Strategy, How Thoughtful Decisions Solve Complex Problems. So, cool. Yeah, I'm excited to read ⁓ Will Larson. We're doing, that's a two-parter. ⁓ So we're gonna read the first half.

Nathan Toups (1:02:38)

Yeah, what are we reading? I think it might actually be another Will Larson book.

Carter Morgan (1:02:54)

in the second half there. Thanks so much for tuning in everyone. You can always find us on Twitter at BookOverflowPod. I'm on Twitter at Carter Morgan. can contact us at contact at BookOverflow.io. Go to website BookOverflow.io to see our schedule, some of our past episodes. ⁓ Yeah, Nathan and his newsletter is at rojoaroboto.com slash newsletter. And that's where the Workforce Consulting Agency is as well. ⁓ And yeah, stay tuned for our episode with Carl Brown.

That's gonna drop a special sneak peek. We try not to give it we like it to be a surprise But honestly, I'm just so jazzed because it was such a great interview. I'm hoping you guys enjoy it That should this is dropping on a Monday that should drop the Thursday following That Monday so check it out. Alright, thanks folks. We'll see you next week for another will Larson crafting engineering strategy. See ya folks