One of my favorite things is reading about the tools other people use, and talking about the tools I use. When I read a post recently about a data journalist's data tool belt, well... I knew I'd have to share my own software engineering tool belt, too.

So, here's my software engineering tool belt.

There are a lot of tools that I use, and not all of them bear mentioning. I've left out some of the tools that are probably very common or not super interesting, unless I particularly love those tools.

The tools I've included are categorized roughly based on things that are directly for coding, vs. all the other supporting tasks that are part of software engineering.

Coding

One of the core tasks for a software engineer is writing code. These are the tools I use to do that.

neovim

I've written before about my Rust vim workflow, and neovim remains my editor of choice. vim entered my tool belt in 2009 and became my primary editor in 2011, and no looking back since. I've dabbled with other editors, but vim continues to shine.

In particular, modal editing is a thing of beauty (once you get used to it). It's also highly configurable, and I think as craftspeople we benefit from honing our own tools.

I also use neovim for almost all the writing I do. Some is in Obsidian (more on that below), but otherwise, it's neovim all the way. Design doc? Neovim. Blog post? Neovim.

tmux

Terminal multiplexers are amazing for efficient terminal workflows. They let you have multiple pseudoterminals in the same terminal window, and you switch between them with your keyboard. It's a lot easier to stay organized than when you have to alt-tab through thirteen different unlabeled terminals during your 2am debugging session!

I've used a terminal multiplexer for about as long as I've used vim. The first one I used was GNU Screen, but I switched to tmux about five years ago. It's easier to search for documentation on, and it was easier to do some of the configuration I was interested in.

My usual workflow with tmux is to open a few windows:

• one for bash (usually git commands), which is my home base
• one for my editor, with a persistent session per project
• and sometimes a third, for a test runner

And then I spin up more windows as I need them. I create one tmux session per project that I'm working on, and it really helps me stay focused on the task at hand and also not lose my place in projects that I'm putting aside for a moment.

tmuxinator

I also use tmuxinator for scripting my tmux sessions. This is a small but definite quality-of-life improvement.

mosh

I'm often writing code or running experiments on my home server, and when I do I usually use mosh. It gives me the experience of lower latency, which is crucial when I'm traveling: From my parents' house, the latency is so bad as to make my server almost unusuable—but with Mosh, it's perfectly fine!

It has other benefits, too. For example, you can stay connected as you roam between networks! This is particularly handy for working from a coffee shop, or was when that used to be a thing I did.

flamegraphs

This isn't one particular tool, but something I look to generate whenever I'm working on a performance problem. The one tool I use the most for this is cargo-flamegraph, which lets you very easily profile a Rust program and generate a flame graph from the profile results.

I've found these invaluable in figuring out where my programs are spending all their time, and what I should do about that. Cannot recommend them highly enough, they're life changing.

git and various forges

git is the dominant version control system today. Okay, citation needed maybe? But it's at least dominant in the places I've been, including the world's biggest bureaucracy.

I don't feel particularly strongly about git itself. I'd probably be fine something else came along tomorrow and supplanted it with clearer UX and whatnot. (Fossil is particularly interesting.)

What I do feel strongly about is forges. I use GitHub for work, because... it's work, and that's what we use! But outside of that, I use SourceHut, because I believe that free software projects should use free software code hosts. It seems kind of backwards and somewhat dangerous to give one very large corporation this much influence over the direction of open source software.

Knowledge Management, Tasks, and Notes

Another big part of being a software engineer is keeping track of things you know and the things you need to do. I've accumulated a few tools I use for this.

Obsidian

For my personal software projects, I use Obsidian to take a running log of notes of what I'm doing and my plan for the day. I started using it during my Recurse Center batch. It is also the home for various notes and references that I want to come back to, lists of blog post ideas, and project ideas.

reMarkable

I use my reMarkable tablet to make my personal todo lists, read papers, journal, sketch architecture diagrams, and make small illustrations¹. It's an invaluable part of my workflow. Before I had it, I used a lot of individual separate paper notebooks—I took four notebooks with me on a work trip once, and this lets me condense that all down to one.

Highly recommended if you, like me, find it much easier to read when you're away from a computer screen. With this thing I can actually get through, and comprehend, computer science papers.

kagi

My search engine of choice is one you may never have heard of, kagi. I saw someone using it at RC and asked about it, and he raved about it, so I gave it a shot. In general, it feels like the results I get are higher quality than the results I get from Google, Bing, or other search engines I've tried.

One of the features of kagi is that you pay for it. This is a drawback in many ways, as it limits the accessibility of the tool, but it's a plus for me because I'm more confident that I'm not the product. It better aligns incentives between me and the search engine.

What's in your tool belt?

So, what's in your tool belt that you absolutely love and cannot work without? If you write a post about it, please send it my way. I'd love to see it.