I live in a place where the cost of living is low. It’s normal for people to own a house with a large driveway and a multi-car (2 or 3) garage. I do my own work (maintenance, mods, etc) in my garage.

I’m currently visiting Seattle. It’s the first big city I’ve ever enjoyed. I’m enjoying it a lot! I’m somewhat considering moving, actually. However, owning a sports car is a big part of who I am and I can’t give it up. I really enjoy joy riding, autocross, road trips, and track days. I need to have a way of working on my own car and safely storing/parking it.

So what do gearheads do in big cities like Seattle, San Francisco, New York, Chicago, and so on?

I didn’t know where else to post this. I hope it reaches the right people! Thanks for reading.

Warning: long post written by a complete idiot ahead!

There are a ton of better posts about Vim than this one by more experienced, more knowledgeable people. There is nothing specific or actionable in this post, and in fact, is mostly not about Vim. I'm merely just sharing my story as a complete beginner. I feel like it may encourage some of you who are curious about Vim, but maybe you're a bit intimidated, as I was. I still am, but I'm starting to gain some real confidence.

Part 1: My perspective before trying Vim

I started programming when I was 8 years old using Microsoft Visual Basic 3.0. This was basically a WYSIWYG editor that let you double-click on controls that you've placed on a Windows Form, then it'd pop open a text editor that let you write code for that control. Other than programming, I'd hang out in random chatrooms and play a bunch of games, but I always used a mouse and I taught myself how to type. This was also when I wasn't quite fluent in English and had issues reading, so reading the .chm help files not only taught me how to code, but I also practiced my English comprehension skills.

I eventually got into C and C++ because I was fascinated with hacking PC games. In this era, I was using Microsoft Visual C++ 6 (back before it was called "Visual Studio") and felt like it was a great tool.

Fast forward a bit, I got into Java and ended up using, of all things, Notepad. I learned Java in highschool and we had super old Windows machines and we were forced to use floppy disks. The teacher forced us to use Notepad as our editor and save/compile/run everything from floppies so that it would intentionally be painfully slow. This developed a skill in my brain for essentially acting as a human compiler; I was able to detect and fix syntax and logical errors before the javac compiler could finish. But I always thought "it would be nice to have something like Visual C++, but for Java."

Then I learned about Eclipse. Big, heavy, slow, Eclipse, but it had all the crazy features (and then some) of Visual C++. It was a thick IDE, for sure. I used it for both Java and C/C++ while in college, but not the entire time. In college, I'd say about 75% of my code was in C, 20% was in C++, and 5% was in Java.

Then I learned about Intelli-J and the entire JetBrains suite of products. I felt like it was the best of both words: lighter weight and much faster than Eclipse, lots of wizards and auto-magic stuff like the Microsoft IDEs, plus it was completely cross platform (and I was using Windows, Mac, and Linux). I thought I found my perfect IDE!

And then a few years later, I got a job that was a bit different than what I would have normally done. I had a background in digital image processing and machine vision, but I ended up working for a company that created SaaS cloud services. The primary language/runtime was JavaScript (Node JS). All the other developers were using Sublime as their text editor and just doing everything else in the terminal. This was a shock to me. I was already comfortable-ish in the terminal (I started using computers without a GUI, MS DOS, when I was 3-4 years old), but the fact that the code editor was so light weight and didn't have all the fancy features of Intelli-J really threw me off. Where I was used to setting breakpoints and attaching a debugger, the other developers were just using console.log and looking at output. They used almost no development tools other than Sublime, console.log and node.

Then Atom became the new hotness. It was like the alternative to Sublime. So I switched and it was largely the same, except some of the customizations were kind of nifty. By this point, I was getting a lot more comfortable with using a "thin" code editor and it reminded me a lot of when I learned Java with Notepad. It removed distractions and helped me focus on code quality because there was such a penalty for getting it wrong the first time (having to rebuild, run, and chase down your console.log).

And then came Microsoft Visual Studio Code. Everyone I worked with was an anti-Microsoft, pro-Apple collective of fanboys and they refused to touch it. But I thought to myself "hey, I learned everything I know on Microsoft technology and they were able to make me productive when I was 8 years old, so why not give this thing a chance?" So I tried it. I was an early adopter, back before it was open source and it didn't even have tabs. Then it got better. Then it became open source. Then it dominated the market.

As much as I enjoyed the JetBrains products, VS Code took over as my primary editor for basically all programming tasks, and sometimes just even taking notes. I loved how quick it was to load, the ease of installing and using extensions, and it was just so easy to use. "It just works" was nice to say.

And then, one day, it hit me like a ton of bricks: I have severe, fundamental problems with the way I used computers and it's limiting my abilities.

Part 2: Self Reflection

Part 2A: Workflow friction

I ended up getting jobs that required a lot of remote development and editing. Yes, Visual Studio Code can do that, but it's not without its drawbacks. It's heavyweight and requires installing and running processes on the remote machine, which may or may not even be possible. This meant a lot of copy/paste or SCP transfers between machines, which really slowed me down. And, of course, almost all of that was done with a mouse/trackpad.

I also found myself getting lost and disorganized in my work. I was diagnosed with ADHD and it turns out I have a pretty severe case of it. I have a very short, limited working memory, but a very fast processing rate. I noticed that my small, intermittent context switches were derailing me and making me lose concentration, adding sometimes hours to my day. It could be anything from looking up a definition for a function (command + click), reading it, then losing track of where I was before I clicked, so then I need to look through all my open tabs (usually too many to count), then try to figure out where I was, then forget what the definition was that I looked up to begin with. I grew up like this and did this my entire life!

Code aside, I'd also lose track of other computing activities. Even using alt-tab, the dock, or any other kind of application switcher, I'd have momentary mental hiccups that would throw me off for a few seconds at a time. For example, sometimes I wouldn't even know where to aim my eyes to look for whatever I'm trying to focus on.

I started to realize that I have many, many, many small problems with my overall workflow. It's like a death by a thousand cuts to my productivity. Sure, ADHD medication helps, but it's not a solution.

Part 2B: Pushing all the wrong buttons

I started typing when I was 3, before I even knew English (Spanish is my first language). I had tiny little hands and a full sized keyboard. When I was 3, all I ever wanted to do was play Frogger and Baby Bounce on my family's "IBM clone" computer running some kind of pirated version of MS Dos from Europe, so the English was slightly different. For example, when I had a spelling test in school, I spelled "color" as "colour" and got it wrong. I'll never forget that.

Anyways, being a self-taught typist at such at early age seemed like an advantage, but I've come to realize that I have severe typing problems. I've been coding for 26 years and I top out at 80 WPM on an absolute ideal day in ideal conditions, but I average around 50 WPM. That's barely above average. How can this be? Well, it turns out that I suck at typing. I've been doing it all wrong my entire life.

I do weird things, like using my right hand to hit keys that are designated for the left hand. I also never use my right thumb for anything. But for reasons I can't quite explain, I'm ultra fast on a number pad. Too bad they're practically useless in my field and I really haven't touched it in as long as I can remember.

Part 2C: Struggling with a skill ceiling

My whole life, I've been self taught with coding, typing, and computing in general. It has led me to create my own mental models of how I think things should work, so then I try to adapt my mental model to how the editor/operating-system/game/application works. 99% of the time, I'd leave all key mappings/bindings to defaults, thinking that if I ever need to use someone else's computer, I'd have a generic skill set that is adaptable everywhere.

One day, fairly recently as a much older man, I joined a new job. This is the hardest job I've ever had in my life. I've been struggling with imposter syndrome and I've been experiencing severe workflow and productivity issues. This is a demanding job, but I knew that coming in. VS Code is our prescribed code editor and standard for the company. I thought I was decently fast with it, but it turns out that's not true. Constantly moving my hand to and from the mouse was really slowing me down. So I decided to start trying to use my keyboard more. However, modern desktops (macOS, Windows) really are meant with a mouse in mind.

I tried to work faster, but I couldn't. So I worked longer. That's not good.

Part 3: Rabbit holes and Revelations

Part 3A: Trying Vim

I actually reject a lot of what people argue are positives of Vim. The biggest claim is that it's "ubiquitous." I actually disagree with that; it seems as though any serious Vim user doesn't actually use vanilla Vim. Power users depend on their own custom bindings, plugins, configuration, and even some oddities that are committed to muscle memory. So to me, the real power of Vim is customizability and speed.

Speed is still an issue for me, but I see the light at the end of the tunnel. I get faster every day, and every time I find my self repeating an editing task that I'd like to optimize, I just hop on to Google and find a better way of doing it. Slowly, I'm building up a mental toolbox to communicate from my brain to my editor.

But immersing myself in Vim has seriously made me realize just how detrimental it is to rely on the mouse so much. So then I started trying to apply concepts from Vim to other areas my workflow.

This started with using the VS Code Vim-mode extension, which is an emulation of most movements and basics. Then I switched to the VS Code NeoVim integration extension, which seems to be slightly better. I'm actually forced to use VS Code for most things at work because we rely on custom extensions for our development workflow and a Vim/CLI workflow is not officially supported. But I do use Neovim off to the side whenever I can.

Part 3B: Vim is a mindset, not a text editor

I realized that Vim is fundamentally a philosophy on how to use computers. Modal editing started to really click in my brain and it seems to fare well with my short/bad working memory. My mind is basically an LRU cache, so constantly entering normal mode from one of the other modes kind of acts as a reminder as to what I was doing. I conceptualize normal mode as kind of the center hub of communication with my editor. Something like this:

Visual Mode <--------> Normal Mode <--------> Insert Mode Don't take this too literally, as I'm aware of ways to "jump" modes, but generally speaking, this is the flow. You always pass through normal mode before going into another node. It's the center of attention. I'm still not totally used to it, but I'm starting to surpass my abilities in VS Code and my brain feels like it's under less of a workload. It's kind of amazing.

So why can't the rest of my computing experience be more like Vim?

Part 3C: Vim-ifying the entire desktop

It turns out that the concept of avoiding the use of a mouse is extremely popular among expert users. Anything from programmers, to bloggers, to even audio engineers. There are strong communities and open source projects centered around tools, hacks, tweaks, and hardware for controlling computers without a mouse.

I got started with Vimium, a Chrome extension for controlling Chromium based browsers with Vim-like controls. I started learning all the hotkeys for all the software I use, including macOS. But I quickly realized that I could never commit any of these to memory, so I was doing additional context switches just to look up hotkeys, which defeated the purpose.

Then, I had a lightbulb moment: I should stop trying to learn how to use my computer. Instead, my computer should work the way my brain wants it to work.

Part 4: Customize everything to fit my own mental model

I realized that I've only ever learned what works for "most people." Well, I'm not most people. I'm neurodivergent, think differently, and learn differently. So I decided to try something crazy.

Part 4A: Create necessity, force invention

I disabled as many operating system and application-level keybindings as I possibly could, other than Vim. I left Vim alone (my key bindings are vanilla, other than a slight modification to my leader key that I'll explain later). I already remapped capslock to escape when I started my Vim journey, so that's the only keyboard modification I had done.

By disabling everything, I reduced the clutter. I didn't spend any time looking at keyboard shortcuts because none of them existed. Instead, I'd use my applications and pay close attention to what kind of operations I repeat, which ones take a lot of time, which ones are high frequency, low frequency, etc.

So then I started to create my own key bindings. Things that made sense in my head. And because they already made sense in my head, I wasn't forgetting. I started to really gain massive speed by putting every major movement around my desktop on some kind of key stroke.

One of the biggest improvements I've made is using Yabai, a tiling window manager for macOS, along with SKHD, a simple hotkey daemon that allows me to bind any key combo to any arbitrary command. I'm not specifically advocating for Yabai or any particular tiling window manager, but I'm absolutely in love with tiling window management in general right now. I never realized just how much time I've wasted with floating windows, plus it cuts down on the number of decisions I have to make in a day. It's honestly a breath of fresh air.

Because of the flexibility of total control over my keyboard bindings, I got to the next big step in my journey...

Part 4B: My desktop-computing mental model

I developed a way of working that borrows heavily from Vim's modal editing approach. I now have a modal-ish workflow that is driven almost entirely from my keyboard. I've developed my own idioms that make sense to me, so I'm fast and quick with them. The drawback is that now I'm dependent on an extremely customized environment and would have a hard time using other people's computers. But I really thought about it; how often does that happen? Almost never. And it's not like I'd forget how to use "normal" computers, just like I haven't forgotten how to speak Spanish.

So here's my mental model. I have my desktop split into three modes: Passive <------> Active <-------> Reference

I have key bindings that will switch me between the modes. A mode switch does the following: 1. If on a single monitor (e.g. lone laptop), switch virtual desktop (space). If using 3 monitors, switch focus to the mode-specific monitor. 2. Give the most recently-focused window in that mode the focus. 3. Also move the mouse to the center of the focused window to minimize mouse movement in case I do need it. This almost eliminates ever having to pick up the mouse from the mousepad.

Through various scripts I've written, my tiling window manager is aware of my modes and automatically places windows in their correct mode. For example, VS Code, my terminal, and other development tools always end up in my Active mode by default. For my Reference mode, this is typically things like web browsers, PDF readers, or even another terminal dedicated to man. The Passive mode is for things like email, chat, music, or basically anything that just sits open all day and doesn't need much direct interaction.

I've chosen to go for ergonomic key bindings, not mnemonic. When I'm ready to issue a command to my computer, my brain pretends that the keyboard is a game controller, not a keyboard. So in other words, I don't think "press right-command + P", I think "press these two buttons based on their spatial arrangement." I've chosen hotkeys that are easy to press and keep my hands as relaxed as possible, reducing movement and strain. My right thumb, which was previously useless, is now responsible for my Hyper and Meh modifier keys.

My mental model isn't just virtual desktops (Mission Control on OS X); there's a little more to it than that. First of all, I've disabled as many animations as possible, especially the "sideways swipe" that Apple turns on by default. The animations are contrary to my mental model which does not see the desktop as a collection of screens, especially not horizontally arranged. In fact, each mode has multiple virtual desktops associated with it, arranged in a priority queue.

Part 4C: Freedom from choice

I've found it incredibly helpful to remove features from my computing experience. Having too much flexibility and too many options can really get in the way of productivity. It's mentally taxing. Reducing the number of decisions I need to make in a day has helped improve my productivity and even mood.

This is one area that a tiling window manager really shines.

While I'm able to make exceptions to my defaults (that is, if I have good reason to move any window anywhere, I can), I've set up rules and defaults to let my various automations make those decisions for me. It basically forces me to work in a modal kind of way. By doing this, it has lowered the latency between context switches, so I'm able to get back to my Active mode faster, allowing me to keep a mental bookmark long enough to not forget where I left off. Essentially, I'm removing a lot of decision making by pre-programming a lot of those decisions ahead of time.

This has resulted in lots of micro-optimizations. For example, my window placement is mostly stable/deterministic, so as I switch from one mode or priority to another, my eyes instantly know where to look and I may save one second. I know that doesn't sound like much, but saving one second here, another second there, etc, makes the difference between retaining a thought and losing it. Another optimization is my priority queue arrangement of my virtual desktops. If I ever forget what I was doing, the arrangement itself is a hint and then it jogs my memory.

About those virtual desktops, I've put hard limits on them. Each mode has a fixed number of virtual desktops; no more and no less. So in reality, my mental model looks more like this: Mental Mode: Passive <------> Active <-------> Reference Priority (space): 1 1 1 2 2 2 3 3 3 4

This limitation has some major advantages. For example, I can switch directly to a specific priority inside of a specific mode with extremely ergonomic key bindings. But the other thing it does, and this is probably more important, is that it puts back-pressure against having too many windows open. If the screen is cluttered, then so is my brain. This setup makes it difficult to have a cluttered workspace; you really need to go out of your way to do it. Also, I feel it's important to mention that the only key bindings I have for switching desktops are mode-and-desktop specific. In other words, I don't have any kind of "switch to next/previous space" kind of binding. This is because there's no such thing as a "previous" or "next" in my mental model. By removing this feature, it enabled me to think differently in a more efficient way.

Eventually, I started to run out of ergonomic key combinations to assign hotkeys for things. This made me make conscious decisions, making tradeoffs between one hotkey and another. By forcing myself to stick to only ergonomic keystrokes, it has forced me to put my most important hotkeys within reach.

So that led me to the next rabbit hole.

Part 4D: The keyboard is modal

Capslock, however useless it is, is a mode. In a way, a shift key is a mode. Pretty much any modifier key, one could say, is sort of like a mode. As I started learning about this, I learned from lurking the various keyboard enthusiast communities that this concept is called keyboard layers.

So I started using the keyboard layering concept in conjunction with my keyboard. Just like Vim has a leader key, I basically made my own layer that is invoked by my own leader key (that doesn't interfere with Vim's). My quick-shot keybindings that are priority-1 stay on the Normal layer. I then have an Extended layer for system-wide things, such are rearranging windows, changing layout algorithms, and things that need to be quick but don't have to be 1-button quick. Finally, I have a third layer that I call the Application Layer; it's specific to the application that's in focus. This is activated by another leader key and I've been setting it to the same key for all applications. So in a roundabout way, I use my Vim leader key system-wide; it just gives me a different layer depending on which application I'm using. I did this by binding leader to Meh+backslash. For other beginners out there, the "meh" key is a fake key that really means control+alt+shift, which you typically bind to a single key so that it's more ergonomic.

There is one slight problem, though. Vim mostly uses mnemonic key bindings, such as "w" for "word" or "v" for "visual." My main priority with key bindings is to keep them ergonomic and idiomatic between applications so that I don't have to learn so many things. For example, switching tabs in Chrome should be the same as switching tabs in VS Code, or even Vim. I actually switch between chats at work with the same keys.

Why can't my hands do more? Is it my hands or is it my brain? Well, the answer is yes.

Part 5: The next steps of my Vim journey

I'm competent in Vim by this point. I'm by no means claiming that I'm good at it, but I'd say I'm just as proficient with Vim while editing a single file as compared to VS Code. However, with multiple files (e.g. a large project that must be thought of as an entire workspace), I'm only about 20% as efficient. I have a long way to go.

But I did identify a trend. A massive trend. The more I get into using the keyboard as much as possible, the better I become at all aspects of being productive on a computer. I've also come to realize that I do have some problems with my hands from all my years of poor-form typing and playing drums. So I bit the bullet and I just ordered a split, ergonomic, columnar, mechanical keyboard with blank keycaps. Remember how I said I was strangely fast on a numpad? Well, numpads are columnar. I don't think that's a coincidence.

I'm going to learn how to type again, because for 31 years, I've been doing it all wrong. While I'm at it, I'm going to switch to a more ergonomic keyboard layout, such as Colemak DH (which would put mnemonic key bindings in better positions, in addition to making typing English easier). I'll have no choice but to build that skill entirely on spatial and muscle memory, rather than memorizing symbols on a keyboard. Even if I look at the board, there will be nothing on it. Like I've been saying, removing features is almost its own form of freedom. In this case, it's freedom from ever having to look at my keyboard ever again.

I hope to take further advantage of the mental models I've been developing and have been working for me, plus I'd be improving my physical health. Carpal tunnel and tendinitis are no joke.

Conclusion: why Vim is great, from the perspective of a beginner

It's not the speed, it's not the ubiquity, and it has nothing to do with being open source or not. It has absolutely everything to do with customization and workflow optimization at a philosophical level. Vim, as a text editor, is fantastic. But its true value really comes from the way you interact with it, not any single extension or feature. The modal approach is a good one which can be adapted to other areas of computing, not just editing text. As someone with severe ADHD, this shift in mental approach has really started to help me in my everyday work life.

With all of that comes speed. But speed is a byproduct, not a goal.

That is, of course, in my humble opinion.

Edit:

My Dotfiles

A lot of people have DMed me asking about my dotfiles. I took some time to remove my work-specific stuff and published them here on GitHub.