here another example: I need to extract all views by view type (in this case “Enlarged Floor Plan”).
The node “Element Types” returns a Autodesk.Revit.DB.ViewFamilyType value, but I cannot find a node compatible with that data structure (System.Type), thus I am not sure how to extract all views belonging to a specific view type…
We don’t have the budget to have architects spend days figuring out these type of things, even because the task is objectively banal (this is not exactly rocket science: to extract a list of views?).
I’m afraid this is all part of the learning curve when learning anything. We all start of by knowing next to nothing and we build on it through experimentation, research and dedication. You yourself have proved this point by solving your own problem which in turn gave you a little more knowledge in how Dynamo is set up and also looks pretty good to me.
Generally speaking, any output type will probably need a node that is directly related to that type. For instance, let’s take this statement from your first post…
Your observation is that you have a surface and not a plane, but you have found a Plane.Normal node but only takes a Plane input… Not a Surface. In this case, the best thing to do is have a look through the Geometry>Surface category nodes in the library and find any nodes you can get a normal vector from… Within a few seconds you’ll see that there is a Surface.NormalAtParameter node. Now, how you interpret what this means depends on your understanding of geometry and what a parameter is (you may well know this or may not), and this is where you experiment. If you don’t understand what a parameter is in the context of geometry, this is where you research and the goal is to complete your script which requires dedication.
Trust me… This isn’t just an architect issue. This is the same in pretty much all the offices in all the disciplines in all the industries. In all honesty, I wouldn’t expect free time to play, it’s not going to happen. If you really want to learn then use your own time, get good enough and then prove that any free time you are given will be beneficial. This is what I did many years back and now I mostly do R&D (which is all the free time! )
Also, we on the forum are here to help and are happy to answer your questions should you get stuck.
I’ll second what @Daniel_Woodcock1 noted, but building on it to say that it’s not a Dynamo thing either. Any programming aspect in any field (even outside of AEC) will require a lot of time digging into the ‘how to.’ The fact that we have Dynamo only makes it more accessible to end users with no coding experience.
Of course there is still a lot to learn. Nearly of the ‘big parts’ of that are best covered early on when users are getting started, but many beginners skip the basics as they are driven by a combination of an eagerness a need to meet a deadline. Two months later they are stuck trying to find the error in a graph that now looks like a plate of spaghetti and index cards that were were tossed into a high speed fan.
Instead if it’s approach it like a part of the process evolution there is usually get better result. Remember none of the staff knew in advance where to click to build a footing the first time they used Revit, it took some time to learn. Dynamo won’t be any different, and if someone finds that it’s actually taking too long to build the graph then they can always do it by hand instead, or get only part of the graph done and do the rest by hand. They can always come back to the problem after the deadline (something I used to do often when I was getting started).
We all start of by knowing next to nothing and we build on it through experimentation, research and dedication. You yourself have proved this point by solving your own problem which in turn gave you a little more knowledge in how Dynamo is set up and also looks pretty good to me. 
)