Monday, November 25, 2002

Dealing with Carpal Tunnel*

In late 1997 when I was working with hand tools or typing for extended periods of time, my wrists would occasionally start to tingle. Like many people I didn't think twice about it and simple assumed it would go away. However as time went by the tingling turned into pain and then I took notice. I went and saw a doctor about the situation. He gave me an arm brace and I was told to return in a month. The arm brace did help and the pain disappeared after a week. Over the next year whenever the pain would return in one of my wrists I would simply wear the braces until the pain went away. The braces were healing my wrists, but I knew that if I kept up the cycle my wrists would eventually not be able to heal. I began to explore different steps that could be taken to prevent injuring my wrists again. Over the years I have tried many different things and spoke to many people about what they have done. The following is a list of the best actions I have taken to prevent further injury to my wrists.

The Desk

When sitting in a chair with your feet on the ground and your hands out, they should fall exactly over the keyboard without your wrists bending up or down. The desk should be at the correct height for this to occur. Note that the purpose of the ability to adjusting the height of a chair is so that your feet are properly on the floor and not for placing your arms at the correct height over the top of the desk.

When I was almost broke and living with several other guys, rather then buying desks, we built them. We went down to Home Depot and picked up some lumber and spent the next two days building our own custom desks. Because the desks were custom built I was able to place the top of my desk at my correct height. My hands rested correctly on top of the keyboard when it was on the top of the desk. The total cost of the desk was only $40 and a weekend's work. I doubt that I could ever find a better desk at a retail store. You don't need to build your own desk, but acquiring one that fits your body is essential! If your wrists are normally below the keyboard you might be able to get a keyboard tray to lower the keyboard's height. For the opposite, books or reams of paper can be used to raise the desk. Remember to try to find the best solution and not the cheapest/quickest one.

The Monitor Height

Keeping your arms straight is a whole lot easier if you have good posture. Part of this is sitting up straight. In my case when my arms are straight the desk is about two feet below my eye level. Because I don't have a three foot tall monitor (putting the center of the monitor at eye level) I now have a little wooden box that sits under my monitor that pushes it up six inches or so. This combined with the monitor's base was enough to raise the screen so I wouldn't slouch.

A Good Chair

Getting a good chair will help keep good posture. You don't need to spend $1000 getting the best chair on the market, but spending $5.95 wont do you any good either. You want a chair that has good support, fits your height and build, and the ability to be adjusted up and down. Your hands should be directly over the keyboard while your feet are firmly on the ground. Expect to spend around $40-$80 for this chair. It will be worth every penny in the long haul.

Trackball Mouse

When I switched to a trackball mouse I saw a dramatic decrease in the amount of pain in my right wrist. Granted I hated those first two weeks when I had to learn how to use the mouse, but now I wont use anything other then a trackball. The reason is that when I use a trackball all of the movement is done by my thumb and not by my wrist. With traditional mice the wrists is constantly moving, often in quick small back and forth movements. The trackball was probably the best positive change I have made to help my hands. Bonus: For all of the gamers out there - How do you think those LPB turn around so fast?

Ergonomic Keyboard

I currently have a Kinesis Classic keyboard, but I didn't always have it. Over the years I have tried quite a number of different keyboards, from so called ergonomic keyboards, to one-hand keyboards and they are all now collecting dust in my closet. You can read up more about the Kinesis keyboard on Kinesis's site, but it all comes down to two things. The first one is that the pinkie (the weakest finger) no longer does a lot of work as the enter, space, delete, etc keys are in the middle where the thumb (the strongest finger) hits them. The second is the curved keyboard design helps to keep the wrist in line with the arm and prevents bending at the wrist. See if you can't find someone who has this keyboard and give it a try. It took me about two weeks to adjust to typing on this keyboard. An unanticipated side affect was that I could actually type faster (~130wpm) using this keyboard because the split keyboard forced me to properly type.


All of the above actions have lead to two main results for me. The first is that my wrist moves as little as possible. The second is that for the majority of the time my wrist and my arms are in a straight line and not bent. The combination of these two maintains a relaxed natural wrist position. This allows the tendons to work without dragging along the edges of the bone causing the inflammation and pain. I still have my wrist guards, but only wear them when I am working on someone else's computer. Some of the tips here are more expensive then others. However would you rather waste $400 buying new keyboards until you find the best, or would you rather have to go through surgery five years down the line? Surgery is just another form of the wrist guard, it will only remove the pain for a few years before it returns. Take a look at your computer area and see what you can change. Making simple changes to your computer area and remembering to take breaks from long periods at the computer (such as walking around and get some blood flowing) will go a long way. The past computer setup I had hurt my hands and I will pay for that the rest of my life. However I am not going to cause them further injury. The only times the pain comes back to my hands is when I am working with power tools for a long time, peeling a lot of potato's or some other repetitive task, but as soon as it starts to hurt I immediately stop and rest my wrists. My hands aren't pain free, but I can't remember the last time I had pain in my wrists because of my computer.

*I have never actually been diagnosed with having carpal tunnel, but I do believe that I was headed down that road.

Thursday, June 06, 2002


Last month after a more then a year of planning on May 11th 2002 at 3:30pm I was married to Jennifer Ann Rogers. After all of the fun we went on our honeymoon to the wonderful island of Aruba for a week. Returning from our vacation we moved down to New Jersey to our new apartment where I have my new job at Sharp Electronics working on the Zaurus PDA. Sorry for the late post, we finally got our internet connection at home today.

Saturday, March 16, 2002

Nine 9's Puzzle

On ITASoftware's website they put up a little puzzle called Nine 9's. I spent the evening solving it and have put up the results

You can download the source here.

The puzzle:
Combining nine 9s with any number of the operators +, -, *, /, (, ) , what is the smallest positive integer that cannot be expressed?

1) The answer isn't zero. You can express zero like this: (9 - 9)(9 + 9 + 9 + 9 + 9 + 9 + 9)
Also, zero isn't a positive integer.

2) The answer isn't one. You can express one like this: 9 - (99 - 9)/9 + 9 - 9 + 9 - 9

3) It's not a trick question.

4) Be sure to handle parentheses correctly.

You cannot exponentiate.
You cannot concatenate (for example, put two 9s together to make 99).
The - operator can be used in either its binary or unary form.
Assume base 10.

Thursday, February 28, 2002

What makes clean code?

The problem of always learning more.

Every programmer remembers his or her first "big" application. By big I am referring about a project that wasn't for a class, it actually did something, and went over some magic line number that gave the creator bragging rights (such as 500 lines). More often then not these projects are not very good games. And of course not only was the point to show everyone the game, but the code as well. The code might even still be saved somewhere gathering dust. The author is proud of it, but wouldn't dare look at the code for fear of what he might find. The code of this first project is probably smeared with programming goop: badly written or out of place code. Part of what made the code so horrible was simply the inexperience of the programmer, but the other half was closely related and is something I have dubbed: learning code goop.

What is learning code goop? It is a subset of regular code goop, the left over code from attempts at solving a problem. As a developer grows their code will naturally be cleaner and more thought out, reducing the overall goop within it. Unfortunately learning code goop stays with coders for a long time (and for some developers it never seems to leave) because it comes from the constant learning of new tools and attempts at utilizing them. As a developer attempts to write an application in the "toolkit of the week" they must learn that toolkit at the same time. They may have read a book, went through a tutorial or even written a few applications in it already. But there is always something new to learn about the libraries and toolkits that are being used by the developer. When the developer wants to add a new feature to an application he must first figure out how to do it using the toolkit. He will probably try several different ways before finding a working solution. But before that happens: temporary functions with nonsense names such as try(), 1 letter variables, includes, and of course code with no comments will be created. This is so the developer can quickly try out what he thinks the documentation might be saying or what he thinks the language can do. In most cases once the new feature is complete the developer doesn't go back and cleanup the functions, variable names, and add proper comments. The new feature is complete and so it is time to move onto the next feature. One reason why the code isn't immediately gone over is that the developer has just spent a good amount of time pouring over the same tiny bit of code over and over and can probably recite it if asked. At this point in time the code is perfectly clear in his mind. Unfortunately this new feature is filled with bits of code goop making the code difficult for anyone to read. Even the original author when presented with the code in a month will probably like to clean it up.

These types of problems aren't the grand scale problems thought out before programming started, but small ones that aren't included in the design documentation. It might be as primitive as a task such as replacing b*r with g*r (* being any length of characters). An inexperienced developer might spend twenty minutes write two functions to do it when it really can be done in one line of code. I can think of countless examples of scenarios that I have seen where students attempt to figure out what can often be done in three lines of code, but there solution is much larger. The trick to avoiding the whole problem is to know the three lines of code. Of course no one knows exactly what will solve the problem and that is where the goop comes from. That is the reason why the problem is found not just in students. Unlike general programming goop that disappears as the developer matures in his/her coding skills this can stick with them for a lot longer.

Unfortunately a good programmer will only know the magic three lines of code part of the time because there will always be new features to learn. The hard part is avoiding writing goop when you are learning these new features. But how can a developer avoid learning goop?

To successfully remove goop from code a developer must do several things. First the developer must be familiar with the internals of the programming language. Not only mastering the basics, but also more advanced components. This way when faced with a simply problem they wont use a solution that shouldn't be. Next the programmer defines some sort of style guild-line to follow. In the book Code Complete the author gives many good suggestions on how to improve the readability of code. Everything from variable naming to application design. Many developers have read the book, thought it was great, but when they look at their code from the week before they can spot areas that need work. More then likely the areas of work are from learning goop and the solution is that when they are done with a little problem go back and clean up the code they had just worked on. Apply the style guides, add comments, and remove unneeded code. Even do a code review of the new lines of code. Some programmers are so eager to hit compile that they often missed such simply things a missing else statements leading to bugs further down the line.

Programming goop is something that affects most programmers. Some are able to overcome it, but many don't. Have you?

Thursday, February 21, 2002


I have created a new application called KAudioCreator. It is a front-end tool for ripping and encoding CD's. I am happy to say that KAudioCreator will be part of KDE starting with KDE 3.1.

KAudioCreator is a front-end tool for ripping audio CDs and encoding the wav files using your favorite encoder. Based upon KDE it combines the look and feel of your desktop with the power and flexibility of the command line tools. KAudioCreator is an audio file creation solution for KDE. It allows you to use whatever encoder you wish to encode your audio files while providing a comfortable GUI. KAudioCreator also provides a job control system so you can see what files have succeeded, failed and stop or cancel jobs as the application progresses.

The source for KAudioCreator is now kept in KDE's repository here.

Popular Posts