August 11, 2009

When inexperience and tech jargon collide

An IT tale of learning to communicate with and never making assumptions about your junior staff

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 offtherecord@infoworld.com. 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.

additional resources
White Paper - How to Improve Delivery of Advanced Web Applications

White Paper

Virtual Workforce: The Key to Expanding The Business While Cutting Costs

Get the independent advice and expertise you need to support a virtual workforce.

Go inside:
The three-step approach to making a virtual workforce a reality.
The four flavors of client virtualization technologies.
The three key initiatives that solve IT challenges.
Download now »
White Paper: Successfully Secure Your Wireless LAN With Wi-Fi firewalls.

White Paper

Addressing Linux Threats Leveraging Fewer Resources

The increase in Linux popularity has increased the frequency and sophistication of malware attacks. Read this 2 page white paper now to learn how you can protect your Linux environment with real-time protection that is certified by all major Linux vendors.

Download now »
White Paper - The 2009 Handbook of Application Delivery

White Paper

The 2009 Handbook of Application Delivery

Ensuring acceptable application delivery will become even more difficult over the next few years. As a result, IT organizations need to ensure that the approach that they take to resolving the current application delivery challenges can scale to support the emerging challenges. This handbook elaborates on the key tasks associated with planning, optimization, management and control and provides decision criteria to help IT organizations choose appropriate solutions.

Download now »
White Paper - Is Your Backup System Outdated?

White Paper

Mid-range Storage Considerations

A common misconception is that mid-range storage requirements are dramatically different than that of a larger enterprise. Mid-range storage users may require less capacity, but they have similar functionality and management requirements. This ESG paper examines mid-range storage needs and reviews a new solution that adjusts size while retaining value, performance and functionality.

Download now »
Accounting IT Guy 11-Aug-09 9:20am
Ouch..thats one way to down a server; potentially for good. Sounds like you brought an intern to do a sys admin level job. One thing about younger computer tech prospects........ they generally have limited corporate/production IT systems knowledge. They know all about PC games, the internet, and other consumer trends, but they do not know much about IT procedure/practices. It takes several years of daily exposure to build that knowledge. You cant assume they know anything until proven otherwise. Trust me, I know, I was one of them about 6-7 years ago. :)
tom@aegis-wi.com 11-Aug-09 9:38am
1 reply
Come on.....Downing a server is not quite a technical term.
prescod 11-Aug-09 12:48pm
At my company, the techies refer to it as "bouncing the server". I always imagine some newbie walking over and walloping the machine.
Hiram Q. Pustule 11-Aug-09 9:40am
1 reply
So many things I don't understand. Like first, why is this on three pages? And second, OK, sure, "downing the server" is a bit more than just yanking the plug, but ultimately, whether the intern pulled the plug or went to the Start button and requested a system restart, you were going to have users tossed off the server anyway, weren't you? It's much better to down a server softly because open files can be closed, new database transactions can be stopped while allowing current ones to complete, and so forth, but any intelligently-written OS (and I'm resisting the urge to make a snarky comment about Windows) should be able to recover from a sudden interruption in power. Because try as we might to prevent them, those kinds of things will happen. They're simply a fact of life.
Loerps 17-Aug-09 7:48am
Earlier in the post it was indicated that the users would be advised when it was time to reboot. This would be part of "downing the server" and would have been done if "downing" had been done properly.

Secondly, no OS can prevent the loss of all data when a system is unplugged. Saving of data is done at intervals while running, and also when a system is going through an orderly shutdown. No disparaging comment about Windows was necessary here.

cholera 11-Aug-09 9:41am
First off...it would be your fault for not giving instructions. Second, since you weren't going to down it until the office manager gave you the ok, so then everyone should have been ready for the server to go down anyways. I'm not saying that wouldn't have damaged the server or caused some other problems, but really it would have had the same outcome to the users.
Shadocat 11-Aug-09 11:15am
1 reply

What I liked about this is that this isn't about some lame new hire. It is about the author relating a mistake that he made and the lesson he learned from it. This article harkens back to the types of articles we got for this column back in the day of the print version.

That being said. How could that guy think that pulling the plug was good for *any* computer, let alone the server?

Also, another lesson to be cleaned from this article: always verify that people are logged out. It reminds me about one case where one person kept logging back in. After the third trip to the file server and seeing her back on, I locked her account and then logged her off. I then let the manager know who was holding up the entire company and that I would only unlock her account after the work was done and the manager had instructed me to do so. After the server work was done and after a long meeting with the manager explaining that no, she wasn't the most important person in the company, I was given the go ahead to let her back in.

Shadocat 11-Aug-09 11:16am
"Also, another lesson to be cleaned" Should be gleaned.
Privacy Paramount 12-Aug-09 2:12am
Jargon creates the necessary synergy to effectively innovate.
killerwhaletank 18-Aug-09 8:56am

I like this article as well because it's not about how stupid anyone in particular is... it's about something that happens all the time in the real world: learning from innocent mistakes and incorrect assumptions!

I always say the best IT people are the ones who've managed to bring down a production system at some point in their lives. ;) It's a lesson that never leaves you. I usually just smile and tell our students the first time they make a big mistake, "welcome to the club". I think most of us have brought down a production system or a server at one point in time... if we're lucky, we recovered before the users noticed! If we're unlucky... then everyone knows about it and you have to grin and take it in stride.

It's easy to forget when you've been working in IT long enough that you didn't come out of the box "fully cooked" either, and that there were a lot of things you had to learn in the experience department before you got to where you are now. I find myself making the same mistakes with some of the students we hire, particularly the ones that are real superstars... I have a tendency to assume because they're bright and motivated and don't need lots of babysitting that they should automatically know what I'm talking about, but I forget that they are learning the hardest thing to learn about a job: the procedures, the culture, and the stuff that you need to know but is never covered in the classroom. There are some things that you only learn by actually being in a job and supporting a real system and *nobody* knows it all right out of school.

Sign up to receive InfoWorld Resource Alerts

Subscribe to the Off the Record Newsletter

The one-stop resource center for IT professionals.

©1994-2010 Infoworld, Inc.