Scarcity and Hackbright - the Top 5%

There are some major parts of Hackbright that deal with scarcity. Our business model (and we are a business) is based on it, and our company philosophy (and we do have one, one that's very important to us) is based around it as well. First, let's talk business.

There aren't enough developers. Not in Silicon Valley, although you can't sit in a cafe without hearing about code or devops. Not in the rest of the world, either. There are nonprofits that need help, terrible industries that need to be automated away (I'm looking at you, medical billing), and information that needs spreading to the bottom billion, so that they can be informed, and more powerful. This kind of thing sounds great, but in order for any of those jobs to get filled, there first have to be enough developers to go around. And there aren't.

There also aren't enough women in development. There are probably a million and a half ways to solve this issue, we're choosing one path. Increasing the number of female devs directly by training them is a great start to help with the issue, as well as solve the scarcity of developers. This brings us to supply and demand, and scarcity. 

We exist because companies can recruit from us. We provide enough high-quality candidates that companies come back to us time and time again. The reason our candidates are high quality is because we train them, yes, but also because we select them from a pool of smart people. Currently, we accept 5% of candidates that apply to Hackbright. Why? Wouldn't it make sense to take more? We're a for-profit company, the students pay us to attend. We're leaving money on the table by not accepting more - we could double our earnings by accepting 10%, right?

The problem here is complex. It's about keeping our quality high - as a company, and for our students. We try to do the right thing for quality first, profit second. Scaling out doesn't make sense if the experience gets worse, or if fewer of our students end up with jobs. The reason quality suffers is because of scarcity.

First, we're doing very emotional labor. Emotional labor is traditionally undervalued, and it's also regarded among the professional world as a limitless resource. If you're a caring person, you should be able to expand that caring to an infinite set of people, right? This is a fallacy - one person can't be the emotional pillar needed from a teacher to as many people as they're asked. Even given that there simply isn't time in the day to do that, we're ignoring the fact that helping someone through something difficult, like say, rewiring your brain to think like a computer scientist in 10 weeks, takes something out of you. It's rewarding, sure. It gives something to you that you can't buy or get otherwise. But it does drain. 

So the emotional labor is scarce - people who can both program, debug well, explain things well, and do the emotional labor are scarce, but the biggest scarcity is people willing to do that labor. This labor is traditionally reserved for significant others, friends, your children, your family. When doing this work, students often replace your friends and family, become as significant to you as your children. You have to be willing to do that to at least a limited extent, and most people aren't, or at least not for long. 

The next scarcity is space - simply having enough desks and pairing stations in a city like San Francisco is both expensive and hard to find. Keeping everyone together as a cohesive class unit is also tough. 30 is probably the maximum number of people that could function as a class, especially because being a part of the class is such an integral part of Hackbright in general. We can't just upsize the class, we'd have to create an entirely new instance of the class - with lead instructors, assistant instructors, a new group of mentors, et cetera. 

The last scarcity is absorption. The bay area needs more developers, but has a limited capacity to absorb new junior developers. Everyone who comes out of any intensive is essentially a "prepared beginner", who, through their own curiosity and drive, as well as a bit of help from a senior developer, can add functionality to software projects, run tests, debug, and make modifications. They're not yet capable of designing a project that scales, or spinning off an entire feature branch without much help. They do consume resources when they join a company, although the company gets a net gain. After about 3 months, all of our students are major contributors in whatever teams they join, but it does take that 3 months. We release 26-30 new candidates quarterly, and they've got to go somewhere - there are a finite number of jobs even for perfect candidates with the exact right stuff.