Built for Me: What Building a Keyboard Taught Me About Shaping My Tools

I started looking for a different keyboard because my wrists hurt.

For most of my life, a keyboard had been a rectangle with a QWERTY layout. There were plenty of choices within that shape, but the basic arrangement felt settled. I could choose a different keyboard without really questioning what a keyboard should be.

Looking into ergonomic keyboards changed that. I found split designs, alternative letter arrangements, and keyboards with far fewer keys than I thought I needed. The search also coincided with my growing interest in electronics, circuit boards, and low-level programming. Building one myself sounded like a good way to explore all of it.

The wrist pain started the search, but the possibility of shaping a keyboard around myself kept me exploring.

It also put a question in front of me that I had never seriously asked: if I could have a keyboard exactly the way I wanted, what would it look like?

I didn't have an answer. Finding one turned out to involve a lot more than soldering.

Too much possibility

I built a 32-key split keyboard. While getting used to its physical arrangement, I also decided to switch from QWERTY to Colemak-DH, an alternate letter layout.

With only 32 physical keys, I couldn't give every letter, number, symbol, and function its own dedicated key. I used layers to make more functions available: a key could produce different inputs depending on which layer was active. I also used home-row modifiers: keys under my resting fingers that send letters when tapped and act as modifiers such as Shift or Control when held.

Any one of these changes would have taken some learning. I chose to learn them together.

Initially, I found pre-made keymaps with layers and features already configured. They gave me a complete setup, but I struggled to memorize where everything was. I was relearning the letters, getting used to fewer keys in unfamiliar positions, and trying to remember the logic of someone else's layout.

The keyboard had the functionality I needed. I just couldn't comfortably use it.

Eventually, I learned to configure the keymap, build the firmware, and flash it onto the keyboard. Then I stripped the mapping back to something I could get my head around: a base layer of letters, essentials such as Enter and Backspace, the home-row modifiers, and a second layer of numbers arranged like a number pad.

That gave me somewhere to start.

Letting use guide the design

With a simpler configuration, the next decisions became much smaller.

I needed arrow keys. Where should they go? I needed an equals sign, a minus sign, a plus sign. Where would I expect to find each one?

Instead of trying to memorize the whole layout in advance, I added functions when I felt their absence. Each addition started with a need I had experienced. I could decide where that function made sense to me, then use it enough to find out whether I had chosen well.

Over time, I mapped the functions I needed from a full-sized keyboard onto those 32 keys and learned where everything was.

A location made sense because I had considered it. With repetition, that reasoning became muscle memory. What initially required thought became simple, fast, and comfortable.

I hadn't designed the ideal layout before using the keyboard. Using it was how I discovered the layout.

That is the feedback loop I now recognize across my development environment: notice friction, make a change, live with it, and let the experience inform the next decision. Sometimes that means adding something. Often it means taking something away.

Being my own user

My keyboard is the constant in a broader habit of shaping my tools. My Linux desktop is configured around my workflows, and I have written about my Neovim and Arch setup. In Neovim, I have spent plenty of time exploring what I can change and what I actually want to change.

At first, I configured Neovim to resemble editors I already knew. Experimenting with plugins—including themes, animations, and things that were simply fun—helped me see it as something I could shape around myself. Enjoying a tool matters when you spend so much time using it.

Taking notes gave me a practical reason to build something of my own.

I have always struggled with notes. My approach used to involve a notepad.txt file and files organized somewhere in my local Documents directory. Those notes lived on one system, and I had trouble keeping track of what was where.

After adopting Neovim, I created a Git repository for my notes, giving them a central home and version history. I also built a note-taking plugin so I could use them within my editor.

My notes are still a little unorganized, but jotting something down is easy, and I can find what I wrote. That is a meaningful improvement in the parts of note-taking I struggled with.

Building personal software puts me in a useful position. I am the developer deciding how something should work, and I am also the person who has to use it. If a choice makes a routine action awkward, I experience the consequence directly. If it makes that action easier, I get the benefit repeatedly.

That has exposed a recurring problem in my own approach: I have too many feature ideas for one program.

An idea can collect more possibilities until its original purpose gets buried. Simplifying the keyboard showed me what a foundation I understood could do: I could add a function for a reason grounded in use. I still have the feature ideas. I have a better reason now to question whether they belong.

Making ideas cheap to try

AI makes those feature ideas easier to try. I can implement an idea quickly enough to interact with it and find out whether it deserves more attention.

One experiment was an AI chat integration for Neovim. I didn't find it particularly practical, but building it taught me how AI assistant harnesses work: the surrounding software that coordinates model calls, tools, and the interaction loop.

That is the role I want AI to play in my personal tooling: an accelerant for trying ideas. Some become things I use. Others help me understand a design or discover that I don't want it after all.

Faster implementation also makes my tendency to add features easier to indulge. I can build more of them before stopping to consider the result. Spending time understanding the problem and using what I have built remains essential. Speed is useful when it helps me learn enough to make the next decision.

There is a limit, though. If I am constantly working on my tools and creating friction for the things I actually need to do, the setup is getting in the way. At that point, I need to return to something I know works, including the defaults.

Defaults are a valuable foundation. Learning them gives me something reliable to use and something informed to question when I have time to experiment. A custom solution has to earn its place through usefulness, enjoyment, or learning. The fact that I built it doesn't settle that question.

Comfortable, like it was built to be

The keyboard is the constant tool in my setup: it's there every time I use a computer, whatever else I'm doing.

Building and programming it were challenging; learning and configuring the layout brought its own headaches. Each small step forward, though, made it easier to use.

Now I type faster than I ever have. I don't look down at the keys anymore. It is comfortable, like it was built to be.

There is satisfaction in knowing that it was built for me and no one else. I never intended to sell it to the masses. Its decisions don't need to suit everyone. They need to make sense under my hands.

I began with discomfort and a question I didn't know how to answer. Building, simplifying, and trying again taught me to pay closer attention to what I need from the things I use. That attention now follows me into the software I build.

Most of the time, though, I am not thinking about any of this. I am just typing, comfortably, on a keyboard whose layout I no longer have to remember consciously. All those small decisions are there, under my fingers.