#13 JB Rainsberger on what it means to truly be agile
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:00
This is developer's journey. My name is Tim Bourguignon. Thanks for joining.
JB Rainsberger 0:09
And we're alive. I'm thrilled tonight to have you, JB on the line. Hi, David. Hello, how you doing? Pretty good. Pretty good. How about you? reasonably well, yes. Recently? Well, oh, I hope the conversation will will go very fine. And then you will be much as reasonably well, but very well, it I'm sure people will be able to tell the difference in my energy by the end. I sure hope so. I sure hope so. This is a gorgeous discussion, I am thrilled to have you on the line. The first contact I had with you was through your talk at aura def 2013, I think it was this seven minutes and 26 seconds and the fundamental theorem of Agile software development. Not just because I sewed at the end, you're completely nuts. Going on the stage and saying I'm going to speak for exactly seven minutes and 26 seconds, and not just saying it but also doing it. Um, but the What you said was really was really, really interesting and, and drove home. For me, really, getting XP in a jail together was really was really a thing that struck me back then. I really encourage anybody who hasn't seen this video yet. To see to watch it. That's really great. So you were in the DJI coach, right. I so I have, I have spent some time doing some things that many people would label as agile coach, I guess. And I know that maybe for some people, this isn't. This isn't such a nice term. But I like to think that I'm kind of a one of the things I do is, is agile leaning coaching in the best sense of the term. Hmm. So mix and matching, not just the dial, but something else in there? Well, I think this is this is one of the key things that makes, I think one of the things that makes the Agile coaching term a little bit that makes people skeptical of it, is that of course, like any popular idea, a bunch of people decide that there's an opportunity to make money. And the market has a tendency to be quite efficient. And so you have a bunch of people who are trying like anybody else to make the most money with the least effort. And so you end up with a lot of lowest common denominator. Maybe not even barely sufficient, but not quite barely sufficient work that people label as agile coaching, in order to sell it just the same way that one of the one of the problems with the popularity of Agile software development is a lot of people want to be seen doing it. And so as a result, they take whatever it is that they already do, they you know, replace a few words with a few agile sounding words. And, and then say we do agile or I teach agile or whatever. And so one of the things that I try to do is to really go back to what are the what are the fundamental ideas underneath Agile software development, and talk more and teach more about those. And if the result is that somebody does something that an outside observer would think of as agile? I guess that's okay. But I don't really care that much. What I care is that it gives them better results or not.
Tim Bourguignon 3:48
Okay, um, you can do have devloping that,
JB Rainsberger 3:52
yes, those values you're talking about? Yeah, so well, so values is a good word. Because one of the one of the very early one of the very earliest, early things from extreme programming was a focus on at the time, the four values. You know, simplicity, communication, courage and feedback. And I think part of the idea was to articulate those values, and really encourage people to treat them, like the fundamental building blocks of everything else they did. So all the practices, all the ideas, the techniques, the principles all came from there. And, and so if you didn't know what to do, or you try to follow the rules, and that didn't feel right, or you tried to follow the rules, and the environment you were in was a bit hostile to those rules, then you could go back to those values and ask, okay, well, what is something simple I could do or what is something that I could do to improve communication? What is something I could do? One of my favorites is related to feedback. So one of the things that I think makes agile Development fundamentally different from what other? What people? What other things people have done is what do we do when we're not? What do we do in the face of uncertainty? What do we do when we're not sure what's happening. And I think that that situation, broadly speaking, splits people into two groups, one group of people, whenever they get bad results, or they're unsure what to do next, or they see mistakes, or they have a failure, or whatever it is, go into the corner, think very hard for a very long time, until they come up with the perfect plan or even a very good plan, and then try to execute on that plan.
And the other group of people
says, Well, if I'm not sure what to do, then I better do something, see what the results are, evaluate how much I want those results, and adjust my behavior accordingly. The first group of people are attracted to any kind of very orderly approach to software development, like waterfall or any of this somewhat traditional approaches. They're also attracted to things like the surgical team approach, or the certain the surgical team model for programming teams, where you have an architect or a senior programmer who does all the thinking draws all the diagrams, and the code monkeys who write the code. And I, you know, I don't want to say that these ideas are terrible, because there are some situations in which it probably is a good idea for the one person who knows what's going on to make all the decisions, while the other people carry it out. I'm not sure that that situation is sustainable over the long term. But certainly in some situations. Sometimes you're forced to work with people who maybe aren't ready to make those decisions on their own, they need to learn some fundamental things before they can start to take on those decisions. The difficulty or the mistake often comes when we fool ourselves into thinking that the surgical team is sustainable, and always needs to say that way that the lead surgeon should always make all the decisions, and that everybody else should always just follow. I hope that at some point, at least one member of the team eventually starts to emerge as a potential new lead surgeon, or head chef, or whatever. Otherwise, you're in trouble. And so there, there's a bunch of people who are attracted to that model and a bunch of people who are attracted to the more experimental you know, inspect and adapt, adapt over time kind of model. And that's an To me, that's what makes Agile software development agile and not something else. And so one of the basic ideas or techniques that you can use that I don't even remember where I learned it for the first time, probably in probably in one of the first book books by the pop index. The agile managers toolkit, I think, lean software development, agile managers toolkit from about 10 years ago. If you feel like you're not getting feedback, if you feel like the feedback that you're getting is consistently telling you to to rework something, then that probably tells you that you're not getting feedback early enough. So whatever feedback cycle you have, shorten it. Now, of course, the problem is, if you have, for example, a team that's used to releasing software every six months or a year, and you tell them right, starting today, we're going to release software to real customers, every two weeks, probably those people will panic. So that might not be the most effective way to proceed. But it might be okay to try to cut that feedback cycle in half. And the idea behind cutting the feedback cycle in half, is it probably forces you to change one or two significant things about the way you work? But it doesn't seem impossible, it seems like something you can achieve, it seems like something you can do. And so you cut your feedback cycle in half, that allows you to continue doing a bunch of things that are familiar, but forces you to change one or two things, gives you a little bit of a challenge gives you sort of that. You know that barely the challenge that's just barely out of your reach the challenge that makes you work a little bit hard, but not too hard. That sounds maybe for a moment sounds like it's not achievable. But after you probably spend a couple of days thinking about it, you start to see how you could get there. And so then once you get comfortable with that feedback cycle, then you start to notice that okay, it's better than it was before but we still notice that we have to do a fair amount of rework not as As much as we used to, but still some, maybe the rework that we do now becomes more annoying because we see how much better things can be. So then we say, Okay, guys, I think it's time for us to try to cut our feedback cycle in half again. And now we're all we're most of us, I'm sure listening are programmers, we know where this is going binary searches fast. Know, what you're more or less doing is using binary search to find the natural feedback cycle that fits you and the people around you and the context that you're in. So you keep fighting your feedback cycle in half, and then letting it become comfortable. And then doing it again and letting it become comfortable. And you keep going until
the feedback is maybe too much until you realize that getting more feedback is not actually helpful, then stop. Go on to the next thing. So this isn't, this is not something that you read. As far as I know, I don't remember reading this in any of the standard extreme programming or Scrum books. I've never heard anyone say it exactly that way. Pick a feedback cycle, cut it in half, let yourself get comfortable loop until the board.
But
we have seen in certainly in extreme programming explained the idea that the value of getting feedback sooner. We've seen it in lean software development, you know, value streams, bottlenecks, Theory of Constraints, all that stuff. And so just go back to one of the values of extreme programming feedback. We believe that feedback sooner helps us converge towards good solutions to whatever problems we have. And so it seems to me an approach like that is a hell of a lot more agile than anything that you see in any Scrum textbook in any scrum master course, in the extreme programming books in this following this rule that rule, whatever. Now, what kind of feedback are we talking about, and what techniques will help us get feedback more often, that could be test driven development, it could be testers programming, it could be automated acceptance tests, it could be planning more often it could be, you know, going to the customer more often, it could be any of those things. And those become the techniques that are familiar to us. From Scrum, XP, any of the Agile Software, tech, schools of thought, but the underlying principle of we see that we have lots of rework, we hear a lot of things like That's not what I meant, that's not what I wanted. That's not what I was hoping for. We have all this rework, well, let's get feedback more often. And then maybe we will find these things more often. And the rework will be less painful. And we'll do less of it and will converge to good solutions sooner. Sounds like a reasonable thing. So this is, this is one of those ways that I like to teach. The ideas in Agile software development, that I hope makes some of the rules and techniques
more intuitive or more,
what's the word I'm looking for? that make them sound less artificial, that make them more pragmatic and more more concrete? That's something like test driven development or test first programming is a way to, you know, get feedback sooner in the conversation you have with your code and with your design, rather than that you do. It's also turning the tables around. So you can it's quite a silver bullet, actually, you can just tell someone, well, we have to, if you agree, we have to cut the feedback in half. And other cutter decide the cycle in half. And then whatever mean, comes to mind is actually Okay, so you're not giving an idea or giving a solution and asking for the person to enter to to implement it. You're just saying, well, we should do this, this is this the endpoint we want to come to. And now you can come with an idea and come with someone of officers solution and you implement it yourself. So it's your decision is your technique. It's what you decide. And people tend to agree with that and tend to to to adhere to it. Way more easily, don't you think? Absolutely. So in, you know, to go back to your original question, or two, the idea of me as an agile coach. I like to think that an idea like that is sort of at the same time, it's actually agile and actually coaching. Because as you say, it's not it's not me saying, Oh, I see what's going on. You guys should really test driven development. It's okay, here's a problem you have where you're finding somebody thing out, when it feels like it's too late to do something about it, or where you think, wow, you know, I really wish we had heard that sooner. Okay, well, that sounds like a feedback problem, I have this stupid little trick. Cut your feedback cycle in half, what will we have to do in order to get that feedback in two weeks instead of a month? And then exactly as you say, let them think about the people who are actually doing the work who are responsible for the results after I leave. They not only do they come up with the idea themselves, maybe they come back to me and say, well, we think we might need this kind of feedback sooner, we're not really sure how to do that, can you give us some ideas, but at least now they're trying to solve the problem, instead of just downloading a bunch of rules from an instructor and following them. And maybe never really understanding the reasons or feeling like they, like they own the results. It's very easy for me to just come in and say, you should do TDD because I've been hired to teach TDD. And that's what I'm going to do. And your manager said, you should be doing TDD. And then I can teach them for three days, and then I walk away, and I count my money, and nothing really changes for them. In fact, one of the things that really bothers me about the cynical form of so called agile so called coaching, is, and I know, let me be frank, I've done a lot of that I've done a lot of terrible, so called nonsense, coaching, I, you know, I wish people I hope people can really hear the quotation marks around coaching, as I say it right. Where I go in, I teach something, even maybe if I get to go back every few weeks, or stay there for a while, what I see happen, what I've seen happen, and I know a lot of my friends have the same problem. After a few months,
maybe 10, or 20% of the people they work with, get frustrated, because they start applying the techniques that they're learning to their own work. And they're seeing results. But pretty quickly, they start to see that not a lot of people around them are seeing the same results, maybe because they don't care, maybe because they don't get it maybe because they're afraid it could be 1000 reasons. But they start to see the gap between their performance and the performance of the people around them get wider and wider and wider, they start to see that there's so much potential for the situation to really improve. But the people around them are don't commit to improving it again, maybe because they don't care, maybe because they're afraid maybe because there are bigger constraints that nobody knows how to deal with. You know, Corporation SIRs are sociopathic. So that's like a reasonable result. And, and just, I know what happened to me, again, I hear it a lot from people that I've coached, and from people that are peers of mine, who just look around and say, nobody here gets it, nobody here is gonna get it, I'm getting frustrated. Now I'm gonna leave. And it's just a matter of time, as soon as I can find a place where it looks like maybe people are going to get it are going to understand are going to think more like me who are going to have more courage to do things, there's another one of the values, I'll go there. And so I worry that a lot of the kind of work that I and my peers do, really just hurts the client, it results in driving their best people away, making them very frustrated very quickly. And then they're left with a bunch of people who don't have quite the same motivation to improve don't have quite the same interest in changing things. And somewhere near the top of the organization chart is a person who expected transformational results. And instead, they see an exodus of their best people, and they don't know what the hell happened. And I've been gone now for three months, six months a year. The good news is they probably don't attribute the results to try interference, which is good for me. Or they do and then they never talk to me again. And we miss out on an opportunity to really make things better. And part of the problem is the fundamental difference in values between Agile software development and traditional business. And part of it is this sort of either cynical or well meaning but not very effective. Agile coaching. But you've been in the business for quite a while now. You were in the early early 2000s already on the on the adult bandwagon, right? Um, have you seen this change through the years? I mean, it's been 16 years now. Yeah. So there's there are pockets, it seems of people who are really who are doing well with this idea. I mean, something like lean startup, lean startup is just extreme business development. I mean, I don't mean to say just like, own like, it's not a big deal. But Lean Startup really seems to me like a natural extension of what we were talking about 15 years ago, taking one step farther in front of the, you know, in applying it to what happens before we sit down and say, Okay, here are the features we're going to work on, let's slice them, let's start writing code. But, you know, all that stuff really seems to me like, you know, like I say, you could call it extreme business development, you could call it extreme product exploration, you could call it agile as if you meant it, you could call it or you could call it just call it Extreme Programming. It's, it's a natural extension of what we had in mind. And so, but of course, lean startup goes through because it acquired a brand and popularity, then it starts to the same natural cycle that agile went through that Scrum has gone through, where again, you have a bunch of people who cynically are making trying to make money off the idea, and are trying to therefore say that they do lean startup, even if they're really not doing a lot of what the ideas are meant to convey. So the good news is that entrepreneurs are more entrepreneurs, who are forced by their nature by the nature of being entrepreneurs. And by having small businesses, they're forced to use the lean agile ideas more faithfully, we're more intentionally more
seriously, they're forced to take themselves more seriously as businesses and to do these things. And they recognize that things like frequent feedback, and you know, courageous experimentation, they can't survive without that stuff. That's one thing that I kept saying over and over again, and a bunch of the people, if you go back to the old, old, old posts in the extreme programming Yahoo group, you know, a lot of us really complained about the fact that we were all working in these big enterprise contexts where everybody could afford to make all kinds of mistakes, and therefore nobody had to take any of this stuff seriously. And it seemed like the most common pattern to really see transformation was to wait until a real crisis happens, and then step in and say, I think I have something that can help us get out of this. And because there was a real crisis, because people had nothing left to lose, they were willing to try this really counterintuitive ideas, that were a big departure from what they from business as usual. And I think that's, you know, today's entrepreneurs, it's never been easier to start a business on your own, it's never been easier to produce a product on your own. More people are trying it. And the ones who are surviving are doing more agile things. Now, they might not be doing test driven development, and they might not be doing continuous integration, but they are doing, you know, extreme, extreme marketing. They're doing, they're, they're, they're, you know, they're finding the simplest ways to hack tools together to get them the information they need to help them decide what even to try to build in the first place. They're, they're monitoring what they do, they're monitoring their product, their service, their their customer response more closely than ever. They're doing a lot of the things that seem extreme. And yet, the IBM's of the world are big enough that they just don't need to do that stuff. The big enterprises are still big enough that you know, what's the the old saying that they can't afford to do it well, but they can afford to do it again. And so they just keep they just keep doing it again, and throwing 100 people at it and hoping for the best and and set you know, you still get you still somehow get people who do horrible jobs getting promoted. You have you know, you arguably have people who drive this you have people who drive businesses into the ground because Being US presidential candidates, I mean, it's it, there's still a huge segment of, of the business world that are, they're just so big, they have so much money, they have so much slack that they don't have to get any of it right, they can afford to do kinds of things that look wrong. And, and enough of it works, maybe by accidents, that, that they succeed, or, and this is the part that really bothers me, the thing that I think is going to stop agile from becoming a serious thing
is that
when you go high enough, in the business world, in the financial world, the systems are simply not inherently lean or agile, they don't, they're not. And the people who are really succeeding in those systems don't, don't need it to be and don't want it to be.
And so
as certain size of business, trying to do what we think is a good way to run a business would actually cause failure. It would because, right, there are rules that they have to follow. Because when the business is big enough, there are just arbitrary rules they have to follow there's, there's a game that they have to play. And at that level, sensible behavior would actually be a mistake. And, you know, be being sociopathic, being bureaucratic, all those things, is actually what it takes to succeed. I remember I had a huge client, who worked in the you know, who was in the medical sector in the US, and trying to do a, an, you know, so called agile transition. And I found out years after I left, that, in fact, one of the key success factors for them had to do with securing government funding, and nothing to do with the effectiveness and efficiency of their business. And so then why would they take Why would they take it seriously, what what they might be able to tolerate the people on the ground playing agile, because shuts them up, because it gives them something to do and it makes them feel better, and it makes them feel more engaged. But you know that there's somebody high up on the organization chart, who just doesn't care about any of that stuff, because none of that has to do with schmoozing the right people in the right government organization to ensure that they get these pipeline of hundreds of millions of dollars to fund all these cute programmers, testers and business analysts and product owners playing scrub. And I don't care what they do if they if somehow by magic, some not. Terrible product comes out. I'm happy. That's good enough for me. Because I did my job. I got the $400 million in funding. And that's all I've done my job for two years. I don't have to do anything else. Yeah, none of that has anything to do with lean agile XP, any of that Scrum nonsense, I just don't care.
Tim Bourguignon 28:20
There's so much I would like to rebound on but
Tim Bourguignon 28:24
would you just say,
JB Rainsberger 28:25
Yes, go ahead. Good. Um, what you just said reminds me of the the I think it's the first chapter of the last book from Jeff Sutherland, the scrum, the art of doing twice the work and half the time, were described exactly that. An institution trying to secure funds, and then more funds, and then more funds and just waiting too long, but don't care it just security funds, then just go on. Again, again, I guess we're there on a sort of becoming at the risk of becoming political. And as a Canadian, you know, I have the right to to bad mouth, the US. It really is kind of this strange Donald Trump approach, that if you have enough money to start, it doesn't matter how bad you are just as long as you can figure out how not to get rid of all that money, it's fine. And you can make a whole you can make a whole bunch of mistakes and do a couple things, right? And, and because you have such a headstart, it doesn't matter, you never lose your place. And that's awfully frustrating for the rest of us. who aren't Donald Trump, who didn't have a million dollar headstart or you know, who, who didn't have those advantages? We can't afford to do that. So we're the ones who actually have to pay attention to what we're doing. We're the ones who have to scrape by and take a more bootstrapping, incremental, you know, slowly compound our advantages kind of approach. And so we're the ones who would take, inspect and adapt seriously and we're the ones who would take frequent feedback and simplicity seriously because we have In a way, that somebody who already has $2.7 billion just doesn't need to do. So that brings me to one of the questions that you you in one of the things that I know that you care about is, what does this mean for the people listening, because I don't, I sure don't want the people listening to then say, right, well, then it doesn't matter what I do, I'm going to go back to bed. So here's, here's the only thing that makes this kind of liberating. The good news is that, especially if you find yourself in one of these big enterprise contexts, then at a certain level, nobody actually cares what you do, which means you have the freedom to do whatever you want. And do it for yourself. One of the things that I you know, especially if I'm working with big enterprise clients, once I start to get to know a team, within a huge enterprise context, we almost always have this conversation. I sit them down, I say, guys, I know you're frustrated, because you're trying to do all this really good work, you're trying to do test driven development, you're trying to engage your customer, it's not working, you're trying to do continuous deployment. And you're having trouble getting past the Build Team or getting past, you know, while you're trying to do continuous delivery, the organization is putting together an operations team. And those two ideas just don't mix. I know that you're frustrated, because it seems like the people around you don't get it. So I'm going to recommend that you do this, everybody looking everybody else. Everybody who's interested in trying to use these agile Scrum XP lean ideas, to help you enjoy your job more, everybody who's in everybody who wants to do that. Let's work together as a team. And let's figure out how to get the most out of our work to make ourselves happy. And I don't care what happens to the rest of the organization, I don't care if it delivers wonderful results, three levels up the organization chart to some Vice President, I only care about you guys doing what it takes to figure out how to enjoy your job more how to whether that means doing better work, whether that means you know, collaborating more often, whether that means better. And you know, if you guys really care about understanding the products that you're building, and the marketing behind it, and the sales that goes along with it, then I want you guys to go and engage the marketing departments, or the product champions, or whoever they are. And if you really want to become awesome programmers, then let's focus on technical excellence and learning design through practicing test driven development. And I'll teach you guys how to practice in a meaningful, mindful way. So that you can really accelerate your learning, whatever it is, that's going to make you feel better about the work that you're doing, let's do that. And the odds are good, that if you do that, the results to the rest of the organization are going to be better, and there's certainly not going to be worse.
And if that's the best you can do, well, that's fine in the worst case, and then I closed the door. And I speak a little bit more softly say, in the first case, four of you will learn a lot in the next two years, enough to go start your own little company. You know, raise it from a baby to a five year old and sell it back to these guys for 100 times what you invested in it. In the worst case, one of you is going to come back in five years as a consultant and charge five times the salary you're making now. And I'm okay with that result. I guess we're gonna leave it to that. That's great. That's a great, great insight. So maximize happiness, and just do it for yourself. That's great. If you if you're not going to, if you're not going to get better results, then that's not a bad result to get I know a lot of people would probably feel like that's selfish. But in an environment where nothing you do matters, in the grand scheme of things, it seems like one of the few rational approaches lest you ever even even though even if it is an environment where you're moving things, if you're completely unhappy, what's the point? Exactly, you're there, your energies guess just going to erode and erode and erode eventually, to the point where you have nothing left to give anyway. So you might as well and you might as well use these ideas to help you derive more satisfaction from the work that you're doing. And ultimately, that's what I end up you know, in a lot of cases, that's what I end up doing. That's why I teach test driven development. That's why I teach value driven product development, any of those kinds of things is to help people feel more intentional about the work that they're doing, and that they can feel better about it. And if they do, then they'll probably produce better results for whoever's paying the money. I'm sure they will. I'm sure they will. Well, we're reaching the end of the time. Books, we actually over it. Is there anything you would like to plug anything you're doing right now or you're going to be doing soon? Absolutely. So the big thing right now is still the world's best intro to test driven development, and Web TV TDD dot j brains.ca. That is my online self paced training course for people who want to learn high discipline test driven development. And I do emphasize high discipline. And even if you don't think you want to learn test driven development, if you want to learn to be better designers, practicing test driven development mindfully is one of the best techniques for deep practice in software design. So if you really want to find out what you know, understand what makes good software design, and what makes good software designers, it's a wonderful mechanism for learning that stuff that you can use alongside reading whatever books on design you like. And in 2016, I am planning to release two more courses. I it's just going to depend on whether the construction here in my recording studio is done in time for surviving legacy code. And maybe one other course i'm not sure yet which one it is, it could be surviving your agile transition, or it could be the world's best intro to TDD level two. Also, I am planning to come back to Europe later this year, I'm hoping to spend a few months temporarily living in Stockholm. So if you'd like, if you'd like to work with somebody with an exotic foreigner from Canada, without paying transatlantic flight prices, then I'm already in Europe, you can always contact me
through jetbrains.ca. And if you just want to ask me a question,
then go to ask jetbrains.ca. And it might take me a while to answer you. But I promise I will. Okay, sounds great. One question about your TDD course. Would you? Would you describe it as something parallel to the book you wrote? Was it j units? recipies? I think or something additional? or reading the book first and then doing the course? Or how would you suggest doing that the course of the book really have nothing to do with each other anymore. J unit recipe was a reference book for how to use j units. My my publisher told me very very, very clearly that I was not allowed to write a test driven development book that I needed to write a Jake book. So there's so in that book, there's a lot of if you're doing test driven development, it'll look like this. But if you're not exactly. So no, the the the world's best intro to TDD is completely separate. And it takes you pretty much from zero to, to becoming to knowing whether you want to learn more about test driven development after that. And so you can really get inside the thought process of someone who designs software using test driven development as the mechanism. It's sort of it's, in a way, as Michael Hill likes to talk about having a conversation with your code. It's me having a conversation with code and seeing how the various micro techniques and foundational principles of software design emerge from just trying to write the test first. Hmm. Well, sounds very great. I'll add all this to the show notes, for sure. Thank you very much for joining. That was great, great insights, great gems. There's so much I would like to ask, but I guess we're just gonna have to do this again, when you feel like your audience is has has had a chance to miss me. I'll take your word for it. We'll do this. All right. Well, thank you very much. All right. Have a great day. And I wish you a great trip to Europe.
Thanks very much.
Tim Bourguignon 39:12
Then talk to you soon. Yes, thank you very much. Bye, bye.
Tim Bourguignon 39:31
Well, my deaf journey just won a few more steps and I hope yours No, I'm sure yours did to send me a feedback you had to drill twice as fast as usual. Let's cut the feedback cycle in half. And don't forget to rate the podcast on iTunes and Stitcher. It would be great to help spread the word. Since we touched on the topic was JB rains burger. In this on the quote on a happiness quote from Steve Martin A Day Without sunshine is like you know, night good night