Before I started working as a software engineer, I would only ever use a command line interface (CLI) if there was no graphical alternative. Each instance felt like a battle against the archaic syntax of a legacy technology, and I would struggle to build a mental model of the file system I was working in. Today, the CLI is at the core of my development workflow, and I'm constantly looking for ways to replace GUI tools with CLI alternatives.

## The catalyst

My comfortable coding workflow went out the window when I started my first software engineering role. I'd never been in an environment with such a high bar for performance - but more significantly, I'd never been surrounded by so many people capable of meeting and exceeding that bar.

Trying (and failing) to merge 15 PRs into production per week across millions of lines of code made me realise that something fundamental needed to change about my workflow.

## The goal

I'd seen some crazy videos online with people flying around their terminal environment, searching/editing files and running commands so quickly I'd lose track of what was happening. I wanted that speed and precision, but every time I dabbled with vim for some quick text editing, I'd end up fighting against the CLI and waste more time than if I'd just done things the normal way.

## The breakthrough

I came across fzf - a command-line fuzzy finder. Invoking fzf runs a fuzzy search over the files in the current directory and prints the name of the selected file. A year prior I would have dismissed this as a triviality, but my recent exploration had fundamentally shifted my perspective.

The CLI is not a set of disparate commands to memorize. It's a system for composing data transformation pipelines with tools that use text as a universal interface. This reflects the Unix philosophy:

• Write programs that do one thing and do it well.
• Write programs to work together
• Write programs to handle text streams, because that is a universal interface

CLI tools are designed to be used as composable parts of a pipeline - not in isolation.

This design philosophy allows a tool like fzf to provide enormous value. It isn't limited to fuzzy searching files - it can search any given text input. Printing the selection is useless in isolation, but incredibly useful when that selection is used as the input to another CLI tool.

When I learned about fzf, I realised that it could solve my two biggest pain points:

1. Navigating to a specific directory (quickly)
2. Opening a specific file somewhere in that directory (quickly)

### Directory navigation

• Define a list of all frequented directories
• Pipe the list to fzf
• cd to the selected directory

With this terminal alias, I can navigate to any of these directories in less than a second with just a few keystrokes.

DIRS=$(cat << ---
~/.config/nvim
~/.config/tmux
~/.dotfiles
~/Downloads
~/projects/command-reference
~/projects/website
~/repos/example
---
)
alias d='dir=$(echo $DIRS | fzf) && eval cd $dir'

### File search

• Use rg (ripgrep) to list all file paths in the current directory
• Pipe the list to fzf
• Open the selected file in nvim

With this terminal alias, I can open any file in seconds with just a few keystrokes

alias s='file=$(rg --files | fzf) && nvim $file'