[deadbabe]

Not true. These mobs often become a theater production where everyone pretends to be focused but they’re just collectively pushing along until hopefully someone solves the problem and they are released from their torturous exercise.

[brightball]

That’s just how meetings in general often work.

[ClumsyPilot]

poorly run meetings that is. This usually indicates the process is wrong, or you have wrong people on the call, or without preparation.

[skydhash]

Yeah, software engineering is a collective activity, but programming is not. From my limited experience with pair programming, it would be faster to design on a whiteboard, partition the tasks, and then review each other code.

[phist_mcgee]

My very first day at a new company I was shown around the office and met my team. At 10.30am I was invited to a mobbing session, where I was asked to contribute to writing to some code.

I did not have a single inkling of what the project was in detail or understood anything that was being talked about or written. But I was expected to 'contribute' in a performative way to show that I was useful to the team. It was perhaps the worst intro to a company you can have.

To this day I despise mob programming.

[brightball]

Participating in a mob on day 1 is a very common on-boarding experience. If you're driving, the rest of the team should be guiding you. If you're navigating with no knowledge of the project, you should be observing and asking questions.

The intention is supposed to be "No pressure, come see how we work and meet the team. Feel free to join in if you see something."

There's no faster way to ramp somebody up than onboarding with a mobbing session. Typically you even use the new person's machine so the team can help make sure everything is setup for them to be productive and help work through any unexpected quirks rather than making you figure it out yourself.

If you were asked to jump in and lead with no knowledge, then yes that was terrible.

If you're open to seeing how beneficial the process can be, I'd recommend reading Software Teaming. Great book and establishes all the core rules about what makes a mob work. The most critical rule? Participation has to be voluntary.

[phist_mcgee]

I don't think it's a good idea at all. Myself and the other new hire were terribly confused, we barely remembered our team member's names, and of course there were nerves on the first day.

I disagree that onboarding this way was the fastest, how could any reasonable person be expected to learn a project going in blind in an atmosphere like that?

[brightball]

You aren’t supposed to. The team is supposed to help you get setup, help you navigate around the project, essentially telling you what to type almost when you’re in front of the keyboard. You’ll be taking a tour.

When you aren’t in front of the keyboard, everything will continue with somebody else while the rest of the team continues to talk through the problem. On day 1, your only contribution is probably going to be familiarizing yourself with how things are setup and maybe asking some questions.

I think whoever set this up for you did a really poor job of explaining the intention.

[phist_mcgee]

Just want to say thanks for your replies, it's really great to get a second opinion on this stuff to reassess. Food for thought :)

[brightball]

Happy to!