1 of 26

Pair Programming Done Right: �Pairing with Pizzazz

Paul Julius

CTO, Intent Media, Inc.

CITCON Europe 2016�Cluj-Napoca

Paul Julius,

Welcome to my talk on Pair Programming. My name is Paul Julius. I recently founded Willowbark Consulting. We focus on coaching, mentoring and consulting our clients on Agile Engineering Practices. We focus on Test Driven Development, Pair Programming, Continuous Integration and Automated Functional Testing.

I have been working on Agile projects since late 1999, when one of my teams adopted Extreme Programming. During that time, I co-founded the CruiseControl open source continuous integration project. I have been consulting clients and working on Agile delivery teams ever since. As a consultant I have the opportunity to try lots of different approaches with a wide variety of teams and talents. Through those years, I have discovered quite a few patterns for software development.

Today I am talking about how to use Pair Programming to make you a better programmer. Actually, if you follow these approaches, not only will you improve, but your entire development team will improve along with you.

2 of 26

What is it?

Pair Architecting

Pair Documenting?

Pair Analysis?

Pair Project Management?

3 of 26

Why?

Or perhaps, why not?

4 of 26

S…L…O…W…

“I can get more done by myself!”

“I don’t want to have to explain myself at every turn.”

“I am not going to pay two developers to do the work of one.”

5 of 26

Boring

“Watching someone else type is boring!”

“Having to explain my every thought wears me out.”

“I can’t sit back and watch all day.”

“That’ll just give the slackers in my department somewhere to hide.”

6 of 26

Loner

“I don’t work well with others!”

“I just work better by myself.”

“The reason I became a programmer was because I like computers, not people. “

“I can’t sit next to someone every day, all day long.”

7 of 26

Crowded

“My desk isn’t big enough!”

“These cubicles are designed to accommodate one person, that’s the whole point.

“My chair is ergonomically configured for

my body, not someone else’s.”

“We need everyone in their own cube,

so we can call them.”

http://flickr.com/photos/magillicuddy/25074192

“My desk isn’t big enough!”

“These cubicles are designed to accommodate one person, that’s the whole point. If someone else is sitting in here, they can’t even reach my keyboard.”

“We need everyone in their own cube, so we can call them.”

“My chair is ergonomically configured for my body, not someone else’s.”

I love that the ergonomics experts are thwarting my efforts to improve teams!

Seriously though, rearrange your desk. I know the facilities people get angry (I’ve had to talk to quite a few), but move your furniture around. Get those annoying file drawers out from under your desk. Move your computer from the corner to the side of your cube.

Better yet, get your team co-located into a team room. I love helping people figure out how to fit team rooms into their existing infrastructure, but that’s the topic of another talk.

8 of 26

Why else?

or why else not?

9 of 26

Great Reasons!

10 of 26

11 of 26

Bricklayer

12 of 26

Fun

And the biggest one for me, is work enjoyment. When I code by myself…that’s when I get bored. I thrive on that back and forth communication to keep me stimulated. My pair challenges me. My pair gives me the opportunity to incorporate teaching into my daily routine. And frequently while we are waiting for a build, my pair tells be about interesting world facts that I didn’t know so much about.

I had a rousing conversation with my pair, Jake Scruggs from Obtiva, about the coriolis effect. See Jake used to be a Physics teacher. I slipped through somehow without ever taking any physics courses. Jake and I used to have some of the best physics conversations while pairing. It never impacted our efficiency. In fact, it helped us work together better.

In turn, I shared my knowledge of beekeeping with Jake. He used to marvel at the relationship between the magic number Phi and the ratio between male and female bees. That’s a tangent that we can discuss after the talk.

My best days of coding have been with a pair. The most productive. The most exciting. By the end of the day though, I am tired. I’m worn out. I go home…I don’t want to look at code again till tomorrow morning.

13 of 26

http://americanrefugee.wordpress.com/

Reduce Your Bus Factor

14 of 26

Vulcan mind meld

If Sarah gets hit by a bus, then nobody knows the DB layer? That’s ridiculous. As a software professionals we should be helping our organizations mitigate risk, not increase it.

Pair programming with someone is like linking your two brains together for the duration of that session. It takes some practice, but you and your pair start communicating at a level far above the level of communication shared in most board room meetings. Through the keyboard, the unit tests, the code and a couple grunts you and your pair share complicated strategies to solve some of the most difficult business problems.

This Vulcan mind-meld approach to sharing ideas is fantastic. I have yet to come across a faster way to ensure that the developers on your team can work in every area of the code base. Be sure to employ a good pair rotation strategy, more on that later.

15 of 26

Get ready!

16 of 26

Personal Cleanliness!

17 of 26

1 Hour Between Commits?

How about 25 minutes?

http://www.pomodoro-book.com/

18 of 26

TDD!!!

Write no production code before we have a broken test…
Write just enough production code to make the test pass…
Repeat…

19 of 26

20 of 26

Pair Stair

Track who’s paired

Who Hasn’t?

Fill the stairs

21 of 26

Chewbacca

22 of 26

Ping pong

23 of 26

Board

Ball

&

24 of 26

Batting Practice

25 of 26

World Wide