Over time, I've realized that programming consists of two things: thinking about what code needs to be written, and mechanically writing that code. I've also realized the first part is a lot more fun for me than the second. I love reasoning through problems but dislike the physical act of writing the code that solves them.
This is analogous to how skill is described in video games, which split it into strategy/macro and execution/micro. In League of Legends, for example, a player with excellent micro may be able to get up to the 90th percentile but plateau because their high-level vision for the game is wrong. Similarly, if they know what plays to make but don't have the dexterity, reflexes, and muscle memory to execute them, they will also plateau.
Genesis
For a long time, I used to game on a trackpad. Because of this, my 'micro' was terrible in every game I played. I would lose every fight in Minecraft, toss projectiles backwards in League of Legends, and generally just have a bad time. I compensated by playing games with obscure mechanics and using pacifist strategies like camping, which revolves around waiting for everyone else to die so you can pick off the survivors like vultures.
At some point, I invested in a mouse because I realized you literally couldn't play shooters without one. A trackpad doesn't let you right and left click at the same time, wholly making scoping impossible. Within weeks, I was already better than I had ever been with a trackpad. In an effort to play catch up with my gamer friends, I became obsessed with aim trainers, which promised to improve mouse skills via drilling them. It worked, and I became great with a mouse.
This obsession with gaming micro and my dislike of the 'micro' of coding has led to a pseudo-obsession with optimizing my coding setup. This includes my editor, editor settings, keyboard, and to a lesser extent my mouse.
The Journey to Better Micro
In high school, I used to use JetBrains for everything. I had toyed around with Atom, and hated how slow and awkward using plugin-based text editors was. This dislike has continued to this day and is partially why I've never really used VSCode.
JetBrains was fast, and as an IDE it came with lots of really useful tools. Over the thousands of hours I spent building random projects in high school, I learned the ins and outs of refactoring, searching, debugging, etc. with it. Even better, I could switch languages seamlessly and my muscle memory worked between all the JetBrains IDEs.
In college, I wanted to apply my optimization of gaming micro to programming to make it more fun. I debated between learning Emacs and Vim, and ended up going with Emacs because it was programmable via Lisp. I had an obsession with Lisp after one too many Paul Graham articles and figured this would be a good way to get exposure. I also thought the idea of having to press 3 keys just to type a character in Vim was ludicrous (insert mode -> character -> esc).
Over months, using Emacs made editing a lot easier for me. I gradually used my mouse less and less and the keyboard more and more. My trick was to use Emacs "to-frustration" each day. I would use Emacs until I got really frustrated by feeling slow, then switch to JetBrains for the rest of the day. This taught me the editor without risking burnout. Emacs infamously requires heavy usage of the control key. By swapping escape and caps lock in Mac settings, I didn't have to worry about pinky pain ("Emacs pinky").
I later switched to Spacemacs after reading about it on the internet. Spacemacs is a heavily modded version of Emacs designed to add a bunch of useful plugins and provide hybrid Vim editing in Emacs. Via Karabiner Elements, I was able to get my caps lock key to dually work as a control and escape key so I could swap between Vim modes and still use Emacs shortcuts. The benefit of Spacemacs is that users get a superset of the functionality of Emacs and Vim, which is hyper-efficient for coding. Spacemacs comes with hundreds of new keybinds that I slowly learned over time. At this point, writing code started to feel painless and enjoyable rather than a chore. If I wanted to edit my code in any reasonable way, there was an intuitive combination of shortcuts that could do it for me.
At a new job, I found people using all sorts of weird and non-standard keyboards and it really inspired me to look at new keyboards. I ended up buying a Kinesis Advantage 360, which has several benefits over a standard keyboard. It's split, which makes it more adjustable. It's also curved, which provides excellent wrist support and is a more natural position for most hands. It has an adjustable tilt to prevent wrist strain. It comes with a thumb cluster that makes 2 keys easily accessible to each thumb (instead of 0.5 - spacebar). Finally and most importantly, it's wholly hardware remappable via ZMK, an API for advanced keyboard hardware reprogramming.
I jumped at the chance to reprogram my keyboard and make tricky keys to hit a lot easier to reach. The con of using Spacemacs over a standard editor like VSCode is that all the modifier keys get used constantly. To counter this, I've dual bound all my modifier keys to the home row. For example, tapping the F-key signals an 'f', but holding it signals a shift code. In addition, on a standard keyboard many symbols are really hard to type, such as curly braces. To streamline typing symbols I made my keyboard itself modal. For example, if I click a thumb key, the next key I type is treated as a symbol. So 'a' might become =, 's' is remapped to +, etc. Not having to move my hand to hit escape, control, command, backspace, underscore, etc. has drastically improved my typing speed when coding.
If this has piqued your interest in optimizing your coding mechanics, I'd highly recommend starting by learning Vim. In addition to all major editors, a surprising number of sites have integrated Vim natively, including LeetCode, Jupyter Notebooks, and Reddit.
Aside on AI
Someone might say optimizing for micro is becoming redundant because of AI, which can take over a lot of the tedium of writing code. I agree in some cases: code that is frequently written, full of boilerplate, etc. should absolutely be automated via LLMs. However, niche fields, novel algorithms, weird languages and such cause LLMs to produce gibberish at a high rate. As I code mostly in these spaces for my jobs, which use obscure languages, niche business logic, and closed source libraries, I've found that writing code classically is (for now) much more efficient than using AI.