PowerShell ideas / Thinking in PowerShell and remembering techniques.

I just wanted to pop in and say hello, also i am in a bit of a pickle. When i write scripts, follow along with tutorials, books or whatever i am able to ‘think’ and type and really get into it. But when i close the book or the script/module is finished, i forget alot of stuff… What are you guys doing to remember how things are connected, how this command is hooked up with that command, building like awesome bindings for your functions etc.? What gets you motivated and what drives you and become productive without having to read up a whole bunch before you go to work on something? I need a more clear mindset on how things in PowerShell works so i can do make scripts from the back of my head.
Happy Newyear and hope someone reply to this who might have been through the same.

The biggest thing to remember are the following commands:




outside that, expose yourself to it everyday. I would strongly recommend taking a look at the PSKoans module on the PowerShell gallery. That is a really good module for keeping yourself actively learning every day.

Homework, homework, homework.

Participate in as many forums as you can. Meaning, that regardless of your day to day role, there are always questions on these forums, that you’d probably never encounter. Work those questions or ideas, even if you never have any plan to post back an answer. Then work them more to make them as elegant and concise as possible.

Read the source code on the MS PowerShell GitHub. Read the source and help files already on your systems.

C:\Program Files\WindowsPowerShell\Modules C:\Windows\System32\WindowsPowerShell\v1.0\Modules C:\Windows\System32\WindowsPowerShell\v1.0\en-US

Read, read, read, and not just PS centric guides, books, but solutions that require PS use. I.E., Exchange, SharePoint, Skype, O365, Azure, AWS, Hyper-, VMWare, etc. Start messing with API and PS. Start messing with GUI development with PS and C# (PS is really a gateway drug to C# —

Participate in PowerShell User Groups. If you don’t have any physically near you, many allow participation via the web. I live in the Pacific NW, but regularly participate in groups in other states.

Give back to your community. Teach sessions at you local boys/girls clubs, ymca/ywca, veterans center and the like.

Master discovery of information on system and the web. Start looking at other aspects of the language. PSEditorServices, Pester, DevOps, web scraping, Security/Risk Management (White/Black/Gray hat scenarios)etc. Graph out your scripts using UML tool or the like.

For example


For example for discovery on my local system I have a fairly large snippet I pulled together as my primary information discover tool… sample below… I have stuff to look at source code of cmdlet / functions / DLL as well, but that’s a lot and I won’t pollute this site by posting all of that here:

# Get parameters, examples, full and Online help for a cmdlet or function

# Get a list of all functions
Get-Command -CommandType Function | 
Out-GridView -PassThru -Title 'Available functions'

# Get a list of all commandlets
Get-Command -CommandType Cmdlet | 
Out-GridView -PassThru -Title 'Available cmdlets'

# Get a list of all functions for the specified name
Get-Command -Name '*ADGroup*' -CommandType Function | 
Out-GridView -PassThru -Title 'Available named functions'

# Get a list of all commandlets for the specified name
Get-Command -Name '*ADGroup**'  -CommandType Cmdlet | 
Out-GridView -PassThru -Title 'Available named cmdlet'

# get function / cmdlet details
(Get-Command -Name Get-ADUser).Parameters
Get-help -Name Get-ADUser -Examples
Get-help -Name Get-ADUser -Full
Get-help -Name Get-ADUser -Online

# Get parameter that accepts pipeline input
Get-Help Get-ADUser -Parameter * | 
Where-Object {$_.pipelineInput -match 'true'} | 
Select * 

# List of all parameters that a given cmdlet supports along with a short description:
Get-Help dir -para * | 
Format-Table Name, { $_.Description[0].Text } -wrap

# Get Powershell Version info per cmdlet / function
# Errors displayed can be ignored
$TargetCmdlets = (Get-Command).Name -match 'process'
$CmdletSupportedPowerShellVersion = ForEach($Command in $TargetCmdlets) 
    (Get-Module (Get-Command -Name $Command).Module) | 
    Select-Object -Property ModuleType,Name,PowerShellVersion,
    @{Name = 'CmdletName_FinctionName';Expression = {$Command}}
$CmdletSupportedPowerShellVersion | 
Select-Object -Property ModuleType,Name,CmdletName_FinctionName,PowerShellVersion | 
Sort-Object -Property Name,PowerShellVersion | 
Out-GridView -PassThru -Title 'Show list of supported PowerShel version for modules/cmdlet/functions'

Get-Help about_*
Get-Help about_Functions

# Find all cmdlets / functions with a target parameter
Get-Command -CommandType Function | 
Where-Object { $_.parameters.keys -match 'credential'} | 
Out-GridView -PassThru -Title 'Available functions which has a specific parameter'

Get-Command -CommandType Cmdlet | 
Where-Object { $_.parameters.keys -match 'credential'} | 
Out-GridView -PassThru -Title 'Results for cmdlets which has a specific parameter'

# Get named aliases 
Get-Alias | 
Out-GridView -PassThru -Title 'Available aliases'

# Get cmdlet / function parameter aliases
(Get-Command Get-ADUser).Parameters.Values | 
where aliases | 
select Name, Aliases | Out-GridView -PassThru -Title 'Alias results for a given cmdlet or function.'

Document the important stuff, and the hard to remember stuff.

When writing functions, always include comment-based help. Especially if they’re less-often used or are internal to some module and you don’t need to mess with them often.

The things you’ll have trouble remembering aren’t the ones that you use all the time; document first the ones you don’t need to use directly that often but are no less critically important.

Beyond that, I lean heavily on Google, bookmarking various articles, keeping mental pegs in good blogs to come back to when I’m stuck (Kevin Marquette’s PowerShell Explained blog is a damn good one to revisit once in a while, doubly so to review for specific info you need.)

I also try to keep track of my thoughts in a blog post of my own when I put something together I haven’t seen elsewhere.

Finally, a lot of what I’ve learned is documented as code in PSKoans: GitHub - vexx32/PSKoans: A simple, fun, and interactive way to learn the PowerShell language through Pester unit testing.

As someone who is also trying to permanently embed knowledge related to Powershell, I just wanted to say thanks to Bill Kindle for mentioning PSKoans and Joel for writing this module!

I’ve had a quick look this morning and it looks a great way to help embed the knowledge…just by doing a little each day.

Cheers, and good luck Sigurd

I think the adage “If you don’t use it, you lose it” is relevant here. Since I starting taking every opportunity to use PowerShell daily my knowledge, memory retention, and skillset has improved immensely…

How long have you been developing PowerShell? I have spent the last two years learning and I’m still learning. During that time I have read books, watched youtube videos on PowerShell topics, joined this forum, read up on PowerShell blogs, and joined a user group. Don’t expect to retain everything you just read and practiced while the book was open. What I did on topics that I did not fully grasp was to find other articles about the same topic. Reading another authors perspective and technique can help as well. You can also save snippets of code in your editor (nothing wrong with that). VS Code is highly recommended for PS development and there are many PowerShell geared articles on configuring and using VS Code.

The motivation for me is a passion for automation and when I see a script perform a complex task that would take several man hours in just a moment, that motivates me even more. I also try to find reasons to automate a task for myself and others and work towards it.

Also, you may want to look into going to PowerShell Summit this year.

What helped me the most was stopping to use RDP sessions and doing everything in PSSession.
The next natural step was to stop all kind of clicks on my local station by automation them.
At the beginning it takes a lot of time, but I call this investment.

Two things that could be helpful, from my experience:

  • Maintain a good documentation for your colleagues and for yourself. Make sure to create a ‘Readme’ file for each script that explains in plain English what that script does (expected input, expected output, dependencies, …). If you forget something, you can always start by reading that file before looking at the code. This will also allow to avoid the problem of too many comments in your script itself (comments are good, too many of them may be hard to read).

  • I have started to build an habit of “one Git commit a day” every workday. If I create a new script, then things are easy. If I don’t have something new to work on, this forces me to look at some of my previous scripts and check for something to fix or to improve (and so far I’m always finding something). So you always have some PowerShell code to review, and this makes the memorization process easier.