DEV Community: Joe Schmitt

The Tools That Make My Terminal WorK

Joe Schmitt — Sun, 05 Oct 2025 19:24:37 +0000

At some point, most developers start to care about their terminal setup. It stops being just a place to run commands and becomes part of how you think about your work.

Over the years, I've built mine into something fast, predictable, and easy to reproduce across machines. None of it is particularly complicated, but the tools fit together in a way that makes the whole setup feel cohesive.

Here's what I use, and why it's worth knowing about.

Dotfiles + GNU Stow

Everything starts with my dotfiles repo. It's where all my terminal configurations live: shell, editor, Tmux, Git, everything.

The reason for having a dedicated repo is simple: these configurations evolve constantly, and being able to version them in Git means I can track changes, experiment safely, and sync them across machines. The tricky part is where those files actually live. Most configuration files belong in your home directory (~/.zshrc, ~/.config/nvim/init.lua, etc.), but you really don't want to make your entire home directory a Git repo.

That's where GNU Stow comes in.

Stow lets you keep your dotfiles in a separate, organized folder structure, and then it symlinks them into place in your home directory. For example, a zsh/.zshrc file inside the repo becomes ~/.zshrc when stowed.

This approach has a few big advantages:

You get full version control and portability without polluting your home directory.
You can easily remove or update a tool's configuration by "unstowing" it.
You always know exactly what will be linked where -- no magic, no scripts, no templating language.

I chose Stow specifically because of that simplicity. The files in my repo are exactly the files that end up on my system -- no templates, no build step, no indirection. You can open any file in the repo and know immediately what your local configuration would look like.

The repo is also structured around profiles:

shared/ for configuration common to all machines
personal/ for personal devices
work/ for work-related setup

That lets me apply a different combination of stow packages depending on which machine I'm setting up. It keeps the configurations isolated but still easy to maintain in one place.

Run stow shared work on a new laptop, and everything falls into place.

Tmux

Tmux is a terminal multiplexer: it lets you run and manage multiple terminal sessions inside a single window. You can split the screen into panes, create tab-like "windows," detach from a session entirely, and come back later with everything exactly where you left it.

For me, it's the backbone of how I work day to day. It ties together everything else -- Neovim, shells, Git, even AI assistants -- into a single, coherent workspace.

Each Tmux session usually starts from a project directory. I'll open one up (often through Sesh, more on that later) and it immediately drops me into a layout I've come to rely on: a main pane on the left and a couple of ancillary panes on the right.

The left pane is almost always my editor Neovim running in LazyVim. On the right, I usually have two smaller panes stacked vertically: the top one runs an AI coding assistant like OpenCode, and the bottom one is just a regular shell for running commands, tests, or quick Git actions.

It's a simple layout, but it covers nearly everything I need. If I ever need a third or fourth pane, I can split, rearrange, or resize them at will using simple keyboard shortcuts.

Navigation is fast and intuitive. I move between panes using Alt + movement keys, and when I need to focus on one task, I hit Alt + z to "zoom" a pane full-screen, then drop back into my grid when I'm done. I can create new windows with Alt + 1--9 and switch between them using Alt + [ and Alt + ].

Those shortcuts make it feel less like juggling terminals and more like working in a dynamic, responsive interface that's entirely keyboard-driven.

I've also added a few "popup" panes, centered overlays that float above the grid. They're perfect for quick context switches: I have one for LazyGit, one for Yazi, one for a bare “quick shell”, and one that runs Sesh so I can instantly jump between sessions.

All of this combines into a setup that's fast to move around in, easy to multitask within, and flexible enough to adapt as I work. Whether I'm deep in code or juggling multiple projects, everything stays within reach.

Neovim (with LazyVim)

Neovim, configured with LazyVim, was my gateway drug into the world of advanced terminal tools.

For years I resisted diving into Vim beyond the absolute basics. I'd been using VS Code for nearly a decade, and that workflow was burned into muscle memory. Every time I tried Vim, it felt like touching a hot stove: awkward and counterintuitive, clearly designed by someone who didn't like other people very much.

What finally got me over the hump was two things:

LazyVim gives Vim/Neovim the vast majority of the features of a modern IDE, in a setup that's cohesive, visually polished, and doesn't require building everything from scratch.
I was spending more time editing files on remote machines, and being stuck in stock Vim or Nano was painful. I realized if I just learned Vim properly and made it my own, it would pay off in flexibility everywhere I worked.

And I was right.

I'm now completely addicted to Vim's modal editing workflow. Motions, operators, and text objects make editing fast -- so fast that I feel clumsy when I have to use a traditional editor without them.

My setup is based on LazyVim's defaults, which I've customized only where it adds clear value. If you peek into my config, it might look like I've gone overboard -- but almost everything I've added falls into the "nice-to-have" category rather than "must-have." I'm careful to only integrate plugins that enhance something I already know how to do manually. The few keymap tweaks I've made are the exception; those are there to match how my hands naturally want to work.

With that setup, Neovim has become my full-time IDE, for both personal and work projects. I've got LSPs configured for the languages I use, auto-formatting, test runners, and build tools all running smoothly. And because everything is keyboard-driven and composable, I can move through code, refactor, and search without ever breaking flow.

Once the motions and shortcuts settle into muscle memory, it's genuinely hard to overstate how fast and intuitive it feels.

LazyGit

LazyGit is my Git UI of choice. It hits the perfect balance between having access to the full power of Git without needing to memorize its arcane command syntax, and being able to see everything that's going on visually.

It handles the basics -- staging and unstaging changes, committing, pulling, and pushing -- but also makes the advanced stuff easy. Interactive rebases, staging individual hunks, managing stashes, switching branches -- all of it's just a few keystrokes away, and all without ever touching the mouse.

It gives me the same control as the command line, but with a clear, structured view of what's changed and how it fits together.

I usually open LazyGit in one of two ways, both of which ultimately boil down to a popup. Inside LazyVim, <leader>ggopens LazyGit directly within Neovim. It's great for quick diffs or commits, though when Neovim is running in a split Tmux pane, the view can get a bit narrow. For that, I have a Tmux keybind -- <leader>G -- that opens LazyGit in a full-width popup across all panes, no matter how my layout is arranged.

That flexibility means I can manage Git state from anywhere, without context-switching or losing focus.

At this point, I rarely need to drop down to raw Git commands. Occasionally, in very large monorepos, LazyGit slows down a bit and I'll use Git directly, but those cases are rare.

The only customization I've made is visual -- I've themed it to match the rest of my terminal and set it to use Delta as the diff tool. It fits right in with the rest of my setup: clean, fast, and fully keyboard-driven.

Zoxide

Zoxide is a relatively recent addition to my setup, but it's quickly become one of those tools I can't imagine going back to working without.

It works as a smarter replacement for the standard cd command. Once you've used it to navigate somewhere, Zoxide remembers that directory. From then on, you can jump back to it just by typing part of its name. For example, after visiting ~/development/my-project once, I can just run z devproj and it'll take me straight there.

For a long time, I didn't really see the point -- typing full paths didn't feel that painful. But eventually I realized how often I was bouncing between the same directories day after day. The real breakthrough came when I discovered the zi command, which opens an FZF-powered fuzzy finder listing all known directories. It removes the "magic" guesswork entirely. I can just search and jump instantly.

I also use zoxide query (aliased to zq) constantly. It's like z, but instead of changing directories, it returns the full path it matched to. That's perfect for scripts or one-off commands where I want to use a path as a search query without moving into it.

One of the most powerful use cases is parameter expansion. If I want to open Neovim in a specific project, instead of manually cding into it, I can run something like:

    nvim $(zq myproj)

That one-liner uses Zoxide's search to expand to the full path automatically.

And that's just the start. Like several other tools in this setup, Zoxide ends up getting used by other utilities -- for example, through FZF integration -- making it a quiet but indispensable layer in the overall system.

FZF + Ripgrep

FZF and Ripgrep are everywhere in my setup. They're not flashy tools on their own, but they're the foundation that makes almost everything else fast and fluid.

Ripgrep (rg) is a modern replacement for grep: it searches through files blazingly fast, respecting .gitignore files and optimized for developer workflows. I use it both directly and indirectly, often without even realizing it, since it powers search in tools like Neovim and other terminal UIs.

FZF, on the other hand, is the universal fuzzy finder. It's the UI layer that lets me pick anything -- files, commands, directories, Git branches, sessions -- just by typing a few letters.

It shows up everywhere:

Inside Neovim/LazyVim, where it powers file and text search.
In my shell, for navigating command history or recently used directories.
In LazyGit, to fuzzy find repositories.
And in Sesh, to quickly jump between open sessions.

FZF has become such a deep part of my workflow that it's almost invisible -- it's just how I find things now. Paired with Ripgrep, it turns the terminal into something that's not only powerful, but immediately accessible.

They're small tools, but they punch far above their weight.

Oh My Posh

Oh My Posh handles my shell prompt, and while it might look like a purely aesthetic choice, it's actually a big quality-of-life improvement.

The real value isn't in how it looks, it's in how consistent and maintainable it is. I've done manual prompt customization in Bash before, and it becomes unreadable almost immediately. Even for Bash, which is already known for being a bit inscrutable, that's saying something.

With Oh My Posh, my prompt configuration is standardized and declarative. It's the same across every shell I use, and it behaves exactly the same on every machine. The configuration is simple and predictable, and I can tweak it without feeling like I'm defusing a bomb.

At a glance, my prompt gives me the key bits of context I care about -- current directory, Git branch and status, and even which shell I'm running -- all color-coded and cleanly presented. It's fast, rock solid, and stays out of the way.

It's one of those small things that you stop noticing entirely until you have to use a system without it.

Delta, Eza, Bat, and Yazi

These four tools fall into what I think of as the quality-of-life category. They don't redefine how I work, but they make the experience smoother, faster, and a little more enjoyable.

I spend a lot of time looking at diffs these days, especially as more and more of my code is written by AI that I then review. Delta makes that experience far better. It's my default Git difftool, and it's also what LazyGit uses behind the scenes. I configure it once, and I get consistent, syntax-highlighted diffs everywhere: clear, colorful, and easy to parse.

Eza is a modern replacement for ls. It adds visual niceties like icons, tree views, and control over recursion depth. I've aliased ls to eza, and most of the time I forget I'm even using it. It makes directory listings just a bit more readable without changing how I work.

Same story with Bat, which replaces cat. It adds syntax highlighting and line numbers when displaying files, but otherwise behaves exactly like cat. It's another one of those small upgrades that quietly improves the default experience.

Yazi is a bit different -- it's a full terminal-based file browser. I don't use it constantly, but when I do, it's invaluable. It's fast, powerful, and great for when I'm spelunking through unfamiliar directory trees. It lets me copy, move, rename, and preview files inline, all without leaving the terminal.

The common thread between all these tools is speed and simplicity. They each follow the Unix philosophy of doing one thing and doing it well, often improving on utilities that have existed for decades. I can absolutely get things done without them — it's just slower and clunkier.

Combined, they make the terminal a place that feels as powerful and polished as any modern IDE. And because I've standardized my color themes across everything, it all looks cohesive too.

Sesh + TWM

Sesh is what ties my whole terminal environment together. It manages my Tmux sessions -- the backbone of how I work -- and gives me a clean, consistent way to move between projects.

Most of my sessions are defined by working directories. I've configured Sesh so that its picker doesn't just list open Tmux sessions, but also directories tracked by Zoxide. That means if I pick a Zoxide directory, Sesh automatically creates a new Tmux session there, naming it after the directory. It's seamless: one action to jump into any project, whether it already exists or not.

I use Sesh almost exclusively through its popup window in Tmux, which makes it fast to open, fuzzy find a project, and jump right in without breaking focus.

Alongside Sesh, I also use TWM (Tmux Workspace Manager), which adds another layer of automation on top. TWM scans directories I've configured and automatically detects projects based on certain markers: a .git directory, a package.json file, etc. When I launch it, it presents a fuzzy finder list (powered by FZF) of projects I can narrow down interactively.

Once I select a project, TWM automatically spins up a Tmux session and applies a specific layout depending on the type of project, all without me lifting a finger.

Together, Sesh and TWM handle nearly all of my session and project management. I don't have to remember where things live or how they're configured, I just pick what I want to work on, and everything else falls into place.

It's the final layer that makes my terminal setup feel like a real, integrated environment rather than a collection of separate tools.

Putting It All Together

The terminal can be as minimal or as complex as you make it. For a long time, I treated it as a tool of last resort, a place to run a few commands and then get back to a "real" environment like VS Code. But somewhere along the way, it stopped being just a shell and became the environment.

The tools I've described here -- from Stow to Tmux, Neovim, LazyGit, Zoxide, FZF, and everything in between -- weren't things I adopted all at once. Each solved one small problem. But together, they've grown into a cohesive system that's fast, consistent, and surprisingly pleasant to use.

That doesn't mean everyone needs this exact setup. The best setups are personal -- they grow over time, one improvement at a time, as you find the friction points that matter to you. If a tool adds clarity or speed, keep it. If it adds complexity or gets in the way, drop it.

This isn't about collecting tools for their own sake; it's about building an environment that helps you think less about how you work, and more about what you're working on.

How I run through a tutorial and actually remember things

Joe Schmitt — Thu, 02 Jul 2020 01:24:28 +0000

This post is part of a (hopefully) long-running series of Dev Diary entires on my process of teaching myself Swift and Swift UI in order to build an app.

As I mentioned before, Apple has some amazing tutorials dedicated to Swift UI. The presentation of these is the best I've ever seen, broken down step-by-step with clear diffs and explanations on what you're doing, and even a quick quiz at the end to make sure you actually understood what you've done.

When doing these types of tutorials, you might often find that you've gotten to the end to that quiz having retained almost nothing. It's ok, it happens. Here's what I do that oftentimes helps to make sure I'm paying attention and actually learning, not just regurgitating.

Re-read every instruction/step more than once. It's too easy to just skim and not really take in what they're saying. Forcing yourself to do it at least twice, or maybe even once out-loud, forces you to slow down and pay attention
Never copy-paste the sample code. I learned this one the hard way from having done these types of tutorials from a text book back in the day. Copying and pasting has the same issue as skimming: you're not actually retaining anything. Forcing yourself to write the lines at least gives you a shot at remembering, just like note-taking helps retain a lecture
Try to do the tutorial step yourself before you copy the step. I can't stress this one enough. When I read an instruction that wants me to do something, I immediately ignore the code they're asking me to write and try and write the code myself. Nine times out of 10 I fail miserably, but that's ok! Eventually I start getting the hang of it and I start being able to complete the example just from its description, without referring to the sample code at all. That's when I know I've nailed it.

Looking in to SwiftUI

Joe Schmitt — Wed, 01 Jul 2020 16:23:31 +0000

One of the most exciting things to come out of the last couple WWDC's is Swift UI. If you're unfamiliar, it's a UI framework that makes writing UI code much lighter and easier by using a lot of concepts that have been popularized by things such as React.

Swift UI is clearly the future of Apple's platforms, and since I'm learning this stuff from scratch anyway, I may as well embrace the future. So my new app will be written in as close to 100% Swift UI as I can manage, and require iOS 14.

But, now I've just added something else I have to learn. Luckily, it seems like a lot of Swift UI's syntax is built upon the basics of Swift, so learning both together shouldn't be too bad.

The first thing I did was to try and figure out what all Swift UI is capable of. Luckily Apple has some great tutorials over on their developer site to help get started. These have been an invaluable resource and I'll be sure to reference them as I get going.

The other place I've been spending my time to try to get my head around what SwiftUI can do is on Paul Hudson's YouTube channel. These have been especially great. I'm not sure what it is about his explanation style, but his videos have led to more "aha!" moments when it comes to understanding the major concepts than most.

I started out with this video on NavigationView, which is one of the simplest and most basic concepts in a UI stack. A few of the major things I learned here:

A navigationBarTitle() is called on a view inside the NavigationView, not on the view itself. Why? Because a NavigationView can contain many sub-views, and each sub-view could/should/will have it's own title. This means that the following simple NavigationView stack looks a bit weird:

struct ContentView: View {
  var body: some View {
    NavigationView {
      Text('Hello world')
        .navigationBarTitle('Navigation')
    }
  }
}

Looking at this code you would think you'd apply .navigationBarTitle on the NavigationView itself. But this is simply because SwiftUI is handling something really clever: everything is a View. Views are the most basic foundation of SwiftUI, and so when you create a Text() it's actually not just creating the text itself, but also the entire wrapping view the text lives in. So as your NavigationView hierarchy gets more complex, this makes more sense:

struct ContentView: View {
  var body: some View {
    NavigationView {
      VStack {
        Text('Hello world')
      }.navigationBarTitle('First View')

      VStack {
        Text('Hello world, again')
      }.navigationBarTitle('Second View')
    }
  }
}

Now it's easier to see what's going on, and why we'd want to apply the title to a sub-view and not the NavigationView itself.

NavigationLink seems to be the way SwiftUI wants you to dig into and out of NavigationView stacks. But, you can get around this and use custom Buttons's if you bind them to certain variables

I left the video with a bunch of questions, though.

Why does the wrapping view struct implement the View protocol as struct ContentView: View, while the body property does body: some View? What does some View mean?
In the video he applied some decorators to his variables like @State and @ObservableObject which I have no idea what they do. He also sometimes passed a variable as it was named, and sometimes with a $ in front of it.

That's fine, I've only just started looking at SwiftUI code, let alone understanding it.

And it just so happens that there's a video on the same channel that explains this: What's the difference between @State, @ObjectBinding, and @EnvironmentObject?

This video was awesome, and it explained so many wonderful things to me

SwiftUI's views are all structs, not classes.

Why is that important? Because a struct is passed by value whereas a class is passed by reference. Additionally, once you've created a struct, it's immutable and can't change. This makes sense if you think about it in terms of another type of struct, a number. Once you create the number 5, you can't change what the number 5 means. This is different to a class which is instantiated and its location in memory is referenced. Once you initialize a class, not only can you update its properties, but all other references to that same class instance will also instantly get those changes.

How does this relate to structs? Well, if our view structs were permanently immutable, then we'd never be able to update them with new data. To solve this issue, SwiftUI provides the @State and @ObjectBinding decorators. What these do is they tell SwiftUI that these specific variables might change, and if they do, then the View should re-render.

What's the difference between @State and @ObjectBinding? Simple: a @State has one-way binding, meaning data only flows one direction, while @ObjectBinding has two-way binding, meaning it can change in both directions.
This also answers the question I had earlier about why some variables had a $ in front of them. When they do, it means that they're bound, and therefore should be monitored for changes. Without it, the compiler will just fix them to their value during compile time.

These videos have been hugely helpful so far, and Paul is a joy to watch. I'll be checking out more of his SwiftUI videos as I learn. But I think at this point I understand enough of the code being written in these videos that I can start prototyping some parts of my app. The best way to learn is by doing.

A (new) place to start

Joe Schmitt — Mon, 29 Jun 2020 14:02:35 +0000

This post is part of a (hopefully) long-running series of Dev Diary entires on my process of teaching myself Swift and Swift UI in order to build an app.

The past 13+ years of my career have been defined by constantly starting new things. In school, I thought I was going to be an interactive UI designer, designing the most beautiful and fluid interactive Flash (lol) web experiences you'd ever seen. But I discovered an itch for building instead of designing, and so taught myself to program instead (ActionScript at the time).

My first job right out of school then was as an Interactive Developer, despite getting a BFA in design. Not coming from a programming background and holding a programming job was terrifying, but the thrill to learn kept me at it, and I ended up building some amazing projects.

But mastery over Flash and ActionScript was not job security, and sure enough a few years later Flash fell out of favor (rightly so, it had so many problems) and web standards was the new hotness. So I buckled down and learned HTML, CSS, and JavaScript. Soon I was building cool new products using web standards.

And on and on it went: learning C and Objective-C, Angular (when that was a thing), ES6, NodeJS, TypeScript, etc.

My favorite thing to tell new engineers that get frustrated by how often and quickly this field changes is this: because everything is constantly new, it means you're only ever 2 years behind the experts. Everyone is new at it, and every new start gives you an opportunity to be successful again.

And so here I am again looking towards another new start. But this time it's not driven by career advancement, but more just general curiosity. I've been wanting to scratch a specific itch of an App idea I've had for a few years, and all the new stuff Apple announced at WWDC 2020 got me excited enough to try it out.

So I'm going to try something new again, but this time, two-fold: I'm going to teach myself Swift and SwiftUI while trying to build an app, and I'm going to document my learning and building process in public. My hope is that anyone reading this (and my future struggles and learnings) will be able to glean some kind of insight into how to learn something new.

And so here's to a(nother) new beginning.