The Hard Part is not PowerShell

I’ve been writing scripts in one shape or form for over 20 years now. During this time I’ve written scripts in batch, AutoIT, AutoHotkey, SQL, PHP, ASP, VBscript and PowerShell. I love automation and typically take hold of whatever scripting language I need to use.

If anything, writing literally thousands of scripts to do all kinds of crap has taught me that the hard part is not getting the script to do what you want it to do; it’s figuring out what you want to do in the first place!

When faced with learning a new programming/scripting language I found the core methodology to be all very similar. Every modern OOP language has variables, constructs, objects, properties, methods, etc. You can always loop over a container of items whether you call the container a collection, an array, a hash table, an associative array, an array list…whatever. You get the point. At their root, they all give you similar tools to solve a particular problem.

Let’s keep this conversation related to PowerShell.

If you’re new to PowerShell or scripting in general and chose to use PowerShell to solve a particular problem don’t be scared of PowerShell itself. If you get stuck on that particular loop or what data type to assign to that variable when it does that thing Google is at your fingertips.

You have and thousands of other resources at your disposal that you can call on to quickly diagnose the problem. IMO, you needn’t focus on how to write the Powershell script, you need to focus more on what to script. Let me give you a couple of examples.

You need to query a SQL server? Not a problem! The Powershell code has already been written into a nice module called SQL PSX. Download it, import it and do it. You’ve got the capability now to query SQL but where’s the data stored you want?

”I see 500 tables and views, where was the data stored again?”

”Damn, it looks like I’m going to have to figure out how to do a few JOINs…”

Before you know it, you’re cracking open a copy of SQL For Dummies. The what is a whole lot more complicated than the how.

Do you need to perform a WMI query? Not a problem! One line with Get-WmiObject or Get-CIMInstance and you're good to go.

Do you say you want to gather something about batteries on your laptops?

So where's THAT stored?

You have no idea which class, what properties/methods you'll need to use to pull the data you're looking for.

This one is near and dear to my heart. You know you can use Start-Process to kick off a msiexec.exe process to install it but how?

What's the GUID I need to feed to it?

Will it bomb if it detects an already existing version?

What were the special, crazy switches the installer needed to do that one, obscure thing you needed?

You get my point. To build a robust, reliable and reusable Powershell script you should not just dive into the code headfirst.

Even though it may be the most fun to do and even though it may “work” at first start to get into the habit of planning your script ahead of time. Write pseudocode of what you want the script to do. Use comments religiously or use regions to break up the code into chunks of what you want to do before ever writing a single letter of actual code.

Define what you want, figure out what you’re going to do and where that information is stored. Once you do this legwork, writing the script to do it will just fall into place.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store