[compscistd]

Our server went down for a couple of days and if we could "run our system on localhost", I'm positive we would have been back online very quickly as opposed to the multiple days it took to track down stored procedures not in version control. Front-end was left twiddling their thumbs during the outage because the server wouldn't run on local and our frontend wouldn't run without a server (we neglected updating our frontend model mocks for years).

Did we learn our lesson from the outage? A big _nope_. I suspect it's because being able to run a somewhat complicated system on local requires thinking in brand new ways with benefits that aren't very obvious from the outset. After that experience, I sympathize a lot with the author's points and hope to work in an environment (ha!) where spinning up a docker container is all it takes to have a _full_ dev environment.

[hinkley]

I often set up a "how to create a dev environment" wiki and then we exercise it many many times.

IBM got a bad shipment of laptop hard drives that exhibited a MTBF of about 2 years, and our equipment dept bought a stack of laptops from that batch. Over a summer we had 6 machines go belly up. Mine was number #5. People still looked at me like I announced that I had stage 3 cancer. Oh you poor poor man. I found this reaction disappointing.

By then the process was about as documented as any I've had. It just took me a day to get it up and running (because the base image left a very slow step until after 2nd boot, which I still maintain is dumbness squared).

A coworker from that cohort had an experience that I still use as an example. He tried to put his work laptop in the back seat of his car. He missed and hit the door frame. Killed the laptop. Similarly, taking your laptop down the stairwell could be a one way trip to the trash bin.

If the information is important for us GET IT OFF OF YOUR COMPUTER. As soon as you know. Put it in storage, or at the very least in some coworker's head/computer. If you do this, consistently, then losing your machine is a shitty inconvenience, but nothing more dire than that.

[gamacodre]

Strongly agree. In the last three years I've rebuilt my macOS laptop from scratch twice (dead hard drive, and a dev tool run amok), and once swapped it for a different size because I really wanted the larger battery.

My co-workers were appalled, but I had less than a day of downtime each time. With continuous backup to an external drive (always on while I'm working), a password manager I can also store certs in, and keeping everything important in a cloud-backed git repo, there isn't a single thing on my work computer that's hard to replace. It's been fantastic.

[mkingston]

Nix is one part of the solution to this problem. About a year ago I lost my data to a corrupt file system. I tried to recover it for some time, eventually gave up, and was back to a working machine, with all the software installed and configured as it had been previously, within two hours of a disk wipe. Most of that time was waiting while nix downloaded and installed packages from the internet.

[pdimitar]

I wish I could easily find beginner-friendly Nix tutorials. Even the official ones immediately assume you know their terminology.

Do you have any good links?

[mkingston]

Nix Pills was the "standard" intro text I started with a couple of years ago. At the end, you'll be able to navigate packaging with Nix in general, even if you're a little unfamiliar with some of the modern idioms and tools. It's very approachable, not especially short, not especially long.

https://nixos.org/guides/nix-pills/

[bozzcl]

Local backup and remote backup. Always.

I only write code on my laptop, but I sync my projects folder with my cloud desktop. It's saved me from several crappy accidental losses.