I want to tell you a bit about peer programming and specifically what it can do for what I call "team quality" Don't worry we'll define both in a moment.

First a little bit about myself...

So, to the defintions! What is peer-programming

pair = 2 people, mob = whole group might not want to call 'mob' 'mob' anymore - but I like the pitchforks visual

Ok, so why are we doing this? And this one's a rhetorical question, I'll give you some answers.

great tool to get a senior engineer together with a more junior share knowledge very directly about where to find things in code, how to do things, how things work. code qualtiy usual reason, alternative to a pull request way to get two pairs of eyes

no proven benefits, very few actual studies on it, and the most cited one focuses on students working in group settings rather than alone. There is no scientific data that would say that peer programming makes sense in a professional setting. inefficient -> from one dev prodcuing 1000s of line of code (don't use that meassure!), to two devs producing the same amount of code. Maybe even less, they talk, they need breaks... really ineffcient. And the one I find really interesting - it's difficult for a lot of people to get into a collabortative way of work. Now that's the interesting part, why is it difficult for people?

I'd argue It's very often difficult for people, because it puts in on situatations of vulnerabilty. Suddenly you have to share your code and your thought pricesses as they're being created. You don't get that moment to pause and polish up your work before you share it with your colleagues. And that puts you into a very vulnerable situation, that would argue that's why a lot of developers actually don't like to do it.

Cool. A lot of negatives. Very few positives. People don't like it. Why should we be doing this?

team quality. I already told you in the title. But what actually is team quality? I define it as three things

trust. a great team will be made up of individuals that trust each other.

having a shared vision of where you're going to. together.

taking shared ownership of that journey towards your vision. These three things are for me, team quality, or what makes a great a team.

and peer programming can actually help us with that. Becuase it creates situations that foster all of these things.

I already mentioned it, peer programming requires you to share

our unpolished work

and our thought processes as they're happening, with our team mates. I doesn't give us that comfortbale situation where we work in our own chamber, and only when we're done, when the work is nice and polished, ironed out all the rough edges, only then share it with someone else. No, you share as you're creating - and that puts you into that situation of vulnerability.

But as you're doing that and realize that they're not ridiculing you for it, but they're there with you to solve a problem. And they're sharing just as much of their own. It allows us to gain a deeper understaning of how we each think and approach problems. And it builds that trust between people. So vulnerability fosters trust, and vice versa we're more open to being vulnerable with people we trust.

Another part, related to trust and also taking shared ownership, peer programming ensures feedback is given as early as possible

you give and receive feedback as you're creating something

not when your work is "done". I've mentioned before the usual way of ensuring code quality via peer reviews, which a lot of you are certainly familiar with. And you're also certainly familar with these situations where you're "done", you open a pull request, and are already off working on something else, and only then you're colleagues come and tell you, you've done something wrong. This point is the worst possible moment to receive feedback. You're 'done' and now someone tells you, you have to stop what you're doing and go back to fix things.

Now peer programming adresses this issue, by ensuring you get feedback while you're doing the work, and it puts you into a situation of collaboration, where you're solving a problem together.

rather than a situation of opposition, where you're critiquing your peers work after the fact.

One slightly different benefit, that again relates to building trust and shared ownership of things, is that peer programming can create collisisions between people.

And by 'collisions' I mean those one on one moments, where you just bump into each other after a meeting, or at the coffee machine, or quickly ask over the top of your screen. They might not always be positive, these moments might even be heated technical discussions or arguments about your favorite football team, but while they happen in an office setting...

they're becoming very infrequent especially for distributed and hybrid teams but if you're not careful also when everyone's remote. Working together on a task of course doesn't mean you're spending hours trading off who types, but it means taking breaks, discussing how to solve problems and also what you're planning to do next weekend. As such, it can create one on one moments between people that might not otherwise connect with each other.

Ok. The previous arguments mostly adressed trust and shared ownership, and apply for both one-on-one peer programming and working in a group. One thing where mob programming specifically can contribute to team quality is on building a shared vistion.

The whole group creative process of mob prorgamming

strenghtens the shared vision about how code should look and be created.

It allows things like work agreements, code standards, etc. to emerge organically, rather than being rules that someone has predefined thinking they'd be useful.

Additionally, both mob programming - where the whole team gathers around a computer and creates code - and mob review - where you just gather around a screen and take a look at code together and discuss things - can create moments to refine what the whole team values. Do we do test driven development, do we need some certain amount of test coverage, how should our classes be named, do we write an I in front of all our interfaces or are we sane people and think that's useleless. All of these agreements can emerge organically from discusson and can be reviewed and refined as we're using them.

Cool, so if I now convinced you, that you want to start improving your team quality with some peer programming, where do you actually start?