With each post, I cover a new topic to help you get your start (or keep progressing) in your IT career. If it’s your first time, start here. Or, see all my posts about interview questions you should definitely be prepared for.
There is a rite of passage that will occur in every Siliconian’s career: that moment when they graduate from the GUI to the Shell.
Just in case that first sentence didn’t fully make sense, let me quickly define the terms.
GUI is “Graphical User Interface”. It’s pronounced “gooey”. It means you are clicking things in some kind of interface to get results. For example, Windows is a GUI. You point your mouse at something, click, and get a result.
A shell, on the other hand, is usually a command line interface. You type what you want to get the result you want.
GUIs are nice when you’re starting out because you can discover how to do things pretty easily. You can tinker until you figure it out. CLIs (command line interfaces, in case you weren’t paying attention) are less friendly. They require some pre-existing knowledge to operate.
Let’s look at an example:
Jill’s manager has asked her to take over creating new user accounts. The process is fairly simple from the GUI. Click new, select user, enter first name, last name, office location, department, job title, and finally add them to the correct groups that will allow them the right permissions to resources.
It’s a lot of clicking, but it’s easy enough when you’re doing one-offs. But after a few months, Jill starts to get annoyed at having to do the same thing over and over. And over. And over. Still, she’s busy and doesn’t have time to look into improving a process that doesn’t cost her a lot of time.
Then one day that all changes. Jill’s manager informs her that she’ll be in charge of new user creation for all the company’s offices. She’ll be provided with a CSV (Comma Separated Values) file containing the information she needs every morning.
Jill opens the first CSV file and stares in disbelief. Five hundred entries.
Now, Jill’s got two options. She can dedicate the next four hours of her life to manually creating these entries. Then, tomorrow, she’ll receive a similar list and lose another four hours (or whatever.) She’ll do that for a few weeks and fall behind on her other work. Or, she’ll make mistakes from the sheer drudgery of it all and someone will start on day one without a user account. And then, two months on, Jill will be fired for underperformance. By that point, she’ll probably welcome it from sheer boredom.
But, Jill’s no dummy. She’s rolled the tape forward and sees that it’s not an option. Reluctantly, she makes the decision to spend some time up front to automate this task.
And there it is. That moment. The rite of passage. For the first time ever, Jill opens up a CLI.
There are many different command line interfaces. If you’re working in a Windows shop, you’ll want to look at PowerShell. If you’re using Linux, you’ll have Bash. But for now, let’s not focus on one over another. I’m going to stay vendor-agnostic here, in the interest of getting you to understand the purpose of whichever shell you decide to go with. So I won’t use actual code, I’ll use pseudo-code, which is essentially scripting logic written in plain English. Scripting is what you’ll actually be doing when you sit down in front of PowerShell or Bash.
Jill sits down at her computer and starts typing a few commands. They follow a logical sequence, which is much like what she’d be doing at the GUI – Step 1: look at the user’s name. Step 2: click new user. Step 3: type user’s name in the name field. And so on and so forth. The only difference is that now she’s going to have the shell do it for her. Her script might look like this:
Set the last name to whatever is in line one’s last name field
Set the first name to whatever is in line one’s first name field
Set title to whatever is in line one’s title field
Set department to whatever is in line one’s department field
Add the employee to the right group
(If employee title is Sales Rep, add employee to Sales group
If employee title is Engineer, add employee to Engineer group)
Go to the next line in the CSV file.
If there is another line, start over from the top.
If there is no next line, print out “All users created” and stop running script.
End of script
Now, when Jill runs this script, assuming she typed everything right the shell will run all these commands for her until all five hundred lines of the CSV file have been iterated through. What would have taken her hours will now take her seconds. Because this script will run in seconds. Yes, there will have been the up-front work of creating the script. This may be a few hours when you’re still new at your CLI of choice. But once you’ve learned about it a bit, you’ll be able to write a script like this in less than thirty minutes. (If you’re talented, you’ll probably go a lot faster than that too!)
So, let’s go back to the way beginning of this post – the title. “What should I learn first?” Well, once you’ve gotten the basics of your job down, you should learn to automate. Since most people will work in a Windows shop, I’ll focus on PowerShell. (I’m not making a value judgment on Linux VS Windows VS Mac. Microsoft just has the numbers when it comes to OS’s you’ll find in offices.)
There are two ways to go about learning PowerShell. One way is to Google what you want to do and try to figure out what’s going in. You might end up copy and pasting a script you find online only to find it didn’t work (if you’re lucky) or that it broke everything (this is the most likely scenario.)
Did I mention PowerShell can be very unforgiving?
So, option two is that you buy (gasp!) a book (double gasp!) Take that book and read it. Every. Damn. Page. Underline what’s important. Look up what you don’t understand. Pester your coworkers with questions about it. Learn the fundamentals.
You can then come up with your scripts by yourself. This allows you to trust them, because you wrote them. If you need to look something up, you understand what you’re looking at. And when something goes wrong, you’re able to troubleshoot it. If you don’t understand the basics, that last part is very hard.
I learned PowerShell by using this book.
I can’t recommend this book enough! It’s based on PowerShell version 3, which is not the most recent version, but the basics of PowerShell haven’t changed, so I think it’s still a good read.
If you’re in a Linux shop, you’ll want to learn Bash instead. You can try this book, which I haven’t used myself but have heard good things about.
That’s it for now, Siliconians. I’ll leave you with this quote:
“She who does not automate tasks is doomed to repeat them.”
(I’m not sure who to attribute this to. If you know, leave me a comment so I can edit this!)