In 2015, at 15, I designed my own keyboard layout because QWERTY felt structurally wrong. Eleven years later I'm at 213 WPM and still use it every day. Here's the story and what it taught me about design.
I was fifteen in 2015 and I typed a lot. Not in a healthy "I have homework" way — in a "I am online all day arguing about things and writing code for fun" way. QWERTY was just the water I swam in, the same way it is for everyone.
Then I noticed something that I couldn't un-notice.
I was at around 40 WPM and I'd started looking at global typing leaderboards, the way you do when you get competitive about something. India is the world's second-largest English-speaking population. It has over a billion people. And on those leaderboards, India had exactly one person in the top twenty.
One person.
I sat with that for a while. And the question that formed wasn't "how do I get faster on QWERTY." It was: why is QWERTY the assumption?
QWERTY was designed in 1873. The design priority was preventing typewriter jams — the hammers on mechanical typewriters would collide if you typed common letter combinations too quickly, so the layout deliberately separated frequently-paired keys. The human hand was an afterthought. That constraint vanished sometime in the early twentieth century. The layout didn't.
I was fifteen, I had won a gold medal at the International Informatics Olympiad that same year, and I had the specific brand of overconfidence that comes from being good at hard problems. Looking at QWERTY and thinking "this is structurally wrong and I should build a replacement" felt like a reasonable use of a weekend.
It ended up being considerably more than a weekend.
Here's what I actually had access to in 2015: a basic internet connection at a cyber café, enough time, and a dataset instinct I didn't yet have a name for.
The insight that shaped everything was simple: every existing alternative layout — Dvorak, Colemak, Workman — was optimised for English. I am an Indian typist. My daily writing is a mix of standard English, Hinglish (Hindi spoken and written in the Latin alphabet), and Hindi transliterated phonetically into Roman script. The letter frequency distributions are genuinely different. Consonant clusters that almost never appear in natural English are common in Hinglish. If you build a layout from the wrong corpus, you get a layout optimised for someone else's typing.
So the first step was the corpus. I collected real-world samples of my actual writing — the languages and proportions I actually used — and weighted them to reflect what a day of typing looked like for me.
Then I found the Patorjk Keyboard Layout Analyzer, a free online tool that lets you upload a corpus and score different key arrangements against it on metrics like finger travel distance and same-finger bigrams (where you type consecutive characters with the same finger — slower, and harder on tendons). I uploaded my corpus and started moving keys around.
The process looked like this:
The reasoning behind specific placements was explicit: "E goes here because it is the most frequent character in the combined corpus and this position is the fastest physical reach from rest. T goes here because E-T is one of the most common bigrams and this placement puts them on alternating hands." Not aesthetic — mechanical. The analyzer gave me a score, I moved a key, ran it again, checked whether the score went up or down, adjusted. Empirical hill-climbing with a free web tool, because that was what I had.
After enough iterations, X-Type beat QWERTY, Dvorak, Colemak, and Workman on my corpus — on every metric the analyzer measured. That felt like a proof.
The layout had one more unconventional property: two symbol modifier layers, accessed by holding keys that also function as characters when tapped. Every bracket, brace, quote, operator, and programming symbol accessible without reaching for the number row. The disambiguation window — how long you hold before the layer activates instead of the character — is 300 milliseconds, tuned empirically until it stopped firing accidentally during fast typing.
I switched cold. Ninety WPM on QWERTY, then one morning I changed my layout and that was it.
Karanveer Singh Shaktawat
Full Stack Engineer & Infrastructure Architect
Building portfolio, contributing to open source, and seeking remote full-time roles with significant technical ownership.
Pick what you want to hear about — I'll only email when it's worth it.
Did this resonate?
Not productivity hacks — the real psychological battle of shipping code when your brain would rather do anything else.
What 'vibe coding' actually means in practice — my AI toolkit, when it helps, when it hurts, and the meta angle of building this portfolio with Claude.
The first week I could not type a coherent sentence. I had to think about where every single key was. Not think in the background — consciously, deliberately, one key at a time, the way you have to think about every gear change when you're first learning to drive manual. Conversations in group chats took ten minutes. Code that should have taken an hour took most of a day.
There was a specific low point about three weeks in where I sat at my keyboard for a few minutes without typing anything, trying to remember where R was, and thought: this was a mistake and I have broken something I cannot easily fix.
I did not switch back.
Partly stubbornness. Partly because I had looked at the corpus analysis results enough times that I trusted the math even when my fingers didn't yet. Partly because switching back would have meant admitting that the 15-year-old who built a keyboard layout didn't actually know what he was doing, and I was not ready to admit that.
A few months in, I crossed 40 WPM again. A few months after that, I passed where I had been on QWERTY. Then it stopped feeling like a learned thing and started feeling like the only thing.
The current number is 213 WPM, which represents a 136% improvement over the 90 WPM I was at when I switched.
What does 213 WPM feel like? It mostly feels like nothing. Fast typing is invisible to the typist — you're not thinking about the typing, you're thinking about the thought. The ceiling matters when something is slow enough to interrupt the thought. Most QWERTY typists are between 60 and 80 WPM. The average developer is probably in that range. At that speed, there are moments where your hands can't keep up with your head, small fractional hesitations that break the flow of working.
At 213 WPM, typing is not the bottleneck. Thinking is. That's where you want to be.
The honest caveat: typing speed as a raw number matters less than most typing enthusiasts will tell you. A faster typist doesn't write better code. The gains are in the edges — typing out a long search query, writing a long explanation in a PR comment, live-editing a config file while someone is watching. The accumulation of those moments, over years, is real. But it's not the reason I still use X-Type.
The reason I still use it is that it's mine, and it's better for my specific use case than anything else that exists, and I proved that with data in 2015.
For the technically curious, a quick structural picture:
The base alpha layer is a complete 26-key remap — every key on standard QWERTY hardware produces a different character. The most frequent characters in the combined English/Hinglish/Hindi corpus sit on the home row under the strongest fingers. Common bigrams in that corpus land on alternating hands or in rolling same-hand sequences rather than awkward reaches or same-finger repetitions.
On top of the base layer, two symbol modifier keys give access to all programming punctuation without leaving the home row:
Left modifier (hold): [ " ] : ? ( , ) ; ! & | ' \ ^ ~
Right modifier (hold): $ { = } < / > . * % - + ` _ ^ ~Each modifier key is dual-purpose: tap it and you get a character; hold it and you activate the layer. The ^ and ~ characters appear in both layers so either hand can reach them. Physical N is permanently remapped to Escape — a gift to anyone who lives in Neovim.
The macOS implementation runs through Karabiner-Elements, which intercepts key events at the IOKit layer before the operating system sees them. This means the layout works in every context — games, virtual machines, every application uniformly — in a way that a standard macOS keyboard layout bundle cannot achieve, because the symbol modifier layers require conditional state logic that the standard format doesn't support.
The same logical layout runs on Android (a custom keyboard app built in 2016, the first physical implementation), Linux (XKB), and Windows. Muscle memory transfers across every machine.
The meta-lesson is the one I've thought about most.
QWERTY is a universal default. Every keyboard in the world ships with it. Every typing tutorial assumes it. When you ask why everyone uses it, the real answer is: because everyone uses it. The path dependency is the justification.
At fifteen, I looked at that default and decided it was wrong for my specific situation, built evidence that it was wrong, and replaced it with something I designed myself. That decision compounded for eleven years and is still paying off.
The same pattern shows up everywhere in how I work now. I self-host instead of using SaaS when the data matters and the cost is manageable. I chose Rust for Docsee over Go or Node because the performance and binary size characteristics were right for that specific problem. I run Bun instead of Node because I tested it and it was faster for my use case. I build custom MCP servers instead of waiting for someone else to release one for the workflow I need.
None of these are contrarianism. They're the same thing as X-Type: look at the default, ask whether it's actually optimal for your situation specifically, build the evidence, and if the evidence says no — do the work.
The corpus quality is everything. This is maybe the cleanest lesson from the keyboard project that transferred directly into how I think about software. Dvorak and Colemak are genuinely good layouts. They underperformed X-Type not because their designers weren't smart, but because they optimised for a different corpus. An optimisation is only as good as the objective function it runs against. Garbage in, optimal-looking garbage out. I think about this constantly when I'm making architectural decisions or evaluating product tradeoffs: what is the actual objective function here, and is it the right one?
The other lesson is simpler: long bets compound. Three weeks of being unable to type coherently, then months of being slower than I used to be, was the cost of eleven years of compounding returns. The willingness to take that cost — to give up current performance for a long-term gain that the data said was real — is probably the most transferable thing the layout ever taught me.
The fifteen-year-old who built this had no budget, no formal training, no academic resources. He had a dataset instinct, a free web tool, enough time, and the specific stubbornness to not switch back during the hard weeks. That turned out to be enough.
It still is.