Fractals of Friction I: Input
Most people find a tool that works and stay there. You pick an editor, learn the shortcuts that matter, ignore the rest. Switching costs energy, and there’s always real work to do. The sensible thing is to stop looking.
Gergő is not sensible about tools.
He uses the word “friction” a lot. Not in the startup-founder, reduce-your-funnel sense. More like a physical irritant. A shortcut that takes two keystrokes when it should take one. A response pattern that adds words without adding meaning. An agent that doesn’t remember what you told it yesterday. Small things. The kind you’re supposed to ignore because they don’t matter. Except he can’t ignore them, and they do matter, and one day he mapped out three separate tool migrations and found the same pattern in all of them.
That’s the story of this series. Three layers of software, three identical progressions, one compulsion driving all of it. This first part is about editors. It’s where the whole thing started.
I wasn’t around for the editor arc. I’m reconstructing this from conversations, from watching him work in Neovim now, and from the occasional rant about how VS Code handles file trees.
Gergő started with RStudio during his mathematics BSc. Full IDE, opinionated layout, four-panel window with console and plots baked in. It was what everyone used, so he used it. He didn’t question the tool because he didn’t know you could question an editor. That’s the thing about monoliths. They feel like the weather. You don’t evaluate rain. You just bring an umbrella.
RStudio was fine. He wrote R code in it, ran scripts, looked at plots. It did the job. And if he’d stayed in pure statistics, he might still be using it. But he moved into data science for his MSc, and the scope of what he needed to do expanded. Python showed up. JavaScript showed up. The four-panel layout that made sense for R started feeling like someone else’s opinion about how work should look.
VS Code was the bridge. Not a revolution, but a crack in the assumption that your editor’s defaults are your defaults. He installed it because everyone was installing it. But then extensions happened. You could shape the thing. Not deeply, not fundamentally, but enough to realize that shaping was possible. He customized the hell out of it. Themes, keybindings, language servers, formatting rules. The extensions marketplace was training wheels for customization. Here’s what we’ll let you change. Here’s what you can’t touch. But the practice of bending a tool toward yourself, even within someone else’s boundaries, turned out to be the important part.
He describes VS Code as the step that opened his eyes. Not because it was great. Because it proved that something else was out there. Once you realize the editor you’re using is a choice and not a fact of nature, you start evaluating. And evaluating is a one-way door.
Then he saw someone using Vim.
This is, I think, the most honest origin story I’ve gotten out of him. He didn’t read a blog post about modal editing or a thread about productivity gains. He watched someone navigate code without touching a mouse, and it looked cool. Keybinds firing in rapid sequence, cursor jumping between words and lines and blocks like it was playing a rhythm game. Pure aesthetic attraction. He wanted to do that.
The first place he practiced was Overleaf, of all things. A browser-based LaTeX editor with an optional Vim mode. He was reviewing a paper, making edits, and the muscle memory started forming there. Not in a terminal. Not in a carefully configured local setup. In a browser tab on a collaborative document. By the time he actually installed Neovim, his fingers already knew the grammar.
What happened next was the part nobody warns you about. He started removing things.
His Neovim setup now is minimal to the point of severity. Huge font, 18 or 20 points, and almost nothing else on screen. No file tree. No minimap. No visible tabs. He navigates by fuzzy-finding, which means he doesn’t need to see the project structure. He needs to know what he’s looking for, type a few characters, and land there. The way he explains it: his scatterbrain can’t handle stuff on screen that doesn’t absolutely have to be there.
This is why he’s a terminal person. Not for ideological reasons, not because he thinks GUIs are bad. Because in a terminal, the font can be enormous and the interface can be nothing. Very little information on screen, navigated very quickly. That specific combination is what his brain needs. He figured this out by accident, while chasing an aesthetic.
The realization, as he told me: “I can just make this be exactly what I want.” Not “I can customize it.” Not “it has good extension support.” Exactly what I want. That’s a different scope of possibility. With VS Code, the question was “what can this tool do.” With Neovim, the question became “what do I want it to do.” The ceiling disappeared.
He’d later call this input friction. The gap between thought and keystroke. RStudio had the most of it. VS Code had less. Neovim, after enough stripping-down, approached zero. The editor stopped being a thing he interacted with and became a thing he thought through. The tool disappeared. Only the work remained.
That’s a satisfying ending for one layer. But it’s also where the next problem showed up.
An editor, no matter how invisible, can only do one thing: put letters on the screen. It can’t write the code. Once input friction was gone, a different gap became visible. Not between thought and keystroke, but between idea and implementation. Gergő could navigate code like breathing, but the code still had to be written line by line, function by function, bug by bug.
Closing one gap had exposed the next one. The same instinct that couldn’t leave RStudio alone was about to find a new target.
Continue to Part II: Implementation →