DEV Community

Shawn Sommer
Shawn Sommer

Posted on

5 Things I've Learned My First Year In IT

Note: This piece was originally posted on my now-defunct personal blog in 2014, but I still believe that the advice applies to people just entering the field and have decided to post it here on DEV in the hopes that it helps people navigate those tough first weeks/months. Hope you enjoy!

I can't believe that I have been in the IT industry for over a year already. I can honestly say that it has gone by fast and has been a very good experience thus far.

In my first year I have worked for both a small company of about 15 people and after that company was acquired, a very large corporation. My first year has been both challenging and rewarding and I would like to share with you some of the things I have learned. While I have learned many more things in the past year I feel like these items apply to IT in general and not strictly to software development

School Didn't Teach Me Everything

While I learned a lot in school, it didn't teach me everything I needed to know in order to do my job effectively. This isn't a criticism of my education, it is simply an observation.

Schools can't account for every variable present in the business world. Things like issue tracking, version control, and corporate policies can only be spoken about in a very abstract sense. Some things need to be learned on the fly in order to succeed. However, school did teach you one skill that you can leverage to close the knowledge gap quickly.

Take Copious Notes

The first thing my boss did on my first day of work was handed me two pens, a thick notebook, and said, "you'll need these, bring them to every meeting". While I use that notebook primarily for meetings, I also use it to work out issues and note some of my observations. Some of these notes have been compiled into easily readable Word documents, some of which I share with new employees when they are learning similar things or running into common issues.

I also keep a log of my daily activities with links to tickets I worked on for easy reference. While it doesn't come up often, sometimes my boss will need to know when a ticket was completed and where it currently and with this system, I can tell him things like "I worked on this on July 10th, and it is currently in testing". At which point he can follow up with the QA group.

Notes will not only help you do your job, but they can also save your bacon.

Note: Even though some of the ideas in the preceding paragraphs are a bit dated I feel the overall idea here is still perfectly valid today.

You Might Not Start In Your Preferred Position

(and that might be a good thing)

I started in the IT field as a software testing intern. This allowed me to see the software from a user's perspective and has given me an advantage I might not have had if I had been pushed directly into development. I could see parts of the software that might frustrate or delight end users. This has allowed me to identify potential pitfalls and (hopefully) avoid them.

I also had a brief stint as a software installer, this allowed me to see the varied environments of our customers and fully appreciate the complexity of the domain in which our software exists.

Both of these experiences have helped me to more fully understand the problem domain of our software that I would have otherwise. Varied experiences will help you grow your knowledge so embrace and learn from them.

Get To Know Your Colleagues

I'm not saying that you need to get to know everyone you work with equally well (as a matter of fact, that may be impossible) but get to know the people you work with every day as well as you can. Getting to know the people around you will not only make your workday more enjoyable but it will also allow you to find gaps in the team's knowledge. When you find such gaps, take it as a personal challenge to fill it.

I am big on the concept of a team and by taking knowledge gaps as a challenge you can help make the team stronger and more efficient. I have always viewed part of my job as making things easier for the people around me and have carried that philosophy with me since a very early age. When I worked in factories I would attempt to learn where the skill gaps were and fill them, in IT I try to find and fill knowledge gaps.

Forge good relationships with as many people around you as possible, you have to rely on each other.

You Will Have Great Days And Terrible Days

Sometimes everything you do will go right, other times it will seem like the world is out to get you. Honestly, there is no better feeling than being able to resolve multiple customer issues in a day. Those days can shoot you straight to cloud 9. You're happy, your bosses are happy, and your customers are happy. Try to cherish these types of days because they'll get you through the days where everything seems to go wrong.

There will be days where you get bogged down in a seemingly insurmountable issue, emails from angry customers will be piling up, and everyone around you wonders why things are taking so long. These types of days can be incredibly stressful and if you have a few of them in a row it can feel like you are stuck in some terrible nightmare. Trust me, things will get better and you have proof in your memories of those blissful, seemingly perfect days.

Well, there you have it, that was how I felt and thought after my first year in the field. Some of you won't have the same sort of opportunities I had and some of the technology referred to is a bit dated but the core concepts are applicable to most people.

Thanks for reading and have a fantastic day!

Discussion (2)

gabe profile image

Great read! Used to intern as an “IT helpdesk analyst” for close to 2 years and your article rings so true. The good days, when you are able to solve each issue with ease are so awesome, to me it always made up for the real shitty days.

ssommerit profile image
Shawn Sommer Author

Hi Gabe, glad you enjoyed it. Being able to cherish those good days is vital. Sometimes we forget how good things can be when everything is going wrong.