Notes on Being in IT
I’ve worked in IT for twenty one or so years, but I started with computers in the mid 80s, a few Tandy’s and (barely) PC compatibles and the usual Commodores and early MacIntosh systems. I did some nascent hacking, taught myself about systems the old fashioned way: trying to make them do what I wanted them to do. I used to program BASIC onto cassettes from paper, did (very) little assembly. When I’d been doing IT type work for a living (as a “system operator” and later as a systems admin) I gave up on programming; I don’t have the patience for it, and there were all these systems to connect and explore. My first real computer job was working with a Novell network, from building the server and stringing coax cabling to managing the whole darn thing, in the process of getting a targeted direct mail startup up and running. It was a crash course in hardware and software, procurement and project management. Connecting everything: printers, mailing systems, databases, plotters, huge data sets, a high performance GIS profiling system, a small group of users, and a large amount of nonsense, all for the purpose of sending targeted junk mail.
During that time (the early 90s), I had my first taste of working too many hours, of sleeping at my desk catching catnaps between phases of expansion and production. The worst I can remember it being was a heavy duty 9am business meeting with Xerox, trying to get them to take back a very large laser printer that they’d sold us as “compatible” with our IPX/SPX network (it wasn’t); I hadn’t slept in 30 hours, and nodded off several times during the meeting.
I also had my first experience with Old School Mainframe Operators. The direct mail startup, a PC-based business, was housed in a small bank owned by a state senator; our mail operation was his campaign publishing arm, but did so well with one PC and one guy in a garage that the senator expanded it to include his banks and cronies as customers. I’d been hired because I was a friend of the daughter of the guy in the garage, the guy with the idea, and I “knew computers.” With no degree (I’d dropped out of college when rent took precedence over tuition) and no formal training, I was cheap, and I was basically hacking my way through the process: learning from the ground up, hands on, no fear of the systems nor any formal respect for their capability. To me, they were the boxes I’d hobbied around on since my youth; nothing serious, just some bits. Legos, but electric. Then I met the IBM Acolytes, the lab-coated, tie-and-white-shirt, bootie-wearing, cleanroom / datacenter data slaves that managed and maintained the unpredictable beast that was the IBM mainframe in the basement. To them, all this PC nonsense was a flash in the pan; cutesy home systems being propped into business because people wanted pretty displays instead of ugly green-on-black tn3270 terminals. To these folks, PCs would never do heavy lifting. Their performance specs weren’t translatable. IBM guys (almost always guys) spent many hours making transactions reliable. Speed was important, but “speed” implied a complete and reliable cycle of operations. On our end, we wanted throughput, sheer speed, the Firehose of Data. The IBM Guys dressed in shirts, ties, lab coats. We dressed, sometimes. Their system was like a gigantic freight train, and took a lot of work to get up to speed, and even more work to stop it. Our systems were instant, flaky, fast and unpredictable. But ours also cost FAR less and did more, more often, and if one of ours broke permanently, we could easily replaced it with zero forklifts involved.
From this blend of (barely) Old and (bleeding edge) New, I began to learn about IT people. About the importance of definition, of title, and about the four types of IT people that exist in the world. And I began to learn about users, and the two types of users there are in the world. In the intervening decades of watching systems and people, I’ve found that those earliest impressions still ring true. Like all generalizations, they are not exact. They are a starting environment, the weather in which I operate.
See, under the vague umbrella of “IT” there are those of us who work in IT Departments. We’re sometimes support for people, sometimes support for systems that serve people, usually support for both. In many ways, the modern IT department is a loose coalition of specialists that do a few things very, very well, or a collection of generalists that do a lot of things reasonably well. Depending on the size of the company, IT can be one person or five thousand. No matter the size or complexity, every person in those IT departments will be one of four different types (each with a collection of sub-types):
- The Veteran.
- I Just Started Doing This For A Living Five Minutes Ago.
- I’m An Elite Hacker.
- I’m A Cog In The System: I Only Do This One Thing.
For users, there are two kinds of users. Only two. There are the ones who trust IT, and there are the ones who do not trust IT. Trust is an important part of this; huge complex systems are as difficult to grasp as magic if it isn’t your job to do so. People are complex things. Trust is difficult. Trust is the dividing line.
For each type of IT worker, there are wizards. No better word to use; it ties into the old school geek mythology thing, and works well in each case. A Veteran is damn near always a wizard. The Veteran has been at the top of their game for so long that the solutions aren’t even a challenge, the real challenge is finding joy in them. The Veteran is aging out of the system, but there’s not a better Thing to Do for Money, so they are married to a dying hope that one day a problem will present itself that is only barely solvable, and the solution will fuel the Life After Work with a healthy glow of accomplishment and a feeling of completeness; They Did All That They Could Do. For every Veteran that is a wizard, there’s a burned out jerk. They’ve been done for years, trying to climb out of IT into anything at all, sick of it since Windows 3.12 was a thing. Some of them end up in car sales or AmWay. Some end up in project management. Some end up retired with a meager 401k and a bad back.
The IT folks who Just Started Doing This For A Living Five Minutes Ago are part of a younger, heavily certified generation. Not quite young, but not yet old, they took a lot of classes teaching them how to pass tests, and they got some certs, and now they’re actually on the front line, doing the thing. They field calls and slowly expand their vocabulary of Stalling Language, they get good at the Google, they curse forums and knowledgebases which they conversely rely on to provide them with knowledge and a voice. They are frantic, always. They are terrified, always, but they mask it with a cocky swagger, an ego defense. They often have physical or virtual swag related to gaming, to IT, to hard core networking. They’re hopeful. They believe in their future, though they despise their task, since their task often deflates their ego. Eventually, they either proceed or wither and die. They like statistics. They usually wear golf shirts.
The Elite Hacker has two flavors: actual talented hacker types who actually are talented and devious and deserve some respect, and the ones who aren’t that. There are more of the second variety. I worked with one very talented hacker who wore a black hat on weekends; back in the mid-90s he was all over certain systems and he taught me a whole lot about BSD, Sun OS, and Cisco’s early operating systems, among other things. Mainly he taught me how to interact with the community, all the poses and posturing and the “social engineering” side of things, chatroom shorthand and scripting. He ran a Mustang BBS with warez and (pirated) games and a healthy text section filled with the latest philes. He was a very fine coder, his code was small and neat and worked very well, and he was a talented sociopath. Last I heard, he was in a prison in California for some repeated drug offenses (he was also a master bong maker, a true artisan). The question, then: was he any good at IT? Yes and no. He was terrible with people, but brilliant with systems. When the systems did something wrong, it made him angry. How dare they, those stupid ones and zeros, defy him. When the users did something wrong, it made him even more angry. That’s not good for IT, that’s stupid and awful. One day, though, he did help me set up an ISP in less than 12 hours. A whole ISP. Modems and T1s and servers and everything. So there’s that. So far as the opposite kind of Elite Hacker, the ones who claim to be but aren’t? Well, they’re bad for business. Don’t bother with them. They’re just trouble.
In retrospect, IT is really just appliance management and repair, and a healthy dose of psychology. Fifty percent of what we do is solve people, and fifty percent is trying to figure out what happened or what will happen, trying to predict needs and wants and points of failure and holes and weakness. In that mix is the last kind of IT person, I’m A Cog In The System: I Only Do This One Thing. This IT person is very often capable of more (sometimes surprisingly so) but they’re not there for more. They’re there for one job, and that’s what they do. Maybe they’re good at that One Thing, maybe not. You see this these days in large orgs with thousands of people, where specialists are encouraged and well paid. The person who does nothing but tune MySQL. The person who does nothing but Cisco switches. The person who is dying one packet at a time. Fed by an industry enamored with defining things, these folks are the result: a perfectly defined, perfect peg for an imperfect hole. If only that hole were perfect, they say. I’m the perfect fit for your synergistic LAMP needs, but don’t ask me to troubleshoot the route between my LAMP and your LAMP. I could, but that’s not my gig, man. Not my gig. These folks are largely in poor physical shape, and don’t live much longer than their One Thing.
Each IT serves the user. Sometimes the user is a developer, sometimes the user is a real estate agent, or a grandmother, or a truck driver, or an entire brewery, or a bank. I’ve worked for all of those and more, and as I moved from neophyte committed enthusiastic IT person to a burned out husk of, oh, useless IPX and SGI knowledge among many other things, I learned early on that the most important thing about the task is the user. The person, or the process controlled by a person, who owns your time. Your opinion on this user doesn’t matter for the task at hand. You agreed to be owned for a time by this user. They may need a nudge, a bit of an education, something to think about. They may need some slight modification of their interaction with the technology. But ultimately, the system will LET them do what they do, or at least it promises to let them. The technology does this. Not just the technology as in the ones and zeros, but the whole package from promise to marketing to sales to maintenance to etc. The user is just using the thing. Understand, then, that what you’re doing, fixing, installing, repairing, creating: it isn’t for you. You’re not paying for it or for you. You’re being paid to provide. Oftentimes, what you’re asked to provide and what you can provide are two very different things. To smoothly do that, to do it well? You need to know the user more than you know the technology.
Also, it isn’t the users fault that they lie. All users lie. They may not know it, and most times they don’t do it on purpose. They’re just not used to thinking like a problem that is about to happen. They don’t mark their actions on a troubleshooting tree. They’re not consciously doing The Wrong Thing. So when they say they didn’t do anything, or that they have no idea what happened? Yes, they’re lying. Don’t take it personally; they don’t know it, and they don’t really care. It’s up to you to do the first thing, to solve the first problem first: talk to the user and solve the user. What kind of person are they? What kind of desk or cubical or office do they have? What sort of life do they lead? What’s their background? How old are they? What’s the last thing they remember doing? How are their spouse / kids / favorite team / whatever? What did they have for lunch? Do they eat at their desk, alone, pining for something more, in a way that results in nothing but more vague pining? Are they into extreme sports? Do they golf or horseback ride or play video games? Find the user, solve the user, and move on to step two. Users are the hard part; the problem they stumbled into is easy. Hell, there is nothing more difficult than telling someone all their precious data is gone because of some thing they did, or worse yet some thing they didn’t do at all. Try it. Try telling someone all their work is just gone. Poof. Forever. Try it, and then think about how much you bitched about the disaster recovery plan that you never put in place because it was so damndable and stupid and expensive and slow (as they all are). The worst part of the job, reader, is the user. The very best part of the job, though, is the user. It’s a very strange place to live. It isn’t much fun, but most things you do for money aren’t.
All that said, in my case? I love the problems. Love them as much as I hate them. I want the big crunchy problems, the huge gnarly twisted ones that have solutions somewhere on the horizon just out of sight. Love the problems that require that I dive deep and focus and lose myself in the tangled bits, the humanity and inhumanity of a silicon system designed by people and built by cheap labor. I love the problems more than any solution. And as long as that’s the case, I guess I’ll stick with it.