My software dev setup

I’m a nerd.

That’s probably not a surprise, but I also REALLY like talking about the things I’m nerdy about. One of those things is working on my workflow: introducing a new tool, writing a useful script, tweaking a keybind, etc. Now you might say “why would you work on your workflow when you could just work on your projects?”, and to that I say: Well, my workflow is a (never-ending) project for me.

So, this whole blog post is just an excuse for me to gush about the tools that I use. Let’s go!

I live in the terminal

I learned how to use a terminal / command line back in the MS DOS days. The efficiency of literally telling the PC what to do is just completely unbeatable in my eyes.

As a terminal emulator I use Alacritty. It’s a minimal emulator that’s fast and can easily be configured through a text file. It doesn’t have multiplexing (I have tmux for that), and it doesn’t have font ligatures (because I don’t like them anyways), so it might not be the best fit for some people. For me, it does everything that I need it to do.

Arch Linux(, btw)

At least for personal stuff, I use Linux; or more precisely Arch Linux.

Linux is simple, I can configure pretty much everything through a text file somewhere, and it doesn’t get in the way. One thing that I severly dislike about Windows and MacOS is that they are way too opinionated for someone like me. For a lot of users this is completely fine, but I need to be able to tweak things under the hood, I want to control what’s installed on the system, … I want to use the system how I see fit.

Windows has very strong opinions on what needs to be installed on the system, it’s barely customizable, and most developer tools, at least for the programming languages I use, only support Windows as an after thought anyways. Add to that the frankly disturbing amount of telemetry, putting ads in my start menu, the recall announcement…

MacOS is at least UNIX-based, but blocks me from doing very simple tasks sometimes. My biggest annoyance being code signed binaries: If you have a chain of binaries that you need to run for your application, and you need to inject code into one of those binaries (for profiling for example), then MacOS likely won’t let you, even if it isn’t a signed binary that you need to inject with code.

Instead I use Linux. It’s snappy, it’s free and open-source, it’s everything BUT opionated and gets out of the way when I want to do something specific.

Linux is incredibly customizable, no matter which distro you choose. I use Arch, and when you install Arch Linux, it has almost nothing installed out of the box. It’s far from a “complete” system, but rather a “build your own distro” type of Linux. Obviously this means that tinkering on your system must be a fun to you, otherwise there’s other Linux distros that might already do exactly what you need.

For me this is perfect though. I have very fine control over what’s installed on the system, and on top of that: Arch’s software repositories are very up-to-date with upstream!

Probably the most important thing about Linux is that I can install what is called a “tiling window manager”. When you open applications in Windows, MacOS, or most Linux desktops, you get a floating window, and multiple windows usually overlap.

The Linux ecosystem has a couple of so called window managers that arrange the windows on your screen automatically such that they fill up as much screenspace as possible without overlapping. For example, if I open my terminal, it would fill up the full screen. If I then opened my browser, my terminal window shrinks to only take up half the screen, while the other half is alotted to the browser.

I could try to explain this for a long time, but nothing makes this as clear as seeing it in action. My window manager of choice is Hyprland. If you want to see what using a tiling window manager is like, check out their examples! Keep in mind, most of that workflow is completely keyboard based: Switching between windows and workspaces, opening and closing applications, etc.

MacOS has somewhat of an alternative called Amethyst, but it’s very bare bones, and I still need to do workspace management through MacOS’ terrible and inflexible desktop system. There’s also yabai, which looks way more powerful than Amethyst, but the installation process is pretty involved and I don’t want to do that on my work laptop.

Neovim

As I said earlier, I do everything I can in the terminal. This includes editing text, be that notes, config files or code. My tool of choice for that is Neovim.

(Neo)Vim is a keyboard-focused text editor that runs in the terminal. The most genius thing about it is its modality. When you open a file in Vim, you start in “Normal” mode, which is used for navigating the file and manipulating it sans inserting new text (moving, removing, or yanking text that is already present). For example, your h, j, k and l keys are used to move the cursor left, down, up, and right respectively. When you want to write new text, you switch to “Insert” Mode, where your keyboard presses, for the most part, just insert text.

These modes (and there’s a couple more) makes it so the keys on your keyboard have many different uses and you really never have to leave the keyboard when using Vim. It does also mean that there’s a learning curve to learn the basic keybinds/motions, and that can be quite an investment. But using it just feels so good… I use Vim motions wherever I can. Even in my web browser I install a plugin to give me Vim-like keybinds.

I got into Vim/Neovim at the start of the pandemic. A month or so before that all started, I saw a coworker of mine FLY through code using Vim, and it was incredible. The thought of trying Vim got even louder when, suddenly, we couldn’t go outside in the middle of spring and summer. I dove in head first and never seriously looked back.

There was a time where I tried emacs for a bit, but because Neovim seamlessly intergrated into my terminal focused workflow, it could never really replace Vim for me. Before I started using Vim, I used VSCode, and had to use the intergrated terminal for shell interaction, but now my editor just runs in the terminal.

Like all of these tools I use, Neovim is highly customizable. I have a, in comparison with others at least, fairly small config. I don’t use a ton of plugins, and I keep the config as such lean and small.

Nowadays Neovim is irreplaceable for me. It’s central to my workflow, and I hope I’m never forced to use anything else

Tmux

This is the last core piece of the puzzle for me. Tmux is a “terminal multiplexer”: It’s a tool that just runs other shell processes and can either run these processes in different tabs (think browser tabs), or split the window you have into multiple smaller windows (also called panes), or both. Here’s an example of how that could look like:

You can primarily see that my terminal window is split into three panes: on the right is my editor (Neovim), on the top left I have another instance of neovim editing a different file, and on the bottom left I have a regular shell running where I was moving files around.

At the top there’s a small bar that shows my tabs: The currently focused tab is the one you can see right now, but you can also see that there’s a second tab and that’s where I’m running the development server for this website in the background.

Having all of these things next to one another, being able to put processes in the background but within reach is incredible.

Moreover, in the top right there’s a small piece of text saying Session: capturedlambdav2. You can have multiple tmux sessions running in parallel, and switch between them easily. Especially at work this is incredible, because it allows me to switch between different projects with just a few keypresses.

But if there was one feature that I cannot miss anymore, it’s detaching. Detaching from a tmux session means that you leave tmux, but keep the session running in the background. This works, because tmux is running a small service in the background to keep these sessions alive. You can even keep these sessions alive without being logged into the machine, which makes any sort of IT work on remote machines sooo much easier:

Imagine you have a server running somewhere, and you need to run a long-running update. If you would just log into the machine and start the update, then you would need to keep the connection to the server alive, otherwise the update process would die. Instead, after logging in, you can start up tmux, start the update process from inside the tmux session, and then you can detach. This puts the process in the background and you can even log out of the machine without stopping the update.

Later, you can just log back in, re-attach to the tmux session you started, and it’s like you never left. All the output your process produced is still there and you can easily scroll through it to see if you missed anything important. If there’s a prompt awaiting your input then that’s still there waiting. Back when I was working as an admin, I used this a lot to, for example, move large amounts of files over night, doing the occassional manual backup, etc. If you’re an admin over Linux / Unix systems, tmux needs to be in your toolbelt.

Conclusion

This was fun. These are the four big and important pieces of my workflow. Unfortunately, at work I have to use MacOS instead of Linux (the only other option was Windows), but it’s close enough despite the annoyances. Here’s hoping that I get to use Linux at work sometime in the future, haha.

I hope you learned something from this! As I wrote in the beginning, I love nerding out about my workflow. It’s just so much fun watching these pieces come together, especially when I can shape and tweak them exactly to my liking. Maybe in the future I will look into specific tools, especially when they’re new to me, and write about exploring them; that could be fun as well.