Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Pair Programming

Pair programming talk given at Boise Code Camp 2010.

John Sonmez

on 29 March 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Pair Programming

Pair PRogramming What is it? Two people at one keyboard
Actively working together to solve the same problem
Switching the keyboard and mouse back and forth
Hmm, what if we try this *switch*
Ok, thats good, but don't forget to extract that into a method like this *switch*
Ah, that made me think of a test that will fail *switch* What it isn't Sit at my computer and watch as I code.
You take a turn working on this problem, then I'll do the next one.
I'll teach you how to code.
Don't forget to wear the same color shirts as your computer
so that everything matches So really... How do we do this? Step 1: Define your task Having a clearly defined task helps. Should be able to be accomplished in 1 hour or 2. Step 2: Pick a small goal Write a failing unit test Refactor a method Create a database table Something small Step 3: Do it, one person drives... The other actively participates No one is passive Lots of talking, suggest names for variables, members, classes Stay on task, but write down things you think of Observer talks higher level, typer solves problem in code Step 4: SWITCH Whenever it seems natural At least every 30 minutes or so Sometimes it is easier to speak in code Why is it so hard? Seems Easy Enough, but Why Do So Many Teams Struggle? Common Problems Not Doing Test Driven DEvelopment It is much harder to pair program when the goals are NOT small and clear TDD has a natural flow of repeated actions that work well with switching roles Not Switching Roles Becomes a watch me code Session One person gets bored Not invested into the work Giving up Too Soon Takes time to see the benefits Takes practice to get the ryhthm Bad Pair Up Not all pair ups are good. Like texting and driving. BENEFITS Increased Productivity Training and Mentoring Collective Ownership and Teamwork Reduced Bugs Increased Understanding Two people are more effective at solving a problem than one
Less likely to get stuck
Less likely to get distracted
Synergy! Best way to learn is by doing
Pair up a weak developer with a strong one and watch him/her grow
Pair up two strong developers and they will learn from each other
Pair up two weak developers and... Not Joe's code, our code
Each member feels like they can work in any part of the code
If Joe gets hit by a bus, someone else can still understand your dependency injection framework
The bug blame game, or crappy code blame game is not as fun Just in time code review
Two sets of eyes will catch more bugs
Less likely two people will go in the wrong direction
Pair up QA person and developer = GOOD! Team becomes cross trained
No more "roles" in the code
Expands even to testing, database and other tasks
Seeing the bigger picture by working on more pieces of the system TIPS There is no magic formula
Keep trying
Remember to switch keyboards
Try forcing the pair up
Pairing hours, pairing workstations
Give some personal time, or developers will revolt!
Full transcript