Completely agree Wez! Thankfully most of my previous jobs have been pretty loose with pairing - we understood it took energy, but that there was also a huge amount of knowledge sharing that could take place when we chose pairing opportunities judiciously. I’m currently working at a job where I’m working solo all day and really loving the flow states, but I still do miss the amount I can learn when pairing with a fellow dev.
I can really relate to the author’s viewpoint on pairing! I find it exhausting to do for more than a couple hours. For me, writing code together is a lot like writing a letter (or email) together. It works well with the right dynamic between collaborators, but it can also be extremely frustrating and consume a lot of energy.
Most of the work involved in progamming I do is not typing out code but deciding on the algorithms/data structures/objects/architecture to use in a system. I like to plan these things out with a coworker to get a second opinion and bounce ideas around. Then, armed with the result of the design session, I like to go back to my computer and bang out the first iteration based on our discussion. It’s a lot easier to then discuss something concrete as long as the changes to the codebase are of a reasonable size.
Interesting division you have as mine is similar but maybe opposite order. I preferred collaboration on requirements, risk areas of dependencies we’d have to use, and environmental factors. Then, I’d go work alone on algorithms and prototype implementations exploring them. Bring back a summary of those for peer review. Others might have their own designs. Advantage is I get to throw my brain at high quality results with some good data to start with. Disadvantage is more work wasted on dead ends if review process catches a preventable problem. That disadvantage can also be controlled a bit in terms of how much time between preliminary handoff and review.
Anyway, that’s how I did it since I was strong in algorithms and correct coding but needed help on ambiguous or complex stuff outside it.
I get tired and drained: As a bit of an introvert, I find extended periods of pairing extremely draining. I don’t think introversion is really factored in when the XP crew advocate for full-time pair programming.
This is my experience as well. To exacerbate the point, I’ve found that some people believe that being introverted is a problem, and a behavior that needs to be “corrected”. I don’t know how recent the idea of introversion vs extroversion being expressed in terms of when your energy is being drained came about, but it seems more known today. (And to reiterate, this doesn’t mean introverts are naturally anti-collaboration. This just means other forms of collaboration need to be considered to be mutually beneficial for various personality types.)
I’m happy that my article spoke to you! I obviously share your viewpoint quite a bit and the fact that you feel the same way gives me a since of solidarity that I am thankful for. :)
Completely agree Wez! Thankfully most of my previous jobs have been pretty loose with pairing - we understood it took energy, but that there was also a huge amount of knowledge sharing that could take place when we chose pairing opportunities judiciously. I’m currently working at a job where I’m working solo all day and really loving the flow states, but I still do miss the amount I can learn when pairing with a fellow dev.
I can really relate to the author’s viewpoint on pairing! I find it exhausting to do for more than a couple hours. For me, writing code together is a lot like writing a letter (or email) together. It works well with the right dynamic between collaborators, but it can also be extremely frustrating and consume a lot of energy.
Most of the work involved in progamming I do is not typing out code but deciding on the algorithms/data structures/objects/architecture to use in a system. I like to plan these things out with a coworker to get a second opinion and bounce ideas around. Then, armed with the result of the design session, I like to go back to my computer and bang out the first iteration based on our discussion. It’s a lot easier to then discuss something concrete as long as the changes to the codebase are of a reasonable size.
Interesting division you have as mine is similar but maybe opposite order. I preferred collaboration on requirements, risk areas of dependencies we’d have to use, and environmental factors. Then, I’d go work alone on algorithms and prototype implementations exploring them. Bring back a summary of those for peer review. Others might have their own designs. Advantage is I get to throw my brain at high quality results with some good data to start with. Disadvantage is more work wasted on dead ends if review process catches a preventable problem. That disadvantage can also be controlled a bit in terms of how much time between preliminary handoff and review.
Anyway, that’s how I did it since I was strong in algorithms and correct coding but needed help on ambiguous or complex stuff outside it.
This is my experience as well. To exacerbate the point, I’ve found that some people believe that being introverted is a problem, and a behavior that needs to be “corrected”. I don’t know how recent the idea of introversion vs extroversion being expressed in terms of when your energy is being drained came about, but it seems more known today. (And to reiterate, this doesn’t mean introverts are naturally anti-collaboration. This just means other forms of collaboration need to be considered to be mutually beneficial for various personality types.)
I’m happy that my article spoke to you! I obviously share your viewpoint quite a bit and the fact that you feel the same way gives me a since of solidarity that I am thankful for. :)