6 ms·
Reminds me of a colleague who RDPed into each of our 140 subsidiaries to change a config file. He had a list of servers on his desk and ticked off every server.
by lhaussknecht 13y ago
Reminds me of a colleague who RDPed into each of our 140 subsidiaries to change a config file.
He had a list of servers on his desk and ticked off every server.
Took him the whole day to apply the changes.
- cstross 13y agoTwo words: job security. (Also: lots of folks really don't enjoy learning new stuff. Or new ways of working. No, they really don't. Even if the new techniques are vastly better and more efficient. Put this down to a human cognitive bias favouring the tried-and-trusted over new-and-untested. There's a lot to be said for that when you're a neolithic hunter-gatherer or an iron-age peasant -- if you try something new and it fails, you maybe get to watch your family starve next spring -- but it's a bit less useful as a rule of thumb in the data centre.)
- pnathan 13y agoTotally true. Even when the path is seamless, initial costs are nearly zilch... learning new things and applying them is anathema to many devs.
- mathattack 13y agoYou can get blamed for changing something! The power if inertia....
- dijit 13y agoI did this with nagios configs in my first job :(
- alephnil 13y agoWhen the service guy in a former job quit, the databases at the customers' production servers started to be corrupted. It appeared that he had manually logged into the database at every single customer regularly and fixed the problem on site. I don't know if had told the responsible developers (I worked on a different product), but after it was apparent that the system was not stable.