What they don't teach you in bootcamps
Bootcamps have gotten remarkably good at their stated goal: getting someone from zero to employable in a short amount of time. This is genuinely useful. The critique is not that they have failed; it is about what they have optimized for.
They optimize for output. And there is an enormous amount they do not cover, not because they are lazy, but because it does not fit inside the format.
The things that are missing
How to read code you did not write. Most bootcamp projects are greenfield. You build something from scratch. The real job involves inheriting a codebase with decisions made years ago by people who are no longer there. Learning to orient inside an unfamiliar system -- to build a mental model of something you did not design -- is a skill that takes years and receives almost no structured attention.
How computers actually work. Not at the level of logic gates, but at the level that matters for writing fast, correct software: how memory is laid out, what the CPU is doing with your code, why cache misses are expensive, what the operating system is doing on your behalf. Brendan Gregg has written an entire book on systems performance that many working engineers have never touched. Ulrich Drepper's essay on memory alone would change how most people write loops.
How to think about failure. Production systems fail in ways that are nothing like the programs you build to learn. They fail under load, at 3 AM, in ways that leave ambiguous evidence. Learning to reason about failure -- to form hypotheses, test them quickly, and narrow the problem space -- is something almost no structured program teaches explicitly.
How long expertise actually takes. Peter Norvig's "Teach Yourself Programming in Ten Years" makes this argument clearly. Bootcamps cannot fix this, but they rarely even acknowledge it. The implicit message is that completing the program gets you there. It gets you to the start.
How to sit with problems. The bootcamp environment is high-feedback and fast-paced. Solutions are expected quickly. The problems are sized to produce results in hours. Real software problems sometimes require days of slow thinking, research, and iteration. The tolerance for that process, the ability to stay engaged with something hard that is not producing visible progress -- this is almost never developed.
The deeper issue
The format of a bootcamp -- condensed, structured, outcome-optimized -- is fundamentally in tension with how expertise actually develops. Deep understanding is slow. It requires repetition over months and years, not weeks. It requires doing things without knowing why, failing, and gradually building intuition through accumulated experience.
This is not a problem you can solve with a better curriculum. It is a structural constraint.
The engineers who come out of bootcamps and build genuinely deep expertise are the ones who understand this and treat the bootcamp as the beginning of a longer process, not the end of one. They keep reading. They take on work that is outside their current ability. They ask why, not just how. They are comfortable not knowing yet.
What to do with this
If you went through a bootcamp: the program gave you a start. The next phase is longer and less structured. You are building something that does not have a graduation date.
The material that builds real understanding is mostly not interactive. It is dense essays, slow books, primary sources. It is reading Parnas on module decomposition and Naur on programming as theory building and asking yourself whether the systems you build reflect any of it.
It is being willing to invest time in things that will not pay off next sprint. That is a different habit than bootcamps build. It is the more important one.