Sharlon Regales for PSGtechnauts

Posted on Mar 12

Keyboard Ergonomics for Software Engineers: Down the Keyboard Rabbit Hole

#ergonomics #keyboard #productivity #hardware

Keyboard Ergonomics for Software Engineers: Down the Keyboard Rabbit Hole

What you'll learn:

Why your keyboard is shaped the way it is

Why that shape causes cumulative strain

How to improve your setup incrementally, from software to custom hardware

Why fewer keys reduce strain

What a minimal 34-key layout looks like

I've been a track and field athlete since I was eight years old. My event, javelin, demands full shoulder mobility, rotational power, and precise joint mechanics built over years. My career, software engineering, runs almost entirely counter to that: stationary, through a keyboard, for hours a day.

This difference brought friction, but I dismissed the early warnings; recurring aches and pains. I told myself it's the training load, stress, and/or irregular sleep. Then came the season-ending injuries: first shoulder, then an elbow, then the shoulder once more.

After the third, my physical therapist was direct: my injuries were symptoms of a bigger problem. The way I was sitting at my keyboard (shoulders rolled forward, wrists deviated, neck craned) was progressively undermining the same joint mechanics that javelin demands. My desk work was undoing years of training. The keyboard I'd never thought about was interfering with the thing I cared about most.

A Brief History of Why Your Keyboard Looks Like That

To understand why your hands land where they do, you need to go back to the 1870s. Sit at a standard keyboard and notice: forearms flat, wrists angled inward, shoulders rolled forward. That's not a bad habit. That's the keyboard working as designed. It had been loading my joints in exactly the wrong way, every day, for years.

This matters beyond athletics. Anyone who types for a living spends thousands of hours a year in the positions that keyboard forces. The cumulative load is the same whether you're training for javelin or sitting in a meeting.

Which raised the question: why does the keyboard demand this in the first place?

Blame the Typewriter

QWERTY was designed in the 1870s by Christopher Latham Sholes for the Remington mechanical typewriter. Each key was attached to a physical metal arm called a type bar, which swung up to stamp ink onto paper. All these arms were arranged in a semicircular arc below the paper roller, converging at a single strike point.

Here's the problem: if you typed two adjacent letters quickly, adjacent type bars would collide and jam. Sholes's solution was to rearrange letters so their bars were less likely to physically crash into each other. The letter arrangement we call QWERTY is, at its core, a mechanical compromise for 19th-century metalwork.

The staggered rows, where each row is offset diagonally from the one below, is a similar story. Linkages between the keys and the type bars needed physical clearance to avoid interference. The stagger is a hardware constraint from a machine that no longer exists, preserved faithfully on every keyboard manufactured since.

Row-stagger (Remington No. 2, 1878):
2 3 4 5 6 7 8 9
  Q W E R T Y U I O P
   A S D F G H J K L ; M
     Z C X V B N

no 1 or 0 keys; typists used lowercase l and uppercase O
M sits after L, not below N; X and C are swapped vs. modern QWERTY

The engineering problem was solved. The layout never changed. Once enough typists and typewriters used QWERTY, switching became economically irrational, even if a better alternative existed. When computing arrived, it inherited the layout wholesale.

Keys That Were Never On the Typewriter

While we're here, at the dawn of the digital age: a lot of keys on your keyboard weren't on the original typewriter. The Escape key was added by MIT engineers in 1960 for early terminal systems. Function keys came from IBM. Media keys arrived with the multimedia PCs in the 1990s. Modifier keys (Shift, Control, Alt, and Super/Windows/Command key with its rotating cast of logos) crept onto the layout over the decades as software demanded new input combinations.

  Esc  F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12  PrtSc  ScrLk  Pause

  ~  .  .  .  .  .  .  .  .  .  .  .  .  Bksp    Ins   Home  PgUp
  Tab  .  .  .  .  .  .  .  .  .  .  .  .  .     Del   End   PgDn
  Caps  .  .  .  .  .  .  .  .  .  .  .   Ent
  Shft   .  .  .  .  .  .  .  .  .  .    Shft            ↑
  Ctrl  Win  Alt   Spc   Alt  Win  Menu  Ctrl        ←  ↓  →

. = letter, number, or symbol key

Nobody ever sat down to design a keyboard for the digital era. We inherited a mechanical instrument built for stamping ink onto paper, bolted on new keys as software demanded them, and called it done. The interface was never reconsidered. Just patched.

My Journey: A Guided Tour of Increasingly Extreme Decisions

That's the inheritance. What follows is what I did about it.

[!NOTE] I never measured any of this: no baseline before I started, no controlled comparison between steps. Every step was a response to a physical problem the previous one hadn't fully resolved. The sequence runs from least to most disruptive: if you know what's wrong, skip to it. I went all the way because the shoulder didn't give me many other options.

Step 1: Try a Different Layout

My first instinct was the same one most people have: if the layout is the problem, why not just use a better one? Turns out, alt layouts exist and people have very strong opinions on them.

Each layout has genuine engineering reasoning behind it; they're not arbitrary alternatives to QWERTY, they're deliberate redesigns. The value isn't in the statistics: it's whether the design philosophy resonates with how you work, and whether you're willing to commit to the relearning. Before that commitment, think about your working context. You may have constraints beyond personal preference. The layout you pick will be the hardest decision to reverse.

The most established alternative is Dvorak (1936): common English letters on the home row (the middle row, where your fingers rest between keystrokes), hands alternating for most sequences, minimal finger travel. It's baked into every major operating system, and you can switch right now without buying anything.

The difference is visible at a glance: notice how Dvorak loads the home row with the most common letters:

  QWERTY:                          Dvorak:
  1  2  3  4  5  6  7  8  9  0    1  2  3  4  5  6  7  8  9  0
  Q  W  E  R  T  Y  U  I  O  P    '  ,  .  P  Y  F  G  C  R  L
  A  S  D  F  G  H  J  K  L  ;    A  O  E  U  I  D  H  T  N  S   <- home row
  Z  X  C  V  B  N  M  ,  .  /    ;  Q  J  K  X  B  M  W  V  Z

  Dvorak Classic:
  7  5  3  1  9  0  2  4  6  8   <- original 1930 number row
  /  ,  .  P  Y  F  G  C  R  L
  A  O  E  U  I  D  H  T  N  S  <- home row (same as Dvorak)
  ,  Q  J  K  X  B  M  W  V  Z

I decided Dvorak Classic: the 1930 original, which arranges the number row to alternate hands the same way the letter rows do, rather than the sequential 1–0 of modern Dvorak. If you're going to rebuild the layout from first principles, you may as well use the version that applied the design philosophy consistently. My typing speed collapsed for several weeks, but then climbed back. Did it meaningfully help with my pain? Modestly, but it wasn't a dead end. It was the first layer of something I hadn't finished building yet.

Step 2: Make the Keyboard First-Class

Fixing the layout helped. What helped more was confronting the mouse.

Every mouse interaction is an interrupt: lift hand from home row, locate the mouse, shift posture to reach it, execute, return hand, re-align fingers, resume. A standard keyboard already holds the forearm in full pronation, palm flat to the desk. Every lateral reach for the mouse is angular movement on top of that, loading the forearm in an already compromised position. Once or twice is nothing. Thousands of times a day, compounded across a career, is a different problem entirely. Time at the keyboard in optimal posture is the goal; the mouse was systematically undermining it.

Then my MX Master died. Perfect excuse. What I hadn't accounted for was the software. Modern software is built around the pointer: graphical interfaces assume a cursor, menus are designed to be clicked, and most applications treat the keyboard as a secondary input at best. It meant being deliberate about every piece of software in my workflow: a tiling window manager, the terminal wherever possible, NeoVim as my editor and vim bindings injected into everything that would accept them. For software that fundamentally doesn't support keyboard-first operation, I keep a dedicated mouse layer on my keyboard. The mouse isn't gone; it's been demoted to last resort.

When the keyboard becomes your only interface, its flaws stop being background noise. Every awkward modifier reach, every useless Caps Lock, every wrist contortion you'd tolerated for years; suddenly they were the whole problem.

Step 3: Program the Keyboard You Already Have

Remember all those patches bolted onto the keyboard over 150 years? KMonad is a daemon written in Haskell that intercepts keyboard events at the OS level (/dev/input on Linux, with equivalent drivers on Windows and macOS) and lets you throw them out, redesigning the interface from scratch for how you actually work today, on the keyboard you already own.

The change that mattered most was home row mods: I mapped my home row keys to dual-function. Tap A and it types a; hold it briefly and it becomes Ctrl. The same for Shift, Alt, and Super across the other home row keys. No more stretching my pinky to the corner of the keyboard; my modifiers now live exactly where my fingers rest.

Key    Tap     Hold
─────────────────────
 a      a      Ctrl
 s      s      Alt
 d      d      Shift
 f      f      Super

Modifiers were the first fix. The second was layers: they work like a more powerful Shift key. Hold a designated key and it transforms the whole board. I built a navigation layer that turns my right hand into the navigation interface, a symbol layer for brackets and operators, a numpad layer for numbers without leaving the home row. Key count stops mattering once you have enough layers; you only need one key per finger.

Base layer:                      Navigation layer (hold Nav):
'  ,  .  P  Y  F  G  C  R  L     .  .  .  .  .  .  Hom PgU PgD End
A  O  E  U  I  D  H  T  N  S     .  .  .  .  .  .  ←   ↑   ↓   →
;  Q  J  K  X  B  M  W  V  Z     @  .  .  .  .  .  .   .   .   .

tap ; -> ;
hold ; -> nav layer
@ = finger position

Layers solved the reach problem. The imbalance was a separate problem: on a standard keyboard, each index finger covers about six keys while Caps Lock, Insert, and Scroll Lock sit there doing nothing, bolted on relics that nobody had the courage to reconsider. I silenced them, redistributed the load, and spread the work more evenly across my fingers.

The last piece was the thumbs. I shifted the whole layout up a row. My home row now sits where QWERTY used to live, which means my thumbs land naturally on what were the C/V and comma/period keys, real estate I gave real responsibilities: Backspace, Enter, Delete, layer switches. My strongest digits, handling the highest-frequency actions, right where they already rest.

  Standard:                  Shifted up one row:          Remapped:

  1 2 3 4 5                  1 2 3 4 5                   Q W E R T
   Q W E R T                  @ @ @ @ T  <- home row      @ @ @ @ G  <- home row
    @ @ @ @ G  <- home row     A S D F G                   Z X C V B
     Z X C V B                  Z X @ @ B                   . . @ @ .
         [     @     ]               [  spacebar  ]             [     .     ]

diagrams are from the left hand perspective
@ = finger rest position; thumb sits between keys, not directly on one

This cost me nothing but time, and it genuinely helped. But it also showed me the hard limits of working with my 'standard' keyboard. The stagger is still there. Your hands still converge toward the centre. The layout is still hardware constrained.

Step 4: Get a Proper Ergonomic Keyboard

If KMonad is the gateway drug, buying an ergonomic keyboard is where you start paying for the habit.

I started with the Ergodox EZ. The first day I used it, the improvement was immediate and almost embarrassing. Splitting the board and placing each half at shoulder width eliminated the forward shoulder roll and inward wrist deviation that a standard keyboard forces: the exact mechanics my PT had flagged as undermining my throw.

The layout abandons the legacy row-stagger entirely: ortholinear, keys in a perfect grid, fingers moving straight up and down the way they actually extend and curl.

The three main grid forms, side by side:

  Row-stagger (legacy):     Ortholinear (grid form):
    Q W E R T                 Q W E R T
     A S D F G                A S D F G
      Z X C V                 Z X C V

  Column-stagger: staggered to finger length

        E            <- middle highest
      W D R T
    Q S C F G
    A X   V B
    Z                <- pinky lowest

A dedicated thumb cluster put backspace and enter exactly where KMonad had trained my thumbs to expect them, now reflected in hardware rather than software.

These boards run QMK, open-source firmware on the keyboard's own microcontroller, so everything from KMonad moves into the board itself and travels with it.

The Ergodox EZ is also large and heavy. After the novelty wore off, carrying it anywhere felt like a commitment. I downsized to the Moonlander Mark 1, same company (ZSA), smaller footprint, fold-out legs for tenting. Tenting rotates each half from palms-flat toward palms-facing-each-other, relieving the forearms of the all-day compression that full pronation imposes. Even a modest angle makes a noticeable difference.

Then the real experimentation started. I was already building layers for navigation and symbols. I started deactivating keys I never reached: the outer columns, the number row, the thumb keys I couldn't comfortably hit. Each time I'd wait a week. If I didn't miss it, it was gone. I got the Moonlander down to around 40 active keys; every deactivated key was one less lateral stretch or over extension, before the problem became obvious: I was fighting the hardware. The board still had all those physical keys; I was just pretending they weren't there. If I was going to work with 36 keys, I should actually have 36 keys. That question had already been answered somewhere in the open-source community. I just hadn't looked yet.

Step 5: Join the Open-Source Community

The community exists for exactly this kind of problem: people who treat keyboard design the way athletes treat training, with repetition, obsession, and enough meticulous documentation to distinguish what actually helped from what just felt like progress. Share everything. Someone's build log from two years ago will save you weeks today.

Miryoku was what I found. It made the case that 36 keys, with the right layer design, covers the vast majority of what you actually do at a computer, and explained precisely why each key is placed where it is. It runs on QMK and ZMK and on KMonad. That last point mattered: I could run the layout on my current keyboard before committing to new hardware, with the guarantee the experience would transfer.

The community produces dozens of open-source designs: the Corne (a 42-key column-staggered split that became a reference design for the whole community), the Totem (38 keys, pushing minimalism
further), and hundreds of others catalogued in the awesome-split-keyboards list on GitHub.

However deep you want to go, the trade-off is always the same:

Option	Money	Time
Full package (board + service)	High	Low
Prebuilt	Medium	Low
Kit	Medium	Medium
Electronics kit	Low	High
Full DIY from open-source specs	Low	High

Pick what best fits your situation, not your ambition. And draw on the resources the community offers.

I joined the BastardKB community. I built a Charybdis Nano, a 35-key split with curved key wells and an integrated trackball on the right half, which makes the mouse layer mostly redundant, and separately the Dilemma, a smaller build with integrated trackpad, my first attempt at a portable solution. Building your own keyboard involves soldering, reading PCB datasheets, and creative problem solving. It is objectively a lot of work, but also deeply satisfying.

The Charybdis Nano, for instance, has an asymmetric thumb cluster: three keys on one side, two on the other. To keep the layout symmetric I reduced to two active thumb keys per side, the freed third key dedicated to a mouse click layer, keeping all pointer work on the right half with the trackball. That left high-frequency keys like Escape, Tab, and Caps Lock with nowhere to go. The answer came from a stenography video: steno has solved the same problem for decades, multiple keys pressed simultaneously producing a single action. That's a chord. Caps Word is the clearest example: both shifts together capitalises until the word ends, then turns itself off. The full layout is in the appendix.

Step 6: The Bottom of the Rabbit Hole

By this point, the ergonomic problem is solved. The remaining problem is simpler and more stubborn: the Charybdis Nano doesn't travel. Smaller portable designs exist. The Dilemma and the Chocofi aim specifically at portability, but they're still separate equipment: another thing to pack, unpack, and connect. The laptop is already the one device that goes everywhere. That's where the keyboard should live.

The obvious answer is a keyboard that replaces the laptop keyboard entirely: not a peripheral, but the actual input layer of the machine. The catch: tie the keyboard to a laptop and a new machine means starting from scratch. That's where Framework comes in, fully modular, open specs, right to repair, built for tinkering, with a community that documents everything.

That's what I'm building. A 34-key, column-stagger board running ZMK, designed from first principles for how I actually work, replacing the laptop keyboard, thus going wherever the laptop goes. The constraints are tight, but when successful, I have a board I never have to leave behind.

Look at the Corne, the Totem, the Charybdis, the hundreds of designs in the awesome-split-keyboards list; each one was almost certainly built by someone who walked this exact path and arrived at this exact conclusion. The open-source keyboard community exists because the rabbit hole reliably produces the same realisation at the bottom of it: nothing out there was built for you, so you build it yourself.

Conclusion: What I Know Now

I've had no season-ending injuries since. I can't tell you whether it was the keyboard, the posture, or just time. I'm not sure it matters. The desk stopped working against my training, and that was the point.

One honest regret: the order this article follows isn't the order I followed. I bought the Ergodox before I'd remapped a single key, reached Step 5 before I'd properly done Step 2. The sequence here is the one that makes sense. Do as I say, not as I did.

Most professionals have researched their laptop, their monitor, their chair. The keyboard is the one tool nobody questions, and the one your hands never leave. For something that touches every working hour of a career, that's a strange place to accept the default.

You don't have to be an athlete for accumulated strain to matter. The season-ending injury was my wake-up call, but the underlying problem belongs to anyone who types for work: a keyboard built for a machine that stopped being manufactured a hundred years ago, accepted by most without question.

You don't have to go as far as I did. A different layout, a remapped key, an afternoon with KMonad; for many people that's enough. But start somewhere. The keyboard was never designed for you.

Where to Start

Layout:

A guide to alt keyboard layouts, covers why to switch, which layout to choose, and how the major options compare
Miryoku, the clearest documented minimal layout; explains every decision and runs on any firmware

Software:

KMonad, remap your existing keyboard before buying anything
QMK and/or ZMK, open-source firmware for programmable hardware

Hardware: Ergo Keyboards, filterable list of commercial and DIY
boards

Community: awesome-split-keyboards, open-source builds and
the people behind them

Research:
Wrist and Forearm Posture from Typing on Split and Vertically Inclined Computer Keyboards,
peer-reviewed study on how split keyboards reduce ulnar deviation and forearm
pronation

My Layout

The current layout on all my keyboards is 34 keys: five columns, three rows per finger, two thumb keys per hand (5×3+2). Diagrams are in grid form, but the layout itself is grid-agnostic: it runs on ortholinear, row-stagger, and
column-stagger boards equally.

Left half                     Right half

Base layer (Dvorak Classic):

  '    ,    .    P    Y       F    G    C    R    L
  A    O    E    U    I       D    H    T    N    S
  ;    Q    J    K    X       B    M    W    V    Z
                 _   Spc      Ent  Del


Number layer — Left:

  \    `    [    /    =       .   PrSc  Cut Copy Past
  7    5    3    1    9       .  Shift Ctrl Alt Super
  .    .    .    ;    .       .    .    .    .    .
                 -   Spc    [Ent] Del


Number layer — Right:

 Past Copy Cut PrSc   .       =    /    ]    `    \
Super Alt Ctrl Shift  .       0    2    4    6    8
  .    .    .    .    .       .    .    .    .    .
                 -  [Spc]    Ent  Del


Nav layer:

  .    .    .    .    .       .   Hom  PgU  PgD  End
Super Alt Ctrl Shift  .       .    ←    ↑    ↓    →
  .    .    .    .    .       .    .    .    .    .
                [-]  Spc     Ent  Del


Function layer:

 Reset .    .    .    .       .    .    .    .    .
 F7   F5   F3   F1   F9      F10   F2   F4   F6   F8
  .    .    .   F11   .       .   F12   .    .    .
                [-   Spc]    Ent  Del


Media layer:

 Prv  BrD  BrU  Nxt   .       .   Nxt  BrU  BrD  Prv
  .   VolD Mute VolU  .       .   VolU Mute VolD  .
  .    .   Stp  Ply   .       .   Ply  Stp   .    .
                 /   Spc    [Ent  Del]

Home Row Mods:

Super Alt Ctrl Shift .    . Shift Ctrl Alt Super

Chords:

  Space + O     →  Tab
  Space + U     →  Backspace
  Enter + H     →  Escape
  Enter + N     →  Insert
  Shift + Shift →  Caps Word

Layer access (hold):

  -              →  Nav
  Space          →  Number (right hand)
  Enter          →  Number (left hand)
  Space + -      →  Function
  Enter + Delete →  Media

DEV Community