your code doesn’t suck

Recently, I had a couple colleagues tell me that their PowerShell code sucks.

One of them is a beginner who manages a large SharePoint farm and the other is more advanced and wrote a few commands that saves me hours of work each week.

See the disconnect there? Their PowerShell code, which helps manage Enterprise platforms and saves hours of work a week, not only doesn’t suck, it’s actually awesome.

 

your ps is actually awesome

Their PowerShell is awesome because it works. Their PowerShell code is awesome because they’re using it. It’s also awesome because the time they invested in creating code that:

  • Will save people time in the future
  • Helped them practice a valuable skill set
  • Keeps them relevant
  • Will look fabulous on their resume

Nobody goes from being a beginner to an expert overnight, and it’s important to allow ourselves the time to learn.

my own story

I feel like I’ve got code that sucks, too. In particular, I’m tortured by one of the commands I used to be super proud of, Import-DbaCsvToSql. I die inside when people talk to me about it, but I leave it in dbatools because people love it. It’s useful and, enough of the time, it works 😉

I learned a ton when I was creating that command, and even did a presentation about it.

The adventure of creating that command (and Bruce Payette attending my session!) was so exciting, it prompted me to dive even deeper into PowerShell.

Yet I fight back against my impulse to remove Import-DbaCsvToSql from dbatools. I literally have to resist the urge, but I do it by reassuring myself that:

  • One day I’ll rewrite it
  • Until then, some people really find it useful

Import-DbaCsvToSql is embraced because it’s fast. But it’s fast because it has no error handling. No error handling can be okay if you’ve got some perfect input, but input is rarely perfect.

The command simply doesn’t work enough for me, yet at the same time it tries to do too much. It totally stresses me out.

And, y’all, I showed this code, along with Start-SqlMigration.ps1 to Lee Holmes of the PowerShell team, all proud. He was so kind in response. I didn’t follow best practices, but he didn’t chide me. He said I was doing great things, and should keep on writing code and continue to improve along the way.

it’s all about adoption

Ultimately, I believe that Lee cared most that PowerShell had an enthusiastic adopter, even if I still had a lot to learn.

And I now realize that adoption is what’s actually important. Adoption will lead to that extreme excitement that I feel when I execute something and announce to my coworkers that I’m chillin because PowerShell is doing all my heavy lifting. From there, I’ll use that momentum to make my code even better.

Then I’ll invite my coworkers over to see my improved code, and we’ll celebrate. Then they’ll invite me over to see their improved code, and we’ll celebrate.

And then we’ll all live happily ever after, with our awesome code.

Chrissy is a Cloud and Datacenter Management & Data Platform MVP who has worked in IT for over 20 years. She is the creator of the popular SQL PowerShell module dbatools, and holds a number of certifications, including those relating to SQL Server, Linux, SharePoint and network security. You can follow her on Twitter at @cl.

Posted in PowerShell
2 comments on “your code doesn’t suck
  1. Eric Singer says:

    Great article and so true!

    I look back at my old code and wonder WTH I was thinking, and I do that every couple of years.

Leave a Reply

Your email address will not be published. Required fields are marked *

*