Why Switch to Arch Linux as a Developer?
The honest answer to why switch to Arch Linux as a developer isn't about aesthetics, package managers, or internet bragging rights. It's about removing friction from your workflow so completely that your brain stops burning cycles on navigation and starts spending them on actual problem-solving. After eight-plus years of mocking Arch users on Twitter, the switch finally happened — and the catalyst was watching a co-worker at Netflix demolish the same tasks in half the time using a setup that was simply faster at every level. That moment was humiliating in the best possible way. It set a clear goal: build a development environment where every action costs as few mental cycles as possible.
The Arch install itself was surprisingly straightforward. Yes, there were a few bricked systems along the way. Yes, getting Sway running on Ubuntu failed spectacularly. But the actual Arch installation process is well-documented, genuinely fun to go through, and gives you exactly the control you need to build a setup around your own workflow rather than someone else's defaults.
02:15
The four-rule productivity philosophy explained before any tool is shown
Watch at 02:15 →
How to Actually Improve Your Developer Experience
Before diving into any specific tool, it helps to have a guiding philosophy. Without one, you end up in a rabbit hole of switching terminals every six months because someone on Reddit said Kitty is better. Here's the four-part framework that drives every decision in this setup:
- Stick close to defaults. Every extra layer of configuration is a liability. The more you customize, the more things break silently and the more time you spend debugging your environment instead of your code.
- Never search with your eyes if you can avoid it. One keypress to get where you want. If that fails, fuzzy-find it. Only after both options are exhausted should you ever scroll through a list visually.
- Don't switch to something just because it's newer. New is not a reason. There has to be a concrete, felt improvement before a tool earns a place in the workflow.
- Build tools that fix real friction, not tools that shave a keystroke. Saving two characters on a git command is not a productivity hack. It's technical debt with a productivity costume on.
These four rules sound simple. Actually following them is what separates a genuinely fast developer setup from a beautiful one that's secretly slow to use.
Hyprland vs i3: Is the Switch Worth It?
After years on i3, the move to Hyprland as a window manager came with one immediately obvious win: no more screen tearing. Beyond that, Hyprland brings rounded corners, window gaps, and a cleaner visual baseline without requiring you to build that experience from scratch. The gaps are still on trial — the jury is genuinely still out — but the core navigation behavior is identical to what made i3 worth using in the first place.
04:30
Hyprland desktop with rounded corners, window gaps, and the custom Waybar status bar
Watch at 04:30 →
One critical configuration change that came with the switch: moving from Alt as the modifier key to Super. Alt is claimed by too many applications, which quietly breaks shortcuts across the whole system. Super solves that problem entirely. The cost is eight years of muscle memory to unlearn, which is genuinely painful for the first few weeks. The payoff is that Alt is now completely free for application-level shortcuts — one press of Alt+1 opens the browser, Alt+2 opens Twitch chat, Alt+3 goes to Twitter. No hunting, no switching, no thinking.
On animations: they're off. Completely. A five-second window animation isn't beautiful — it's a stun lock. Instant transitions keep focus where it belongs, which is on the work.
How Should Developers Organize Their Workspaces?
Workspace organization is one of the highest-leverage things you can do for daily developer productivity, and almost nobody talks about it seriously. The setup here is rigid by design:
- Workspace 1: Browser
- Workspace 2: Twitch chat
- Workspace 3: Testing
- Workspace 4: Coding
- Workspace 5: AI prompting (because CSS should never be written by hand)
- Workspace 6: Drawing and visual work
The point isn't which programs live where. The point is that the layout never changes. Super+1 always takes you to the browser. Always. There's no decision to make, no scanning a taskbar, no Alt-Tab roulette. Your hands know where to go before your brain finishes the thought. That's the target state for every part of this workflow.
09:10
Live demo of Harpoon file jumping and Telescope fuzzy find inside Neovim
Watch at 09:10 →
What Is the Best Neovim Navigation Setup?
The single most important insight about Neovim — and code editing in general — is this: most of editing is finding where you need to be. The actual keystrokes to change text are fast. The expensive part is getting your cursor to the right file, the right function, the right line. Optimize that and everything else falls into place.
The navigation stack that covers roughly 95% of all movement looks like this:
11:45
TM Sessionizer fuzzy-finding across all project directories in under a second
Watch at 11:45 →
- LSP navigation (80% of moves):
gdto jump to definition,Shift+Kto inspect a function,leader+rrto find all references. The language server does the heavy lifting; you just need to know three commands. - Harpoon (fast file jumping): Mark the four or five files you're actively working in and jump between them with a single keystroke. Same philosophy as workspace organization — zero searching, zero thinking.
- Telescope (fuzzy find everything else): When Harpoon doesn't have what you need, Telescope fuzzy-finds it instantly. A community-built alternative is in development and will likely replace it when it's ready.
- Undotree (non-linear undo): Most developers forget that undo history is a tree, not a line. Undotree exposes that branching structure. And here's a thought worth sitting with: Git is just undo history at the project level. Same concept, bigger scope.
Notice what's not on this list: custom abbreviations for git commands, remapped shortcuts to save two keystrokes, or elaborate status line plugins. Every line of configuration that isn't solving a real navigation problem is a line that will break at the worst possible moment.
Tmux vs Zellij: Does It Actually Matter?
The honest answer to the Tmux vs Zellij debate is that it almost certainly doesn't matter for your workflow. The commands to create a detached session at a specific directory are functionally identical between the two tools. If you already know Tmux, the switching cost is real and the benefit is marginal. If you're starting fresh, either works.
What does matter is TM Sessionizer — a fuzzy-finding layer on top of Tmux that lets you jump to any project directory instantly. Combined with Tmux's native session and window management, it handles everything a terminal multiplexer needs to do: persistent sessions, fast project switching, and clean window organization. Panes, for what it's worth, are optional. Sessions and windows cover the vast majority of real use cases.
What Is a Telos of Rice and Why Does It Matter?
The Greek word telos means end goal or purpose. The telos of rice — the purpose of customizing your Linux desktop — is the question most people never ask before spending forty hours tweaking their setup. Without a clear answer, you end up optimizing for screenshots instead of for work.
The telos here is developer experience, full stop. Not looks. Not showing off a Neofetch readout. Not having the most animated window transitions on the block. Every tool, every keybinding, every configuration decision gets evaluated against one question: does this make the work faster and less mentally taxing?
That's why FastFetch isn't installed. You know what operating system you're running. That's why Yazi isn't in the workflow. Netrw inside Neovim handles file navigation without adding another tool to maintain. That's why get integration in the editor, while genuinely cool, gets used sparingly — because git add . && git commit -m covers 99% of real commits and takes two seconds.
The goal of a great developer setup isn't to impress anyone. It's to reduce the thousand small moments of friction that accumulate across a workday into a slow, grinding exhaustion. Fix the navigation. Fix the repetitive operations. Make the boring parts invisible. What's left is the part that's actually worth showing up for — building things that work.
