no, i'm entirely unstructured about my learning.  i'm a complete mess with this stuff.  please, please don't base anything on my methods, because i'm pretty clueless.  i could be more disciplined, but i wouldn't like it very much, and i still wouldn't be a math wiz.

on the nodes.... i think you're thinking backwards.  he doesn't need to know anything about nodes for Math and Color Math.  Color Math > Power is a specific mathematical transformation.  forget about Pow for now and just look at Add.    Add is just that.  Subtract is just that.   the top input is the first in the equation and the bottom is the second.  with Add that doesn't matter, because a + b = b + a, but with Subtract and other functions, it does.

so let's take your example about bump and displacement maps.  how would you know that solution?  first, identify the problem:  people make maps where mid grey, or 128, 128, 128 (to the color picker) , or 0.5, 0.5, 0.5 (to the Poser material room nodes) is supposed to be 0 or no change.  well, how do you get 0.5 to be zero?  you subtract 0.5 from it.  obvious, right?  and you don't need to know anything about the material room other than the fact that you have a node that subtracts.

you don't need to understand the nodes first.  before that, you need to think about the colors as numbers.  then certain solutions become obvious.  after that, you might want to understand the stuff that's less straightforward, but to use them as bagginsbill does, you need to think about how they mathematically transform what goes into them.  personally, i can't go that far, but i can sort of tweak things.

bagginsbill learns all these complex mathematical functions for how materials work in the real world, then chains the functions the material room provides together to mimic them.    some nodes do make complex transformations (like the skin node), but often those don't work properly. 

ok, i'll reveal some of my idiocy.  so one of the things i changed in PR2 was how i generated the SSS map.  iirc, bagginsbill generated it with a straight comp node to pull out the red component of a texture.  in my own previous experiments, i had treated it differently.  i approached it this way.

i have a texture.  what do i want to know?  how much red there is in it relative to everything else. because the red can get bright due to everything being bright, and that's not what i want.  i want the percentage of red.   how do i get percentage?  by dividing.  so i need the red divided by the total.  i probably dealt with the total in the stupidest way possible ( i realize as i write this), but the point is that i plugged the red comp node into a divide math node.