How to mentor bootcamp graduates
This post was inspired by "How Dev Bootcamps Are Failing Their Students" by Tyler Hawkins (and yeah, I started writing it 3 months ago, something something about unfinished projects).
Software development bootcamps have passed their hype stage and now they're somewhere around the trough of disillusionment and the plateau of productivity. New bootcamps keep opening, but it's harder to find people who believe the overpromising "become a professional developer in 10 weeks" slogans. As long as the demand for software developers grows though (and it almost certainly will when economy starts recovering), bootcamps are here to stay. We, lead developers and engineering managers, need to learn how to make the best of it.
The rise of the bootcamps
According to Wikipedia, the first programming bootcamps were created around 2011. While they were met with a solid dose of skepticism, it is impossible to ignore their impact on the software development industry. Yes, it has always been possible to become a programmer without a degree in CS, but let's be honest - it was a difficult path, that required a lot of discipline, determination and spare time. Suddenly coding bootcamps changed it - they promised to turn newbies into professionals within a few months or even weeks. Too good to be true? Certainly a little bit, but hey, for thousands of people it actually worked!
The success of bootcamps and the chance to join tech companies after a few weeks of training was possible due to 3 major trends happening at the same time:
- the rise of SaaS powered by faster internet, cheaper hosting, AJAX, and new easy-to-start frameworks like Django or Ruby on Rails
- grow of tech companies, including tons of new startups supported by VC money
- boost in process of digitalization across multiple industries
These 3 things led to a huge increase in demand for software developers. I'm not kidding here - when I attended some tech conferences in 2011, I heard "by the way, we're hiring" in every single presentation. Universities, which are traditionally the source of workforce in intellectual professions, could not keep up with this need - even if they suddenly doubled the number of new CS students, we would have to wait at least 3-4 years to see the effects.
So on one hand there were tons of companies that had enough resources to hire more developers, on the other there were people who were ready to switch careers, lured by a promise of quick training and high salaries. Boom! Welcome to a software bootcamp - a badly needed solution for the demand problem.
What's the goal of a bootcamp?
This context is important to understand why bootcamps' curriculums look the way they look. Bootcamps were never meant to replace a university degree. They're not "CS in a nutshell", I wouldn't be surprised if you could complete a bootcamp without hearing the term "computer science" at all.
The goal of the bootcamp is not to teach you CS or even to teach you software engineering. The primary goal of bootcamps (besides making money of course) is to help their clients to land their first job as a developer/designer/data scientist/whatever. This is the primary metric bootcamps use to show that they're a good investment, this is the primary selling point - you give us $$$ and put a lot of work for a couple of months, and we'll help you to land a job in a booming, well-paying industry.
This is a critical thing to remember - bootcamps optimize for job interviews, therefore their curriculums reflect the desired skills, the technologies that are in demand and the questions that are commonly asked during interviews (BTW this is how the tech companies can shape the curriculums of bootcamps - by changing the way we do interviews).
Fresh grads and shaping knowledge
Because of the very limited scope that's taught at bootcamps, we - team leaders and managers - need to adjust our ways of mentoring and coaching new employees to help them progress and become productive.
When we work with fresh university graduates, they posses some knowledge that's ready to be used, but more importantly, they have spent a few years studying different topics that can be useful in software development, so they have much more knowledge that can be "unlocked" over time. Bootcamp graduates naturally lack this knowledge, simply because they've never studied these subjects. They're more like "what you see is what you get" - in order to make progress they can't just access the information they have learned in the past, they need to get it first (to be fair they often have a lot of knowledge of other topics, especially if they have previously worked in other industries - part of this knowledge can be translated into faster improvement of programming skills).
I like to compare this to pottery and clay - university grads accumulated a lot of material over years to start turning into practical skills quite quickly, bootcamp grads need to get this material first, because the few weeks they spent studying is just not enough to get enough of it.
Finally we can get to the point where I can talk about some practice and how to help bootcamp graduates to progress quickly.
The first part of the process is to make sure that our new colleague is aware of the importance of CS fundamentals. They need to know how learning basics of data structures and programming paradigms makes it easier to learn other concepts. At the same same time they shouldn't be ashamed they don't know these things, we need to ensure them that gaps are expected and we're there to help. Often people realize that there are many things they do not know yet, but it's still worth to talk about it.
The second step is directing them to the right resources. While you can draw up a plan of what they should learn step by step, I believe what works better is to follow the natural flow - if your team member needs to do some database work, point them to the right book about SQL and to someone in the team who can help them if they get stuck. If they need to improve performance of some script, tell them about how to profile applications and how they can find better algorithms that can replace some brute force solutions. Don't try to force them to follow classic CS curriculum - knowing how operating systems work is great, but it's not the most urgent thing to learn.
Third part is the pace. A job in the new industry is a stressful thing. No matter how hard we try, our new team members will have doubts, will have moments when they want to quit and give up on programming. You might not see it, they might not say it aloud, but there's a high chance that they will struggle and will work hard every night to keep up with their colleagues. That's why the pace is important. Learn 1-2 new things at a time, don't try to understand everything at once, relax and get good sleep everyday, keep slower but consistent pace - we need to repeat these words to reassure the new employees that they're on the right track.
Finally, something that I shouldn't have to say, but that might be a problem in some environments - inclusivity. Our industry tends to be hostile towards people that do not match the image of a typical programmer, be it regarding their gender, age, but also their education - CS graduates might feel superior to other programmers and it is our job to ensure that everyone feels welcome in the team, that everyone feels valued. Except for assholes, assholes should not feel welcome.
Different paths to success
Coding bootcamps are here to stay, whether we like or not. With the current trends like growing demand for software developers, wider access to informal education, with universities struggling to deliver good quality of lectures while they are forced to teach remotely, we are going to see more and more people taking alternative ways to become programmers. I personally believe that it is great, I am excited about the democratization of this process. We've seen it with MOOCs, we see it with bootcamps, we'll see it with other ways. It is wonderful that the pool of talent is not limited by their ability to spend 3-5 years studying CS. As managers, as leaders, as experienced developers we should treat it as a challenge and opportunity, not a problem.
"For hire" photo by Clem Onojeghuo on Unsplash
Pottery photo by SwapnIl Dwivedi on Unsplash