I have discovered the killer line to use in an interview for an IT job. This line breaks the ice and is guaranteed to get everyone to crack a smile. It's also certain to make you stand out among the host of candidates vying for attention.

Before I get to the line that is certain to slay dragons, I have to say that, as an IT guy who has worked with hundreds of people over the years, there’s one thing that most people hate doing: documentation.

Can you guess what I say during interviews? That’s right. “I love doing documentation.”

Now, it’s bad enough being thought of as a geek, but being a geek who actually likes documentation? At this point, however, I would suppose that the interviewers are thinking “Wow! This is the guy we need for our team. The nearest we've ever come to documentation was an out-of-date spreadsheet and an email trail. He could do the documentation I was meant to do.”

“Do Not Read This”

I discovered fairly early on in my IT career that, for most people, documentation is like cleaning the office kitchen: everyone wants it done but most people think someone else was supposed to do it. That’s why documentation is a huge area of neglect in many IT environments. So when I wrote my first user manual for one of our customers, I knew the bar was not very high. They needed some documentation for a system which they had been running perfectly well for years. I knew the documentation had to be written. I also knew with a fair degree of certainty that my documentation wasn’t going to be read. So here is how I started my user manual:

“Do not read this book. At least, do not read it from cover to cover. It is not a novel. It is not a best seller. It is a reference manual.”

Well, those opening sentences were quite a hit. The customer had the manual, which made them happy. Better still, quite a few people had read the opening lines, so the manual made a good impression. Now, I wouldn’t dare claim that anyone actually read the rest of the manual, but the positive reaction to the opening was evidence that those people had at least read the beginning of my manual, and obeyed it. Mission accomplished.

Documentation is a bit like insurance. You know you should have it, but you hope you will never need it, and you’re glad if someone else offers to do it. But what if that someone else who has to do the documentation is you?

Killing Writer’s Cramp

Now, if you’re in a position where you need to produce documentation, let me suggest an approach that's different from sitting in front of a blank screen, wondering where to start. In my job interview, I didn’t say I love writing documentation; I said I love doing documentation, as in producing documentation. Even if the word “documentation” implies that you'll be creating documents, that doesn't have to be the case these days. A screen shot is worth a thousand words. With the advent of smartphones that have great cameras and acceptable sound, it’s not that hard to produce a simple video. In fact, it’s worth it to consider using video as a part (or even all) of your documentation plan.

You may be thinking that creating a video requires a lot of preparation, massive expense, and an enormous operation that includes filming, editing, and a big intrusion on your time. However, creating a video for your documentation doesn’t have to be like that at all. There are plenty of different software programs around that let you screencast. Screencasting lets you record what’s on your screen while you explain things as you go, just as you would if someone was watching over your shoulder. As with written documentation, the bar is not very high. If you want to start filming yourself —chatting about your IT systems, for example—you can get plenty of great tips online.

Of course, you can easily get more elaborate with your video editing by introducing chapter headings and links to “real” or official documentation, like an IBM RedBook. You can even overlay some music on your video. You don’t really need to do all of that, however. A short, 90 second video that explains how to choose host names or how work flow happens can be very valuable. In addition, it can even be a video you can put up onto a YouTube channel, as long as you don’t compromise any secure information.

“Here’s How We Do Things Here”

Suppose you want to show someone how to install the Virtual I/O Server. Well, you could just point them to the official documentation, and that’s a good idea because official information is always useful. However, you have quite a few site-specific tips that only you know; maybe you use Shared Storage Pools, or you have NPIV for your virtual clients, or, instead, use virtual SCSI (vSCSI). Which of the many network options do you use to get the virtual clients out to the world?

What I’m saying is that it’s worth taking a fresh approach to documentation. Your ability to produce it in one form or another is something that will differentiate you from the very many people in IT who don’t document, or even those who say that they hate to document.

If you have to do something as part of your job, you might as well learn to be good at doing it. That way, you can grow to love that part of your job. It’s worked for me, even if people haven’t read my documents.