My keyboard layout that optimizes the ratio of switching costs to benefits

You must notice that the default keyboard layout is not very optimised for writing code. Standard touch typing assumption of “home row” assumes that all characters you will need are close to the home row. This assumption is correct when typing text, but it is not longer valid when writing code. Many of frequently used characters, like parentheses, brackets or equals sign are placed very far away.

For example, let’s look at following made up snippet of C++ code:

for(int i=0;i<10;++i){}

22 total characters (Without space)
If you would want to touch type this snippet, 8 of them would be typed by right hand’s little pinky. Let’s look at the distances of each key from respective fingers position on the home row. To simplify, I’ll count pressing the shift as 1 and for diagonal keys I’ll use pitaghoras:

f o r ( i n   t   i =   0 ; i < 1 0 ; +   +   i ) {   }
0 1 1 3 1 1,4 1,4 1 2,8 2 0 1 2 2 2 0 3,8 3,8 1 3 2,4 3,2

Total distance: 38,8
Average distance per key: 1,76

That’s pretty bad. Here is a good list of alternative keyboard layouts I’ve ever seen: . All of them are focused on changing the arrangement of letters. Changing arrangement of letters is tackling the wrong problem.
Letters are small portion of overall typing cost during programming, since variable names and language keywords get autocompleted in any sane editor. Frequently typed special characters are used very frequently when writing code, but all layouts do not take this fact into account.

Let’s think if it is possible to solve a problem without:

  • Relearning how to type
  • Don’t spend days reconfiguring your favorite apps
  • Do not lose muscle memory associated with majority of shortcuts
  • Don’t make your computer unusable for other people
  • Still be relatively productive on other computers
  • Make it as non intrusive as possible, so people won’t mind too much if you install it on shared computers

My layout begins with a few simple observations:

  • During typing usually only one thumb is responsible for typing space and another one hangs in the air
  • There is not much ergonomic benefit in using other-hand cmd key. Thumb do not restrict movement of other fingers and is located in the nice poisiton. I can easily reach all letters with my left hand if I hold down the left cmd key (Pinkies are not detached, learn to use correct shift)
  • Majority of people I know use left cmd for all shortcuts anyway, so we can do something fancy with right cmd
  • No one I know uses caps lock. People I know even if have to type a few capitalised letters just hold shift

So here is the keyboard layout I propose. Crossed keys are not disabled, they are only not supposed to be used.


Right cmd becomes a “blue” layer. So for example you press right cmd and a to type ‘(‘, or right cmd, shift and g to type ~. Right thumb will rest all the time on right cmd, so activating a blue layer is frictionless and do not require changing finger position. Left thumb will be responsible for pressing space, left cmd and alt. Notice that such placement of thumbs is acustomed to “staggered” column layout of your keyboard – e.g. columns are not straight, but bended by about 30 degrees to the left. What’s more caps lock becomes ctrl and if it is pressed quickly and without any additonal key it becomes escape. Right shift if is pressed quickly and without additonal key becomes delete. Enter if pressed with something else becomes ctrl. If it is pressed alone it is still plain old enter. All subsets of cmd,alt,ctrl,shift can still be easily pressed together, and some of them more easily than before.

Let’s see how far away from the home row our keys are now:

f o r ( i n   t   i = 0 ; i < 1 0 ; + + i ) { }
1 1 1 0 1 1,4 1,4 1 0 1 0 1 2 1 1 0 1 1 1 0 0 0

Total distance: 16,8
Average distance per key: 0,76
57% distance reduction and workload is more evenly distributed between fingers. You can complain that pressing two keys is not convenient. Notice that some of the buttons that we press with cmd were previously pressed with shift, which is way worse than right cmd, since we need to move our pinkie to reach it. What’s more, special characters and numbers are usually pressed consecutively, so right thumb goes up or down only once per few characters.
For example if I want to type expression “= (2+3)*4-5” I hold the right cmd during typing the whole phrase. In for example we type on average 2 characters which each press of right cmd.

Installation instruction for Linux:
Implementation is on github

Installation instructions for Mac:
1. Open keyboard -> modifier keys, and change caps lock to ctrl:
2. Install Keyremap4macbook
3. Load my private.xml from
4. Set following options in keyremap4macbook:
5. In key remap4macbook change key repeat->key overlaid modifier to 200 ms. It means that if you hold say right shift for longer than 200 ms, but don’t press it with any additional key it will not translate to delete. If you want to press shift with something, but change your mind in between it won’t press unwanted delete.

You are all set. The only program that was malfunctioning with this layout was, because Alfred manages input in it’s own way. Go to Alfred preferences -> file search -> actions and disabling ctrl as Show actions modifier solved the problem for me.

One more change to my layout I considered is making the space button an additional shift in case it is pressed with some other key and a space if it is pressed alone. It’s a pity that on normal layout a finger movement is required for so important button. I didn’t, because it would break my ability to efficiently type letters on another keyboards. What’s more, with this layout I rely on shifting less than I used to and variables are not capitalised in c++, so I decided it’s not worth it.

There are a few free fields left in the blue layer, so some of characters that require shift and cmd like * or # could be fit there. I didn’t do it yet just in case I’ll come with better use for these fields.



  1. The human brain is wonderful at learning stuff like keyboard layouts. If you are having difficulty with the standard keyboard layout I suggest you spend more time on it.

    If you are a programmer, you shouldn’t be worrying about the keyboard because typing is only a small component of programming.

    Similarly, the piano keyboard layout is extremely poorly conceived because the harmonic relationships are not taken into account. Harmonic keyboards are available but are not popular. Good musicians can play a keyboard perfectly just through practice.

    1. I was already quite efficient with default layout. But I hope that if I’ll adapt more efficient layout I’ll be more efficient overall.

      There is a problem with Carpal tunnel and RSI as well (it’s real problem for many people). By typing on usual inefficient layout you can damage your wrists.

      Jeff Atwood in claims that even if we are not typing during the whole day while programming it’s better to be fast typist, because of limited size of working memory. The less time you spend typing the less things will escape your head.

  2. Hello. I like this idea really much. Are you still using it? Also, seems like the “blue layer” is not included in the xml anylonger? (or am I missing something)

  3. Yes that works, thank you very much! I have a Swedish keyboard so I have to remap a little but the blue layer is working.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s