beishlineinterview

The person I interviewed was Bill Scheirer, a Systems Administrator at a company called [|Trifecta Technologies]. Bill told me that most of his writing consists of technical documentation of processes and procedures that work for troubleshooting problems. He explained that when a problem was submitted to their tracking system, he researches possible solutions on blogs/forums/technets/etc and tests them to find out what works and what doesn't. After successfully fixing the issue, he writes up the procedural documentation and stores it in the companies intranet wikipage for future reference. Other writing he does is note taking during meetings on technology people want implemented, then research the most cost effective and easiest way to maintain it.

On an average day, Bill says he writes 2-4 procedural documents based on what projects he was given, as well as take inventory on a couple servers and virtual instances.

The majority of Bill's writing is for technical understanding and how to fix issues, what works and what doesn't, and keep track of what server networks and systems are located on. A huge issue in Bills line of work is having easy-to-reference and up to date guides for a large amount of abstract virtual networks that you can't exactly go and see. if you lose a password or the IP address of a machine that doesn't technically exist since it's a virtual image on a cloud server in another country, it becomes very hard to get that information back.

Bill does most of his writing for himself or others on his technical team. They use common abbreviations and technical terms that they all would understand, but someone outside of their group may not know without a key. If he's writing to a client, he'll often break things down and try to explain the harder to understand technical language with something easier to grasp.

Bill says the most he gets out of his writing is being able to go back and reference past documentations to solve current problems faster than if he had to start from the beginning. Also adding the the collective knowledge database of his colleagues and keeping things organized makes everything run more efficiently so they can focus more on fun endeavors than "busywork."

The way computer sciences are advancing at this day in age, it's impossible for one person to know how to fix everything. It's always a learning process and using the internet to find solutions to the problems is a great resource. I'm not very surprised that this is how it's done, but I wasn't aware they'd write documentation for future reference to solve the issues faster if they spring back up. This wouldn't be my first career choice, since it's mostly working with software, while I enjoy working with computer hardware.