IT pros are people too! We make mistakes and consequently set ourselves up for well-deserved joshing from our colleagues. Alas, here is one such personal tale of missteps and (mild) mockery.
At the start of my career, I took a job at a small project management company. There were only about 20 employees at the head office and not many more in total, although we probably had a couple of hundred subcontractors working for us. We were in the oil industry, so the subcontractors were mostly in places such as the North Sea and Houston.
[ For more stories about IT jobs, check out "10 users IT hates to support." | Pick up a $50 American Express Gift Cheque if we publish your tech story: Send it to firstname.lastname@example.org. | Get your weekly dose of workplace shenanigans by following Off the Record on Twitter and subscribing to the Off the Record newsletter. ]
I'd joined the company as a junior programmer. The entire computer department was only three or four people, one of whom was busy managing, while the other two dealt with computer support. I'd taken it upon myself to broaden my skill set and institute a proper backup regime and generally look after the operations side.
When the basics aren't routine
One time, I was preparing to leave early to travel for a career advancement course scheduled for the following day. I was trying to check off items from my to-do list before I had to depart.
One of the tasks was to defragment the system disk. During lunch hour, I went through the procedure. All routine: I backed it up, formatted it, restored the tape, went to reboot.
But nothing happened. The system simply wouldn't reboot. I tried again, but it kept hanging.
What was going on? I thought I'd covered all the bases. As I tried to figure it out, the lunch hour ended and people started wondering why their terminals weren't working.
The rest of the computer department, of course, came to see what was going on. To cap it off, it was time for me to leave for my trip.
My co-workers told me to go, and they'd work on the problem. I hated leaving behind such a mess, especially one I had made. I also hated not knowing what on earth had happened. But I packed up, said good-bye, and left.
That was the problem?
When I returned, my co-workers greeted me and asked how my class had been. I brushed the question aside and asked if they'd figured out the problem with the system reboot. They were most amused to tell me that yes, they'd diagnosed the problem shortly after I had left.
Checking the printout in the system console, they found that I'd told the system the console was 300 baud, when it was actually 9,600. One quick reformat and restore, and the system was back up and running.
How could I have missed that?! But I had, and I was forced to endure some good-natured ribbing from my colleagues for a while. At the end of the day I was a junior, learning the ropes.
More important, I was not going to repeat that mistake. From then on, I was doubly cautious about retracing every step, no matter how small, when figuring out why something isn't working the way it should. I've since adopted a motto: "Don't plan what to do, because it'll be obvious. Plan for what can go wrong -- then it won't."
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to email@example.com. If we publish it, we'll send you a $50 American Express Gift Cheque.