Pair programming is a form of communication, it's a way for people to teach each other. Some people really work well with this learning style, and if you're one of those people, I would absolutely find ways to do it regularly.
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.
I as a senior definitely learned some things from our juniors, too. I still remember some keyboard shortcuts, I learned in these sessions, like ALT+SHIFT+UP / DOWN to increase/decrease the marked text or with Eclipse Keymap ALT+Y to mark the next occurrence for multi-cursor tasks.
My first peer programming experience was exhausting. After 2 hours I was done for the day. After practicing for a few weeks, we could do around 4 hours split into 2 hour sessions without getting too tired. So it definitely has an effect to practice. Another positive aspect of it is (pretty likely) getting less distracted. You need a strong focus to concentrate on the task and the other person.
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.
Pair programming is a form of communication, it's a way for people to teach each other. Some people really work well with this learning style, and if you're one of those people, I would absolutely find ways to do it regularly.
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.
I as a senior definitely learned some things from our juniors, too. I still remember some keyboard shortcuts, I learned in these sessions, like ALT+SHIFT+UP / DOWN to increase/decrease the marked text or with Eclipse Keymap ALT+Y to mark the next occurrence for multi-cursor tasks.
My first peer programming experience was exhausting. After 2 hours I was done for the day. After practicing for a few weeks, we could do around 4 hours split into 2 hour sessions without getting too tired. So it definitely has an effect to practice. Another positive aspect of it is (pretty likely) getting less distracted. You need a strong focus to concentrate on the task and the other person.
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.
Not per se, but it might help you learn to communicate better.