Leaning into Power Platform
I have a confession: I'm a SharePoint Developer, and I don't like Power Platform; I'd rather do it in PowerShell.
In my previous SharePoint engineering roles, I've enjoyed writing PowerShell code to solve automation problems and to manage infrastructure. I've even used PowerShell as a workflow engine. I just enjoy writing code more than I like designing a workflow process with a GUI interface (Power Automate Flow). At Bridgestone, that wasn't a problem because there was lots of automation that we could solve with PowerShell. We also had the infrastructure and tool acceptance as an IT department that empowered me to use PowerShell.
My new role is more of a pure developer role so we don't have access to some of the same infrastructure that I had access to at Bridgestone. Additionally, PowerShell as a tool just isn't as accepted, and the existing developers don't have any experience with it.
Not liking the main toolset used by SharePoint developers, developing on Office 365 strikes me as an odd place to be as a SharePoint developer who's developing on Office 365. Part of the problem, as I see it, is that I feel skilled with PowerShell. I can solve a problem with PowerShell way faster than I can solve a problem with Power Automate. People like to do what they're good at, so that makes sense.
So to try to change my mindset and to get better with the Power Platform toolset, I'm going to do a few things.
- I'm going to purposefully resist the urge to reach for PowerShell first when solving automation problems. Instead, I'll reach for Power Automate and do it with a Flow.
- I'm going to lean into getting better with Power Platform like I leaned into teaching myself HTML/CSS.
- I'm going to write about what I learn here on my site.
Okay, that's it for today. Thanks for reading! Wish me luck.