I learnt about pair programming at university when we were studying Agile methodologies. At the time it seemed very full-on — almost scary. I pictu...
For further actions, you may consider blocking this person and/or reporting abuse
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 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.
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'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!
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.
Absolutely agree. Just read a great article earlier today about this topic
bloomberg.com/opinion/articles/202...
Thanks for sharing! Some interesting facts there 👍🏻
Ok, great article, but: would you be available to do pair programming with me? :D