Episode: 1215
Title: HPR1215: Pair Programming
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1215/hpr1215.mp3
Transcribed: 2025-10-17 21:46:02

---

Greetings. My name is Christopher Hobbs. I go by no method about the internet. I've
recently started listening to HPR and I decided I'd like to try to contribute. This
is my first podcast and while it's brief, I hope to contribute more as I learn more
about podcasting. I have a few subjects I'd like to talk about. I decided to dial in because
I don't have proper audio gear and there's something quaint about using the phone to record
a piece like this for a public service. The call and number appeared to be out of service
so I'm recording this with a pretty interesting setup, but I suppose that's discussion for
another installment. Please send any feedback on my audio or my format and all the just
where I can. I'll provide my contact info at the end of this podcast. I've been interviewed
on pair programming recently and gave a talk on it at work so I figured it'd be a good topic
for a quick podcast. I've been pairing for both work and recreation for a couple of years
now. I've been developing for probably the better part of a decade. A former IT drone
recently switched careers to development. This topic may not be an exact fit for HPR, but
I hope you find it enjoyable. I know some of you are already doing some programming. So
what is pair programming? Well, it's an agile software development technique where two
developers work together at one workstation. I believe it either came from the extreme
programming camp or XP popularized it. You can find more about that in some of the links
in the show note. So how do you pair? The basic process is that one developer drives
while the other one observes. So one person is typing, the other person is watching and
guiding. There's many ways to handle this. You can have one developer write tests while
the other codes. You can take turns coding using the Pomodoro technique or you could code
in intervals, but the bottom line is that it provides an inline code review. You want
to switch roles regularly depending on the pair that may be any amount of time. I find
myself switching up about every 20 minutes to hour or just whenever one of the pairs happens
to be tired. Some of the benefits that it provides, first we mentioned inline code review.
One developer is constantly looking at the code. Side effect of this is you have to make
yourself both confident and vulnerable as you're answering to another person for every
line of code you write. Those of you building open source projects shouldn't have much
trouble with this, but sometimes developers on proprietary projects get shy. This is
pretty easy to overcome in a few hours or if you really just know the person you're working
with, you'll get passed it quickly. Per programming can help relieve burnout. It generally lets
people rest their brain for a little bit while the other person drives. I found that
it's easier to wear down after coding for eight hours in a given day by myself, but
with a pair, I'm not usually as tired at the end of the day and I feel better about my
work having someone else watch it. While pairing, you should be learning new tricks
for your pair and teaching them new tricks as well. Learning should be constant, you should
be in constant communication, and this also helps to defeat knowledge silos and raise
bus numbers. If you pair it from musculously through an organization, both domain and
general knowledge get passed around to everyone and no single person will have a locker or
a choke hold on any given project. There are a few things to overcome, however, in pairing
isn't always easy. You have to drop your ego a little bit and listen to the other person.
You eventually learn when to talk and when to listen and once in a while you have to
agree to disagree. To avoid getting stuck in an argument, try to understand the other
person's point. The best way I've found to handle this situation or a situation similar
to this is to generally accept what other person wants to write if you can't verbalize
a solid argument against it. Then after you guys have moved on and done other work and
you've had some time to research the topic, come back and revisit it and explain your
position better. So lastly, I'd like to talk just briefly about remote pairing. You
don't have to be in the same room to pair with somebody or even on the same continent. If
you've got an internet connection and a box with SSH available, you can pair remotely almost
any time. Granted, you'll need very likely a Unix based operating system such as Linux,
the BSD's or OS10. All you need to do is fire up a terminal multiplexer like GNU screen
or Teamux and your favorite console editor like VEM or EMAX or SAM or ED or whatever you
happen to use in the console and just hit the ground running. You can handle communication
with your favorite VoIP service, be that SIP or Skype or Google Talk or any of the other options
for VoIP. There are some graphical options to remotely work on the same file with another
person like I'm going to butcher this name. I believe it's Subetha edit and Gaby are both good
options. The issue there is they only cover the editor. You're still going to need to share a
terminal somehow, be that another SSH session. You'll need that terminal to be able to compile or
interpret your code. There's always a shell session necessary for that. Screen sharing applications
should really be reserved for high bandwidth connections such as in the same building or just a
really good internet connection and even then they can get sketchy. I found text to be the best
way to handle remote sessions. So I think that about wraps it up. I know this is pretty brief but
it's all I had for a first topic and I hope to provide some more information. I'm open to
remote pairing almost any night if anyone has an open source project to work on or wants to
practice different languages. You can find me on the web at altbit.org, a-l-t-b-i-t.org,
or you can email me at cmhobsatacm.org. That's cmhobbsatacm.org. Both of those should lead you to
other social services like my GitHub repository, Identica, Twitter, things of that nature.
Thank you for your time. I appreciate everybody listening to this and giving me the opportunity
to provide you with some information and I hope this is the first of many.
You have been listening to Hacker Public Radio or Tacker Public Radio does our.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HPR listener like yourself.
If you ever consider recording a podcast, then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the Digital Dog Pound and the Infonomicom Computer Club.
HPR is funded by the binary revolution at binref.com. All binref projects are crowd- Exponsored by
LUNAR pages. From shared hosting to custom private clouds, go to LUNAR pages.com for all your hosting
needs. Unless otherwise stasis, today's show is released under a creative commons,
attribution, share a life, lead us our license.