My Remote Mob Programming Experience

35 pointsby zufallsheldabout 3 years ago

11 comments

Developers (or perhaps managers) are always coming up with zany and new ways of doing things. It’s good fun, but mostly just that, fun. I hate hearing ad-hoc rationalizations about “team building” or “collaboration” or “synergy”. Call a spade a spade, it’s some made up technique for having a bit of fun. Some people will hate it, some will like it. Stop coating it in bullshit buzzwords. And preferably, don’t force people to play your game if they don’t want to.

评论 #30383931 未加载

评论 #30390758 未加载

lordnachoabout 3 years ago

I can see some use for the mob, but I think I'd struggle to do it all the time.For certain fiddly things, it can help a lot to have several eyes. "Spot the bug" type issues, perhaps. Also "let's design and agree this interface" seems like a thing that might work, eg if you're all implementing the interface in separate backends on your own time. The big one is probably "let me show you how it currently works" which probably a lot of people have done as an intro to a new team.But just generally coding as group I think could get tiresome. You'd have to think about how to navigate things socially, ie how do I get the shy person to bring their ideas if they have any, and not let the domineering one keep talking over everyone? Plus you tend to think faster than you can implement, and that impedance mismatch would need to be dealt with across people.Finally there's the cost of it. Four devs could easily cost the company a million bucks a year. 250 days of $4000 8 hour days -> $500/hr. Seems like a lot, you'd better have some quite scalable income to make it worthwhile. It's definitely not impossible, but chances are you want to sometimes use the $500, sometimes work separately.Also there's tools to make this a lot easier these days. VS Code lets you share itself online, that's pretty useful.

评论 #30384554 未加载

rpastuszakabout 3 years ago

We used git-mob in my team at Typeform, and besides the script still being a bit fiddly at the time, the overall experience was quite good, especialy with a mix of new and more seasoned developers involved.What I recommend is increasing the rotation time to 25-30 m, especially initially.The approach I'm experimenting with now is using vscode remote (ssh) and working with a shared remote workstation (running on EC2 and GCP).Pros:- no need to worry about sharing the same environment (all of you work off the same workstation after all)- less infra: no need for external CI (you can just run the build scripts on the workstation, via commit-hooks).PS I wrote a quick, practical overview of different pairing/mobbing patterns: <a href="https://sonnet.io/posts/snakes/" rel="nofollow">https://sonnet.io/posts/snakes/</a>

评论 #30384849 未加载

mrozbarryabout 3 years ago

I don't know if this is just advertising, but I'm the main developer behind <a href="https://mobti.me/" rel="nofollow">https://mobti.me/</a> , which is a distributed mob programming timer. I'm aware of mob.sh, and have been asked if there would be any integrations. It has always seemed like it already has a timer, so I kept saying no, and now I have more definitive proof.Anyway, I have a few mobbing tips that I use daily (have been consistently mob programming for 2+ years every day, and my previous job was pair programming all day for 2 years, as well):- No heroes in the mob. If the mob cannot function without a specific person, then you are not mobbing. The only exception may be when a mob is first brought together to work on a new problem where only a single person has domain knowledge, but that shouldn't be relied on beyond a sessions or two.- Respect the timer, but be flexible to finish ideas. Strict timer adherence can sometimes kill the mood, but when someone takes over, it can also kill it. Always acknowledge if the timer is up, and if you need to finish something, ask the mob if it's okay. Don't continue if people disagree.- Prefer high level intentions. Don't tell people "make this variable, call it foo, and use it fetch from this endpoint" if instead you can say "can you fetch this data and store it?" - people can always ask for clarification, but they should be free to figure out the problem on their own.- Ask for corrections after your coder is done writing an idea. If someone has the right idea, but is writing the wrong code, let it play out for a moment. Maybe the code being writing is considering a problem you haven't, or at the very least, the person writing the code can explain it when it's done so the team can decide if it's good or not. Trying to throw in corrections as someone is typing is a lot of cognitive overload.- Reflect often, and honestly. After you're done a session, see how it went. It's okay to call someone out for being too bossy, or highlight if someone isn't being heard, as long as it's done for the sake of being a better team. Maybe the timer is too long, maybe there are too many people, maybe not the right people, and all these sorts of things should be thought about as a team.

jillesvangurpabout 3 years ago

It's a useful thing to do once in a while with your team. However, like pair programming you should not obsess about doing it all the time or forcing people to do it. But it's a great tool, especially if you have a few juniors on your team. Not everybody is a natural coach and sticking everybody in a meeting where they solve stuff together tends to be a great way to nudge seniors into teaching juniors a few things. I tend to sneak in group editing sessions in my team, usually with some vague goal of looking at some feature together or figuring out some issue. I just tell one of them something like "hey can you share your screen?" and before you know it it's 3 hours later.Basically, staring at the same code with a group of people is a great way to spread knowledge in a casual way while actually solving some issues. The issue solving is a nice bonus but it's the knowledge spreading that really counts. You pull people slightly out of their comfort zones by making them work on a topic that isn't necessarily their specialty so they learn a few new things. And they pay attention to how others work.One surprisingly useful thing is that the way people use tools; or even which tools they prefer can provide learning points for others. Somebody will use some neat key combination or some arcane editor feature (e.g. multi selecting bits of text) and you see multiple people doing that some time later. So, this is where I disagree with the article: the last thing you want is everybody using some uniform development environment. Let people use what they want to use show what they can do with those tools. And in case they are being clumsy, somebody will tell them "why don't you just ..." and end up learning something.And finally, they get used to solving stuff together instead of being lone wolfs. I love it when I see people spontaneously decide to hop on discord for an hour or so to solve an issue. Often all it takes is just the realization that help is a chat message away and you can just share a screen and look at stuff together and figure it out.

shimst3rabout 3 years ago

We used mob programming as a framework for conducting coding dojos, it was a very good experience.We based the sessions roughly on the book <a href="https://pragprog.com/titles/mpmob/code-with-the-wisdom-of-the-crowd/" rel="nofollow">https://pragprog.com/titles/mpmob/code-with-the-wisdom-of-th...</a> - having some kind of system is highly recommended.While I haven't got the chance to do mob programming ever since, I'm looking forward to change this in the future. It's such a great tool for mixed-experience teams (especially good for onboarding new hires or junior devs) or cross discipline teams (having a product manager in the mob really helps removing boundaries).

einpoklumabout 3 years ago

> When one team member works on Windows, another in WSL, and a third in a Linux VM, there are countless road blocks to get everyone to reach a point to be able to work meaningfully. Of course we switched to Docker at some point.This seems to be an example of how mob-programming would encourage a "put a hammer to it" approach rather than something more delicate and flexible (e.g. using a meta-build system like CMake to account for platform specificity).I'm not saying that's always a bad thing, but if this is how many/most problems end up being handled then I'm not sure I like it.

评论 #30384491 未加载

buscoquadnaryabout 3 years ago

Thought this was going to be about somebody who accidentally signed up for a sketchy job a recruiter offered them and then eventually found out they were working for organized crime.Was disappointed....

lobstrosity420about 3 years ago

Me and my team do this informally on Discord sometimes, I had no idea it had a name. Yes, this is not something you want to do too frequently, but it can be pretty awesome - especially during those "we have no idea how to implement this" times.

thrower123about 3 years ago

There is a contingent of advocates for mob programming and to a lesser extent pairing, who are just insufferable zealots. Like most programming technique evangelists, they are devoid of nuance and hammer endlessly on their single note. More often than not they have no real accomplishments to backstop their authority either.I'll go Bartleby: I'd prefer not. The entire reason I ever got into programming is because it was a refuge from dealing with people. Working alone on a technical problem is energizing; working with other people on the same is frustrating and makes me want to do violence within an hour or two.

TameAntelopeabout 3 years ago

The amount of outright hostility I've faced professionally for suggesting mob programming was staggering.Some developers really like to be left alone, and it's terrible for the business, but it's been an unspoken thing (or spoken, i.e. Maker Time) for so long that any attempt at disrupting the freedom triggers a substantial backlash.This looks like a lot of fun, I hope I'll be able to implement it someday...