Setting Up a Dev Machine for the Unknown

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

February 2020. There’s news of a virus spreading abroad, the Philippines just confirmed its first cases, and nobody is quite sure how seriously to take it. Offices are still full. In hindsight, this was the last “normal” month — which makes it a strangely good time to write about something I’d been doing anyway: making my dev setup portable enough that where I work stops mattering.

The test

Here’s the test I hold my setup against: if this laptop died tonight, how long until I’m productive on a new machine? If the answer is “days,” the setup is a liability.

My answer, broken down:

1. Dotfiles in a Git repo

Shell config, aliases, Git config, editor settings — all in one repository with a setup script. Clone, run, done. Every tweak I make on one machine gets committed, so no machine ever becomes “the good one.”

2. Projects that bootstrap themselves

Every Laravel project I touch should answer “how do I run this?” with something close to:

git clone <repo>
cp .env.example .env
composer install && npm install
php artisan migrate --seed

If a project needs a wiki page, a senior dev, and three undocumented steps to boot, that’s debt. The .env.example file is documentation that can’t go stale, because the app dies loudly when it’s wrong.

3. Databases are disposable

Seeders over SQL dumps passed around in chat. If I can’t rebuild a working local database from migrations and seeders, the project owns me instead of the other way around.

4. Nothing important lives only locally

Code pushed daily, even WIP branches. Notes in something synced. SSH keys are the one thing I treat as per-machine — generate new ones, add to GitHub and servers, revoke the old. Keys are cheap; reused keys floating across dead laptops are not.

5. Know your tunnel out

A VPN or a jump host you’ve actually tested, for the day you need to reach a client server from somewhere unexpected. Discovering your access doesn’t work while production is down is the classic version of this failure.

Why bother?

Honestly? At the time, the motivation was mundane — a laptop nearing end of life, and the memory of January’s ashfall week still fresh. Portability felt like good hygiene, the dev equivalent of keeping a go-bag.

One month later, “working from somewhere unexpected, indefinitely” stopped being a thought experiment for every developer in the country. I didn’t see that coming. But the go-bag was packed.