Lean TDD With Brian Okken  🔗 **Source:** [Lean TDD With Brian Okken](https://www.youtube.com/watch?v=2Y7fOH3VleU) [00:00:00] Welcome to the Overcommitted Podcast, [music] your weekly dose of real engineering conversations. I'm your host today, Erica, and I'm joined by Hey, I'm Britney. We met [music] while working on a team at GitHub and quickly realized we are obsessed with getting better at what we do. So, we decided to [music] start this podcast to share what we've learned. We'll be talking about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a community where engineers can learn and connect. Today on overcommitted we are joined by Brian Aen lead engineer at road and Schwarz creator of a pi test book and course and author of a new book we are thrilled to be talking about today called Lean TDD. Welcome Brian. [00:00:43] >> Hey thanks for having me on the show >> to kick us off. What's one thing you're currently building or obsessed with learning right now? So, one of the things I've always wanted to do, I'm kind of excited too because uh there's a SAS idea like that I've had involving estate sales and stuff like that that I wanted to build for a long time, but I don't have the capacity. And I'm not really a web developer. I've been embedded for most of my career. And I I mean, I've done amateur web stuff and have a couple sites up, but but something like a big SAS that does communication with texting and all that, I don't know how to do that. But I'm hopeful that with a little bit of an AI agent, I may be able to build something useful for people. So that's something I'm trying to get to. Yeah. So that's what I'm building. [00:01:27] >> That's exciting. Yeah. There's nothing like finally scratching that itch of something you've been wanting to build for a long time. >> Well, we are going to be talking about your new book, Lean TDD. TDD standing for testdriven development. And you know, shameless plug, it's a great book and it's very practical. But for anyone who might not be familiar or who hasn't read the book, uh what is lean test-driven development or TDD and how is it different from traditional TDD? And if you could give us the version you tell someone who's never written a test and then the version for someone who's done TDD for a decade. >> Okay. For somebody who's never written the test, I don't really believe you. [00:02:10] Like if somebody writes software, they somehow figure out if it works. Like like I build a thing, I'm supposed to build a thing. I build a thing and what manually test it, maybe push some buttons. If there's no user interface, then you have to like write a little what a little wrapper around it to to like drive the thing to see if it's working right. Or maybe in a ripple, like if you're a Python person, you can do uh do it in the terminal. I don't know. Is ripple just a Python thing? I'm not sure. Uh but I think anyway some other languages have like an interactive area you can try things with. I mean I came up in C and C++ we didn't have anything like that. Yeah you got to compile stuff first but okay so you tried something out manually. You want to make sure that it keeps working like [00:02:54] the the manual part's hard to do if you just keep you can't just keep trying everything out all the time. So the the idea and also you learn stuff when you try it out. So the idea around test-driven development is to say hey like what is it like what would I try it out as like what what would I do to try it out to make sure it works and just write that that the little wrapper thing in a in a script and then to the test is we call it a test function but it's it it gets called by the the the test runner so you don't really call it yourself. It's just a little tiny snippet of code that runs and make sure things work. And so we usually like set up a system to say I'm going to get [00:03:37] ready to get the thing ready so that I can run my function and then I run a function and then either check the return value or something and then make sure that works. It's it's like just slightly a little more time than actually just writing your own little manual thing to try it out. The benefit though is that you keep going. You can keep you you make sure that they all work always. So you just keep adding to your suite and you got all these tests to make sure that nothing breaks and which is really great for things like refactoring because you want to like try to change things up and and and and then not break things. The lean part is we break things all the time. And so we like internally like a little so I want I want to like to have a whole suite [00:04:19] that I can push up because we have GitHub and CI and like stuff where I want like I change some new code and I just want a something to run that checks everything to make sure I didn't break anything maybe before a merge or something. So we're trying to build up those automated tests to make sure that they work. But we do like to refactor and stuff and especially with the AI you can and agents you can say can we just like move this over there? This looks weird. Can we split this up and it'll just do that. But if you've changed a bunch of functions and you have tests at the function level it's it's going to break your test. So you got to rewrite the test. But we don't really usually change the API to the system that much. We have to say like I'm actually adding a new behavior. I'm changing a [00:05:01] definition of behavior. So the really the idea around lean TDD is just to say let's try to get the tests as high as possible so that we can refactor without breaking tests. That's pretty much it. Great. Now you don't have to buy my book, but there's more gems in there. So >> Oh, there is. Oh, there is. Starting with sort of picking up where the book starts of making the argument for TDD and why it's valuable. and you recognize that engineers who do know what TDD is often find reasons not to do it. One of which is that they say that it's going to take them more time to do TDD than the alternative. >> Yeah, it will if you do it the way most people teach it. So most people teach it [00:05:45] at that little function level thing and that's hard. So let's say I like I I'm I'm in the middle of like something massive and oh I got some data coming in. I just need to like you're not going to really write your own sort algorithm, but I'm just like like let's say I want to take all these these uh elements in and I want to sort them or something. I could [snorts] write like a test for my little sort utility function also some and but like you probably won't because you'll just pull off the shelf sort but okay in our theory that we don't have off-the-shelf sort. We're going to write a little maybe a test for that. But then I could just like try it out and and nobody's going to change the sort function so it's not going to break really is it? So do I really need the test? And so the decision of it's really [00:06:30] it's actually pretty hard. I think it's harder to write tests for small things than for the system because what is it supposed to do like and and I write so a lot of the code I write is in the middle like I'm I'm there's a big software in lots of teams there's there's lots of layers of stuff and I'm like maybe taking when somebody clicks a button a package thing comes down and I have to route it to the right hardware or something like that or I need to when a measurement's done grab some hardware data and like push it up to the UI. How do I test that? Do I really have to like stub and fake out and everything? And a lot of people teach that to say really I just want to test the function you're writing. So isolate everything else, fake it, mock it, all that sort of stuff. And I've never done that because [00:07:13] I don't even know how. Even if I did know how to do that, what would the requirements be? I don't know because I don't I'm not thinking about the system requirements and it's not the whole system requirements. It's just like this piece like is it going to take negative numbers? I don't know whereas like if you run it through the system I can look at the data coming through and go for the whole range of input this function only gets the numbers like 1 through 7 so I don't need to check anything else or there's yeah I I think there's a way if you stay at the small level I think it will take more time but if staying at the higher level I don't think it takes more time but there are a lot of people that don't want to think about the system that's the other part is um like [00:07:57] I that's not my job it's somebody else's job. However, when I started, and it wasn't my job when I started, it was my job to do the little tiny in between thing. But when I started asking people like, well, how do I drive it from the outside? All of that time I gained back because I didn't have to rewrite my tests because the API never changed. I just I kept being able to drive it from the outside. I also found stuff that was wrong with other people's systems because not everybody else was testing well. And so even though my job was like the little tiny piece, when I started caring about the system, a couple of things happened. I started get learning about the system better. So I was better at my job because I just understood the the whole thing. I understood the customer's perspective better because [00:08:39] that's what I was thinking about. Um I was able to go go to like do demos at customer sites and stuff because I knew it way better than the the marketing people did. And the other thing is I was I was helping other people do their job better because I'd be like, "Hey, this thing isn't quite working. Can we do that?" And a lot of the things we fixed never hit issue report or bug tracker. It was just like a message to somebody going, "This is weird. Is this supposed to do this?" And they're like, "Oh, no. I'll fix it." And it's done in minutes instead of instead of going through the triage phase. The other thing that happened, that was the the immediate benefit. The big benefit was I started getting noticed by a lot of people and when they do like the whole who should [00:09:21] get a raise thing, people are like, "Oh yeah, that guy's good." Because I was out there talking to people and so it skyrocketed my career. I think it benefited me a lot to just get well known in the company. So >> I could see that making the case for you for sure. Finding bugs and and fixing things before customers do. >> Yeah, for sure. that that that makes a lot of sense and >> well it's it's also Ca so I I try to discourage people from CYA testing or cover yours and and it's it's it's real though I I really want to make sure that the bug never lands on me however I also want the system to work I mean big [00:10:04] picture we really want the whole company has to make money or else I don't get raise sort of thing so anyway >> it's true and reorgs happen so often in a lot of companies that what isn't your problem one day could very much become your problem the next day. >> Yeah. Yep. >> Yeah. Yeah. When I learned TDD, it was very much like write this unit test and make it fail and then make it pass. And yeah, I think that that approach just never worked for me in part because it did take so much time and so much like ah it's so granular and just this one thing. So, I really appreciated that about your book where you're taking like a step back and you're like, "All right, what's really important here is the whole system." [00:10:45] >> Yeah. Also, it's just a bummer that that's where the what all the teaching is. So, I was around in the '90s and it was called units and unit testing because the test frameworks were called unit test frameworks for some reason. And so, unit test was the thing that a unit test framework would do. And and it in the the whole like, oh, it's the smallest possible thing that came later. It's like somebody else threw that on there. And then Canon like Kat Beck came out with Canon TDD a while later. What? What? But like a long a long while later. It's been 10 years or so, but it was a long time after tester development started. And he pretty much said that it's like he his Canon TD does not say just units or just functions. It's it's [00:11:28] wider scope. So I'm grateful for that. I could see I mean the tooling landscape has changed so much since when the agile was created too you know like there weren't things like >> Mocha back in you know whenever the original >> what's Mocha again >> it's for browser test running >> yeah so like we just we didn't even have browsers back then like I mean we did so the the browsers came out in the '90s but the uh but with but we weren't creating I was we weren't creat creating instruments with them. Back then we were uh we were using like you know Windows gooey tools and and Sun Solaris gooey tools and stuff and you could automate [00:12:12] those but they were horrible. They were like pixel like set the the mouse cursor at these XY axes and and trigger the click button. Yeah, nobody wants to automate the gooey stuff. So we would just like hire teams of people to do that. But yuck. Who wants to push buttons as a job? He says as I'm pushing a little a little rectangle full of buttons all day long. Keyboards are different. I like keyboards. >> Yeah. Later in the book, you kind of talk through what your lean TDD workflow is. And it did really strike me that so much of it focus focuses on the behavior and what it actually does, but you're also being very reflective throughout [00:12:56] the process of the implementation itself. You kind of walk through an example of of something you might write and you talk about defining the acceptance criteria and then going from that to to the actual implementation. And I really appreciated how at no point in your described process you turned your brain off and went on autopilot saying like, "Okay, I you know, for example, like this name is great. I'm just going to use it." You're kind of like questioning throughout the process of does this make sense for the user? Is this going to be clear? Um, but you also say kind of at each step, don't change the test and the production code at the same time. You kind of focus on one or [00:13:38] the other. I wonder if you can kind of like give us a little insight on that. Maybe tell us a little bit about one of the examples or kind of um share with us what that looks like for you. >> There's been there's a there's a set of test room development proponents that have always said that to say to basically you you and that's one of the toggle things of like red green refactor. you're either changing the test or you're changing the code and and you don't change both at the same time, but you do get into a that the issue is you get into a state where things don't work. You're always there's like if you change the test, it's going to break and that's the red part and if you change the code, it's going to break and that's the green part, but or it's going to you're going to fix it and then hopefully it'll fix and then it's green. [00:14:22] But the the the toggling not doing both at the same time is the is one of the aspects that I bring that up because there's a lot of there's a lot of variations of test room development that do like with mocks and stuff and and stubbing that you really have to change both at the same time or it's going to break. Now, the higher level up in the API you go, the less chance you're going to have that you're going to have to do that because you're you it's like especially if you have an API that the customers are using, you're probably not going to like rearrange the parameters. You might and you'll but you call that like a major version change. So things happen you have to do and you can add adding things isn't so much of an issue [00:15:06] but the the the changes that you make. I mean it's it's having a test suite that you can trust that's at a high level so that you don't have to change it when you change your code allows you to do so many fun things. You can just go you know you can be in the shower at night and go that that algorithm just like is weird and I don't understand it. I'm just going to try rewriting it. And you can just like delete it and or you can try to fix it. see if it you know it's prettier and to see if and run the test and see if it works. If it doesn't you can just what get revert. The the hard part of having tests really tied to the the structure of the code is that if there's a test that that like I want all the tests to be something that if it [00:15:49] breaks I'm not going to ship the code. If if the test can break just because I refactored something but the functionality of the system's still great that's not a good indicator. And that's one of the the uh there was an interview with I actually kind of like Kent Beck. He's he's a weirdo, but I like him. And one of the things he said in an interview was we want our tests to be like you can imagine all of the different permutations of like letters in a in a in some code. And some of them will be workable software and some of them will actually be workable software that you that you'd actually be proud of. And we want tests to be the ones that eliminate the bad stuff and just keep the good ones. And so there's a like and if we really if we had that if [00:16:33] we had an API that's so high that's not even language specific like a REST API or something [snorts] we could rewrite the entire thing in a different language. I could go from Python to to Node or something and ideally the test would wouldn't care about the implementation. Now I don't I and I actually often test at this high level usually not rest APIs but because I'm I'm in embedded systems but I the the API that we do call the instrument with is a language agnostic API and that even though we're not going to change languages we often take something that's in software and make it faster in hardware or take something in hardware but the hardware piece is like going out of date or our vendors freaking out so [00:17:18] we change it to an FPJ. J or something. And these systems are like decades old. Like we we've been using this codebase for a long time and uh some of it we don't want to go back and retest everything. These that would be ridiculous. So we we want the test to be solid. >> It kind of makes me think like sometimes testing at least this like sort of automated testing is used for things that it wasn't really designed for. The way you describe it in the book is this check. Does it work? You know, what what does working mean and does it work? And I've come across tests where they're testing for performance. You know, we have like and some of these are the most annoying things in, you know, [00:18:02] in some CI I've seen like query counters, you know, does your does your implementation increase or decrease the query count on this table or this database cluster, you know, and and the intention is good, right? It's like we don't want to overload overload the database with too many queries. You know, are you introducing something that's going to 100x the query count? Like please don't do that. Save our databases. We're going to like put this test in place to help you. But does that answer the question, does it work? Not really. or you know what what kind of makes me think of with the unit tests is I feel like the way I've I've heard sort of the origination story described I guess with like pair programming and [00:18:47] then I feel like along with that comes the testing is a bit of this taste like the software taste like okay you you wrote it but like did you write it well and then it's like well what what is what is well-implemented software like and you really can't write a unit test for that, you know, that's >> And also, do you remember when we car it was like just a couple years ago when we cared about like that the code was written well? I love that. But the that like lots of people are proud of code that they can't read uh because of the I don't know the AI wrote it. It works. So, actually, I don't pro I don't think that that's a good idea. I treat the AI stuff like an intern or a new hire that [00:19:30] I'm gonna I'm gonna read the code um because I have to maintain it and and I think everybody should because the the the excuse that oh well I can have an AI support it. Well next year's model might not understand last year's model's code I guess. I don't know. I just I think that I should read it. But if you don't that's fine. I guess it's fine. But you're going to want to test to make sure that it works. And and that's kind of where I'm that's why I introduced the book now. I've actually wanted to write this book for like 20 years. But I think people are ready to listen that highle tests are important because especially for people that aren't even looking at the low-level code. Are they really going to write the unit tests and then have an agent run it? I don't think [00:20:13] so. Simon Willis proposes using and I think a lot of people do proposes using a thing called just having that the agent use red green refactor just telling it to do TDD and I have I have I haven't really thoroughly tried this out to see if it writes decent unit tests but I have had experience where I already have a good set of tests and an agent will augment those and add to it and I'm like oh yeah that's a good one. Sometimes I delete them because it's got like got like customer data in it or something like that. I'm like, "Yeah, don't do that." And I actually think it's fine to have style. I I like it when I look at some code and I go, "Oh, I can tell tell that like Jack wrote that because that's kind of his thing." And I it's it's a group ownership of the code, but it's fine to have style. I [00:20:58] think uh and also we if you don't understand it now, you can just ask your agent to describe a function for you. So >> yeah, it's all right. >> Yeah. I think on the AI side, I feel like I've seen a lot of like pre-baked harnesses and stuff that use the TDD frameworks now and I feel like almost now they do it too well where they add too many tests and I find myself having to like refactor the tests almost more than the actual code that is being changed because they just keep adding more and more and more and more and more tests and like they sometimes they're going to be testing the same things or you know testing contradictory things or anything like that. So I feel like it's it's still very valid to have to learn about about how tests should be written [00:21:40] and you know about how your software works from that perspective if nothing else than like not wanting to wait hours for your CI to finish. >> You can also throw away tests. That's fine if if you don't think that they're valuable. Like one of the common things I was talking with a Django developer and he said often he'll start like doesn't I don't know where to start. So, I'll start in a like a small area and I'll write tests around that and then I'll I'll go to like the larger area with the database and write tests to make sure that works and then I'll go through with like the user interface and then write some playright tests to make sure it works through that that that system and and when I was talking to him he was one of the early readers of the book and he said one of the things I never thought about is those those previous iterations of the tests I don't need to keep those around because if [00:22:25] they break I'm not going to fix anything that because the highle test still passes. is if the little one breaks, I'm just going to delete it. So once I write a larger level test for something, I can just throw away the older one. And we can do that with agent test, too. If if an agent feels like it wants to do that, or more likely, it really wants to have tests so that it can bill you for tokens, you can you can delete those afterwards if they're not helpful. But I I also I I actually have one I don't have very many rules with agents cuz I I don't know. seems like they should if they work right, they should just get what I say. But but one of the rules is put the unit test or the put the test at the highest level that makes sense for this job. And in the old thing like so a [00:23:10] lot of the things of like well big tests are slow and unit tests are fast really like that's from like the '9s. Stuff is fast now. We got fast computers with lots of memory and I run a whole bunch of stuff off of a 2019 laptop. Um, and yeah, it was a MacBook Pro, but it's from 2019. And it's still I never like I never think, oh, the suite's too slow uh for small stuff for like for big stuff with hardware. Of course, it's going to be slow. But a lot of that's a that's another thing is you got to get around is a lot of the unit test driven develop the test-driven development people will often say your tests have to be super blazing fast because there was this idea that if they weren't fast people weren't [00:23:53] going to run them because they were running them on their computer. We don't run them all on our computer anymore. or I run I run like my components tests on my computer and then I push the code up and do a merge request and then some magical thing goes and like tests all of my code and uh and it runs the whole suite and if it runs for 5 minutes I don't care. I'll get a I'll get a ding in 5 minutes that says there's a code error and I'll like interrupt my coffee break and go fix it. What you just said about deleting tests makes a lot of sense with the lean mentality too where you talk about what waste is. Lean is the opposite of wasteful and you talk about waste means wasted time. Wasted code. Code that's outdated or not needed [00:24:38] anymore. That's taking up space in your repository is by definition waste. cuz if it breaks, someone has to fix it or decide to delete it later on down the line. So, yeah, that that makes a lot of sense in that in that kind of philosophy. >> I'm glad you bring that up because that's the other part of lean is that I I stole the lean from the idea of the the lean movement and lean manufacturing, but primarily I learned about that through the a book called lean software development. And it's again, it's it's like Kent. It's great. is a little weird though, but it's a it's the the first like especially the first half like the first lean software development the first part of it talks [00:25:20] about lean principles [snorts] and then the the but the like the last twothirds of the book are like some examples of how you might implement those principles as practices and my first reading of that way back in the day was some of the practices are weird and it's like well they're just writing different test they were writing different kinds of software than I So they might not apply, but the the principles are good. And so that's another thing I wanted to do with the lean TDD book is to introduce more people to those concepts of lean because we don't usually talk about that in software of of that. I mean, we kind of sometimes do like like uh the the source code that we're shipping, we if somebody [00:26:05] says, "Oh, that's 100 lines of code. I can implement that in 20." That seems great, right? But if somebody says, "Oh, I got 20 tests for that." And somebody else says, "Oh, I've got a thousand tests." You would be impressed with the thousand. It's like, but I wouldn't I wouldn't be impressed with somebody with like 20x larger source code size. So why why am I impressed with larger numbers of tests? >> Yeah, I'm not. I I think smaller is good. >> And number of lines of code is very much oversimplifying it. you mentioned like you have to take into account all these different aspects how you know maybe the 10 lines of code is harder to understand than the 20 lines of code. So then you're wasting some future engineers [00:26:49] time to try to understand and like think through what it even means or maybe how it connects. The one one of the things that I it doesn't happen with all projects but there is a division of labor that sometimes goes on and it's different in different different industries and different countries but in my experience there was a stigma around test engineer that it wasn't a it was not as an advanced person as a software engineer and and so because of that and often it was reinforced by the company with pay scales which is awful. I think a really great test engineer is a really great software [00:27:32] engineer that also is good at writing tests and also is good at communicating with a broad sense of people can understand vagueness. Basically manager skills and an awesome software engineer and a pragmatic thinker. This doesn't seem like less skilled than a software engineer. It seems like more. But nonetheless, there is a stigma. So there are some companies where software engineers are going to not want to write the system level tests because it's not their responsibility and and some also so there's some some uh push back from software engineers about writing system tests of like well it'll test other people's code too and I don't care about that. Well you should they're it's paying your salary. The the other end of it is do test engineers like worry about software engineers writing tests? They [00:28:14] want them to write unit tests but do they want them to write system tests? Some might be afraid of that because of like job security thing, but the reality is is is there's tons to test. And so that model I do want to bring up because I think it's safe for both cuz a a really great thing to do I think is to have have the software engineer be involved even if we have a test engineer writing a lot of the system tests. we can still get software engineers writing them because we want them to be able to read it because when the test fails in CI, we want this the developer to be able to debug it and run it locally, debug it and figure out what's wrong and not have to toss it over to a test engineer to to interpret for them or gather logs or something dumb. They could do it themselves. The other aspect [00:28:58] of it is I'm a software engineer, too, and I like to like I like the functionality part. I I'm I'm fine with testing like making sure that the functionality works and testing that the things like you said of like timing tests of does it did it slow down is it sec is the security testing is a thing we have to do especially now there's how much database use the memory usage there's all sorts of stuff you can test and also corner cases well what if does the user interface handle like all of the language model languages of the world that go into it or the sizes of names or all this sort of wacky stuff. Those are great things to extend. So I really like to have a like a straight through line. I talk about it in the [00:29:40] book of a a skeleton design of like build the skeleton of the system, the skeleton of the tests and then build out. And that's a great way to hand off. So initial development of a feature developers can work on that. They think it's pretty good. They hand it off and then a test engineer also can like be working on that also, but then can continue and add the corner cases, add the timing cases, add the add the extra security stuff, all the extra stuff that has to be done. There's not we're not running out of things to test. We got tons to test and our our systems are even just becoming more complex and also just maintaining the test system itself, maintaining CI. There's plenty to do, but it's all thinking. Like you said, I don't want people to go on autopilot. [00:30:23] And I think people need to be a we weary of that. Don't don't wish that your job was autopilot because all the autopilot jobs are going to go away. We need people to think and if you're not thinking in your job, you should you should be worried about AI. But if you are thinking, I don't think that people should be worried because there's plenty to do. >> Yeah. Yeah. I I think of a lot of that production level and state in best case scenario. I I typically try to think of that at the beginning too almost as an acceptance criteria consideration like it doesn't break other areas of the system and you know it doesn't have a certain level of performance regression for this experience like those are all [00:31:08] you talk about acceptance criteria for the features itself knowing how it works for the user but yeah and and again that's not something you can necessarily write a test for, but I don't know kind of what you were talking about with everyone's responsibility ultimately. Usually it's the engineer who's on call. It's usually not the test engineer who's on call, but everyone's everyone's working together to make sure that this works. No matter who writes the code, who writes the tests, who does the testing, you know, it kind of doesn't matter at the end of the day. The point is that it's all working as it's meant to in the in the deployed version. Yeah. And if you start caring about all the pieces more, like if you care about the [00:31:51] test, you care about the CI, you care about everything, it's all there. The effective use, think about the the one of the things I like about lean is is everything. If like start thinking about your meetings, does it need to be a half an hour? Can be 25 minutes. I mean, even if you cut it down for by 10 minutes, gives everybody 10 minutes back to their day. Things like that are important. and and just the more you think about the whole team and the whole codebase, it's going to benefit your career, I hope. And if it doesn't, get another job because it should. The Can I Can we break out a little bit because I want to talk about a little bit about the the meta aspect of of writing this book and audio book at the same time? >> Yeah, sure. We'd love to hear it. >> Is that okay? The one of the things I [00:32:34] did with this book is it's self-published, but I mostly did it cuz I was kind of afraid that I like a couple things. I was I was worried that it was too small because it's only 100 pages. But I also didn't I wanted to have it be like what my what I was proud of. The first book I wrote about Piest was through Pragmatic and I really like working with Pragmat. It's a great company, but but there are some like limitations of like, well, it should be large and you should add an example and things like that. And I wanted this to be tight, small, something that you could throw in your your carry-on bag at a on an airplane and have it read by the time you get where you're going. But the the other thing I wanted to do was do an try an audio book. And I I wasn't sure that I was able to get able to do it cuz [00:33:17] I never done an audio book before. But I really enjoyed that process of getting the book to where I thought it was good and then reading it while I was recording it. And I didn't release the entire book until after I read it because there were so many places where I would read a paragraph and go, "Wow, that just sounds pompous and idiotic. I can't I can't say that out loud." And or I was sometimes I was too mean. I was like making fun of other other like stuff. But everybody that does different test designs and stuff, they're just trying to make software better for everybody. They're not jerks. So, I I toned it toned the like snark down a little bit. And and I think that I think that more technical books should be [00:33:59] small because if you're writing a book, I I still think books are powerful because you can jump in and do a long form thinking about the whole thing. But I like really like the idea of recording it as an audio book. Even if you don't release it as an audio book, you should be able to read it out loud to somebody and then change it that way and not just in your head cuz I I thought I already did that. I thought I would the whole process since I was intending to do an audio book. Anyway, I'm just saying I think more people should do techbooks as audiobooks because I don't really read books that much anymore. I listen to audio I listen to audio books but you know that >> yeah I definitely enjoyed the audiobook version and I wonder if that approach can even help in in the software [00:34:41] development life cycle of reading your acceptance criteria or your test descriptions out loud to see if they they make sense. >> It's a it's a bummer that the term acceptance criteria is what we have. It just sounds so formal. It's all it is is like a thing of like your software should do this. It should like a calculator should add two numbers. That's one of the acceptance criteria. But [snorts] acceptance criteria seems so formal. >> Yeah. >> But anyway, >> I agree. I I I don't know. Do you have a better name for it? >> No, that I would have I would have put it in the book if I had a better name. I also So our our company is is trying to do a version of it of the I talk about acceptance test driven development in the book and that's something our [00:35:24] company is is is been working on and I've been heavily involved. Another reason why I wrote the book is so I can hand it out to people instead of describing all the backstory. I'm like just read this. >> Thanks for sharing. [snorts] Um well with that we're going to move on to our fun segment and uh we know that agile is about eliminating waste but you know if you could be wasteful about something in the software development life cycle what would it be and why? >> If I could be wasteful. Okay. Do do I have to go first? >> You can if you want to. We usually let the guest go last. >> I'll go last then. >> Okay. Well, I can go first. This is maybe arguably not wasteful, but I do [00:36:08] really enjoy having like off sites or like, you know, sort of inerson meetups every once in a while. >> Yes. >> Not, you know, not to the extent where I'm like going to happy hour every day or whatever. Like that's exhausting. I'm not into that. But like once a month, once a quarter, like if I'm going to spend some extra cash, like get us a nice dinner, you know, just kind of give us a good time every once in a while and and I feel like that goes a long way for me. Yeah. Well, I love that. I didn't even consider that as part of the software development life cycle when I was reading this earlier. So, I would change my answer to that if that's the option. But otherwise, I think uh one of the parts that I enjoy the most, I think, is planning what thing [00:36:53] something's going to be. So, like, you know, planning in advance, like, oh, okay, here's the classes we're going to make or here's the, you know, the changes that we're going to make. Um, so that's probably where I enjoy being the most wasteful. And I probably do waste actually quite a bit of time, more time doing that than I need to and bike shedding things far more than I actually need to. Yeah. So, that's probably mine. I guess I have one more like silly answer to this. If I could get a 3D printer and like 3D print some like technical diagrams, I would also definitely do that. I just think that would be really fun to like either have like very artistic diagrams or like 3D printed models of how the system works. >> Yeah. Literal building blocks. >> Yeah. [00:37:34] >> Remember when people doing their like uh 3D printed uh GitHub history? >> Yeah. I I don't know if that's a thing anymore, but that was funny. >> Yeah, I think the website still exists. You can make like a little city skyline. >> Did you ever did you ever finish your your off of your commit history, Britney? >> It's so big. [laughter] >> It's like a king-size blanket. So, no. I'm halfway through it. And now I don't even work at GitHub anymore. So, I'm like, is this even as much fun to do as it was before? The website's still up, though. If anybody wants to go to commit graphan.com and get your commit graphan >> commit graph gan. That's great. >> I'll I'll do a tea cozy of the last week [00:38:16] of commits. How about that? >> There you go. That's the perfect way to do it. Yep. >> Good. >> Well, you could do like a scarf, like a a scarf, and then it just could be continual and then >> Yeah, I think that's the way to do it. Don't try to make a full blanket. It It will take you a year. What about you, Brian? What's your what's your favorite way to waste your time while building? >> Well, actually, so the the I I I was having trouble, but the off-site thing reminded me of early in my career. So, like, you know, when the the dot thing was going on in the '90s, that's when I got hired first. And one of the things that was cool that HP did, actually, HP was a great place to work in the '90s. And it I was in Santa Rosa, California. And one time it actually happened quite [00:38:59] a bit. Like there would just be a little bit larger quarter than they were expecting. And so they would like we'd hear about it at like maybe 9:00 night 9:30 or 10 in the morning. There'd be an announcement that says, "Hey, quarter quarter earnings is pretty good. We're going to do a barbecue." So at lunch they would just do there'd be like burgers and hot dogs and sodas and beers and stuff like that just out on the in the right outside the cafeteria in this area just and that's that's totally cheap compared to how much money is going through there. But it was cool to just say to have that experience of yeah it's good uh we're doing good. Let's have some some something some extra. I know standups. So, I don't have my own team right now, but I had a team working [00:39:42] for me for like 12 years or something. And we had to do these stand-ups, especially through co and then we just kept it up. But the whole like try to keep it to 10 minutes sort of thing, you know, that that quick thing. I thought it was terrible because it was often the only time that my team talked with each other and we would talk for tactical things of like, hey, can you fix this or whatever, but I dedicated half of the meeting to catching up on everybody just personally. How was your like, hey Jeeoff, you were going to go hiking this weekend. How'd that go? Or how was your vacation? Or anything cool? People would even show off like cool electronics that they bought or whatever. and and just that that personal connection. I don't I [00:40:25] think you can't measure it, but I think it's important even if you're in a remote team to try to capture that still. >> Yeah, for sure. Well, great. Thank you so much for joining us. Where can folks find you on the internet? >> Well, that's changing, but pythonest.com is the best place. So, you can find me there. It's all one word. And uh I was going to like sunset that and switch to another blog, but let's face it, I'm the test person. I like I write about testing and I'm mostly testing Python. So I've had that blog for a long time. So you can find me there and links to everything else. There's courses. Uh leanTdd.com is the book, but you can find that from a great big giant thing on pythonest.com also. But yeah, I'd [00:41:09] love to get feedback. And I also want this this book to be accessible to everybody. So, it is only through Amazon right now and Audible. So, you can do Amazon and Audible, but I tried the whole 90-day thing. So, I got to wait until November to open it up to other places. So, in November, it'll open up to more people. But yeah, that's me. Well, thanks. >> Well, thank you listeners [music] so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast app of your choice. Check us out on Blue Sky and share with your friends. Until next week. Goodbye., Lean TDD With Brian Okken, Overcommitted, 01m37b0zhrfn7p4btr72mv5yf9.