My first job right out of college was with a small software company that developed systems for medical offices. The company covered every aspect from start to finish, which included developing the network/hardware equipment and software, installation, and support.
Being a small company, the sale of a system was a big thing. In our town, word of mouth helped create sales, which helped us make payroll, so keeping customers happy was very important.
[ Want to cash in on your IT experiences? Send your story to firstname.lastname@example.org. If we publish it, we'll send you a $50 American Express gift cheque. ]
My primary job was to program, but I also helped out with installation and support. I found myself frequently having to go to a customer site and troubleshoot a network or hardware problem. Additionally, I was called upon to help with installations -- not just the software I was developing, but things like printers and PCs as well. That's the nature of the small business.
Business was booming, and our staff was having a hard time keeping up, so the owner of the company decided to hire some young college students to help out, especially with the basic tasks and, after evaluation of their skills, wherever we could use their assistance. Most were very inexperienced, but some were pretty smart -- the hacker type.
Some of these hacker-type students would accompany me on service calls when I was needed. At the time of this incident, I was loading a lot of patches and software upgrades to make the programs run better and to eliminate bugs.
I headed out one afternoon to do some software loads with one of the students who'd proven himself to be one of the more experienced that was working with us at the time -- or at least he seemed that way. The job involved rebooting the server after loading the patches. We arrived on site, and I asked the office manager if I could load the patches and then let her know when it was time to reboot. With her approval I loaded the software, then asked my young assistant to down the server. To my horror he walked up and just unplugged it from the outlet.
Down went everything. All the employees who were logged in lost their connection, and some even lost the data they were working on. I looked at the young man and asked him what he was thinking. Everyone in the busy office was looking at him, including the office manager. He started shaking, and I started to feel really bad for him.
[ Tired of being told to do more with less? Participate in InfoWorld's Slow IT movement: Rant on our wailing wall. Read the Slow IT manifesto. Trade Slow IT tips and techniques in our discussion group. Get Slow IT shirts, mugs, and more goodies. ]
I later found out that he plain did not know how to "down the server" and thought it was a matter of just unplugging it. But the way he was sweating and shaking will forever be etched in my mind. Ultimately, it was my responsibility to get the job done.
It can be tricky getting acquainted with someone else's knowledge and skills. My lesson that day was to never assume a junior coworker, especially a young student, knows the technical aspects of what they are doing. Find a way to politely ask, and explain IT jargon just to make sure they know what you mean. I also learned a few lessons in service recovery -- the hard way.
Supergeeks fess up to some of the dumbest things they've ever done -- and the lessons they learned as a result
IT heroes toil away unsung in miserable conditions -- unsung, that is, until they make a colossally stupid mistake
Idiot-proof your enterprise with these 10 hard-luck lessons of boneheaded IT miscues
The trick to nipping IT miscues is testing, testing, testing, as these hard-luck lessons in boneheaded quality assurance attest
Are you a script kiddie or a hacker hero? Take our quiz to find out
More dirty tech deeds, done dirt cheap
Somebody's got to do them -- and hopefully that somebody isn't you