I've found pairing really useful for certain activities. If I'm working on very critical code or if I need to churn something vast out quite quickly, then pairi

I've found pairing really useful for certain activities. If I'm working on very critical code or if I need to churn something vast out quite quickly, then pairing has served me well. As a new generation enters software I've noticed there's some differences, but it follows the same theme. Aside from pairing, they like to watch people code. Notably, I had a codebase that had been through a POC but lacked some E2E tests, so I streamed myself writing tests and refactoring code to make it more testable. The engineer picked up on the tools I was using, what I was doing, why I was doing it, and got to see me make mistakes. I think this is yet another avenue where we have opportunities to engage young devs and onboard them more quickly. As someone that loves and suggests pairing, I'll pass on this: - Never mandate pairing, authorize it. Some people really don't like pairing and will just complain endlessly. - If you authorize pairing, find two people who are really good at it and have them train people on how to do it with your equipment and your environment. - Personalities that clash on a team will predictably not pair well together.