I’m a lone programmer. I don’t mean I’m lonely or bereft of friends and family but rather I’m currently independent and so I write code for fun and [hopefully] profit and mostly, well, by myself. It’s liberating and scary at the same time, having no one to tell me what I need to do and no one to hassle me about deadline – um, nobody but the rent actually but I digress.
Being a one-man development team also means I need to design, create, prototype, test and use all of my code. It also means that I have to pay extra special care to be able to be fast, efficient and user-friendly; words etched through [Meyers;01], develop interfaces which are easy to use since eventually you’ll be your own client. Being that and an avid reader of everything under the sun and sometimes the moon, I’ve tripped across the concept of Agile Development awhile ago and tripped hard; it stuck.
Agile methodologies are quite broad and deep and far too hard to put into a single post [hey, there are BOOKS, like lots and lots of books devoted to them and written by far more experienced programmers than I]. I’ve so far read through [HuntThomas;02] and [Astels;03] and am fully planning on picking up [Beck;04] and [Martin;05] in the very very near future. But enough about my lack of sleep and back to topic, namely pair programming and how do I attempt at pairing with myself without an extra personality or two around in my head?
Pair-Programming I think is one of the strongest approaches taken by Agile development and brought to the software development environment. I don’t mean by that the idea that another programmer stares behind you and points to every syntax/spelling/grammer/Odin-knowns-what mistake I might make, seriously, the compiler would pick up on that eventually and test-driving would on all the rest. Nope, I’m talkimg about the concept of having another person there, at realtime, which isn’t going to be annoyed at me for asking questions and bouncing ideas from. It’s a boost to morale and an opportunity to “homebrew” the code into something which transcends both programmers’ total skills, considering of course that the two programmer have learnt how to cultivate proper communication etiquette and reflection practices [perhaps Agile leads should also invest in some Applied Social Science courses, I’m only saying it because my wife has studied it for the last couple of years and some of it bled towards me and was quite eye-opening].
But pair programming, alone? impossible! or is it?
There are far too many punctuations in the above sentence but that’s hardly relevent.
Pair programming is about reflective practice in my eyes and reflective practice can be done by oneself. For example I never write code without a notebook next to me for quickly jotting down ideas, there’s always a document opened [usually a .txt opened inside the IDE] where I simply write everything that I think about, not just concerning code-design, write about everything and anything which occupies my cognitive frame-of-reference. I read aloud my thoughts, I talk to myself and I talk to any of my daughter’s stuffed animals which are always lying around to listen [they rarely answer back but I always do]. Every unit of functionality I code I reflect on and every once in a while I get out of my chair, walk around the room, blink a few times and read everything over pretending I’m someone else. It may sound funny and it isn’t as ideal as having another programmer but it works, for me anyway; I wonder what other people do…
Well, that’s it for now, time to go back to some OpenGL code.
“to love oneself is the beginning of a lifelong romance”
 Scott Meyers, Effective C++ : 55 Specific Ways to Improve your Programs and Designs
 Andrew Hunt & David Thomas, The Pragmatic Programmer
 David Astels, Test-Driven Development: A Practical Guide
 Kent Beck, Test-Driven Development: By Example
 Robert C. Martin, Agile Software Development: Principles, Patterns and Practices