Are you still manually creating new virtual machines? Are you going into the Active Directory Users and Computers tool and creating, modifying or resetting passwords? If so, you may be looking for a new job in 5 years.

In today’s fast-paced IT environments and cash-strapped organizations, IT professionals, system administrators, database administrators or anyone else in IT is constantly being asked to do more with less.

Quit naming servers URANUS

The old ways of managing servers, desktops, databases et al just can’t keep up anymore. We’re no longer allowed the luxury of personalizing servers with names, RDPing to machines to make a configuration change and making the same change on lots of machines one at a time especially in an enterprise.

How can we non-software developers keep up with this pace?

Code.

Coding is not just for software developers

You may be thinking, “Code? I’m not a software developer. They code! I manage the infrastructure”! Technically you’d be right but I’d argue that those little ad-hoc scripts you’ve got laying around need to be thought of differently. Those scripts consist of code. You are a developer.

Traditionally, when someone was referred to a coder, they were speaking about a computer programmer or software developer. This coding term has beens solidified in our brains for decades now. There has always been a clear demarcation point between a developer and a system administrator.

But nowadays, DevOps is changing that. Organizations are tired of of developers and operations fighting over who’s fault it is that the app server died. They’re tired of the constant blaming and lack of collaboration. A business just wants to do business and two groups of bickering children doesn’t bode well for that goal.

Over time, this disparity between “coding” and system administrators eventually was noticed across organizations and the DevOps movement was born. System administrators now needed to learn about the developers’ world and vice versa. It’s time to wave the white flag of peace and understand that we’re all on the same team and begin working towards that common goal.

One of the lessons that a DevOps culture teaches IT professionals is code is good. Code is not just for developers and code does not just build software applications. Code can, in fact, apply just as well to a sysadmin’s job of provisioning infrastructure, creating user accounts, building databases and nearly everything else on a sysadmin’s daily todo list.

Code opens up new doors

As soon as these tasks are written in code, IT professionals now begin to reap the benefits of defining work in code can do including:

Self-executing documentation

Change tracking across the infrastructure

Automation

For example, what’s it take to create a new Active Directory user via the GUI?

Figure out where the tool is on your computer

Double click on the icon

Find the OU you need to create the user in

Right-click on the OU

Click New user

Fill out all of the fields

Click finish

…and do you perform this right 100% of the time? Probably not. In code, it might look something like below and can be executed by simply typing out a single line in a PowerShell console.

<# .SYNOPSIS This script connects to the default domain controller on a domain-joined computer to create a new AD user while also creating the user's home folder with the same name as the username. .EXAMPLE PS C:\> .\New-User.ps1 -UserName jjones -FirstName 'Joe' -LastName 'Jones' This example creates an AD user called jjones with a given name of Joe and a surname of Jones. It also creates a home folder for the user at \\FILESERVER\Users\jjones. #> param( [Parameter()] [ValidateNotNullOrEmpty()] [string]$Username, [Parameter()] [ValidateNotNullOrEmpty()] [string]$FirstName, [Parameter()] [ValidateNotNullOrEmpty()] [string]$LastName ) try { #region Create the AD User $params = @{ Name = $userName GivenName = $FirstName SurName = $LastName } New-AdUser @params #endregion #region Create the home folder New-Item -Path "\\FILESERVER\Users\$userName" -ItemType Folder #endregion } catch { Write-Error -Message $_.Exception.Message }

Learning will be an uphill battle until it’s not

I’m not saying that writing this above example is going to be easy if you’re just starting out.

It won’t be.

It’ll be frustrating and you’ll want to go back to your old ways. However, automating things through code is like pushing a boulder. Whenever you first start out, pushing that boulder is going to be really hard and you’ll want to give up. But if you keep pushing, momentum will begin to kick in and things will get easier.

If your code is written with reusability in mind and like building blocks, you’ll soon find that the code you wrote last year can apply to today relieving you from having to reinvent the wheel.

Continuing this process over and over again will eventually allow you to automate all of the mundane, boring tasks so you can either focus on the more creative side of your job or even finding another job completely!