Well, if the bootcamp is going to spend 3 months teaching you how to make a website using the industry-standard tools and frameworks, you're going to know absolutely shit at the end.
Consider a typical front-end developer setup - with IDE/smart editor, linters, transpilers, packers, package managers, project generators. These are all useful tools, but to be even a marginally competent developers, you have to know what they do and why. Otherwise, you'll be completely lost when some default changes. You'll be flabbergasted when you discover that the project structure you're used to isn't "how the web is made", but just an opinionated pattern that was sort-of fashionable at the time you were learning.
I've seen this problem happen with code camps teaching people RoR some years ago; I believe it now happens with Node/React.
I encountered a particularly egregious example of this recently.
I was running a group of recent(-ish) hires through a training course recently. Part of it is penetrating-testing a dockerized application on their machines. One of the things the application is vulnerable to is various forms of form tampering attacks.
One of my students just stared helplessly at this. They were absolutely stuck. I had no idea why. I came to find out that one of my students had managed to make it through a bootcamp, and an interview process, and be on the job for several months all without learning a Chrome or Firefox developer console could be used to edit a page's HTML. Or that a page could be saved and edited that way.
I hadn't even considered the possibility that a professional engineer in a web development role might be ignorant of how to edit an HTML form by hand. It implies a shocking ignorance of how the whole thing works.
I once observed a "become a web developer quick" RoR-based course, where they made people write their "hello worlds" as full-blown RoR apps with full MVC project scaffolding - meaning dozens of folders, and having to create 3 files (M, V, C) and write a lot of code to put something simple on the screen. I realized then that people finishing this course lack what I consider one of the most fundamental insights in writing client-server web software. I wonder if the person from your story lacked it too.
The insight is this: a browser is a program that reads text that it gets from files or servers, and that text tells it what to put on the screen, how it looks and what can be done with it. When you're learning the basics of a (backend) programming language, you first learn how to put text on screen. The same way, you can put text into a file, or (with some more tricks) into a network connection. So if you write a program that prints HTML to stdout and make browser read from it, you get a client-server web page. Boom, that's pretty much all. Everything else you'll ever learn is just managing complexity. Modules, MVC, database connections, etc. - it's all serving the goal of generating the right text that gets shipped to browser.
I was surprised by the ways people (sometimes junior programmers with little web experience) didn't get that. Some didn't know that browser simply reads text (happens when you're exposed to frameworks instead of raw HTML). Others thought MVC is something fundamental to web apps, instead of just being a way to keep your "print HTML to stdout" code from very quickly getting out of hand. So whenever I teach something the basics of web development, I always start with this - raw HTML as text, the connection to "your program can print text to stdout, so it can print HTML to stdout too", and we build up from there.
I can’t vouch for other programs, but I co-founded Dev Bootcamp (the first programming bootcamp) and the sequence you outlined is almost verbatim how we brought students into Rails.
We’d explain it the way you described. We’d have them start with Sinatra apps after 3 weeks of modeling problems in CLI apps.
After their 10th hand-written form with error handling, they’d see the value of Rails form helpers immediately once they hit the last few weeks.
Similarly, they’d write lots of SQL queries by hand in their CLI apps. We’d push them to separate it behind method boundaries then class boundaries then build a mini-ORM.
When ActiveRecord came along it was no problem because they had a model of the problems it was invented to solve.
It's also good to hear that there are bootcamps who seem to do this right (and, importantly, want to do this right)! So thank you for doing it like this, and thank you for taking time to share it in a reply.
I read the whole excerpt you linked, and holy cows if you did not just significantly improve my base opinion about boot camps. The way you introduced AR is exactly the way I would do it, with the same digressions to hammer down things like "AR is ultimately just writing SQL for you", and "AR is ORM, there are many ORMs with different approaches", and "where does a concept live?", and "map is not the territory".
BTW, the evolution of your feelings is pretty normal and it brings back memories. Haha. People would always be like, "Uh, yeah, ok, so you're churning out code monkeys, right?"
Then we'd bring them in, show them what we were teaching and how we were teaching it, and they'd go "Oh man, I wish I had been taught like this!"
Having been in the situation, all I can say is that sometimes you have to expect "shocking" gaps when working with inexperienced people at not let it throw you. It's part of being a teacher. You have to remain positive. If they're quick to learn it when you teach it to them, it's fine. This is learning on the job and it's expected.
That happened to me at Google for someone who didn't come in as a software engineer. I didn't handle it well and it's one of the things I most regret.
In this particular case, my student was hired directly into a software engineering role from outside the company within the past few months. This, to my mind, suggests a whole sequence of failures starting with the contents of the bootcamp.
That's an important thing, I agree. Seen a few shocking gaps in my co-workers at previous jobs, and whenever time and energy allowed, I always tried to carefully (to not bruise egos) and positively[0] patch it with a quick mental model update. I don't fault people for being inexperienced, or for not growing up as a computer nerd like I did. I only start having issues if someone wasn't given knowledge they're supposed to by organized learning (hence my scepticism about bootcamps, but see jfarmer's comment in parrallel), or when they claim knowledge and competence they visibly lack.
Programming is a profession. As you say, learning on the job is normal and expected.
It's not about understanding everything thoroughly. It's about understanding, for most things they use, what does the thing do in general, what's the scope of it, and why that job needs to be done in the first place.
Consider a typical front-end developer setup - with IDE/smart editor, linters, transpilers, packers, package managers, project generators. These are all useful tools, but to be even a marginally competent developers, you have to know what they do and why. Otherwise, you'll be completely lost when some default changes. You'll be flabbergasted when you discover that the project structure you're used to isn't "how the web is made", but just an opinionated pattern that was sort-of fashionable at the time you were learning.
I've seen this problem happen with code camps teaching people RoR some years ago; I believe it now happens with Node/React.