But I’m a Sysadmin/Scripter/Commandline junkie

I’ve been guilty of this in the past, but one thing I have come to realize is that scripting is programming. Running ad-hoc commands at the command line is programming. When you type some content that directs the computer to do some work, you are programming.

So, when you say “I’m not a developer”, I hear:

• I write “throw away” scripts
• I don’t use source control
• I don’t build reusable scripts
• I don’t test my scripts
• Anyone should be able to do this

Stop devaluing my profession

Scripting and command line work is important. It should be treated as such and treated professionally. While you may not have adopted all these practices, you need to start.

Everyone writes “throw away” code

While everyone writes “throw away” code once in a while, professionals do more than just that.

Source Control

When you use source control, you are saying “my work product is worth protecting and sharing amongst my team (or wider)”.

Using source control removes the assumption that you are writing “throw away” code. It says you are treating your work output like it has value.

Building reusable scripts

One of the hallmarks of professional development is code reuse. Rather than reinventing the wheel or having each team member solve the same problem a different way, professionals share scripts (or modules or libraries). If you aren’t adding to the libary of things your team can do, your sole value lies in what you physically do. Professionals are enablers of others. People occupying a job focus on what they alone can do.

Testing your scripts

Testing for professionals isn’t “run the comamnd and run for cover”. Using testing tools and checking all the logic you can outside of running the commands can provide a level of confidence in how your script will behave. Running it in test environments gives you a further level of confidence your code does what you epxect it to do.

Building scripts is a skill

While PowerShell is extremely approachable for new users, it takes time and effort to get good at it. By acknowledging that we are developers, we give ourselves permission to build that skill as part of our daily work.

Maybe it’s time for a change

I like where this is going

Pick one thing.. start using source control. Get comfortable with it.

Then start adding in some Pester tests.

Don’t try to go back and boil the ocean by writing tests for all the things. Just write tests for new stuff you are doing or edits you are making to existing scritps.

That’s not for me

If any of this stuff is scary to the point of, “I don’t want to get anywhere near that.”, you probably want to find a different line of work.

IT work is going to continue to evolve and if you can’t build solutions (which requires development), your options are going to be increasingly limited in the field of IT operations.