Brittany Gates profile picture

Data Center Aficionado & Creative Writer

Close this search box.

Git Gud Techs And Stop Taking Easy Tickets

My opinion is harsh but git gud techs and stop taking easy tickets because you don't want to get "stuck" with a difficult-to-diagnose server.

This post may make some technicians mad but it must be said: Git gud techs. And the only way to do that is to stop taking easy tickets. I know, I know, getting stuck with a difficult or a troublesome computer or server sucks. I’ve been there too. However, after dealing with that situation I came out the wiser. I knew how to fix those same or similar problems in the future. And I could pass that knowledge along to other techs.

How To Git Gud Techs

The first step to git gud techs is to step out of the comfort zone. If you an awesome troubleshooter for hard drive issues I want you to take tickets for memory issues. Or if you are scared of networking issues I want you to take those tickets.

Once you take a ticket out of your comfort zone the next step is to use all the resources and tools available to work the ticket on your own. That could be an internal knowledge base or wiki, search engine results, or even a YouTube video. From there you work the ticket using that help. Use it fully, trying all the steps. And document each step in the ticket! Oh, that part is so important because if you don’t document then you can’t go back to review your steps. You can’t review what worked or what didn’t work.

I know some techs don’t want to length their ticket with this information but it’s important. Not only will you read this ticket now and possibly in the future, but other techs too. Because tickets are a type of knowledge base. Many ticket systems allow searching so other techs can use them to determine a solution to their ticket.

What To Do If You Get Stuck

If none of the resources and tools you found online or in the internal knowledge base or wiki helps you then ask for help. Ask a coworker for assistance with your ticket. However, you must be able to show what steps you took to try to resolve the issue beforehand.

I would have junior techs come to me and ask for help. And when I reviewed their ticket I would see little to nothing done. So I would ask what they did to troubleshoot the problem and I would get a basic response. It’s like the tech spent ten to twenty minutes on their own, got stuck, and then ran to me so I could resolve their ticket. While I don’t mind giving assistance I’m not going to do anyone’s work for them.

Which means to git gud techs you must be fine with your coworker giving you a hint or a suggestion of what to try next. Or your coworker may provide the answer to your question in the form of an article with step-by-step directions. Really, working in IT isn’t about resolving issues; it’s about learning how to resolve issues. Because one day you won’t have someone to turn to and will need to figure out the solution to your problem. And when that time comes, and it will come as I can tell you from experience, you need to have the knowledge of how to find the resources and implement them correctly.

Share This Post!

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x