Views integration & Views Documentation: a serious problem

The last two days at work, I had to 'write some views plugins.'
Now, I am someone who prides herself on being able to figure out most code-related problems, provided a little bit of documentation & some source code. I have a reasonable amount of confidence.
The things that I can never do in Drupal are usually things like writing fields, making widgets, or things like 'doing views integration.' In the past I have tried, mangled a whole bunch of code together, and then wind up giving up because I traipse down a long chain of code and it goes nowhere and wastes so much time.
My experience with views was the worst I have ever had. Surprisingly, my problem isn't that views is object-oriented. Simpletest is object-oriented, but it is also very well documented and relatively easy to learn. I went from download to straightforward tutorial right away. A little review in the PHP manual of classes & OOP syntax helped too.
At Drupalcon I watched a lively argument between crell + merlinofchaos vs. chx. It was an object-oriented vs functional PHP debate. Chx was saying the functional PHP was better because it is easier for novices to understand. And I know too that Development Seed produces a lot of object-oriented code. The problem is not OOP. It might be that OOP is harder to document? Or it makes people build things that are more abstract...and drupal doesn't have a system to capture this knowledge?
I think the problem has to do with making mental models of what one is building. All my problems with Drupal development are in contributed modules/systems (all very powerful) - that have 'structures' with funny names. (like 'widget' 'plugin' 'handler' 'filter' 'field' 'chaos tools')
(Drush, by the way, seems to be doing pretty well balancing the awesome technical + outreach & education. Not sure if Drush is not as complex...)
The problem is that all of these parts are very real to the people who understand, and the hard part is sharing a mental model that makes sense.
Sometimes people use diagrams for this. Honestly, diagrams just confuse me more.
Personally, I learn from connecting pieces, and fiddling with components. Making things appear and disappear. It's slow, but it works and I wind up with a very solid understanding of what I am doing. Over time, it made it so I can read code and know what it will do. I like it, it works for me. And it works in the absence of knowing who to talk to & what questions to ask. Most Drupal people are self-taught, as I am.
Views has some documentation. Also, after using views for 2 years - I know very very well what everything does in the interface. The part about 'extending' views (how/why/to do what?) was a mystery. Even though I can write sql queries.
But VIEWS IS MISSING DOCUMENTATION ABOUT HOW TO GLUE THINGS TOGETHER (in code) for common desirable tasks.
Google searches were not helping, the Views doxygen documentation was not what I needed to get started. Nothing on the drupal.org website was helpful. Looking in the views/modules was semi helpful - I had to have views_handler_filters.inc open and do lots of guessing of which tools were the most useful to do the main things like 'connect all the parts' (connect the handler to the filter to the module to the theme to the whatever) - and then which functions were super useful (like for getting an exposed filter to display in the views UI)
I can honestly say, now that I have seen how it is done, I never, ever would have figured it out on my own.
No, what I needed was my co-worker Ronan Dowling. We had something we had to get done, and we sprinted together and he showed me how to put the view together. Thank you, Ronan.
The best analogy I can think of (for themers) is to imagine going from learning Drupal exists to jumping into the preprocessing hooks. Holy WTF.
I have seen some of Crell's presentations about Views 2 - which sort of helped - but what I learned today is that making views plugins & handlers isn't 'hard,' you just need someone to show you how.
It is:

pretty much a matter of copying & pasting & renaming the right things in the right places

knowing what you want to build

impossible to figure out on your own & it does not mean you are stupid if you can't figure it out

once you know how the parts connect, then you can play with the API & make some creative use of the toolset provided by views

The creators of views are definitely not the people who should do the documentation. They are probably the worst people to do that work, and there is really no reason to blame them. They did a great job building something powerful.
However, I really think that when there are Drupal tools that are as widely used & powerful as views, that the creators of these monsters need to reach out to Drupal users and convince us to document what they make. I really got the sense that they thought the argument was about OOP vs. functional PHP - I think the argument is about keeping Drupal's code open & inviting to use.
Doing things like saying 'hey, did you know that you can build plugins that do this, this and that' (things people do a lot when themeing) - or 'we are going to show you how easy it is to do this...)
But I know that these awesome programmers build tools that are sophisticated...but then, because they make no sense to outsiders, most of us feel like we can't even try to help because they must be so smart that we would never figure it out.
This kind of experience is only making me even more supportive of the idea that it is a million times better to build less but make your code better documented.
By documented, I mean - getting other people to try to use what you made, understanding if your code is 'usable' or 'makes sense' to others by asking them. Watching them. Seeing where people get stuck. Was the name you used for your variable really the best word? Sure, it made sense to you at the time...but all those flashes of light you had in your mind at 3am one night don't really help community software. The awesome ideas you had late at night ARE awesome and sure, everyone will think you are very smart. And you are giving a wonderful gift to the world. But your gift won't shine all it could if we all don't step up and try to document projects like Views. And I think the people who would be the best documentors are either people like me, or people like my co-worker, Ronan - people who have tried to make sense of views. I don't know the history of this issue, but after what I saw today I am just shocked. There must be something really wrong, but so many of us use views we should really do something about it. What...I do not know.
I guess the first place I would look would be to people who contributed views plugins...but seriously, up until today - as a total outsider I would have no idea how to even begin.
Once I digest what I experienced today, I might eventually be able to get creative with views plugins - which would eliminate the need for repetitive themeing (and yes, a themer could write a views style plugin for sure.) I would be able to work with data imported into the database from other tools. I could make views do other things. I'll be a rockstar later, but at the moment I am still in shock.