My Dev Enviroment
You know that feeling when you spend three hours configuring your editor just to avoid writing code? Yeah, it took me a couple of months to realise I was spending too much time on rice than on actual work.
So … after countless late-night sessions tweaking my dotfiles, I finally accepted the truth: done is better than perfect.
Here are some thoughts from shifting focus from working on my dev enviroment to working in my dev enviroment.
The Problem: When I first switched to linux.
Oh glorious feature creep. Every new video, article, and recommendation had me opening the package manager. Installing IDEs packed with features I’ll never use, desktop environments that look pretty but eat RAM, and tools that solve problems I don’t actually have.
The result? A system that’s slow, distracting, and breaks in mysterious ways.
Upon reflection my goal became: maximum productivity, minimum overhead, still sexy. Every tool had to justify its existence by solving a real problem I faced daily (and had to look good doing it).
The Core Philosophy: Terminal-First
Here’s the constraint that shaped everything:
If I can do it in a terminal, I will.
The Full Philosophy
- Keyboard speed: My hands should rarely leave the keyboard
- Resource efficiency: Terminal apps use a fraction of GUI resources
- Reliability: Text-based tools rarely crash, and if they do they tell me why
- Consistency: Similar keybindings across all applications
- Sexiness: What’s the point of ricing if it looks shit?
Note: I do rarely use a GUI for some things. The key outcome is speed. And a GUI is quicker at some things.
Update: The Hyprland Detour
My original version of this post recommended Wayland and Hyprland. After six months of daily driving that setup, I switched back to X11 and i3. Here’s why.
Hyprland’s animations, transparency effects, and smooth transitions were fun to configure and impressive to look at. But they added nothing to my productivity. The gimmicks became distractions. I was spending more time tweaking blur and opacity values than writing code.
The switch to i3 was surprisingly painless. It was a swap, not a rebuild. My shell, terminal, editor, all my tools carried over untouched. The only things that changed were the window manager and a handful of Wayland-specific utilities.
The result: a faster, more stable, more predictable environment. No compositor quirks with NVIDIA. No flickering. No mysterious crashes. Just windows that tile and keybindings that work.
The Stack (And Why Each Piece Matters)
OS: Arch Linux
Problem solved: Bloatware and unnecessary services.
Why it works: You only get what you explicitly install. No background processes you didn’t choose.
Getting started:
# Use archinstall for a guided setup
# Or follow the manual installation guide at archlinux.org
# (I use arch btw)
Display: X11
Problem solved: Wayland’s NVIDIA compatibility issues and compositor overhead
Why it works: Mature, stable, predictable. NVIDIA drivers just work.
pacman -S xorg-server xorg-xinit xorg-xrandr
I originally ran Wayland but moved back to X11. Wayland is the future, but with NVIDIA on a productivity-focused setup, X11 is still the pragmatic choice.
Window Manager: i3
Problem solved: Keyboard control, tiling windows, zero distractions.
Why it works: Tiling means every pixel is useful. No animations, no transitions, no wasted frames. Just windows where you put them.
pacman -S i3-wm i3blocks i3lock
I moved from Hyprland to i3. Hyprland’s visual features were fun but added nothing to my workflow. i3 is simpler, faster, and doesn’t break.
Key config details: Picom for tear-free rendering (no transparency, no blur, no fading), feh for wallpapers, i3blocks for a status bar with attention-based coloring (grey by default, color only when something needs your attention).
Terminal: Kitty
Problem solved: Terminal fatigue from ugly, slow interfaces
Why it works: Hardware acceleration, good font rendering, and modern features
pacman -S kitty
When you’re staring at a terminal 8+ hours a day, it better look fucking nice.
Shell: ZSH
Problem solved: Bash’s limited tab completion and customization
Why it works: Better globbing, completion, and plugin ecosystem
pacman -S zsh zsh-completions
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
chsh -s /usr/bin/zsh
Browser: Firefox
Problem solved: Privacy invasion and resource bloat from Chromium-based browsers
Why it works: Better privacy defaults, extensive customization, and alignment with FOSS philosophy
pacman -S firefox
For maximum privacy, consider the arkenfox user.js project. It’s a hardened Firefox configuration that disables telemetry, fingerprinting, and other privacy-invasive features while maintaining usability.
Editor: Neovim
Problem solved: IDE bloat vs. editor limitations
Why it works: Infinitely customizable, but you choose exactly what to enable
pacman -S neovim
The key realization: You don’t need AI autocomplete, extensive linting, or 50 plugins. Start minimal and add tools only when you hit specific pain points.
My setup: Dracula theme, LSP for diagnostics only (errors, not style opinions), manual-trigger autocomplete (no auto-popup), Telescope for project-wide navigation, bufferline for visual buffer management, and splits/tabs for multi-file workflows on large codebases.
The biggest workflow improvement was learning to use buffers (open files in memory), splits (visible panes), and tabs (saved layouts of splits) properly. For complex projects, I set up reference layouts with 4-5 files visible at once and jump between tab layouts depending on whether I’m writing, reading, or testing.
Files: Yazi
Problem solved: Slow GUI file browsers, mucking with themes, the disgust upon opening a fm gui.
Why it works: Thumbnails in the terminal? Visual navigation? Looking cool? Yazi checks the boxes.
pacman -S yazi
Application Launcher: Rofi
Problem solved: Nested menus and mouse-dependent app launching
Why it works: Fuzzy finding means typing “fire” launches Firefox. Frequency sorting means your most-used apps float to the top.
pacman -S rofi
Use rofi -show drun (not run) for frequency-based sorting of desktop applications.
Everything Else
# Media and monitoring
pacman -S cmus cava btop
# Document viewing
pacman -S zathura zathura-pdf-mupdf feh
# Compositor (tear-free rendering, no effects)
pacman -S picom
# Screenshots
pacman -S maim xclip
# Because why not
pacman -S tty-clock
Theme: Dracula Everywhere
One theme across every application. Consistency matters more than variety.
- Kitty: Dracula color config
- Neovim: dracula.nvim
- i3bar/i3blocks: Dracula palette colors
- Rofi: Custom Dracula rasi theme
- GTK/Thunar: Colloid Dracula Dark
- Icons: Tela Circle Dracula Dark
- Yazi: Custom Dracula theme.toml
- Zathura: Dracula recolor config
- btop, cava, cmus: Dracula themes
It took some effort to set up, but now everything looks like it belongs together.
The Complete Installation
Here’s the core system in one go:
# Core system
pacman -S i3-wm i3blocks i3lock picom kitty zsh zsh-completions neovim \
yazi rofi cmus cava btop zathura \
zathura-pdf-mupdf feh maim xclip tty-clock xorg-server \
xorg-xinit xorg-xrandr dunst
# AUR packages (install yay first)
yay -S colloid-dracula-gtk-theme-git tela-circle-icon-theme-dracula
# Shell setup
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
chsh -s /usr/bin/zsh
The Real Benefits
After six months with this setup (and another few months after the i3 migration):
- Faster context switching: No waiting for applications to load
- Less distraction: No notification popups, no animations, no visual clutter
- Better focus: Full-screen terminal sessions create flow states
- Easier maintenance: Text-based configs are debuggable and portable
- Stability: No compositor crashes, no flickering, no mysterious Wayland bugs
- Consistency: One theme, one font, one philosophy across every tool
Getting Started
Don’t try to replicate this exactly. Instead, identify your biggest productivity bottlenecks and replace them one tool at a time. Start with your most-used applications and work outward.
As much as I love the aesthetic of using a terminal for everything that isn’t what this is about … it’s about building an environment that disappears when I’m working, letting me focus on the problems that actually matter.
Your mileage may vary. But if you’re spending more time configuring your tools than using them, maybe it’s time to embrace “good enough” and get back to building things that matter.