Most of the bootcampers did three months of "frontend" work and are oblivious to what goes underneath in the murky world of business logic and services.
Until they have been able to demonstrate they are confident in:
* Presenting data to a user
* Validating inputs
* Making correct requests and understanding the interactions of an API (whether its REST, RPC, programmatic, internal)
* Processing requests
* Persistance and access of data
* Basic security
* Be able to document and explain all areas to a basic level.
* Debug and provide a root cause analysis.
Then they will remain a junior developer and I think that will be many of these bootcampers fate, as they are either unwilling or incapable of doing work outside their comfort zone.
This is a fair assessment - not just of boot camp developers but of all developers. I don't think I agree that it is a problem that some people working as a junior developer today will never become a Technical Fellow, however.
I've personally found (especially in the "enterprise") that many senior developers do not actually have fifteen years of experience - but one year of experience fifteen times, and are functionally junior developers with the wrong title. Educational background does not tend to be an indicator of this.
Few bootcamps seem to do a good job of teaching students what to expect in a career path or what they'll need to do to advance in it.
I think our industry is headed for a collective reckoning, though I would not begin to speculate on a timeline. We're going to have to square seniority as a measure of skill with seniority as a measure of time, and no matter how it happens a number of people are going to be unpleasantly surprised.
Yes, we all know someone who's done something for 2 years and is amazing, a true genius/savant who redefines what's possible. They're the exceptions.
I've been in professional software around 25 years, and was recently talking with a colleague (roughly same years of experience). He's just started a new job, and is working with people coming out of a bootcamp, and is frustrated because they're both currently being put on the same tasks - some basic FE JS work - and the bootcampers are actually slightly more productive than him. It's because that's literally all they know - they happen to know the same versions of everything the company is using, because it's what the bootcamp used. They can't do anything else, but both parties are being judged by this one ability right now, and he's questioning his own value now. It's giving the junior folks sort of a weird view of what 'old people' are capable of (which, as an old person, bothers me some!)
Isn't the point that they _are_ junior developers after completing a bootcamp? Juniors can be some of the best people in your organization if your org is willing to take them on and teach them things.
Not saying you need a full 4 year program and a CS degree. I don't have a CS degree, but 2 degrees in electrical engineering and computer engineering. That gave me a very solid and low level concept of computing that most CS grads dont get. Programming languages are a dime a dozen. Some are better suited for certain tasks than others.
Someone going to a Ruby on Rails or Node/JS boot camp isn't going to get that exposure to multuple languages. They're not going to know that, say Python is a better language/ecosystem than JavaScript for scientific analysis. They're not going to be exposed to C, C++, C#, Java, Rust or Go. Personally, I wouldnt even interview someone that's taken a boot camp in C or C++. The languages are too nuanced and complex to even get a foothold in 3 months.
Sorry this ended up very rantish, and I didn't mean for it to be so. I'm trying to make the point that while, yes, boot camps serve a purpose and may be useful to some folks, they will not and are not designed to give you enough knowledge to truly excel in the industry with the knowledge gleaned from the boot camp alone. It will take an extremely passionate and aggressive self learner to be more than a junior after a boot camp.
Over the past 20 years, this general principle has been validated, at least in my experience - a good boss I had once said only the top 10-15% of people in IT know what they're doing. The next 20-30% have some idea, but they're sort of useless. The bottom half, you do not hire if you can help it...
Very little of this applies to people on their second career doing bootcamps for a leg up.
There's also a massive disconnect from the reality of just how complicated modern software needs (not) to be.
That said I agree that some 3-month bootcamp probably isn't enough time to really internalize the basics of programming (unless you're really smart or have prior exposure), let alone learn to design and write nontrivial programs.
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 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.
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.
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.
A bit of the flavor: http://bit.ly/dbc_activerecord
It’s always sad to hear that the bootcamps that followed us didn’t try to give students the right mental models, but I believe you!
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".
Here's a thread I posted the other day, though, that might be interesting to you: https://twitter.com/jfarmer/status/1127324440469970944
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!"
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.
Programming is a profession. As you say, learning on the job is normal and expected.
--
Ah, bullshit. No you don't. Most people only understand a small subset of what they use. They are junior devs.
I went to a coding camp. I sat in a group working with my classmates on our group project and I noted that what we were learning was "just enough so that we can learn reasonably well on our own.... so that maybe later we will be good at this".
They looked horrified...
Most boot camp students really do not know at all the level of complexity involved, how much you need to just go figure out yourself / learn about ... learning, and etc.
Yes I’m aware of the differences in capability and no I’m not complaining. I’m just saying it was easier back then.
Many of the comments here have focused around the skills and personality traits of coders. I agree with most: problem solving, some level of aptitude and curiosity are all important parts of the basic mix for success. Most of the discussion around motivation either has circled around economic benefits or some self-driven desire to learn.
Again, while not invalid motivators - I think a BIG one that's not been discussed is the general allure to the raw transformational power enabled by software (automation). With only a few lines of code, disruption can be created to make things easier, make things faster, make things safer, make things better - with immediacy and impact. In my case, I used it to disrupt inefficiencies and accelerate solving problems. As a factory process engineer, that kinda power was way too intoxicating to look away from. But manufacturing wasn't quite ready to embrace software quite yet - so I made the career jump. For me, I wish coding camps or other channels would have been accessible in small remote towns in the Midwestern part of the U.S. back then, it would have accelerated my confidence and given me a channel to seek a career. Instead the luck of the dotcom boom opened doors in job fairs where I had plenty to offer in the technical realm but little to show in terms of code at the time. Nevertheless, 15+ years and going in software has been a great ride thus far and one that I couldn't have predicted.
[1] https://medium.com/@boilerupnc/ten-lines-9a8403984bbf?source...