Pair Programming in the Clink

[article]

Back to pairing in the afternoon.  Dave sought me out because I had mentioned in the group that I could help people with user stories (something I actually do know).  Dave said he had a hard time with stories, so we worked that into our pairing exercise.  Dave is a smart guy, a natural programmer, and even a fast typist. We got pretty far with our Dots game. But just before it was time to break again, Dave got a tap on the shoulder and a whisper in the ear. Apparently, Dave had a visitor, and so he made his apologies to me and left in a rush.

Before the day ended, we had two more pairing sessions and retrospectives. People talked about increasingly complex ways to solve the programming problem, most of which were lost on me. Around 4:00 p.m., an announcement came over the loudspeaker saying they were starting “the count.” Every morning and afternoon, the COs walk through the building and make sure all the prisoners are still there. It was a big deal for us because it affected our departure time. We could not be caught in the hallways during “Count” because we might mess something up. The COs did not come into the computer lab to count our guys; I guess they were somehow exempt since they were doing this activity with us.  Count is a big deal.  If I had to go to the bathroom or something during Count, I would have held it.  I was not going to be the one who screwed up Count.

Apparently, Count can take anywhere from fifteen minutes to several hours, depending, I guess, on how much trouble the COs have trying to find people. Although our pairing exercises lasted until about 4:30 p.m., we might have been there past 6:00 p.m. if Count had lasted longer.  But, Count finished quickly and it was time for goodbyes.

I really had a nice time that Saturday. I appreciated the prisoners’ interest in learning and their willingness to pair with me even though I lacked a lot of the knowledge they were searching for. It was always more of a sense of learning together.  Before we left, one of the prisoners asked me, “Would you do it again?”  I didn’t hesitate in answering, “Yes.”

I guess the biggest thing I needed to learn was how to get rid of my vision of what it’s like to be in prison.  Sure, the COs keep a tight lid on knowing where prisoners are. Sure, it’s a tough life.  And you have to be OK with people telling you what to do. But there are bright spots. The Green Initiative is really amazing.  I’ll bet MCI is doing more to reduce, reuse, and recycle than most schools are. And this software group, too. Imagine going into prison without relevant skills and coming out being able to code test-driven Java. That’s pretty cool.  I’m so impressed with Dan and the other volunteers who spend a big chunk of their spare time helping people in prison. It’s a worthwhile endeavor, and I was glad to be a part of it.

If you are interested in participating in this one-of-a-kind program, contact Dan Wiebe at dwiebe@pillartechnology.com. He will let you know when we are doing this again and will give you all the prep you need to take the leap.

The following photos are from the latest trip.

 

 

 

User Comments

1 comment
John Daughety's picture
John Daughety

Actually, I like this slight divergence from the normal boudaries for the weekly column. I recently watched a documentary on solitary confinement and am glad to hear your experience of a different kind of prison - human interaction is really important and giving them the opportunity to work with folks on the outside is a nice benefit. I would also argue that coding is a very appropriate skill to be teaching prisoners, as I consider it one of the core "trades" of the new millenium. It certainly opens up a released prisoner's options from the usual manual labor, which pays less and less if you can find that kind of work. Also, Dan was very smart to include you because coming up with user stories is not something that comes naturally to a developer but really sets him/her apart from the other developers if he/she can do it well. One thing I have learned in my career, drifting from waterfall-dominated environments to way-out-on-the-edge agile shops, is that daring to understand the parts of agile development that are not strictly defined as development work builds better relationships in agile teams and results in better developers. This is not just true of developers, either; testers who sequeser themselves in only test-related work are limiting their career options as well. There has never been a better time to reach out, even if it feels a bit clumsy at first.

August 25, 2011 - 6:46pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.