Abstract

I am working on five years in the IT industry; and while I would still consider that early in my career, it did seem like a logical point to reflect on the journey so far. This post will likely be quite ramble-y and not really containing anything technical. Rather, it is going to focus on various parts of working in IT that I have come to learn. This will likely be a boring read for people that have worked in the industry as long or longer than I have, but hopefully will be at least somewhat helpful to people aspiring to work or just started working in the field.

My Start in the Field

My path in IT so far has been rather fortunate; when I was hired at my current company, I was floundering a bit out of college and didn’t have a lot going for me on my resume other than the variety of personal projects I had done. Thankfully though, I had shown enough interest and capability of learning while also appearing to be a human being that I was hired as a desktop support technician. Starting the new career was intimidating and I often questioned whether I was an impostor or not; over time that feeling faded a bit by being able to tackle bigger problems while also working well within my team. I learned how to research problems, and not only when to ask someone else, but also how to ask someone else for help. Asking probing questions to more senior people exposed me to a lot of different things that a desktop support position typically would not have been allowed to do. It also eventually built myself up in a way that when the system administrator position opened, I was asked to take the role. Taking the sys admin role also means that I have to assist in training up the desktop support position to eventually turn them into sys admin material.

Lessons

In the short time I have been working IT, I have picked up on a couple of lessons that I was not taught in school that can make life a bit easier when working in the field:

• Precedence: This is a term often used in law, but it applies with IT requests as well. Do we have previous examples of this type of individual asking for this type of request. For example, has a manager asked for a new distribution list to be made before? If yes, how did we handle that? If no, why? This can help break requests down into categories that can be processed more easily, especially with requests that would be considered odd. What is the most similar request we have gotten? how did we handle that, and how is the current request different. What does that change? This is a lesson I was taught from my previous sys admin, and is something I use on a regular basis when making decisions on how to approach a problem.
• Most people do not understand computers: This one seems obvious because of course they don’t, that is why they pay you. However, the level of not understanding computers is difficult to really describe without experiencing it. On a regular basis, I have users that will call their computer tower a “CPU” or restart their monitor and claim they have “restarted the computer.” Unfortunately, the lack of understanding most people have for magic thinking rocks (computers) goes much deeper than that. It is not helpful to blame them, they don’t speak the language of strange abbreviations and fancy words, and what is a ‘server’ anyway. The vast majority of end users don’t know and don’t need to know, what they need is an IT person to figure out what they are trying to say, then fix their issue.
• Owning mistakes: Making mistakes really sucks, especially when it affects a lot of people. One of the wonderful things about working in IT is that your mistakes can affect lots of people! It’s part of the job. Accidentally cutting an Ethernet cable in use, a department may no longer have a network. Set the wrong VLAN config on a switch, network is broken downstream of the switch. Unplug the wrong cable on a server, whelp, server is down for the whole company (true story too). Making mistakes can and absolutely will happen over the course of a long and prosperous career, learning from the mistakes is what makes us better, and builds junior people into senior ones. Own your mistakes, and do your best to fix them, or at least try to come up with a game plan for fixing them.

Struggles

As unfortunate as it is, struggles will exist in every aspect of life, nothing and no one can be perfect. This section is going to go over some of the things that I struggle a bit with, and I suspect a lot of people do as well. It’s worth noting that most of these things are not going to be technical, everyone knows that IT people hate printers.

• Impostor Syndrome: I do believe this is a fairly common occurrence in many professions, but Impostor syndrome is something I do struggle with fairly often. Constantly questioning whether you are good enough to be there and whether or not you know enough. The best advise I have to combat this is keeping track of your growth and accomplishments; that can take form of a blog, a notebook, or just revisiting where you started. It won’t prevent the Impostor syndrome from hitting, but it might help negate the negativity it generates.
• Effective Writing: Effective writing is an important skill for anyone working in 21st century or later. Most of civilization is founded upon the idea of reading and writing to communicate ideas and concepts very quickly. Reading and writing are also skills that many people do not practice either of those skills on a regular basis, especially writing. Even more importantly, tailoring your writings to a specific audience. Much of this blog is targeted towards at least slightly technical people, but I have had to do quite a few pieces of writing that was intended towards a non-technical end user. Being able to communicate with the written (or more often typed these days) word is key to being successful in the modern world, whether that be in the form of email or a written report.
• Expectation management: This skill is one that can be applied with every level of worker in which they are having to operate with other people. Making people understand what is realistic and what is not is something that can save a lot of pain on the back end by having an unpleasant conversation on the front end. People do not always understand what they are asking for; as the expert, it is your job to inform and make them understand (at a high level) what the implications of their ideas will be. The best approach to this is to be very blunt, very honest, and have a very good understanding of the problem space the problem exists in.

Unsolicited Advice

We have not reached the point in the writing in which I give advice that no one asked for. This advice will very heavily focus on the operations side of IT, but an analog could probably be found on the dev side as well:

• Work on personal Projects: This is even more true for the people that currently do not work in IT. Personal projects are the way to show what you know without that pesky experience thing that a lot of companies require. As it turns out, software doesn’t really care whether you are certified in the tech or not. If you can click the buttons to make the product do the thing, that is a talking point during the interview. The more you can talk about projects that relate to things the company does, the better your chances of getting hired are. In addition to that, being able to talk about personal projects show interest in the field; people that have that interest will always do better than people that don’t because they want to learn more. One question I asked when interviewing candidates is “tell me about the project you have done that you are the most proud of.” For someone that really enjoys the field, this question will be the easiest one to answer, but to someone that looks at it as a paycheck, it will be extremely difficult.
• Start a blog: I have done another post about this, but there is no reason to not have a blog of some sort. There are so many platforms that will allow anyone to host static sites for zero cost that it is quite sad that more people do not take advantage to up their web presence. Blogging is a great way to show off various projects that you have done, as well as practicing soft skills, as well as showing off those soft skills to the world. If the blog is successful, it is possible that it could be a resume supplement and help get a job in the future as well.
• Practice soft skills: Soft skills are the skills that are not generally directly taught, but will make you a lot easier to work with. These are things like verbal and written communication skills, explaining technical concepts to non-technical users, and documentation. Those are not usually skills that are taught directly, rather it is expected that you will figure it out at some point. You do not have to wait to start working in IT to do this though. Write about the cool stuff you do! talk to people about your projects! Even if it is just people you know personally, try to explain to them some of the things you have been working on. You can gauge how much better you have gotten at explaining things by benchmarking how quickly their eyes glaze over.
• Perfect is the enemy of good, and also the enemy of progress: It doesn’t matter how “good” you are now. You are not perfect, and that is okay. No one is expecting that of you, there is no point in expecting it of yourself. Don’t get caught up on doing everything perfectly because in the “real world” nothing is perfect, it is merely trash vs trash-lite. So, find the best solution you know how to, and just start working with it. If something better comes up, re-address what you are currently doing.
• Just start: The last thing, is just start. By that, I mean just start doing something you find interesting. It doesn’t really matter whether it is actually interesting or not, because that is a subjective opinion. Nothing is ever as intimidating as it seems once you get started; even if you find yourself not understanding something, that just means you need to go learn some other things before coming back to this topic. I’ve done that on numerous projects and blog posts. There is no shame in putting something down for a while to level up the relevant skills and kill it later. There is also no shame in picking something up that you had no business (only in a test environment, don’t break prod) touching and trying to get it to work.