What world backup day should teach us about development

Happy Daylight Savings Time to many of the readers out there. For me, it serves a few purposes. It means for the next few weeks I'll be waking up in the dark again, however, I'll have more daylight to enjoy after work. It also means spring is here and so is the potential for nicer weather. Daylight Savings Time is actually a friendly reminder for a few tasks I need to take care of. 1. It reminds me to change the batteries in my smoke detector, and 2. it means I need to back up my disk drives. I do full system backups twice a year. My setup consists of a rotating hard drive, two local hard drives, and an offsite cloud-based backup (done continuously throughout the year). It's one more than the rule of 3, however, one of the drives is getting on its last legs, and will be retired soon enough. My backups are encrypted in the event someone got ahold of my drives. And I use a password manager, with a paper copy in a safe, in case somehow my backup manager fails.

So, as I noted in the title. From a technology perspective, it's great that I have these redundancies, but as a developer what does this teach me. Well, I think redundancies teach us a lot. Having a plan B incase plan A fails, and even a potential plan C can be a lifesaver if something goes wrong. A case in point would be the OVH fire that happened recently. It is a blessing no one was hurt, however, there was a good chunk of time where services dealing with WordPress were interrupted across the world. Here are some of my observations of some of the redundancies we can use as developers or systems engineers.

1. Backup of your data. Something as simple as using a git repo can save you in the event that your system crashes. If you are self-hosting a git repo, make sure that data is backed up as well.
2. Have a well-planned system for rebuilding a machine in case it crashes. One of the most recent pet projects I worked on was creating automated scripts to set up developer machines in the event of a new hire, or system crash. Services like Boxstarter or Chocolatey can provide a lot of help in the redownloading and setup of these machines. Other ideas include machine images using cloning software, or developer VM's that can be downloaded as images.
3. Redundant service providers. At one of my previous work locations, they designed their system to have 2 different ISP's on their network in the event that one had an outage. Both used different technologies at the time (fiber / copper / coax). While this would be overkill if you use a cloud provider, as many of them have the redundancy done for you... if you are self-hosting, it might be wise to have a redundant location or backup cloud provider like Heroku in case of an outage
4. Keep your code/system platform autonomous. Granted, I don't see companies like Microsoft or Amazon going away, there are chances that pricing models can change. If you keep your code or system independent from the platform you use, you gain the ability to plug and play just about anywhere.
5. Design your code to be self-governing (Design against an interface, not an implementation). I've seen this before as well where a company wants to stay nimble and get their project work done quickly, so they will program their system against the 3rd party API, and treat their program as a wrapper. To future proof yourself, program around your own model object... even if that means borrowing elements of someone else. It is usually easier to create a transform method for a different 3rd party than it is to have to support 2 platforms or rewire a different API into your existing application. An example would be one of my open-source projects dealing with displaying weather info. The reason I can support multiple weather services was that I decided what my application needed and then wrote multiple wrappers for different APIs to match what I needed. This way, if a provider changes their terms of service or gets shut down, it doesn't kill my code.
6. Know more than one programing language. While it sounds harder than it is, I recommend having a solid foundation of 2-3 languages. Many companies today are looking for developers that can both write up a backend system in C# or Java, as well as write up frontend code in Javascript, or Typescript, using frameworks such as Angular, React, or Vue. As well, some companies might want Python or Ruby, or PHP devs. While it is fantastic to say, know all of these languages, my recommendation is to pick 2 to 3 to study know fairly well and focus more on the core development process and design. I say 2-3 because I feel that you might miss out on some elements of other languages you might not pick up on with your primary language platform. Because, yes, today you can write everything you need for a Webapp in HTML and C# or HTML and Javascript... but what happens when your preferred language falls down the list of popularity. Having a solid foundation in programming is more important than code languages, however, having more than one language doesn't pigeonhole you into that one language.
7. Feature flags or fallbacks. Sometimes a feature you release into the wild can cause more problems than it solves. Or sometimes, your feature isn't a feature, it's a straight-up bug. It's important to have the ability to switch your production environment over to the previous version OR be able to turn off your feature entirely using a feature flag. This way, in the event that your release to production doesn't go so smooth, you can quickly go back to what you were at before. Even Microsoft thought of this with System Restore, introduced with Windows Millennium Edition back in 2000. When writing code, especially if you are running an agile methodology, it is important you are able to turn on and off the code you are working on... especially if you are touching shared or base code.

What other redundancies may I have missed in my writeup. Comment below and share your thoughts, thanks for reading.