Perhaps the only thing more famous about the tech industry than its enticing perks, is its grueling work culture. From a diversity and inclusion perspective, the industry’s pressure-cooker environment has been criticized for promoting a type of pseudo-feminism that not only forces women to choose between work and family, but also keeps men from feeling like they can play a larger role at home. Fortunately, some tech companies are beginning to rethink this notoriously demanding work culture so that employees can actually take advantage of better-targeted benefits in order to be happier, healthier, and even more productive.
This month we take a broad look at opportunities for improving the liveability of the tech sector (in the U.S. and abroad), and the idea of “human-friendly workplaces”. In this issue, we spoke with Alex Jacobs and Naomi Saphra about overcoming RSI (repetitive strain injury) through voice coding, and Ling Jueding and Woody Zuill about their experiences with building healthy, mindful, and successful work environments.
We hope you enjoy this issue of Inclusion.Tech, and look forward to your ideas and feedback, growing our community, and together making the world a better place.
Outmaneuvering RSI with Voice Coding
In this article, we connected with software engineer Alex Jacobs (Solinea) and Ph.D candidate in natural language processing and machine learning Naomi Saphra (University of Edinburgh), who shared their experiences overcoming RSI with voice coding.
IT: What precipitated the condition that led you to begin voice coding? What was the experience like?
Alex: Towards the end of 2015, I noticed that the “normal” wrist discomfort that I experienced after long days of coding was getting worse, and was starting to affect my hands which was new. It was not bad enough that I stopped working or sought help, but it was starting to take up more space in my thoughts. I was probably trapped somewhere between feeling helpless, and being in denial. What followed was an increase in pain that would appear, if graphed, to be an exponential rise. By mid-March, I informed my employer that I can no longer perform my job and would need to seek medical help. It was extremely anxiety provoking, as the consequences of no longer being able to type would extend beyond my current job, and pose as a challenge to my entire career. Further, if I switched careers, most other positions that I would seek, would likely require that I use a keyboard as part of my responsibilities.
Naomi: In 2013, I started to experience pain in my hands. I stopped knitting and the pain went away a few weeks later. In 2015, I returned to intern at Google for my second year there. As I was typically typing for about 12 hours a day, it did not take long for my hands to start hurting again. I had bad posture and often used a laptop while coding. The pain continued to build throughout the summer.
One day, a friend gave me a coloring book. Within half an hour, I was in so much pain I couldn’t uncurl my fingers. The first couple of months saw the most acute pain. I would visit bars and order a shot of vodka with a straw in it because I couldn’t pick up the glass. Every morning, I would type “Netflix.com” with my knuckles, thus expending all my “hand juice” for the day, and spend the rest of my time in bed. I stopped all of my hobbies.
A friend visited to help me pack to move. After she left, I realized that she had tied the curtains open. I knew I couldn’t untie the knot, and knew that I wouldn’t be able to sleep because of the lamplight outside of my window. I started crying. I just wanted to sleep and not wake up until my hands had healed.
I tried to apply for worker’s compensation. But since I could not type or hold a pen, my application was rejected because I had not completed all of the paperwork in time, despite help from friends.
IT: How did you arrive at voice coding as a solution and has it allowed you to continue your previous career, or enter a new one?
Alex: I was able to channel some of my anxiety into research and seeking community support and advice. I had attended Hack Reactor (10th Hack Reactor cohort), and had access to the alumni network through our shared Slack channel. I figured if there was a single group out there that had a likelihood of other people sharing my plight, an extended network of software engineers would be it. My intuition was correct, and at first it appeared that although there were other people who were experiencing some symptoms of RSI, the way that people were treating it seemed to be no different than what I had already found online. The standard approach is to just take anti-inflammatories, maybe wrist braces, and get on with it as an unfortunate side effect of the software engineering discipline. Unfortunately for me, by this time I had progressed too far down the path of injury to consider just taking anti-inflammatories. I had a sense that by doing so I would only be masking the symptoms, but continuing down the path of injury. By this time, some of the things that I had read were rather frightening, including the possibility of the injury progressing to the point where every day household and grooming activities would become challenging or impossible. Then somebody posted a link to VoiceCode.io. Around this time, I had also been denied treatment by my doctor, who told me that I would have to take up a worker’s comp and claim the injury as being work related. Once I started down the path of paperwork and long waits while trying to work through the system to see a doctor, I realized that I was going to have to be a major agent in my own healing process. I started doing more reading about RSI, and looked more seriously at VoiceCode. My partner at that time happened to be a medical professional who had dealt with worker’s compensation cases. She was really supportive about the idea of voice coding, even though it involved significant cost and a painfully steep learning curve. I realized that I was at the crossroads between two difficult choices: hoping that I would eventually regain the ability to type again and not lose my job in the process, or take the risk with voice coding which would allow me to continue working but would be a painful learning process. I chose the latter, and here I am currently dictating the answers to this interview in the same manner that I perform all of my work these days. I didn’t lose my job, and my manager was extremely understanding and supportive of my learning curve.
Naomi: After 5 months of basically doing nothing except wait for the pain to recede, I was ready to try something else. I had seen some talks about voice coding, so I referred to Twitter on what solutions people had encountered for it. That was how someone recommended VoiceCode to me.
While my workflow has definitely slowed down, my PhD supervisor has been very understanding. It is a slow adjustment, but I believe that I can complete my degree in this way. I still hope that after I finish, I can work as a programmer in my field.
IT: What recommendations do you have for preventing this kind of situation from occurring in the first place? For example, what, if anything should be changed about work culture, working conditions, etc.
Alex: I think we’re talking about a systemic problem here. It’s not so easy to figure out how to change the prevailing culture around ergonomics and physical working conditions. For example, it’s hard to point fingers at this being a management problem, because basically everybody is in the same boat. We are all basically using the same technology: tragically outdated keyboard and mouse input devices. The truth of the matter is that not everybody’s body will respond the same to the physical demands of computer work. Some people can get away with making an adjustment such as using an ergonomic keyboard, and/or modifying their chair or desk height. And for others, the same adjustments will only slow, but perhaps not stop the progression of injury. So, given the variances in how differently people will respond to the same activities, I think it is perhaps most important to provide education and awareness of options. I had never heard of voice coding prior to hitting my limit and realizing that I needed to investigate a new method of interacting with the computer. Had I heard of this earlier, would I have adopted it? Hard to say, but probably not likely because the learning curve was steep, and the financial investment, including hardware is significant. At the moment, my full set up (I don’t use every component all the time) includes a high-quality microphone and external soundcard, a head tracking infrared camera to substitute as a mouse, and foot pedals to take the place of clicking. When using the entire set up, I can effectively write code all day without needing to use my hands. In reality, now that I have experienced some healing and have a little bit of leeway towards touching the keyboard without triggering a debilitating pain cycle, I will occasionally use my hands to enter key combinations that are difficult or frustrating to VoiceCode, as well as manipulate the trackpad. It is a goal of mine to continue to optimize my VoiceCode setup, so I can further reduce the need to use the keyboard. It is very relevant to mention here that I am a remote employee, which gives me the flexibility of customizing my home office to support this set up, and be able to work in an environment where I don’t have to deal with social stigmas around the pacing or style of my work. On the occasional days where I do enter the office to work with my coworkers in person, I deal with a lot of internal stress related to worrying about judgment of my work style, or the fact that I’m always excusing myself to work privately so that I don’t have to bother other people with my utterances while I am working. My coworkers have been only supportive, I guess it is just a normal aspect of our human nature to worry about what others are thinking about us.
Naomi: Everyone should police their friends! Don’t be afraid to ev-hand-gelize (sorry). If you see someone sitting with an obviously non-ergonomic work set up, talk to them. I wish someone had talked to me. No workplace should have a culture of working without breaks, or for 10 or more hours a day. Meetings with ergonomics staff should be mandatory for new hires. If you were joining the NFL, the physical therapists and personal trainers would not be some opt-in perk. RSIs are the sports injury of our profession, so employers need to act preemptively and emphasize that this is really something that happens to everyone eventually. This includes interns, since I assumed I wouldn’t have to worry about the impact my lifestyle had on my health until I was much older. Exercise is important. Cardio exercise helps your circulatory system contend with the inevitable inflammation that results from typing. After my hands stopped working, I couldn’t punch so I had to stop martial arts. I have since picked up roller derby, which is helping me manage pain as well as find focus again.
IT: How did your experience change your perception of disability/awareness of disability?
Alex: I have been extremely humbled by this experience. I continue to confront and work through my fears about losing my current job, and whether or not I will be employable given the fact that I plan on continuing to VoiceCode going forward. This experience has opened my eyes and helped me develop compassion for people who are differently abled who’ve had to confront and overcome these fears on a daily basis. I have also realized through this process that there are many times where I would wonder how somebody might judge me if they were to watch me work. Would I seem inept or slow? My workflow has changed dramatically, but I have also seen ways in which voice coding has made me a better engineer. I used to have a habit of “thinking with my fingers”, which involved a lot of quick input and changes to code, followed by saving and inspecting the results in the browser or test spec. I realized that this is just a lazy habit, that in my case also contributed to the injurious repetitive nature of how I engaged with the keyboard. Now, such input would be quite laborious given the need to speak everything, so I spend a lot more time thinking about my solutions before I execute, which makes my text entry more efficient overall. However, from the outside it might appear that I am “doing less”, even though I know that my overall rate of feature production is equivalent, if not faster. So people who have overcome challenges related to interacting with technology are probably unfairly judged on a regular basis as to their ability to contribute, although their contributions may be just as good, if not better due to the amount of contemplation that has likely gone into figuring out how to work around these challenges.
Naomi: It has became very important to my life that Google’s speech recognition system has a 15% higher word error rate for women. I’m just lucky that I have a fairly standard American accent. I never seriously considered these issues through the lens of disability before. I now realize that the ways in which we accommodate disabilities can end up extending those accommodations only to a select few.
IT: How can global tech and inclusion.tech promote awareness and support for this cause?
Alex: I believe that in this case, awareness is support. Had I previously known that VoiceCode was available, and that there was a thriving community working together to move from the current beta version to the next major release (which is due out very soon). I would encourage anybody who is getting the signs from their body that endless keyboard inputting is taking a significant toll on their health to look into it sooner than later. It is no longer just a theoretical framework. It is a thriving community of developers that help each other out when it comes to using and optimizing VoiceCode. People share command snippets and techniques with each other on a regular basis. I also want to raise the point that VoiceCode is not just a means of reducing or removing the need to use your hands for keyboard input. It can also be seen as a workflow optimization tool with some incredible features for writing your own command sequences to handle a wide variety of use cases.
Naomi: By fostering a culture that is aware of the risk of RSIs and that accepts that it is something likely to happen in almost every programmer’s lifetime, we implicitly create a workplace that is more accommodating for people who can no longer type at all. The accommodations that make it easier to avoid RSI are the same ones that make life easier for people who are disabled, including speech recognition systems and ergonomics experts. By showing that these problems can happen to any programmer, we also encourage empathy for people who suffer from life changing disabilities.
Creating Human-Friendly Workplaces
In this article, we connected with founder Jueding Ling (Zank) and Agile consultant and co-originator of mob programming Woody Zuill, who shared their thoughts on creating emotionally healthier, more productive work environments.
IT: What is your idea of a healthy, “human-friendly” workplace?
Jueding: A workplace where people don’t need to hide anything about themselves. They shouldn’t be afraid that their personal preferences will affect their professional growth. For example whether they’re gay or pregnant (Author’s note: pregnancies are highly regulated in China and are major considerations for companies as they must provide rather generous maternity benefits).
Woody: We need to provide a workplace where people can excel in their work and that allows them to excel in their lives. People should be able to answer these three questions everyday: “Do I feel fulfilled in my work? Am I getting support and the training that I need to complete my work? Does somebody that I respect notice that I’m doing well?” It’s a real boost because if everyday we feel that things are bad and they’re not going to get better, we’re going to spend most of our life energy protecting ourselves in the workplace from all the negativities. If we feel that we’re always getting the chance to do our best, and that whatever our best is, is good enough, then we’re going to feel fulfilled in our lives.
IT: What are some measures and best practices for creating such a work environment?
Jueding: We encourage people of different genders and sexual orientations to work together and to empathetically communicate, which we’ve found to help prevent misunderstandings and reduce anxiety. In turn, this kind of supportive environment allows individuals to flourish and to contribute to their fullest extent, which encourages everyone to appreciate each other’s strengths and better relate to different perspectives. I think it’s important to have diverse groups of people to work together to promote awareness and understanding. And I think businesses can demonstrate their commitment to being inclusive and supportive by acknowledging that women are as capable as men and by being supportive of the gay community. As a result, the general public will naturally become more accepting and supportive of their own companies, and these companies will then attract more people from these demographics. If people feel that the work environment is safe, they will be able to work more comfortably and make more friends and therefore do better work. Also, I think the first thing as an individual is to have the courage to be yourself and be confident in who you are. This is the best approach to raise awareness and nurture understanding from the general public.
Woody: There’s an old joke in the software development world that says that if it’s after five o’clock we’re writing tomorrow’s bugs. Because when we push ourselves to think of the right answers to something, we’re not going to get the right answer. In The Art of Thought, Graham Wallace describes at least four phases of thought, including preparation and incubation. Preparation is when you study something, you think about it, and you talk with other people about it. Incubation is when you don’t think about it, you don’t talk about it, and then you think of other things. During that incubation period, at some point you’ll become illuminated and you’ll realize what you need to do. Then the cycle starts over again. This sequence isn’t strict, per se, it simply refers to an interspersed process. Illumination might come hot and heavy for a while. So if this is true, then what we typically do at work is when we need to get something done we tell everybody they have to work late to get that stuff done. And then that’s sort of counter to this whole idea. I’ve often asked this question when I’m giving a workshop: When do you do your best thinking? And the results are things like “while I’m taking a walk”, “while I’m relaxing”, “while I’m taking a shower”, “as soon as I wake up in the morning” or “in the middle of the night”. So does anybody use those techniques at their workplace? “Go take a shower, Barry.”, “Let’s go take a walk, Susan.” You know we don’t do that, so we expect people to just be able to deliver on command. Sometimes we have to work under pressure. Particularly if it’s something really critical or life saving, such as if miners are trapped in a mine or the famous story of the Apollo 13 rescue mission. But even there, I suspect the kind of answers they came up with, were the best they could do under the circumstances. A better thing would have been to never have the accident at all. There’s a great article on that by Repenning and Sterman called “Nobody Ever Gets Credit for Fixing Problems that Never Happened”. If we spend most of our time making things better, we’re going to have less problems. But nobody gets credit for making things better, they get credit for solving problems.
There’s a saying that goes something like, “Those who are doing the work, can best determine how to do the work.” So if you make an environment where the people doing the work are actually allowed to do that work, and discover how to do that work really well. They’ll find a way to do it. But you have to give them time. So we can’t really say, “Prove to me that’ll work, before we try it”. It doesn’t make any sense to me. When you’re working on a problem that you need to deliver to your company, there’s going to be the pressure of needing to get the work done. And I’ve seen this in many work places where the manager, if the people working for the manager don’t do well, that reflects really poorly on the manager, so the manager insists on things getting done quickly and right. But with things like software development, much of it is an exploration and the pressure of working, makes it harder and harder to actually explore. And so if we try our ideas — most of our ideas are not gonna work — but we have to try them so we can discover the ideas that will work.
I think there are a couple of things that are really important to accomplishing this. And I think the concept of “turning up the good” from Kent Beck’s Extreme Programming Explained, turned out to be really useful. For this you just look for the things that work well and ‘turn them up”, like the knobs on a mixing board. And a weird thing happens when you do that, you’ll notice that lots of problems fade away. And that’s what we were doing when we started mob programming, we were mostly focusing on being able to work well together. We noticed something was good right then and there, we decided to simply continue doing it, rather than go back to our cubicles and just work. We decided to just work together, because it was working so well, and at the end of the day we had decided it had worked so well that we would just keep doing it tomorrow… And that was five years ago this month, and it just got better and better for us.
IT: What can global tech and Inclusion.Tech do to promote “human-friendly workplaces”?
Jueding: Inclusion.tech should cover more companies that have effectively created inclusive workplaces and promoted diversity, and how they’ve done this, so other companies can learn from their example. Right now people are paying more attention to how businesses make money, but they should be paying more attention to the people who actually make these companies successful.
Woody: I think as the future of work, especially in things like software development continues, we’re going to be working on bigger and bigger problems that require more than one person to be working together on something so we’re going to need to be better at teamwork.
So just like with anything you do, if you don’t practice it, you’re probably not going to get better at it. And I’ve actually talked over the years to folks who tried pair programing, and they say “It wasn’t really good for me”, “It doesn’t really work with how I work”, and I say “Well how much did you do?” And they say “Oh we did it for a couple hours and just it wasn’t working so we went back to what we were doing”. So it’s like saying, “Yeah I couldn’t play the piano. I tried it for two hours. I just wasn’t very good at it.” That doesn’t make a lot of sense to me, to try something for two hours and say it doesn’t work. I would say let’s get good at it first, then let’s make a decision.
If we’re really good at pair-programing. Then we’re probably pretty good at sharing our ideas with other people, and getting their ideas and using their ideas. As a matter of fact, that’s a good thing to practice. And I think that’s why the driver-navigator model worked so well for pair programming, the idea that we’re practicing allowing someone else to give us the idea and then to put it into code. Not every idea has to be discussed. We can hear the idea, try it, and discover for ourselves how well it works. So when you’re working with a group of people, you might have two or five different ways you want to approach something. There’s no reason you can’t try them all. Because coding is a design process. The output of software development isn’t code, it’s running software that’s going to work and do whatever it was intended to do. So if we’ve realized that (and there’s a great paper on the topic by Jack Reeves, called “Code as Design”), we can think about code as a kind of sketchbook, for sketching our ideas, and as they finalize, we erase and emphasize and strengthen the parts that are working. We can use code to communicate with each other as we work it out.
I would suggest that you might want to just try learning together on some simple exercises and practice getting along with each other and practice listening to other people’s ideas and translating them into code. Here’s an exercise I like to share. The person with the keyboard, their job is to trust what the other people are saying and convert it into code. If they think they have an idea that they want to put into the computer they should allow someone else to take they keyboard. And they should abandon the keyboard and express their idea. As a matter of fact, if you don’t have a clear idea what needs to go into code right now, we can go to the whiteboard. But as soon as we have an idea, we can go right back to coding. So we would have a rapid feedback loop, where we would have an idea on how we would want to first try to attempt coding, and then give it a try, and see what it does for us. So the idea is that let’s practice, let’s practice as a team. Let’s practice being good with each other.
Note: Interviews edited for length and grammar.