Pair Programming: Better Than Adderall
For programmers with ADD, metacognition helps us tap into our most productive selves, because through metacognitive reflection, or being aware of our own thought processes, we can identify gaps in our executive functioning. I think of executive function, which takes place in the frontal lobe of the brain, much like a personal CEO: analyzing and planning out tasks to be done, making decisions and carrying them out. Modern academic research in the fields of neurology and psychology points to executive functioning as a major struggle for those with ADD and other similar learning disabilities. My ADD mind is fully capable of performing each of these executive tasks, like making decisions or implementing them. However, the difficulties occur when I need to perform these steps together in order. That’s when metacognition can really help me, as research shows it being an effective behavioral therapy for us differently-abled individuals.
The extreme programming movement [1][2] was created in part to enable instant code review through the practice of pair programming, which we do all day, every day at Pivotal Labs. While pairing, I get much more than just constant review of my code output; pair programming enables me to engage in a form of metacognition. As a part of the pairing process, I am regularly communicating my decisions to my partner (my pair) so that they can understand what I am thinking, and I expect them to do the same for me. By vocalizing my thought process to my pair I engage much more of my brain than if I were simply to make a decision and move on to the next problem. I actively have to think about the decision that I just made, and then engage the part of my brain that synthesizes thoughts into speech. Once I reveal my thoughts, my eyes and ears are picking up on my pair’s physical reactions to my words, looking for clues to their satisfaction with my decision. And all of this may lead to a discussion, as they are another intelligent, fully functioning engineer with great thoughts on how to proceed, so I will likely have to engage yet more gray matter as we come to a team decision.
Before I joined Pivotal Labs, I used to do traditional code reviews. Sometimes, but not always, I would be asked to explain why I made certain decisions, long after the moment of creating the code. When compared to the metacognitive steps in pair programming, the code review process lacks a natural structure for the solo programmer to reflect on code decisions and their consequences in the moment. Having an external party evaluate your output after the fact is no substitute for making better decisions at every step of the way. Additionally, it is always easier to make changes and refactor to write cleaner code as you are working on a story. Waiting for a code review, which may occur any number of days after the story has been completed, to surface any code quality issues presents the programmer with the burdensome task of having to remember what they wrote and why they wrote it that way. Do you remember not just what you had for lunch two days ago, but why you chose that menu item over another? That is what the solo programmer can expect to face in the code review process.
By “thinking about my thinking,” I effectively shift my brain into overdrive, activating it fully, and telling the little CEO-in-my-head to get a move on! When I programmed alone, I would have to add extra, inorganic steps to my coding process in order to metacognate, or worse, risk letting my sleepy CEO steer the helm of my ship by itself. And with pair programming, there is even the added benefit that my pair might notice a step that my metacognition-enhanced CEO missed, thereby effectively plugging up any holes this metacognitive process didn’t cover.
