RSI stands for Repetitive Strain Injury.
Repetitive strain injury is an umbrella term for several cumulative trauma disorders caused by overuse of the hand and arm. The tendons, tendon sheaths, muscles, ligaments, joints, and nerves of the hand, arm, neck, and shoulder can all be damaged by repetitive movements.
- Dr Emil Pascarelli and Deborah Quilter [0]
Some of the long-term causes of my RSI:
- Bad posture
- Long periods of programming/typing without breaks
- Use of a laptop as my main computer (neck is angled downwards, body tends to hunch forward)
- Bad equipment (low-quality keyboard and chair).
The immediate cause of my RSI:
- A sustained period of intense work and high stress.
During an approximately six-week period (November 2015 - January 2016), I managed two large transcription projects simultaneously, each for a different client.
Project 1 ran from 22 Nov to 10 Dec 2015 (19 days inclusive) and contained 37976 utterances. Project 2 ran from 25 Nov 2015 - 4 Jan 2016 (41 days inclusive) and contained 119779 utterances.
Total = 37976 + 119779 = 157755 utterances
The company I work for provides several services for companies that operate automated and semi-automated call centres. One of these services is transcription of utterances.
In this context, an utterance is a short (1-6 seconds, sometimes up to 15 seconds) segment of audio. It is selected from a recorded phone call and usually contains a caller's response to an automatic prompt. Call centre companies want these audio segments to be transcribed so that the transcriptions can be used to test and improve the system's accuracy. The system's initial transcriptions are usually preserved so that transcribers can correct them instead of having to type the utterance from scratch.
Example automatic prompt: "Please say one of the following options: New Insurance Claim, Check Claim Status, Billing, or say 'help me with something else'"
Example caller response: "new claim"
~160k utterances in six weeks was an unusually high transcription rate for my company.
During these six weeks, I did these things (as well as various other smaller tasks):
- Wrote scripts to extract the system's initial transcriptions from the data sent to us by our clients.
- Typed lots of terminal commands when managing our transcription web application (written and maintained by my brother Nicholas, who was working alongside me). [1]
- Lots of transcription.
- Hired 19 new transcribers in addition to our 6 existing transcribers. This required lots of emails and messages. New transcribers need guidance and have lots of questions. [2]
- Wrote and re-wrote our transcription FAQ several times.
- Distributed invoice templates and collected weekly invoices from each transcriber. It was necessary to analyse the data and calculate how many transcriptions each person had done each week, and to let each transcriber know how much to charge us. [3]
- Wrote and re-wrote scripts to perform proofreading that allowed me to catch and correct various types of common errors.
- Wrote scripts to make a random selection of each transcriber's recent work, then check these transcriptions against my corrections of these selected transcriptions and calculate an accuracy score for each individual transcriber. [4]
Overall summary:
- Worked nearly constantly
- Did not sleep enough
- Did not maintain a regular sleep pattern
- Was highly stressed
- Typed constantly
- Did not exercise enough
Around the middle of December 2015, I began to feel some aching and slight numbness in my wrists (I didn't feel any sharp pain). It was similar to the aching in muscles that one feels at the end of a sports training session or a workout in the gym. I assumed the aching would stop after some rest and recuperation when the project was finished.
During the last few days (January 1-4) of the project, the aching/numbness became stronger and began to persist even after I had stopped typing.
I rested for several weeks before beginning to work again.
Over the next five months, the aching/numbness in my wrists became pain/numbness/burning/cold, and spread out into my hands and forearms. I typed less and less, but over time the symptoms increased in severity and regularity. I knew there was a problem but kept telling myself that with some more rest, it would resolve itself and I would return to normal. This is called denial. [5] Not only did I enjoy programming more than any other work I had ever done, I had also made it my chosen field, and my hopes and plans for the future were entirely based on my ability to type and to write useful code. When you're facing the possibility of the end of everything you've ever worked for, denial is... attractive. Denial was also easier to maintain due to the intermittent and somewhat random occurrence of the pain/numbness (which, if it occurred, often began after a delay e.g. two hours after beginning to type). As the symptoms became more regular and more tightly correlated with typing (less delay), denial became correspondingly harder to maintain.
Eventually, by June 2016, 10 minutes of typing could cause several hours of severe pain. An hour of typing would produce two days of severe pain.
In early June 2016, I saw a doctor and was diagnosed with carpal tunnel syndrome. I then experienced the next four stages of grief in rapid succession (anger, bargaining, depression, and acceptance).
A few days later, I bought a dictation program.
I installed the dictation program (Dragon Dictate 2.5 for Mac) on my work machine (a 2008 Apple MacBook running Mac OS X 10.6.8 Snow Leopard). I began testing it but in its initial state it was unusable for programming entirely by voice (the text output usually required substantial editing, and the text editing voice commands were insufficiently precise). The target demographic for the system was probably not programmers with RSI. I think it was aimed at:
- people with RSI who would like to write emails/documents (i.e. English, not code)
- people who have to make lots of notes quickly and are willing and able to hand-edit the results of dictation.
Several people volunteered to take turns to do my typing. This allowed me to produce just enough code to navigate certain data processing chokepoints in several projects. Their assistance was very valuable and much appreciated. However, they had either not programmed at all or only a little, so to them the code was mostly a foreign language. We had to proceed character by character, or nearly so. This is extremely slow and frustrating for both parties. It is also not conducive to the long uninterrupted thought process and the "harmony of control" that are necessary for producing good code.
At one point, I became frustrated with the slow speed of dictating code to another person and wrote a script myself. I then experienced extraordinarily severe pain, which lasted until I saw another doctor the next day, who diagnosed me with peripheral neuropathy and prescribed amitriptyline.
Amitriptyline quickly and drastically reduced my perception of the pain. I still felt it, but as a remote, dull ache - unpleasant but not particularly painful. It also made me drowsy, although this decreased rapidly with repeated exposure. This drug was extremely useful - if I triggered RSI symptoms, I could stop whatever I was doing, take amitriptyline, and ride out the storm.
The doctor also prescribed splints, to be worn while sleeping. During sleep, muscles on the inside of the arm compress slightly more than muscles on the outside of the arm. This is not normally a problem, but when inflammation is already present in the carpal tunnel, this extra compression will add additional pressure on the nerves passing through the tunnel, causing pain/numbness/burning/cold, which will cause you to wake up in the morning with your wrists in a painful state, and can also interrupt your sleep.
In August 2016, I turned back to the dictation system. I heavily customised it (mostly by turning various commands off) so that it could be used to write text character by character. Although slow, it was about the same speed as dictating to an assistant, and I could think through a problem carefully without speaking, which is boring for a human assistant to sit through.
The developers of the dictation system had thoughtfully left room for plug-ins. I began to spend most of my time reading the manual, reading textbooks on the plug-in language (AppleScript), and using the characters I could produce by voice to write small plug-ins. Sometimes I would also type characters using an index finger or the eraser end of a pencil. Gradually, I made the system more usable as a programming tool, which allowed me to expand the system itself more quickly. I learned how to pass part of the dictated text into a plug-in's code as a variable, allowing me to create commands such as "press left arrow [x] times", where x was e.g. "three". Eventually, I figured out how to pass the dictated text for a particular command out to a Python script, allowing me to write powerful commands that could easily catch and correct many misrecognitions, as long as they were properly specified.
I include this level of detail about my dictation system because it has formed an integral part of my recovery. It has allowed me to work (slowly) while resting my hands and arms. It has also meant that rather than wait in frustration for recovery I could proceed steadily towards a goal (the creation of a usable dictation system). Making steady progress towards a goal appears to be an important component of human happiness/satisfaction, and in working towards my goal I have avoided most of the depression that often accompanies RSI. Depression has a variety of negative effects on health and the body's rate of healing, so it is preferable to avoid it not just because it is unpleasant but also because it might slow down recovery.
By January 2017, I had improved the dictation system to the point that I could produce code at a reasonable speed. I have made various improvements since then, but I started to hit diminishing returns - increasing amounts of work are required for smaller gains in capability. Major improvements would require access to the source code, which I do not have, as the application is proprietary and compiled. I have created a demo of the system [link] [paywalled], in case any reader wishes to see it in operation.
I estimate that I can now write code using the dictation system 10 times faster than when I started working on it. I can also edit normal text smoothly and accurately by voice. I cannot dictate for as long as I used to be able to type and I am perhaps 20 times slower than my original speed, especially when doing tasks that require switching between several windows or manipulating buttons/controls on GUI interfaces. Nonetheless, I can work at a slow, steady pace, and complete various useful tasks, especially ones that involve reading (e.g. anything to do with taxes or regulation) or producing small scripts that do a lot of work. Sending electronic messages to other people still requires work but is not the enormous challenge that it used to be. I can manage transcription projects and check the quality of the work.
I have over time become less dependent on the dictation system. After this long period of recovery (July 2016 - February 2018), my condition has improved. My symptoms, when they occur, are weaker, and I manage them better. I can detect the initial onset of symptoms much earlier and can thereby avoid triggering the worst responses. I rarely take amitriptyline. I use better equipment and have better posture while working. I can usually do a small amount of typing, if I am careful, and on some days I can do a larger amount. If any RSI symptoms begin, or if I have to produce a lot of code or text relatively quickly, I switch back to the dictation system.
[start of footnotes]
[0]
Page 49.
Repetitive Strain Injury
A Computer User's Guide
by Emil Pascarelli, MD & Deborah Quilter
Copyright © 1994 by Emil Pascarelli and Deborah Quilter.
Published by John Wiley & Sons, Inc.
Repetitive Strain Injury
A Computer User's Guide
by Emil Pascarelli, MD & Deborah Quilter
Copyright © 1994 by Emil Pascarelli and Deborah Quilter.
Published by John Wiley & Sons, Inc.
[return to main text]
[1]
The web application is a very useful interface for this type of transcription. It includes an editable auto-complete and shortcut keys for annotations. The speech system's initial transcription is displayed and can be copied for correction or ignored if it is too inaccurate. Almost every action can be performed by using only the keyboard.
[return to main text]
[2]
Most transcribers did not do very many transcriptions, but if I had not hired them all I would not have found the few who did enormous amounts of work.
[return to main text]
[3]
If a project is urgent and can be distributed among many people, and you need to find these people quickly, offering immediate weekly payments is helpful.
[return to main text]
[4]
No checks were performed for the transcriptions in Project 1. The transcriptions were needed as soon as possible, without time for checks.
Here is the overall analysis for Project 2.
A complete match means that I thought that the raw text (e.g. "hello i'm calling about a bill") and the annotations (e.g. "[breath-noise]") were both correct.
A raw text match means that I thought that the raw text was correct but that the annotations were not.
The raw text score is the most important aspect of a transcription project. The annotations are mainly used when working on a speech system - they help a speech system writer to quickly see likely causes of misrecognitions.
Despite the pressure of the unusually large workload and the large number of new transcribers, we managed to achieve a high raw text accuracy rate - very usable for a speech system project.
Some transcribers had low accuracy scores but these tended to do relatively few transcriptions. In a couple cases I redid most of their work. Starting from inaccurate transcriptions was still useful, as they were usually more accurate than the speech system's guesses, and we were trying to finish the projects as soon as possible (both clients were in a hurry, particularly our Project 2 client, which was under pressure from its client).
Here is the overall analysis for Project 2.
119779 total number of transcriptions in project
14528 checked
2663 corrected
12.1% overall percentage reviewed
81.7% overall score (complete match)
88.6% overall raw score (raw text match)
A complete match means that I thought that the raw text (e.g. "hello i'm calling about a bill") and the annotations (e.g. "[breath-noise]") were both correct.
A raw text match means that I thought that the raw text was correct but that the annotations were not.
The raw text score is the most important aspect of a transcription project. The annotations are mainly used when working on a speech system - they help a speech system writer to quickly see likely causes of misrecognitions.
Despite the pressure of the unusually large workload and the large number of new transcribers, we managed to achieve a high raw text accuracy rate - very usable for a speech system project.
Some transcribers had low accuracy scores but these tended to do relatively few transcriptions. In a couple cases I redid most of their work. Starting from inaccurate transcriptions was still useful, as they were usually more accurate than the speech system's guesses, and we were trying to finish the projects as soon as possible (both clients were in a hurry, particularly our Project 2 client, which was under pressure from its client).
[return to main text]
[5]
When you enjoy programming, writing a good program to solve a problem produces a feeling of pleasure, success, self-worth, and skill. Moreover, being able to type and test your approach to the problem at the same speed at which you think is an experience similar to skateboarding rapidly down a long hill. It can be exhilarating. [6] I was loathe to admit to myself that I might have caused permanent damage to my body, because this would put this experience out of my reach for a long, long time, perhaps forever.
[return to main text]
[6]
This may perhaps be only true when writing scripts, where you can see the result of each new section of the script as you go. Writing new features for an important application (often taking into account complex interactions with other parts of the application) or implementing vital calculation routines (which may be run millions of times and must be perfect) is like engineering - these must be designed very carefully and slowly, with many tests (each of which should itself be carefully designed). A skateboarding approach, in these areas, is a terrible, terrible idea.
[return to main text]
[end of footnotes]