Most setup posts focus on aesthetics: screenshots, animations, and endless tweakability. Mine is different. I optimize for output, not for turning dotfiles into a side project with its own release cycle. Except for my neovim config, lol I know how that sounds.
I want a workstation that helps me ship code with minimal friction. That means fewer moving parts, fewer surprise breakages, and fewer hours lost to "just one more config tweak."
My rule is simple:
fewer configs -> less maintenance -> faster delivery
In Rust terms: I want zero-cost abstractions in my environment, not hidden maintenance allocations.
This mindset did not appear overnight. I started with Gentoo at 14 and was a full-on customization addict for years.
25 years later, here we are. I am a dad, I have a job, and I want to start coding after business hours with no bs. I want to use the same IDE config professionally and for fun. So this is the workflow I use now.
The principle: build a machine for work, not for care
I do not want a pet system. I want a reliable tool.
For me, that means three practical constraints:
- Prefer strong defaults over custom plumbing.
- Use tools that solve multiple problems in one place.
- Minimize maintenance debt, even if the setup looks less "exotic."
A setup can be technically impressive and still be bad for throughput. If I need to constantly babysit window rules, plugin interactions, or shell glue, I am paying an invisible tax every week. If the whole thing feels like chained unwrap() calls, it is too fragile.
Rob Pike captures that nicely: "Less can be more. The better you understand, the pithier you can be." [^4]
The big change happened over roughly the last decade. As my career moved from physics research into production software architecture, reliability started to dominate novelty. The more complex the real systems became, the more I valued boring defaults and low operational entropy.
Why KDE Plasma on Manjaro is my daily driver
For daily work, I use KDE Plasma on Manjaro because it gives me a polished base with enough power when I need it, without forcing high-maintenance customization.
KDE's "simple by default, powerful when needed" [^1] maps almost perfectly to my working style.
I get:
- Sensible defaults that are usable immediately.
- A mature desktop with predictable behavior.
- Flexibility for edge cases, without requiring everything to be handcrafted.
This keeps cognitive load low. I can focus on the problem at hand, not desktop internals.
Why I do not daily-drive Hyprland (even though I like it)
I like Hyprland. It's fun, expressive, and powerful.
But for my production machine, desktops like it often come with extra plumbing:
- More custom integration between components.
- More edge cases when packages or configs move.
- More "it worked yesterday" moments after routine updates.
One concrete pain point for me was KWallet integration. I spent a long time trying to make Hyprland work with KWallet in a reliable cross-over way, found at least 20 different hacks, and most of them were brittle in daily use. A lot of them felt like unsafe blocks around session startup.
That overhead is acceptable on a hobby box if you are a teenager or if solving these issues is your hobby. On a machine I depend on for delivery and personal after-hours satisfaction, it is friction and frustration.
That is also why I keep Arch mostly on a separate machine for experimentation, not as my primary workstation.
A quick note on Omarchy
Omarchy is getting a lot of hype right now, and I understand why. Its core idea is very close to this post: ship the stuff out of the box so the defaults are already good enough for real work.
I still do not use it as my main setup because I personally prefer Manjaro's presets. In Rust terms, both are solid crates, but Manjaro's defaults currently fit my production API better.
Terminal layer: Alacritty + Zellij
My terminal stack stays simple:
- Alacritty with Source Code Pro Nerd Font for clean rendering and speed [^7].
- Zellij (since 2025), after many years with tmux.
I switched for the same core reason: less setup effort and less long-term maintenance.
Zellij positions itself as "Terminal Workspace with Batteries Included" [^2], and the docs emphasize that it is useful with defaults, not only after heavy personalization [^3]. That is exactly the vibe I want: fewer custom macros, more predictable behavior.
In practice, this means I can open a working session quickly with consistent panes, tabs, and project context, without maintaining a large tmux ecosystem.
Cross-platform proof: same core setup on macOS at Spread
At Spread I use a Mac for daily work. I did not rebuild my workflow from scratch there.
I just brought over the same core tools:
- Alacritty
- Zellij
- My Neovim config
For window management on macOS, I use Raycast to make behavior feel more close to Plasma. But again I changed the bare minimum to make me feel at home.
That portability is a big part of the strategy. If the same terminal/editor layer works across Linux and macOS with minimal changes, I spend less time on environment drift and more time shipping, with fewer OS-specific quirks in my head.
Editor layer: Neovim as a command center
My editor is nvim with this Neovim configuration, kindly hosted by the spread-ai team on GitHub: https://github.com/spread-ai/nvdata. I do not treat Neovim as a plugin museum. I treat it as a compact control center for everyday engineering work.
Why this fits my workflow:
- Keyboard-first speed: modal editing reduces context switching.
- One place for the core loop: navigation, diagnostics, refactors, formatting, and Git are integrated.
- Composable without bloat: I can automate repetitive work but keep the base lean.
This gives me high leverage without a heavyweight IDE footprint.
What this config does well for modern web stacks
The config is tuned for real project work, not only demos.
1. Web-first LSP baseline out of the box
Language servers like ts_ls, html, and cssls are ensured via Mason + mason-lspconfig.
This removes setup drift between machines and shortens time-to-first-commit on new repos.
2. TypeScript ergonomics that matter over months
TS inlay hints are enabled, which improves readability in large codebases where type context is otherwise hidden behind function chains and generic helpers.
3. Team-aligned formatting defaults
prettier.nvim is wired for everyday frontend files:
javascript, typescript, tsx, json, css, html, and markdown.
Formatting is fast, predictable, and close to what teams already expect. Think rustfmt, but for the web stack. "Readable code is reliable code." [^5]
4. Structural editing support via Treesitter
Treesitter parsers for typescript, tsx, html, and css improve syntax awareness and make navigation/editing less error-prone in nested component code.
5. High-frequency mappings for daily velocity
I rely on direct keymaps for common actions:
- Diagnostics hover:
K - Diagnostics list:
<leader>dl - Code actions:
<leader>ca - Prettier format:
<leader>fp
The value is not novelty. The value is reducing repeated micro-friction.
6. Delivery tools in the same flow
Telescope, Neogit, Diffview, and Claude Code are integrated so search, review, patching, and AI-assisted iteration all happen in one continuous loop.
I spend less time jumping across unrelated interfaces.
What this looks like in a normal workday
This is the practical loop I optimize for:
- Open terminal, attach/start Zellij session.
- Jump into repo and scan codebase with Telescope.
- Edit in Neovim with LSP diagnostics and hints active.
- Run formatting and quick fixes from inside the editor.
- Review diffs with Git tooling, then commit.
- Repeat this loop all day without reconfiguring the environment.
The workflow is intentionally boring. That is exactly why it scales across long weeks and high context switching. Boring and deterministic beats clever and flaky.
Why this outperforms "perfect setup" culture
The internet rewards highly customized setups because they are interesting to look at. But visual uniqueness is not the same as engineering throughput.
For sustained output, I care about:
- Recovery time after updates.
- Onboarding time on a new machine.
- Number of custom components I need to remember.
- How fast I can return to deep work after an interruption.
A simpler stack often wins these metrics, even if it is less flashy.
Final takeaway
My workflow is not minimal for ideology. It is minimal for output.
The same idea applies to config sprawl too: one of Ken Thompson's most productive days was "throwing away 1,000 lines of code." [^6]
On Linux, KDE Plasma on Manjaro is my stable desktop base. At Spread on macOS, I keep the same terminal/editor core: Alacritty, Zellij, and a focused Neovim setup. That gives me exactly what I need: fast startup, low maintenance, and strong day-to-day leverage for modern web development.
No workflow is universal. But if you want a practical rule that consistently improves throughput, this one has worked for me:
make the default path fast, boring, and reliable - then spend your energy shipping (and avoid unwrap() in your desktop stack).
[^1]: KDE Community, Plasma 5.10 announcement (tagline): https://kde.org/announcements/plasma/5/5.10.0/ [^2]: Zellij homepage: https://zellij.dev/ [^3]: Zellij User Guide (overview/default configuration): https://zellij.dev/old-documentation/overview [^4]: Rob Pike, Less is exponentially more (2012): https://commandcenter.blogspot.com/2012/06/ [^5]: Rob Pike, Simplicity is Complicated (dotGo 2015 slides): https://go.dev/talks/2015/simplicity-is-complicated.slide [^6]: Eric S. Raymond, NTPsec blog quoting Ken Thompson: https://blog.ntpsec.org/2016/11/29/less-is-more.html [^7]: Source Code Pro Nerd Font reference: https://www.programmingfonts.org/#source-code-pro