DevNexus: I've Pair Programmed for 27,000 Hours, Ask Me Anything!

I recently attended DevNexus ATL this week, and officially being my first conference, I have to say - it was an experience. One of the conferences I attended was in the format of a Q&A session, where the presenter opened up a few talking points, and then engaged the audience by invoking questions in relation to the topic.

I thought it was interesting to hear the different questions and perspectives people had on peer programming. We had a fair audience of about 40-50 people. So it wasn't stale or in lack of attention.

I'm in the habit of taking notes during our meetings from work, so I just jotted down a few things while in the conference.

Here's I've Programmed 27,000 Hours, Ask Me Anything! by Joe Moore

Q: If you're working with a strong developer, how can you not step on their toes to ensure a full throughput?
  A: Stay neutral; objectively describe the situation
    "The sheet of paper/ticket has the authoritative info - let's go with that"
    as opposed to "You need to do this"

Q: If working with a weak developer, how can you work with them without crushing their feelings?
  A: Ping-Pong development. Have the newbie write a failed test.
    Expert makes the test pass by writing the code for it.
    Expert makes a failed unit test.
    Newbie writes code to make the unit test pass.
   A: Try doing all while expert is "hands-off" in that they are doing just enough to get the newbie up to speed, but not taking control of everything. Experts need to learn how/when to let go, newbies need to learn how to 'grab the bull by the horns'

Q: How can you sell pair programming to accounting so they can justify the cost of 2 salaries on the same issue?
  A: Justify the cost of 1 developer maintaining a feature, and then becoming "That Guy"; then losing that guy to the lottery, or a bus or what have you.
  A: Justify the cost of having that one developer iterating over the project with issues multiple times, as opposed to multiple devs iterating fewer times for a more robust product.
Tis better to measure 10 times and cut once, than it is to measure once and cut 10 times.

Q: If you have odd number of people?
  A: Rotate teams regularly to ensure high development velocity; yes there always will be that 'odd man out'. Though it could work in your favor - each dev will have the opportunity to go into 'The Rabbit Hole' on a regular basis. Developers need this sometimes.

Q: Why not triple programming?
  A: It creates a dynamic different from the pair-programming.
    Odd-man-out, or 2 vs 1

Q: How do you deal with despairing different amounts of experience?
  A: It can slow the pair down, but the alternative is worse: 1 newbie + 1 expert, expert trudging along while newbie is slowing the whole team down, not just the guy in the pairing.
    If pairs work with different skillsets can result in advancing the newbie exponentially.
    Ping-Pong programming:
    Expert demonstrates something
    Newbie implements the lesson

Q: How do you get the new dev involved and engaged to understand the why behind the project instead of "Did I get this line of code right?" ?
  A: It takes time; the new dev will need to understand the business logic behind the requirement.
    Explain the concept of why we're implementing these things and where and here are the articles and links to review.

Q: Diminishing returns: Can you talk on how pair programming can continue to provide returns for teams once they've been trained up?
  Most of what's been talked about today seems to be a nice ramp-up and cross-training stuff.
  A: If 2 devs can go off on a project and come back on the same thing, then yes, it's probably not much of a gain to continue pair programming for simple tasks.
    If 2 devs go off and come back with different results, then there might be some discussion and collaboration.

Overall, I thought this was a really good session. We got some in-depth questions that really provoked some thought around the idea of pair programming.

No comments:

Post a Comment