Don Jones on PowerShell, Career Growth, and the First Follower

A Jane Street host welcomes the PowerShell meetup and explains that the Windows team uses PowerShell extensively to automate its infrastructure. The organizer invites first-time attendees and prospective speakers to join the monthly community gatherings.

I have worked with PowerShell since before its November 2006 launch. Jeffrey Snover invited me onstage at TechEd Europe when he introduced it, and we have been friends and colleagues ever since. I also helped found PowerShell.org and worked with the people who built its summit.

I want to connect the experiences that shaped my career with some practical PowerShell habits. Looking back at your past matters: things that seem unrelated can become strengths if you recognize how they prepared you for what comes next.

As a teenager I helped run Star Trek conventions, including one where Denise Crosby auctioned underwear for charity. We had to cover hotel costs, flights, and guest fees; I learned budgeting and scheduling long before I thought of myself as a businessperson.

Working at Electronics Boutique taught me just as much in another way. Experiences accumulate like arrows in a quiver. Once you recognize how an earlier job shaped your thinking, you can use those strengths deliberately in your next one.

A guidance counselor told me I could not work with computers because I was not good at math. I did not go to college; instead, I studied electronics and computer repair at a vocational school in Virginia Beach.

The Navy recruited civilian workers for depot maintenance on aircraft including F-14s. In a long apprenticeship I learned how an entire aircraft worked, and we practiced finding the fastest, cheapest way to return a battle-damaged plane to service.

That training made me see much of life as engineering: where am I, where must I get, and what is the critical path? When frozen pipes burst at our cabin, we had to decide quickly whether we could restore heat and water or needed to leave.

A temporary fix need not be beautiful if it gets the plane back in the air. But remember to go back and fix it properly later; people in IT sometimes forget that part once the emergency has passed.

After the facility closed in the early 1990s, I worked in retail and eventually became an AS/400 operator. I knew so little about the machine that someone had to explain it was a computer. Most of what I know I learned on the job.

That habit helped when PowerShell arrived after I had built a career around VBScript, including books with Jeff Hicks. I had to experiment and learn as I went. Even an unwanted detour can become an asset if it teaches you how to learn.

Consider a function with both a computer-name parameter and a file-path parameter. I would rather have it do one thing: accept computer names. You can read names from a file or a database elsewhere and pass them into the function.

Otherwise the function grows a new parameter for each source: a file today, Active Directory tomorrow. That growing complexity makes it harder for anyone to maintain. Keep the component small and use the wider system to assemble the behavior you need.

An audience member asks whether that means always using the pipeline. No: understand the system and use it as designed. You may supply a collection as an argument, for example. The principle is not a ritual but choosing the right mechanism for the job.

The same issue appears at the output end. A tool should emit its results to the pipeline instead of growing a separate file or CSV parameter: another command can put those results in a file or database.

A common beginner mistake is placing Format-Table inside the function. It may look good on screen, but formatting the data there makes it much less useful to downstream commands. Format the output at the point where a human needs that presentation.

Use PowerShell’s verb-noun naming convention and approved verbs instead of inventing your own naming system. People familiar with the environment should be able to understand what your command does without learning a private vocabulary.

Another example emits two different kinds of objects. Jones says that mixing output types makes the result harder for PowerShell consumers to handle. Instead, assemble the relevant properties into one custom object and send that object down the pipeline.

I distinguish tools from controllers. A tool performs a small, general operation without knowing the business context. A controller combines tools for a specific process: producing a report, presenting a menu, writing a CSV, or provisioning a user.

Keep generic tools simple and put the contextual decisions in the controller. The smaller the tool, the easier it is to write unit tests for it. An audience member notes the connection to the single responsibility principle in software design.

Following established software-engineering practices also changes how others see your work. You are not merely someone writing scripts to get through the day; you are building tools that may support critical business processes.

In this 2019 talk I advise against Write-Host, even though later versions connect it to the information stream. I prefer explicit commands such as Write-Information, Write-Verbose, Write-Warning, and Write-Error so the intended stream is clear.

I also argue against global variables in scripts, because code can run inside hosts that handle global state differently. Module-level variables have a narrower scope; an audience member’s GUI example can often use script-level variables instead.

I discourage return outside a class because its behavior can mislead someone expecting the return semantics of another language. PowerShell can already emit values before return; I prefer explicit output and control flow. Inside a class, return has a different purpose.

My other caveat concerns PowerShell classes as they existed when I gave this talk. Most tasks, I argue, are better expressed as functions; a class can define a structured object, but for substantial class work I suggest considering C# and its tooling.

Format and indent code so other people can read it. At the time I recommend VS Code over the aging PowerShell ISE and point to the emerging Windows terminal as part of a newer tool environment.

Put small functions into modules and use controller scripts to combine them. A user-provisioning process might call dozens of small tools in order. Select appropriate output streams, and consider whether a person will even be watching the script run.

Learn Pester and try test-driven development: write down the inputs and outputs, write tests for the desired behavior, then implement the tool until the tests pass. In that process the tests also serve as a functional specification.

Use modern source control and document the code. Good names can make obvious operations self-explanatory, so a comment need not repeat every command. But provide actual help, whether comment-based or generated from Markdown.

My book and workbook on helping others ask readers to write down their goals. I think the physical act of writing and a deliberate learning environment can help ideas stick. Jones frames this as an interpretation of how memory and the senses interact.

Set aside time and a place for learning instead of assuming an hour of video amid workplace interruptions will automatically be retained. His practical point is to give sustained attention to the material and create conditions that support it.

I have also become interested in the value of generalists: people who can handle a range of tasks well enough to move a project forward. Renovating our cabin means doing plumbing, electrical work, carpentry, and flooring, even when the result is not perfectly straight.

At Electronics Boutique, our manager taught every employee how to open and close the store, count money, receive shipments, and contact headquarters. That expectation gave me a much wider view of the business than a narrow role would have.

Later, as an AS/400 operator, I volunteered to learn a new phone switch. During a snowstorm I rewrote a troublesome point-of-sale program; my manager paid me for the work. The recurring lesson was to learn whatever the situation needed.

Do not let your place on an organization chart become your identity. Your employer owns the job and should equip you to perform it; you own your career, including the skills you may need after this particular job ends.

That may mean buying a book, finding training, or setting up a lab to learn a technology your current role does not require. A friend missed an opportunity with better pay and benefits because he had never learned an adjacent database skill he knew he needed.

You can love your company and still invest in your own development. Layoffs, a company failure, or an attractive new opportunity can expose the difference between being good at today’s job and having a flexible career.

DevOps is not a product you buy and install. I describe it as a way of organizing IT operations to enable desired outcomes, especially rapid, repeated software deployment. If that is not the outcome you need, copying the label alone is not useful.

In a traditional arrangement, project managers, designers, developers, and infrastructure teams hand work over a series of walls. Operations deploys the result and is blamed when it breaks, even if it had little involvement in what was built.

Jones criticizes heavyweight change-control practices as obstacles to rapid delivery. In his view, frequent small changes make failures easier to locate and reverse: if a deployment contains one change, there is less to investigate than in a giant release.

A product-centered organization instead puts people from the relevant disciplines on the same team. The shared question is what the customer receives, rather than whether each department has completed its own separate handoff.

Ask a customer to sketch what they think your organization does. They are unlikely to draw a team for an IP-address spreadsheet and separate Windows and Linux silos. Organizing around a customer outcome makes the structure easier to connect to actual value.

People may participate in more than one product team. To keep professional practices consistent across those teams, Jones describes guilds where developers, designers, or systems engineers compare standards and make compatible decisions.

At his company, principals move between teams, contribute work, spread useful practices, and help business leaders assess professional development and promotions. Different organizations can implement the same underlying idea in different ways.

Large organizations need leadership support because the change affects hiring, priorities, and human resources. But a company does not have to reorganize everything at once: start with one product, learn what works, and adjust the structure as you go.

When presenting the idea to management, explain the outcome and the organizational changes required rather than selling a buzzword. A decision not to fund it may be reasonable; individuals then have to decide what kind of workplace fits their own career.

Do not be only a hammer looking for nails. Learn enough to choose an appropriate tool for a problem. Different product teams may use different languages when those choices help them deliver their particular work.

For example, I might use Python for Linux automation because of its mature ecosystem, even though PowerShell is cross-platform. Learning another language takes effort, but I learned PowerShell too; I can learn something else when the task calls for it.

I think employers increasingly need people who can learn across the stack and adapt to changing requirements. You do not have to be the world expert in every tool; the valuable habit is learning enough, quickly, to make progress.

Jones argues that technology has become central to businesses far beyond the software industry. He contrasts established firms carrying older systems with small entrants that can build and release products rapidly, making adaptability and time to market important.

A video of a lone dancer shows a different kind of leadership. One person joins him, invites others, and soon a group forms. What looked strange when one person did it becomes easier to join as more people participate.

The lesson is the first follower. The leader may have the unusual idea, but the first follower shows others how to join. Jeffrey Snover once showed that video and called himself the dancer and me PowerShell’s first follower.

That role does not require being the foremost expert. Many people first encountered PowerShell through my books or classes, but I enjoy teaching the initial concepts so they can move on to more advanced teachers and eventually create things themselves.

People have told me that getting started changed their jobs or their families’ trajectories. My response is to help someone else. Look behind you occasionally and offer a hand; you know something another person has not learned yet.

Several years ago I started a Las Vegas magazine for hotel concierges: restaurants paid to include their menus in a consolidated, updated reference. The idea had promise, but the downturn arrived and restaurants cut spending.

When the venture was clearly going badly, we walked away without treating that as a moral failure. It is fine to invest time in a pilot, discover that the idea does not work, record the reason, and try something else.

Failure can teach you whether to iterate or stop. Share the context, not just the verdict that a product was bad: what were you trying to accomplish, what did you expect, and where did it fail? That lets another person decide which lessons apply.

Jones offers Windows PowerShell Workflow as an example of a good idea whose implementation, in his opinion, failed. The team could still learn from the experience rather than pretending the outcome was a success.

Star Trek fans can invent elaborate explanations for an inconsistency, such as a transporter with no sound, when the real answer may simply be a production error. Software also contains accidents that users later depend on, making them difficult to remove.

Jones recounts the PowerShell filter construct as a historical leftover: after a source-control rollback it remained in the product, and users came to depend on it. His larger point is that not every awkward feature has a grand design rationale.

At the end of the talk, I explain that I am stepping away from the DevOps Collective and moving toward business management and strategy. New authors are taking over the PowerShell in a Month of Lunches books, and a new team will continue the community’s conference work.