Something that I think causes problems for many people starting out with PowerShell, especially anyone for whom it's their first real programming language (and yes, it is very much a programming language), is that what you see on the screen is only a small piece of what's actually there.
You see, PowerShell is built on the object-based .NET Framework. Everything in PowerShell is an object. Specifically, a .NET object. Even if you run a DOS command like "ipconfig" in PowerShell, you're actually getting back a "String" object.
Okay, okay...technically, you're getting back an array of [System.String] objects.
If you want to confirm that for yourself, open a PowerShell window and type the following commands to see what you get:
PS> $test = ipconfig PS> $test[0].GetType().Name String
Okay, so after storing the results of "ipconfig" into the variable $test, I'm calling the GetType() method on the first item in the array to see what its type is, and then grabbing the Name property. Another useful property is FullName, which can be helpful for more complex objects when you need to pull up the MSDN documentation on them (as in the above example, [System.String]).
I'm getting ahead of myself here...
I'm not going to go into a lot of detail here about how objects behave in a .NET world, and you probably don't need to know how they work in great detail to be proficient with PowerShell, but at the very least you should know a few basics about how to peel back the surface and look inside.
Have you ever been working with your results from a command or series of commands and they don't behave the way you're expecting them to? It may simply be that you're dealing with different object types than you think you are. I can't count the times that I expected the results I got from a command to behave like a string only to find that it was something else entirely (usually after banging my head against a wall trying to figure out why something didn't work). Sometimes, just throwing the results into a variable (you should be doing that anyway, most of the time) and executing its GetType() method to see what you're working with can give you a great deal of clarity. Once you know what you're dealing with, it is often a lot easier to figure out what you need to do to get to where you’re trying to go, either by working with the object correctly or converting it to the type you need.
Also, about Methods: all .NET objects have them, even if you created the object yourself ([PSCustomObject]s; useful for setting up output) and never added any methods to it. At the very least, all objects have a few baked in basics such as GetType() and ToString(), which they inherited from the object class [System.Object] (the parent class of all objects; again, a subject beyond the scope of this post). If you want to see what methods an object has available to it, you can do one of two things: you can take the name you get from GetType().FullName and search MSDN for the full documentation on that object class (useful if you know how to read it), or pipe the object to Get-Member and look through the list of Methods. Incidentally, you can also get the object type name from Get-Member's output (it's the TypeName at the top of the output); I just find using GetType() more .NET-y and cleaner, since it puts out less output (and also lets me specifically target which field I'm trying to identify, which is useful if I need the type for a particular property on an object rather than the whole object).
Anyway, in short, everything in PowerShell is objects working with objects, and the whole thing is built on the .NET Framework, so understanding how these objects look and act is incredibly useful long term. If you want to dive deep into how this works and get a better understanding of interacting with PowerShell this way, I highly recommend spending some time learning a bit of C#. Even a mild understanding of C# makes the .NET objects PowerShell uses make a whole lot more sense.