 All right, cool. Ooh, that's a little bit loud, huh? What's up, everyone? Thanks for joining the last talk of the day. Appreciate you all. If you're looking for 17 metrics, I reduced it down to seven. Make it simple for everybody. But yeah, more seriously, seven metrics that matter more than coding time. Coding time is a metric that I've talked about often. But I think there's some other ones that I really want to dive into in this session that will be more interesting for you all. But a little bit about myself. My name is Dan Lines. I'm one of the founders at Linear B. I also founded the Dev Interrupted Community. So I'm very grateful for that. I'm the podcast host. I get to talk to all these amazing people from different organizations, companies, really smart people. Usually what they're talking about is something around developer productivity or let's ship code faster. And that's the kind of stuff that I'm into. So some of the metrics that we're going to be talking about today is in that vein. And hopefully give you some tips of how we can do this better as a community. That's my goal here. Kind of an ironic thing. So our job as developers is to build, is to create. That's when I get the most enjoyment out of what I do, create something, create something new. But the thing is, and we'll get into some of the data, there's oftentimes not enough time spent on coding, especially if you're working in a professional job. Maybe it's your first job out of school. You might think, oh, I'm just going to develop some amazing stuff. But you find out that actually sometimes the majority of the day is meetings, updating tickets a lot. In the code review area, which we're going to talk about planning, retro, design reviews. And sometimes it might be a 50-50 split. But some of the data that we have, it's maybe like two and six hours. Maybe it's a little extreme, but something like that. And the thing is, there is a million developer tools out there. You can find anything that you want around the developer tool if you want to code faster. GitHub's got a bunch of cool stuff. Co-pilot, I'm sure everyone's checked it out. If you want to code smarter, IntelliSense, if you want more security, there's a million tools out there for security. Code less. There's probably too many tools, everything that you want all of the time. But what I've kind of seen is, as an industry, I think we're now optimizing the wrong bucket. There's enough developer tools out there, but there's other stuff that's going on. The meetings, the housekeeping, the ceremonies that you get into, and especially the code review process. That's something that I'm passionate about. That's where I think we need to spend a little bit more energy. So when we're at our day job, we can actually spend more time coding. And that's what this talk is about. So pull requests. Show of hands. We like pull requests. We don't like pull requests. Somewhere in between, thumbs up. Yeah, we like them. OK. Merge requests, anyone? Or are we all a pull request camp here? Pull? OK. Yeah, so it's like kind of a, it depends on the audience, but can't live with them. Can't live without them. I actually think they're very good. But there are some people out there that are saying that we should get rid of them. So it's kind of depends on the audience here. Typical day in the life of a dev, I remember being super pumped to solve any problem. Hey, I just solved this really, really cool problem. I want to go get it merged. I want to go get it shipped. That's what would make me feel really good. I can move on to the next task with a clear conscience. Does that happen all the time? So I'm saying not so fast. Does anyone have, has anyone heard the terminology cycle time before? Yeah? OK. Maybe one. So cycle time is one of those interesting metrics that's really popping up within the engineering world community. It's one of those Dora metrics. What does it measure? It depends on who you ask. In this talk, what it measures is, OK, I've created a branch. I'm starting to code. How long does it take me to go from coding to deploy to production? If you don't know this metric for your team, it can be something that's interesting. There's a few metrics within side of cycle time that are also interesting, like coding time, which was in the title of the talk. But we're not going to focus there today. PR pickup time. So when you do kind of finish your branch, you open up a PR. How long does it take to get picked up? PR review time. How long does it take to actually get reviewed? And how long does it take to get deployed? That's what cycle time is. And here's five metrics for you that I think are fairly important. But what we see in the community, where do we have the bottleneck? It's actually not in coding time. So coding time is looking pretty good. We have a linear B labs thing I'm going to show you where we get to analyze all these PRs, all this data is from the community. So coding time is actually going very well for us. In deployment time, probably depends on where you work, but it's getting better and better. There's so many tools now to help us get software out in a more efficient way, get the code out. That middle area of I need a reviewer. I need to finish my review. This is not going so well for us. It's the red areas up here. This is what's taking a long time. And so this is what I was just mentioning. So at linear B, we're fortunate enough, we do have a labs team. We're coming up on analyzing about a million PRs at this point in growing. So that's where the data that you're seeing from this presentation is coming from. 25,000, 30,000 developers in growing there. And what we find with pull requests is they're actually idle most of the time. And what does idle mean? No one's doing anything with them. They're just sitting there. I opened a PR. I'm waiting for a review. Or let's say that someone has actually done the review and maybe they gave some comments or a merge request, or sorry, a change request, then it's sitting there waiting on me. So 50% of PRs are idle 50% of the time. 33% of PRs are idle about 77% of the time. And it's not a good thing. You can think of idle as kind of being like swapped out in memory. So if I open a PR and I'm waiting and waiting and waiting, it's going out of my mind. I'm on to the next task. I don't get paid usually just to sit there, maybe sometimes, but most of the time I move on to my next task. I'm developing something. I have this PR sitting there. It's degrading. So it's a very bad thing. And in this talk, I've separated out two kinds of idle time. At the top, what you'll see in the slides is maybe like a standard flow that a PR goes through. I'll pretend I'm the first person. I open up the PR and then I wait. I'm trying to find a reviewer. Maybe I assign a reviewer. Maybe I'm posting in Slack. Hey, can anyone take this? Someone might find it the next day, get some initial comments. Maybe the PR's large and they have to take a break. Maybe more comments. Ask for a change request. Now it's the next day. I come in, I make some fixes. Maybe I make some more fixes. I say, is this good? Another day goes by and eventually it gets merged. Takes a lot of time. Now in that process, there's a transition time and there's a distraction time. I'll describe the two different times here. So in transition time, this is more natural of how PRs work today or MRs work today. I open the PR, I need someone else to review it. There's an inherent transition time. It's just a handoff. Not much maybe that you can think that you can do about that. There are some things that I think we can do. But it's kind of just natural in the process. And it happens because, and I'll talk about it a little bit later, we're kind of treating all PRs the same as an industry today, which I don't love. We're gonna get into some solutions for that. But when I say we're treating them all the same, it means I'm opening a PR and I'm waiting for a reviewer to come review, no matter what the size or what the complexity is. In large PRs tend to also not be a so good thing. They take longer to the review. No one wants to pick them up. Try opening a large PR on a Friday. See if it gets picked up. It's not gonna get picked up. Maybe even on a Thursday, actually. And so this transition time, it just adds delays and it's between two people. Now the other type of time or idle time is distraction time. And this is within one person. It's like, it's just me. It can happen because of interruptions. So for example, I start my PR review. It's a large review. I need to take a break. I might get pulled off to an urgent task. I might wanna go get some lunch. Now I have to do a cognitive reset, cognitive reload. I come back to the PR. Do I pick up right where I left off? No, I have to do, okay, what was I doing here again? What was this thing about? So this distraction time, it adds up and it adds up and it adds up. And these are some of the reasons why the PR process is taking so long for us. So it's like no one really wants to pick it up. There's an inherent transition back and forth between two people. And then once a review starts, especially if it's a large PR, it's not gonna just finish immediately, okay? The other thing that our data shows is that delays actually cause more delays. So it's that type of situation. If you open up a PR and you don't get someone reviewing it day one, like that same day, it's not a linear growth. It's more exponential of how long it's gonna take for it to get merged. So one of the tricks, and you might know this, you might not know this, or you might not even been thinking about it, if you're able to get your PR picked up for review within the first hour, that's best case scenario. Oftentimes, you'll get it merged the same day. And if you're unable to do that, then the time goes up and up and up. Makes sense? Okay. So here's what I want to get to. I think there's a holy grail, and I'm calling it continuous merge. And some of the concepts of continuous merge will get into them, but let's give more of the power to the developer to decide how their code goes through the review lifecycle. Other concepts of continuous merge, let's not treat everything exactly the same. Okay, let's start splitting up and we'll talk about it a bit here. Now, when I talk about continuous merge, some people might say, you know what, do we really need PRs? Do people think we need PRs by the way here? You think we do. Okay. There's some people out there that are saying, hey, we don't really need it, just use your CI, let your test pass, that type of thing. I don't think it's, I think it's smart, but I don't think it's appropriate for most situations. There are some projects that I think we could get away with no PRs, but that's not something that I'm advocating for here. So everything you'll see in the rest of the talk is saying that we do need PRs, even though I want to change a bunch of things about them. So yeah, like I was saying, I think pull requests are actually here to stay. I think they are beneficial. There is some data out there that shows that peer reviews detect about 65% to 80% of bugs. So that's a quality super, super important, should be top of mind for everyone. I do think it's a good way to share knowledge. I do think it's a good way to increase maintainability. A lot of the feedback that you'll get on your PR, it might not be, oh, this is gonna bring down production. It might be a maintainability thing. Hey, if you did it this way, or what's the test patterns look like here. And the other thing that's happening is, I don't know if everyone's noticing, but there's more and more developers entering the workforce. Like the amount of developers that are in the workforce is increasing at a fairly rapid rate. I think PRs is a really good way for that onboarding, coaching, especially with juniors. So definitely an advocate for them, not a detractor. Now, here's some of the interesting stuff and some of the takeaways. So what have we learned so far? In cycle time, which is one of those metrics that I think everybody should know, the bottleneck is in this PR process for most organizations. But there's things that we can do to optimize. So the first thing that you'll see on the left-hand side of the slide, adding context really, really helps in two ways. If you add context to your PR, you're gonna get a faster pickup time. So people will be more willing to review what you put up. And actually, our data shows that the review is done faster, the actual review portion of it. And there's two pieces of context that I think is kind of a minimum that should be there. And I see really good results. One is what is the priority or what is the ticket? Is this a bug? Is it not a bug? Is it a new feature? Are you refactoring something? Give someone the piece of context of what are they getting into? If someone doesn't know what they're getting into, they're very unlikely to just start if they have low energy. So I don't know what I'm getting into with this PR. Okay, I'm gonna do it tomorrow, tomorrow morning, right? So always provide that type of context. The other thing that I think is maybe obvious, but kind of innovative actually, provide an estimated review time. Here's how long we predict this PR review is gonna take. Is it gonna be five minutes? Is it gonna be an hour? Is it gonna be a half an hour, 45 minutes? What does that do for the reviewer? It does something really cool psychologically. Let's say for example, it's like 11 45 a.m., team's going to lunch at noon. If I know, if I put a PR onto your plate, for example, and you have an estimated review time of five minutes, you might say, hey, I can get this in before we go out, okay? And that's a way for me to get my PR picked up faster. Of course, it needs to be accurate. That's the point of it. But also it does a service. Let's say that it's a 35 minute review. Well, I actually don't want you starting that PR review. That's like a disservice to the reviewer. Oh, I'm gonna start it. Then I'm gonna get pulled away. Then I'm gonna start it again, let's say after lunch. And now I have to go back from the beginning. It's not really, you don't really pick up where you left off. So providing that context super, super important. I really encourage that. The other thing is just measure. How many, like I know, okay, let's do a raise of hands for developers in the room, devs, okay. Team leaders or managers, anyone like that? Yes, someone. What I was saying when we were chatting in the beginning of the talk here, there's a bunch of tools out there that allow your team to have visibility into where the bottleneck is. I highly encourage measuring just that cycle time to start with. Some teams that I see have a problem with picking up the PR, which again means I'm here to start my review. And other teams have a problem once the review starts, how long that review takes. You might have both of those problems. You might have one of those problems or not. So measure, so it's a good thing to talk in like a retro, hey, why are these reviews taking so long and this repo versus this repo, let's reduce it. And the last thing is around communication. So I'm gonna talk about this thing, worker B. I've been working on a suite of tools under the umbrella name worker B. So that's why you see it here on the right hand side. And one of the things that I think is really important if you don't have it today is some type of messaging service that's at least saying, hey, you've been assigned this PR or hey, this PR has been approved, you can merge it now. There's some more advanced things in there that I'm gonna advocate a bit, but at least have some, we call it worker B for linear B, but at least have something that's communicating back and forth, yeah, okay, makes sense. Another thing, and I think this is really, does anyone read the Martin Fowler blog? You all check that out ever? Okay, someone posted something. I saw someone say like maybe I read it. Someone posted this ship show ask concept. I have their name here, I'll do a disservice if I pronounce it. Ship show ask, what does that mean? It's the concept that not every single PR needs to go through. And they're actually not even talking PRs in this, but not every single piece of code needs to go through the same review cycle. So for example, a piece of code that's very low risk, maybe it's only documentation change. Why is it going through the PR cycle? In a review cycle, it's bottlenecking, doesn't need to. Now on the other end of the spectrum, maybe you have a 500 line, a thousand line, hopefully not but let's say 500 lines of code change in the PR, maybe that needs two reviewers. But for some reason as an industry, mostly what we're doing is one reviewer for every single PR. And so here's a concept to start classifying by risk type and saying hey, some of these PRs, maybe we can auto merge them, documentation only, for example, test change only. And some other ones, maybe they need more review. So this is a really cool concept that I'm into. I'll talk about it a little more towards the end of the presentation. The other thing that I wanna say, I've said it a few times during the talk, but I cannot emphasize enough how important it is to keep your PR small. Like that's, if there was one, probably one takeaway from this talk, keep your PR small. That actually helps everything in the cycle time process. Your coding time will be smaller. The pickup time, someone, how excited am I to come and do your review? I'm telling you if it's big, I'm not excited. If it's small, I think I'm gonna do it. The amount of time it takes me to review much, much less and the amount of time it takes to merge much, much less. So this is a behavior that we've seen over and over and over again in the data teams and what does large and small mean? Usually 150 changes or less, that's good. Anything over that, you're not gonna get like good performance in terms of getting your code out to production. So you definitely wanna keep your PR small. This is what I was talking about in terms of context, adding the estimated time for the review. So what our data shows, again, we're at about a million, I think it was like 900,000 PRs that we've analyzed so far and starting the climb up to the million range. What we've seen is PRs that include this estimated time of review do so much better on the pickup time. So like a lot better on, oh, I do actually wanna go review this or again, maybe I can do it before like in this five minute period of time before my next meeting or even better, thank you so much for telling me how long this is gonna take. I know I actually have to block off time in the afternoon and let me block off the hour to get it done so I don't get interrupted. This is actually a game changer even though it seems simple. It's like when you read a blog, it tells you how long the read time is. Yeah, so you can determine do you wanna read it or not. This is something that I really encourage to get into all of your PRs and of course what the graph is showing is the ones that are very small get picked up really quickly. If you have like a 15 minute review time or less, you're golden. So that's what you wanna get to. Okay, this is interesting. So we talked like pretty briefly about the Ship Show Ask concept but really what it is is a concept of let's not treat every PR exactly the same. We can start having classifiers for PRs and we can take different actions based on risk, priority, where we want our efficiency to be for our team. So one of the tips here is why don't we start creating a fast lane for the right PRs? Doesn't have, I'm not advocate, like quality is number one but even if you go back to your team and you say, hey, if I'm just making a change to documentation or if we're just making a change to let's say you might even be a little more risky images or I'm just doing test coverage or test related changes, could we get those into a fast lane type mode where either they're auto merged or they're prioritized? Teams that do this, it makes a big difference. So I highly encourage, it's a little more advanced to define a risk model that would be the next situation if we could say, what's the security risk? What's the test coverage? Did the test pass, did the test fail? Are we changing a sensitive piece of code? Now I have a full model that I can decide what to do but just start with like a fast lane, right? It's like when you go to the airport there's probably not many people remember when there's like one line and there's like three lines. I don't know who has the clear but I have the TSA pre, right? So you start getting less risk it through sooner. So you should really encourage doing this. Another tip that I have is and this is a little counter-intuitive. So one thing that I do like about pull requests is I can put a PR up and maybe someone else in a different time zone or someone else on their own schedule can review it whenever they're ready. Like that's cool, I do like that. And it's great with open source, all of that totally makes sense to me. But we did find something out that's again a little counter-intuitive. If you know when your teammate starts reviewing your PR so think about this concept, I'm coding so like I put up a PR, now I went on to my next task and I'm coding which is great because we're working in parallel. If I know that my teammate has started my review, I'm not saying stop what you're doing. I'm saying be available because if we go back to that transition time, if they're commenting or asking for code changes and you're not getting to them immediately, you're getting them to the next day, it takes much longer for your code to get merged. So if you're just okay, I know that they're reviewing it right now, maybe they'll ping me on Slack, maybe I'll see an email message come in, whatever it is. If you're available to actually do, like make the changes or answer questions, that's a really, really good thing. So highly recommend it, know when your teammate is reviewing your code. So I mentioned that I've been working on a few tools under the umbrella name of WorkerB that kind of does some of this optimization and routing. I'm experimenting with a few concepts. I'll show you what's available today and then I wanna give a little sneak peek into what's coming next and then we'll close it out here. So the first thing, we have something now, it's the fast lane concept that I was talking about before. So code changes or pull requests that are only affecting one file and are five lines of code changed or less, which means you can view it in a small snippet. We started to send them in a Slack message to the reviewer and saying, hey, this is a really small one. Could you give this a look right now so we could keep the pipeline moving forward and just approve it. Now you're still going through a review. It's not an auto-merge situation. You're still going through a review, but it's so tiny. There's no reason it needs to be bottlenecked but behind these really big reviews. We've had a lot of success with this. So this is one of the things that our WorkerB includes like a chat bot on Slack. So if everyone on the team installs it, it would say, hey Dan, small change assigned to you could you just take a look at it. Bam, it gets through. Teams are really liking this. So this is kind of like I would say a version one to that idea of having a full model of classifying pull requests. And this is going great for us. Another thing that we added in, it's probably common sense, but after the approve happens, why not just get a message to say, hey, your approval went through. Do you want to merge this? And now we can actually get the code into the main line. We stopped degrading as code stays not in the main line. I think it's older and older and older. This kind of completes the flow. Also I've had great success here. This is an interest like very, I think, probably my favorite tool that I built so far with the team. It's called WorkerB for pull requests and it's a Chrome extension. It's working with Chrome and GitHub right now. And it does a few things for you. It allows you to promote your PR within Slack. So a common pattern that a lot of teams have is I don't necessarily assign a reviewer. I'm kind of asking in an open Slack channel, hey, is anyone available to do my review? Well, what happens if you have this extension on GitHub, you can click on something that says copy link. And when you click on that copy link and you post it into Slack, it opens up your pull requests in a really nice way and includes the estimated time of review. So I'll say like five minutes, two files change, two commits. And you can add a little message. It seems simple. We have teams that are like adopting this like crazy because like I said, with that estimated time of review context, now everyone can determine, oh, this looks like well put together. It's easy to pick up. I'm gonna take it right now. So if you're interested in really getting your PR, like picked up faster, providing your reviewer in more context, this is what this Chrome extension does. The other thing that the extension does is when someone starts reviewing your pull requests, it will let you know. So I think everyone's probably used Google Docs when you're both on the same file. You see those little avatars at the top. That's what it does. It will pop up. Someone's GitHub handle say, hey, this person's reviewing right now. Please be available. And this little extension is allowing teams to get code merged much faster. So that was another thing that we built to try to address some of these problems. So here's something much more advanced that I'm working on that I wanna give everyone a sneak peek into. Happy to talk about it after. So the other, the previous two things that I showed you, like they're GA, like live, you can go and use them and all of that. This is a sneak peek of something that I'm working on. We're working on creating a configuration file that teams can put on top of a repo that have some of those out-of-the-box rules that will help route PRs based on risk. So for example, if you start using this configuration, we're gonna say, hey, will I identify anything that is just a documentation change or anything that is just a test change? And that's gonna go into the auto merge category. As soon as that PR is put up, the team obviously agrees on this config file. That's just gonna get merged. Pull requests that are X lines of code and one file, you're gonna get into that fast lane where the chat bot's gonna say, hey, could you review this right now? Then you have kind of your standard PR, which is, okay, let's say it's 150 lines or less. There is some risk from a security standpoint. Let's go through the normal PR process there, one reviewer. And the other thing they'll do out-of-the-box is say, okay, let's say it's 250 or 500 lines of code. We're actually gonna recommend multiple reviewers for this. And the Slack bot will coordinate this. We'll look for the previous code owner plus the reviewer that you assigned. So the reason that I'm so proud of this, I think it's one of the first time in history that we're kind of saying, hey, PRs, they're a little bit different. Let's classify them and let's take the appropriate action. The other thing that will come with this feature set is each developer on the team can install a plugin on their IDE and while they're coding, it will let them know what lane they're in. Hey, you're in the auto-merge lane. Up, you just cross into the fast lane, but if you wanna get back to the auto-merge lane, this is what you need to do. Oh, you just crossed over into the two reviewer lane, but if you make your pull requests much smaller and you have 100% test coverage in your test pass, you can be in the one reviewer lane. So it kind of gives that instantaneous feedback to the developer based on the rules that we saw on this last screen that the team has agreed upon. So now every developer knows kind of the fate of their PR. It will also give you the estimated time of review and estimated time of merge. But this is, I just wanted to give everyone a sneak peek. This is the next stage that we're working on here. So yeah, I mean, if you were digging what I was talking about here, I kind of just have a call to action, like let's all improve. Like I said in the beginning, I am the founder of the Dev Interrupted Community. I am the podcast host. If you wanna come on the pod or you know someone that would be good to talk about this type of stuff, hit me up. If you want the Worker B for Chrome extension, that's in the middle there. You can just type Worker B for pull requests or you can go to the Chrome store and do that. Also, here's the link, it's linear B. So that's my company, Linear B. Linear B.io slash Worker B for Chrome onboarding. It'll kind of give you some information there. And lastly on the right hand side, we do have a platform called Linear B. This is four teams. And by the way, like this stuff is free. I'm not, everything on here is free. We do have a platform for teams. It will show you your team cycle time, where the bottlenecks are, where they're not. And it will give you that Worker B chat bot that will start coordinating between each developer. It will give you the fast lane stuff and it will give you that estimated time to review and to merge. So that's free as well. It's app.linearb.io slash register. And just wanted to say thank you very much. I know it's a Friday end of the day and appreciate you all. I'm open for questions if you haven't. It does, both, yeah, yeah. Yeah, sure, exactly. More clicks lead to, I'm gonna put this off to later. I'm gonna do this Monday. Yeah, sure. We have a few different modes. We can use a personal access token, which will allow you to have a little more customization of what you wanna give access to or not. So for example, if you're an individual developer or maybe you just wanna try it with a few people, you can restrict it. And then, we are a business, right? That makes money. There is a team version where you can get, it's more like the global authorization, usually an admin will be doing that. But what's nice about that is then everyone on the team is already authorized and then can just start using. So we kind of have like progressive disclosure, depending on who you are. And with the, I really recommend the Chrome extension because it's just like really, it's kind of like a taster. And if you wanna then go to like, okay, let's see what this full platform's like, you go from there. We've been talking about that. Yeah. So we don't have the CLI yet, but what we've found is actually developers are all working like a little bit differently. So it's like some want the CLI, some like the Chrome extension, some like a Slack bot that's like their little buddy to remind them, some like it like in the IDE to say, actually I didn't mention it, but in the IDE in that extension, we're also gonna have a button that says open pull request now, like just open it for me, right? So we're kind of trying to go around the whole ecosystem. No, they don't have any tastes or preferences. Sure. There's two things that come to my mind. So what it seems like for you is you're having a hard time getting a review. And for example, if you try this Chrome extension, this worker B for pull request, it does entice a review because what it's saying, if you are creating small PRs and doing things the right way, hey, I really have my stuff together. It's not gonna take you that much time, but I would appreciate this review, right? So some of these tools that you can use, and even if you use the one on the right-hand side, that will actually ping your colleague in Slack and say something like, hey, he only has a little tiny review for you, could you review it now? Or it might say, hey, it's a bigger review. But, so you can do all that. But the thing that came to mind for me, I've been actually experimenting with a routing rule when I was talking about PR, a routing rule called the time bomb. And what does it mean? It means, okay, we have a rule that the PR is open for 48 hours. And anyone can review during that time, and if a review starts, the bomb won't go off. And bomb's probably not the best word, but you know what I mean, right? But if it gets to 48 hours, hey, I can do a self-review and I can merge it because I don't wanna wait. I think I have high quality. You put the power back in the hands of the developer. So one of those rules that's kinda saying like, hey, it's open to the team, I'm showing it to the team for the review, but if no one cares to get to it or doesn't have enough time, let's get the code merged and get it out there. So you might like a rule like that for you. Yeah, so we're debating whether to put that as a default rule in that YAML file or not. We're gonna come up with a few different rules. And then it's probably obvious, but you can edit the rules and you can do whatever you want with that. I can read what you're saying. I saw a sign go up. Oh, okay, one minute left. Yeah, no problem. It is a culture thing. And the thing on the right hand side, the linear bead.io, people are using that for retros because it brings data. Your culture is displayed in data. Hey, we're not getting to these PRs. Is it a good thing? A bad thing? Is everyone cool with that? Are we not cool with that? So data visibility is a good thing in the culture situation. All right, well, thank you, everyone. Guess what? My time is up.