| A method can be effective and practical even if you've never seen it used. My anecdata: I have worked at four different companies over fifteen years that all had pairing as a regular practice. Those teams had fewer defects, higher "social trust", zero silo areas, no cowboys, and rapidly trained Jr engineers into Sr engineers. They were much more aggressive at paying down technical debt. I would estimate that pairing at least half of every day can produce Sr engineers 3x faster than just giving a new hire tickets and doing code review on a PR. Also on a team with strong pairing culture, people often feel safe to "go home" in ways that I don't see in regular teams. Knowing that anyone on the team can handle any ticket you can feels quite liberating. Obviously most engineers hate it though. It's less comfortable. Everyone I've seen who gets good at pairing comments that they are working a lot harder and getting a lot more done than solo. This is hard if you like to spend most of the day puttering around. It's also not as great for deep thinking, so in teams with regular pairing culture it's a good idea to have forced solo time without assigned work just to make sure everyone gets that time to read, think, and process. Of the four teams, one of them definitely was slower pairing, because they actually used mob pairing with 6 people on a zoom call and only the Sr guy typed. That was extremely ineffective but they didn't want to change because the other 5 loved just playing video games all day on a call. That team also was in meetings 6 hours a day, so they only paired like 90 minutes most days. That team had a lot of issues. In my experience if you build a healthy pairing culture, it's the most effective way to build a highly trained stable team. |