In Rust We Trust 🦀 - productivity

Why Vim Felt Inevitable

Nikolai Shelekhov — Tue, 03 Feb 2026 00:00:00 +0000

I didn’t switch to Vim because it was trendy.
I switched because everything else started to feel wrong.</p>

It Started With Friction</h2>
Over time, I became increasingly sensitive to small inefficiencies:</p>

Reaching for the mouse</li>
Breaking typing flow</li>
Context switching between tools</li>
UI-heavy editors fighting my focus</li> </ul>
Individually, these are minor.
Collectively, they compound.</p>
As someone who cares about systems performance at the kernel and runtime level, it felt inconsistent to tolerate inefficiency in my own development workflow.</p>
The Ergonomics Shift</h2>
The turning point wasn’t Vim itself — it was ergonomics.</p>

Moving to compact keyboards</li>
Optimizing for home-row typing</li>
Reducing hand movement</li>
Eliminating unnecessary reach</li> </ul>
Once you train your hands to stay anchored, the mouse becomes an interruption.</p>
Traditional editors assume pointer interaction. Vim assumes intent expressed through motion.</p>
That difference is fundamental.</p>
Modal Editing and Systems Thinking</h2>
What clicked for me was this:</p>
Vim treats text editing like a language.</p>

Verbs (`d</code>, c</code>, y</code>)</li>`
`Motions (w</code>, }</code>, t(</code>)</li>`
Objects (iw</code>, ap</code>, etc.)</li> </ul> You compose actions instead of triggering commands.</p> That composability mirrors how I think about system design:</p> Small primitives</li> Clear contracts</li> Composable building blocks</li> Zero unnecessary abstraction</li> </ul> It felt closer to Rust than to an IDE.</p> Why Neovim (Not Just Vim)</h2> I eventually moved to Neovim for practical reasons:</p> Native LSP integration</li> Async plugin model</li> Lua configuration</li> Tight terminal integration</li> </ul> I wiped prebuilt configs and built my setup from scratch.</p> Not because prebuilt configs are bad — but because understanding your tools matters.</p> When your editor becomes infrastructure, you should know how it works.</p> The Real Benefit</h2> The biggest gain wasn’t speed.</p> It was flow.</p> Fewer context switches</li> No mouse dependency</li> Terminal + editor unified</li> Predictable behavior</li> </ul> The editor stopped being a UI and became an extension of intent.</p> Is It For Everyone?</h2> No.</p> Vim has a learning curve. It requires patience. It requires deliberate practice.</p> But if you:</p> Care about ergonomics</li> Think in composable primitives</li> Prefer keyboard-driven workflows</li> Enjoy understanding your tooling deeply</li> </ul> Then it may feel less like a choice — and more like inevitability.</p>



How I Keep Up With Tech Trends
Nikolai Shelekhov — Thu, 15 Jan 2026 00:00:00 +0000
“How do you follow all the tech news and programming trends?”</p>
I sometimes get this question in interviews.</p>
My answer is simple:</p>
RSS.</p>
Yes — that “dead” technology from the 2000s.</p>
Why RSS Still Wins</h2>
Modern content consumption is algorithm-driven:</p>

Infinite scroll</li>
Engagement optimization</li>
Notification loops</li>
Recommended content you didn’t ask for</li>
</ul>
The result is noise.</p>
RSS flips the model.</p>
You choose the sources.
You get the updates.
Nothing else.</p>
No ads.
No ranking algorithms.
No engagement tricks.</p>
Just a chronological stream of content you explicitly subscribed to.</p>
What Most People Don’t Realize</h2>
Most technical platforms still publish RSS feeds:</p>

Tech blogs</li>
Documentation sites</li>
Security advisories</li>
GitHub releases</li>
YouTube channels</li>
Reddit communities</li>
Mastodon accounts</li>
</ul>
RSS never died.
It just stopped being marketed.</p>
My Setup</h2>
I use News Explorer</strong> as my primary reader.</p>
It supports:</p>

RSS feeds</li>
YouTube</li>
Reddit</li>
Mastodon</li>
Bluesky</li>
Podcasts</li>
</ul>
Everything syncs via iCloud across devices.</p>
No external accounts.
No cloud dashboards.
No algorithmic layer.</p>
Just folders and feeds.</p>
Scale</h2>
I currently track 6,000+ articles across:</p>

Rust</li>
Polkadot</li>
Solana</li>
Security advisories</li>
Systems programming blogs</li>
General software engineering</li>
</ul>
All organized.
All searchable.
All in one place.</p>
It replaces:</p>

Dozens of open tabs</li>
Social media scrolling</li>
Random bookmarking</li>
“I’ll read this later” lists</li>
</ul>
The Real Advantage</h2>
RSS creates a pull-based information system.</p>
You are not fed content.
You poll your sources.</p>
This small inversion has large consequences:</p>

No FOMO</li>
No engagement pressure</li>
No missing updates because an algorithm deprioritized them</li>
No context switching into unrelated content</li>
</ul>
It is closer to how engineers think:</p>
Deterministic input.
Controlled sources.
Minimal noise.</p>
When It Makes Sense</h2>
RSS works best if:</p>

You care about specific ecosystems</li>
You follow technical releases closely</li>
You want signal over volume</li>
You value focus over discovery</li>
</ul>
It is not optimized for entertainment.</p>
It is optimized for clarity.</p>
Final Thought</h2>
If you feel like you are drowning in tabs,
or missing important updates because a feed decided they were “low engagement,”</p>
try RSS.</p>
Sometimes the most boring technology
is the most effective one.</p>


Running Multiple Claude Instances in Parallel
Nikolai Shelekhov — Fri, 12 Dec 2025 00:00:00 +0000
The first time I waited twenty minutes for Claude to finish implementing a feature — only to realize it went in the wrong direction — I thought:</p>
There has to be a better way.</p>
There is.</p>
Instead of running one AI assistant sequentially, I run multiple Claude Code instances in parallel. Each works on the same problem in isolated git worktrees. When they finish, I compare results and keep the best parts.</p>
The Core Insight</h2>
AI assistants are not deterministic.</p>
Same prompt.

Same model.

Different results.</p>
Sometimes the first attempt is excellent.

Sometimes it drifts.

Sometimes it confidently builds the wrong abstraction.</p>
If you work sequentially, each attempt is a gamble.

You wait, evaluate, retry.</p>
Parallelizing removes the waiting loop.</p>
Why Git Worktrees</h2>
Branches alone aren’t enough. They are just pointers.</p>
Git worktrees create:</p>

Separate working directories</li>
Each with its own checked-out branch</li>
Sharing the same repository history</li>
</ul>
That means you can have multiple implementations evolving simultaneously without stashing or context switching.</p>
Same repo.

Same base commit.

Multiple active solutions.</p>
My Workflow</h2>
I use a small helper command:</p>
git parallel "add-auth" --agents 3</span></span></code></pre>
This:</p>

Creates three worktrees:

add-auth-1</li>
add-auth-2</li>
add-auth-3</li>
</ul>
</li>
Launches Zellij</li>
Starts Claude Code in each pane</li>
</ol>
Then I:</p>

Give each instance the same prompt</li>
Let them run in parallel</li>
Come back later to compare outputs</li>
</ul>
What Happens in Practice</h2>
Typically:</p>

One implementation is overengineered</li>
One misses edge cases</li>
One is clean and well-structured</li>
</ul>
Sometimes:</p>

Each has a strong idea worth keeping</li>
The final solution becomes a synthesis</li>
</ul>
Instead of restarting the same assistant three times, I evaluate three candidates.</p>
Total elapsed time is roughly the same as one attempt.</p>
The quality of outcome is consistently better.</p>
Where This Works Best</h2>
This approach shines when:</p>

Designing new features</li>
Refactoring complex modules</li>
Exploring architectural directions</li>
Working in ambiguous problem spaces</li>
</ul>
It is unnecessary for:</p>

Small bug fixes</li>
Mechanical changes</li>
Deterministic tasks</li>
</ul>
Parallelization only makes sense when multiple valid solutions exist.</p>
The Mindset Shift</h2>
The mistake is treating AI as an oracle.</p>
It isn’t.</p>
It is a probabilistic generator.</p>
The better framing:</p>
You are running experiments.</p>
Each agent instance is a sample from a distribution of possible implementations.</p>
Your job is evaluation and selection.</p>
This turns AI assistance from a linear conversation into a parallel search process.</p>
Tradeoffs</h2>
Is it more resource-intensive?</p>
Yes.</p>
Does it consume more tokens?</p>
Yes.</p>
But developer time is expensive.
Waiting is frustrating.
Context switching is costly.</p>
I would rather review three implementations once than restart one implementation three times.</p>
Parallel AI feels closer to how we approach distributed systems:</p>
Spawn workers.

Collect results.

Select the best outcome.</p>
It turns uncertainty into leverage.</p>

In Rust We Trust 🦀 - productivity

Why Vim Felt Inevitable

How I Keep Up With Tech Trends

Final Thought</h2> If you feel like you are drowning in tabs, or missing important updates because a feed decided they were “low engagement,”</p> try RSS.</p> Sometimes the most boring technology is the most effective one.</p>

Running Multiple Claude Instances in Parallel

Final Thought</h2>
If you feel like you are drowning in tabs, or missing important updates because a feed decided they were “low engagement,”</p>
try RSS.</p>
Sometimes the most boring technology is the most effective one.</p>