Pair programming has its challenges, but the inherent benefits outweigh the downside, especially as you work to overcome the issues that slow down your team as you grow.
← All talks
Turing Fest 2020
Pair Programming for Skeptics and Practitioners
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Hello, and good morning if you are in an Eastern time zone or similar. Excited to talk to you all today. I agreed to give this talk because I believe in something that I wish were more widely known in our community. And that is that I think there's a practice that greatly reduces many of the biggest problems in software development for very little cost.
And very few people are using it. And that practice is pair programming. And I think adopting it can be a huge competitive advantage for your team. So the rest of this talk will be me trying to back up that argument and discussing some of the costs that do come with pairing because there are some.
And then also discussing how you might get started even if you have a bit of a skeptical team. So let's make sure we agree first of all on what we're talking about. My definition of pairing is pretty simple. It's just two programmers looking at the same piece of code at the same time, working on it together.
Now there's different styles of pairing. You might have a dedicated driver and navigator. You might take turns. You might do ping pong pairing. You might be in person. You might be remote. To me none of that super matters. That all falls under pairing to me.
If you have two programmers and they're looking at the same piece of code at the same time, that's pairing. So having defined what I'm claiming is the solution, what are the problems that I'm claiming pairing helps with? So number one is a problem that I think doesn't actually get talked about enough in our community.
And it kind of surprises me, which is that basically all software development projects slow down over time and often quite substantially. So greenfield projects, shipping speed is basically always high. Right? Like everyone loves the first six months of a project. Super fun. Features are flying out the door.
Next six months, not so good or a little bit slower. And then it's in years two and three and after that, that you really start to see things slow down. And it gets harder and harder to ship new features, to add new things.
And it's around year three where you start to see it gets to be so painful that people will start advocating for rewriting something entirely, which is sort of the ultimate slowdown. So I want to talk about why does the slowdown happen and how can pair programming potentially help.
And so I think a good way of talking about this or analyzing is saying what slows down slow teams? What are the things that teams that are shipping slowly spend a lot of time doing that teams that ship quickly are not? So the first one on this list for me is and a big one fixing regressions.
So slow teams often break things that used to work, right, without noticing it. Another is fixing fresh bugs. So I think slow teams tend to push code into production that doesn't consider all the edge cases in play. And this new functionality that was done actually isn't done because it has problems that then need to get fixed shortly thereafter.
And then the third thing is fighting bad architecture. So I think slow teams tend to build on shaky foundations, which is actually very easy to do. It's hard to predict what kind of architecture you're going to need in the early days of a project.
But I think the defining characteristic here is slow teams don't bite the bullet and fix it. They don't actually go back and clean up that problem. So how can pair programming help these things? Well, go to regressions. So there's three things. Regressions, number one.
Regressions are preventable with a good test suite, right? But if you ask most people like, hey, what's your testing strategy? They go, well And they have a little bit of tinge of guilt because they know they should probably be writing more tests, but they don't do it super consistently.
In a pair, when you're pair programming, the level of testing tends towards the maximum of the two developers involved. I think that's actually a really important point and so I'm gonna come back to it later. But let's keep moving. Number two is the fresh bugs I talked about.
Bugs tend to hide in edge cases that we didn't consider. So in a pair, you can fight this because one developer is not typing. So if you and I are pairing together and I and I have the keyboard, you can actually be sitting there thinking, what are the edge cases that are involved here?
What happens if this is nil? What happens if the user is not signed in? And you can catch a lot of these little edge cases because you're involved in the process. You're there. You have all the context. But you don't need to actually type the symbols on the line.
You're thinking a level of or two of abstraction higher. And so we can prevent ourselves from pushing these bugs into production. And the final thing is the bad architecture point. So if you're pairing things, every architectural decision is automatically considered by two people.
And so you're going to tend to find superior solutions. And it's not just that you're going to start with better architectural decisions. But also there is a social pressure to not do the wrong thing and just build another build continue to build on these shaky foundations.
I think you're much, much more likely to bite the bullet when someone else is with you and you say, should we just rewrite this part now? Like I know we know that this is not how we wanna to have this code look over the long term.
And you know you have support, by the way. So sometimes it's a little bit too intimidating to refactor a bit of code because and like rebuild this this this sort of architecture part because you don't feel supported. But if you have someone there with you, you might be a little bit more confident and willing to tackle that.
So I said earlier that the level of testing of two programmers tends to be towards the higher of the two. And I think this is actually a really huge point. So pairing is like a maximization function for two people and their skills. So it's like you get the best of two developers.
Now let's imagine that you and I are pairing on something. And I am great at multi threaded code and not so great at documentation and testing. And you are not so great at multi threaded code, but you're great at documentation and testing. If you and I pair on something that involves those three things, we can end up with a work product with a final deliverable that is great in all three of those categories.
But if you and I had either you or I had tackled this project separately, it would have had those weaknesses in it, in the areas where we were weak. And so there's this interesting thing which is that if we pair on something, we can end up with a final result that is better than either of us could have done independently.
I think this is like such a critical thing to a huge point in favor of pair programming where it's a little bit like one plus one equals three. Neither of us could have made something as good as both of us can make together.
So at the end of the day, it's code quality that slows down projects. And I believe it's pairing that gives you your best shot at producing really high quality code that prevents the slowdown. So let's look at the second problem that I think pairing helps with, which is hiring.
So everyone wants to hire great developers, but it's very hard to, right? We'd love to all hire a bunch of senior developers, but they are expensive. And even if you can afford them, they are hard to find because of market conditions. And basically every company I've worked at had this problem.
But the best ones went after this fairly aggressively by starting with junior developers. By looking for junior developers and then training them into the developers that they want them to be. And a key approach to this was pair programming. So this is actually how I got into programming professionally.
So I had no professional programming experience. And I wanted to break into the industry. And I was teaching myself Ruby on Rails on the side. And I was fortunate enough to bump into a job posting for a junior Rails developer. There was a institution in Boston that had been looking for a senior developer for like six months, and could not find somebody, because of the reasons that I mentioned.
And so eventually they gave up and said, alright fine, we'll hire a junior person and we'll train them into the person we want them to be. I saw the thing. I applied. It worked out. I started my first day. And on day one, I was basically kind of useless.
I could not ship any sort of code professionally. But I had a very prescient boss and he said on day one, he's like, grab your chair. Come sit next to me at my desk. And then he took his monitor and he moved it from right in front of him to between the two of us, so we could both see equally.
And he said, go grab your keyboard and plug it into my computer. And then we started working together side by side. And we did this for hours, basically every day since I started for the first few months of my tenure there. And never in my life have I learned as much as quickly as I did during those months.
Because pairing wasn't just teaching me how to write better Ruby and how to use Ruby on Rails, but I was learning all of those auxiliary skills of a professional developer. I was seeing how a great developer debugs problems. How he used his tools like Vim and Terminal.
This is when I discovered my love for Vim and really fleshed out my skills there. And even saw things like how many commits like did he split things into? What did his commit messages look like? There's just so many little things you can learn when you pair with someone.
And by the end of those three to four months, I was a totally productive member of the team. And it was an investment that really paid off for them. And ended up with the developer they were looking for. So hiring I think is one of these huge problems.
It's very challenging. But I think a great approach is to start a little bit earlier on the skill level curve. And then build up the programmers that you're looking for. And I think pairing is just the highest bandwidth tool that we've yet found for this.
And by the way, this makes sense because like the apprenticeship model has been around for hundreds of years. Right? If you wanted to become a blacksmith in seventeen hundred, you were gonna do it by sitting next to, standing next to you, working next to you, someone with more experience than you.
And they would constantly give you corrections and you would make things together and you would slowly up your skill level over time. So that's the second problem I think pairing helps a lot with. Number three, and the last one is turnover. So it's great if you can hire great people, but if you lose them, it doesn't really matter, right?
So programmers, we programmers, I think tend to be very driven by skill acquisition and improving. So we're always trying new things. We like to learn new techniques. There's something about programming that it draws in people that love to learn and to tune their skills up.
I don't think I've ever paired with someone and not learned something. Even when I was the much more senior developer, even pairing with a new person. Because the Venn diagrams of your knowledge never fully overlap. Right? Even a new person might know a keyboard shortcut or a tool or a trick or something that you don't know.
And so just about every time that I've spent a decent amount of time pairing with someone, I've picked up some little thing like, wait, how did you do that? What was that right there? What's this program you're running? That sort of thing. So turnover I think can be greatly helped by pairing.
And finally, I will link you to a site at the end here. Well, there was a study that showed that programmers that pair regularly were reported higher job satisfaction in a statistically significant way. So I will throw a link to that towards the end.
So this is not just a gut feeling here. Now there's some challenges with introducing pairing to an organization. Number one is that there's sort of this really obvious counter argument, which is like, it seems like this is gonna be slow, right? Like if we're taking our developers and putting them together, surely this must be slower.
But I think pairing is slower in the way that writing tests is slower. So it's like, yes, maybe today you are paying a bit of a speed penalty perhaps. But over the long term, you're going to be moving faster, Right? That that test suite over time protects you and keeps you moving quickly.
And so yes, it takes longer to add tests to something that you just wrote than just YOLO shipping it. But it's going to keep us going at a consistently quick pace for the long term. Also for what it's worth, the you'd think the penalty might be something like a hundred percent, right?
Like we're gonna get half as much done because we are doubling our programmers up. But there was a study that again I'll link to of industry programmers, not just college students. And it's found the pairs are moving forty percent faster typically on programming tasks than individual people.
So they're not getting blocked. They're moving quicker. So you do pay a bit of like a raw horsepower penalty today, but it's not as deep as you might think. And over the long term, I believe it pays off super well. And and by the way, I personally I feel that if you are pairing on something, if you have two people pairing on a feature, then you don't need to then do code review after the fact.
Because pairing is like live code review. You might still want to. I think there's some reasonable arguments to be made for it. But I think it's also a reasonable counter to say, we paired on this. Let's not we don't need to do a separate asynchronous code review on it.
And so you're saving this time. You can sort of claw some of that time back by saying, we're saving on code review. We're just doing this like live code review as we go. Another challenge of introducing pairing is that it is definitely mentally more challenging.
You will sleep deeper on days you pair program than those you don't. And it's because you sort of have to stay constantly on. I think we tend to not realize how many breaks we're taking, how many mini little disconnects we're doing, like how many times we open Twitter or email or something like that or pull out our phones.
But if you're pairing with someone for a few hours, you will know it because it becomes like socially untenable to do this. And so you just sort of stay in the zone and stay productive. And now part of that's great because you're probably gonna get more done.
Three or four hours of pairing I think is kind of like eight hours of solo work. It has like a lot of interruptions. But it is definitely mentally harder. You need, I think, more longer real breaks. So if you're pairing, make sure to build in like away from keyboard time.
Don't just like say like, let's pause and I'm gonna go read Twitter. Like get up, go do something else. Play ping pong if you're in the startup world, that kind of thing. And the final challenge is that pairing is actually just not for everyone.
I think the I think the idea that programmers are all introverted is probably a bit exaggerated. I think a lot of lots of us are extroverts. I'm one. And but not all of us are. And pairing requires a lot more social interaction. It's definitely more draining to have to consider another human as you're working.
And so some people just won't like it. And if they've given it an honest try and done it with good people and decided it's not for them, that's okay. That's just how it is. So you're not guaranteed to have a match there. So just a couple more things. How do you introduce pairing?
I have a few tips here. So I think pairing, kind of like Vim, has a bit of a marketing problem. In that people hear it and they think pairing is this big special thing. Need to learn how to do it. It's hard. I'm not a pair programmer.
Like, it's like a religious thing. It's like, oh, I'm I'm not I'm not that. I don't pair. But I think you can kind of sneak it in by downplaying it and just say like, hey, Mary, like, could you take a look at this with me real quick?
Or like, you helped write the authentication code. Would you mind just like give me a second set of eyes over here? And look, don't even call it pairing. Just act like, you know, we're just we're just working on something together. Because that's really all it is. Yes.
You can get better at it. Yes. It actually is a skill. But in the early days, to like just start it and try it, I think you can kind of downplay it and keep it kinda light and just say, can I just get a second set of eyes on this?
No big deal. I also recommend you start slow with kind people. So do short sessions, maybe half an hour, maybe an hour. And do it with people that are nice. Like like there's it requires a certain amount of empathy and compassion to pair well.
And so start with people you think are capable of those those emotions. And then finally, I wrote quite a bit about this at this site here, learntopair dot com. A lot of articles on even doing your first pairing session, templates for good pairing, anti patterns that people typically have in pairing, how to pair with a junior developer.
It's everything, just about everything I know about pairing and totally free. Feel free to check that out and that will help you kind of get going. But that's what I have for today. So thanks very much. Let's bring Ben back in for for a follow-up chat.
Hey, Ben. Hey, how you doing? Good. Thanks. How are you? Yeah, good. I'm good. Looks like it's a nicer day in Boston than it is here in Edinburgh. It's bright, but I wouldn't say it's nice exactly. Well, I'll be cycling home after this and I'm gonna get very wet, put it that way.
So really, really fascinating talk, especially for I mean, I'm I've been in the startup world for for a while. I've been in software companies, but I'm not an engineer. So pair programming is not a thing that I've obviously done. But really, really interesting listening to particularly from, I guess, a founder perspective or thinking about the overall efficiency of startups.
Just a couple of questions then on it was something you mentioned at the end about working with people who are nice and empathetic. How much is how much does constructive pairing depend on interpersonal relationships, trust, etc? Yeah, a fair amount. I mean, it's definitely inherently a social activity.
And that is sort of its strength and also possibly its weakness, depending on the kind of people that you work with. But, yeah, it's interactive. So you you do need to do it with people that want to do it, I suppose, and, like, have the the social skills to pull it off.
And you mentioned it as a way, you know, you gave the example where you were brought up to speed really quickly in the company joined three, four months, you were, you were the developer that they wanted, or that they would have hired, had they had the bigger budget.
And I mean, so many startups can identify with that problem. That maximization of skills of developers of of speeding up quality code, you know, you made a bunch of arguments in favor of pairing. But is that do you think that's the main one from for startups?
Why why this is something they should be doing? Maybe. Yeah. I mean, so for startups, their products are young. Right? So they have less of the slowdown that happens as your product gets larger and there's more code to maintain. So it probably is the case that for most startups, hiring is probably their first priority as opposed to like, continue keeping their shipping speed super high.
Startups will tend to go fast, think, kind of by the nature of where they're at in the product development life cycle. Yeah. Yeah, that I agree with that. That makes sense. What about if you have two engineers of sort of similar skill levels or experience?
Does pairing still work well in that in that kind of scenario? It's it's a different thing, obviously, Totally. Yeah. I mean, it actually I found it works well in basically all it doesn't the the skill level difference doesn't matter. It doesn't matter if it's really big, and it doesn't matter if it doesn't exist at all, actually.
Think it's there's there's there's benefits to pairing kind of regardless of what the relative skill is. Even with someone who is sort of the same skill level that I am, they definitely have different knowledge that I have, right? Like, no two people have exactly the same knowledge of programming and techniques and tools, and things like that.
So, it's kind of hard to not bump into something and learn something from someone when you pair with them regardless of skill level gap. Yeah. Yeah. That sounds that sounds like it makes sense. The the so you were developer at Thoughtbot, and you you decided to leave to find your own company.
Was this it was just the classic case that you were trying to solve solve your own pain? That, you know, you you were doing pair programming at Thoughtbot, and you were like, wow, there's gotta be a better way. Yeah. There I had used some tools for remote pairing, and one of them that I liked a lot what got bought by Slack and went away, Screen Hero, and there was nothing on the market that was quite as good for it when I wanted to pair remotely.
I kept asking friends, hey, what are you using now that that you're that Screen Hero is gone, and no one had a good answer. So eventually, said I I feel like I'm gonna there's like market opportunity is kind of hitting me in the face.
I kinda have to take advantage of it. That's why I started the company that I did to to make a a tool for remote pairing. Yeah. It's interesting, isn't it? How often that something gets acquired and disappears, and they've already kind of proven the market wants it, and, you know, like the amount of times you hear people still talk about Google Reader, for example.
Questions come in from Mohammed Alisa in our audience, asking you about conflict. How do you solve conflicts during pairing? Sort of a broad question. I don't know if there's pairing specific conflict is or like that I'm not sure I have pairing specific techniques for how to solve conflict.
I think it's how do you solve conflict in general? I don't know. Sounds complicated? It definitely it's depends on the the case by case, and who's involved, and what the nature of the conflict is. But again, this is I guess the hardest part hardest part of pairing is that you're more likely to have to negotiate on the fly with people as you're working on something, as opposed to kinda being off on your own, just making your own decisions.
So, I guess the I guess my advice would be kind of just general advice for solving conflict, which is to sort of state your case, and why you think it should be this way and not that way, and try to stay calm, and be friendly about it if you can.
And then, at some point, if you if you can't reach a consensus, then I think a good tool is called disagree and commit. It's just like, okay, don't think this is the best path forward, but I'm going to having stated that, I'm gonna go ahead and just support moving forward with your vision.
I won't drag things down. That would make sense. The so on, you know, tuple is obviously designed for for remote pairing and remote has become is having its moment. Have you found that there are unique challenges? You know, you mentioned in your, in the example of the mentoring that you were literally plugging into to the other person's screen and, you know, what what would you say are the remote challenges in in or sorry, unique challenges in remote pairing?
There's not a ton. It's pretty similar. So like with a webcam, and you know, good quality audio and low latency, it's pretty close to like sitting next to each other, only without like the possible physical uncomfort, like uncomfortability of having someone like right up in your space.
So it's it's not a huge downgrade. It does, it is a bit harder to read people, just from like, just face. Like, body language can be useful, like, can kinda tell if someone's checked out, and you can see if they seem tired, are they slumping, are they upright?
So, I would say, the probably the biggest burden is just that it's not quite as much signal, and so, it's probably easier to lose someone's attention, and probably easier to not quite know where their heads at. So, it probably requires a little bit more attention be paid to is your pairing partner engaged and and with you?
And do you think it it makes sense to to stick with the same pairing partner for a long time? Like, you get that dynamic, you get you understand each other better, you're you're you're kind of get past those problems? Or is there something to be said for, you know, let's freshen it up, let's switch every six months or whatever, whatever cadence that that you might think is best there?
Yeah. I think there's a lot of good to be had in in mixing up pairing partners. One nice benefit of pairing that I didn't touch on, just due to time constraints, is spreading knowledge around the team. So, it's like programming skills to spread on the team, but also just knowledge of the code base.
Like, one thing that can slow teams down is like, Oh, well, John wrote the authentication system. So, we should have him do this thing. And you sort of lose that flexibility of having people have general ownership of larger parts of the code base.
So, I do think it's nice to to pair with a variety of people, so you get access to the things that they know in terms of like the code and also just their their skills. And from switching to the to the startup perspective, For you personally going from being a developer to being a CEO, I mean, I'm assuming you're still developing, you're still working on the product.
But now you've got this whole other hat, this whole other life. Best bits in that toughest bits. How's that been? The toughest is probably giving up coding as like my main activity. So I I do write a little bit of code these days, but not very much.
And after having invested so much time and having a lot of mastery in that, going to instead working on things that I'm not good at because I have a lack of experience with them is is a bit challenging, for sure. And just because I love programming, so I don't I don't not having that in my life as much is a bit difficult.
The best bit is adding awesome people to the team and seeing how big that impact is. So, I had never built an organization before, and now I'm starting to have this experience of like, adding another great person. And then, suddenly, we have this huge increase in productivity, but also just like a new perspective, new abilities.
It's it's really, really gratifying to see what the kind of leverage and the benefits you can get by by hiring awesome people. Yeah. No. It's definitely one of the most satisfying parts of building a team, especially if you're you're hiring the people that are good at all the things that you're bad at.
It's it's kinda magical to see when they can when they can unlock things that for you are kind of a mystery. How so how big is the team now? We are just four full timers and two part timers. Okay. Okay. Cool. And remote or a mix of in office and remote?
It's a bit of a it's a bit of a mix. So I have two co founders, and the three of us all live in the same town. And so we see each other in person somewhat frequently. And then the rest of our folks are all distributed.
Yeah. Yeah. And it's how how you found, you know, the COVID sort of forced remote on people that otherwise wouldn't have maybe got into it, particularly corporates. You know, I've been speaking to people who, in things like law firms and accountancy firms where, you know, it's funny, on the one hand, they're like, this is amazing.
You know, we don't need to wear our suits or get dressed up or whatever. But there's also a lot of areas where they're struggling and, and those a lot of their teams and processes are not set up for remote. Have you found that there's been a big, you know, like an increase in demand has has people seen seen COVID related growth?
Or is it just, you know, sort of regular year for you guys in that sense? No, no. It's it's been crazy. We had huge growth. March, April, May was like an enormous explosion of of customers and usage. And the rate that we're adding customers is still much higher than it was before.
And things were going well before, before COVID. So it was we went from like a quite a healthy growth rate to like a kind of ridiculous growth rate. And the types of companies we're seeing sign up has also changed. So in the earlier days, we were getting more startup y, very tech focused companies.
So some larger companies, but they were usually like very technologically advanced software companies, typically. Now, I'm seeing like Fortune five hundred companies sign up that like are like, you know, retailers, things like that, and like, where you wouldn't necessarily expect them to have like a large technology investment.
So the the profile is changing a bit. Yeah. Yeah, for sure. I mean, think that that probably matches with the just that general thing we were talking about about, you know, the companies plenty of companies are doing remote that we're gonna do it anyway, or or, you know, all they had to do was not go into the office because they already have their laptop with them versus those bigger companies.
From it, just out of curiosity, an InfoSec perspective, are you on compliance and, you know, working with these Fortune five hundred companies? That's probably there's probably been some twists in the tail there. Right? Yes. Yeah. Learning how to do enterprise sales has been an interesting process, especially for a developer.
Like, the nerd in me wants it to be really efficient, and like, to fix all the processes, and like, it's just there's so much resistance to that. But yeah, we did have to, like, we did end up getting like an external security audit to help make sure we were like, doing the right things.
We fill out a lot of questionnaires and vendor on boardings and things like that. It's been and also, we've had to build out features for these enterprise customers. Nothing too crazy like that we didn't wanna add anyway, but they sometimes do have sort of bizarre requests that you might might be surprised by.
Like, instance, like Tuple is a remote pairing app, and it's one of its core value propositions is that you can do you can remote control the machine, like, so, as if you were sitting there next to your pair, and also had your keyboard plugged in.
But Sure. We had an enterprise customer ask like, Can you disable the remote control for everybody on the entire team? And we were like, sort of? Like, yes, we could technically make that happen, but like, shouldn't you just go use Zoom at that point?
Yeah, it's, it's always interesting to hear about this sort of culture clashes, especially around technical stuff, where startups have this sort of very obvious way that you do it this way and enterprise, just not not seeing it that way. Yeah. You mentioned the the enterprise sales and that whole strange new world.
So have you are you the de facto salesperson for the company, or have you made a sales hire yet with four people, I guess? No. We hired somebody in sales, and that was a wonderful instance of that thing you touched on, of like, how nice it is to hire someone better than you at a thing.
I I sort of lack the patience for enterprise sales, and we hired someone who is really into it, and loves it, and is good at it. And it's been like amazing to take that off my plate and yet have it still keep going.
Yeah, yeah. No good salespeople are are they're pretty incredible. And for any of our any of the viewers who are watching or who watches back later on, someone who's in a technical position, and they're thinking of founding, and they're going to be in maybe in that moving away from the keyboard a bit and getting into the more leadership role.
Any any tips or any like, oh, watch out for this thing, because this this really got me. I think it's such it's challenging. Like, it's I think you're gonna have the tendency to wanna stick with the the technical stuff. I think I maybe I might have spent too long on in that mode, where I was like, still writing code, and still doing that kind of individual contributor work, when I should have been thinking about hiring the next person, or like building out processes, or things like that.
I do also think, I'm still new to this, but management is a skill, and like being a leader, an executive person at a company is a skill. And so, it's worth getting training or like learning about it, reading about it, hiring a coach maybe.
And don't just don't just kind of like, bumble your way through it because it will affect the people you hire, and so you don't wanna be bad at it. Yeah. And have you have you managed to find any any good mentors on for the CEO journey?
I have been working with a coach, yep, that I like. Executive coaching, I think, is tricky. I think there's a lot of not that great people out there. It's a little bit like SEO consultants. Like, there's like a handful that are really amazing, and then, like, a lot of them are kinda just like, So I can recommend one person.
Her name is Starla Sireno, s I r e n o. I'm not sure if she's taking new clients, but she's great. Excellent. Good. Good tip. Okay, Ben, think we're gonna wrap it there. So thanks very much for joining us and walking us through pair programming.
And great to have you here. We'll perhaps get you over to Edinburgh sometime when we're in the in the next phase. Great. Best of luck with the with the triple journey. So thanks for joining us. Awesome. Cool. Well, thanks for having me. It was fun.
Okay. Thanks, Ben. Okay, so that's that's our talk number two wrapped up for today. Final session of the day starts at four pm. Four pm UK time. So twenty five minutes from now, where we've got Ran Fishkin coming in to tell us about his views.
And he's got strong opinions on the matter about how we can navigate as marketers navigate the world of, well, maybe even the world beyond Facebook and Google. So that's that's at four pm. So we're gonna take a quick break now and see you back then to have hear from Rand.