A professor in college told us that we'd likely never use 90% of what we learned in our curriculum. He said engineering is largely an exercise in vocabulary: the core structures in CS are like "function" words (articles, prepositions, pronouns) in human language; they tie the other "meaty" words (nouns, adjectives) together. The nouns and adjectives are the specific technologies you use.
A CS degree teaches you the function words. A bootcamp teaches you a small set of meaty words with a sprinkling of function words. However, the meaty words are the most useful day-to-day. But you have to be able to discern and use new meaty words all the time, or you'll "sound" dated eventually. "Radical, dude! I'm stoked about these parachute pants!"
I've met many CS-degree-holding engineers who don't understand this vocabulary exercise. They choose a particular programming language they're most familiar with and proceed to reinvent the meaty words. They're doing it wrong, and will almost always be less productive and useful. Bogus!
If I'm going to build a machine learning system, I'm not going to open my editor and start writing parsing libraries and convex optimization algos in my favorite language. I'll find a well-supported framework and learn how to use it. If I need to learn the framework's language better, then I will.
Go for the meat first, and you'll be a great engineer.
While you'd be a very brave or silly individual to try to reimplement BLAS yourself, there is definitely value in knowing how to implement any library for yourself.
If programming is behaviour and data, then the deeper and broader your appreciation for data and behaviour in its many forms, the more tools you'll have in your toolkit.
Learning by doing is mainly the defacto way of learning for programming, and so while you may never use your own language to ship in production, there is still value in learning to build your own compiler.
When you use someone else's framework, you are using their abstractions and their mental model of the world. Lucky for you if it happens to be spot on with your own or aligns with your way of thinking. If the abstraction is too tight though, and the fundamental knowledge is not your own, then when "new-and-shiny" framework is outdated for "newer-and-shinier" framework, your framework-specific knowledge is completely redundant.
That's not even starting on confidence that comes with being able to roll up your sleeves and read anyone's code when you've earned enough chops by building various projects.
I often hear "You weren't a CS major?!?!". My common response is "You were?!?!".
I worked in finance as an equities trader for 6 years before taking a boot camp and switching over. I was heavily involved in hiring while in my prior role.
One thing I found is that I was drastically more inclined to hire the English major over the Finance major. If they've managed to overcome the commonplace cognitive biases that work against them, chances are they are more intelligent/hard-working than the relevant educational background.
None of this is meant as a slight to CS grads, I'm simply pointing out the somewhat irrelevant dependence on an undergraduate degree. Technical mindedness is much more important than a 4 year rubber stamp.
It seems you're guilty of the same cognitive biases. "Screw those finance guys! Rosencrantz and Guildenstern over Oskar Morgenstern!"
Edit: On my first job interview out of college I was turned down by the head of engineering because I didn't have enough experience in C++. "Silly college kid can't do shit." I was called back and offered a job because another manager was impressed by my work at the speech recognition lab at my school. Three months into my employment they filed a patent on an algorithm I devised to build databases that were searchable through speech interfaces. The engineering head ate crow.
Hiring developers is a crap shoot, but it's hard nowadays to hire a truly incompetent developer. I've really only encountered one in my lifetime who was incapable of basic development tasks.
In the 15 years I've been a working engineer (and 25 in general programming), I've noticed the level of knowledge and skill required to build usable products has been greatly reduced. Why? Because there's been 15 years of advancement by seasoned engineers, prompted by business people, to build tools and frameworks that fit large swaths of business needs.
That cycle is ever present in tech. The obscure things become clearer and more accessible to laymen through the efforts of the experts. And you can bet those experts have deeply studied CS topics, whether at a college or on their own.
A CS degree teaches you the function words. A bootcamp teaches you a small set of meaty words with a sprinkling of function words. However, the meaty words are the most useful day-to-day. But you have to be able to discern and use new meaty words all the time, or you'll "sound" dated eventually. "Radical, dude! I'm stoked about these parachute pants!"
I've met many CS-degree-holding engineers who don't understand this vocabulary exercise. They choose a particular programming language they're most familiar with and proceed to reinvent the meaty words. They're doing it wrong, and will almost always be less productive and useful. Bogus!
If I'm going to build a machine learning system, I'm not going to open my editor and start writing parsing libraries and convex optimization algos in my favorite language. I'll find a well-supported framework and learn how to use it. If I need to learn the framework's language better, then I will.
Go for the meat first, and you'll be a great engineer.