Powershell adoption at the workplace, part II
Let me first reply to comments from the first post in the series
Chris -
I don't have a ready set link that I use to tell people about Powershell, so for sitting down with them and showing has been far more effective than telling. For instance, my friend Andy, despite cutting his teeth on Unix, Bash, Perl, and Tcl still hasn't installed powershell despite my not so subtle jabs that he's at risk of losing his geek mojo. But when you show it to them people get it pretty quickly. Yes, I have played around with PowerShellIDE and Powershell Analyzer, they're both promising tools.
Locrain -
The navigator is cool, thanks. I can't share the code, it belongs to my employer. But you don't want it anyway, the underlying data store has a habit of turning hardened architects into whimpering basket cases. But in any case, I suspect it's just a matter of time before a SQL Server navigator is developed and integrated into a project like the PowerShell Community Extensions
Adoption is uneven, everyone on the team uses the navigation provider to look into the proprietary database, it's just so much easier and more powerful than other methods. The two junior developers don't use powershell much beyond that and the build aliases, I think that's partially a matter of their responsibilities, and partially a matter of culture - they've never used the command line before. On the other hand, one of the senior developers, who has experience as an oracle DBA, is actively adopting powershell for ad-hoc and production scripting.
As for what Microsoft could do to help drive adoption, that's easy.
Create a new console host for powershell.
- The windows console is just awful, and everyone knows it.
- PowerShellIDE and Powershell Analyzer aren't sufficient - they are third party tools, and getting third party tools into large Financial Service companies can be very difficult. They also don't feel right as a console replacement.
- The powershell language and technology is just fantastic, it deserves, no needs, a default interactive environment that's worthy of it.
My dirty napkin design for a new powershell console would be built on top of WPF. It would keep the standard CLI paradigm in use for the last 30 years, and not separate the input area from the output area like powershellide does. It would take advantage of WPF to allow for different fonts of the input and output and help. Be copy and pasteable all over, output would have infinite scroll, zoom-ability, and possibly allow for XAML to be used in defining format specifications.
----------------------------------
And onto the next story of driving adoption...
This past Friday I was having a conversation with Bob, the primary business owner of our application. He's extremely technical and our conversation got onto the subject of report's and data cleanup in the proprietary database. I hadn't told him about powershell or the navigation provider, for a couple of reasons, but mostly I wasn't sure that he would be interested. But this particular conversation basically demanded that I show it to him. I went through the basics. ls, select, where, group, gm. He loved it. So I started talking about some general powershell commands, showed how get-command ps explained that ps was just an alias for get-process.
Me: go on, type in ps
Bob: oh wow, so this shows all the tasks, just like task manager?
Me: Yep.
Bob: [pause] can this list files,.. and who owns them?
Me: I show him ls on the filesystem and get-acl
Bob: I've been looking for something like this for years!