When developers do their work, they should constantly bear in mind two scenarios.
What if my computer blows up?
What if I blow up?
These two questions encompass what I like to call ‘the pessimistic ultimatum’, which questions what might happen should the worst happen.
What if my computer blows up?
Let’s consider the first scenario. Though it’s unlikely your computer will ‘blow up’, there’s always the chance your hard drive will fail, or your laptop will get stolen, or you accidentally run some dangerous rm -rf * command.
You’ve been coding solidly for five hours, and have been saving locally every few minutes, when suddenly your laptop dies. What do you do now? Is there any way of getting your hard work back?
One should always bear in mind the possibility of hardware failure, and ensure they have at least a moderately up-to-date version of their work copied somewhere not on the local machine.
GitHub, or some other source control system, is probably the best solution. Don’t be afraid to push your changes on a fairly regular basis; at least a few times a day is good practice.
An automated backup system is a good alternative if you can’t be bothered with Git. Keep your project inside something like Dropbox, where all changes are backed up in the cloud and files can be pulled down remotely from any computer, provided you remember your Dropbox username and password.
At the very, very least, copy your work to another device, be it a portable hard drive, USB stick, or another computer. However, these backups are subject to the same risks as the local computer, and I even know of someone whose computer crashed halfway through copying to a USB drive, rendering both copies useless.
What if I blow up?
Though your own spontaneous combustion is even less likely than that of your computer, you can never guarantee your life won’t be cut short by an unexpected bus careering around the corner, or a knife-wielding murderer, or a slip onto the cold, unforgiving pavement.
It doesn’t necessarily need to be your own demise that gets in the way of work- you can be taken ill, or forget the password to your account, or simply forget to document your work before switching jobs.
Backing up your work to multiple locations is half of the problem. The other half is sharing your knowledge with others so that your work can actually be put to good use.
Let’s go back to that code you’ve been working on for five solid hours. Stop and think to yourself: ‘if I pop my clogs in the next couple of hours, will someone be able to find my work? Will they understand how to set it up, what it does, how to fix it if errors occur? Would it be simpler for them to rewrite from scratch everything I’ve written to date?’
Every minute of work that you do is utterly worthless if it isn’t backed up, or if nobody understands it. It is well worth investing at least a few minutes in writing a README.md that explains the purpose of your code and how it can be used.
Documentation isn’t the be-all and end-all, however, and nobody will be able to read your README if they don’t know where your project lives, or even that it exists at all.
I’m not saying that you should email your last will and testament at 5pm every day to everyone in your corporation. But do make sure that you make life as simple as possible for whoever lands the unfortunate job of overseeing your project if you’re not around. Do they know where everything is? How to set everything up? What to do, who to contact and where to go if something goes wrong (or right)?
If you disappear off the face of the earth today, will the organisation be able to cope tomorrow? Answering this may mean going as far as training another member of staff so that at least one other person knows [insert obscure programming language here]. Or making sure another developer knows a password to the system. Make sure you cover every eventuality.
We all want to be indispensable to our employers. The very best developers achieve this by being as dispensable as possible.
