A problem with code schools

Software engineering, as a career path, has skyrocketed in popularity for many good reasons. And as demand has grown, so has supply - there are vast numbers of code schools and online courses, both free and paid, and traditional education providers are actively working to up their game.

At face-value, this is a good thing for aspiring devs - everywhere you look, there are opportunities to learn. But in reality, there are a lot of pitfalls worth avoiding.

This article is going to drill into one major problem that I have seen a lot and first-hand experience with.

Big business

The coding bootcamp market is huge. It's hard to say precisely how huge, reports vary, with estimates going as high as USD 1048.8 million in 2023.

And it's still growing.

Alternative tech education is a competitive space. A lot of different training products are being created by people with different backgrounds and motivations. And the quality of the education and teaching mechanisms are typically not held to any standard in the way that traditional education tends to be. This is not to say that traditional education is of a higher standard than all alt-ed, I am a great believer in alternative education, I am just saying there is typically a lack of standardization.

I can also speak from first-hand experience when I say that teaching people to code well is not straight-forward. Learning to code well is one thing, and imparting coding knowledge and skill is a whole other thing. Teaching code is a skill that needs to be honed, you don't get it for free.

Alt-ed providers need to figure out a lot in terms of how to teach and assess their learners. And then there is the question of what to teach, what technologies and techniques, and to what depth.

Some alt-ed providers have relationships with accreditation providers such as universities and government agencies so that they can offer some kind of trusted certification. This has the potential to be useful, but I have seen it turn into a box-ticking exercise that occasionally forces learners to do assignments based on outdated technologies. So that is a bit of a mess as well. This is not to say that all accreditation is bad, it's just not a silver bullet, and it's complicated to get it right.

So code schools are a bit all over the place by default.

An over-simplification

There is big money in this space, a great potential for changing people's lives, and many challenges around teaching the right things to the right level of detail. Given this, I'd classify code schools into 3 broad categories:

1. The good ones: These code schools are doing their best to ensure the long-term success of their learners by, at the very least, giving them solid, useful skills. These training providers don't only aspire to be good, they get it right (I work for one of these 😉 )
2. The aspirational ones: These training providers are on their way to being good - they have good values and want the best for their learners but are still figuring things out (If you are one of these, get in touch 🗨️ )
3. Those out to make a quick buck: There are bootcamps who craft their offers to make them easy to sell and cheap to run, sometimes to the detriment of their learners (I have dealt with some of these 😢)

These are very broad categories and definitely an oversimplification. There is nothing wrong with turning a profit if you are doing some good in the world.

The main thing here is that there are code schools that optimize for income at the expense of useful education. They get away with quite a lot because tech is pretty opaque and mysterious to the uninitiated and because people get fooled by vanity metrics.

Looking at some real courses

Here are descriptions of 2 web dev courses from different training providers. These are real offers from real training providers that are training people right now. Both of these courses are aimed at learners with little or no programming background.

Course 1 doesn't cover a lot compared to course 2. And it takes ages in comparison. It also covers professional skills like Agile and Kanban, and hard-to-sell-to-noobs things like testing.

Course 2 looks like cv-padding to me.

I've spoken before about why junior devs should focus on deep mastery of a few things rather than shallow familiarity of many things. TLDR: it is better to be useful at one thing rather than essentially useless at a great many things. It is better to demonstrate the ability to do something challenging and meaningful rather than the ability to do many unrelated basic projects. Breadth does have its uses, but it should not be the main thing a junior developer pursues.

To the untrained eye...

For aspiring devs or non-technical funders, course 2 might look better than course 1. People don't know what it takes to solve real problems with tech until they have spent some time in the trenches themselves. People are impatient. Course 2 is probably cheaper. And folks are swayed by pretty websites and marketing material. I can tell you that course 2 is quite popular.

Some of you reading this might look at the breadth of the knowledge promised in course 2 and think, "I could do that." Maybe you can, maybe you have enough experience and aptitude that you can get that expertise that quickly. I have been involved in training literally hundreds of developers from scratch and I can tell you that most would walk away with surface-level knowledge and, depending on how the course was taught, probably a few bad habits.

The code school I work for has tested quite a few people who got all the way through courses like course 2. People graduate these things without knowing what a return statement does, understanding for loops, knowing what an object is... They are able to talk the talk because that is what they have been trained to do, but they struggle with solving problems with code. If there was a tech-themed pub quiz they would smash it. And they might do well in a job interview.

I have only dealt with a limited number of these rushed-looking bootcamps and I'm hesitant to paint everyone with the same brush. But my experience has been 100% negative.

Why don't people catch on

There is potential for a lot of smoke and mirrors in this game. Tech is pretty opaque, especially to the uninitialized. If a would-be dev takes on course 2 and they get through it by showing up to all their classes, and getting a passing grade on all their projects and tests, then they will know some stuff.

When they enter the job market, their CVs will be full of keywords that recruiters look out for. They might even appear to be more experienced than they are because of the breadth of keywords. When these learners get into a job interview, they might talk the talk pretty well. They might have been trained to talk the talk - interview-hacking is a whole thing.

Interviewing is a whole thing as well - it does take a certain amount of skill and process to figure out if someone is good or not in a short amount of time. Hiring is risky, and firing has its own challenges.

If a grad from a keyword-packed bootcamp lands a job and feels out of their depth then that's ok because you can just tell them that they have imposter syndrome. "Imposter syndrome is completely normal in this field; I feel it too. You'll be ok".

There's definitely more to it than this; I'm still trying to figure it out. There are some code schools out there that are brilliant and some that seem obviously flawed in what and how they teach but still seem to have a good reputation.

The downsides of teaching for mastery

If you want to teach someone to code well then you need to know how to code well. But that isn't enough. Teaching a learner to properly appreciate things like loose-coupling, cohesion, and what a useful test is is hard. And of course there's a lot more to know than that. If you are teaching for mastery, then your syllabus needs to be top-notch, and you need to hire experienced developers and train them to teach well.

If, on the other hand, you are training a person to be familiar with many tools, then your teachers don't need to be as skilled. It's a much simpler task. Education staff are much more replaceable because you don't need to train them as much.

The other downside is that the focus is narrow when you train for mastery. This has a few effects:

Firstly, learners might not know the lay of the land very well. There will come a time when they need to make good decisions about what technologies to use for a project, and they might not be in a good place to do that well. That said, junior talent often doesn't need to make that kind of decision, and it is something that remains hella-tricky even for seniors.

In my experience, junior developers are often curious enough to go and find out about different technologies on their own. But it is also good to be intentional about exposing them to different ways of doing things.

Another issue is that if you focus on teaching learners a narrow band of skills, those had better be the right skills. It's important to make sure that the skills are industry-relevant. This isn't very hard to do if you pay attention to the job market. Something we do where I work is have conversations - we speak to a lot of technologists in industry to find out what skills they need, and we gather a lot of feedback from our grads.

Another issue is that CV-padding is quite popular - if a junior has a lot of keywords on their CV then they might, to the untrained eye, look better than someone who has mastered just a few things. They will definitely have a higher chance of being noticed by people recruiting for a broader array of jobs.

This one is hard to address.

A code school can address this to an extent by building a rock-solid reputation and by building relationships with companies that hire junior developers.

Junior developers can also do a few things to improve their chances of being noticed. The two main things I would recommend here are community involvement and building stuff:

If a junior wants a job at a specific company, it would be useful for them to look at what tech stack that company uses and spend time learning it by building real things with it. Learning programming languages is easy enough once you have one down. Once you have some context about how different technologies work and how data moves, then figuring out new tools and frameworks usually isn't a big deal. Of course, it's important to pick your battles here.

There is also that old adage, "It's who you know...". I highly recommend that junior devs show up to tech-community events. Go there to learn - wear your curiosity like a badge of honor. And add value where you can.