Users

Working at a computer lab certainly has its benefits. I get to sit around, program, and futz with computers all day...and get paid for it. Then again, there are those times where you just want to throw a brick through the computer due, in par, to stupid users. These are just a few anecdotes of my life as a labbie.

What computer?

This occurred during my first semester here, when I didn't really know what was going on in the grand scheme of the lab. I mostly took random hardware requests and fixed computers, things I knew how to do. Anyway, I had to replace a video card on a machine from the instructional (read: public) labs. When I was done, I brought it back down only to notice a user sitting at the "computer" I just took, fervently pressing the monitor power button in a vain attempt to turn the computer on. Had she looked down and to her right, she would've seen no computer. I had to stifle my laughter as I put the computer back.
Moral of the story: Make sure a computer is physically present before you try to work on one.

"I think I know where my computer is..."

We've been moving people around to new offices a lot recently. In order for the movers to move their furniture, we had to bring their computers down to the lab (they were otherwise locked to the desk). A user, whose computer was temporarily taken down, sent mail asking "why is my computer down?" I replied saying his computer would be temporarily down for an office move. He claimed that the lab had been keeping his computer for weeks now (strange, considering I personally moved it the previous night). I calmly put him in his place. Then he asked, "well, could you at least bring it up so I can get my mail?" Not after questioning what I'd done, buddy. Needless to say. His computer was among the last to be moved.
Moral of the story: Don't piss off computer lab staff, in general. If you do, we won't give you any favors. We're nice people, so try to be nice to us.

It's a Webpage!!!

I once had someone ask me if publicly viewable webpages could be viewed from anywhere. That's not the stupid part, the stupid part is that it took him 10 minutes and tried to not sound stupid by throwing technical jargon in my face.

Example: "Do your servers display html if it's requested from any IP address?"
Translation: "Can I see webpages?"

He made it sound as if he had a specific problem with viewing them from home, not as if it was some general question on public webpage accessibility.
Moral of the story: If it's a general question, don't make it sound like a specific problem. It's just easier on everyone. Deal? Good.

Room?

Tip to users and troubleshooters. It helps to know which specific computer has a problem so the administrators can actually solve the problem. We're smart people, and we'll do what we can to figure things out, but we're not mind readers...yet.

This specific example takes the cake, though. One time a user mailed in a request about a monitor problem in an instructional lab. The violations...

  • Didn't give us the name of the computer. Strike one.
  • Didn't give us the name of the lab of said computer. Strike two.
  • Did give us a room number. However the room number not only wasn't a computer lab, it didn't even exist. Strike three, you're out!
    Moral of the story: Throw us a bone here, people, and give us some freakin' info.

    Self

    Now, even though I have much computer experience and have learned a lot from working in the lab, I have been known to make stupid mistakes. Here are a couple examples of my brainless folly...because if you can't laugh at yourself, you really shouldn't laugh at anyone.

    Shutdown woes

    On more than one occasion I've remotely shut down the wrong computer by accident. Luckily, I gave anyone else logged in ample warning to save their work before shutting it down.
    Moral of the story: Give people warning when there's a potential interruption of their work.

    Oops...

    Here's my reigning stupidity of all time. I'm a web programmer, I create and maintain web scripts, forms, and pages. One such script will create or delete an anonymous ftp directory based on your login.
    Example: Let's say the particular user's login is foobar (standard computer terminology). This will create or delete the ftp://(path to ftp)/foobar directory.
    The script is written in perl and uses an "rm -r" system call with a variable interpolated path. For those who don't know: rm -r will remove everything at and below the given directory.
    So, my call was written as "rm -r (path to ftp)/$login" which should be interpreted as "rm -r (path to ftp)/foobar" (remove all of foobar's stuff). Unfortunately, my script got $login incorrectly, and $login contained an undefined value upon the system call. So, my call was interpreted as "rm -r (path to ftp)/".
    That's right, I inadvertedly deleted everyone's ftp directories. I had to go up to my boss and say "I f***ed up". Luckily, backups are readily available and it took about 10 minutes to restore everything.
    Morals of the story: First, always have backups readily available. This not only helps in case of computer crashes or accidental deletion, but also in the case of rowdy and/or absent-minded system administrators. Second, whenever testing out scripts with system calls, print the system call first.

    Oops...again

    This is a near tie for reigning stupidity. I had to do some work with databases (Actually, I do a lot of work with databases). Now, we have many database apps for common tasks, especially inventory tasks which was what I needed to do.
    However, the task I needed to do was non-standard and would've taken far too long using the tools we had created. So, I decided to take matters into my own hands, go directly into the database and run some SQL queries to simplify my life.
    Long story short, I ended up making a query that changed everything in the inventory database, not just the 1 or 2 records I wanted. Fortunately, I did put things into a transaction block, meaning I could rollback my changes after the 20 minutes or so it took to finally finish the query (inventory is a big database).
    Morals of the story: First, when working with a large database with much sensitive info that you didn't create, run everything in a transaction block. If you f*** up, you can always roll back. Second, be careful when issuing queries especially in a straight SQL interpreter (like psql or isql).

    Back to main