Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.
 

Learn to Code or Else: An IT Professional's Guide

By - Source: Toms IT Pro

System administrators and developers must come to the table and learn each other's jobs, or they may find themselves without a job.

Credit: sfiocracho/shutterstockCredit: sfiocracho/shutterstockAre you 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 IT environment, IT professional, system administrators, database administrators or anyone else in IT is constantly being asked to do more with less. 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.

MORE: Best Resources for Learning to Code

How can we non-developers keep up with this pace? Code. You may be thinking "Code? I'm not a 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. They usually just aren't thought of like that.

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

Organizations are tired 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 don't bode well for that goal.

Over time, this disparity between "coding" and system administrator 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 toward 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 to-do list. 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

Do you perform this right 100 percent 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 \FILESERVERUsersjjones.
#>
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 "\FILESERVERUsers$userName" -ItemType Folder
    #endregion
} catch {
    Write-Error -Message $_.Exception.Message
}

I'm not saying 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 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. Continue 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.

Comments