This won't be a short post, but it'll give you a summary of close to a year's worth of trying to teach people how to program. We know what works and what doesn't, and so far there's a lot of stuff out there that just doesn't work, based on our own experience and what our paying customers are telling us (they're mostly people who tried and gave up on Codecademy, Codeschool, Udacity, and Coursera).
- Graduated from UIUC in May of 2011
- Started OfficeHours.TV
- Co-founded Niroka
- Co-founded Dojo, which later became Bloc, which we announced on stage at LAUNCH
- Raised some seed money, hired 2 friends from college
- Started a class of 15 students, announced a class for 45 students--we've had 70 applications, turned down half, and accepted 20. Skip to the bottom about engagement if you want to understand how we're actually teaching people to learn to program.
I bought a one-way ticket to San Francisco right after graduating, which is where I planned to start a fashion startup without having met my co-founder (I realize how crazy this sounds). I had been talking to him on the phone, working with him for about 6 months, and we both were UIUC alumni.
As any broke college student, I didn't have the personal runway to work on the startup while my new cofounder was doing a wedding and honeymoon that lasted several months. I also wasn't passionate about fashion--I wear a Dropbox and Rap Genius shirt 6 days out of the week, and I've been known to go out to bars in basketball shorts and sandals.
Why was OfficeHours.TV my first project? It seemed like something people wanted, and it was a good extension to writing Startups Open Sourced.
OfficeHours.TV: get advice and feedback from entrepreneurs
The first thing I built was OfficeHours.TV. At its peak, someone bid $600 for 30 minutes of Brian Chesky's time. The problem is that model was not easily repeatable. It's difficult to find a lot of people who had Chesky's clout, and harder to get them to hold regular office hours as they were donating the money to charity. There was probably a total of $3,000 in transactions from this project.
I started looking at possible co-founders midway through. I knew @choxi from school, and I ended up working on the project with him remotely while he was at Groupon leading their social team. If you're looking at cofounders, this is a great way to do it. Add them as a GitHub collaborator and see what they do. @choxi was committing code that night, and before long he was committing more code than I was. I initially tried walking him through the code base on Skype and he was like "it's alright, I can read the code, you don't have to explain everything to me."
I eventually convinced @choxi to move here in October rather than January because we would do YC again (I'm an alum). I didn't realize that there was a conflict of interest policy for companies of the same stage--this varies depending on investors, and most investors will not invest in you if they've already invested in a competitor. That's all good and fine, but we had to turn to a different source of seed funding (more on that shortly). Basically, nothing went according to plan. That's no exaggeration.
Here's what the home page of OfficeHours.TV looks like:
Niroka: learn anything from anywhere
So OfficeHours.TV was losing steam after a month or so because we were running out of people to reach out to. It was around this time that @choxi and I started working on Niroka: Skillshare meets Udemy. We allowed people to teach classes both online and offline. We posted fliers all over campuses around San Francisco. At one point we were trespassing in an all-female residence, shamelessly posting fliers to let people know they could teach or become any musician from playing the guitar, piano, or being a DJ. If you're a college student in San Francisco or Berkeley and you used a public restroom in the fall of 2011, you probably heard about Niroka.
There were some logistical problems here: the people asking to become instructors did not want strangers in their homes using their equipment, nor did they want to carry the equipment to a location. We basically had to become a Zipcar for musical equipment. We were on the phone with42Floors--I was in the same YC class as Jason Freedman so I knew what he was up to before they announced--and they were telling us we'd need some retail space to do this. But investors pushed back on this idea and said it didn't scale. Here's what the site looked like at one point:
I have some personal gripes about investors. They feel too shortsighted, but I get how their funds work and why they need returns on a 5 or 10-year scale. The other one is that nearly every investor will tell you that "team matters the most," but that's merely convincing BS. At least it was convincing; it could have been unconvincing BS and that's not a whole lot better.
I only know of a few investors that actually stick to the "we care most in the team" mantra. In reality, traction is the single most important thing you need, followed by who else is in the syndicate, and then finally team gets a little bit of weight. The flaw in thinking here--and I think it's driven by being shortsighted--is that you can invest in a company with traction right now, but if that traction goes away, you'll be left with two guys and you are gambling on the hope that they're good enough to figure something else out. I'm not saying I want to spend 20 years building a company that doesn't go anywhere, but I think the order of the priorities is off. Team should always come first. People like YC get this: you can fund entrepreneurs and if they're good, they'll figure something out eventually. Hey, did you know you could even apply without an idea now?
Back to the drawing board: Dojo (Bloc) is born
At this point, with a whiteboard full of ideas to solve our own problems and most of them scratched out for various reasons, we were excited by Heroku's new Cedar Stack and the possibility of deploying apps on behalf of the user. What happens if you remove the local development and deployment hurdles to an aspiring programmer out there? Is it possible to learn faster? Do people stay motivated and engaged because of this? We tested this hypothesis. Dojo was born, and there was some excitement when we showed off our prototype. Nobody had done this, not evenCodecademy was experimenting with app deployments.
About 5,000 application deployments in, we decided to start hitting the streets for some seed investment. One of the first investor meetings we had with YC alumni Jude Gomila lead to a chain reaction of meetings that would follow. Jude liked us as a team, but he also really liked the idea. "This is fucking cool and I wish I had done this" is the phrase we remembered from walking out of that meeting of Heyzap's offices. A slew of introductions followed, in addition to criticism about how poor our pitch deck, executive summary, and investor pipeline spreadsheet were. I focused full-time on fundraising around this time.
Dojo was renamed to Bloc because we didn't want to get sued by a similarly-named company for trademark infringement. Trybloc.com went through two major iterations. The first version was essentially Ace editor and emscripten in the browser. It was a glorified TryRuby and looked like this:
The second version had a guide, editor, and tasks ('tasks' were unit tests that ran remotely on your code which was deployed to S3). It was built mostly around the announcement of the product at LAUNCH 2012. Watch me present on stage here. We hired the amazingly awesome Matthew Skiles to do the front end. It definitely looked and worked better than our previous version:
We even hand-crafted our beta invites as wooden blocks with invite codes on them:
The reason this model doesn't work can best be summarized this way: developers today use their own tools because it just works. You can't run and hide from a terminal. You need to embrace the terminal, and you need to embrace the editor because that's the best development experience that exists right now. The company that puts all of this in the cloud or the browser isn't coming any time soon. There are just some things that aren't going to work well in the browser, and programming is one of them.
There were a few other problems we noticed around this time.
User engagement: I suspect any company involved in teaching people how to program is having trouble with this. Basically, we saw a tradeoff when you are trying to capture a user who wants to learn how to program. You can gather up lots of them if you start with something trivial (see Codecademy's home page) but you end up with what we've heard others describe as tourists who were not committed. We made a conscious decision that we didn't want casual users. We wanted the type of person who has tried to learn how to program, got stuck, and gave up. This person knows something doesn't feel quite right when they try to learn how to program, they just feel anxiety and frustration. It's something hackers take for granted because we grew up with computers, Freenode, Stack Exchange, and our own nerdy friends, professors, and TAs who helped us when we got stuck.
Revenue: Our model was not working in a way that helped us. We had deployments, but none of our numbers were impressive enough for most investors. We didn't have the revenue, and we didn't have the staggering user growth (although we did get decent adoption with 40K apps deployed and over 5,000 users, it just wasn't good enough).
Technical challenges: When you make changes to an application, you want to see changes immediately. That's how developers work right now: they make a change, save a file, and hit refresh and see it in their browser instantly. It works really well that way because the feedback loop is tight. To "hack" this problem, we asked users to complete these tasks and then ran unit tests against users' code with the click of a button. This was nothing like the string matching and code injection we did in the first iteration of Bloc. These were actual unit tests being run against applications we were uploading to an S3 server on the fly. Ultimately, it just wasn't good enough. Deployment times through Heroku were 2 minutes, so we needed to find a way to speed that up to a few seconds, and we didn't have the runway to do it.
Value: At the end of the day, we may have been nerding out more than we were genuinely satisfying customers. Some people thought what we were doing was cool, but we knew deep down that we couldn't help people apply for an entry level developer job or build their own applications independently. It wasn't an immersive learning experience.
Fundraising process during Bloc
I remember walking away from the fundraising process worn out and broke. As Louis C.K. would say: I would have been so broke that if something was free, I couldn't even afford it. My credit card had been maxed out at $10k; I never went that far into debt before. Walking back from a McDonald's in the Mission District on a cold night in November, I asked Roshan if he could cover my rent in January because I would be out of money, and he thought he could. Turns out he was also out of money by January, and we had to ask our family to help us cover February's rent. Any hope your family had in your "entrepreneurial dreams and aspirations" is soon met with a little more skepticism when you're in debt and asking them to pay for your rent.
We hired two employees (friends we knew from college) before we even had the money to pay them. One of them quit their job, and the other turned down an offer to join us. I distinctly remember sitting down with them in February and telling them we may have to go get jobs. I could barely hold it together at the gym that night. As I was biking home, I broke down at a secluded street corner in Palo Alto and did that thing babies do when they need their diapers changed. I'm typically not emotional, but this was a low point for me. It was around this time I started scheduling interviews with tech companies.
At any lowest point in the game (and there were many), I would always tell myself and everyone else: "This is par for the course." If you can't handle being in debt, constant passes/rejections from investors you look up to and whose opinion you respect, you think your startup is without a doubt going to fail, and you have to tell your friends they have to get a job somewhere else and you can't pay them on time, you may not mentally be ready to handle the ups and downs of startup life. This is why naivety is so important for those who will do it anyway. They have no idea what they're about to get themselves into, and if they did, they might decide not to do it.
Solving the ever elusive engagement problem
Of all problems out there, engagement remains the biggest. We can get the users and the revenue. As of last week, people will pay us $3,000 for 8 weeks of mentorship to learn how to become web developers. We've had over 70 applications, we've accepted 20, and we've turned down about half of those.
We're actually in a really nice position because we get to pick who we want to work with. As long as you're driven, don't easily give up, are fully committed, and you're easy to talk to (read: not an asshole), you're in. I give the same advice to people who ask me to read their YC applications: don't give them a reason to reject you. That's a lot easier than it sounds; some people actually overthink the application and think every answer has to be pristine perfect. Just focus on not screwing it up. At YC's scale, it's probably far easier to find one good reason to reject you (eg an unjustified uneven equity split) than it is to get a bunch of green lights lined up. Disclaimer: this is my own opinion and observation.
Try putting yourself in our shoes. You want to teach people how to program, but everything you've tried stops working very quickly because the user walks away. How would you fix that problem right now? I'll tell you how we did it, but take a step back first.
Here's something we know for certain: people want to learn how to program, and it's still an unmet need. Try to answer this question: I want to learn how to program, so I'm going to ________________. Most people start out this way by getting a book, and then they get stuck somewhere. Most people don't know about Freenode and most people on Freenode aren't going to help beginners with their seemingly trivial problems.
When I trace my own experience, the learning pace accelerated drastically when I had someone sitting next to me to prevent the "getting stuck" phenomenon that often requires a rubber duck to power through. It was actually @siong1987 who helped me learn the fastest in the winter of 2008. It could have gone slower and more painfully, but we were both there writing code together. I picked it up very quickly because I didn't get stuck for very long on any single problem. I had an unfair advantage.
For beginners, too many problems exist to block the flow, and users get stuck in the anxiety fragment. Programs like Dev Bootcamp and Code Academy are nice, but they fill up quickly, require a full time commitment and cost more ($12k for DBC, $6k for CA, and $3k for us). If you live in San Francisco, you should do DBC. We're actually directly inspired by their model; Shereef Bishay--who I call the Egyptian Paul Graham--has been mentoring us and guiding us on how to go about building this.
When there's money and reputation on the line, people don't want to fail. These are two of the strongest motivators that exist. After nearly a year of iterating on educational startups, we think we've found the ideal combination to solve the engagement problem.
Commitment. A student pays $3,000 to take the class, and we've already found that this works as a great filter to find people who are already motivated and excited about learning to program. Having money on the line is a great motivator, just like having a gym membership.
Connections. The very first interaction (the interview) someone has with us is a face-to-face Skype call. The second interaction (the follow up) is also a Skype call. E-mails are too impersonal and make it easy to back out. Students build connections with other students in their cohort. It's the same reason choosing a friend as a cofounder is such a good idea: the potential disappointment in walking away is a strong deterrent to hold the company together. This makes it difficult to give up and motivates students to work harder; they don't want to let their peers down.
Interviews. By doing interviews, we understand what scheduling conflicts exist, what kind of goals someone has, and how much time they can commit to the program. We wouldn't accept someone if we didn't think they could complete the program--we rejected an applicant on the spot during an interview because they said they could not commit to the 3 hours per day. We at least know this was the wrong time for them to be doing this. We also are up front about our willingness to drop students because of their lack of commitment; we are estimating that 3 or 4 will be dropped from any given cohort.
Feedback loops. If we aren't doing a good job of teaching, we'll know very quickly because we have multiple interactions with every student each week. Likewise, we know if they're struggling. I personally will require my students to blog each week, I'll do retrospectives on Fridays, I'll do code reviews weekly, and I'll be doing several Skype calls each week with them.
There are questions about whether this model scales, but it can be applied to anything, even outside of programming. You don't need 4 years and piles of debt; you can learn faster when your mentors are good and you commit to immersing yourself. You could do this with UI design, animation, foreign languages, or anything really.
We're on track to generate $100,000 in revenue in the next 2 months. We're now opening it up to accept mentors here--have you ever wanted to get paid a $150k salary for a teaching fellowship?
If there's something you want to learn, tell me and we'll find the right mentor to teach it.