Would you believe that it is already the second Tuesday in February? Wow, this month is sure going fast. But being the second Tuesday of any month means just one thing – It’s time for the SQL blogging universe to come out in force and post their blog posts for T-SQL Tuesday. Andy Leonard (b | t), my friend and physically closest SQL Neighbor, is hosting the party this month and he wants to know “What is your Why?”. Specifically,
Why do you do what you do?
The answer to this is in two parts:
1. I like things to run as efficiently as possible, and
2. I’m lazy.
I started off my IT career in college. I was studying for an Electronics Engineering degree (you know, working with transistors, capacitors, resistors, diodes, etc. on circuit boards). In this curriculum, one of the required courses was a computer programming class (so that we could see how people were using the stuff we were building). And I fell in love with programming and shifted over to a programming degree.
At the time, our “computer lab” was a bunch of old, dumb terminals. These terminals connect to a mainframe (in the next city over) with a state-of-the-art 110 baud acoustically coupled modem (like the one pictured). We would dial in to the mainframe, establish a connection, and do our work. However, the mainframe only supported a fixed number of active connections at a time, so frequently we had to wait and keep trying to connect just so that we could do our work. What a waste of time.
One nice thing about the computer lab… since we were working on the mainframe, we had a complete set of the manuals for the mainframe and the terminals (they covered an 8 foot table end-to-end). One day while I was waiting, I noticed that these particular dumb terminals had two cassette drives (this was in an era way before disk drives). Wondering what they were for, I started digging around in all those manuals for how they worked. I found out that you could put the terminal into an offline mode, and type away. Later on, you could play the tape back, and it would enter everything as if you were typing then. What you typed would be encoded onto the tape. The caveat is that you couldn’t see what you were typing. When the tape played back, would it be gobbledygook?
So, I stopped off at my neighborhood Radio Shack, picked up a couple of computer cassette tapes, and I was ready. The next time we were waiting in the lab for connections, I calmly sat down at a terminal, flipped the terminal offline, and insert a cassette tape. And started (blindly) typing in my program. Immediately, all conversation in the lab stopped – they were all looking over my shoulder. When I finished, I joined the queue of waiting for a connection. When I got one, I played back the tape, fixed the two typos, ran my program, got the output, signed off and left. What this saved me was all the time typing in the program after connecting to the mainframe.
There you go… my first real use of technology to be more efficient. It was only my time, but it still counts.
Well, life interfered before I finished by degree. Of course, I was a tecky geek – I loved everything in technology. I was in the military, had a family, and was a leader in the local Cub Scouts pack that my sons were in. I was in a position that required paperwork being sent in for each child for all advancements / awards that they were receiving. My biggest problem is that I’m not well-known for my penmanship, so it was a slow, laborious effort on my part. Using my Apple //c computer, with the AppleWorks database component, I tracked everything and even had it print out all the necessary paperwork.
In the last few years of my military career, I was working in a technical library. One of the huge tasks that the library constantly endured was ensuring that all the technical manuals were up-to-date. Quarterly, we would be pouring through the updated microfiche of the released manuals / releases to make sure that we had the latest updates. Even for our small library, this was a job that just took a very long time. After we would find needed updates, we would have to order them – a process of filling out paperwork. Due to the time involved, this was a constant process of many tiny orders.
In order to track where all the manuals were in our library, we had a small computer system (utilizing a FoxPro (DOS) database). We found out that we could get the entire Navy’s library reference on 9 track tape, and that the orders could be submitted (via modem) electronically. Well, you can guess where this is going. I coded a solution to load the tape (the big 9? reels) into a database, compare it to our database of technical manuals to determine what updates needed ordered, and then generating the order file. Then send the file electronically. Two weeks later, the supply folks came by the library, wanting to know what to do with the two pallets of updates that had just come in.
After the military, I worked with various business and government entities creating programs for automating their processes. The automation allows the process to run efficiently on a repeated basis, ensuring that all the required steps are performed.
The lazy part? Well, that is simply me saving all the time that doing the process over and over would take me. Sometimes doing it over because I messed something up (couldn’t read my writing on paperwork). Going through past orders to determine if this is something that had already been ordered. Sometimes forgetting or skipping a step. And I wanted the time to be for what I wanted to do, not what I needed to get done.
My “What is your Why”
My Why is simply to reap the benefits of automation. It allows me to quickly do tasks consistently and remove mistakes, if done manually. This carry’s over in my current life as a Database Administrator. I create scripts to do database administration tasks. This allows me to quickly dive in to issues to help those systems run better. More efficiently. And it frees up time for me to do what I want to do. So that I can be as lazy as I desire to be.
You can read all of my other T-SQL Tuesday posts at this link.