For the longest time, I was under the impression that moving to a terminal based development environment takes a lot of time and effort. But after moving to one, I would say this is only partially true.

There is a stark contrast between having a productive environment and having the perfect environment.

What is considered a productive environment definitely depends on the person, but I would go as far to say that most people would be surprised by how few things they need in order to be productive. I won’t deny that there is some initial time investment, though my point is rather you get out what you put in.

The more time you spend understanding and building workflows that work for you, the more productive you come out of it. I could say this for any development environment, but I’ve found that it is the most customisable and fun in a terminal based one.

It doesn’t take long to realise that you can never actually finish building your environment, it will always be a WIP.

The Rundown

Some of the main tools/components I have as part of my environment.

Alacritty

My terminal emulator of choice for its simplicity and alignment with the philosophy of composing tools together.

This means you won’t find things like tabs or splits (which are best left to a window manager or terminal multiplexer) nor niceties like a GUI config editor.

Alacritty was built from the ground up to be highly extensible and as a result its base feature list is very conservative. This means no bloat.

The OpenGL rendering is also a huge performance bonus.

• https://alacritty.org/
• https://jwilm.io/blog/announcing-alacritty/

tmux

My day to day workflows all take place on the command line inside a tmux session.

An absolute game-changer for helping me with general context switching and reducing the cognitive load when working with many projects at once.

I primarily use sessions and windows, rarely panes.

Asciicast thumbnail is a bit borked - the tmux statusline is not rendered properly 🤷

Zsh

A very powerful shell with many new features and differences to bash.

My zsh config is very simple and I intend to keep it that way.

• I only have a few basic zsh functions, aliases, and bindings at the moment
• A simple (but primitive) way of loading things dynamically

I don’t use Oh My Zsh as I found myself rarely using the extras, but perhaps the real reason is that I’d prefer to know how things work under the hood.

You probably know by now that I’m a simplicity enjoyer.

My shell looks like this:

A customised variant of the ‘pure’ powerline10k theme - see theme config

Neovim

The humble code editor. The cornerstone of any DEV environment.

Writing a short paragraph about it won’t do it justice so I’ll probably dedicate an entire post about my Neovim config in the future.

All I’ll say for now is that the people working on Neovim have created something amazing.

vimwiki

Although vimwiki is a vim plugin I use inside Neovim, it is not actually related to editing code.

As the name suggests, it is a personal wiki.

I’ve completely migrated off Notion and now manage everything inside vimwiki for things like:

• task lists
• diary
• notes
• work wiki
• personal wiki

Being able to use my personalised editor for writing can only be described as “seriously smooth”.

When I’m working on something and need to quickly jot something down or need to look something up in my notes I can do so without breaking the continuity.

Lazygit & Lazydocker

Two very functional and pragmatic tools I use daily.

The tool completely eliminates some tedious parts of my git workflow and the CLI interface is suprisingly ergonomic.

• https://github.com/jesseduffield/lazygit
• https://github.com/jesseduffield/lazydocker

Dotfiles & Dotbot

I use my dotfiles for both my personal and day job work. The dotbot tool makes it reasonably easy (though still a bit iffy) to replicate my environment on another device.

Final Words

There are still so many things I want to improve for my setup, but I’ve decided to not rush things - I’m in it for the long haul anyway.