Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Speaker 1: Become a patron for just five dollars a month. You
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month, we'll get
Speaker 1: you that and a special dot NetRocks patron mug. Sign
Speaker 1: up now at Patreon dot dot NetRocks dot com.
Speaker 2: Hey, Carl and Richard here with your twenty twenty four
Speaker 2: NDC schedule.
Speaker 1: We'll be at as many NDC conferences as possible this year,
Speaker 1: and you should consider attending no matter what. The Copenhagen
Speaker 1: Developers Festival happens August twenty sixth through the thirtieth. Tickets
Speaker 1: at Cphdevfest dot com.
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth. Tickets at
Speaker 2: Ndcporto dot com.
Speaker 3: We'll see you there, we hope.
Speaker 1: Hey, guess what, it's dot net rocks number one four
Speaker 1: h So it's almost the beginning of World War One.
Speaker 2: That's it. Sure we are, I'm doing this for a while.
Speaker 2: Just wait to use you the comment today, friend, you'll
Speaker 2: you'll laugh.
Speaker 1: Oh that's gonna be good. Well, anyway, I'm Carl Franklins,
Speaker 1: Richard Campbell, and we're going to be talking to Ulrical
Speaker 1: Melgren in a few minutes. But first let's do that
Speaker 1: thing we love with a doo dooo dudes. Music? Better
Speaker 1: know a framework? All right? Man? What do you got? So?
Speaker 1: Our friend Simon Kropp sent me this. It's not as repo,
Speaker 1: it's Tyler Brinks and the name of it is Sequel
Speaker 1: Parser dash CS. It's an extensible sequel lexer and parser
Speaker 1: for dot net. Interesting. Yeah, it was ported from a
Speaker 1: Rust project. Right, you parsequel statements into an abstract syntax
Speaker 1: tree and there you go, and now you can, you know,
Speaker 1: querry your way around it. Interesting.
Speaker 3: Cool?
Speaker 2: Why do I want this? What's wrong with t sql?
Speaker 1: Well some of us aren't tseql gods, such as yourself Richard.
Speaker 1: But I'm a god of anything good. Well you know
Speaker 1: I think you are.
Speaker 2: But okay, just another way to get at the data.
Speaker 1: Yep. I love it. And you know that's it and
Speaker 1: if you need it, you need it. That's what I think.
Speaker 1: That's fair. I buy that.
Speaker 3: Yeah.
Speaker 1: So who's talking to us today, Richard? Well, you know,
Speaker 1: I know.
Speaker 2: We're talking about MOB programming, right yeah, And we've talked
Speaker 2: about mob programming before, so I figured I'd go back
Speaker 2: and what he's out of coincidence? But by the way,
Speaker 2: what he's still doing his thing, he's doing he's still
Speaker 2: doing workshops, he's out there. Yeah, by coincidence. The last
Speaker 2: time we talked about mob programming was in twenty thirteen
Speaker 2: on episode nine to twelve. Oh my gosh, now we
Speaker 2: published nineteen twelve today when we're recording this, Yeah, on
Speaker 2: August twenty seconds, so literally a thousand episodes ago.
Speaker 1: We did something weird.
Speaker 2: We actually talked to an entire mob, which included Woody
Speaker 2: Zoo right about mob programming. And actually we had a
Speaker 2: ton of comments on that show, so I figured I'd
Speaker 2: drag out a ten year old's comment. I mean, what's
Speaker 2: the big deal?
Speaker 1: Really, it's a very American thing, right, It's like, oh,
Speaker 1: you like pair programming, how about mob programming? How about it?
Speaker 1: The only we know it would be better?
Speaker 2: More So, ten years ago, Richard Garside wrote this comedy.
Speaker 2: He says, I'm wondering how far you can scale a mob?
Speaker 2: When does it stop making sense to recruit new people
Speaker 2: for one mob? And what point you start multi mobs?
Speaker 1: See? See that's exactly my point. More more a mob
Speaker 1: not enough for you. More mobs make more mobs. You know.
Speaker 2: I think we're gonna take that. Got to take that
Speaker 2: question over to el Rica at some point. So, Richard,
Speaker 2: thank you so much for comment. I hope you still
Speaker 2: hear this ten years on, or at least you'll get
Speaker 2: the email prom and so forth. A copy of music
Speaker 2: code BI it is on its way to you. And
Speaker 2: if you'd like a copy of music Cobe, I write
Speaker 2: a comment on the website at dot at Rocks dot
Speaker 2: com or on the facebooks. We publish every show there,
Speaker 2: and if you comment there and I read it on
Speaker 2: the show, we'll send you copy music Coby Music to.
Speaker 1: Cobe by still going strong after all these years. Yeah,
Speaker 1: and still a favorite way for people to get into
Speaker 1: the zone when writing code works for me. And you
Speaker 1: can follow us on X Twitter because we've been there
Speaker 1: for years before it was X. Of course many many
Speaker 1: years before it was X. But the cool kids are
Speaker 1: hanging out. I'm mastadon, I'm at Carl Franklin at tech
Speaker 1: Hub dot social, and I'm.
Speaker 2: Rich Campbell at Masdon dot social.
Speaker 1: So send us a two. That's another way that you
Speaker 1: could get a copy of music to code by for sure. Okay,
Speaker 1: let me introduce our guest. Ulrika Malmgren has been in
Speaker 1: the software industry in some form for twenty years or
Speaker 1: so as of this recording. Anyway. She started out as
Speaker 1: a software tester, using exploratory testing to study and learn
Speaker 1: about software and users. After realizing that quality was more
Speaker 1: more than just testing, she worked as an agile coach
Speaker 1: to help teams improve their ways of working. But for
Speaker 1: the past eight years she's been a c sharp developer,
Speaker 1: working mostly with back end applications. The last six of
Speaker 1: those years have been using MOB programming as said fourth
Speaker 1: in the comment, or software teaming as it's also called
Speaker 1: as a way of working. So url COO, welcome to
Speaker 1: dot net rocks.
Speaker 4: Thank you, thank you for having me.
Speaker 2: I was really excited to see you had this talk
Speaker 2: at NBC Oslo, and I'd meant to do the interview
Speaker 2: there in person, but things happen, so now we're doing
Speaker 2: a little bit later from there because we haven't talked
Speaker 2: about MOB programming in ages, but clearly it's still going
Speaker 2: on wood He still doing his thing, like there's plural
Speaker 2: size videos on the topic. How do you explain mob programmer.
Speaker 2: That's team programming.
Speaker 5: Ah, I would explain it as the entire team is
Speaker 5: working together, so we're programming together. I liked how you said,
Speaker 5: like para programming on steroids were even more power programming.
Speaker 4: But also.
Speaker 5: Not just the programming part of it, So the entire
Speaker 5: team is working together, but maybe also answering emails, preparing
Speaker 5: power port presentations, all the other stuff that you do
Speaker 5: when you're doing software development.
Speaker 1: I was going to say, the last time we talked
Speaker 1: to Witty about this, everybody was in a room and
Speaker 1: one person was driving visual studio or whatever the software is,
Speaker 1: and everybody else is sort of chiming in. And now,
Speaker 1: in the age of zoom and remote, that must be
Speaker 1: quite a bit different, isn't it.
Speaker 4: It is, but it works really well, so we do that.
Speaker 5: Actually, my team is fully remote, so I get to
Speaker 5: spend a lot of time with my cat, and that's good.
Speaker 5: But what we do is we have a computer at
Speaker 5: the office, and we're using ANIDSK to remote to that computer,
Speaker 5: and we have a slack or a team call or
Speaker 5: something ongoing HM, and we talk and we do all
Speaker 5: of our communication and programming on that computer. So I
Speaker 5: don't have the source code on my laptop. Actually, I
Speaker 5: only use my laptop to connect to this computer and
Speaker 5: to do personal work, things like things that are just
Speaker 5: for me, right, And.
Speaker 2: I find that a fairly common practice putting my run
Speaker 2: ass hat on where the sort of data integrity points
Speaker 2: of view or keeping all the source code in the
Speaker 2: company means you're just logging into a virtual machine or
Speaker 2: a remote instance somewhere and that's where all the code lives,
Speaker 2: and the home machines don't actually have don't ever run
Speaker 2: the code, they just have access to it through a console.
Speaker 2: And that solves the problem that you know, you don't
Speaker 2: have to synchronize, like you're all working one place and
Speaker 2: you still have that MOB program in mindset of there's
Speaker 2: one active keyboard on the code.
Speaker 1: How many monitors do you have?
Speaker 4: I have the one is a big one.
Speaker 5: That's the downside of it, because we only have one
Speaker 5: monitor on the office, so we that's the one we
Speaker 5: have connected to.
Speaker 2: And I certainly remember that from some of the other
Speaker 2: conversations we had in this space where often somebody in
Speaker 2: the MOB is on another machine and they're searching for
Speaker 2: code samples, and other cases of addressing this particular problem
Speaker 2: like many in some cases totally short circuit the development process, like, wait,
Speaker 2: this has been done. Here's an example, and it's starting
Speaker 2: to look like what we're already doing. Like, let's go
Speaker 2: dig into this exactly.
Speaker 5: You can while you're troubleshooting. You can have multiple threads
Speaker 5: of googling going on at the same time, so you
Speaker 5: can be I'll stack over frough a couple of people
Speaker 5: trying to find what could be a possible solution for
Speaker 5: this at the same time if you want to.
Speaker 1: Yeah, so I knew what he told us about the
Speaker 1: metrics being you know, productivity wise being very very good.
Speaker 1: Are there any new numbers or any numbers that you
Speaker 1: can share with us in terms of, you know, single
Speaker 1: developer at a time and a team working versus pair
Speaker 1: programming versus mob programming.
Speaker 5: I'm not aware of any, and in our teams we've
Speaker 5: only done this.
Speaker 4: We don't have any numbers to compare to.
Speaker 5: Yeah, but I feel that there's so many situations where
Speaker 5: we are that this software team and mopgram is just
Speaker 5: helping us so much that I would have to say
Speaker 5: that the numbers would have to be good towards more programming.
Speaker 5: I'm thinking of all the during the summer. Now, because
Speaker 5: of vacations, I was sometimes alone at work and I
Speaker 5: was sitting there and it took me a while to
Speaker 5: figure out why I was doing this stupid mistake, which
Speaker 5: would have been something that my team would have pointed
Speaker 5: out immediately.
Speaker 4: They would have seen immediately that I was doing something.
Speaker 1: You say, this is an interesting dynamic here. Now, what
Speaker 1: if you have I don't know, let's say you have
Speaker 1: a team of thirty and ten of those team members
Speaker 1: are working on this part of the app, and ten
Speaker 1: are working on another part of the app, and ten
Speaker 1: and working on any Does everybody work on the same
Speaker 1: thing all at the same time, so like there's no
Speaker 1: such thing as a merge conflict or how does that work?
Speaker 5: Yeah, I'm not very good at bronchos because I've never
Speaker 5: used them.
Speaker 1: Yeah wow, yeah those.
Speaker 5: Sizes though, So we have teams of for now, two
Speaker 5: to five people.
Speaker 1: Yeah, yeah, so.
Speaker 4: We don't have that kind of a size of a team.
Speaker 1: And that's a dressing a dressing.
Speaker 2: Their listener Richard Garsides comments like, how big is what
Speaker 2: can a mob really be? Five seems like a reasonable
Speaker 2: number where everybody can still be engaged.
Speaker 5: Yeah, I would say three is really good, and then yeah,
Speaker 5: the engagement thing is a thing because if you were
Speaker 5: doing it, So one way of doing more programming is
Speaker 5: using a timer and having people rotate at the keyboard.
Speaker 5: So you'd say, every ten minutes we change driver, we
Speaker 5: changed a person is sitting at the keyboard when is
Speaker 5: actually typing the code. But all of the time you
Speaker 5: get to have input on what is being done. But
Speaker 5: sometimes you want to rotate, and if you are five people,
Speaker 5: you get ten minutes at the keyboard and then you
Speaker 5: have to wait forty minutes.
Speaker 1: Once an hour y.
Speaker 4: Yeah, and for some people.
Speaker 2: If typing is what you like in programming, right, I mean,
Speaker 2: I got to think there's some natural typers and some
Speaker 2: natural searchers and some natural reviewers.
Speaker 4: Too, exactly.
Speaker 5: So we have tried those kind of rotation patterns, but
Speaker 5: we've also sometimes gone away from them and have had
Speaker 5: a more natural kind of cycle of some people like
Speaker 5: to type more, some people like to go go think more.
Speaker 4: Yeah.
Speaker 1: So to get back to what I was saying before
Speaker 1: though about multiple team sections working on different sections of
Speaker 1: the code. What if there's somebody on the team that
Speaker 1: you know when you go down a rabbit hole in
Speaker 1: a particular thing, that they're not even working on. Do
Speaker 1: they contribute as well? Do you have to take time
Speaker 1: to explain what the other people have done to those
Speaker 1: who haven't done it yet. I mean, there is that
Speaker 1: a problem.
Speaker 5: That's actually sort of an excellent point towards my programming
Speaker 5: and the fact that when you are in the mob
Speaker 5: and you're working on a thing, you get to see
Speaker 5: the rabbit holes, so to see, like, Okay, we went
Speaker 5: down this path and we found a dead end. This
Speaker 5: wasn't actually the way to solve this problem. And you're
Speaker 5: learning those things as well, because if you're just doing
Speaker 5: like a pull request and you're sort of explaining this
Speaker 5: is what I did, you rarely explain the other paths,
Speaker 5: the paths that you didn't take.
Speaker 4: The things that were dead ends.
Speaker 5: Sure, you get to learn the thinking that up to
Speaker 5: the actual solution, but I.
Speaker 1: Can also see how you know, if you've got parallel
Speaker 1: sections of the team working on different aspects of the
Speaker 1: application all at the same time, are they three times
Speaker 1: as productive as the whole team working on one of
Speaker 1: those at a time? Like some people may think.
Speaker 5: That, yeah, I think you want to have very like
Speaker 5: your own domain or your own application and not have
Speaker 5: to share that with someone else.
Speaker 4: I think that's also a key to getting making it
Speaker 4: work all right.
Speaker 1: So breaking down the teams into sections that are working
Speaker 1: on a particular thing. We're all working on that thing. Yeah,
Speaker 1: that makes sense.
Speaker 2: And the point being that, just like we saw with
Speaker 2: pair program, and there's two pairs of eyes on something,
Speaker 2: you tend to make fewer mistakes, Like that code tends
Speaker 2: to be very check inable and sticks around. There's less
Speaker 2: iterating on it. I like the third pair of eyes
Speaker 2: because they do the other thing. You know, you definitely
Speaker 2: need two pairs of eyes on the code at any
Speaker 2: given moment, so that as soon as that third ones introduced,
Speaker 2: that's the one that could be searching yeah, you know,
Speaker 2: or thinking yeah and pulling new information into the equation,
Speaker 2: or reading even just reading the smacks in more detail
Speaker 2: and saying do we actually understand this? Right?
Speaker 1: Like? You know, it's kind of like a continuity person
Speaker 1: on a movie set, isn't it somebody who's got a
Speaker 1: sixty thousand foot view of everything and says, oh know,
Speaker 1: in that last shot, the coffee mug was half full.
Speaker 1: You got to fill it up again.
Speaker 5: It also sometimes looks a bit back when we were
Speaker 5: in the office and doing this. It looked a bit
Speaker 5: weird to the others because we were sitting and discussing
Speaker 5: a lot, and we were talking and talking, and then
Speaker 5: finally we reached consensus about what is it we're actually solving,
Speaker 5: how do we want to go about this, what's a
Speaker 5: solution we can all stand behind. And then when we
Speaker 5: finally reached that consensus, just typing out the code wasn't
Speaker 5: really something that took us very long.
Speaker 2: It was the easy part because you had consensus. And
Speaker 2: I got to think, if you've got four people agreeing
Speaker 2: on a path and they're really agreeing, like there's not
Speaker 2: a lot of bullying going on, the quality of that's
Speaker 2: going to be pretty high.
Speaker 4: Yeah, it is.
Speaker 5: And also you get but you have to sort of
Speaker 5: learn to sort of this is something I really want
Speaker 5: to stand up for, right, I'm just I'm not we're
Speaker 5: doing tabs and not spaces. I'm going to die on
Speaker 5: that hill now, that kind of thing. And then you
Speaker 5: need to figure out what are the things that I'm
Speaker 5: willing to let go of and that I'm willing to
Speaker 5: slip because I think you can't win every bottle. You
Speaker 5: can't have four people having absolute consensus and everything. So
Speaker 5: you have to be a bit of a You can't
Speaker 5: be too opinionated about everything.
Speaker 2: You can't fight to the death on everything, and nobody's
Speaker 2: going to want to work with you eventually. Like there's
Speaker 2: just there's got to be some This is not that
Speaker 2: important to me, it seems more important to you. Let's
Speaker 2: try it, because let's face it, none of this is permanent.
Speaker 2: You could go back and revise. Yeah, better to just
Speaker 2: get to a path where it's like, I don't see
Speaker 2: a problem with that. I don't know that I do
Speaker 2: it that way, but I don't see a problem. Let's
Speaker 2: go and see what we get. Yeah, yeah, I think
Speaker 2: that's That's the compelling part of this is that the
Speaker 2: biggest thing you get away from with pair programming, I
Speaker 2: noticed is the those death sparals just trapped in. I
Speaker 2: can't get this out the door. I'm just smashing my
Speaker 2: head on the keyboard, and another pair of eyes and
Speaker 2: ultimately another pair of hands just breaks that up. And
Speaker 2: you're always rubber ducking.
Speaker 5: Yeah exactly. And also you're learning like IF when you're IF.
Speaker 5: I'm not very good at CSS, for example, but my
Speaker 5: colleagues are better than me, so if I were to
Speaker 5: solve this future of my own, my CSS that I
Speaker 5: would produce would be at a certain level, which is
Speaker 5: not very good. But when we're doing this together, we
Speaker 5: always get like the best person's level of knowledge, right,
Speaker 5: which is also really interesting and I'm learning at the
Speaker 5: same time.
Speaker 2: Do you switch keyboards at that point? Like does the
Speaker 2: CSS when you hit to the point where it's like,
Speaker 2: well we need little CSS here, It's like, all right,
Speaker 2: already take that.
Speaker 1: Yeah.
Speaker 5: Maybe the other way around though, maybe I'll take that
Speaker 5: because I'm not so good a right, so you can
Speaker 5: be the one.
Speaker 2: To turn yeah and let them coach you through exactly
Speaker 2: better see sess yeah, and sharing that knowledge.
Speaker 5: I need to get this from my fingers, to get
Speaker 5: the mechanics of it.
Speaker 1: And that's an.
Speaker 2: Interesting angle on this, and it also speaks to I
Speaker 2: don't want three of the same person on here on
Speaker 2: this project. I want an array of skills.
Speaker 1: I'm trying to think of the pushback, right, If you
Speaker 1: have a team of five and you go to your
Speaker 1: manager and say, hey, instead of everybody working on stuff
Speaker 1: and branching and merging and all that stuff, why don't
Speaker 1: we work together? You know, the pushback might be is
Speaker 1: I think, well, you have to prove that the productivity
Speaker 1: exceeds what you can do individually and the quality. Productivity
Speaker 1: and quality they go hand in hand.
Speaker 5: Yeah, And people always say that, and it's really interesting
Speaker 5: because has this sort of working individually, has that really
Speaker 5: proven itself to be good productivity and good quality?
Speaker 1: M Right?
Speaker 5: Like did we always we were doing software perfectly on time,
Speaker 5: bug free, and then some people came along and say
Speaker 5: can we work together? And everything went downhills from there.
Speaker 2: Just do more unit tests. But I mean, I think
Speaker 2: I want to play with the math on it. So
Speaker 2: if we've got four people in a four week sprint,
Speaker 2: each takes a task, all right, in the end of
Speaker 2: four weeks, you're supposed to deliver four tasks. Now flip
Speaker 2: that on his head, and four people work on each
Speaker 2: task a week each, all four of them work on
Speaker 2: it once. Are you going to get a better result?
Speaker 2: Can they deliver those four features one a week collaboratively?
Speaker 2: And then I mean, I think it's hard to deny
Speaker 2: that you'll get better quality code for having more eyes
Speaker 2: on it.
Speaker 1: That's always true, definitely.
Speaker 2: So the quality question is not there the productivity question.
Speaker 2: The question is can you get those four features built
Speaker 2: that sprint. Like that would be my argument to the
Speaker 2: team lead. It's like, hey, our goals deliver these four
Speaker 2: things in the sprint. How we do it?
Speaker 1: Don't ask? You know, you can't. You don't have the
Speaker 1: benefit of parallel universes. You can't say all right, it'll
Speaker 1: do bose ways and see what happens at the end.
Speaker 5: Remember that there's so much more to program to software
Speaker 5: development and just the programming part. There's like reading the code.
Speaker 5: There's understanding the code, there's understanding why are we doing
Speaker 5: this in the first place. There's so many other things
Speaker 5: that you're doing. And I think that if you've been
Speaker 5: a part of all of the code production up until now,
Speaker 5: you're rarely going to be in a position where you're
Speaker 5: sitting there and you're not understanding what a certain post
Speaker 5: of code is doing because you were there when it
Speaker 5: was created. So the part when it is okay, I'm
Speaker 5: reading code is taking me a long time to understand
Speaker 5: what previous the previous programmer was doing. That part is
Speaker 5: gone because you were there for that part.
Speaker 1: Yeah, well, you have the potential for new kinds of nastiness,
Speaker 1: don't you like when people don't agree, and they're resistant
Speaker 1: to doing it the right way. Has it ever come
Speaker 1: to fist the cuffs?
Speaker 5: I think it's even more passive aggressiveness in all the
Speaker 5: sines where you're sort of like, oh, I'm going to
Speaker 5: change this now, that's my turn to where on this
Speaker 5: future I'm going to change it to what I think
Speaker 5: is better.
Speaker 2: Edit the code right in front of them. Yeah it's
Speaker 2: not pretty.
Speaker 1: Well, Dave did this and introduced a bug because he
Speaker 1: wasn't smart enough to think that this and that. So
Speaker 1: I'll just fix it right now.
Speaker 5: But also, my most the argument that I like the
Speaker 5: most about when you talk about productivity is the one
Speaker 5: thing that you hear in every retrospective is we have
Speaker 5: to be better at knowledge sharing.
Speaker 4: That's always the thing that comes up.
Speaker 1: And then you share all the time.
Speaker 5: Yeah, and then you have people say like, okay, so
Speaker 5: we should have knowledge sharing sessions and then that doesn't happen,
Speaker 5: or we should we should be better at talking to
Speaker 5: each other, and then that doesn't happen. But we don't
Speaker 5: have to solve that problem because we're organically knowledge sharing
Speaker 5: all the time. Yeah, we don't have to think about
Speaker 5: is this an important thing that we need to tell
Speaker 5: someone else about.
Speaker 1: Also really good if one person leaves the team.
Speaker 4: Yeah, yeah, that's brilliant.
Speaker 2: You've always got more pairs of eyes on the code.
Speaker 2: You've got them routinely teaching each other. You're not doing
Speaker 2: a separate teaching exercise, right, Like the fact that the
Speaker 2: skilled CSS person who's in the MOB walked you through
Speaker 2: writing better CSS, as opposed to doing like a luncheon
Speaker 2: learn on CSS, or just simply getting all the CSS
Speaker 2: work from the whole team all the time so that
Speaker 2: that person gets better and better but never really teaches
Speaker 2: anyone else. Like, there's a whole bunch of things solved
Speaker 2: at the same time with this approach, and only a
Speaker 2: small part of it is writing the code exactly.
Speaker 1: I think she use a different term than in the MOB.
Speaker 4: That's what I want.
Speaker 5: I want to flip this conversation around, like ken, I
Speaker 5: think I when I started to submit talks about this topic,
Speaker 5: I wanted to contrast it to the other way of
Speaker 5: working the thing that we were doing before. Right, And
Speaker 5: it turns out I felt like I needed to find
Speaker 5: a name for it because I would have more programming.
Speaker 5: That's not a particularly good name, But we talk about
Speaker 5: a software team maybe sometimes which is slightly better, but
Speaker 5: still a name for something.
Speaker 1: How do you like it?
Speaker 2: Ensemble programming.
Speaker 1: That's very, very very the word area day. Yeah, yeah,
Speaker 1: I like it. But yeah, group programming perhaps programming.
Speaker 4: Yeah, but what's the other thing then, what's the thing
Speaker 4: that most people are programming? Yeah?
Speaker 5: Yeah, I like that one, and I think I like
Speaker 5: even better one that we came up with in the group,
Speaker 5: which was individual centered programming or development, because if we
Speaker 5: have if in more programming, you take the work and
Speaker 5: everyone flocks to the work and does the work. In
Speaker 5: the other style, you split the work to the individuals, right, but.
Speaker 2: You still have this great ritual of merging it all together.
Speaker 2: But you now are oscillating between working individually and working
Speaker 2: in a team where you all have to collaborate on
Speaker 2: the integration cycle. Why not just be in the team
Speaker 2: all the time?
Speaker 1: About mono programming and polyprogram.
Speaker 4: Multi threaded, single threaded, Yeah.
Speaker 1: Right, remin brain goes, oh, looks like the cat is
Speaker 1: taking a walk.
Speaker 2: Yeah, but actually at this point about the oscillation of
Speaker 2: switching modes where you go head down on your own
Speaker 2: sometimes you know, in a tail spin, to try and
Speaker 2: produce your portion of the work. To bring to the team,
Speaker 2: and then you work as a team to do the
Speaker 2: integration just seems weirder than why if you just work
Speaker 2: as a team the whole time.
Speaker 5: Yeah, And there's so much wasted time that is spent
Speaker 5: during those synchronizations, like the stand ups, Yeah, what did
Speaker 5: you do yesterday?
Speaker 4: What are you going to do today?
Speaker 5: And then you have long stand ups, so then you
Speaker 5: spend the retrospectives talking about how should we have better
Speaker 5: stand ups?
Speaker 4: So first you waste the time during.
Speaker 1: The stand ups, then you waste more time.
Speaker 5: Than you're wasting the retrospective time talking about how you
Speaker 5: can waste the time in a better way.
Speaker 1: Yeah.
Speaker 2: What if everybody knew what everybody was working on because
Speaker 2: they all worked on it. Yeah, Yeah, suddenly this weird
Speaker 2: idea seems like the normal idea, and what we've been
Speaker 2: doing is weird.
Speaker 1: I would think though, that in bigger projects where you
Speaker 1: have multiple silos of work, it could pose more of
Speaker 1: a problem, don't you What.
Speaker 4: Would be some multiple silos?
Speaker 1: All right, So let's say you're working on a project
Speaker 1: that has a solution that has thirty or forty projects,
Speaker 1: and you know they hire one person to work on
Speaker 1: this one project. Because it uses a particular language or
Speaker 1: technology or something, and another person is doing the data
Speaker 1: the back end, another person is doing the communications, right,
Speaker 1: I mean you've got a team of twenty or thirty people.
Speaker 1: That seems a little bit far reaching from me.
Speaker 5: No, yeah, maybe this wouldn't be the best solution for that,
Speaker 5: but maybe it would be splitting up that problem.
Speaker 4: Yeah, in a different way.
Speaker 2: Yeah, let's come into this another angle. We kind of
Speaker 2: recognize that at any given mob, any given ensemble is
Speaker 2: three to five people, right, Yeah, you have a limit,
Speaker 2: and so there's a cadence as fast as you can
Speaker 2: produce code with that team. Even if that team works
Speaker 2: flawlessly together, they're in their their space, they know what
Speaker 2: they're doing. They're only going to put out so much
Speaker 2: code in so much time, as efficiently as they can be.
Speaker 2: And that could be a lot. A lot of projects
Speaker 2: could be happily solved that way. But you have a
Speaker 2: larger project with way more milestones that need to be done,
Speaker 2: and you want to have more people working together. I
Speaker 2: don't think you make the individual mob bigger, But now
Speaker 2: you get into multiple mobs and you're back to possibly
Speaker 2: fighting that synchronization problem wherever. So often those mobs need
Speaker 2: to come together to synchronize their code.
Speaker 1: But at least they would be working within their own
Speaker 1: domain hopefully and wouldn't be crossing each other, so there'd
Speaker 1: be less chances for emerged conflicts and things like that.
Speaker 1: I hope, yeah, I mean would you would?
Speaker 2: This is where the architect comes into play and we
Speaker 2: build boundaries to say here, you know, maybe negotiate the APIs.
Speaker 2: You might even have a mob of mobs here where
Speaker 2: one lead from each mob gets together with the other
Speaker 2: four mobs and they go through the architecture of how
Speaker 2: they're going to build those interfaces.
Speaker 1: Middle management mobs.
Speaker 2: But now you're getting to, like you said, a twenty
Speaker 2: to twenty thirty people working on a project that's a
Speaker 2: lot of code like but you know, and it's really
Speaker 2: a speed thing that they want a certain level of
Speaker 2: deliverables in a certain amount of time. So you're going
Speaker 2: to introduce complexity. There's no two ways about it. Like
Speaker 2: you can't can't get twenty people sitting around one keyboard
Speaker 2: and be productive. There's a threshold there.
Speaker 1: But I like the multiple groups or multiple mobs or
Speaker 1: multiple ensembles idea because as as these five, four or
Speaker 1: five person units, they can be a lot more productive
Speaker 1: in their silo than the four or five individually working well.
Speaker 2: And the bigger thing is recognized. Every piece of code
Speaker 2: is looked at by multiple peeple, so it tends to
Speaker 2: be a higher quality.
Speaker 1: Yeah, produced more rapidly.
Speaker 2: Yeah, you know, because as soon as we getting the
Speaker 2: mobs of mobs where now we could be back to well,
Speaker 2: why don't you just have individual developers they do the
Speaker 2: same consolidation because an individual makes more mistakes and a
Speaker 2: group makes for your.
Speaker 1: And some simple rules like those pieces that are shared
Speaker 1: among all the projects that somebody has to update, you know,
Speaker 1: they have to eraise their hand and tell everybody, hey,
Speaker 1: I'm gonna be working on this tonight or tomorrow morning.
Speaker 1: Check all your stuff in by five, and then you know,
Speaker 1: have it done in a couple hours, and then we
Speaker 1: can you know, just prepare. I'm not trying to say,
Speaker 1: trying to prevent merch conflicts before they happen. Yeah, yeah,
Speaker 1: you would hope, you would.
Speaker 5: Hope if you were to have some sort of synchronization
Speaker 5: in between, you can at least send any of the
Speaker 5: team members from any of the mobs, because they will
Speaker 5: have the same knowledge.
Speaker 1: They should have all the same knowledge.
Speaker 4: About their work at least delegates.
Speaker 2: But just like you have somebody good at CSS, you
Speaker 2: might have somebody good at persuading.
Speaker 1: So you want to send it to that mob. Interesting,
Speaker 1: it's not just about technology.
Speaker 2: Well, it never is, right, Like, this is all about
Speaker 2: how well we work together and how we come to
Speaker 2: consensus on things, and how different viewpoints make for a
Speaker 2: better answer when done constructively. It can be done toxically,
Speaker 2: like what I what I find in you about this
Speaker 2: is like, this will certainly hunt down the toxic people
Speaker 2: in your group. If you can't make this team programming work,
Speaker 2: it's going to show fast.
Speaker 1: Yeah.
Speaker 4: It requires people to be humble and to be curious
Speaker 4: about other people.
Speaker 2: Yeah, and to expect understand that they're they're capable, like
Speaker 2: they all deliver.
Speaker 4: Yeah, you have to.
Speaker 5: If someone has an adverse solution to yours, you have
Speaker 5: to be more curious about why would you that be
Speaker 5: a good solution in your opinion? Right, rather than to
Speaker 5: bash them and be sure that you win that argument.
Speaker 2: Mm hmmm, well anyway, don't win any argument, right. The
Speaker 2: code bench it right, Like, I'm perfectly willing and I've
Speaker 2: been in that situation with two really smart people and said,
Speaker 2: all right, we're both going to write and we're going
Speaker 2: to have a bake off.
Speaker 1: Then right, and you'll see what we That's a fun way.
Speaker 2: Yeah, it's it's an approach. It has its own problems.
Speaker 2: Now we talk about metrics. Actually we should break for
Speaker 2: a moment for these very important messages, and we're back.
Speaker 2: It's done at Rocks. I'm Richard Campell. Let's call Franklin hey,
Speaker 2: and talking to our friend Luruka about mob programming for
Speaker 2: the first time in a long time. But it feels
Speaker 2: more mature now, like I'm maybe it's just as I'm older.
Speaker 2: I'm like, duh, yeah, working together better.
Speaker 1: We have more tools now.
Speaker 5: Yeah, to me it feels it feels like the obvious approach.
Speaker 5: But it is because I've been doing it for every
Speaker 5: day for six years, so sure. To me, it feels
Speaker 5: a bit odd to do it any other way, Like
Speaker 5: why would you split up the work and split up?
Speaker 5: May I have more risk?
Speaker 1: Yeah?
Speaker 2: Yeah, I mean people do pseudo mobbing anyway. The number
Speaker 2: of times I've seen an organization where each person has
Speaker 2: a piece of code, but they keep checking in with
Speaker 2: each other about problems they're having with their code. The
Speaker 2: problem is that that's an in interruption driven way to
Speaker 2: do it. So that other person was focused and working,
Speaker 2: and you pulled them out of that to ask them
Speaker 2: a CSS question.
Speaker 1: Idd interruption driven development, that's it.
Speaker 5: I'm terrible at asking for help when I'm working alone.
Speaker 5: I will sit and bang my head against the solution.
Speaker 5: I'm trying to figure it out. Yeah, maybe this thing.
Speaker 5: I'll just try this thing, then I'll ask for help.
Speaker 2: Yeah, totally. And that's what I saw with Paar programmer.
Speaker 2: Right away as the other person knows the moment you're
Speaker 2: spinning because they're there, they've watched it happen, right, and
Speaker 2: it's that coach effect of dude, you're spinning, like it's okay,
Speaker 2: let's get you out of the spiral, Like let's rethink the.
Speaker 1: Problem and come at it from a different direction.
Speaker 2: So you no longer have to have the sort of
Speaker 2: executive function to go, oh, I'm spinning here, pull yourself
Speaker 2: out of it and try and find a way. There's
Speaker 2: somebody there, puts the hand on the shoulder.
Speaker 1: It's like, hey, the four most important words a programmer
Speaker 1: can memorize and use is well, that didn't work right,
Speaker 1: You've got to know when to say that and try
Speaker 1: something else. Yeah, wow, wow, indeed this is normal.
Speaker 2: But the remote angles interesting too, because I guess our
Speaker 2: text so much better than it was in the past.
Speaker 2: Time we were talking about this, like to just sit
Speaker 2: in a zoom call or a team's call with all
Speaker 2: the faces there, and you know, the code window and
Speaker 2: handing off control for typing, and then beside that you've
Speaker 2: got another window open because you're doing a little searching
Speaker 2: or checking or going over docs and and a steady
Speaker 2: stream of conversation about what we're writing. Doesn't even seem
Speaker 2: weird now, and a few years ago that wouldn't be
Speaker 2: that easy. The pandemic fixed this really pandemic. The pandemic,
Speaker 2: I'm not going to go that far, but I'm saying
Speaker 2: everybody's ring got better. The etiquette of online communication evolved.
Speaker 2: Remember we had the stupid hat period during the pandemic
Speaker 2: when everybody turned on a filter so they had the
Speaker 2: digital hats on.
Speaker 1: I never did that.
Speaker 2: You missed all that, now, no, you missed out.
Speaker 1: I guess I saw other idiots doing it, but I
Speaker 1: did not did not partake of that.
Speaker 2: But it literally was like a rapid incubator evolution to
Speaker 2: emerge etiquettes around around online, which I mean it speaks
Speaker 2: to there must be a sort of agreed upon etiquette
Speaker 2: and mob programming too, like are you big on the
Speaker 2: every camera on thing?
Speaker 4: No, we don't actually do that.
Speaker 5: I think one thing that is interesting with the combination
Speaker 5: of remoting and more programming is we spend so many
Speaker 5: hours a day talking to each other, right that we're
Speaker 5: getting to know each other very well. Yeah, And I've
Speaker 5: have onboarded people fully remotely and in a way where
Speaker 5: you sort of you get to know them personally because
Speaker 5: while you're working, you sort of you crack a joke
Speaker 5: and then you end up having a mini break talking
Speaker 5: about something else.
Speaker 2: I need caffeinated beverage. Now, please do you leave on?
Speaker 2: You stay on through lunch already, windy unplug.
Speaker 4: No, we typically.
Speaker 5: Have real lunch breaks and have uh have other breaks
Speaker 5: as well, so we try to make sure to have
Speaker 5: a break every hour and lunch breaks. And I'm an introvert,
Speaker 5: so for me, being remote and getting a lunch by
Speaker 5: my own.
Speaker 1: Yeah, is actually important, is really valuable.
Speaker 2: And you need to get off the screen. You need
Speaker 2: to get up and move around a bit.
Speaker 1: I got to feed my cat. Yeah, I'm kind of
Speaker 1: chuckling because Ulrica's cat has jumped into her lap and
Speaker 1: is showing us it's butt.
Speaker 2: Yes, that's brilliant. You're you're keeping it together, just fine
Speaker 2: and everything. Everything a great cat again. Another thing that
Speaker 2: came out of the online was the pet sessions and
Speaker 2: children children wandering in such as I was having a
Speaker 2: long talk with a senior executive at Microsoft at one
Speaker 2: point and the little girls came piling into the room
Speaker 2: and she goes, really sorry. I'm like, it's all good.
Speaker 2: Put on a speaker, let's chat. Tell us the story.
Speaker 2: They want to tell you stories.
Speaker 1: I want to hear them.
Speaker 2: Let's do it, you know, to spend spend six seven
Speaker 2: minutes letting the kids tell about getting home from school
Speaker 2: and then they off they go again.
Speaker 1: Way better answer.
Speaker 2: You know, everybody's delighted you talk about, you know, connecting
Speaker 2: with folks so exactly.
Speaker 1: Yeah, you know, the social aspect of it. We we
Speaker 1: you know, talked about it as being good, but it
Speaker 1: really is good. I mean, we can't dismiss that as
Speaker 1: a benefit a small benefit. It's a huge benefit. I mean,
Speaker 1: you have people that connect with each other are more
Speaker 1: happy in general. Well, and if they're more happy, then
Speaker 1: they're going to be more productive and gonna want to
Speaker 1: solve problems.
Speaker 2: Teams that trust each other are more productive. Yeah, because
Speaker 2: it resolves arguments faster. If I trust it, you're smart
Speaker 2: and good at what you do. When you disagree with me,
Speaker 2: you almost get this, I must have done something wrong,
Speaker 2: like what did I miss? Rather than the defensive No,
Speaker 2: you know, I know I'm right.
Speaker 4: Yeah.
Speaker 2: That trust makes those things fast.
Speaker 4: Yeah.
Speaker 1: I mean.
Speaker 5: Also, we have uncovered a couple of techniques that we
Speaker 5: use when we notice that we have I wouldn't see
Speaker 5: a conflict, but maybe different ideas on how to solve
Speaker 5: a problem. So one thing that we've done is that
Speaker 5: we've actually split the team up in those cases and
Speaker 5: we get to go and sit by ourselves, uh and
Speaker 5: maybe draw a bit on a on a PowerPoint or
Speaker 5: a Mirro or something like that, draw out your solution,
Speaker 5: your idea of how we should do this, and then
Speaker 5: we come together and we present those those pictures to
Speaker 5: each other. Because when you are remoting and you don't
Speaker 5: have the whiteboard just next to you, it can be
Speaker 5: a good idea to be able to just sit by
Speaker 5: yourself and get get to draw a solution, get to
Speaker 5: think about the problem on your own, and then then
Speaker 5: come back and talk about how should we solve it together.
Speaker 2: It also resists the loudest voice effect to right or
Speaker 2: the law. You know, I've often had a talker in
Speaker 2: the group where it's like, hey, if I just agree
Speaker 2: with you, you stop talking. You know, So to diffuse
Speaker 2: that and go okay, everybody, go in your respective corners
Speaker 2: and draw out your finish your idea to present back
Speaker 2: equalizes the fast talker versus the quieter, more contemplative one.
Speaker 2: Like that quiet person if they had thirty minutes to
Speaker 2: really round out their idea and then present it with
Speaker 2: everybody watching, is going to land better.
Speaker 1: That's a great technique.
Speaker 2: Well an, that's the you know, the amount of moderation
Speaker 2: I've done over the years. It's like, how do I
Speaker 2: make sure the quieter, thoughtful person gets heard and to
Speaker 2: unplug the mob for a bit and let them go
Speaker 2: and do that and then come back and everybody gets
Speaker 2: a cycle talk through the ideas.
Speaker 1: That's great. You know if in this in another case,
Speaker 1: you might have three different ways to achieve the same thing,
Speaker 1: and so rather than you know, and it could be
Speaker 1: something relatively simple. So rather than have everybody go through
Speaker 1: all three of those potential solutions all at once, you
Speaker 1: have them split up for say an hour. All Right,
Speaker 1: you try it this way, you try it that way,
Speaker 1: you try it this way, and then we'll come make off. Yeah,
Speaker 1: bake off. Right. You don't want to spend too much
Speaker 1: time doing that, but you can where if you're starting
Speaker 1: as a group. But if you're not starting as a group,
Speaker 1: then you don't have those options. No, you might have it.
Speaker 2: It might have happened privately in each room and only
Speaker 2: find out an integration with people spent two weeks on it,
Speaker 2: right right, to spend a couple of hours spiking it
Speaker 2: and then bring the code. I mean three people go
Speaker 2: off to write that code in different ways. One of
Speaker 2: them's going to come back O Okay, my idea wasn't
Speaker 2: that good when I actually tried to code, like nope,
Speaker 2: And then the other two to come back with different approaches,
Speaker 2: and it's like, okay, well let's put some insutation around this,
Speaker 2: spend it up. What are we looking at? And I'll
Speaker 2: bet you none of them are correct, like all of them.
Speaker 2: It's like, hey, the way you did that instrumentation was
Speaker 2: better than the way I did it. My code may
Speaker 2: be fast, but you measure better, Like, let's borrow from
Speaker 2: each other and you get a better result. I just
Speaker 2: think about how people feel at the end of the
Speaker 2: day after an experience like that.
Speaker 4: Yeah, it's much more fun you something together.
Speaker 1: Yeah, I feel like I've been at recess one day
Speaker 1: with my friends in grammar school, you know.
Speaker 2: But also heard also took it out for a spin.
Speaker 2: Also got affirmed like that's pretty cool, and I never
Speaker 2: thought of it that way. We're not doing it that way,
Speaker 2: but that was pretty cool. Yeah, that seems very positive.
Speaker 2: So many positive elements to this versus now you know,
Speaker 2: this oscillation between working independently and trying to integrate.
Speaker 5: Well, so touching on the thing that people are going
Speaker 5: to be noticing if they try OUTMA programming, they are
Speaker 5: going to be noticing personal conflicts in a way that
Speaker 5: you didn't have before because you're used to maybe if
Speaker 5: you had a different opinions in a meeting, you would
Speaker 5: split up and then go to different desks, right, but
Speaker 5: here you're sort of you get stuck in that those
Speaker 5: different opinions. You're stuck in that moment of Okay, we're
Speaker 5: not agreeing, we have to solve this, and you're going.
Speaker 4: To be stuck in that.
Speaker 1: Right.
Speaker 4: Yeah. Different, So maybe you will notice.
Speaker 5: That your retrospectives might be a bit less about how
Speaker 5: do we have a faster stand up and more of okay, so,
Speaker 5: how should we handle when we have different opinions?
Speaker 4: What should we do?
Speaker 1: It's not just that, but personality type clashes. Yes, Like
Speaker 1: if you're not emotionally intelligent enough to realize that, oh,
Speaker 1: that person is the direct opposite of me on the
Speaker 1: the Carl Jung's spectrum or the Myers Briggs scale or
Speaker 1: whatever you want to use, and you're not smart enough
Speaker 1: to know that, all right, well, you know I have
Speaker 1: to read past the body language and all of that
Speaker 1: other stuff that I'm taking in as information and just
Speaker 1: get to what they're saying. Yeah, yeah, that can be tough.
Speaker 5: Yes, I think you will grow as a person in
Speaker 5: that sense because you will have to to learn about
Speaker 5: other people's personalities. Sure, a bit more and maybe there
Speaker 5: to say I feel like comfortable when you're interrupting me,
Speaker 5: can I please speak things like that that might come
Speaker 5: up to the surface in a way that wouldn't come
Speaker 5: up to the surface when you don't have to stick
Speaker 5: in the moment.
Speaker 4: Sure.
Speaker 2: Yeah, I keep thinking back to who is the politician said?
Speaker 2: Can I finish root?
Speaker 1: There you goanage.
Speaker 2: But you know, I think and you also will have
Speaker 2: refereeing type personalities in there. It's like, wait, let's hear
Speaker 2: this out. Yeah, I mean it gets challenging when you
Speaker 2: get in a situation where we disagree on this. Somebody
Speaker 2: wants to spite the code. The other one's like, why
Speaker 2: we don't need to do this, Let's get moving on.
Speaker 2: It's different people are different pacing. So but I think
Speaker 2: he speaks Now I'm thinking in terms of it has
Speaker 2: to be an uneed even number, so you don't end
Speaker 2: up with a perfect splint on any position.
Speaker 4: Yeah, it does help to have that.
Speaker 2: Yeah, three or five, four would be problematic. Yeah, because
Speaker 2: you will have that schism. So yeah, better to have
Speaker 2: it and even split, so at least you can get
Speaker 2: a sense of, well, the majority disagrees with you, wethough
Speaker 2: hopefully they do that kindness. There's got to be a
Speaker 2: lot of kindness in this. You're going to be successful.
Speaker 2: It speaks to certain set of personalities.
Speaker 1: Yes, indeed, challenges besides the things that we've talked about. Obviously,
Speaker 1: I've brought up pushback potential, you know a few things
Speaker 1: that you need to be kind of understand before you
Speaker 1: pitch this kind of thing. But what are some challenges
Speaker 1: or potential pitfalls that people could fall into that we
Speaker 1: haven't already talked about.
Speaker 5: I find a typical one that I've heard is when
Speaker 5: people go, this work is not suitable for more programming.
Speaker 1: Interesting.
Speaker 5: Yeah, so you're doing a lot of more work and
Speaker 5: then things get difficult. Maybe it's a bug that you're
Speaker 5: supposed to troubleshoot, and you're a bit stressed out, and
Speaker 5: then it gets a it gets difficult, and then your
Speaker 5: instinct will be to retract from the difficult moment. And
Speaker 5: so people have lots of opinions on this work is
Speaker 5: not suitable for mobbing, And I think.
Speaker 2: Is there work that's not suitable for mobbing?
Speaker 5: Possibly if you're doing something very repetitive like putting changing
Speaker 5: all the lines in a two hundred and fifty row file,
Speaker 5: maybe something like that, that just.
Speaker 2: Means that the rest of the mob is bored. The
Speaker 2: typers typing as fast as they can as opposed to
Speaker 2: like you, if you've got three people who can and
Speaker 2: agree on something that seems very marveable, because otherwise you
Speaker 2: would have found out the disagreement after the code was
Speaker 2: already written.
Speaker 5: Yeah, but I think situations where you are typically troubleshooting
Speaker 5: situations are a bit more difficult.
Speaker 4: Interesting, So what typically ends up? And this is so funny.
Speaker 5: Had a colleague was a senior developer, Like we all
Speaker 5: looked up to him, and he had really good solutions
Speaker 5: every time. And at one point in time someone asks
Speaker 5: him like, okay, so, in your opinion, what makes a
Speaker 5: senior developer? And his answer was someone who reads the
Speaker 5: error messages that Yeah. I was like, surely that can
Speaker 5: That can't be the level that we're holding people out.
Speaker 5: But if you look around, people not reading error.
Speaker 4: Messages often a problem. Yeah.
Speaker 5: And so if you did that in a mob situation
Speaker 5: where no one actually reads the actual message and everyone
Speaker 5: goes like, oh I know what this is yea, and
Speaker 5: people have different ideas on what this is is.
Speaker 4: And you're a bit stressed because he's a production error.
Speaker 2: You let somebody, You let the person on the keyboard
Speaker 2: run with their immediate age things, but my off the keyboard,
Speaker 2: I would want a copy of that error message and
Speaker 2: looking it up, and somebody else is searching through log
Speaker 2: saying how often it's happened? Like debugging is a group.
Speaker 2: Seems really powerful, but it is, but it's hard.
Speaker 4: Oney, hour a bit stressed.
Speaker 1: Yeah, yeah, I can see. Another challenge would be people
Speaker 1: who think slower than other people. So take my wife
Speaker 1: and I playing a game, for example, she can figure
Speaker 1: out we play a logic game, right, and she figures
Speaker 1: stuff out way before I do because I'm a programmer, right,
Speaker 1: I'm methodical. All right, apply this rule, eliminate these possibilities.
Speaker 1: Apply that rule, and she's like, it's there, you idiot.
Speaker 2: You so, But mixing intuitive and logical processing often builds
Speaker 2: great results. Yeah, you know, as long as everyone's got
Speaker 2: a little patience for each other. I'm coming at this
Speaker 2: from an administrator's perspective, where we've been firefighting. It four
Speaker 2: of us firefighting an outage, often remote, you know, with
Speaker 2: an IRC channel open, which ends up being a record
Speaker 2: of us actually diagnosing the problem. And the joke is
Speaker 2: every time it's like, hey, it was a six hour outage.
Speaker 2: It took us one hour detect it, four hours to
Speaker 2: diagnose it, and fifteen minutes to implement the fixing, get
Speaker 2: it up and running again, and then another hour to
Speaker 2: write it up. But everything is about diagnostics. But having
Speaker 2: multiple eyes on logs and searches and so forth made
Speaker 2: a huge difference for us. I never thought of it
Speaker 2: as mobbing, you know, because we weren't acssarily creating anything.
Speaker 2: We were just trying to put out a fire. Yeah,
Speaker 2: but you know, the big rule repeating to ourselves is like,
Speaker 2: don't make the hole deeper. If you're going to make
Speaker 2: a change, you know what change you've made in how
Speaker 2: to revert it. So, you know, often we get it
Speaker 2: back up, but we've mangled six things trying to get
Speaker 2: it back up because we didn't actually fully diagnose the problem.
Speaker 5: And I think that's one of the situations where people
Speaker 5: but it's common that people sometimes do I few them
Speaker 5: up perming from time to time. They can the teams
Speaker 5: can go okay, so this is really important to get right.
Speaker 5: Let's do this thing together, or this is an actual outage,
Speaker 5: let's do that together. But maybe they're not revert to
Speaker 5: it when it comes to normal work.
Speaker 2: Is to do a periodic mob programming with a team,
Speaker 2: maybe as a transition from the from traditional styles.
Speaker 5: I think A common one which is pretty good is
Speaker 5: onboarding team members. Right, that's a good place to start
Speaker 5: if you're in.
Speaker 2: The mob and the mom help them big up, build
Speaker 2: out their configuration, and get to check in able code.
Speaker 2: Always my threshold for how many days after we hire
Speaker 2: someone can they are they capable of checking in code.
Speaker 2: It's not about their programming ability, it's about understanding the
Speaker 2: infrastructure well enough to have gotten to the point where
Speaker 2: their code can be checked in and pulled into this
Speaker 2: into the pipeline. Yeah, doing that as a mob would
Speaker 2: be more fun, But I'd love this statement you said, like,
Speaker 2: this code's too important to do individually, so we'll do
Speaker 2: it as a group. It's like, isn't all code that important?
Speaker 2: As soon as you can say that, then it's like, oh,
Speaker 2: this code is stupid. Let one person work on it.
Speaker 1: Do you transcribe these sessions and refer back to those
Speaker 1: transcripts when you have issues?
Speaker 4: No, we haven't done that.
Speaker 5: We can some transcry to summarize it, because it's good
Speaker 5: to know why I did with this actually happen mm hmm,
Speaker 5: But we haven't had any transcription so far.
Speaker 2: Although let's face it, with a new ll M technology
Speaker 2: of the things. Transcription has gotten way easier, transition and summarization. Yeah,
Speaker 2: you know, if you're paying for the premium version of
Speaker 2: teams that comes in the box now with with copil,
Speaker 2: with M three ct I copilot, that every imagine every
Speaker 2: you know, six seven hour programming session. At the end
Speaker 2: of it, you get an everybody gets an email saying
Speaker 2: this is what you did today. I don't know how
Speaker 2: high quality that would be, but that's the tools we
Speaker 2: have now, Like it's peaks to the whole other elevation. Interesting,
Speaker 2: this may actually be getting easier.
Speaker 1: Yeah, all right, So have we left any stone unturned?
Speaker 1: Is there anything else that you want to talk about now?
Speaker 5: I think I think with the most important thing for
Speaker 5: me is how how I feel like while we're doing
Speaker 5: knowledge work.
Speaker 4: I think that's what we should optimize for.
Speaker 5: And a knowledge work is about its about knowledge sharing
Speaker 5: and learning new things and helping each other grow and
Speaker 5: learning from each other. So I think I think my
Speaker 5: programming is is the best fit for that, and to me,
Speaker 5: it feels like it should be the normal, the normal
Speaker 5: way working the team. And then there could be situations
Speaker 5: where you could go for individual or solo work in
Speaker 5: certain situations, perhaps, but I think the normal should be
Speaker 5: working as a team.
Speaker 1: M h. Great stuff.
Speaker 2: So are there resources you point people to for this?
Speaker 5: Alrica, I would say Woody is all the book. Software
Speaker 5: teaming would be a good a good place.
Speaker 1: What's next for you? What's in your inbox? H oh?
Speaker 4: We are going to be.
Speaker 5: Continuing on a sourcing so I was listening to your
Speaker 5: last episode just today.
Speaker 4: Yeah, so that's gonna be fun.
Speaker 1: Yep. Good well. Thank you for bringing this topic back
Speaker 1: to dot net rocks. It's been great and it's good
Speaker 1: to hear that you're being successful with it, and I
Speaker 1: hope some of our listeners are also thinking about doing this.
Speaker 1: It's good stuff. Thank you, Thank you all right, and
Speaker 1: we'll talk to you next time on dot net rocks.
Speaker 1: Dot net Rocks is brought to you by Franklin's Net
Speaker 1: and produced by Pop Studios, a full service audio, video
Speaker 1: and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online it wop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives. Going
Speaker 1: back to show number one recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code.
Speaker 1: See you next time. You got J Middle Vans
Speaker 4: And