Remote Mob Programming with Ulrika Malmgren

How'd you like to listen to dot NetRocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month, we'll get you that and a special dot NetRocks patron mug. Sign up now at Patreon dot dot NetRocks dot com.

Hey, Carl and Richard here with your twenty twenty four NDC schedule.

We'll be at as many NDC conferences as possible this year, and you should consider attending no matter what. The Copenhagen Developers Festival happens August twenty sixth through the thirtieth. Tickets at Cphdevfest dot com.

Ndcporto is happening October fourteenth through the eighteenth. Tickets at Ndcporto dot com.

We'll see you there, we hope.

Hey, guess what, it's dot net rocks number one four h So it's almost the beginning of World War One.

That's it. Sure we are, I'm doing this for a while. Just wait to use you the comment today, friend, you'll you'll laugh.

Oh that's gonna be good. Well, anyway, I'm Carl Franklins, Richard Campbell, and we're going to be talking to Ulrical Melgren in a few minutes. But first let's do that thing we love with a doo dooo dudes. Music? Better know a framework? All right? Man? What do you got? So? Our friend Simon Kropp sent me this. It's not as repo, it's Tyler Brinks and the name of it is Sequel Parser dash CS. It's an extensible sequel lexer and parser for dot net. Interesting. Yeah, it was ported from a

Cool?

Why do I want this? What's wrong with t sql?

Well some of us aren't tseql gods, such as yourself Richard. But I'm a god of anything good. Well you know I think you are.

But okay, just another way to get at the data.

Yep. I love it. And you know that's it and if you need it, you need it. That's what I think. That's fair. I buy that.

Yeah.

So who's talking to us today, Richard? Well, you know, I know.

We're talking about MOB programming, right yeah, And we've talked about mob programming before, so I figured I'd go back and what he's out of coincidence? But by the way, what he's still doing his thing, he's doing he's still doing workshops, he's out there. Yeah, by coincidence. The last time we talked about mob programming was in twenty thirteen

We did something weird.

We actually talked to an entire mob, which included Woody Zoo right about mob programming. And actually we had a ton of comments on that show, so I figured I'd drag out a ten year old's comment. I mean, what's the big deal?

Really, it's a very American thing, right, It's like, oh, you like pair programming, how about mob programming? How about it? The only we know it would be better?

More So, ten years ago, Richard Garside wrote this comedy. He says, I'm wondering how far you can scale a mob? When does it stop making sense to recruit new people for one mob? And what point you start multi mobs?

See? See that's exactly my point. More more a mob not enough for you. More mobs make more mobs. You know.

I think we're gonna take that. Got to take that question over to el Rica at some point. So, Richard, thank you so much for comment. I hope you still hear this ten years on, or at least you'll get the email prom and so forth. A copy of music code BI it is on its way to you. And if you'd like a copy of music Cobe, I write a comment on the website at dot at Rocks dot

Cobe by still going strong after all these years. Yeah, and still a favorite way for people to get into the zone when writing code works for me. And you can follow us on X Twitter because we've been there for years before it was X. Of course many many years before it was X. But the cool kids are hanging out. I'm mastadon, I'm at Carl Franklin at tech Hub dot social, and I'm.

Rich Campbell at Masdon dot social.

So send us a two. That's another way that you could get a copy of music to code by for sure. Okay, let me introduce our guest. Ulrika Malmgren has been in the software industry in some form for twenty years or so as of this recording. Anyway. She started out as a software tester, using exploratory testing to study and learn about software and users. After realizing that quality was more more than just testing, she worked as an agile coach

Thank you, thank you for having me.

I was really excited to see you had this talk at NBC Oslo, and I'd meant to do the interview there in person, but things happen, so now we're doing a little bit later from there because we haven't talked about MOB programming in ages, but clearly it's still going on wood He still doing his thing, like there's plural size videos on the topic. How do you explain mob programmer. That's team programming.

Ah, I would explain it as the entire team is working together, so we're programming together. I liked how you said, like para programming on steroids were even more power programming.

But also.

Not just the programming part of it, So the entire team is working together, but maybe also answering emails, preparing power port presentations, all the other stuff that you do when you're doing software development.

I was going to say, the last time we talked to Witty about this, everybody was in a room and one person was driving visual studio or whatever the software is, and everybody else is sort of chiming in. And now, in the age of zoom and remote, that must be quite a bit different, isn't it.

It is, but it works really well, so we do that.

Actually, my team is fully remote, so I get to spend a lot of time with my cat, and that's good. But what we do is we have a computer at the office, and we're using ANIDSK to remote to that computer, and we have a slack or a team call or something ongoing HM, and we talk and we do all of our communication and programming on that computer. So I

I find that a fairly common practice putting my run ass hat on where the sort of data integrity points of view or keeping all the source code in the company means you're just logging into a virtual machine or a remote instance somewhere and that's where all the code lives, and the home machines don't actually have don't ever run the code, they just have access to it through a console.

How many monitors do you have?

I have the one is a big one.

That's the downside of it, because we only have one monitor on the office, so we that's the one we have connected to.

And I certainly remember that from some of the other conversations we had in this space where often somebody in the MOB is on another machine and they're searching for code samples, and other cases of addressing this particular problem like many in some cases totally short circuit the development process, like, wait, this has been done. Here's an example, and it's starting to look like what we're already doing. Like, let's go dig into this exactly.

You can while you're troubleshooting. You can have multiple threads of googling going on at the same time, so you can be I'll stack over frough a couple of people trying to find what could be a possible solution for this at the same time if you want to.

Yeah, so I knew what he told us about the metrics being you know, productivity wise being very very good. Are there any new numbers or any numbers that you can share with us in terms of, you know, single developer at a time and a team working versus pair programming versus mob programming.

I'm not aware of any, and in our teams we've only done this.

We don't have any numbers to compare to.

Yeah, but I feel that there's so many situations where we are that this software team and mopgram is just helping us so much that I would have to say that the numbers would have to be good towards more programming. I'm thinking of all the during the summer. Now, because of vacations, I was sometimes alone at work and I was sitting there and it took me a while to figure out why I was doing this stupid mistake, which would have been something that my team would have pointed out immediately.

They would have seen immediately that I was doing something.

You say, this is an interesting dynamic here. Now, what if you have I don't know, let's say you have a team of thirty and ten of those team members are working on this part of the app, and ten are working on another part of the app, and ten and working on any Does everybody work on the same thing all at the same time, so like there's no such thing as a merge conflict or how does that work?

Yeah, I'm not very good at bronchos because I've never used them.

Yeah wow, yeah those.

Sizes though, So we have teams of for now, two to five people.

Yeah, yeah, so.

We don't have that kind of a size of a team.

And that's a dressing a dressing.

Their listener Richard Garsides comments like, how big is what can a mob really be? Five seems like a reasonable number where everybody can still be engaged.

Yeah, I would say three is really good, and then yeah, the engagement thing is a thing because if you were doing it, So one way of doing more programming is using a timer and having people rotate at the keyboard. So you'd say, every ten minutes we change driver, we changed a person is sitting at the keyboard when is actually typing the code. But all of the time you

Once an hour y.

Yeah, and for some people.

If typing is what you like in programming, right, I mean, I got to think there's some natural typers and some natural searchers and some natural reviewers.

Too, exactly.

So we have tried those kind of rotation patterns, but we've also sometimes gone away from them and have had a more natural kind of cycle of some people like to type more, some people like to go go think more.

Yeah.

So to get back to what I was saying before though about multiple team sections working on different sections of the code. What if there's somebody on the team that you know when you go down a rabbit hole in a particular thing, that they're not even working on. Do they contribute as well? Do you have to take time to explain what the other people have done to those who haven't done it yet. I mean, there is that a problem.

That's actually sort of an excellent point towards my programming and the fact that when you are in the mob and you're working on a thing, you get to see the rabbit holes, so to see, like, Okay, we went down this path and we found a dead end. This

The things that were dead ends.

Sure, you get to learn the thinking that up to the actual solution, but I.

Can also see how you know, if you've got parallel sections of the team working on different aspects of the application all at the same time, are they three times as productive as the whole team working on one of those at a time? Like some people may think.

That, yeah, I think you want to have very like your own domain or your own application and not have to share that with someone else.

I think that's also a key to getting making it work all right.

So breaking down the teams into sections that are working on a particular thing. We're all working on that thing. Yeah, that makes sense.

And the point being that, just like we saw with pair program, and there's two pairs of eyes on something, you tend to make fewer mistakes, Like that code tends to be very check inable and sticks around. There's less iterating on it. I like the third pair of eyes

Like? You know, it's kind of like a continuity person on a movie set, isn't it somebody who's got a sixty thousand foot view of everything and says, oh know, in that last shot, the coffee mug was half full. You got to fill it up again.

It also sometimes looks a bit back when we were in the office and doing this. It looked a bit weird to the others because we were sitting and discussing a lot, and we were talking and talking, and then finally we reached consensus about what is it we're actually solving, how do we want to go about this, what's a solution we can all stand behind. And then when we finally reached that consensus, just typing out the code wasn't really something that took us very long.

It was the easy part because you had consensus. And I got to think, if you've got four people agreeing on a path and they're really agreeing, like there's not a lot of bullying going on, the quality of that's going to be pretty high.

Yeah, it is.

And also you get but you have to sort of learn to sort of this is something I really want to stand up for, right, I'm just I'm not we're doing tabs and not spaces. I'm going to die on that hill now, that kind of thing. And then you need to figure out what are the things that I'm willing to let go of and that I'm willing to slip because I think you can't win every bottle. You

You can't fight to the death on everything, and nobody's going to want to work with you eventually. Like there's just there's got to be some This is not that important to me, it seems more important to you. Let's try it, because let's face it, none of this is permanent. You could go back and revise. Yeah, better to just get to a path where it's like, I don't see a problem with that. I don't know that I do it that way, but I don't see a problem. Let's

Yeah exactly. And also you're learning like IF when you're IF. I'm not very good at CSS, for example, but my colleagues are better than me, so if I were to solve this future of my own, my CSS that I would produce would be at a certain level, which is not very good. But when we're doing this together, we always get like the best person's level of knowledge, right, which is also really interesting and I'm learning at the same time.

Do you switch keyboards at that point? Like does the CSS when you hit to the point where it's like, well we need little CSS here, It's like, all right, already take that.

Yeah.

Maybe the other way around though, maybe I'll take that because I'm not so good a right, so you can be the one.

To turn yeah and let them coach you through exactly better see sess yeah, and sharing that knowledge.

I need to get this from my fingers, to get the mechanics of it.

And that's an.

Interesting angle on this, and it also speaks to I don't want three of the same person on here on this project. I want an array of skills.

I'm trying to think of the pushback, right, If you have a team of five and you go to your manager and say, hey, instead of everybody working on stuff and branching and merging and all that stuff, why don't we work together? You know, the pushback might be is I think, well, you have to prove that the productivity exceeds what you can do individually and the quality. Productivity and quality they go hand in hand.

Yeah, And people always say that, and it's really interesting because has this sort of working individually, has that really proven itself to be good productivity and good quality?

M Right?

Like did we always we were doing software perfectly on time, bug free, and then some people came along and say can we work together? And everything went downhills from there.

Just do more unit tests. But I mean, I think I want to play with the math on it. So if we've got four people in a four week sprint, each takes a task, all right, in the end of four weeks, you're supposed to deliver four tasks. Now flip that on his head, and four people work on each task a week each, all four of them work on it once. Are you going to get a better result? Can they deliver those four features one a week collaboratively?

That's always true, definitely.

So the quality question is not there the productivity question. The question is can you get those four features built that sprint. Like that would be my argument to the team lead. It's like, hey, our goals deliver these four things in the sprint. How we do it?

Don't ask? You know, you can't. You don't have the benefit of parallel universes. You can't say all right, it'll do bose ways and see what happens at the end.

Remember that there's so much more to program to software development and just the programming part. There's like reading the code. There's understanding the code, there's understanding why are we doing this in the first place. There's so many other things

Yeah, well, you have the potential for new kinds of nastiness, don't you like when people don't agree, and they're resistant to doing it the right way. Has it ever come to fist the cuffs?

I think it's even more passive aggressiveness in all the sines where you're sort of like, oh, I'm going to change this now, that's my turn to where on this future I'm going to change it to what I think is better.

Edit the code right in front of them. Yeah it's not pretty.

Well, Dave did this and introduced a bug because he wasn't smart enough to think that this and that. So I'll just fix it right now.

But also, my most the argument that I like the most about when you talk about productivity is the one thing that you hear in every retrospective is we have to be better at knowledge sharing.

That's always the thing that comes up.

And then you share all the time.

Yeah, and then you have people say like, okay, so we should have knowledge sharing sessions and then that doesn't happen, or we should we should be better at talking to each other, and then that doesn't happen. But we don't have to solve that problem because we're organically knowledge sharing all the time. Yeah, we don't have to think about is this an important thing that we need to tell someone else about.

Also really good if one person leaves the team.

Yeah, yeah, that's brilliant.

You've always got more pairs of eyes on the code. You've got them routinely teaching each other. You're not doing a separate teaching exercise, right, Like the fact that the skilled CSS person who's in the MOB walked you through writing better CSS, as opposed to doing like a luncheon learn on CSS, or just simply getting all the CSS work from the whole team all the time so that that person gets better and better but never really teaches

I think she use a different term than in the MOB.

That's what I want.

I want to flip this conversation around, like ken, I think I when I started to submit talks about this topic, I wanted to contrast it to the other way of working the thing that we were doing before. Right, And it turns out I felt like I needed to find a name for it because I would have more programming. That's not a particularly good name, But we talk about a software team maybe sometimes which is slightly better, but still a name for something.

How do you like it?

Ensemble programming.

That's very, very very the word area day. Yeah, yeah, I like it. But yeah, group programming perhaps programming.

Yeah, but what's the other thing then, what's the thing that most people are programming? Yeah?

Yeah, I like that one, and I think I like even better one that we came up with in the group, which was individual centered programming or development, because if we have if in more programming, you take the work and everyone flocks to the work and does the work. In the other style, you split the work to the individuals, right, but.

You still have this great ritual of merging it all together. But you now are oscillating between working individually and working in a team where you all have to collaborate on the integration cycle. Why not just be in the team all the time?

About mono programming and polyprogram.

Multi threaded, single threaded, Yeah.

Right, remin brain goes, oh, looks like the cat is taking a walk.

Yeah, but actually at this point about the oscillation of switching modes where you go head down on your own sometimes you know, in a tail spin, to try and produce your portion of the work. To bring to the team, and then you work as a team to do the integration just seems weirder than why if you just work as a team the whole time.

Yeah, And there's so much wasted time that is spent during those synchronizations, like the stand ups, Yeah, what did you do yesterday?

What are you going to do today?

And then you have long stand ups, so then you spend the retrospectives talking about how should we have better stand ups?

So first you waste the time during.

The stand ups, then you waste more time.

Than you're wasting the retrospective time talking about how you can waste the time in a better way.

Yeah.

What if everybody knew what everybody was working on because they all worked on it. Yeah, Yeah, suddenly this weird idea seems like the normal idea, and what we've been doing is weird.

I would think though, that in bigger projects where you have multiple silos of work, it could pose more of a problem, don't you What.

Would be some multiple silos?

All right, So let's say you're working on a project that has a solution that has thirty or forty projects, and you know they hire one person to work on this one project. Because it uses a particular language or technology or something, and another person is doing the data the back end, another person is doing the communications, right, I mean you've got a team of twenty or thirty people. That seems a little bit far reaching from me.

No, yeah, maybe this wouldn't be the best solution for that, but maybe it would be splitting up that problem.

Yeah, in a different way.

Yeah, let's come into this another angle. We kind of recognize that at any given mob, any given ensemble is three to five people, right, Yeah, you have a limit, and so there's a cadence as fast as you can produce code with that team. Even if that team works flawlessly together, they're in their their space, they know what they're doing. They're only going to put out so much code in so much time, as efficiently as they can be. And that could be a lot. A lot of projects

But at least they would be working within their own domain hopefully and wouldn't be crossing each other, so there'd be less chances for emerged conflicts and things like that. I hope, yeah, I mean would you would?

This is where the architect comes into play and we build boundaries to say here, you know, maybe negotiate the APIs. You might even have a mob of mobs here where one lead from each mob gets together with the other four mobs and they go through the architecture of how they're going to build those interfaces.

Middle management mobs.

But now you're getting to, like you said, a twenty to twenty thirty people working on a project that's a lot of code like but you know, and it's really a speed thing that they want a certain level of deliverables in a certain amount of time. So you're going to introduce complexity. There's no two ways about it. Like you can't can't get twenty people sitting around one keyboard and be productive. There's a threshold there.

But I like the multiple groups or multiple mobs or multiple ensembles idea because as as these five, four or five person units, they can be a lot more productive in their silo than the four or five individually working well.

And the bigger thing is recognized. Every piece of code is looked at by multiple peeple, so it tends to be a higher quality.

Yeah, produced more rapidly.

Yeah, you know, because as soon as we getting the mobs of mobs where now we could be back to well, why don't you just have individual developers they do the same consolidation because an individual makes more mistakes and a group makes for your.

And some simple rules like those pieces that are shared among all the projects that somebody has to update, you know, they have to eraise their hand and tell everybody, hey, I'm gonna be working on this tonight or tomorrow morning. Check all your stuff in by five, and then you know, have it done in a couple hours, and then we can you know, just prepare. I'm not trying to say, trying to prevent merch conflicts before they happen. Yeah, yeah, you would hope, you would.

Hope if you were to have some sort of synchronization in between, you can at least send any of the team members from any of the mobs, because they will have the same knowledge.

They should have all the same knowledge.

About their work at least delegates.

But just like you have somebody good at CSS, you might have somebody good at persuading.

So you want to send it to that mob. Interesting, it's not just about technology.

Well, it never is, right, Like, this is all about how well we work together and how we come to consensus on things, and how different viewpoints make for a better answer when done constructively. It can be done toxically, like what I what I find in you about this is like, this will certainly hunt down the toxic people in your group. If you can't make this team programming work, it's going to show fast.

Yeah.

It requires people to be humble and to be curious about other people.

Yeah, and to expect understand that they're they're capable, like they all deliver.

Yeah, you have to.

If someone has an adverse solution to yours, you have to be more curious about why would you that be a good solution in your opinion? Right, rather than to bash them and be sure that you win that argument.

Mm hmmm, well anyway, don't win any argument, right. The code bench it right, Like, I'm perfectly willing and I've been in that situation with two really smart people and said, all right, we're both going to write and we're going to have a bake off.

Then right, and you'll see what we That's a fun way.

Yeah, it's it's an approach. It has its own problems. Now we talk about metrics. Actually we should break for a moment for these very important messages, and we're back. It's done at Rocks. I'm Richard Campell. Let's call Franklin hey, and talking to our friend Luruka about mob programming for the first time in a long time. But it feels more mature now, like I'm maybe it's just as I'm older. I'm like, duh, yeah, working together better.

We have more tools now.

Yeah, to me it feels it feels like the obvious approach. But it is because I've been doing it for every day for six years, so sure. To me, it feels a bit odd to do it any other way, Like why would you split up the work and split up? May I have more risk?

Yeah?

Yeah, I mean people do pseudo mobbing anyway. The number of times I've seen an organization where each person has a piece of code, but they keep checking in with each other about problems they're having with their code. The problem is that that's an in interruption driven way to do it. So that other person was focused and working, and you pulled them out of that to ask them a CSS question.

Idd interruption driven development, that's it.

I'm terrible at asking for help when I'm working alone. I will sit and bang my head against the solution. I'm trying to figure it out. Yeah, maybe this thing. I'll just try this thing, then I'll ask for help.

Yeah, totally. And that's what I saw with Paar programmer. Right away as the other person knows the moment you're spinning because they're there, they've watched it happen, right, and it's that coach effect of dude, you're spinning, like it's okay, let's get you out of the spiral, Like let's rethink the.

Problem and come at it from a different direction.

So you no longer have to have the sort of executive function to go, oh, I'm spinning here, pull yourself out of it and try and find a way. There's somebody there, puts the hand on the shoulder.

It's like, hey, the four most important words a programmer can memorize and use is well, that didn't work right, You've got to know when to say that and try something else. Yeah, wow, wow, indeed this is normal.

But the remote angles interesting too, because I guess our text so much better than it was in the past. Time we were talking about this, like to just sit in a zoom call or a team's call with all the faces there, and you know, the code window and handing off control for typing, and then beside that you've got another window open because you're doing a little searching or checking or going over docs and and a steady

I never did that.

You missed all that, now, no, you missed out.

I guess I saw other idiots doing it, but I did not did not partake of that.

But it literally was like a rapid incubator evolution to emerge etiquettes around around online, which I mean it speaks to there must be a sort of agreed upon etiquette and mob programming too, like are you big on the every camera on thing?

No, we don't actually do that.

I think one thing that is interesting with the combination of remoting and more programming is we spend so many hours a day talking to each other, right that we're getting to know each other very well. Yeah, And I've have onboarded people fully remotely and in a way where you sort of you get to know them personally because while you're working, you sort of you crack a joke and then you end up having a mini break talking about something else.

I need caffeinated beverage. Now, please do you leave on? You stay on through lunch already, windy unplug.

No, we typically.

Have real lunch breaks and have uh have other breaks as well, so we try to make sure to have a break every hour and lunch breaks. And I'm an introvert, so for me, being remote and getting a lunch by my own.

Yeah, is actually important, is really valuable.

And you need to get off the screen. You need to get up and move around a bit.

I got to feed my cat. Yeah, I'm kind of chuckling because Ulrica's cat has jumped into her lap and is showing us it's butt.

Yes, that's brilliant. You're you're keeping it together, just fine and everything. Everything a great cat again. Another thing that came out of the online was the pet sessions and children children wandering in such as I was having a long talk with a senior executive at Microsoft at one point and the little girls came piling into the room and she goes, really sorry. I'm like, it's all good. Put on a speaker, let's chat. Tell us the story. They want to tell you stories.

I want to hear them.

Let's do it, you know, to spend spend six seven minutes letting the kids tell about getting home from school and then they off they go again.

Way better answer.

You know, everybody's delighted you talk about, you know, connecting with folks so exactly.

Yeah, you know, the social aspect of it. We we you know, talked about it as being good, but it really is good. I mean, we can't dismiss that as a benefit a small benefit. It's a huge benefit. I mean, you have people that connect with each other are more happy in general. Well, and if they're more happy, then they're going to be more productive and gonna want to solve problems.

Teams that trust each other are more productive. Yeah, because it resolves arguments faster. If I trust it, you're smart and good at what you do. When you disagree with me, you almost get this, I must have done something wrong, like what did I miss? Rather than the defensive No, you know, I know I'm right.

Yeah.

That trust makes those things fast.

Yeah.

I mean.

Also, we have uncovered a couple of techniques that we use when we notice that we have I wouldn't see a conflict, but maybe different ideas on how to solve a problem. So one thing that we've done is that we've actually split the team up in those cases and we get to go and sit by ourselves, uh and maybe draw a bit on a on a PowerPoint or a Mirro or something like that, draw out your solution, your idea of how we should do this, and then we come together and we present those those pictures to

It also resists the loudest voice effect to right or the law. You know, I've often had a talker in the group where it's like, hey, if I just agree with you, you stop talking. You know, So to diffuse that and go okay, everybody, go in your respective corners and draw out your finish your idea to present back equalizes the fast talker versus the quieter, more contemplative one.

That's a great technique.

Well an, that's the you know, the amount of moderation I've done over the years. It's like, how do I make sure the quieter, thoughtful person gets heard and to unplug the mob for a bit and let them go and do that and then come back and everybody gets a cycle talk through the ideas.

That's great. You know if in this in another case, you might have three different ways to achieve the same thing, and so rather than you know, and it could be something relatively simple. So rather than have everybody go through all three of those potential solutions all at once, you have them split up for say an hour. All Right, you try it this way, you try it that way, you try it this way, and then we'll come make off. Yeah,

It might have happened privately in each room and only find out an integration with people spent two weeks on it, right right, to spend a couple of hours spiking it and then bring the code. I mean three people go off to write that code in different ways. One of them's going to come back O Okay, my idea wasn't that good when I actually tried to code, like nope, And then the other two to come back with different approaches, and it's like, okay, well let's put some insutation around this,

Yeah, it's much more fun you something together.

Yeah, I feel like I've been at recess one day with my friends in grammar school, you know.

But also heard also took it out for a spin. Also got affirmed like that's pretty cool, and I never thought of it that way. We're not doing it that way, but that was pretty cool. Yeah, that seems very positive. So many positive elements to this versus now you know, this oscillation between working independently and trying to integrate.

Well, so touching on the thing that people are going to be noticing if they try OUTMA programming, they are going to be noticing personal conflicts in a way that you didn't have before because you're used to maybe if you had a different opinions in a meeting, you would split up and then go to different desks, right, but here you're sort of you get stuck in that those different opinions. You're stuck in that moment of Okay, we're not agreeing, we have to solve this, and you're going.

To be stuck in that.

Right.

Yeah. Different, So maybe you will notice.

That your retrospectives might be a bit less about how do we have a faster stand up and more of okay, so, how should we handle when we have different opinions?

What should we do?

It's not just that, but personality type clashes. Yes, Like if you're not emotionally intelligent enough to realize that, oh, that person is the direct opposite of me on the the Carl Jung's spectrum or the Myers Briggs scale or whatever you want to use, and you're not smart enough to know that, all right, well, you know I have to read past the body language and all of that other stuff that I'm taking in as information and just get to what they're saying. Yeah, yeah, that can be tough.

Yes, I think you will grow as a person in that sense because you will have to to learn about other people's personalities. Sure, a bit more and maybe there to say I feel like comfortable when you're interrupting me, can I please speak things like that that might come up to the surface in a way that wouldn't come up to the surface when you don't have to stick in the moment.

Sure.

Yeah, I keep thinking back to who is the politician said? Can I finish root?

There you goanage.

But you know, I think and you also will have refereeing type personalities in there. It's like, wait, let's hear this out. Yeah, I mean it gets challenging when you get in a situation where we disagree on this. Somebody wants to spite the code. The other one's like, why we don't need to do this, Let's get moving on.

Yeah, it does help to have that.

Yeah, three or five, four would be problematic. Yeah, because you will have that schism. So yeah, better to have it and even split, so at least you can get a sense of, well, the majority disagrees with you, wethough hopefully they do that kindness. There's got to be a lot of kindness in this. You're going to be successful. It speaks to certain set of personalities.

Yes, indeed, challenges besides the things that we've talked about. Obviously, I've brought up pushback potential, you know a few things that you need to be kind of understand before you pitch this kind of thing. But what are some challenges or potential pitfalls that people could fall into that we haven't already talked about.

I find a typical one that I've heard is when people go, this work is not suitable for more programming.

Interesting.

Yeah, so you're doing a lot of more work and then things get difficult. Maybe it's a bug that you're supposed to troubleshoot, and you're a bit stressed out, and then it gets a it gets difficult, and then your instinct will be to retract from the difficult moment. And so people have lots of opinions on this work is not suitable for mobbing, And I think.

Is there work that's not suitable for mobbing?

Possibly if you're doing something very repetitive like putting changing all the lines in a two hundred and fifty row file, maybe something like that, that just.

Means that the rest of the mob is bored. The typers typing as fast as they can as opposed to like you, if you've got three people who can and agree on something that seems very marveable, because otherwise you would have found out the disagreement after the code was already written.

Yeah, but I think situations where you are typically troubleshooting situations are a bit more difficult.

Interesting, So what typically ends up? And this is so funny.

Had a colleague was a senior developer, Like we all looked up to him, and he had really good solutions every time. And at one point in time someone asks him like, okay, so, in your opinion, what makes a senior developer? And his answer was someone who reads the error messages that Yeah. I was like, surely that can That can't be the level that we're holding people out. But if you look around, people not reading error.

Messages often a problem. Yeah.

And so if you did that in a mob situation where no one actually reads the actual message and everyone goes like, oh I know what this is yea, and people have different ideas on what this is is.

And you're a bit stressed because he's a production error.

You let somebody, You let the person on the keyboard run with their immediate age things, but my off the keyboard, I would want a copy of that error message and looking it up, and somebody else is searching through log saying how often it's happened? Like debugging is a group. Seems really powerful, but it is, but it's hard.

Oney, hour a bit stressed.

Yeah, yeah, I can see. Another challenge would be people who think slower than other people. So take my wife and I playing a game, for example, she can figure out we play a logic game, right, and she figures stuff out way before I do because I'm a programmer, right, I'm methodical. All right, apply this rule, eliminate these possibilities. Apply that rule, and she's like, it's there, you idiot.

You so, But mixing intuitive and logical processing often builds great results. Yeah, you know, as long as everyone's got a little patience for each other. I'm coming at this from an administrator's perspective, where we've been firefighting. It four of us firefighting an outage, often remote, you know, with an IRC channel open, which ends up being a record of us actually diagnosing the problem. And the joke is every time it's like, hey, it was a six hour outage.

And I think that's one of the situations where people but it's common that people sometimes do I few them up perming from time to time. They can the teams can go okay, so this is really important to get right. Let's do this thing together, or this is an actual outage, let's do that together. But maybe they're not revert to it when it comes to normal work.

Is to do a periodic mob programming with a team, maybe as a transition from the from traditional styles.

I think A common one which is pretty good is onboarding team members. Right, that's a good place to start if you're in.

The mob and the mom help them big up, build out their configuration, and get to check in able code. Always my threshold for how many days after we hire someone can they are they capable of checking in code. It's not about their programming ability, it's about understanding the infrastructure well enough to have gotten to the point where their code can be checked in and pulled into this

Do you transcribe these sessions and refer back to those transcripts when you have issues?

No, we haven't done that.

We can some transcry to summarize it, because it's good to know why I did with this actually happen mm hmm, But we haven't had any transcription so far.

Although let's face it, with a new ll M technology of the things. Transcription has gotten way easier, transition and summarization. Yeah, you know, if you're paying for the premium version of teams that comes in the box now with with copil, with M three ct I copilot, that every imagine every you know, six seven hour programming session. At the end of it, you get an everybody gets an email saying this is what you did today. I don't know how high quality that would be, but that's the tools we

Yeah, all right, So have we left any stone unturned? Is there anything else that you want to talk about now?

I think I think with the most important thing for me is how how I feel like while we're doing knowledge work.

I think that's what we should optimize for.

And a knowledge work is about its about knowledge sharing and learning new things and helping each other grow and learning from each other. So I think I think my programming is is the best fit for that, and to me, it feels like it should be the normal, the normal way working the team. And then there could be situations where you could go for individual or solo work in certain situations, perhaps, but I think the normal should be working as a team.

M h. Great stuff.

So are there resources you point people to for this?

Alrica, I would say Woody is all the book. Software teaming would be a good a good place.

What's next for you? What's in your inbox? H oh?

We are going to be.

Continuing on a sourcing so I was listening to your last episode just today.

Yeah, so that's gonna be fun.

Yep. Good well. Thank you for bringing this topic back to dot net rocks. It's been great and it's good to hear that you're being successful with it, and I hope some of our listeners are also thinking about doing this. It's good stuff. Thank you, Thank you all right, and we'll talk to you next time on dot net rocks.

And