future me will thank me for my dev setup!

I saw Prime’s My Dev Setup Is Better Than Yours earlier this year and got inspired by it. I tried to mock it but that didn’t go too far. I abandoned it and never got serious about it. If you haven’t seen or heard about it, the gist is (a) Prime shows an approach that works for him and (b) he explains his dev setup is better than mine because it’s his; and it works for him and because it is so custom-made for himself, it makes him productive.

Last year I changed jobs, which implied a new laptop and new vigor to create my “dev setup”. But this time, I couldn’t invest time into adding my features and started looking for tools that would fix this for me instead. I found plenty of them, some I had tried earlier and some new ones as well. Instead of doing a “classic Harman’s analysis” (which is more like analysis-paralysis) I went ahead and chose stow and wanted to see the mileage I will get with it. Overtime I added just to the mix and I guess I’m super happy about how it looks. There are too many things I can improve, but that goes for so many other things in my life.

So behold, sudo make me a sandwich or my dev setup, which is the best for me and might not work for you at all. But future Harman will for sure thank current Harman (epoch: 1769955510) for organizing the dev setup and writing a few words about it. It’s not perfect but its mine.

In a nutshell:

• brew bundle manages the bottles and casks that I need
• just reduces the number of bash script needed
• stow manages the dotfiles

There are a lot of things I want to improve though. And maybe I’ll stop being lazy and do them sometime in future.

Improvement 1: simpler bootstrap steps: As of 02d2867, the bootstrap requires me to install homebrew, install just and stow using homebrew, clone this repo, define XDG_CONFIG_HOME¹, and install required software using brew bundle and configure most of them with stow. That leaves out folder structure for Git and SSH key generation for Github.

If I spend some energy learning make and its idiosyncracies, I can ditch just. And if I write a shell script to overwrite partially or completely the .config that I create, I can ditch stow. Since my dev setup is on a public Github repo (and will be public forever, I guess), can clone it using HTTPS for the first time on /tmp directory and just go brrr with the setup e.g. to create XDG_CONFIG_HOME, folder structure for Git, brew bundle and force updating dotfiles.

Since I don’t buy a Macbook so often, this improvement doesn’t provide the ROI required.

Improvement 2: make it work for my servers too: I don’t buy Macbooks too often, but I create and delete Linux servers too often. Right now, my setup implies only local setup and not servers. I still largely use Claude Code on my server to set them up and manage installations. Solving this problem will actually make me saner. I’ve some ideas where I can test them up with ephemeral machines²

Improvement 3: missing configurations: I use ripgrep, fzf, direnv and many more other tools but I use them raw. I should spend some time and integrate fzf well into the workflow instead of manually adding flags.

Improvement 4: smaller neovim configuration: Right now, I use kickstart.nvim and I’ve been using it for some time. I understand neovim well enough to use a simpler and modular neovim configuration. But I’ve been too lazy to get to doing this.

I believe there are many more improvements that I believe can be done, which I can’t think about right now. 2025 Harman would have created a list of TODOs which would give him “Phantom Obligation”³. But, instead I chose to dump them here and address it when I address it.

EOF