33 Tips That Sysadmins Wish They Would’ve Learned Sooner

Welcome to the best list of sysadmin tips on the internet! I can write that with confidence because I had a lot of help from hundreds of other sysadmins in writing this article.

I’ve been in IT for about 20 years and have learned some valuable lessons over that period. To that end, I wanted to help other up and coming sysadmins avoid some of the mistakes I had made when starting.

However, I’m only one person, so I reached out to the community at /r/sysadmin [ reddit.com] and asked everyone there for their tips. I was thankful and shocked at the overwhelming number of tips submitted, with almost 300 responses the first day!

It took me a while to read and sort through all the amazing advice. Here are the 33 best sysadmin tips that came from this group effort. Thanks to everyone from /r/sysadmin who left a comment!

Table of Contents

Tip #1 – Own Your Mistakes

This was the most up-voted tip that was submitted, and it’s a good one. Mistakes are just part of being human and that extends to working with computers. I mean, we have hardware and software bugs to deal with and those are literal mistakes, so it’s kind of built into our industry.

Whether you’re new to IT or an old hat with a bag of tricks up your sleeve, you’re still going to make mistakes. However, my advice to up-and-comers is to not freak out or have massive anxiety over messing up. You will mess up, but it can light a fire under your butt to fix the problem and help you learn to avoid similar mistakes in the future.

Tip #2 – Document Everything

The third most upvoted tip was “if you didn’t document it, you didn’t do it.” This is one of those tips that could have saved me years of problems, so please take it to heart.

I took over one IT department because the last guy got hit by a car and passed away. When Dean died, most of his projects died with him, as they were password-protected, scattered across personal and company workstations, and not documented at all.

I did everything I could to salvage his work, but a lot of his labor and technical legacy was lost on the day he died. I didn’t know him personally, but aside from this one bad habit, he was actually a very competent technical wiz, which made it feel that much worse that so much of his work was lost.

It was a wake-up call for me, but it wasn’t the first time that I had been bitten by a lack of documentation, but thankfully it was the last.

Tip #2.5 – My System to Document Everything

For the last 5 years or so, I’ve developed a little system that ensures I always write documentation for any new servers, workstations, GPOs, spreadsheets, methods, functions, batch files, or anything else someone might have to work with in the future. It goes like this:

  • I start by creating the documentation first. Either a header comment in source code or a new Word or text document. At first, all I type is the overview of what is being accomplished, such as the problem and how this intends to solve it.
  • Next, I document each step in the “help document” before I perform it. If it’s source code, then I make a comment before each method, function or major line of code.
  • After I finish a section, I ask myself “what would someone replacing me want to know?” and then write a series of questions and answers to try and help any future readers.
  • Instead of reinventing the wheel and rewriting common instructions in my own words, I like to link to official documentation or long-standing tutorial resources to minimize the time-investment in documentation writing.
  • Finally, I “publish” this help document to a central repository with all the other documentation. Usually, this is just a network share, but in different consulting gigs, I’ve used a web server, OneDrive [ microsoft.com], and NextCloud [ nextcloud.com] depending on the client’s preference.
Systemize Everything
Automate what you can, systemize anything routine that is left to do manually.

This definitely includes consistent and proper documentation writing. If you can’t automate it, at least systemize it.

A couple of notes regarding this system. While it works for me, it may not work for you.

The final step doesn’t apply to source code, unless there is a front-end, in which case, I would have developed the front-end using this system as well, so it would also be fully documented during creation. This can backfire if you’re constantly revising your front-end since you can invalidate your documentation with every new change.

I write documentation in Word, LibreOffice [ libreoffice.org] or Notepad++ [ notepad-plus-plus.org]. For coding on a desktop, I like Atom [ atom.io] and from the command line, I’m an old-school fan of vi [ wikipedia.org] with no intention to ever switch. Neither of these editors make comments any easier to create, but if you just write them as part of your standard practices, this process quickly becomes your auto-pilot.

Tip #3 – Don’t Trash Talk The Person You’re Replacing

If you ever take over for another sysadmin, you will be inheriting their set up, for good or for ill. I’ve personally replaced amazing IT wizards and felt nervous trying to live up to their encyclopedic level of Unix mastery, but I’ve also inherited messes.

When I stepped into the worst “garbage fire” situation of my career, the company had pirated Windows on all 30 of their machines, had open WiFi on their main business network, and left all their workstations unlocked without any password protection with the entire company’s sensitive information unprotected.

Despite how dire the situation was when I took over their IT department, I never once directly criticized the previous IT director. I simply purchased valid Windows keys, set up a separate public-facing network for WiFi, set up a Windows Server on-premises for AD and set up GPOs that locked inactive workstations and required complex passwords that had to be changed every 30 days.

There was nothing to accomplish by insulting the previous employee, and everything to gain through helpful actions that improve the situation. I identified current deficits, informed the owners what should be addressed, how much it would cost, and how quickly I could roll out the solutions.

I didn’t shame them or give them the hell-fire wrath speech but instead educated them on their existing problems and how I could easily fix them. Despite the cost, they greenlit almost every project I submitted over the next several years due to the trust I built early on.

Yes, the last guy in that position didn’t do a good job, but instead of taking the low road and attacking his character, I focused on identifying problems and implementing solutions that benefitted the business. It’s professional, it’s to the point, and you avoid drama by not offending people who liked the person you replaced.

Tip #4 – Do Basic Troubleshooting Before You Skip to Advanced Diagnostics

This was the second most voted tip and is important because you end up wasting valuable time when you ignore it.

By far, this was the community tip that I am still guilty of violating the most. Sometimes I’ll skip a basic troubleshooting step and then waste a bunch of time on some advanced diagnostics… only to figure out the solution was the basic step that I had skipped!

Since I still struggle with this tip, I have decided to focus on starting from the ground up when troubleshooting. No more advanced diagnostics for me until I’ve ruled out all the common problems!

Tip #5 – No Changes on Friday

I wish I would’ve known this tip earlier because I would often make changes on Friday and then have to come in over the weekend to make sure Monday morning went smoothly. That’s not a big deal if you’re being paid hourly, but it sucks when you’re on salary and forced to come in on your days off.

This one tip alone can save you from losing so many weekends. This really is a tip I wish I could go back in time and share with me 20 years ago.

Some other Redditors shared variations on this theme, including “no updates after tech support leaves,” “read-only Fridays,” and “no changes after 3 pm on Fridays.”

Another discussion, which I agree with, centered around the fact that you sometimes have a large amount of maintenance to do and that sometimes working on Friday is required so that you have the necessary time to wrap everything up by Monday morning.

Tip #6 – Become an Expert on the Open Systems Interconnection Model

Having a solid foundation in the underlying structure of layered networking will make your life as a system administrator much easier. Without an understanding of OSI, you’re basically troubleshooting networking issues in the dark!

While this was just the 5th highest rated tip, it is my personal favorite and the one I think will benefit new sysadmins the most over the course of their careers.

Tip #7 – Make Regular Backups & Test Restore Them On a Schdule

If you haven’t tested the restoration process, then you haven’t made a backup. I like redundancies and rolling snapshots in conjunction with full backups. However, at the end of the day, the most important thing is ensuring that your backups work.

This is one of those lessons I learned the hard way. We lost a critical system, I fired up the backup and the restoration failed. I then spent the rest of the day trying to salvage the backup, to no avail. This is the type of disaster you’re setting yourself up for when you don’t test your backups.

The entire point of making backups is to have them to help you when things go wrong, but if you don’t regularly test out the restoration process then you may find out too late that your backups aren’t functional.
Free Backup Software I Use
To me, there is no such thing as “too many backups.” I like to deploy multiple solutions, which I’ve listed below.
  • Create Synchronicity [ sourceforge.net] for Windows (in place of using a cron job on Linux)
  • File History [ microsoft.com] on Windows 10 that replaces the Backup and Restore offered with Windows 7.
  • ODIN – Open Disk Imager [ sourceforge.net] – Useful for command line backups of disk images on Windows.

Tip #8 – Make a Backup or Snapshot Before Doing Any Major Changes

It’s easy to be confident but it’s hard to roll back changes if you didn’t make a backup before you started. If everything is working before you start, it’s a good idea to take a snapshot or backup so that if the worst-case scenario plays out… you can just restore to the last good working configuration and try again later.

Tip #9 – RTFM (Read the F***ing Manual!)

It doesn’t matter if it’s hardware or software if you haven’t read the manual and you have a question, you should start there. The manual is going to give you all the foundational material you need to understand exactly what you’re working with. Generally, everything that you need to know about the product should already be in the manual.

Tip #10 – Use Calendars & Setup Auto-Renewel for Domain Names & Certs

Even giant corporations fail to do this sometimes, resulting in lost operational hours and disruption in services. It’s a good idea to automatically renew certificates and domain names so that you don’t need to worry about manually renewing them. Regardless, you should note these expirations on your calendars and also set up email notifications so that you don’t let something critical expire.

Tip #11 – Don’t Keep Legacy Systems Just Because It’s Easy

It can be a lot of work to roll out new hardware, so it’s common for legacy systems to stay deployed long after they have been made obsolete. This is fine in a lot of cases, especially for equipment that isn’t exposed to the internet. However, legacy systems that are exposed to the internet need to be replaced once security patches are no longer being issued. Otherwise, they are a persistent security threat until retired.

Tip #12 – Only a Few IT Certifications Will Actually Get You a Job

Getting a certification is a great way to prove you know a subject and also a source of revenue for the certificate issuer. Unfortunately, most professional certificates are designed primarily as a source of revenue, either directly or through indoctrinating you into the company’s ecosystem of products. That means if your goal is to get employment as a result of your certificate… you should choose your certificate wisely.

Here is my short-list of IT certificate companies that I believe can help you get employed as a sysadmin:

I maintain a giant list of free certifications that I try and update daily, but I’d recommend those mainly for learning purposes rather than direct employment opportunities. I’ve previously written a rather long article on whether or not free certificates are worth acquiring which explores the topic in-depth.

Tip #13 – Not Everyone Is Going to Like You

Earlier I talked about securing a company with lock screen timeouts, password complexity requirements, and password changes mandatory every 30 days. When I rolled this out, I had a department head blow up on me, telling me I had ruined their productivity, cost the company millions of dollars, and that they were going to get me fired.

I never got fired, but that person never liked me after that. They’re not the only person who took offense to me doing my job. Heck, I’ve even upgraded someone from a Core 2 Duo to a Ryzen 1700 workstation and they were pissed off having to redo their icons and resyncing their Chrome browser.

Don’t take it personally. Different people have different computer skill levels, and when you come and change things, not everyone is going to appreciate those changes… even if they’re clearly for the better. Also, when tech things go wrong, some people might blame you. Again, don’t take it personally!

When I initially posted this tip as part of the reddit post, I had worded it differently which elicited this reponse:

I agree that you shouldn’t try and make people angry, but my point is it’s hard to avoid so don’t take it personally when it happens. However, Zaphod_B here has some great counterpoints in that you should actively be trying to build a good relationship with everyone you work with.

Tip #14 – Develop Consistent Policies, Automate & Systemize Everything

In tip #2 I talked about documenting everything, which was a by-product of this tip: to systemize everything that can’t be automated.

When you develop clear policies and systems around your workplace, you can rest easier on sick-days or when someone new is on-boarded, knowing that everything is being taken care of. This consistency also helps your end-users as well as other IT staff to all stay on the same page and act predictably under any given scenario.
In terms of automation, if you perform a repetitive task with a mouse or keyboard, then it can probably be automated through a batch file, macro, cron job, or task schedule. One commenter mentioned checking everything (documents, scripts, code, and infrastructure) into a Version Control System, which is one effective way to systemize your department.

Tip #15 – Build a Trusting Relationship With Upper Management & Every Day Employees

When I made my Reddit post asking for sysadmin tips, I included 16 tips of my own. A handful of those tips were worded a bit negatively and were aimed at either upper management or regular end-users.

After reflecting on those criticisms, I have to agree with them. I was wrong, and that’s alright (see tip #1.) If your goal is to help others, then it’s hard to go wrong even when you make a mistake. At the end of the day, if you can engage upper management in an honest and open relationship, they can help you build the best IT department possible.

In the same token, the IT department only exists to service the needs of the end-users. They really are your main customer as a sysadmin, and so keeping them happy and productive should always be your main goal. Work with them, keep them in the loop, and try to make their lives easier.

Tip #16 – Constantly Learn New Things, Don’t Always Rely On Google

None of us know everything, so often we turn to Google to fill in the gaps in our knowledge. This is perfectly fine, but you need to learn and retain important information that you’re looking up. If you can’t repeat it back in your own words an hour later, you should study the subject so that you retain all the relevant information important to your job.

For effective troubleshooting, it is best if you completely understand the foundation or underlying principles. Google is there for all the specific details that are hard to remember, but if you have a solid grasp on the fundamentals then you have a good foundation to begin troubleshooting from.

Tip #17 – Put As Much As You Can Into Your Retirement From Day 1

The exact advice here depends on the details of your company’s retirement plan options, but I must confess, this is another tip I wish I could send back in time to myself at a younger age. Start early!

Tip #18 – You’re Better Off Buying Ethernet Cables Rather Than Making Them

To start out, I want to say there are times when making your own ethernet cables makes total sense, such as:
  • Running large amounts of cabling across long distances, like a warehouse or industrial park.
  • When you have an existing cable that has a damaged connector that you don’t want to re-run.
  • When you’re milking the clock and want to look busy while actually not doing a whole lot.

Generally, I find the time and effort it takes to create ethernet cables erode any savings I might have gotten from not ordering them “pre-assembled.” In fact, since I charge $125 an hour, making ethernet cables cost a ridiculous amount of money to my clients compared to buying them.

Tip #19 – Some Really Smart People Don’t Know Anything About Computers

I know someone who has a photographic memory, who can tell you the birth date of every president, the capital of every state, the score of every Yankees game, and yet they do not even know how to open a web browser because they’ve never used the internet. People who don’t know how to use a computer may seem rare, but I still encounter them in almost every company I do consultation for.

When I write documentation for end-users, I try to write them as if they had no prior computer knowledge. That means I’ll explain even basic steps in any procedure and/or I’ll link to documentation intended for beginners so that anyone reading the document can get up to speed and follow along.

Tip #20 – Make You & Your Work As Transparent As Possible

If all your work has a paper trail and it’s easy to follow along, no one will question what they’re paying you for because they already know. What I do personally is to make a note in a spreadsheet every time I perform a task. I submit this spreadsheet every time I invoice a client along with an email that overviews all the wins, losses, and things still on my todo list.

Tip #21 – Learn to Say No

Sometimes someone will want to task you on a low priority, low yield job while you have other more pressing matters to attend to. If your house is on fire, you’re not going to worry about fixing your dripping sink, and in the same way, you need to prioritize mission-critical tasks before spending time on vanity projects or other less valuable distractions. It can be hard to say no, but sometimes it is necessary.

Tip #22 – Practice Interviews By Routinely Applying for New Jobs

This is a tip that I would’ve never thought of, but I like it a lot. Reddit user “Jupit0r” cautions that you “shouldn’t stay at any one place too long” or else you might feel stuck there. I can definitely attest to that feeling. His solution is to go out, at least once a year or more, and apply for other jobs to keep your interview skills up to par. The side benefit of this strategy is that you might end up with a better job!

Tip #23 – Mentor Your Staff So That They Don’t Need to Bother You

If you’re lucky enough to be a sysadmin with an actual team of IT staff underneath you, then train, build up and mentor them to close as many tickets as possible without your help so that you can focus on the high-level stuff and actually have days off without getting disturbed by work.

Tip #24 – Verify Anything You Hear, Since People Have a Habit of Repeating False Information

There’s not a lot to this tip, but it’s still highly relevant, especially in the world of tech.

I’ve actually done a lot of electrical wiring in my career, and the story that jumps out to me regarding this tip is shocking… literally.

I was about to wire up an on/off switch and I asked my co-worker if he had turned off the breaker. He said yes, so I started wiring up the switch and before I knew what was happening, I was being electrocuted! He hadn’t turned off the breaker after all. If I would’ve used my voltmeter I could’ve verified this for myself, so a hard lesson learned. I don’t recommend learning lessons the hard way.

Another Reddit user named greenonetwo phrased this same tip a bit differently:
Don’t assume anything. Ass – u – me.

Tip #25 – Supposed “Temporary” Solutions Often Become Permanent

This is a really good tip left by Reddit user Doso777. It’s another one where I wish I could go back in time and tell myself to “do things right the first time” because in the world of business, you often only have one attempt before moving onto the next project.

Tip #26 – Under Promise, Over Deliver

I live and breathe this tip as much as possible, especially when it comes to estimating time-frames. If I think something will take an hour, I quote 2 hours. If I think it will take a week, I quote 2 weeks. This doubling ratio may not be right for you, but after 20 years my experience tells me that I need to double whatever I estimate to be safe.

The beautiful thing about doubling my time-estimates is generally I am right the first time and am able to deliver in half the time I quote. This looks really good to the client, but it also gives me leeway in case everything goes wrong.

Tip #27 – Don’t Be Afraid to Ask For Help

If you don’t know something, chances are someone else does. They may be on stack overflow or down the hall, but regardless, don’t let pride prevent you from reaching out and finding the solution. You don’t know everything and you never will, but luckily no one expects you to have infinite knowledge. Reach out to experts when you need to. Two heads are better than one, and as Reddit user ajscott says “sometimes a different perspective makes all the difference.”

Tip #28 – Measure Twice, Cut Once

An ounce of prevention is worth a pound of cure, etc. The point is that you should build robust, well thought out solutions, not flimsy band-aids.

Part of building a robust solution includes proper documentation so that anyone walking into this business will have a quick path towards understanding how and why your system is the way that it is. It also means you should spend time engineering your solution and considering the cascading effects that will occur with different implementation strategies before you ever roll out your final solution.

In case you’re wondering about how to properly engineer a solution, Reddit user thermalblac offers this advice:
Cardinal rule of systems engineering: keep it simple

Tip #29 – College Doesn’t Properly Prepare Students for IT Jobs

This is based solely on my personal experiences working in the field, but I never met anyone fresh out of college who was actually prepared for their IT role.

Specifically, I’ve watched Computer Science graduates who specialized in programming drown under the weight of real-life coding. I’ve watched a Computer Science graduate who specialized in Windows networking quit in frustration when trying to troubleshoot a SPARC server running Solaris. I’ve watched a Computer Science graduate punch a CRT monitor and break their hand over Novel Netware frustrations. All of them were fresh out of college, and none of them were prepared for the real tech world where outdated crap like Netware somehow still survive.

What prepares people for working in the IT field… is working in the IT field. In the same way that a soldier will never truly understand warfare until they’ve fought in a battle, the IT college graduate will not understand tech until they’ve worked on the frontlines and earned some battle scars.

Tip #30 – If You Don’t Educate Management, They May Direct You Inefficently

You may be lucky and have someone in upper management who actually understands tech and your role in the company. For most sysadmins, this is not the case.

You should try and foster a trusting working relationship with management. They probably don’t want all the details of every problem, but do want to know about solutions, including how much they will cost in time and money. Educate your management team, but don’t bore them with technical details unless they request them.

Don’t be afraid to say no if they try and direct you to start meaningless or fruitless tasks. Let them know why the task isn’t ideal. If they still insist, then you should fulfill their request, but at least you know that you tried to stop them from wasting company resources.

If you and upper management can work together, in unison to accomplish your shared objectives, then the whole company will benefit from your efficient and synergized work.

Tip #31 – Microsoft Licensing is Confusing

I guess this isn’t really a tip, but actually more of a complaint! The problem is that if you call up Microsoft and talk to 4 different reps, you will get 4 different answers when it comes to licensing questions.

I guess the tip here is don’t ever expect to understand Microsoft licensing because apparently, no one at Microsoft can agree about how their licensing actually works. Also, they change the licensing terms on a regular basis.

Tip #32 – Build Trust & Consistently Communicate With Everyone

All human relationships rest upon the cornerstone of trust. If there is no trust, the relationship is shattered and team building is impossible. Before anything else, you must build trust.

You earn trust by honestly communicating and by actively working to help people and solve their IT problems. If you can be the person who is known for helping others, people will trust you and your job will be easier as a result of not dealing with a bunch of drama.

You won’t be able to understand people’s problems and pain points if you’re not effectively communicating with them. In turn, your people will not understand all the helpful things you do for them if you don’t effectively communicate the features and benefits that you’re providing your users.

Tip #33 – Make a Backup Plan In Case “Plan A” Fails

This article has a lot of sysadmin tips, but if you remember, the first one was to “own your mistakes.” Logically, if we’re planning on making mistakes we should have some backup plans to fall back on when those mistakes happen.

Having a secondary plan is not planning for defeat, it’s planning for continuous service and business operations in case the primary plan has a temporary or permanent delay. This is another area where pride can get in the way. Don’t be proud, be smart and flexible by having multiple options on the table for any given situation.

Concluding Thoughts

There’s so much to learn as a sysadmin, but by the time you’ve learned a good portion of it… you find that 10 years have got behind you. No one told you when to run, you missed the starting gun

Seriously though, if you know someone starting in IT, send them this article and help them save some of their precious time on earth. If even one tip here saves them one weekend of unnecessary work then it was worth it.

If you have any good sysadmin tips you want to add, please leave them in the comments below as well! Speaking of good sysadmin tips, here is a good Reddit post that didn’t make it into this article yet but is about to:

I want to thank everyone on /r/sysadmin for their contributions. This post wouldn’t exist without the efforts of the community, and I hope this group effort actively helps up and coming IT professionals. Please let me know if this post helped you in the comments below now.

Notify of
Inline Feedbacks
View all comments