Pages

28 June 2015

Pairs

You might need a fresh cup of coffee for this post. I needed coffee to write it.

I'm reading Kent Beck's book, Extreme Programming Explained, this summer. It's a few years old, but it's been on the recommendation lists of several people I know and respect for quite a few of those years. I keep track of a lot of industry press and research literature, and people argue about software production methods constantly (and have done so since people first started programming computers). Not everyone agrees that extreme programming (XP) is a good thing, but even if not everything that it suggests is implemented out in reality, a large portion of it is really in use. Much of it has to do, unsurprisingly, with people and how they interact. I'm a computer science student fighting with PTSD, so I'll take help where I can find it. 

If there's one word I hear when being given advice about programming, or read about ways to program effectively, it's communication. You have to be able to communicate with the people you build software with, and the people who will use the software you write. Not communicating means that the software doesn't solve the problem for which it was built, and civilization comes crashing down. I've seen this in action, and it's true. Pair programming is one of the things that's presented as a solution to the problem of communicating while building software, and that's been a subject of tons of debate. The overall impression is that it's a good thing, and from my admittedly limited experience programming in pairs, I again agree completely.

Still I'm spending a lot of my time writing code by myself. There is a lot written about ways to build software faster and with fewer bugs, and there is also a lot written about Post Traumatic Stress Disorder (PTSD) and social anxiety. There's very little, at least as far as I've been able to find, written about pair programming when one or both of the programmers in the pair have PTSD to deal with. There's really no manual for being a student with PTSD, and there's similarly no manual for being a programmer with PTSD, so I've been working mostly alone since I started seriously hacking again a number of years ago.

PTSD likes being alone, suffering in silence. 

Part of it is that social interactions can be complicated-- the world is dangerous, and dealing with people can be even more so. Avoiding things is a huge part of how PTSD keeps itself going. PTSD makes it difficult to concentrate, which makes programming harder-- for me it means that I sometimes have to hammer longer on learning a new concept than people who don't have trouble concentrating. I don't have the greatest sense of time ("chronologically challenged" is a term I like), and I have a wacky sleep schedule, and there are all kinds of things I could list that make pair programming a difficult thing when PTSD is involved. 

They all boil down to fear, being afraid that I won't be productive because the PTSD symptoms will get in the way and then people won't want to work with me because they think I'm stupid or slow or an asshole or whatever reason. It's the paradox that you have to be able to communicate, while at the same time your brain wants to be back in the Desert. You can wear headphones and listen to Massive Attack to mitigate your brain wanting to play back flashback movies (headphones in fact help a lot) but you can't pair program with headphones on. The fear I feel is that the mechanisms I've come up with to cope right now (i. e., working alone in a lab in the middle of the night) don't apply to the real world where I write code and people give me money in return (and where people pair up to write programs).

Hold the thought on pair programming for a moment. 

In the early days o' the web (aka the 90's) I was a programmer at a company that built web sites for companies that sold houses. I wrote some good software there, but it was hard to do good work there because we didn't have things like extreme programming. We actually didn't have a lot of things, like source code control or testing or QA or in fact any of the really good tools and methods that I use daily on my own projects now. Programmers were never allowed to talk to customers; we were often discouraged from talking even to each other. Many of the practices that were normal at that company (and others like it) (and who no longer exist) were the reasons that someone sat down and came up with something like extreme programming. I mention this because my experience back in the day gives me a pretty good perspective on now not to do things, while also giving me a pretty good reason to do some of the things that XP suggests. 

There's also a lot about extreme programming that meshes well with the cognitive therapy I've worked on for PTSD, probably enough to write a new book, but here's one example-- testing. The (very simplified) idea of writing tests for software is that you end up with a set of tests that software has to pass before you consider the software "good". If you're using a program on your computer and your computer crashes, it's probably because the "something" happened that the program didn't expect-- since no one tested that "something" happening, the program doesn't know what to do with the problem and so it crashes. 

If the sound of a gun firing takes you back to the Desert, a truck backfiring (or in fact any loud, sudden noise) can take you back to the Desert too. PTSD is your brain being trained to hear the gunshot (or something that sounds like one) and processing it the same as you'd process it in the Desert. If the gunshot is associated with something bad happening, well, that's where the PTSD is from. Whatever you see or feel as a result of hearing a truck backfiring in Indiana is your brain running a program that it wrote when you were in the Desert that does things like make your heart beat faster and your senses to sharpen (it's the fight or flight response).

Cognitive based therapy (CBT) helps you learn that when you hear the truck backfire, you need to stop and think about the noise you just heard-- how likely is it that you just heard gunfire? You learn to evaluate the noise you just heard vs your response to the noise, and see if it matches up. The program runs-- the PTSD, your brain's response to the noise the truck made-- and CBT is the test program that runs that says hey, wait a minute, the output of the program PTSD is running doesn't make sense. What CBT does, eventually, is writes a series of tests that look at the programs PTSD is running and invalidates the programs (reactions) that aren't valid.

A big part of the fear that's generated by the idea of pair programming is that same fight or flight reaction--- it's emotional, not rational, but there it is anyway-- it probably has nothing at all to do with the person you're paired with, or even the problem at hand. It's extra stimulus, having another person at the same desk. The way I think, even when my brain does successfully navigate the PTSD, is probably going to be different than the way someone things that doesn't have PTSD to worry about. It takes time, usually, to even articulate what's going on. And so I've spent several hours writing all of this down, trying to make some sense of it.

The challenge-- my challenge-- this summer, is trying to put what I've learned in therapy at the VA together with the experience I've accumulated, and try to match that up with what industry (where I'll be at some near future point) is doing, plus computer science. 

Which, as it did today, keeps me up all night sometimes. :)











No comments:

Post a Comment

If you'd like your comment to stay private, please let me know in your comment. Anonymous comments are also allowed.