Uncle Bob: Why I Stopped Reading Code and Building Harnesses

0:00 Working hypothesis is that human beings are too slow when dealing with code. So, if we're going to move at the speed of the agents, we're all going to have to back off a little bit and maintain the high-level supervision, but at the level of code, that's probably out of our domain now. >> Hello everyone, and welcome to Hanger DX. This is a podcast about developer experience and how engineering teams solve productivity challenges. I'm your host Ankur Jain, co-founder of Aviator. Here we are building verification platforms for AI-generated code so that it creates guardrails and reduce slap. So, with that, I'm very excited to bring in my today's guest, Robert Martin. Everyone knows him as Uncle Bob and probably one of the most experienced people I've had on podcast, so I'm very excited to learn from Bob's, you know, almost 60 years of journey in software engineering and programming from, I guess, like all the way from assembly to where we are today.

1:00 >> Yeah. >> >> So, Bob, thank you so much for making time. We'll love to, you know, jam on a lot of different things. I did also talk a lot about code reviews recently. So, with that, can you also please introduce yourself for folks who might not know you? >> Okay, well, like you said, I'm Bob Martin. Some people call me Uncle Bob. I've been a programmer since, well, probably 1964. When I was 12, but my mother gave me a little plastic computer and it kind of changed my life. but yeah, I've been around the block a few times. Didn't done assembly language, COBOL, Fortran, C, C++, Java, and a billion other languages. Now, I'm deep into the AI world and having myself a blast.

1:43 >> Sweet. So, I mean, I would probably start with your book, Clean Code. You wrote that almost 20 years ago. It's probably one of the most influential books, you know, about reading the code. And now you say you don't read code anymore. Yep, that's true. >> So so tell me a little bit about like things in the last I guess we don't need to even go over last 20 years, but like you know, what does it actually look like day-to-day for you today?

2:08 >> For me, day-to-day, I I sit I don't use IDEs anymore. I barely ever see code. Sometimes I do, but very seldom. my primary tool at the moment is a terminal window in which at the moment I'm using the Grok TUI, although you know, I've also used Code X and Cloud. It's many others that I can think of. and I I sit in I tell it what I want and how it should get to where I want and what tools to use and what what constraints to apply and what thresholds to apply. and then I watch it very carefully.

2:50 And then I try to look at the architecture that it generates. And I try to get as much intelligence about what it has done as I can without forcing myself to go all the way to code. My working hypothesis is that human beings are too slow when dealing with code. So if we're going to move at the speed of the agents, we're all going to have to back off a little bit and maintain the high level supervision, but at the level of code, that's probably out of our domain now for the most part.

3:23 >> Okay, so I'm going to like at least go back 2 years, right? Even 2 years ago, I believe you publicly said that AI is not the future of coding. >> Correct. Yes. >> So what changed? >> The AIs. >> So yeah, even as much as a year ago, I was fiddling around with AIs and I had them do a few things for me and they did them rather stupidly. And I was convinced that well, this is just not going to go anywhere. And you know, it's a nice little tool. I can use it for a little bit, but I still have to be deep in the code.

3:56 And then it happened to me about January where I started to see this change. All of a sudden I could ask the the agents to do something and they would do it better. Not great, but better. And I thought, oh, something's going on here. And then like virtually every month after that, it has gotten better and better and better. I've I've just extracted myself from a rat hole that I've been in for the last two or three months attempting to build constraints that would keep the models in place. And now they've completely outgrown that.

4:35 Yeah, I don't need these constraints anymore. The doggone models are doing extremely good jobs. Not perfect, but very good jobs. >> Amazing. So, let's talk about constraints. maybe we can even start from, you know, 3 months ago when you were building these constraints to kind of like even today where constraints may still be needed. So, maybe kind of like 3 months ago just talk about I think you mentioned surrounding agents with the extreme constraints. I don't know how much of that is still true. So, tell me kind of what those constraints are and what is the state of the art today.

5:12 >> I still use the same constraints. The difference is now that I have relaxed the the austerity with which I enforced them. So, our first constraint, unit tests. The the agents, if you don't have them do unit tests, so far as I have seen, they will go off into wonderland. But if you have them write unit tests, that's a a double-entry bookkeeping kind of approach. They have to say everything twice, and that keeps them kind of in line. All right, they they look they can look at at the tests, they can look at the code and they say, "Oh yeah, that's the direction we were going." It has been many times that I have seen an agent break a test and then back off and realize, "Oh yeah, no, I need to go this other direction." You can see that as you watch the code stream by in the window, right? Can't read the code, but you can kind of see what's going on.

6:10 So, that's constraint number one. Constraint number two. CRAP. there's this old metric that came from about 2007. Some guys put it together. It was change something something something. I can't remember what the the acronym stands for. but it's called CRAP and it's it's a very interesting metric because it takes test coverage. So, you measure test coverage with a coverage tool and you combine that with cyclomatic complexity and they've got this complicated formula that they plug it into and you get out this number and the number skyrockets if you've got a very complicated function that is not tested.

6:57 It's perfect. It's perfect. So, I I'm I make sure that the agents keep CRAP low. Now, I used to keep CRAP down to four. and then I started thinking, "Well, that's probably too restrictive." And I backed it off to six. And at this point I'm looking at it and thinking, "Well, I think 12 was probably okay." This is part of the relaxing that I've been doing because the agents are getting so much better. So, that's number three. CRAP.

7:26 Number three. Mutation testing. everybody knows that if you if you run a code coverage tool, the code coverage tool does not tell you what has been tested, it just tells you what has been executed. But if you run mutation testing, you can prove that the coverage is actually covering things that aren't tested. So, the mutation tool goes in and makes modifications to the source code and expects every modification to fail a test. Any modification that does not fail a test is a surviving mutant and I have the agents kill all the surviving mutants within limits. There's some things that it can't kill and some things it shouldn't kill. But, for the most part, it kills the surviving mutants and that gives you a much higher reliability on the coverage numbers, right? So, those are the three primary constraints that I've been applying. I could talk about a couple more, but they're a little bit looser.

8:22 >> No, let let's kind of like even double click a little bit on this, right? So, you talked about unit tests. >> Yes. >> One of my concerns or challenges always with unit test is if agents have slightly different understanding of the task, they can write unit tests which will service, you know, it will succeed. It will pass. Like, the agents are generally trained to reach a goal and they will be like, okay, test passed. How do we actually build better constraint where, you know, the test are somehow better aligned with the intent or the task itself?

9:00 >> Two ways. Two ways. Number one, I am the final arbiter. So, I run in a very tight loop. I make them I force them to make changes, then I I execute the code, I play with the system, things that I don't like I tell it to change. So, that's number one. For certain applications, that works great. Right? If you've got something that pops up on the screen and you can move through the steps very quickly, you can get the agents to fix anything that they misunderstood and they misunderstand a lot of things.

9:35 They can't see the screen really. You know, they won't interact like a human would. So, a lot of human factors things they just ignore and then I have to go back and and fiddle with it. Number two, Gherkin. if you've got a fairly elaborate system that requires a lot of algorithm not algorithmic, a lot of behavioral specification. >> Mhm. >> It is wise to have humans produce that and I I like Gherkin as a language for that. This is the old behavior-driven development you know language. I like having Gherkin for that.

10:12 I I've had my agents build Gherkin interpretation tools. They will parse the Gherkin, they will execute the Gherkin so that you have a second set of tests that are authored or at least reviewed by humans. >> Mhm. >> Now, I think this works. I've had good luck with it. I've also had very bad luck with it. As part of this thing that I've extracted myself out of over the last couple of months, I put way too much emphasis on Gherkin.

10:44 Had the Had the agents building the Gherkin, had the agents testing the Gherkin and what I discovered was that the the farther away a human is from the Gherkin, the weirder the Gherkin gets. And it And it eventually becomes a an almost nonsensical description of the system. So, I backed away from that almost entirely. If I'm going to use Gherkin on a project, I'm going to author it entirely.

11:14 And then after that, I can probably figure out a way to execute it. >> I see. That's what you mean by farther away. So, if agents are writing Gherkin, humans are not providing review. You can probably include that. >> Yeah, it it's And the review is tricky, right? You can get an agent to write the Gherkin. The problem is the agents use language that is a string. It's just string. >> And is it English or a different language?

11:40 >> As you are reading what the what the agents produce in Gherkin, you can kind of nod yourself and say, "Yeah, sure." But in the end it just doesn't make any sense at all. So, you have to be very careful with that that level of review. And my current position on this, which is likely to change next week, is that I think humans need to author it, period. >> Interesting. >> So, that is in human language, not in agent language that sort of appears human.

12:15 >> Fair. I guess that could be a model constraint then. Like, it could be something which can hopefully improve over time, right? I feel like Yeah. >> That's why I said, you know, next week, who knows? >> >> Okay. And I think you also mentioned about the cyclomatic complexity. I generally don't like that metric, but like sure, even if it is something and you actually talked about crap, which I do not know, I'll go and read about it later. you mentioned that kind of like you moved from four to six to 12, whatever that is. because you're saying it's like >> number of indents.

12:47 >> So, I guess the question here is these are very objective metrics. So, this is essentially like saying is like six is a number where it's like readable, 12 maybe a number where it might not be readable. So, why are you relaxing that? Like, even if agents writing that code, like, you know, you still it is essentially defining the readability requirements. >> my rule before this was four. So, I wanted I wanted very small functions. And I wanted very small functions because human beings are extremely limited in their short-term memory. Keeping more than five or six or seven things in your mind at once is beyond most humans.

13:29 Agents do not have a short-term memory constraint like that. They can keep several dozen things in their mind. they can manipulate many, many different facts simultaneously. and so I'm relaxing it. Just going back and the way I measure that is to to measure whether the agents get confused. >> Interesting. >> see when an agent gets confused. And cuz they'll start doing things and breaking tasks.

13:59 >> it right. >> Breaking something else. They'll do all the things a human would do if you give the if you task saturate the human. >> That is very interesting. So, well, one thing which kind of I'm inferring from this is you have essentially now declared that this is a code only to be read by agents. >> Yes. Not by humans. >> Yes. Yeah. So, like you're saying >> Essentially if Right. So, you're saying essentially some of that complexity is acceptable because agents can understand it even humans cannot.

14:32 >> Yes. >> That's very interesting. Okay. So, this brings into probably the more interesting part of the conversation I want to have, which is code reviews. Right? And and one thing I would like to at least set the frame of reference as just because also sort of like this is our audience is I find that the way of operating in software teams is very different than working on solo projects. A lot of work you probably are doing these days is likely a solo project. Oh, yes. Right? So, do you have any thoughts on kind of like, you know, the way you operate, is this going to be the same for software team? Like think about like, you know, enterprise software. I'm not even talking about like COBOL, right?

15:15 Like, you know, those mainframe stuff, right? Like I'm talking about like modern software engineering. >> >> Like companies like Google, Meta, whatever. Some of them are still doing reviews. This is sort of like a debate which is going on constantly. I was just like talking in New York about how we kill reviews, but like this is a podcast for you. So, I would want your opinion on what does it mean to review the code? And and I think like another frame of reference I have for this is is how long until we stop reading that Well, well, I pretty much stopped now.

15:46 >> Yeah. I still look at it from time to time. I'll pop up a little window and look at the module and think, "Yeah, I don't like that module." But, most of the time, you know, 95% of the code I never see. so, but you said something interesting, teams. Something is going to happen here. I'm not quite sure what it is, and this is my wild conjecture. But, it seems to me that a single human can now do the work of a team. Okay. And therefore, our reliance on software teams is going to change dramatically, I think. Instead of a tight-knit group of five or six developers constantly communicating with each other, I think we're going to have isolated individuals who are producing much more code than before, much larger kinds of elements.

16:37 And they'll have to communicate at a very narrow interface boundary. And so, the amount of collaboration, I think, is going to decrease, even though the amount of functionality increases. >> pure conjecture on my part. Make It might go the absolutely opposite direction. >> >> But, that's what I mean. >> That's what I'm thinking right now. >> Interesting. I think I have a different opinion on that, and obviously I would not like, you know, got a whole spiel here. Like, most of my conversation which I did in New York at my code review talk was about building mental models and knowledge sharing.

17:15 I find we still ways to do that, right? Like the thing which made software engineering interesting and exciting and there was like whole software architects and these like, you know, you know, Jeff Deans of the world was learning about better software practices and sort of like understanding the trade-offs and kind of like making those decisions, which I find in software teams and in collaboration are very critical and also I find when you are not even writing the code, that is the place which is, you know, still the most intriguing and exciting part of software engineering.

17:52 >> So, can I share a screen with you? >> Yeah, go for it. >> Let me show you what I'm currently working in. Let's see if I know how to do this. I hit the share button, right? And I want Yes, I'm going to allow you to do that. Let's see, what can I show you? >> So, this is a first in our podcast. I'll I'll be also kind of like put this in the show notes so people can find it if they're not watching the video.

18:16 >> Looks like that one I can share with you. This is what I'm working on at the moment. and you're looking at a static thing. This is actually very dynamic. So, what I do is that I've got a project I'm working on, fairly elaborate project. I have a tool that will break it down into UML. This tool is coupled to an agent. So, the agent and the tool communicate back and forth. And I can click on items, I can expand items, I can collapse collapse items. I can play what if games. Now, this looks like UML, it's kind of like UML, but it's dynamic, which means I can drill down, I can drill back. Let me see if I can show you some of that.

18:58 Just basically, let's see, how do I >> >> Oh, yeah, that's right. P, right? I was just looking at a a what if game, you know, what if I did that to this model? This model's got red all over it cuz there's problems with it. Some of the problems you can see up here at the corners, the crap is too high. The mutation rate is too low. I think if you go down here, you'll see some red arrows. Those red arrows are misaligned dependencies. I don't like them, right?

19:29 So, I'm still looking at the high-level design. I'm still looking at the structure. And then I can I can take an element like this and I can double-click it and I can drill down into it. And if I go even a little farther, I can drill down to the level of, say, a code. If I want to see the code, I can look at the code. Usually, I don't have to do that, but every once in a while, I will. Okay.

19:52 This is the kind of level that I'm at right now. As a collaboration tool, this is pretty interesting. I don't know, but you know, if for individual evaluation of the system, it's pretty interesting. As a collaboration tool, it's pretty interesting. I could walk through this diagram with you and explain the way the system works pretty quickly without you ever having to look at the code. This was the old the old dream of UML, but UML was conceived back when it was a static thing that you did before you wrote the code. This is now a dynamic thing that you do after the code is produced so that you can inspect what the agents have done and then undo the horror that they have created.

20:39 >> Interesting. >> Yeah. >> So, almost this is like a more structured way of doing specs after the fact. Yes, after Yeah, like you're kind of like synchronizing it with the code. So, it's like kind of like almost dynamic spec as well, right? So, just the whole thing which gets maintained, but the beauty of this is it's more logical layer versus sort of like specs generated into be just English. >> Yeah, and then, you know, then I can play what if games. I've got an agent attached to this thing. So, I can go to the agent and I can say, "Well, I don't like the way this is arranged. Can you move those things around? Can you put them in different layers?" Right? And the agent will will do that, and then I can take a look at a a proposed structure, which is this. This is not the real structure of the source code.

21:23 This is a proposal that if I like, the agent could turn into real source code. >> Very interesting. Do you think there's a scenario where this could potentially become a review surface itself? Like one of the things which I always find is we need a way to do those debates and collaboration, especially when you work in software teams, right? Like even when you're talking about like, "Okay, everyone has sort of like works independently." You still need to collaborate to understand what broadly whatever we want you are working on. And like at least have like arguments on like architectures and like design decisions. So, do you think something like this could be that?

22:01 >> That's my intent, right? Is that something like this is the way we will all have to interact with with systems over the next couple of years. I don't know where it's going after 2 years from now, but over the next couple of years, you could look at diagrams like this and focus on the things you care about. Right? What do we care about in designs? We do care We care about that it's properly partitioned, that we can decouple things that are highly variable, and isolate things that are highly static, right? Those are the kinds of things that a software engineer is really worried about. And in a diagram like this, or maybe there's some other kind of diagram, I don't know, but in a in a depiction like this, you can see that.

22:45 And you you can circle things and say, "Well, this is bad, but that's good." And then have an agent, you know, shuffle things around and make it better. >> Fascinating. Interesting. Do you have recommendations for software teams in terms of review itself? Like and maybe I think it's a loaded question because in some ways I would also want to know is do teams need certain level of constraints or harnesses? I know you kind of like had some opinions on harness engineering as well. Maybe we'll go there, but what do teams need to be in a place where they can potentially either kill reviews entirely or kind of like, you know, reimagine reviews the way you're doing.

23:25 >> So, the first thing any team needs is a a set of disciplines. Set of rules that they're not going to break until they've all decided to break them for some reason. So, a set of rules that they all decide they're going to follow until they have a meeting and decide they're going to break a rule. and those rules would be things like, okay, unit tests. We're going to get unit tests. We're going to drive coverage as high as possible. We're going to keep our crap below a certain threshold. We're going to mutation test to within certain certain limits.

23:55 We're We're going to do that. We're going to verify that that has been done correctly. Right? And then after that, maybe Gerkin is part of it if it's a big enterprise system. Maybe Maybe a human review in the in the in a kind of a gooey cycle is part of it. But, those disciplines are really important. The The thing that you want to avoid in any kind of team or even individual setup is the vibe coder who just kind of prompts his way to something that appears to work.

24:26 >> >> You want to make sure it actually does work. >> Interesting. So, let's talk a little bit about harness engineering. I feel like this was also relatively recent. You said harness engineering is overrated. I may be paraphrasing. tell me a little bit about what's going on there. >> Last several months, right? I was I was working on a harness and the harness was austere. It had an agent for specification and an agent for coding and an agent for review and an agent for architecture. All these agents and they were arranged in a kind of assembly line. And they would hand off to each other. And I spent a lot of time dealing with those hand-offs to make sure they weren't leaking information into each other, right? What I found is that if they leak anything into each other, they all become the same agent after a while. So, I had to keep them, you know, extremely limited in what they could say to each other.

25:18 And I got this working. I was really proud of it. Like it went back like 10 days ago, right? I was like really proud of this. This is really cool. I can have multiple projects running and and then, you know, you have little cards on the screen and the cards would move from swim lane to swim lane as things were It was really neat. I was so happy. And then I realized, my god, this is inefficient as hell.

25:44 >> >> And the real giveaway was that I never used the harness to create the harness. The whole time that I was creating the harness, I was just driving a single agent. And the agent was getting better and better and better. I I had the the breakthrough moment for me. Was about 10, 11, 12 days ago now. I sat down with an agent. It was Grok at the time. And I had like a 45-minute in-depth discussion with this agent proposing things, getting counter-proposals back from the agent, having a the kind of discussion like I could only have with an extremely seasoned senior engineer.

26:30 And the doggone agent would would would throw darts at my proposals. It would I would propose something and it would say, "Nah, that's stupid. You can't do that. Here's why. Why, why, why, and why?" And it would be right. And I go, "Oh my god. Damn thing is right. Okay, well, what about this?" And then it would come back with a different proposal. For 45 minutes, I was interacting with this thing that was equivalent to me talking to a senior engineer.

26:58 And at that point I said, "Wait a minute. If I If I am willing to invest that much trust into a single agent, give it that level of consideration, why am I putting it into a harness that makes it act like a menial slave?" >> Hm. >> And at that point I said I said, "Wait a minute. I got to back off. I've got the wrong model in my head." >> Interesting. Interesting. So, I mean, this is also very timely. I don't know whether you read, but like Steve Yegge's Gastown is also going away.

27:33 >> Well, everybody thought that was great, right? And And you know, a year ago or 8 months ago >> No, yeah, very soon. Very soon. >> how cool is that, man? You got all these handoffs and like And then it's like, "Well, we don't need that anymore." >> Interesting. So, Well, I guess then maybe the question is, are all software factories doomed? >> I I don't know what a software factory is right now. >> Right, I guess the definition also keeps on changing. I don't know what a harness is right now anymore.

28:04 >> >> Me, either. Right now I'm thinking I can get a lot of work done, very high-quality work done by myself with a single agent and a visualization tool like the kind I'm using. Right? That gives me the confidence to say, "Yes, this is production ready." And I I don't know where the I don't know where that stops. You know, this gets to the whole exponential curve thing. And And I lived on the exponential curve, you know, from the 1960s on. I was on that exponential curve. Moore's law was running like gangbusters. We needed new computers every year and a half. Right?

28:44 Impossible to keep up. All of that was driven by shrinking electronics. Exponentially shrinking electronics is what drove that. We are now on a different kind of exponential curve. This is the AI exponential curve, and it's all being driven by growing power and growing real estate. Which has a very severe physical limitation. I don't know how long we're going to be on that exponential curve. Now, the limitation when we were shrinking things was atoms. Atoms and speed of light. Now, the now the limitation is real estate and generated power.

29:21 >> Interesting. >> And that's why Elon Musk is going to orbit. >> >> I mean, in some ways you can also argue or imagine a world where once you hit a certain level of equilibrium that you start optimizing these things so it continues shrinking again. Like you kind of like don't need that many big large language models to actually do the kind of work that we do today. >> Yeah, maybe. Maybe. I mean, we've got a an instance case in our skulls.

29:48 >> >> Right? 2 lb and 20 W. >> There you go. >> Not bad. >> Right. And and we are still looking up maybe quantum computing might solve some of these challenges, too. Maybe. No. You have different opinions on that. okay. So, I think we talked a little bit about bunch of things. I would want to at least potentially go back to teams as well. And more from cultural standpoint, right? If we are working with agents and we are saying maybe software factories or harnesses like harness engineering is overrated, that means like in some ways we're still doing certain supervision of the agents as we kind of like work along with them.

30:26 What does it mean for responsibility standpoint? Like there used to be a author, there used to be a reviewer. Some were well-defined responsibilities. There used to be a team who owns the code. what does that mean today for teams? Like is it like all reviewers spending the same amount of time as authors or authors expected to be responsible for the change that's being made. I mean, like I also have these opinions that, you know, the responsibility now is about building better guardrails, but like you're also talking about maybe we don't need enough constraints. So, like responsibility, ownership, how do we think about that?

31:00 >> Well, the first thing I think about that is that the agents are not responsible for anything. And they're entirely irresponsible. That only humans can be responsible. At the moment and probably over the next several years. Which means that we humans, we software developers have to take our skill and our experience and apply that to what the agents have produced and then sign off. Right? With with all the responsibility, with all of the repercussions that that implies. Right? So, if I'm if I'm on a team, you know, I'm doing this kind of UML work, I'm doing all the the Gherkin work or the the crap and the coverage and the the mutation work. I'm I'm going to make sure that that system is deployable and rational.

31:47 Without devolving all the way down to reviewing the code. Because I think reviewing the code is A, it's not very useful anymore and B, it slows everything down like crazy. So, somehow we humans have to have to take responsibility for the systems at just above the code level. Leave the syntax to the agents, but everything else we still we still hold near and dear to our hearts and we are responsible. >> Very interesting. So, okay, so now you're saying obviously that agents cannot be responsible for clean code.

32:20 So, you have to measure cleanliness in some ways. So, let's just say if you were to maybe this is sort of like a also rapid question. If you were to rewrite clean code today, it's almost been like, you know, 20 years from scratch for a world where agents write most of the code. Second edition? Second edition? Okay. I thought I thought you were going to call it Clean Code. so so yeah, what give us a glimpse of that?

32:47 >> So I wrote the second edition just before I started this AI thing. Just, you know, right at the moment when I thought these these this AI stuff isn't going to go anywhere. what I put in the book is pretty much the same as what I had in the previous book. A lot more examples, a lot of stuff like that. But in the end, all the same principles apply, even with agents, right? You still want the code to be clean. You still want good partitioning. You still want good dependency. You still want good names. You still want to manage your comments properly. All those things still apply.

33:21 But the thresholds might be different. The boundaries might be a little different. That's where I'm kind of exploring things at the moment. But all the rules are still there. So, you know, I'm not going to change anything in any of the fundamental principles in Clean Code. I think it still all applies. And it is the responsibility of the developers, the humans, to make sure that those rules are applied properly. >> Interesting. Yeah, I mean, I also talk about like, you know, humans were never perfect at this either. So, you know, if we can get agents as good as humans were, you don't need them to be perfect.

33:58 >> Yeah, it's sometimes I think they might be a little better. >> They already might be, yes. I guess if you talk about average. >> Yeah, if you talk about the average. >> >> You know, and so at some point the agents will beat the chess master. >> >> Right? It if the exponential curve continues. >> Right. Right. Right. Awesome, Bob. I would have loved to continue this conversation, but I think we should have to wrap it up. Maybe we'll do another one in a few months, and we'll see how things have evolved.

34:30 >> Only a little different by that. >> >> So again, thank you. This was one of the most entertaining and also very close to my heart topic that we talked about and obviously everyone who was listening, thank you so much. If you folks are interested in developer experience or work in the space, come join us. We also run a community called the X where we have these conversations live over Zoom and yeah, with that Bob, it's it was a pleasure.

34:58 >> Lot of fun. >> Thank you.