Been using/encouraging it for the past 3-4 months to teach my team new stuff.
We even resort to mobbing occasionally, when I introduce new concepts fx. We will sit together and implement a feature so everyone has an idea of how it works.
I have 3 juniors on my team, and so far the feedback has been great, and productivety has been boosted greatly. :)
"I've read about peoples' experiences at companies where every line of code is pair programmed [...] My favourite setup that I've experienced so far is a team where pair programming was left up to the developers"
Absolutely. I recently worked in a company where pair programming was enforced all the time by managers who didn't understand the benefits of pair programming.
It practically has made me hate it, when in fact I used to love it.
PS: Good to see Jordan being mentioned here in the dev community :)
The big thing is not everything needs to be paired. I appreciate you calling that out. I pair all day everyday where I work. If we are doing boilerplate stuff the navigator may take a moment to check on our outstanding pull requests, or do something else to make us more efficient.
Pairing is just another tool in your toolbox, and is far from a golden hammer.
I find pair programming SO useful when there's a difficult debugging task at hand, for all the reasons you mention. It can be very useful to have a second brain on standby to challenge assumptions!
I also agree it's excellent for learning and mentoring - I've picked up so much from pair programming and seeing someone else's approach to a problem, not just the resulting code. Plus, challenging myself to explain what I'm doing and why has helped solidify a lot of my own learning and soft skills :)
We use a similar approach in our company with a timer of 15 minutes to switch between Driver and Navigator. We also follow the process where one person is writing the test and other fixing it as we follow strict TDD process.
I have written a similar article describing how it benefit us
The same soft-skills that are used when reviewing code apply. E.g. asking questions instead of telling or directing, being patient and polite, and giving the other person time to respond. As well as an attitude that even a fresh junior can teach the most senior person new skills. These apply for both the driver and the navigator.
I would be interested to hear other peoples' input on this question. For me, different pairs behave in different ways depending on seniority and whether you two are friends or not.
Marco would not be Marco if he had not been called Marco.
Marco makes things. Marco has doubts. When Marco has not doubts, he stays at the sun, looking at the clouds or the sea.
Been using/encouraging it for the past 3-4 months to teach my team new stuff.
We even resort to mobbing occasionally, when I introduce new concepts fx. We will sit together and implement a feature so everyone has an idea of how it works.
I have 3 juniors on my team, and so far the feedback has been great, and productivety has been boosted greatly. :)
That's awesome! Mobbing when there are new concepts is a great idea.
"I've read about peoples' experiences at companies where every line of code is pair programmed [...] My favourite setup that I've experienced so far is a team where pair programming was left up to the developers"
Absolutely. I recently worked in a company where pair programming was enforced all the time by managers who didn't understand the benefits of pair programming.
It practically has made me hate it, when in fact I used to love it.
PS: Good to see Jordan being mentioned here in the dev community :)
Thanks for sharing Carlos, that’s very interesting.
Jordan’s breakdown of the pair programming roles is really great!
The big thing is not everything needs to be paired. I appreciate you calling that out. I pair all day everyday where I work. If we are doing boilerplate stuff the navigator may take a moment to check on our outstanding pull requests, or do something else to make us more efficient.
Pairing is just another tool in your toolbox, and is far from a golden hammer.
I find pair programming SO useful when there's a difficult debugging task at hand, for all the reasons you mention. It can be very useful to have a second brain on standby to challenge assumptions!
I also agree it's excellent for learning and mentoring - I've picked up so much from pair programming and seeing someone else's approach to a problem, not just the resulting code. Plus, challenging myself to explain what I'm doing and why has helped solidify a lot of my own learning and soft skills :)
Yes, I always learn new stuff!
It's a lot better to watch someone write it and ask the questions there and then instead of watching it go through code review.
We use a similar approach in our company with a timer of 15 minutes to switch between Driver and Navigator. We also follow the process where one person is writing the test and other fixing it as we follow strict TDD process.
I have written a similar article describing how it benefit us
linkedin.com/pulse/happy-developer...
Thanks for sharing that resource. The timer approach sounds really interesting.
Hey Andrew!
I'd like to know which "soft-skills" would you address to the navigator and which to the driver?
Are there any?
Hi!
The same soft-skills that are used when reviewing code apply. E.g. asking questions instead of telling or directing, being patient and polite, and giving the other person time to respond. As well as an attitude that even a fresh junior can teach the most senior person new skills. These apply for both the driver and the navigator.
I would be interested to hear other peoples' input on this question. For me, different pairs behave in different ways depending on seniority and whether you two are friends or not.
Ok, great article, but: would you be available to do pair programming with me? :D
Absolutely agree. Just read a great article earlier today about this topic
bloomberg.com/opinion/articles/202...
Thanks for sharing! Some interesting facts there 👍🏻