Recently a project came up at my office which required me to learn some of the basics of PowerShell. And now it is my favorite new technology.

Here’s why…

• Widely available – I am very conservative about adopting new technologies. For something as potentially immersive as PowerShell, I want to know that once I write scripts I will be able to use them wherever I go. Microsoft is full-on invested in PowerShell nowadays – all the new server products use it as the management shell. So chances are your operations staff are already using it and will be happy to let you help them write scripts (and run your own in the production environment).
• Piping of command output – Un*x based shells have always been famous for their piping features. Commands can be endless linked together to essentially build small programs out of tiny utilities in a single line of script. PowerShell takes that to the next (wonderful) level. In PowerShell any command can be piped to the next one, but you are no longer dealing with plain text – now you can pipe output as .NET objects, which gives you much greater control over who gets what and when.
• .NET integration – Since PowerShell is built on top of .NET and is truly .NET-focused, you can use it to script any .NET object you have ever used or created. That means all of your C# experience instantly makes you a mid-level PowerShell developer. And it even means that you can use PowerShell to play with and test your objects before writing them into a C# program. It’s kind of a casual place to write the first draft of your C# code, and in some cases you might find that there is no need to write C# at all since PowerShell solved your problem!
• Ad-hoc reporting – Most of my programming nowadays is based on ad-hoc reporting or moving data between various SQL databases, file systems, and Active Directory. Sometimes the best way to prototype that kind of programming is to do some exploratory work, and PowerShell gives you a whole boat-load of useful commands (they are called “cmdlets”) to do this type of work, including nice commands to prettify the output. Again, you might find that you solve your problem without ever firing up Visual Studio to compile C#.
• Shell profile customization – Windows has always given us some minor ways to customize the shell, but Un*x based shells have always far outpaced Windows in this area. I would say that gap is closed now. In PowerShell, you can easily add script to perform any initialization you want to setup your shell.  And you can even write a set of custom functions for common tasks so that those functions are always available to your shell.
• Consistent, clean, and modern API – The .NET API is great, but there are so many gaps in it (quickly being filled) and so many inconsistencies in the way various API groups are used that you can spend a lot of time reading documentation and examples. With PowerShell, Microsoft was able to build the entire API from scratch and the result has so much consistency (and useful libraries) that it makes it easy to complete a complex task quickly. The language’s dynamic typing makes it even easier to pass data between commands and not get snagged-up by learning too much syntax or having to look-up every parameter list. In many cases, the most natural thing you think to type turns out to be the default.
• Fun like Perl – Like Perl, PowerShell has this cool ability to impress friends and family by showing the neato one-line script you wrote which re-imaged 1000 computers, setup their profiles, created user accounts, and then downloaded all the software needed for the new profiles. I am exaggerating, but not much. Mostly, that is just a novelty, but it can be useful when exploring data or a new API. And anything that keeps your programming fun is also a good thing.

Personally, I think spending a week with PowerShell will make any C# programmer into a better programmer, and will make any system administrator into a better administrator. The learning curve is steep for systems guys, but if you can get a more advanced scripter or a programmer to help you get past a few of the fundamental concepts you should be able to progress pretty quickly. Enjoy!

I just can’t get my head into it again.

That’s what I call a “debugging valley” – a great vast empty space (this is not like one of those nice valleys you might see in Vermont) where I’m stuck and just don’t feel like climbing any of the many paths that I could take to get out.

My best advice for myself? Just keep writing – the same way you get past writer’s block in fiction, essay, or any type of prose. Just keep going – tweaking, editing, revising, writing some new stuff – until your “voice” comes back to you. And then finish the darned project!

In the end, I would say it didn’t help me nearly as much as actually writing software did. In retrospect, I was reading the wrong stuff. I was getting a lot of specific advice from a lot of experts, but without enough context to make good decisions.

One area in particular where I was misguided had to do with best practices, coding style, and architecture related to software libraries. I would be writing a simple application and get very bogged down in designing it the way one was expected to design a reusable software component or library. I tried to make everything reusable and well-documented, even though the truth is, I was mostly writing one-off applications and prototypes and there was no benefit to trying to follow a lot of the recommended design principles.

My advice to my junior self? You are either writing an application or a software library. Figure out which one, and do it.

That’s because I am a “serial blogger” – I kind of change on a whim what the point of my blogging effort is pretty frequently. For the most part, my generalized and personal blogging is over at Working Sandbox. But I really want to have an active blog here also on WordPress.com, because I think it is important to be an active user of the WordPress.com-hosted service, just to round-out my WordPress experience.

So I am planning (fingers crossed!) to write a blog here about my experience as a software developer… something like that. In the future, that might change.