I just grew up with one eye and figured out how to navigate a world designed for two.

What that actually means for a software engineer is that depth perception comes from colour and contrast, not binocular vision. My brain learned to read spatial information from hue, brightness and saturation the same way most people read it from parallax. It is not a workaround. It is just how I see.

That constraint turns up everywhere in my setup. But nowhere more deliberately than in my terminal.

The problem with dotfiles

Most engineers have dotfiles. An alias here, a function there, a .zshrc that has grown into something they are afraid to look at directly. Mine started the same way.

The problem I kept hitting was platform drift. I run macOS at my desk, Linux on remote machines and Windows when I am doing embedded development. Three shells that is zsh, bash, PowerShell 7. Three environments where muscle memory should be identical but never quite was. I would type gs on Linux and get a command not found. I would run a Docker alias on Windows that silently did the wrong thing. Small friction, constantly.

The standard advice is to just pick one platform. I cannot do that. The tools I use do not live in one place.

So I built a system.

59 files, loaded in order

The architecture is simple: 59 numbered topic files per platform, each covering one area of concern. They load in numeric order via a glob pattern — five lines of shell code that pick up everything from 01-exports through to 59-starship automatically. Adding a new capability means creating a new numbered file. Nothing else changes.

Each file is small and focused. 02-colours sets the terminal palette. 06-functions has shared utilities. 23-kubernetes has every kubectl wrapper I actually use. 37-kotlin has Android build shortcuts. The number tells you where in the load order something sits and roughly what priority it has.

The real discipline is the naming rule: every alias has the same name on all three platforms. gs works on macOS, Linux and Windows. The differences live inside the function bodies, hidden from the muscle memory that runs the command. Cross-platform consistency is a product decision, not a technical one. I made it once and the architecture enforces it from there.

Colour as engineering

Back to the eye.

The default terminal palette in most tools is some variation of dark background, bright white text, red for errors, green for success. That works fine if you have full colour vision and binocular depth. For me, colour has to carry more semantic weight because it is doing extra work.

I spent time choosing cyan, magenta, green and yellow as my four primary accent colours. Not for aesthetics. For function. Those four survive deuteranopia and protanopia simulations - the two most common forms of colour blindness without collapsing into the same perceived hue. The contrast ratios hold. The meaning does not blur.

I documented the decision in my engineering journal, entry 002. The reasoning matters: if I ever have to revisit it, I want to know why it was not arbitrary.

The mirror architecture

Every git push fans out to GitHub, GitLab and Codeberg simultaneously. Not three separate pushes — one command, three destinations, handled by remote.origin.pushurl. A pre-push hook auto-registers new repositories on first push so I never have to think about it again.

Gitea is a fourth mirror but it is more complicated: the ELB in front of it blocks HTTPS pushes from non-AWS IPs, so that one goes via GitHub Actions over SSH on a scheduled trigger. Infrastructure problem, infrastructure solution.

The sync-meta script keeps repository descriptions and topic tags in sync across all four platforms. Because maintaining four identical profiles by hand is how metadata rots.

The lazy-load trick

nvm adds roughly 200 milliseconds to every shell start. Not catastrophic, but noticeable enough that you feel it across a day of terminal use.

The fix is a stub function. Instead of sourcing nvm at startup, I define node, npm, npx and nvm as shell functions that load the real nvm on first call, unset themselves and then re-run the original command. The cost is paid once, on first use, not on every shell open.

Entry 004 in the engineering journal documents the tradeoff: the stub approach means tab completion is slightly delayed on first invocation. Acceptable. The 200ms-per-shell cost was not.

The journal

There are nine entries. They document: why the modular structure replaced the old monolithic file, why those four colours, how alias conflicts were resolved between platforms, the nvm decision, the mirror architecture, Windows static analysis setup, and Starship.

Writing them is not nostalgia. It is insurance. When I come back to a decision six months later and want to change it, the journal tells me what constraints I was working under when I made it. Most of the time that stops me from re-making the same mistake. Sometimes it tells me the constraint no longer applies and the decision should change.

Engineering is full of decisions that look arbitrary in retrospect. The journal is how I make sure mine do not.

The dotfiles repo is public: github.com/zaccessss/dotfiles

The project page with full breakdown is on my portfolio at isaacadjei.me/projects/dotfiles

Until next time.

Isaac