Why a shell-first setup wins
Centering your development workflow around the shell pays off in ways that go beyond simple habit. Because shell tools are small, designed to interoperate, and driven by text, you can chain them together into powerful pipelines, automate repetitive chores, and keep your hands off the mouse. The cost is real: the command line is less approachable than a GUI, and you need to learn a new vocabulary of commands. But once you're past that curve, the flexibility and speed are hard to beat.
There’s a useful distinction to make here. The terminal is the graphical window that lets you type into the shell; the shell itself is an interpreter that executes the commands you feed it. On most Linux systems, that’s Bash, but alternatives like Zsh are common. The terms “command-line” and “shell” are effectively interchangeable in practice.
Unlike a desktop environment that renders windows, buttons, and menus, a command-line tool only needs to handle text input and output. That’s a major reason so many of these utilities exist: they’re far less work to build and maintain than a GUI, and they run fast because there’s no graphical layer to paint. Every byte of effort saved on presentation goes into responsiveness.
The Unix philosophy of composing small programs is where the real leverage lives. Each CLI does one job well, and you link them together for results no single tool could produce alone. For instance, piping the history command through sort, uniq, and head reveals which commands you run most often and how frequently:
The other big win is automation. If you find yourself repeating the same sequence of actions—resizing batches of images, grepping through a specific file type—you can wrap it in a shell script once and never type it out again. And when you eventually need to manage remote servers, the shell is often your only option, since most headless machines have no graphical interface at all.
The practical payoff of keeping your hands on the keys
The fact that the shell is text-based means your hands never have to leave the keyboard to interact with it. That sounds trivial, but the effect over a workday is noticeable. Every time you reach for the mouse, you break your flow and spend a moment reorienting. Staying on the keyboard keeps your attention fixed on the code rather than on the mechanics of moving a cursor.
This isn’t about a theatrical “hacker” aesthetic—it’s a legitimate ergonomic argument. The Pragmatic Programmer makes the point directly:
“Using only keystrokes for common editing operations is more efficient than mouse or menu-driven commands because your hands never leave the keyboard.”
It’s worth stressing that this is a comfortable way to work, not a purist’s constraint. The tools described in this article still respond to the mouse if you want them to. But they’re designed in a way that keyboard control feels natural, and the more you lean into that, the easier it becomes to maintain focus.
The tools that enable a mouseless environment have a secondary benefit: they’re all configurable as plain text. That means your entire setup can be captured in scripts and configuration files, letting you rebuild a complete working environment from scratch if your system breaks or you move to a new machine.
Linux as the sane foundation
The author’s path to this setup started with a common frustration: a mainstream Linux distribution that abstracted away all of the system’s internals. Updates were fragile, and when they failed, recovering the system required a full reinstall and days of reconfiguration. The UX was sluggish and prone to display bugs.
The problems weren’t with Linux itself, but with the distribution’s approach. Understanding how the underlying system fits together—rather than relying on a tool that hides the details—makes you resilient to breakage. This is ultimately about having a system you control, not one that hides itself from you until something goes wrong.
A tiling window manager is a large part of that control. It removes the need to peruse and arrange windows with the mouse, instead letting you organize your workspace with keyboard shortcuts. The terminal, the editor, and every other tool fit together into a layout you direct without ever leaving your home row.
The environment described here is not a single app but a stack that builds on itself: an X terminal like URxvt provides a fast, configurable surface; a multiplexer like tmux adds session and pane management on top of it; and tmuxp makes those layouts reproducible. Vim, the text editor, becomes the last piece—the tool you use for editing code and prose alike.
Working this way isn’t a drastic overnight switch, and it was never a choice between keyboard and mouse for daily tasks. The design philosophy, rather, is that the keyboard should be the default—because it lets you think in terms of commands and intent rather than clicks, and it gives you a development environment that’s fully your own.
Choosing a Foundation: Arch Linux
Arch Linux has a reputation for being difficult and unstable. In my experience, that reputation is undeserved. After years of daily use across Windows, macOS, and other Linux distributions, I’ve found Arch Linux to be the most stable system I’ve ever worked with. It’s not a strict requirement for building a mouseless development environment — the other tools discussed here work well with other distributions, macOS, or Windows via WSL — but it offers several compelling advantages.
Rolling Releases, Fewer Surprises
Arch uses a rolling release model, which means you update your system regularly, typically weekly or bi-weekly. This contrasts with the long-term support model of distributions like Ubuntu, where major updates arrive only a couple of times a year. The conventional wisdom is that frequent updates introduce instability, but I’ve found the opposite to be true. In six years of daily use, I’ve never encountered a serious problem. Regular updates mean your applications are always current, and each update introduces fewer changes at once, reducing the chance of something breaking.
Repositories and Resources
Arch’s official repositories are extensive, and most tools you’ll need are a simple install away. If something isn’t in the official repos, the Arch User Repository (AUR) likely has it. The AUR is community-maintained, so there’s some inherent security risk, but sticking to official repositories and being selective with the AUR should keep you safe. The Arch Wiki is another major asset. It’s arguably the best Linux documentation available, useful not just for Arch users but for troubleshooting any Linux system.
A Minimal Install That Teaches
Arch Linux is minimal by design. Installation is a manual, shell-driven process, which can seem intimidating. However, it’s a valuable learning experience. Understanding how a Linux system is assembled helps you diagnose issues when things go wrong. Given how prevalent Linux is — on servers, phones, and embedded devices — this foundational knowledge is increasingly important for developers.
Window Management with i3
Operating systems generally operate in three layers: the kernel, which interacts with hardware; the shell, which provides an interface to the kernel; and a display layer, such as a desktop manager or a tiling window manager. Desktop managers like GNOME or Unity handle windows, status bars, and application launchers. Tiling window managers are a lighter-weight alternative focused purely on window manipulation.
The i3 tiling window manager is extremely light. I use it on a decade-old Lenovo x220 without any slowdown. It’s simple, well-documented, and fully keyboard-driven. The core concept is that windows are placed in distinct workspaces, each representing a full screen. When you open applications, the screen is automatically partitioned among them. For example, one Firefox window takes 100% of the screen; three take 33% each.
You can also adjust the layout. Instead of side-by-side windows, you can stack them vertically and cycle through them with keystrokes. Floating windows are supported for applications that need them.
The goal of i3 is to simplify window management. Instead of manually moving and resizing windows with a mouse, you can perform these actions with keystrokes only when needed. I was reasonably proficient within two days of use. While i3 isn’t available for macOS, alternatives like Amethyst or Divvy offer similar functionality.
The Terminal Stack: URxvt, tmux, and tmuxp
A Simple Terminal: URxvt
URxvt is about as simple as terminals get. It’s fast, reliable, and does exactly one thing: provide access to the shell. I’ve never seen it crash or slow down in years of use.
Session Persistence with tmux
tmux is a terminal multiplexer that allows you to manage multiple shell sessions in the background. If your terminal closes or crashes, your tmux sessions remain intact and can be reattached later. This is particularly useful for remote servers. You can SSH into a machine, start a long-running process, disconnect, and later reconnect to find everything still running.
tmux also lets you split a single terminal into multiple windows, each containing several panes. This mirrors i3’s approach but is limited to creating new shells. Some i3 users see this as redundant; I prefer to use both, as each serves a distinct purpose.
Automating Session Setup with tmuxp
Setting up a tmux session manually for a project — creating windows, dividing panes, and launching commands — can be tedious. tmuxp solves this by letting you define your session layout in a YAML file. You can specify which windows and panes to create, along with the commands to run in each. Loading this configuration automatically rebuilds your entire development session. I maintain one of these files per project, which saves considerable time and effort.
Turning an Editor into an IDE
Given how powerful the shell is, it makes sense to use an editor that runs within it.
Vim’s learning curve is often overstated. Running vimtutor gives you the basics in about 20 minutes. Reaching mastery takes time, but basic productivity comes quickly. Vim is extensible through plugins and can interact directly with your shell, effectively becoming a full-fledged IDE.
A major advantage of Vim is its language-agnosticism. I can work in PHP, Golang, Clojure, or any other language without switching editors. With Language Server Protocols (LSPs), you get auto-completion, linting, and refactoring support for most modern languages. This avoids the burden of configuring multiple IDEs, each with its own interface and settings.
Vim is also resource-efficient. I routinely keep six or seven instances open on my aging hardware without issue, whereas opening two IntelliJ IDEs would slow my entire system down. This is practical when working on multiple projects or microservices concurrently. As with the other tools discussed, Vim is highly configurable, letting you include only the functionality you actually need.
Coherent Keystrokes Across Tools
One of the strongest arguments for this entire setup is consistency. The keyboard shortcuts in most applications are a mishmash of unrelated key combinations that are difficult to remember and differ wildly between tools.
The tools in this stack share a coherent keystroke language. They’re designed to work together, so the same key combinations perform similar functions across different applications, with a single modifier key differentiating which tool you’re controlling. Vim’s keystrokes are particularly systematic. Commands form a simple, composable language — for instance, daw deletes a word, and dap deletes a paragraph. Many command-line tools borrow Vim’s key bindings, so learning Vim’s vocabulary gives you a head start with countless other CLIs.
Automated Setup and Installation
While installing Arch Linux manually is an educational exercise, repeating that process for each new machine is inefficient. To address this, I maintain scripts that install my entire mouseless development environment, including Arch Linux itself and all of the tools I use along with their configurations. On a new computer, running these scripts brings up a fully configured environment in one step.
Try It Before You Judge It
The real payoff of a mouseless setup is its modularity. Because every component is tied to a text file rather than a vendor lock-in, swapping tools is a matter of replacing one config for another. Don’t like tmux? Plug in a different terminal multiplexer. Unhappy with i3’s status bar or your application launcher? Switch them out, too. Nothing is bolted down.
That degree of freedom comes at a price, of course. Building and maintaining this kind of environment takes time, motivation, and effort. It is not a weekend project if you want it polished. To assist with that process, the author of the source article has published a book, “Building Your Mouseless Development Environment,” which covers the full configuration of each tool, scripts to install the entire system with a single command, and the customization logic for tailoring it to your own needs. If the Linux shell is unfamiliar territory, the book also includes a custom project to help you get comfortable with it.
A free sample of the book, along with its complete table of contents, is available online.
The surest way to know whether this workflow suits you is simply to try it. Even if you abandon it later, the process of assembling the system teaches you a lot about the underlying tools and your own habits.
Related Reading
- “I Used The Web For A Day With Just A Keyboard,” Chris Ashton
- “A Complete Guide To Mechanical Keyboards,” Ben Frain
- “Making A Strong Case For Accessibility,” Todd Libby
- “Accessibility In Chrome DevTools,” Umar Hansa
