One tension that sometimes arises in the PowerShell community is between the hard-core developers, and hair-on-fire administrators. As a broad technology, this tension and desire for balance drives our design decisions every day.

PowerShell is all about striking a balance between a range of experiences:

• Task oriented, and consumption-only. AKA “Copy and Paste Admin.”
• How do I use PowerShell to restart a computer?
• Problem oriented, and composition-based. AKA “Admin Scripter.”
• How do I collect a log file from a cluster of machines I need to parse out of a web page?
• Technology oriented, and interoperability-focused. AKA “Developer” / ISV
• How do I expose my product’s transacted object model to PowerShell users?

In general, the output of each category empowers the categories that come before it. As a product becomes PowerShell-enabled, admin scripters can then leverage the cmdlets and providers to solve their problems and scenarios. They might blog them, wrap them in a script or module, or otherwise share them. At that point, they become pre-packaged tasks ready for copy and paste.

We tend to walk a fine line with this goal, but I’ve grouped our 100+ new V2 cmdlets into three buckets: Admin, Developer, and Both. Here is what the comparison looks like right now:

PS >gc newcommands.txt | group { $_.Substring(0,1) }
Count Name                      Group
----- ----                      -----
   75 a                         {a Add-BitsFile, a Add-Module, a Checkpoint
   11 d                         {d Add-Type, d Debug-Process, d Export-Prox
   16 b                         {b Complete-PSTransaction, b ConvertFrom-St

Granted, we’ve spilled more blogging ink on the developer and scripting-oriented features (transactions, modules, eventing, etc,) but that’s largely because it will take some time for our SDK and help documentation to catch up.

In addition, PowerShell’s goal is always to soften the learning curve and blur the distinction between the buckets I mentioned earlier. For example, the scripts and functions you’ve come to know and love now have access to all of the power of compiled cmdlets. Or more simply, some scenarios that used to require .NET scripting (random numbers, split and join, etc) now have task-oriented cmdlets or language features.

Now, what about “constructive feedback?” Frequently, we’ll find a blog post or comment saying something along the lines of, “PowerShell just isn’t admin-friendly.” Or, “PowerShell just isn’t developer-friendly.” Of course, we’re always working to make the product better, but that comment is an ideal spot to help ensure we get this right. The best way to help us is to make your feedback constructive, and something we can act on. Tell us why you feel this way, and it has a chance of improving the product. Aimlessly grumble, and it does not.