Something that I think gets 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 technically getting back a "String" object.
Okay, okay...technically, you're getting back an object array of "System.String" objects.
If you want to confirm that for yourself, pop open a PowerShell window and type the following commands to see what you get:
PS> $test = ipconfig PS> $test.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 name 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.
Maybe I'm getting ahead of myself here...
I'm not going to go into a lot of details 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.
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 be simply that you're dealing with different object types than you think you are. I can't count the times that I expected some value I got back 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 probably be doing that part anyway, most of the time) and executing it's 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 need 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 (PSCustomObjects; 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 searching 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 very specifically target which output and field I'm trying to identify; useful if I need the type for a particular property on an object, rather than the whole object).
Anyway, the short story is that 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 it from the C# side of the house makes the .NET objects PowerShell uses make a whole lot more sense.