[Izkata]

Also on the "forgetting it's a skill" track: pair programming isn't just one thing. There aren't just two roles, the one at the keyboard and the one not - there's a bunch of different roles you can take on, depending on who you're pairing with and how they (and you) work.

For example, with one co-worker at the keyboard, I would fully take on a support role: He was a slow typist, so I'd keep an eye out for typos and quietly nudge him instead of having to wait for a compile/run loop, I'd look up documentation so he wouldn't have to keep context switching, and so on. Before that point though we had roughly equal roles at the design stage (he was a very strong proponent of "keep it simple" and made me realize I was drifting into an "architecture astronaut" mindset, so I think we worked really well together overall).

In another, with some co-workers unfamiliar with a codebase but wanting to learn more, I'd take the high-level guidance role where I'd be mentally working a few steps ahead on the overall design/goal while they worked on the nitty-gritty details. They'd be learning how the pieces fit together without having to worry yet about side-effects or other problems because I'd be acting as guardrails, keeping them on the right track and identifying those problems ahead of time so we can deal unavoidable ones right away. Ideally this role doesn't last long with anyone as they'll need to learn those parts on their own, but it works sometimes.

As a step up from that second one is on/off pairing, where they'd be testing their knowledge on their own to come up with a solution, then we'd pair for a while to make sure they're on the right path and maybe get past a spot where they were stuck on how to do something.