Part VI: Culture

This section focuses on all of the parts of work that aren’t in a console or web browser - how work has and will change, how to be a better teammate, how to grow as an engineer.

Where PowerShell Has Taken Work

It’s foundational to PowerShell to be declarative. As folks who work, we benefit from that same declaration of intent. PowerShell has removed much of the meandering from our technical workflows, and we can now share our declarative work with others in a consumable, repeatable, and collaborative way.

Equally importantly, the introduction of PowerShell hit a reset button for getting into our trade. Familiarity with the GUI has given way. What you did with NT 3.51 is no longer so important; it’s about what you’re doing today, and by leveraging PowerShell, you’ve supercharged what you can accomplish. A script isn’t a written note about a process or procedure, it’s a structured, source-controlled document that can be applied and reapplied easily in an intended environment.

Reminiscing

What’s new was old, and what was old is new again. If you look through the internet archive or (perhaps) a really well-stocked thrift store you might be able to find early computer magazines from the 1980s. One staple of these magazines was the inclusion of programs that you could type into your computer by hand.

Now, a thousand lines of BASIC might make for a pretty dull read today, but it’s an example of shared code thrown out into the broader world: to be shared, tested, mistyped, and—most importantly—modified by the reader. This gave you the ability to do something yourself. You had quite an opportunity if you were lucky enough to share a program that you typed in with your friends, peers, or computer club; you could gain a bit of notoriety by sharing your hard work with others who didn’t have the magazine, the time, or the ability to focus on tiny printed lines of code.

GUI

Jokingly, I could say that Xerox ruined computers with a GUI. By making computers more accessible, Xerox opened up computing to a whole new audience—and early Macintosh computers did much the same. Programming moved into the background, becoming something that only a subset of users engaged in, instead of all. VisiCalc and its compatriot programs started defining what a computer application could be. And over time, the conversation morphed from make, to buy. “I have a task, so I’ll build a tool” became “I have a task, so I’ll buy the tool that fits the job.”

It’s true that although buying a tool can restrict creativity, it’s unwise to talk in absolutes. However, we know from research with children and perception¹ that humans rely on information (books, blogs, etc.) and each other to form opinions and gain understanding. If you’re told that you have to look at a packaged solution, you may never take the opportunity to build something on your own.

Click Next

Here’s an experiment: Tell a friend what you think are the best directions to your favorite restaurant, and don’t let them write anything down. Note the despair in their eyes when you don’t give them the street address, probably the most critical piece of information they’ll need in order to actually get to the restaurant! Leaving out this level of information leads to confusion, misinterpretation, and editorializing. If you want to make sure that they get to the restaurant, and at the right time, you’ll need to transfer the important information succinctly. For example, the address can’t work only in MapQuest; it needs to work wherever the listener gets their directions. (Okay, maybe I’m making an argument for GPS coordinates.)

If your instructions are “click next in the dialog box” instead of declarative as Repair-DbaDbMirror, you’re going to run afoul of context really quickly.

Defined Patterns and Slowed Innovation

If everyone has agreed that Excel is the only way you’ll ever manage a spreadsheet, does it limit the conversation? Digging more, if the only accepted ways to automate a task are through Perl or C, then why would there be any reason to do something different? There isn’t. This has parallels to competition in business; if it’s accepted that there’s only Choice A and Choice B, it becomes very difficult to create Choice C.

Moving Forward

Communication can often be the prime mover. For example, in my organization, Active Directory exists only because of the implementation of Microsoft Exchange, which required the adoption of a directory service, and hence a move from Novell (or Banyan for the cool kids). In this scenario, Active Directory was almost a byproduct of Exchange.

Well, fast forward, and Exchange is now integral to communication in of lots of companies. Unfortunately, it’s a huge product, with lots of sprawl. You’ve got Mailbox, Transport and Client Access servers, not to mention the underlying SQL Server architecture. One might argue that Exchange circa 2007 was the start of a small cloud, contsisting of similarly configured, load-balanced servers. And we learned that you couldn’t efficiently manage an environment like that with clicks, but you could with that newfangled PowerShell. This moved configuration and management from Microsoft Installers (MSIs) and answer files to readable, reproducible code—just like our goal when we first opened an issue of Byte magazine. Now, as an IT Pro, you can spin up a test environment consistently and accurately. Combine this with the rise of virtualization (VMware went public in 2007), and we’ve got the beginnings of repeatable infrastructure.

In an early demonstration of PowerShell, from October 2004², Jeffrey Snover talks about how naming and consistancy are critical to the quick adoption of new technologies. After showing some of the commands and syntax to find system processes, he turns to the camera and tells a story. He says, there’s a joke in the VMS community, about how you can sit a VMS operator down, tell them that there’s a fish finder attached to the VAX, and question whether they can operate it. The answer from the VMS operator is, of course, show /fishfinder, get /fishfinder, etc.

While a fish finder on a minicomputer is pretty absurd, change and new products aren’t; replace fish finders with SQL Server, or Azure functions, and you see the importance. True, it’s all part of the perfect storm: a rapid rise in access to computing resources, the sprawl of feature requirements, changes in virtualization technology—so many little things gave PowerShell and its community a great place to start and thrive. However, these are just pieces of technology, and they do very little to address the folks that sit between the keyboard and that chair.

Nod to Cultural Change

PowerShell and its community wouldn’t be where they are today without the rise of companies like FaceBook, Google, Twitter and Microsoft. By taking on the primordial challenge of big change these companies had to transform existing business models to adapt them to customer demands. These needs at scale gave us the cloud as we understand it today–and for us to manage that scale we had to change the way we work, moving from treating our servers as pets, to treating them as cattle. We had to adopt DevOps practices as we know them, with all of their transparency, source control, and team collaboration. (While these are all great topics for another time, we’re here to talk about what DevOps did for PowerShell—this is a PowerShell Conference Book after all!)

Current Location

That amazing shift set the stage for a reboot of our environments. I would argue that, as IT Pros, we’ve been granted a fresh start. But many of us still run legacy systems–SMB v1 still haunts us despite Ned Pile³–and we might need to run a few hosts on old versions of software, for various shaky reasons. However—and this is the real point—the rest of our infrastructure is working in ways that are more accessible and designed in that spirit of transparency. In changing the way we work, we’ve removed the biggest barrier to change: gatekeeping.

Lords of the Gate

Think back to your first installation of SQL Server or CentOS. You probably installed it one step at at time, line by line, click by click. If you were to describe to someone else how to perform the installation, it would be much like those anecdotal directions to your favorite restaurant: a meandering tale of “First do this, then this, and oh, then do that…”

Compare that to what you’d do today, which is (I hope) more like: “Here’s what I wrote for my environment; you can see where I reference some of our internal practices, but read through it and hit me up on Slack if you have questions.”

Even better, there are numerous public repositories containing examples of what other people have done, plus blogs and social media posts that let folks find things on their own. There’s an easily accessible community of people who share your trade and are willing to put themselves out there as a resource for others. There’s been a big reduction in “who you need to know” to get access to this knowledge. It’s now easier (although not always easy) for folks with some internal motivation, and there are plenty of ways around traditional groups.

The point is, we’ve gotten back to “here’s the code; take a look.”

“But They Have Suspenders!”

We’ve got a second reason to be thankful for changes resulting from the adoption of cloud computing: it provides a strong incentive for companies to look at the environment (read: market), see where growth is, judge what their competitors are doing, and make some decisions. If part of your portfolio of services involves hosting Windows VMs or .NET-related services, you’re going to find PowerShell in the ecosystem.

Mix this with a Microsoft that’s hard at work going back to its roots—providing really great integrated development environments (Visual Studio Code) and making sure their products are everywhere (.NET Core)— and you end up with PowerShell running on Linux, and partners who make sure their modules work on the cross-platform implementation of PowerShell. You see things like AWS Tools for Windows PowerShell⁴ and VMware’s PowerCLI⁵.

When this kind of expansion across environments occurs, combined with an open tradition of sharing, you create a broad-based appeal that allows people with diverse experiences to join the conversation. Been a Unix admin for 30 years, but are trying some cloud deployments? Here’s some PowerShell. Are you a content designer and you want easier deployments—maybe even send your customers a demonstration environment? Here’s some PowerShell. These folks come to the community and, because of the adopted norms, they can start contributing—which, in turn, enriches the content that makes up the community’s body of knowledge. They stop being people in suspenders, or people with MacBook Airs, and are just folks.

Tale of Two Definitions

By this stage, I hope you’re looking at the PowerShell community in a different light, and maybe even smiling, because—just by reading this book, following folks, and most importantly contributing in some large or small way— you understand that it’s something bigger and more special than one user group or one message board. Here are two definitions that might contribute to your understanding.

A Community of Practice

A community of practice is a group of people who share a concern or a passion for something they do, and learn how to do it better as they interact regularly.

This definition reflects the fundamentally social nature of human learning. It’s very broad. It applies to a street gang, whose members learn how to survive in a hostile world, […] a group of engineers who learn how to design better devices or a group of civil servants who seek to improve service to citizens.⁶

Communities Aren’t Just Teams

A community of practice is held together by the “learning value” members find in their interactions. They may perform tasks together, but these tasks don’t define the community. It’s the ongoing learning that sustains their mutual commitment. Members may come from different organizations or perspectives, but it’s their engagement as individual learners that’s the most salient aspect of their participation. The trust members develop is based on their ability to learn together: to care about the domain, to respect each other as practitioners, to expose their questions and challenges, and to provide responses that reflect practical experience.⁷

(These definitions may seem a bit dense, but Etienne & Beverly Wenger-Trayner created the concept, and have a whole gig associated with it.⁸)

I was fortunate enough to participate in a Community of Practice in my local area, sponsored by Community Engagement Fellows.⁹ From the very first day, when communities of practices were discussed, I was amazed to realize at how well the actions of the broader PowerShell community already reflect this relatively rare and powerfully collaborative practice.

Where To Go From Here

The point of this chapter is simply to help you understand how special this community is. And the point of this book is to broaden access, to break down financial barriers, and to build a more inclusive and diverse community in which we can all benefit. It’s a charge to you, reader, to go from not knowing that you know, to knowing that you know. This is powerful and deliberate, just like your code, just like your source repositories.

Share, encourage, and contribute. This can be why we work.