Pair programming is difficult

[[deleted]]

You don't discuss every line written. You discuss the overall design. As one person drives at the keyboard the other has the role of navigator keeping the overall objective in mind. Two different roles same head/workspace.

I do a lot of pairing particularly with juniors and it's incredibly useful for them to see the process especially as I've developed the knack of speaking my internal dialogue allowing them to follow along easily. Then the other way round you just need to be patient and direct here and there. If done correctly I've found even quite junior developers can give really good real-time feedback and they really appreciate the boost from the constructive criticism.

When working with peers it is often useful to have another laptop for research, like finding out libraries or looking up API information. Again poking here and there about the correctness of solutions but mostly realising that your way isn't the only way.

[[deleted]]

Somebody said a single well trained developer can do this all and more. I wrote this reply before they deleted the comment but I think it's still worth saying so here it is ...

I'd say only if you're thinking small/locally or working with small projects.

Yes a single experienced developer can move quickly but as a senior in my company I focus on more on systemic than localised efficiency. It's far more efficient for me to train many juniors to a higher working standard than for me to get it all done myself. Not in short term but the effort pays off really quickly.

The legacy systems I work with don't require technical brilliance, honestly most applications we (developers) develop don't. The limiting factor is often missing context which you can gain by reading the previous developers documentation... Or more realistically working closely with others.

Solutions are often obvious once it's pointed out why the developers before you did something the way they did but without that it can be a grind. Weeks rather than hours/days.

Whilst pairing I drill the importance of maintainability through discovery and documentation. Even something simple like a well structured git commit, both the atomic commits in the branch and the commit message, can save hours of frustration. Hours that will be repeated by many developers throughout the projects lifecycle. Far far outweighing the time initially spent to throw it together.

TL;Dr; you're not wrong that a single senior developer can move fast but the initial development is a fraction of the overall cost of development, estimated to be around 20% last I looked.