I'm curious - is generic programming (GP) used much in industry?
It's really widely dependent on the context of the team and the project.
For example, in video games, often the code is the "simplest" possible (and even sometimes too simple) but in large architectures. That's because game developers have a lot of problems to fix and don't want to bother with meta programming (that is a separate very abstract and hard to grasp language inside C++).
At the same time, basic usage of templates are common even in those shops and you can see some template-based optimizations in some very specific functions of some engines.
But in game dev, most people will just avoid any metaprogramming.
Now, on the other extreme side, some really complex or heavy processing applications, that are not common, requires some kind of heavy metaprogramming because of performance and flexibility (at compile time) requirements that are not common. I'm working in one right now.
It's not common but it exists and some niche domains (in some scientific or number-crunching embedded contexts) does require people knowing a lot about metaprogramming or wishing to learn.
In the middle, most people will just use meta-proggramming as "client", not as "designer". Most meta-programming code are bundled in libraries because libraries are tools for code and what is better than a library that can adapt to the custom types you've been working with until now?
Boost (http://boost.org) is a set of libraries, some being made of heavy metaprogramming black magic, and are used in a lot of C++ shops as "STL++", an extension of the STL (and it is).
Not every shop does use it for several reason, like compiler compatibility (some boost libraries can make your compiler beg pardon for every time he did hurt your feeling...) and more often because some developers don't like not being able to understand how a tool works inside (try to understand Boost.Spirit...)
Whatever the companies you will work for, some will use this paradigm, some will less or not at all or even forbid them.
There is no consensus because nobody have the same needs, context or team.
But still, obviously, it is used. Maybe ask who use boost on their mailing list to have more real-world examples?
Short answer: no.
Long answer: There's no "simple way" because OOP is far from simple. Procedural programming is all about "variables" and "if then goto". Everything else is syntactic sugar, but those four things are all of what procedural programming is about. Once you get them nothing can stop you.
OOP is a way to organize variables and pieces of code. How many patterns are there to define OOP? 25? 30? Even teachers who learned OOP from different languages and backgrounds don't agree on its own definition, so ... how can it be simple?
I don't know how you came to that, but since your mother has a similar experience to mine, I can tell you how I came to that.
I was programming in C in a very large project. It was 1988. Many programmers organizing modules and libraries, with the difficulty of avoiding interference in other jobs and keeping a good segregation of duties.
We came to a "solution" that was to put all interrelated global data into structs, placing in those struct some function pointers where callbacks were required. We generalized in that way what we called io_mask (sort of textual mode dialog boxes) and graphic_manager etc. etc.
In 1996 It was very easy to discover that those structs were named "classes" and those function pointers replaced by member function and virtual functions, or with links to other objects (called behaviors) by other programmers who renewed that old project.
I started to understand OOP when I started to feel the need for it: segregation, polymorphism, and runtime defined behaviors.
Today I work with OOP, but I don't think of it as a doctrine to serve: just a "common idiom" (set of ...) that let us speak together without the need to provide long explanations and descriptions all the time. In fact, more a "convention" than anything else. After all, all OOP does is -again- "if then goto": it just does it "multilayered". Hence abstraction and idioms over idioms.
Ignore them. Until she doesn't feel the need for them don't even try to explain: she will feel them just as a complicated way to do simple things. And she is right... until what she does is -in fact- simple.
No one will think to "organize a desk" if there're just four things on top. It make sense when the things on top start to interfere each other. That's the time for OOP to come in.
You don't need OOP to work with C++. The entire C++ standard library is not designed in terms of OOP (although it can cooperate with it), and C++ is not Java.
In all my experience the worst C++ teachers and C++ programmers are the ones who come from Java, teaching all their prejudice about everything is not OOP, denaturating a language like C++ that is not (just) for OOP.
Let me suggest a good book for those who want to approach C++: Accelerated C++: it will bring you into C++ idioms without pretending to follow a predefined doctrine.
Best Answer
If you're programming in a purely object-oriented language such as Eiffel, Smalltalk, or Ruby then you're probably going to be forced to learn object-oriented programming from the get-go (as it's effectively the cornerstone of the language) (also note that these languages often have support for other types of programming, such as functional, etc.).
Now, having said that, both object-oriented and procedural programming are ultimately derived from the imperative paradigm, effectively describing how the program is meant to accomplish its task. As such, you still use certain procedural ideas in your program.
In languages that are hybrids (and not fully object-oriented), such as Java, you will still see a lot of object-oriented programming (as it's very relevant in the programming field today, also, Java is routinely used to teach object-oriented concepts).
Bottom line: you don't need to spend years (or even months) learning the procedural paradigm to be capable of understanding the object-oriented paradigm. You can start learning the object-oriented paradigm from the get-go (and you'll doubtlessly pick up certain procedural concepts as you go).