In my time as an IT guy and Systems Administrator, one thing I've learned is that being lazy tends to work in my favor. Not in the way where I let a ton of work pile up or in in the way where I neglect to complete the tasks that are expected of me. I mean in the way that leads to me automating myself out of a particular task entirely. 

The Need to Automate

When I first started out as a help desk technician, I did my best to do everything the way I was shown how to do it. This meant a lot of remote sessions and phone calls with clients to solve simple problems. It also meant a lot of satisfied customers, providing I did my job well of course. However, as I grew in the role and began taking on more responsibilities, doing everything the manual hard way wasn't scaling. I had some basic programming abilities, and I knew my way around Python scripts well, but Python doesn't work well for a primarily Windows environment. Because of this, I wasn't able to dive directly into automating for my environment at work; I had some learning to do first.

There were already lots of automatons that my colleagues had created over the years. On the whole, they weren't getting much use since the people who trained me didn't make much use of them either. I started looking into what some of them did and began finding ways to use existing automations in my day-to-day troubleshooting. In doing so, I learned something critical: clients are the happiest when you fix their problems without ever having to interrupt their work at all. Sure, there are some outliers that love to chat with IT on the phone, but on the whole, customers were thrilled if I was able to fix someone's issue without ever needing to call them on the phone or book a remote access session. The benefit of this was twofold: happy clients (which led to even more positive feedback), and the ability to handle more support requests due to the boost to my efficiency. 

Learning by Doing

Over time, my curiosity got the better of me as it often does. I was deeply fascinated by how these automation policies worked under the hood, and I was determined to figure them out. I began digging into the inner workings of things and was met with nothing but PowerShell each time I looked under the hood of something new. I was able to get a general idea of what was going on within the code but hadn't done much work with PowerShell at this point. I did some reading on the syntax and usage of PowerShell and began writing some of my own basic scripts. Thankfully, a background in programming and Python scripting helped accelerate the learning process significantly.

Over time, I learned what each of the existing automations in place were doing and even began to make minor improvements. I began writing more complex scripts of my own and eventually came to be highly proficient in PowerShell, writing modules, creating entirely new business processes from scratch and overhauling and modernizing older code. While my fellow sysadmins might balk at this, PowerShell has become my favorite scripting language; I even prefer it over Bash.

Benefits & Drawbacks

In a way, the title of this post is a bit misleading as I wouldn't consider myself, or any of the experiences I've written about in this post, to be lazy at all. What I am lazy about though, is doing anything manually. If it makes sense time investment wise to automate something, I will. The first execution of a new script that will shave tons of time off my day is incredibly rewarding and satisfying. Sometimes it's wrapping a simple one-liner in an executable automation policy so the help desk can easily get quick answers to questions without having to look up the correct formatting and syntax for a command. Other times, it's a few hundred lines of code that will automate a significant and time-consuming manual task out of existence. Regardless, clicking "Run" on code I wrote or contributed to is one of my favorite things I get to do each day at work.

I'll be the first to admit, spending time automating things can sometimes be a tough sell, especially when something turns out to be more challenging to automate than it might've initially seemed. Manual tasks and poor automation are both subject to user error and failure, from myself and my colleagues alike; being human is a tough and incurable condition. But when the time is spent to automate something properly with resiliency against failure, be it from an unanticipated input or an unexpected system state, it takes s burden off my team and I, and it removes the human error factor. Simple adding a check to ensure a valid ticket number is entered into a complex onboarding automation can have a significant knock-on effect. Something that simple can prevent a whole slew of problems that might have been missed during a manual process or even caused a poorly written automation to fail or produce unintended results. When done correctly, automation can provide an incredible boost to a team's efficiency and productivity.

Running a single script or automation policy compared with completing a time intensive manual task is, in my opinion, almost always the preferred option. The hours spent perfecting a complex script are all worth it when I get to see my team using my code to easily complete challenging, error prone tasks through automation. If clicking a button to solve a problem through automation makes me lazy, then I think being a lazy administrator is a good thing.