Just some random observations, most of them snarky, that I’ve made over the last decade:
1. The server will always go down when you need it the most. Pretty self-explanatory.
2. The documentation is always no more than 95 percent complete. Unfortunately, using software is like running a mararthon: you have to complete it all or it doesn’t really count. A little known fact: if someone, by accident, does write complete documentation, the universe in mysterious ways conspires to undo it, or even add false information.
3. Inevitably, you will delete something you wish you had not. Once you accept this, you can move to the next step of recovery.
4. The most important thing you must know is when you are climbing out of the hole and when you are digging it deeper. I’m serious about this one. Not only can this be frustrating, but digging deeper can be catastrophic, not only for you, but for anyone who shares resources with you. “Oops. Just wiped the entire server.” Not a good way to make friends. Speaking of friends…
5. You will have to ask a lot of questions, especially when you’re starting. If you made it through graduate school, you’re probably used to being very independent and puzzling it out eventually. You’ll still have to do that, but remember the hole. Sometimes, you just have to ask.
6. Bioinformatics will make you feel stupid. Daily, if not hourly. So be nice to people who ask questions (also see #2): time was, you had no idea what the hell you were doing either.
7. It will always take longer than expected. Don’t delude yourself.
Why do we do this again?
mikethemadbiologist
You should become a botanist and go search for new plants in the jungle.
The jungle really likes computers and shows it by eating your laptop.
So no worries about crashing servers. 😛
For your first point, servers will often fail in such a way that they appear fine in every test that the sysadmin throws at it, but they are not functioning for remote users. That’s how my replacement and I spent my last day at work before retiring.
Servers can also fail from vendor-supplied and maintained software. I had a security incident from that. I also had a web server where the vendor supplied and configured the content management software. The configuration file for the Windows service that ran that software had become corrupted since the previous monthly reboot after MS updates. With the help of the vendor, that was an easy fix.
Most (all?) of these can be generalized to any scientific pursuit – especially, ESPECIALLY number 4.
Thanks, I needed that. There’s a kink in my neck, but I can’t tell if it’s from staring down at the bottom of the hole or staring up at the top while trying to figure out how to get there….
Lest people think you are exaggerating, a friend once took down the entire IBM Supercomputer Center when he borrowed a script and discovered that their flavor of UNIX interpreted “cd; rm */*” differently than ours did. The admins were delirious when they learned that it was just Stressman Strikes Again! rather than another full on assault by the Romanians.