fourwood posted:

“You can make above the median with some effort” and “160k is massively underpaid in the US” are… not the same thing.

quote:

Programming time (at least 6 hours)

There are three roles, Typist, Navigator and Support.

The Typist is a smart input device, the only thing they input into the computer is what the Navigator told them to, nothing more, nothing less. Watch out for Typist doing things they were not told to - “run-away typist antipattern” leaves the other two just watching, unengaged and loses all the benefits of the mob.

The Navigator tells the Typist what to do. They are doing the majority of the thinking, and executing those plans through the fingers of the Typist.

The Support observes the process as a whole, is responsible for keeping track of the timer, and assists the Navigator as needed; any orders given directly to the Typist by Support are to be ignored by the Typist, as that would lead to “run-away seniors” antipattern, in case the Navigator is less experienced.

After 10 minutes, Support is responsible for enforcing the switch - Support becomes the next Typist, Typist becomes the next Navigator, and Navigator becomes Support. PHPStorm has a simple Pomodoro timer at the bottom status bar that works for keeping the time.

The switch happens at the time interval, not at logical code / ticket boundaries. This ensures that all team members are fully engaged and participating in each logical section (as usually a section requires more than 10 minutes to complete). In case of more complex test setups, this also ensures that each has it set up, or forces the mob to automate the test setup through TDD. Switching happens mid-sentence, which makes picking it up for the next person easier as the code is likely in a syntax error state. For fast switching, use https://github.com/remotemobprogramming/mob command-line tools.

Guinness posted:

Also the very notion that there are 6+ hours of hands-on-keyboard coding to do every day is just laughable as well, unless this is just the most mindless code grind shop ever.

Guinness posted:

I came across this description of one company's mob programming methodology and I'm burned out just from reading it. It sounds absolutely horrific and dehumanizing. I totally get that pairing or even mobbing can make sense in specific situations when trying to debug something gnarly or teach something complex, but doing it all day every day sounds like my literal developer nightmare, especially over zoom. I need my solo flex time to think and solve problems in non-linear ways, and I absolutely cannot be "on" for hours and hours at a time.

https://engineering.meetsoci.com/mob-programming

There's so much awful stuff to quote that I'd just be copy-pasting the whole thing, but here's a taste:

Also the very notion that there are 6+ hours of hands-on-keyboard coding to do every day is just laughable as well, unless this is just the most mindless code grind shop ever.

lifg posted:

I did mob programming for one day. My team collectively decided never again.

Guinness posted:

chglcu posted:

Loud ticking clock and periodic electric shocks if you’re typing slower than the current moving average of all employees.

e: Actually, thinking about it some more, that sounds more tolerable than mob - or even forced pair - programming.

LLSix posted:

Uh, that’d mean roughly half of all employees are being electrocuted at all times.

LLSix posted:

What happens in the morning when everyone first starts working? Do they all get shocked because they haven’t been typing yet today?

Plorkyeran posted:

We sometimes get the entire team together and spend an hour trying to fix some bug and it's great for knowledge transfer and learning about debugging techniques and the like, but an hour of that is enough to leave me fried for the day.

minato posted:

Pair programming is fantastic for knowledge transfer for juniors or new hires. Watching someone else use tools and write code is always an eye-opener; I've found so many neat techniques I wouldn't have found by self-discovery.

Outside of that, so many stars have to align for group programming to be successful that it seems impossible to blanket recommend it. Maybe it'll work for your group? But is everyone:
* fully engaged? no distractions, errands to run, outside interruptions?
* caring about the problem they're solving?
* have been trained so that they all understand the method?
* are disciplined enough to apply it consistently? Auto-course-correct when they start to go off the rails?
* don't have personality traits that subvert it all? (Control freakishness, stubbornness, talks too much, doesn't talk enough, etc etc)

Oh, one of those is missing? Well, poo poo, it's not gonna work.

It also assumes that problem solving is "grinding the problem until you have a solution", when sometimes the solution only presents itself when you've had time to back off & reflect.

quote:

The Typist is a smart input device, the only thing they input into the computer is what the Navigator told them to, nothing more, nothing less. Watch out for Typist doing things they were not told to - “run-away typist antipattern” leaves the other two just watching, unengaged and loses all the benefits of the mob.

The Navigator tells the Typist what to do. They are doing the majority of the thinking, and executing those plans through the fingers of the Typist.

awesomeolion posted:

Thanks for the ideas. I was thinking of setting up two computers and have each one working on a different task and switch back and forth. Feels kinda unrealistic though for some reason.