Qwerty or Not

Switching to the Dvorak keyboard layout can be worth it. I’ll discuss benefits and some caveats. But I want to offer a warning: switching from Qwerty to Dvorak and back to Qwerty again is an experiment in brain plasticity that isn’t going that well for me.

First, a bit of background. Most computers have a standard keyboard with the “Qwerty” layout. I’m sure everyone has noticed the letters are not alphabetical or in any other obvious order. The keys are arranged peculiarly because of the mechanical limitations of early typewriters, and like so many things, the layout of the keys is purely out of tradition. Personally, I didn’t know much about keyboard history until Qwerty helped ruin my wrists.

I worked at a company that had several claims due to repetitive stress injury (RSI) so they were sensitive to these things. One fine day, after several hundred thousand lines of code, I could no longer type. The management called in an ergonomics expert who suggested (among other things) that we look at the Dvorak keyboard layout for our programmers. It is a more efficient layout than Qwerty and they said it could ease the pain. All I needed to do was retrain my brain and my hands. This process would take several weeks, but since the company was averse to another injury claim they agreed to let me and several other employees take the time to switch to the Dvorak layout.

The Dvorak layout is based on the simple idea that the most common letters in the English language should be grouped together on the keyboard so that you barely have to leave “home row”. All modern computers can be switched into a Dvorak layout. But unless you get a new keyboard that shows the Dvorak keys you will need to learn to touch type because the letters you are typing will no longer match what you see on the keys. Most good typing software has a training mode for this layout.

The problem is that after typing on Qwerty for years our brains are literally hardwired to the layout. There is a physical part of your brain that connects the letter ‘J’ to your right index finger. To switch layouts means to first disconnect and then rewire that key in your head. The process is very frustrating. It took about a month before I was back up to speed. But then I was almost as fast as before. I persevered and have typed in Dvorak layout almost exclusively for the last 10 years.

Here are some things I learned along the way:

  • I have not had any more serious hand or wrist pain since I switched. I can’t claim with certainty Dvorak was the cure because I don’t code/type as much now but when I first switched years ago the pain went away and never came back.
  • I was never as fast in Dvorak as Qwerty. I hit maybe 95% of my old speed. This was due to more errors. But I still always felt more efficient. You feel like you are typing less because you don’t move around on the keys as much.
  • I lost my Qwerty “mode”. I could still type Qwerty by looking at the keyboard but could never touch type it after switching to Dvorak.
  • Passwords and hidden inputs can be mine fields if you have to touch type long cryptic strings.
  • Logging into other non-Dvorak computers is a pain and using remote access technologies has a whole other set of challenges.
  • If you are a heavy keyboard shortcuts user you will have to retrain on those as well. It can seem like relearning your applications again. Photoshop and Emacs are tough to relearn! Also, key combinations that made sense based on layout (W A S D) don’t make sense in Dvorak.
  • You have to remember to change layouts for anyone who needs to type on your computer. It always freaks them out (may be a good thing for a boss who needs to “make just one change”).
  • Most mobile devices only have a Qwerty keyboard so you can never completely get away from it anyway!

Now, for more fun. Eventually I grew tired of all the problems caused by being “different” and just wanted to use the same keyboard as everyone else. I’m no longer an isolated programmer coding on my own machine with my own special configuration. And I don’t have to code thousands of lines at a time any more so I’m not as worried about my hands. So I bit the bullet and decided to switch back to Qwerty. After ten years of typing with a Dvorak layout, how hard could it be?

It. Is. A. Pain.

I do not recommend switching back if you’ve already committed to Dvorak. I feel I have un-wired my typing circuits in some fundamental way. Maybe it’s just because I’m older, but here are some of the issues I have run into for the last month of trying to switch back:

  • After several weeks of training every day with good software, I’m up to a meager 45wpm and still about 10% error rate.
  • My brain seems to be permanently confused over the locations of certain letters no matter how much I train on them.
  • One of the most frustrating things I have ever tried to do. My fingers do not do what I want them to, even when consciously willing each one. What muscle memory?
  • I do expect to improve more. In fact, the last day has gotten better. But it is taking much, much longer to switch back than it did to convert to Dvorak.

In short, switching keyboard layouts was mostly a good thing for part of my career. But at this point switching back to Qwerty was probably not! If you are thinking about trying the Dvorak layout, consider that you will be the odd one out and that you will never get away from Qwerty completely. But, most importantly, it is a lifetime commitment. It will change your brain in ways that are difficult to reverse. If you aren’t sure, and you are not desperate to try something to prevent or cure RSI, I think sticking with Qwerty is fine.

Over and under

We all want to deliver excellence. But one ‘nugget’ of wisdom in consulting is that it is best to under-promise and over-deliver.  The implication is we should say we only need to do X but then deliver X + Y and everyone will love getting more than they expected. But is this really a good idea?

What if a patient went in for a single bypass surgery and afterwards the doctors said they did two? Should the patient be happy? Should he/she say, “Hey, I got a deal, it was a two-for-one-bypass!” Probably not. The patient might wonder if it was really necessary and be concerned about healing from more surgery.

We need to recognize that software development is the execution of a set of procedures which are deeply tied to the client’s health in complicated ways. Each technical decision, even at the level of a database stored procedure, for example, is like a small incision that shapes the outcome of the whole project. But sometimes it becomes an imperative on a project to deliver both mightily and most vigorously, to bear down upon a set of deliverables and try to just knock the client’s socks off. This is not bad. But what about over-delivering by under-promising?

I’ve come to think of that idea as just plain wrong. More surgery does not automatically make for a successful outcome. Of course surgery is not the most apt metaphor for software development. But it is useful to highlight some things that we overlook if we think of software only as a product (and that more “product” is always better):

  • All projects are invasive, no matter how necessary or strategically important. Like medical procedures they must first do no harm and then seek to cure.
  • Putting a lot of effort into adding extra whiz bang features, UI gloss, or performance optimizations all come at a cost to the client as increased maintenance, support, training, higher desktop or server requirements, and so on. These are long term costs and together can be significant!
  • Trying to beat schedules or, worse, purposefully over estimating to get an easier schedule to beat, ignores the fact that delivery has to be carefully timed for testing, user acceptance, deployment, training, support and so on. Trying to coordinate all of this with stakeholders while rigging and jumping  schedules is really bad planning and wastes everyone’s time.
  • Over delivering means delivering unexpected new features or working on a schedule not approved by the stakeholders. How is doing anything not approved by the stakeholders really better?

In short, I think that over delivering is just as bad as under delivering. Our goal should always be to deliver the feature sets we defined with all stakeholders on the schedule agreed upon. And when the pressure is on to “just do more than expected” we need to remind ourselves that over shooting and under shooting both miss the bulls eye.