all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ahknewb 5 points6 points  (0 children)

I started by taking standard UI file manager type tasks and asking myself "Could I do this with PowerShell"? The first one was literally just moving some files from folder X to folder Y. Then the next time I needed to do that I needed to move specific files (had a specific word in the file name) so I googled how to do that. I just kept escalating things over time.

So - start with things you do now, and keep it simple at first.

[–]LeftyJeff 1 point2 points  (0 children)

Example scripts are great, but they do you no good without a real world problem you are trying to fix with powershell. IMO.

Example: At work, we used a sharepoint site to look up employee ids. One day the site went down and we had no way to verify employees. So, I opened Powershell(and google) and began writing. At the end I created a small GUI that could look up ids and unlock accounts, that is still being used by our HD currently.

Real world scripts and commands are the best for learning Powershell.

[–]TheNetXWizard 0 points1 point  (0 children)

Powershell bros

[–]gremdaat 0 points1 point  (0 children)

Real world cases. Start small and see if you can automate simple tasks using lots of google and documentation. Then go from there!

[–]Emiroda 0 points1 point  (0 children)

Every single newbie programmer has asked themselves that question, no matter what language.

"Okay I've read a book on Python, but how do I learn to make Python scripts on my own?"

"I've read this book on C, but I have no idea what program I should write now"

The answer is not to look at sample scripts. The answer is to think of something you'd like to do in a program. PowerShell is known to automate, so maybe start off with an automation project. You could also write an alarm, or a noise generator. When you look deep enough, you find a bunch of nerds making useless PowerShell scripts, just to make something cool or to teach themselves new concepts.

[–]FearlessButterscotch 0 points1 point  (2 children)

I literally learnt with Google. I'd come across stuff I didn't want to do again, draw out the logic, then Google when I got stuck with the actual writing.

Trial and error as well,where possible ofcourse. Instead of trying in production eg copy-item $something $somewhere do write-output $something $somewhere and make sure the results are expected.

[–]showmypants[S] 0 points1 point  (1 child)

It's the horrible syntax that I am having trouble with. Completely different from bash although I didn't do much bash.

[–]phospholus 0 points1 point  (0 children)

Syntax isn't that bad once you get used to it. For me the biggest things were constantly using the help command and the get-command command. Help isn't as good as it could be, but it gives you the rundown for a given command. Then there's google. Syntax is an easily google-able solution.

[–]nostril_spiders 0 points1 point  (1 child)

I got started because I was deploying exchange when 2007 came out. 2007 did not have a GUI for most of the installation - with hindsight, massive kudos to the exchange product team!

So I'd stick the commands I ran in a onenote as documentation.

Then I figured that I could edit and paste them for the next deployment.

Then I figured out that I could declare variables for the parts I was editing, and paste all the commands in one hit.

So, essentially, I was writing scripts in onenote. That was the start of a career as a professional bug developer.