Honestly, it's sounds kinda insane. Mob programming certainly is a tool with its good use cases, like maybe tracking a bug, onboarding a new team member or making critical changes to core stuff.
However, I just can't imagine having three engineers making 100k+ sitted together everyday on a single laptop to write yet another REST api or whatever.
Compare that to 3 engineers struggling through solving problems in isolation because they lack information that is in each other's head.
Culturally traditional management is biased to create the 3 struggling engineers scenario because most management strongly believes that people working on many tasks in parallel is peak efficiency. You see this manifest in places that run the Jira + PR feature mill. Staff that complete lots of jiras and have lots of green dots PRs in their GitHub profile are considered "peak performers"
The fortune 500 is littered with companies full of this anti-pattern. Less so each year though, because if amazing execution on digital transformation matters to the business, to the extent those 3 struggling engineers execute poorly, the competition slowly eats the incumbent's market share.
There's a big difference between "free flow of information" between engineers and enforced mob programming. The former often works quite well with just regular unstructured meetings, whether face to face or online.
We use "mob programming" once a week for 30 minutes, in a way that you described - a "Sentry Smackdown". In zoom, we find 3 of the most "interesting" sentry errors, split up into 3 break out rooms, each group sees what they can find, then 5 minutes at the end to give our update and next steps.
I love it and it's helped get momentum on things which would typically just sit there. BUT, 30 minutes is definitely my maximum for something like this.... even if we did something minor like make this meeting 1 hour long - I would dread it.
Context: we do have an engineer on-call (on a weekly basis) and they will respond to urgent sentry errors, but the above helps sentry errors with less urgency get moving without being a total buzkill for the on-call engineer to look at ALL of them.
