When you become a senior dev, you should be taking time to help juniors build their skills. You will need to involve them in architectural discussions, pair programming for complex PRs, etc. So these are skills you need to have, IMO.
One technique I've seen work well is, build a PR for a specific feature, then ask someone if you can do a quick "pair programming" / demo session where you outline the architecture, show the code, maybe debug and step through some stuff. Like a highly developer-oriented demo, as a preliminary step for the other dev hitting Approve on your PR.
This has a lot of benefits:
- It can morph into pair programming
- A lot of questions that are raised in a good PR will be answered synchronously
- The PR feedback you get will be much, much better--in fact, it'll be the kind of feedback that you turn you into a mid-level and eventually senior dev.
However, I think that peer programming does not work with everyone. Sometimes the peers do not match and getting work done is extra difficult. It also depends on the task. In my experience there were things that I could do better working alone, e.g. working on specification stuff like parsing a complex file format where I read a lot of documentation in the first place.
If you have someone to practice with, I think you could try to improve it and see how it works, but it should still be fun and not something you hate and you just need to do to improve.