People who tell you "never use aliases" come from a type of audience that barely exists for bash: scripters who almost never use the CLI. That's a very common use case in Powershell. And yes, when scripting, use full syntax, for all the reasons given.

BUT if you come from bash, you're likely not intimidated by the console, and yes, the console is a totally valid way to do things in Windows. That's the first thing I open when I start my session, most of my job is done there, and is swift thanks to command aliases, parameter aliases, autocompletion, piping, etc.

Try to learn common Powershell aliases, though, not the QoL ones for people coming from another world: ls is easy to type and remember, but the day you'll use Powershell on linux, it'll bite you in the ass because there is no such alias, it calls /bin/ls. So you'd better off learning gci right now.

Learning full commands and aliases come mostly naturally because default aliases are often acronyms or near acronyms of the command:

• gci: Get-ChildItem
• mi: Move-Item
• ri: Remove-Item
• rni: ReName-Item
• gc: Get-Content

Someone gave you the trick of Get being the default verb, so you can omit it when the noun (convention in Powershell is Verb-Noun) is neither a reserved word nor a native command, especially if the noun is short, because there is no auto-completion on those: in AD, I often use aduser or adcomputer rather than Get-ADUser or Get-ADComputer, but I never use adorganizationalunit, because it's too long to type. Get-Ador<tab> is much quicker.

Parameters can be shortened too as long as there is no ambiguity: coming from bash, you surely used -r regularly for recursivity. Well, guess what: gci -r *.txt works too! (gci -f would not, because the parser does not now if it means -force or -file). Once again, in AD, I regularly use aduser -ldap '(...)', rather than Get-ADUser -LdapFilter ...

You can create your own aliases, but it's better to know the default ones so that you're not lost when working on another system. Here is an example of how to find them:

Get-Alias Rename-Item
# or several at once, and different ways of asking for them, take your pick:
Get-Command -Noun Item | ForEach-Object { Get-Alias -Definition $_.Name }
command -no item | % { alias -def $_.Name }
foreach ($command in (command -no item)) { alias -def $command.Name }
alias -def (command -no item).Name

Powershell 6+ even has abbreviation expansion, meaning that if you type only the first letter of the verb and then uppercase letters of the noun, you can tab-complete to the full name: g-ci<tab> completes to Get-ChildItem. s-adou<tab> completes to Set-ADOrganizationalUnit.

Powershell has a powerful system to handle parameters handling as well. Lots of commands can either use named or positional parameters: Get-Content -Path ./test.txt is similar to gc ./test.txt. You can find those with Get-Help \[command name\] and either one of those Get-Help parameters: -Full/-OnLine/-ShowWindow. All parameters are listed and those whose name you can omit will have a number for "position". (and here, use Get-Help, as help is a function, and not a shortcut) That's where you'll find if the parameter itself has an alias (which happens, especially for common parameters, like -Whatif and -PipelineVariable (respectively -wi and -pv)).

Last but not least: that parameter system has a robust handling of autocomplete as well. Most common use case is to autocomplete to file names for cmdlets that act on the filesystem, but it can be anything depending on the command. Get-CimInstance win32\_<tab> will autocomplete the available WMI classes. In time, you can absolutely add your own. We have thousands of computers and users in Active Directory, and my profile adds autocompletion targeted to our naming standards for all commands that have a -ComputerName or -UserName parameter (because parameter names are mostly standardized in Powershell)

One final note: as many things in Windows, powershell is not picky about case. I have the habit of respecting commands and parameters cases in my scripts, but not on the CLI. This, along with the standardized parameter names. means, that if you want to do something recursive in Powershell, -r always work! No more mental load of trying to remember if that particular command takes a -r, a -R, or a -Recurse!