How Carpal Tunnel improved my Code


“Waterfall”. M.C Escher.1961.

When I started waking up with annoying and persistent tingling every morning around one and a half years ago, I didn’t take it very seriously which probably was the wrong thing to do. By the middle of 2016 however, the pain had gotten annoying enough to affect my concentration which is when it was evident that I had carpal tunnel. With help from my father who is luckily a medical doctor and told me about wrist braces and various lifestyle changes, the pain became a little manageable however I was still left with an engineering constraint.

Here is what usually happens when I sit and type: After the first ten minutes the area between the thumb and index finger of my left hand begins tingling (I am left handed so it starts with the left hand). Around the seventeen minute mark, my right hand starts feeling similar tingling. After around half and hour, my hands are pretty much in pain and I also begin feeling pain around my shoulders. After forty minutes, I simply have to stand up and either walk around or lie down for a bit before resuming work. The pain subsides more or less completely after ten minutes of rest but my breaks typically last twenty minutes as I am lazy.

To summarize, every forty minutes of typing incurs a cost of 20 minutes. Initially, I was pretty depressed as I made the mistaken and naive assumption of time spent writing code was directly proportional to my productivity as a programmer. With that assumption, carpal tunnel meant a ~33.3% loss in productivity. I have been measuring my roughly productivity by assigning difficulty levels to tasks I store on Google Tasks. This includes research projects, course projects, assignments, reading textbooks/documentation etc. Surprisingly, after eight months of this, it seems my initial assumption of a ~33.3% loss in productivity could not have been more inaccurate. In fact, it seems to me that my productivity has actually  increased over this period.

Yes, I am aware that correlation does not imply causality. Understandably, there are a lot of factors involved in this increase in productivity from the fact that I gain more knowledge and experience with time to the fact that my caffeine consumption has also increased significantly. However, I am still convinced that carpal tunnel is playing a significant role in this trend. Here are a few reasons why I think that is the case.

1- The 20 minute “break” isn’t time wasted

In fact, during the 20 minute break I think about the code I have written and what I plan to do in my next 40 minute work session. In other words, this has turned into a kind of planning session that precedes every work session. The key advantage to this is that, earlier on if I had say ways to approach subproblem X, I would first mentally sort them in descending order with an order principle like: (w_{1} * ease of implementation + w_{2} * probability of working – w_{3} * computational resources required) where the w_{i}s are weights. Then, I would mentally execute the following algorithm:

approach_list = []

while not tired:
    new_approach = think_of_approach()


while not working_fine(current_approach):
    current_approach = approach_list.pop()

until I managed to come up with one that worked fine.

Now what the planning session allows me to do is prune the approach_list before the implementation and testing steps by simply thinking through all the approaches and removing the ones I can deduce (or when I’m really unsure, mathematically prove) will not work. In other words, now I execute the following in between the two while loops (after sorting, although it doesn’t matter):

approach_list.filter(approach => deduce_correct(approach))

Since the deduce_correct function takes less time in the average case than implementtest, this method of pruning the dataset more than offsets the 20 minutes “wasted” in the planning session.

2- Pain incentivizes cleaner code

When every key-press hurts your hands, it is not difficult to motivate yourself to write code that is more:

  • Clear: as altering, say, variable values to figure out what a piece of code is doing later in case I forget will result in more agony.
  • Concise: the less code I write to address every problem, the less it hurts.
  • Reliant on the standard library and third party APIs: reinventing the wheel hurts too much.
  • Better commented: The last thing I want to do is rewrite a routine because I’ve forgotten how it works. The clearer (and more concise) comments I write, the less painful my future.

3- Picking the right tool

This is in some ways a corollary of reason 2. I have now also become more inclined to begin projects using programming languages and technologies that will help me get them done with the least amount of boilerplate code etc. While admittedly this can add performance and scalability challenges as things get more complex, I realize I often over-complicated my life by thinking that far ahead resulting in even bare-bones functionality taking a long time to get implemented and in me often resorting to hacky solutions. For example, it is almost redundant to mention that a simple web-crawler written quickly and beautifully with python + urllib or node-js + https/http libs (or even bash + wget) can take over twice the time (and twice the code) if implemented in certain other languages (Captain obvious: “He means Java”).

Statistics: Writing this took me 1.575 writing sessions and 2 planning sessions. 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s