A personal account from a Pivotal engineer, and some tips on how to approach pairing with a colleague who has an access need.
Recently at Pivotal, we had an internal thread asking for advice on pairing with someone who has access needs. This is something that I spend quite a bit of time thinking about given I have two severe repetitive strain injuries (RSIs) in both of my wrists, and pair program daily. The recovery time for such an injury is typically much longer than is reasonable to take time off for (months to years), and necessitates eliminating any behaviors that contributed to the injury (which in my case was due to a lot of typing and guitar playing).
All of this is to say that I currently only interface with computers by using my voice, and I’m still able to code, browse the web, post on this forum, make music, and do any of the other fun things one does with computers these days. When I saw this thread, I wanted to share the perspective of pairing with someone who has an access need when using a computer.
I feel strongly that pair programming is a fantastic way to be able to work on a software development team in spite of any access needs one may have (be they short-term, long-term, or permanent). It’s very easy as a software developer to overlook the fact that your job is more than just mechanically producing code. However, having a pair who can act as a physical conduit with your pairing station is a wonderful mitigation because you see yourself contributing to changes in the codebase quickly. In many circumstances, pairing has made me feel unaffected by my injury, and this freedom is something I think any software developer with access needs should be able to experience daily.
That being said, I think there’s a need to have software/hardware workarounds to make it easier to communicate code ideas. Verbalizing low-level code details is often unintuitive and unclear, so it’s important to be able to generate code somehow, even if only as an example. This could be as simple as some drag-and-drop templates into your IDE, or something more complex like a dictation set up. The answer to how complex of solution here depends on the individual who has the access need and what’s technically available to use.
Some advice I would offer towards those pairing with someone who has an access need:
Ask your pair what their expectation of your session involves. To what extent are they expecting to drive? How does your pair want to contribute to the code? Do they have any concerns before you start?
Ensure your pair has all of the necessary hardware or software to accommodate them setup on your workstation. Directly ask them this at the start of the day, and ensure that they’re comfortable while you’re pairing. Stop and fix any issues that arise over the course of the day. This will communicate that you are prioritizing your pair’s ability to contribute equally.
When I pair, I make a point to wear a headset that isn’t noise-canceling and has an open ear on one side. I always try to wear the open side so it faces my pair, and will re-orientate myself if necessary to accommodate this. Further, I can use my voice to start and stop the software I use, which communicates to both my pair and the computer that I finished my thought. I try to make sure my pair is as aware of this practice as possible for a smooth experience.
Ask how they want to contribute. If your pair has no way of entering code, and has interest in doing so, work with them on ways that they can easily do so.
Be adaptable and understanding. It’s not uncommon for accessibility technology to require or change settings and software that developers may become accustomed to, or may have strong opinions about using. It’s important to be kind in this situation, and to recognize that many people have abilities others don’t. What workflows are affected by the usage of accessibility technology should be secondary to ensuring that your pair feels accommodated and able. This could be as simple as remapping a key command, using high contrast syntax highlighting, or using a different text editor altogether, and it goes a very very long way.
It’s worth noting that Atom, Sublime Text, Visual Studio Code, and other non-native editors are notoriously bad with accessibility technologies. I can attest firsthand to how a native editor like Xcode outperforms all of them out of the box. Keep this in mind when pairing, and see if your pair has a preference for any tooling because it’s easier for them to use.
Be patient. When I first began dictating code at work, I was painfully aware of every moment that I was dictating, and it affected my ability to express my ideas. I started timing those moments to see if it was really any longer, and I realized they weren’t. Dictating code was about as long as the average time you waited for your pair to express an idea. This led me to recognize that I had the perception my pair wasn’t being patient with me, which was due to them being silent while I dictated.
However, when I raised my concerns to them, them being impatient was not the case. In fact, they were pretty interested in how the system worked, and asked me to dictate more because of how new it was to them. Had we been more transparent about our experience, maybe that situation could have been avoided altogether. Being patient and offering positive reinforcement will go a long way.
Take breaks. Ask your pair if they have any particular schedule of breaks they need in order to be accommodated. You may need to take more breaks than usual.
Some of this advice might seem self-evident, but is worth repeating because it can be easily overlooked given the complexity of pairing. Should anyone have more questions, or would want to go into further detail, I’m happy to jump on a Google hangout and talk accessibility technology and pair programming. Additionally, I can make a lot of recommendations around software someone could use to write code/use computers with their voice if anyone has a need.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
Hands-free Pairing was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
