I hate pair-programming/mob-programming. I’m an introvert, and I got into computers because of that. If I had known that programming would turn into a group sport, I don’t think I would have gotten into the field in the first place. It also seems that the type of programming that mob-programming is bad at, is the type of programming that I enjoy.
Not sure if it is part of being an introvert or not, but my problem with it is that my brain really can’t handle outside interference when it is focused on solving something. To get out of the frame/context that I am mentally building up, or to adjust it to get into the mental context of another person looking at the same problem is so inefficient that it wastes almost all my energy without actually getting closer to the solution. I am not capable of splitting my brain into parts where one handles the communication and the other that is programming. It is all or nothing.
That said, calls where it is more of a sketching and brainstorming thing can be productive. For those it is better to have a more wandering mind and not a sharply focused mind.
One thing mob/pair programming proponents have to start thinking about is how much more draining it is when carried out in a language that’s not your native language. I like to think that my level of English proficiency allows me to collaborate seamlessly with other anglophones, but no matter how many decades I spend reading and speaking in English, it never seems to get any less draining to speak in and listen to English while I’m working on a problem at the side. Or similarly, responding to chat messages while listening in to a meeting. It’s simply too hard to multitask communication in a non-native language.
I know that this is a native/foreign language issue, because it doesn’t happen in my native language.
I’m happy to be the over-the shoulder guy asking questions and giving advice, but really only to help solve something difficult. I can’t stand being watched so feel as you do wrt pairing as usually threatened by middle management drunk on buzzwords and looking to put their fingers into the pie.
FWIW, I’m also an introvert who got into programming to take a break from people. Pairing has always pushed me near the edge of my limits. In larger groups following a driver/navigator/everyone-else rotation, the rotation itself leaves more room for downtime, and the size of the group also leaves more room for anybody to step out for any reason. I can’t put a finger on when or how I suddenly got real comfortable in just about any ensemble/mob, but it’s something that happened for me. I still enjoy programming solo, too (though when I’m banging my head against the wall on something, I inevitably rue the absence of other brains).
You know your needs and desires best. Nobody should be forced to work together: it doesn’t feel good and it’s not cost-effective. I’d suggest only that you try to stay open to the possibility that there’s some future scenario in which programming-together might feel different for you.
Disclaimer 2: it’s also fun for me. I can enjoy pairing but I enjoy groups of >=3 more.
Claim: mob/ensemble programming is merely differently challenging for optimization work than it is for bugfixing than it is for feature development.
Verbiage in attempted support of claim: In feature development we usually try to finish one thought at a time. In bugfixing we usually try to pool our skills and intuition to get to the bottom of one strange thing. In optimization work, as the author says, we usually try a bunch of a different things until we find one that’s worth keeping. That feels a little different and requires our patience and joint attention to be applied differently, is all. If we value the shared learning produced by programming as a whole team in other situations, we can continue to value it in these. If our ensemble is large, we might still parallelize optimization work by splitting into smaller ensembles that synchronize briefly whenever they’ve finished trying something. Or, as the author says, send off a person or two to do all the experimenting and bring back their findings. Plenty of real teams that ensemble by default do choose this. Also note that optimization is not the only kind of work that can benefit from “set-based design.”
The last time I tried mob programming it completely derailed when a simple npm install took ages on my machine and the discusssion became what OS I should use.
I’m pretty skeptical of mob-programming as more than a “sometimes tool”, but this definitely sounds like a case where “you’re holding it wrong.”
You’re discussing what OS to use? Folks in the group need to feel comfortable saying “fun talk, but don’t we need to get back to working on the problem?” This takes some time to get a feel–the right amount of digression isn’t zero, but it’s not “talk about whatever you want for as long as you want”.
Or can someone else drive? Push code in progress, let someone else work on it.
Everyone is blocked by the same npm install, and it really just is that slow? If there’s no other work for the mob to productively do, get some coffee and come back. Edit: or maybe debugging why NPM is slow is a worthwhile activity. It’s a judgment call.
Nice topic – I have another explanation in addition to “trying lots of things and then throwing most away”, or “start-stop motion”.
My explanation is that performance is like security – it’s a holistic property of the code. It’s not modular; it doesn’t live in one place.
So to optimize, you need to jump around between levels, between code written by different people, and even between languages and tools.
Now actually that sounds like more people would help? More people have more experience with different code, tools, and techniques.
I think getting input from many people is important, but one person has to “figure out the optimization”. They have to figure out how to make it faster without breaking things – that’s always the challenge.
It’s probably a mix of reasons why optimization isn’t good for mob programming, but IME that’s one of them.
I don’t have much experience with “mob programming” but I imagine it can be very good for writing new code that fits well within the existing architecture. Because you have input from everybody and are not doing things in your own idiosyncratic way. You can spread knowledge about the established conventions.
But I think optimizations can be pretty idiosyncratic by their nature. They tend to break abstraction, and there’s not one way to optimize. In fact I’d even say that the best or most clever optimizations are the ones that break abstraction.
I think this is a good insight, and it’s related to the cases where pure red-green, small step TDD is most effective. Lots of people sell TDD as a panacea, and it’s a good practice, but there are types of code where it doesn’t work well. The “red-green, small step” qualifier is very important. If your concept of TDD is “try to write tests as early as possible, make them run as fast as possible”, nothing I’m saying contradicts that.
One way pure TDD can fail is that it seems to work best “as a design tool” for certain types of code. Hillel shared a wonderful case study where Ron Jeffries tried to TDD up a Sudoku solver, and it didn’t go well, because it’s just that important to get the big picture right, and TDD wasn’t by itself an effective tool for that (https://buttondown.email/hillelwayne/archive/i-have-complicated-feelings-about-tdd-8403/).
Another case is certain types of code that involves writing new algorithms or using complicated data-structures. A lot of times for an algorithm or data structure, the most effective tests cover the entire algorithm, not a smaller unit. Moreover, when it comes time to change the internals, you often end up taking bigger steps, as you have to move from one functioning implementation/algorithm to an entirely different one in one big step. Having tests is incredibly important here, but you’re probably not doing rapid cycles of red-green iteration. It might be more like “break 100 tests, stare at one/debug it for a half hour, fix it, now you have 35 failing tests. Repeat.”
In optimization terms, I think TDD looks a lot like a form of local search. You start out in a location, make small changes, and see if they improve your situation. When you’re handling one requirement at a time, incrementally building something up, this works really well.
Yeah I would definitely say that TDD hill climbing vs. “global optimization” are necessary alternations / complements. Hillel is talking about software architecture there, and I do consider architecture similar to optimization, in that it’s holistic and you’re breaking – actually DEFINING – boundaries.
It reminds me of what I wrote here - https://news.ycombinator.com/item?id=39438552 - IME we are always alternating between hacking and reading/learning. Either extreme is bad, and we’re always learning from the last mistake.
Same thing with TDD local search vs. global optimization – I think the best thing is alternating, and that’s the best chance of converging on something good.
Sometimes that alternating is done by different people too, which is why it’s good to have some diversity in viewpoints. Software can be an argument :)
“Mob programming” is something I’d never even heard of until now, and frankly it sounds like absolute hell.
But, I want to hear how they’re selling it, so can anybody here point me to some of the information about these “Hunter industries” people with regards to the method?
I’m big on group work, but not mob programming exactly—I think many of the benefits of a group are lost if you only group up people of the same role. I think you get more shared ownership, awareness, team focus, and empathy for each other’s concerns when you form a group to carry a task through multiple process steps that would otherwise involve handing off from one role to another. You can just do all that together. We call it a road trip, as opposed to a relay with handoffs: everyone in the car, periodically switching drivers. It’s good that it means fewer tasks in flight and removes the wait queues between those steps, but for me the bigger deal is the overlap: There’s no error-prone handoff event or game of telephone; you’re all there the whole time. Which process steps you can combine with group work really depends on your particular project, but I’ve had success with groups of 1-2 software engineers plus 1-2 test engineers, and other roles if the task calls for them.
Regarding the article’s bit about throwing things away together, I think mobs can be pretty good at that if they involve multiple disciplines. Working independently, I may avoid discarding tests that strike me as low value, because that’s closer to someone else’s center of responsibility and it either risks stepping on their toes or involves an interruption or sync. But if my test engineer is there with me we can just talk about it for a moment and make a call we’re both comfortable with. See also deviations from visual designs.
Mob/ensemble “programming” is a misnomer, because you’re exactly right. Teams that ensemble often think it’s only supposed to be programmers in the ensemble. But if they involve testers, UX designers, product managers, business analysts, or (gasp!) customers, they’re just about guaranteed to come up with something more relevant and more valid.
Proponents of pairing/mobbing attribute all sorts of benefits to it: higher quality code, more shared ownership
It’s interesting to me that code quality / shared ownership is touted as one of the advantages of pair/mob programming.
Maybe it’s the specific orgs/environments I work in but I find best/cleanest code I’ve contributed to is code that has a singular vision written mostly by an individual. I can usually spot code paths that have been touched by different groups, unless you’re super vigilant I think code quality can easily be spoilt by too many cooks.
Conversely I see individual ownership and responsibility for parts of a system as an advantage not a flaw. It’s nice to be able to just triage tickets/bugs off to specific developers responsible for that part of the system. Usually they’re able to turn around a fix super fast because they have the knowledge required.
I don’t think the shallow knowledge gained by pairing/mobbing on small tickets is really a substitute for the deep knowledge you get by just quietly experimenting/tinkering on part of a system that you own.
I’ll regularly pair with colleagues when they’re blocked on something and I have the knowledge to help them, (or vice versa). But the idea of multiple people working on a single feature just seems like a huge waste of time/resources.
Naysayers claim it slows team velocity down, is emotionally exhausting, and only works with very particular personalities. To which the advocates respond that if mobbing doesn’t work, it’s a problem with your company culture.
This may very well be how some advocates are responding to this criticism, but it’s a terrible answer.
The primary benefit of ensemble programming is knowledge transfer, of getting people up to speed on things they don’t understand well. Or, solving a problem together that one perspective alone might take much longer to solve.
It’s not a replacement for individual programming time, it’s a complement. And the level of benefit the team gets from this depends on the people involved. Some people simply learn one-on-one better than they will handing them a bunch of documentation.
Simply optimizing for information density is the wrong priority when you have unequal context; you need a dialectical process in order to ensure you are being actually understood.
An important thing about software engineering is reducing feedback loops so that you can iterate faster. This is how ensemble programming works: you can’t be sure that what you’re saying to someone is making sense until you hear them reflect it back to you, and written communication slows down this process.
At a certain point of your career, it will become more important to think about team-level dynamics instead of just your own personal work. I consider myself a force-multiplier: my job is to make other people more productive. Ensemble programming is a valuable tool in my professional toolkit for this reason.
I hate pair-programming/mob-programming. I’m an introvert, and I got into computers because of that. If I had known that programming would turn into a group sport, I don’t think I would have gotten into the field in the first place. It also seems that the type of programming that mob-programming is bad at, is the type of programming that I enjoy.
Not sure if it is part of being an introvert or not, but my problem with it is that my brain really can’t handle outside interference when it is focused on solving something. To get out of the frame/context that I am mentally building up, or to adjust it to get into the mental context of another person looking at the same problem is so inefficient that it wastes almost all my energy without actually getting closer to the solution. I am not capable of splitting my brain into parts where one handles the communication and the other that is programming. It is all or nothing.
That said, calls where it is more of a sketching and brainstorming thing can be productive. For those it is better to have a more wandering mind and not a sharply focused mind.
One thing mob/pair programming proponents have to start thinking about is how much more draining it is when carried out in a language that’s not your native language. I like to think that my level of English proficiency allows me to collaborate seamlessly with other anglophones, but no matter how many decades I spend reading and speaking in English, it never seems to get any less draining to speak in and listen to English while I’m working on a problem at the side. Or similarly, responding to chat messages while listening in to a meeting. It’s simply too hard to multitask communication in a non-native language.
I know that this is a native/foreign language issue, because it doesn’t happen in my native language.
Funny, I hate mob programming but love pair programming.
I’m happy to be the over-the shoulder guy asking questions and giving advice, but really only to help solve something difficult. I can’t stand being watched so feel as you do wrt pairing as usually threatened by middle management drunk on buzzwords and looking to put their fingers into the pie.
FWIW, I’m also an introvert who got into programming to take a break from people. Pairing has always pushed me near the edge of my limits. In larger groups following a driver/navigator/everyone-else rotation, the rotation itself leaves more room for downtime, and the size of the group also leaves more room for anybody to step out for any reason. I can’t put a finger on when or how I suddenly got real comfortable in just about any ensemble/mob, but it’s something that happened for me. I still enjoy programming solo, too (though when I’m banging my head against the wall on something, I inevitably rue the absence of other brains).
You know your needs and desires best. Nobody should be forced to work together: it doesn’t feel good and it’s not cost-effective. I’d suggest only that you try to stay open to the possibility that there’s some future scenario in which programming-together might feel different for you.
Disclaimer 1: mob/ensemble programming is one of the most powerful tools in my software development coaching toolbelt.
Disclaimer 2: it’s also fun for me. I can enjoy pairing but I enjoy groups of >=3 more.
Claim: mob/ensemble programming is merely differently challenging for optimization work than it is for bugfixing than it is for feature development.
Verbiage in attempted support of claim: In feature development we usually try to finish one thought at a time. In bugfixing we usually try to pool our skills and intuition to get to the bottom of one strange thing. In optimization work, as the author says, we usually try a bunch of a different things until we find one that’s worth keeping. That feels a little different and requires our patience and joint attention to be applied differently, is all. If we value the shared learning produced by programming as a whole team in other situations, we can continue to value it in these. If our ensemble is large, we might still parallelize optimization work by splitting into smaller ensembles that synchronize briefly whenever they’ve finished trying something. Or, as the author says, send off a person or two to do all the experimenting and bring back their findings. Plenty of real teams that ensemble by default do choose this. Also note that optimization is not the only kind of work that can benefit from “set-based design.”
The last time I tried mob programming it completely derailed when a simple npm install took ages on my machine and the discusssion became what OS I should use.
I’m pretty skeptical of mob-programming as more than a “sometimes tool”, but this definitely sounds like a case where “you’re holding it wrong.”
Nice topic – I have another explanation in addition to “trying lots of things and then throwing most away”, or “start-stop motion”.
My explanation is that performance is like security – it’s a holistic property of the code. It’s not modular; it doesn’t live in one place.
So to optimize, you need to jump around between levels, between code written by different people, and even between languages and tools.
Now actually that sounds like more people would help? More people have more experience with different code, tools, and techniques.
I think getting input from many people is important, but one person has to “figure out the optimization”. They have to figure out how to make it faster without breaking things – that’s always the challenge.
It’s probably a mix of reasons why optimization isn’t good for mob programming, but IME that’s one of them.
I don’t have much experience with “mob programming” but I imagine it can be very good for writing new code that fits well within the existing architecture. Because you have input from everybody and are not doing things in your own idiosyncratic way. You can spread knowledge about the established conventions.
But I think optimizations can be pretty idiosyncratic by their nature. They tend to break abstraction, and there’s not one way to optimize. In fact I’d even say that the best or most clever optimizations are the ones that break abstraction.
I think this is a good insight, and it’s related to the cases where pure red-green, small step TDD is most effective. Lots of people sell TDD as a panacea, and it’s a good practice, but there are types of code where it doesn’t work well. The “red-green, small step” qualifier is very important. If your concept of TDD is “try to write tests as early as possible, make them run as fast as possible”, nothing I’m saying contradicts that.
One way pure TDD can fail is that it seems to work best “as a design tool” for certain types of code. Hillel shared a wonderful case study where Ron Jeffries tried to TDD up a Sudoku solver, and it didn’t go well, because it’s just that important to get the big picture right, and TDD wasn’t by itself an effective tool for that (https://buttondown.email/hillelwayne/archive/i-have-complicated-feelings-about-tdd-8403/).
Another case is certain types of code that involves writing new algorithms or using complicated data-structures. A lot of times for an algorithm or data structure, the most effective tests cover the entire algorithm, not a smaller unit. Moreover, when it comes time to change the internals, you often end up taking bigger steps, as you have to move from one functioning implementation/algorithm to an entirely different one in one big step. Having tests is incredibly important here, but you’re probably not doing rapid cycles of red-green iteration. It might be more like “break 100 tests, stare at one/debug it for a half hour, fix it, now you have 35 failing tests. Repeat.”
In optimization terms, I think TDD looks a lot like a form of local search. You start out in a location, make small changes, and see if they improve your situation. When you’re handling one requirement at a time, incrementally building something up, this works really well.
Yeah I would definitely say that TDD hill climbing vs. “global optimization” are necessary alternations / complements. Hillel is talking about software architecture there, and I do consider architecture similar to optimization, in that it’s holistic and you’re breaking – actually DEFINING – boundaries.
It reminds me of what I wrote here - https://news.ycombinator.com/item?id=39438552 - IME we are always alternating between hacking and reading/learning. Either extreme is bad, and we’re always learning from the last mistake.
Same thing with TDD local search vs. global optimization – I think the best thing is alternating, and that’s the best chance of converging on something good.
Sometimes that alternating is done by different people too, which is why it’s good to have some diversity in viewpoints. Software can be an argument :)
“Mob programming” is something I’d never even heard of until now, and frankly it sounds like absolute hell.
But, I want to hear how they’re selling it, so can anybody here point me to some of the information about these “Hunter industries” people with regards to the method?
I’m big on group work, but not mob programming exactly—I think many of the benefits of a group are lost if you only group up people of the same role. I think you get more shared ownership, awareness, team focus, and empathy for each other’s concerns when you form a group to carry a task through multiple process steps that would otherwise involve handing off from one role to another. You can just do all that together. We call it a road trip, as opposed to a relay with handoffs: everyone in the car, periodically switching drivers. It’s good that it means fewer tasks in flight and removes the wait queues between those steps, but for me the bigger deal is the overlap: There’s no error-prone handoff event or game of telephone; you’re all there the whole time. Which process steps you can combine with group work really depends on your particular project, but I’ve had success with groups of 1-2 software engineers plus 1-2 test engineers, and other roles if the task calls for them.
Regarding the article’s bit about throwing things away together, I think mobs can be pretty good at that if they involve multiple disciplines. Working independently, I may avoid discarding tests that strike me as low value, because that’s closer to someone else’s center of responsibility and it either risks stepping on their toes or involves an interruption or sync. But if my test engineer is there with me we can just talk about it for a moment and make a call we’re both comfortable with. See also deviations from visual designs.
Mob/ensemble “programming” is a misnomer, because you’re exactly right. Teams that ensemble often think it’s only supposed to be programmers in the ensemble. But if they involve testers, UX designers, product managers, business analysts, or (gasp!) customers, they’re just about guaranteed to come up with something more relevant and more valid.
It’s interesting to me that code quality / shared ownership is touted as one of the advantages of pair/mob programming.
Maybe it’s the specific orgs/environments I work in but I find best/cleanest code I’ve contributed to is code that has a singular vision written mostly by an individual. I can usually spot code paths that have been touched by different groups, unless you’re super vigilant I think code quality can easily be spoilt by too many cooks.
Conversely I see individual ownership and responsibility for parts of a system as an advantage not a flaw. It’s nice to be able to just triage tickets/bugs off to specific developers responsible for that part of the system. Usually they’re able to turn around a fix super fast because they have the knowledge required.
I don’t think the shallow knowledge gained by pairing/mobbing on small tickets is really a substitute for the deep knowledge you get by just quietly experimenting/tinkering on part of a system that you own.
I’ll regularly pair with colleagues when they’re blocked on something and I have the knowledge to help them, (or vice versa). But the idea of multiple people working on a single feature just seems like a huge waste of time/resources.
This may very well be how some advocates are responding to this criticism, but it’s a terrible answer.
The primary benefit of ensemble programming is knowledge transfer, of getting people up to speed on things they don’t understand well. Or, solving a problem together that one perspective alone might take much longer to solve.
It’s not a replacement for individual programming time, it’s a complement. And the level of benefit the team gets from this depends on the people involved. Some people simply learn one-on-one better than they will handing them a bunch of documentation.
Simply optimizing for information density is the wrong priority when you have unequal context; you need a dialectical process in order to ensure you are being actually understood.
An important thing about software engineering is reducing feedback loops so that you can iterate faster. This is how ensemble programming works: you can’t be sure that what you’re saying to someone is making sense until you hear them reflect it back to you, and written communication slows down this process.
At a certain point of your career, it will become more important to think about team-level dynamics instead of just your own personal work. I consider myself a force-multiplier: my job is to make other people more productive. Ensemble programming is a valuable tool in my professional toolkit for this reason.