The last two places I've worked paired fairly heavily, perhaps 50% of the time, and on some squads mobbing has been popular as well. As an introvert, I prefer

The last two places I've worked paired fairly heavily, perhaps 50% of the time, and on some squads mobbing has been popular as well. As an introvert, I prefer to go solo unless I'm working on something I know would benefit from additional knowledge or brainpower, but I've found pairing to be the single most powerful tool I know for training junior devs and for bringing people up to speed on code bases, languages, techniques, or business domains -- which is often quite important. There is undoubtedly a velocity cost in the short term, since ideally the junior person ("junior" here might be a senior person who is new to the code or the business) will "drive" (type) more, and some time is spent in the teaching. But the investment in higher overall knowledge of the team, and in catching bugs/avoiding dead ends early, tends to pay off. One subtle thing that takes time and practice is deciding when to stop pairing, because one or both of you needs a break, or time to think about the problem at one's own speed. I also think one can become over-reliant on pairing for learning. Personally I love reading (even printed books!) for learning languages, and writing for shaping thinking and capturing knowledge for future people. Not everyone loves these activities equally, but they are important skills for engineers to develop, and pairing is not a replacement for them. Finally, sometimes it's good to just go off and think for awhile.[1] [1] https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc