I like to be fast. I like to code fast. I like to press two keys and refactor the name of a function across an entire repository. I like Treesitter. I also like LSPs. And most importantly, I use vim btw.
As an engineer, one of your main jobs is keeping multiple concepts in your mind, letting them slosh around up there until eureka strikes, and ultimately, knowing precisely where to find or insert those nebulous concepts as code. Being able to locate and fire those fresh concepts with the precision of a AGM-114R9X Hellfire missile is a core capability of being an effective engineer. If people argue that engineers should spend time honing soft skills, I can also squeeze in my argument that there’s room for engineers to improve their mastery of their IDE/text editor1.
I do think that a certain enchantment with LLMs comes from devs that just can’t… code… fast. 2
My philosophy for moving fast across my codebase without breaking things revolves around a hierarchy of “most recent access”:
Fastest ──────────────────────────────────────────────── Slowest
<C-^> <C-o/-i> <leader>1-4 gd/gr <leader>fo <C-P>/<C-f>
│ │ │ │ │ │
│ │ │ │ │ └─ Global search
│ │ │ │ └─ Recent files
│ │ │ └─ Semantic (LSP)
│ │ └─ Working set (Harpoon)
│ └─ Jump history
└─ Last buffer toggle
- jumping to last place visited / last buffer is faster than fuzzy-opening that buffer
- jumping between 3 files (
handler.go,handler_test.go,main.go) using harpoon is faster than tabbing and shift-tabbing through my open buffers - jumping between definition and reference using the LSP is faster than
live_grep-ping for the function name - using
]fto semantically jump between functions and]cto semantically jump between classes is faster than20jor<C-d> - if all else fails, we can fuzzy search for strings or file names
As you can see, I never mentioned marks. That’s because I don’t use them. Maybe I should, maybe I will. When will I use marks?
If you want to start on your journey to being a text editor badass, not just some IDE scrub, try to change your habits around your editor usage to follow the above principle. If you need help with this habit formation, for vim users m4xshen/hardtime.nvim is a very helpful plugin that will force you to use more efficient vim movements by literally blocking your ability to use inefficient ones.
As always, my dotfiles are available on Github if you want to peek at my setup.
This is an idea that ThePrimeagen put into words for me, but I’ve been doing since my first internship, i.e. I’ve been obsessing over vim before it was cool ↩︎
Yes, I do understand that coding agents are more than glorified refactoring tools, but that doesn’t stop people from wasting tokens asking Claude to do what they could do with a bit of elbow grese and muscle memory ↩︎