Dialogical Code and the Adventure of Pair Programming

Near the end of last semester, as the developers of SLAB taught us Praxers to write code (PHP in this case), pushing us to learn different conditional loops and such through repeated problem solving exercises, they also encouraged us to work in pairs or in even larger groups. Coding is not something you do alone, they said. I’d say, rather, that really good, efficient, and fun coding is not something you do alone.

Throughout this spring semester, as Veronica and I have written much of the PHP that drives the Ivanhoe WordPress Theme, we have pair programmed. We have sat together in the grad lounge of the Scholars’ Lab and we’ve scrawled our ideas across three whiteboards (front and back), planning our next steps, prioritizing development GitHub issues, sketching out the logic of the next piece of code we’re going to write. And then we’ve sat together, or sometimes stood or paced, and written the code, one of us typing, the other pouring through documentation, checking syntax, or suggesting a different approach. It’s been a heavily dialogical process. A substantial amount of the back-end code of Ivanhoe is the surface hiding hours and hours of conversations.

It’s been brilliant and fun and one of the best parts of my year.

As we’re getting close to the end of Praxis (and we’re still working, still coding, still trying to get at least the foundation of some of the more advanced features in), I’m thinking a lot about how much of our personalities or styles of thinking have been embedded in the code itself. The code is a literary object, produced iteratively by a group of people. Could you tell which of us is which just looking at it? Could you read the style of the comments, the organization of the conditionals, or the placement of the variable definitions and know something about us? About me?

I suspect you can, but I also think it probably gets harder as the code develops and gets closer to release, as it is iteratively picked over, cleaned up, made to fit standards and requirements. All of which are good - clean, efficient code is beautiful. But so is the archive of our work on GitHub, which is messy and bears the impressions of our thinking (including all the commented-out code I refused to delete until the end, just in case we ever needed it again - silliness, given what GitHub does).

Our commit history there is the record of our conversations, between all of us in the Scholars’ Lab and Praxis who have put time and effort and caring into this work, not just those of us coding.