as an introvert I HATE pair or mob programming... I can do it for 30min.. max 1h but all day long = NO GO. I am already searching for a new job because I am sitting always with someone. In pair I am very unproductive. E.g. 5h of "debugging" with someone and no result... Then after work I spend 30 minutes by myself in total flow and can fix the problem. I prefer to work alone, feels better and I work alone faster.

@VictorMartinez-vi7jx

4 ай бұрын

I agree completely man

@arimill1045

2 ай бұрын

"Hey I think better on my own, so I'm going to take 30 minutes to tackle this and come back" Zuill mentioned this in his original talk, Mob programming doesn't ban this. If anything it properly timeboxes you, and if you are incorrect you can come back to the team with new information.

Vulnerability is for the brave. Very nice introduction, already hooked up. I'm trying out mobp for the first time next week. Can't wait for it to happen 🎉

It’s very important to remember: the question isn’t whether pair programming is faster than solo programming. The question is whether it’s at least 2x (pair) or 3-4x (3-4 person mob) faster, as you’re tying up multiple developers concurrently. For it to have positive returns, it must be exponentially more efficient than solo development on any given task, not just slightly more efficient. You may find some perceived gains in speed, but are they outpacing the developers you’re tying up from doing other things? For the ROI to be there, it must be 3-6x more efficient, not just marginally more efficient. Are you REALLY closing your tickets 5x faster? I’ve spent time in teams that mobbed a lot, and they sometimes worked faster, but NEVER were they consistently 4-5x faster. Sometimes it was even slower. It has value for complex tasks, architecture discussions, difficult algorithms, outage or incident debugging and triage, etc. But it’s use is greatly over stated for mundane typical tasks, where it’s simply impossible to obtain a 5x gain in productivity by throwing multiple developers at a problem.

@augustusmurphy7520

2 ай бұрын

I have to raise a flag that "closing tickets" is a very ambiguous way to measure something-I think anyone with experience in the industry can agree that it's very difficult to find two tickets between two different teams that are comparable. I think that the difference between resource and flow efficiency is worth thinking about. Optimizing for "resource efficiency" means that every person on a team should be occupied all the time. Optimizing for "flow efficiency" means we are optimizing for the outcome of the team. Is every ticket we close delivering business value? On the (vast) majority of teams in the industry you might have a 15% chance or something like that. What are the real bottlenecks in software development? For me I'd say paramount among them are knowledge siloes. Next I'd say lack of automation for repeated tasks like acceptance testing or deployments. Those problems can be difficult to solve, and in my experience become much, much easier when working closely with others. Ensemble work (pairing or mobbing) is a skill like any other, and it demands that people are actually able to work together as human beings, not individual cogs in a machine. I would expect a significant dip in productivity if a heavily-siloed team (in other words: the overwhelming majority) just tried to "throw the switch" and work as a mob-you have to be willing to work at it together. But the benefits that can ("can", not "will") be seen from working this way are so far beyond most peoples experience in the industry that describing them sounds like a pipe dream. Take a look at how Hunder Industries works. They are one of the few that has cultivated a culture that is positioned to maximize for flow efficiency. To the point you raised in your last paragraph that is has value for complex tasks but not for simple ones. Most people who practice ensemble programming successfully would agree with you. There is no rule book to follow. You do what makes sense, if you have a mob of 5 and one person is a wiz in writing Python scripts to automate away some repetitive task and can do it in 15 minutes, nothing is stopping them from being on their own machine and doing that on their own before bringing it to the team.

I am autistic and affected by adhd. I do mob programming all day long. While it feels uncomfortable in the beginning, it has a lot of benefits, if done right. The team shouldn't be larger than 5 people, and it should contain all experience levels. You can drop out anytime and join back without being judged, or turn your brain off for some minutes even as the driver. You can bring in new ideas directly during implementation, not weeks ahead in a planning session - something like "you might wanna try mermaid for that diagram in that readme instead of writing it down in sentences". You can teach your colleagues by demonstrating your style of working and learning from them. And the result will be of a higher quality with less unexpected issues just because of the combined experience of 5 brains. Even documentation happens on its own just because someone asks for a comment in code for later use. I don't fear it at all anymore. I'm not even afraid of presenting code to larger audiences. And my imposter syndrome is gone. And yes, there are some tasks I'm doing on my own. When I really need my brain to be not disturbed by someone else's thoughts, like when I'm creating a new architecture or toolchain. Edit: I'm a SRE in a pure operations team. Lots of kubernetes deployments. And we're 100% remote.

@branvandermeer

4 ай бұрын

Thank you very much for you comment and opening up, I really appreciate reading your perspective.

I find myself committing way more mistakes if I'm being watched over. I just concentrate in not making mistakes instead of the actual thing I'm doing, so I go slower and can't get a holistic view of the system because my "mental context budget" is being spent in the social context. Also, I can't solve complex problems because there is no way of having a deep train of thought running while bombarded with constant interruptions from co-workers complaining about minor things, such as names of variables and functions. The best work is deep work, the one you do alone, uninterrupted and fully focused on one single task.

@branvandermeer

4 ай бұрын

As the driver, you're not supposed to be solving complex problems, that's what the navigator is for. If you tend to focus on not making mistakes while others are watching you, I guess you need a more "psychologically safe environment" to free yourself from the judgements of others. Only when you feel totally free to make _all_ the mistakes, the pair/mob can learn. Maybe a book-tip: the 5 dysfuctions of a team, by patrick lencioni.

@manuillo94

4 ай бұрын

That makes no sense. If the one who is solving the problem is not writing it, you are just adding a layer of human error and possible miscommunication. Also, I don't want the first version of what I write to be seen because it usually contains stupid errors that I can see and solve in no time just reviewing it once. Those small stupid errors are the ones I don't want others to see. Not because I'm afraid, but because I respect their time.

I really like this idea. I didn't know it's called "mob programming" but I always preferred that way of programming. Whenever I work on some multi-discipline project I always need to wait for someone to do part of the job that I will integrate. Issue was that other team members didn't know context in which I'm using their stuff. I always spend my free time at work to work with someone on something and when other have free time they can come to me and see how my part operates and how I'm using their stuff. So my take is this: "One multi-talent with bunch of specialists" is how this could work flawlessly. I am starting to freelance soon and having my partners/contractors/vendors work on my code with me is a way to always be in a loop and understand the challenges as they arise vs when someone needs to report this to me.

I think mob programming works well for short periods of time when the whole team can really be engaged and thinking in the same direction (like solving a complex problem/bug or aligning on design decisions early on eg for an api). On mundane tasks however mob programming can be extremely boring as the spectator can feel like they are just waiting. I used to recommend individual/pair/mob based on how much problem solving power a task needs. Trivial tasks can be done quickly by one person, no need to involve everyone else. More complex tasks in pairs, and even more complex can work well in mob if they are likely to engage everyone and everyone can benefit from the learning.

software teaming/mob/pair programming is a huge effort. I don't know if it's something that's healthy to be done all day. I also don't know if sucking the brain dry in problem solving all day by ourselves is healthy either. I think there are definite points to be made about a cadence and dedicated breaks. There are a few things that come with software teaming that can't be reproduced otherwise: - built in quality ( without folks working together, new product updates have to be thrown over the wall for someone to "inspect". a good idea, but quality can't be inspected in, and it creates continued waste cycles ) - product delivery - we are not just "completing a ticket" when we finish an item when working as a group. That this is in production and we are getting feedback to see if it has any type of value pulse. - product mindset and breaking down functional titles - everyone has a product mindset and thinks about the impact to the end Customer.

Thanks for sharing! comment for the algorithm. I hope to see you around for a long time.

I like pair programming for prototyping and debugging parts of the job. I’m curious to try mob programming! I feel that it requires the product owner and whole team to be in sync about it, have same timezone and work hours, that’s not always possible in remote teams. So it might be not for everyone, but I’d give it a try! Thank you for the video!

Mob/pair programming totally sucks for someone with ADHD. I'd rather talk to an AI about my code, and have other people review my code later.

Pair programming has never sped things up for me. I'd be willing to try mob programming, but I expect it to be as worthless as pair programming. I'm also extremely dubious that it helps "focus on the important things." However my experience may be limited by being mainly a back end developer. I can imagine that for UI, having a number of opinions might be helpful.