In video gaming, its standard advice to record your gameplay and review your own games to spot mistakes and areas for improvement. Reviewing recorded games is extremely important to improving because:
Competitive gaming modeled itself after professional sports, where experience teaches us "coaching" and "reviewing your own performance" make a big difference. Not everyone can afford a coach, but self-review is free (even if not as good), so there's no excuse not to self-review. And yet "watch your own replays" is still common advice to people asking for tips to improve, because lots of people don't do it. If you don't do reviews of any kind - either on your own or with the help of a coach - then you just aren't that serious about improving at your game. Which is OK! But still, many people clearly want to get better...but default to grinding more games, or watching more Twitch.tv, instead of reviewing their replays.
What I'm getting at is this: I think we're overlooking "reviewing performance replays" as a way for software engineers to improve. I've basically never heard this suggested in programming, even though there isn't any reason why it wouldn't work. Maybe this is based on the (completely unconvincing) arguments about how software engineering is so different from every other human endeavor that there is nothing to learn from other fields.
Try it: record yourself programming for say, 2-3 hours, and then watch your own replay on fast forward. Where are you making mistakes? What are you wasting time on? How could you be more efficient?You might find that:
I've done (and noticed in others) all of these issues here! Catching and fixing mechanical mistakes like this easily explains "10X programmer" differences in productivity. But as an industry almost nobody focuses on any of this, ever, except maybe, briefly, once, during employee onboarding at a "let me show you how our internal tools work" session. And then they get punted to The Wiki.
What about code review? Isn't that part of how we coach programmers to be better? Sure, but that's critiquing the output, not the actual process of the coding. And it's hard to improve the output without drilling down into the process. I think this is a failure, because my experience is that SO MUCH of a programmer's productivity comes from mastering skills, tools, and workflows...not just memorizing a bunch of syntax, APIs, and even design patterns.
I suspect this is part of the appeal of pair programming - pairing lets us learn skills and shadow-coach each other in a profession that essentially never does otherwise. There are so many things that I can correct and improve on the spot if I'm pairing with a more junior developer. So in that sense it's actually more like a coaching session than a "pairing" session. But this is suboptimal, because when we are "pair programming" we are usually trying to accomplish a specific task, and "hey let me teach you to (open and save files with hotkeys |use a debugger)" feels like a sidetrack. It's almost better if we focus on coaching the "mechanics" of programming separately.
On the other hand, lots of people dislike pair programming because 1) yeah it's kind of wasteful, 2) some people just don't like the pressure of coding live in front of an audience, and 3) live coding with another person can be kind of frustrating if you're not operating at the same speed , or the person at the keyboard has mechanics limiting the productivity of both engineers. The solution to all of this is to do coaching and skill transfer with replays: that way we have the ability to fast-forward and skip uninteresting parts, and no performance anxiety.
Software engineering as we know it is only roughly 50-60 years old at this point - still in its infancy. Future generations will regard us as basically cavemen, programming with primitive tools and espousing superstitions like "typing speed doesn't matter:"
In the future, I think replays and live coaching will be a key way to train software engineers. We'll look back and wonder why we didn't do it sooner. Well, whenever we start trying to train software engineers.
 In my experience, true pairing works best when both programmers have roughly equal experience and familiarity with the codebase relative to the problem at hand, so they can both contribute and review the work as it's being done live. When there's a big skill imbalance it feels more like a coaching session, but if you ignore this phenomenon and try to "pair" anyway, it can get frustrating for both parties - nobody enjoys "programming at 20% speed but also no multitasking," and nobody enjoys being told what to type without understanding what is going on.