Yesterday was a snow day for most here in the DC region; we only got around six inches at the house, but other people from $WORK were reporting a foot or more. What could have been a good solid day of plugging away at stuff at home instead turned into snow shoveling, kid wrangling, and a late afternoon nap. So it goes.
Transcript of Perlcast interview with Tom Limoncelli, author of The Practice of System and Network Administration and Time Management for System Administrators. Lots of good stuff there, such as:
Josh: at one point in the book you say that acknowledging the user’s issue is as important as solving it. And why is this?
TL: people want to be acknowledged when they make a request - it’s very comforting. We system administrators don’t go for psychology much, but the psychology of what we do is really important. So if the user sends an email to Help, to create a ticket, but doesn’t get any kind of auto-reply saying “Yes, we received your ticket - here’s the number.”. A user isn’t sure if the ticket was lost or if it’s being worked on. And they’re going to be sort-of stressed until they get some kind of reply.
If you reply five hours later, and say “It’s done.” - that person has been stressing out for five hours, and probably thinking “Oh, these darn sys-admins, they don’t do anything”, and then they get the surprise “Oh they were working on it all along.”.
Well, that’s not good to have the user saying bad things about you for five hours. So if, instead, you reply right away, saying: “Hey, I got your message - I’m working on it.”. Hopefully give some kind of time estimate (“it should be done by tomorrow”). Then five hours later you send an email saying “OK, it’s complete.”.
Now, your user was only stressing out for five or ten minutes or even an hour before they got that initial reply. So psychologically, that’s going to make them like you a lot more. If you don’t do that and your co-worker does do that - their perception is going to be that your co-worker is a better system administrator, because they’re keeping them up-to-date - they’re keeping them informed about what’s going on.
‘The only rule is work’ (‘There should be new rules next week.’)
With git, we’ve invented a new world where revision history, checksums, and branches don’t make your filesystem slower: they make it faster. They don’t make your data bigger: they make it smaller. They don’t risk your data integrity; they guarantee integrity. They don’t centralize your data in a big database; they distribute it peer to peer.