Key Development Skills for IT Pros

This post was originally published February 19, 2019 on AbleBlue.

In my former life as a consultant, I was constantly aware of the impact that the pace of cloud technology evolution has on IT professionals. Recently, while moderating a panel at Office and SharePoint Live! 360 in Orlando, I asked the question: “IT Pro vs. Developers, is it time to bury the hatchet?” The panel consisted of four great friends of mine, Eric Shupps and Ben Curry, representing the IT Pro side of the house; and Rob Windsor and Paul Schaeflein, representing the Developers.

As I watched, listened, cajoled and questioned, the general consensus from the developers was that IT still struggles with understanding “modern development and development tools.” While IT insists on Developers following a standard of practice, the IT pros themselves still use haphazard and sometimes risky procedures for themselves, and do not hold their IT teams to the higher standards development uses.

The general consensus from the attendees was they supported that contention. We heard story after story from the IT pros in the audience about how they are not supported with the right tools to become better, that the IT organizations are not investing in them and their future, that they are too busy fighting fires to take the time to learn something new.

While I do understand the reality that we are all busy, as a trainer in my previous life I recognize that organizations have to train their people and allow them the time to “Level Up” their skills. I think it is necessary for the employees’ well being, their organizations’ longevity, and ultimately the supportability of the systems they manage.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Microsoft makes it easier than ever for IT pros to get up and running with the necessary tooling to dip their toes in development waters, while making their job easier and providing a better process for the companies they support. IT pros may start by initially switching from PowerShell ISE to VSCode with the PowerShell Extension. If you are “just writing scripts,” step up and try writing PowerShell Modules instead.

Here are four ideas to get you started.

Repeatability

I am always thinking about how repetitive a task is. If I have to do it more than 2 times I’ll try to figure out how to be more efficient. For example, if you have ever written the same script over and over, start thinking about creating PowerShell Modules for the functions that you use repeatedly. These could be anything from routine maintenance tasks, to heroic data restoration tasks. By thinking about the tasks that would have to be executed in an emergency before the emergency happens, your stress level will be much lower when the day comes that you need the module.

Another idea to save time is using snippets when writing your code. There is a fantastic community project for Visual Studio Code (VSCode) called Awesome Snippets that will get you started. I have some customers that have created their own snippets that they share as a team.

Further Reading

VSCode PowerShell Extension – Write, Debug, and Test PowerShell in VSCode.
Awesome Snippets – PowerShell Code Snippets

Testability

On a recent project, I was concerned about the number of folks that were going to be messing with the module I was writing. I noticed a few individuals were not providing documentation, examples, or full sentences in the help text. Now this may not seem important, but if they are failing to properly document the code, how much attention are they paying to the code itself?

Back in November I had the pleasure to hear Thomas Vochten, MVP speak at SharePoint and Azure Connect in Haarlem, Netherlands. He demonstrated an approach to testing PowerShell using a module called Pester. This module ships with Windows 10 and there are updates available from the community. There are two reasons I really like this approach.

1. The process of creating tests helps you ensure your code works as you intended.
2. The process of creating tests and monitoring code coverage can help ensure that you test the alternate paths of your code.

There is a “tax” associated with creating tests, however — it takes time that does not directly impact the delivery of your PowerShell code. I admit, I am not “writing the test first and then writing the code,” in true TDD fashion. In fact, the first module I used Pester to test was a module I thought was nearly complete. That is where the PesterHelpers module can bootstrap a bunch of tests for you by reading your existing module and generating tests for you.

Further Reading

Pester – Test and Mock Framework for PowerShell
Pester Helpers – Helper functions for Pester
MVA: Testing PowerShell with Pester – Microsoft Virtual Academy Course on Pester

Version Control

I use version control for nearly everything I write. My documents are in OneDrive, not a version control system per se, but it is backed up to the cloud on every save. My blog posts are written in markdown, and version controlled in Azure DevOps (aka VisualStudio.com). All of my PowerShell modules and scripts are in separate projects by Customer and/or Project and stored in Azure DevOps. It doesn’t matter if it’s Azure DevOps or Github.com or any other system you are familiar with, most of these systems use a flavor of Git for version control. I think that every technical person should have a grasp of the basics of Git. You need to be able to Fork, Checkout, Branch, Add, Commit, and Merge with confidence.

I am pretty comfortable with this process because I use it every day. Do I NEED to? No, could I use OneDrive for my module files, sure. But by forcing myself to implement these practices, I can talk to a developer about Git and the issues they face with a shared understanding. I can transition from working on my Surface on the couch with my dog Ruby, to my home office, to the Mac at my downtown Austin office, with ease and confidence. It makes me comfortable knowing I have all the versions of my edits stored safely somewhere other than one hard drive. Further, as soon as you add a team, it becomes significantly easier to share your stuff.

Further Reading

Azure DevOps – Project Management, Version Control, Build Management, and Continuous Integration

DevOps

I like to think of DevOps as thinking end to end, or holistically, in terms of the lifecycle of the work. From defining the problem to writing the first line of code to delivery to applying updates, “lifecycle” DevOps thinking will help your work be portable. For example, that cool module that you built that may, someday, need to be updated — are you the only person who has the code? Can your team update it confidently or update it without you? Can they change the code without erasing your farm, locking you out of the tenant, or causing other issues? Do they have to call you on your vacation…just in case?

DevOps is about supporting the enterprise and managing the lifecycle of your code whether you are a Developer an IT pro or a combination of the two. By creating testable code, you can configure your version control system to reject check-ins that do not pass the tests. You can configure the build server to automatically deploy your runbooks when they do pass the tests, so that they enter production as efficiently as possible.

In other words, I like to enjoy my vacations, and I assume you do, too

What items are on your shortlist for “The Next Thing” you want to learn to level up for your role?

The Interview