Start asking me about B-tree algorithms and my eyes will glaze over.
However you can go and look inside my MySQL database tables and you will see a beautiful relational database. I enjoy computers/programming because going back as far as I can remember I have never run across a problem that I could not figure out with enough gray matter time. I really enjoy making stuff and solving problems, I used to do all of my math homework in my head and then have to go back and write out the solutions (for the teacher to check) just because I enjoyed solving the problem step by step.
Not that I don't believe you, but I'm genuinely curious.
When you're designing a "beautiful relational database" without thinking about the algorithms behind it, how are you taking the performance effects of those algorithms into account? How do you know which relationships and queries are likely to be efficient and which are not?
Parent is talking about beautiful schema, not a beautiful query planner. If you are capable of understanding the concept of abstraction and encapsulation, you can design a good system knowing the performance characteristics of your components but not their internals.
The geniuses who wrote postgres don't know how to write responsive web sites. The geniuses who make gorgeous fast websites don't know how a Btree is implemented. It's OK. That's how the global economy works.
But the fast-website people still need to know what makes a query slow and how to improve it. They don't (and shouldn't) write their own database engine, but they need to know how their equipment works.
What I was trying to get across is that knowing the correct term for something and actually knowing how to do it are two different things. I run across stuff all the time in CS where I'm like huh? what's that? then I google it and find out "oh so that's what you call the way that I did "X" in "Y" application.
TLDR: I build stuff, it works and I smile.