Create a community the hard way

At Hackbright, we have a strong community. Our students, mentors, partner companies, even applicants we regretfully turn away are very involved, and contribute in a positive way. I've been asked, how did we get here? I've actually been thinking about it myself recently, and I've figured out how we did it. We used one guiding principle that maybe we weren't strictly aware of, but we've followed faithfully and over time, we've built an awesome group of people that continually surprise me.

Love is all you need

I'll get into details, so follow me here. 

Our main guiding principle is that we love them. Love them really, honestly, like they are family. 

It turns out, you can't actually get anything worthwhile without caring about it. Think back to every job you've had where you didn't care, where the seconds ticked by like minutes, and the minutes were hours. You probably found yourself resenting your boss, your customers, which in turn feeds the cycle of resentment.

Now think of a place you've been, some organization, where you cared. Maybe this was a school, or a church, or a volunteer organization. Maybe you were lucky enough to have been part of a company that cared about you, and you in turn cared about those around you. However, excepting perhaps in the case of a church, you probably wouldn't describe that feeling as "love". You might say, "I love my job" or "I love this company", but what you likely meant by that is "I really like this job".

This is a step further - this takes something from you, but gives immeasurably back. Being a part of a community with the right stuff, the stuff people will pour their hearts into, that requires actual love. 

This is not to say, happy-go-lucky hippy flower power time prevails all the time. This past class, "Hackbright" became a verb, which means "to cry on the floor of the bathroom". Emotions don't run that strong when you don't love something. Familial love doesn't come easy most of the time - think about the screaming fights you've had, and times when you've had to cut a family member off because that was the only way they could get better. Sometimes, you have to say something difficult to someone, and then they don't understand, and they hate you for it, and you have to wait until they come to an understanding on their own. 

But think about this - you'd do pretty much anything for your family. Anything to ensure they have a happy, healthy life. Anything to make them more comfortable, their lives easier, to make them better than they are. These actions are how you tell them you love them, not by saying "I love you", although verbal affirmation is an important action to take. 

So, how to create a community? Love them. Honestly, deeply love and care that they are able to do whatever it is they have their heart set on, and help them to do that. They will love you back, and they will love each other the same way. Do the love thing in your own way, we each have our own special-snowflake way of showing it.

The Business Case for Love

This totally works, by the way. We're not the only ones doing this. I can name some companies offhand that love their customers in an authentic way. Zappos, Rackspace, There are many more, but those are companies I can especially call out. They range from large to small. Famous to startup. The common factor is authenticity, and success. You can't fake this kind of thing, and if you try your customers will know. 

When your customers know you love them, they don't switch brands at the slightest slip-up. They don't leave because you're not perfect, because you're not the cheapest option. It's no longer a race to the bottom line with your customers when you have an actual relationship with them. Much like a real relationship, the other person doesn't leave because someone is slightly more attractive, or makes slightly more money than you. These things are superficial compared to the relationship you've built, and your competitors can't make a dent in that. 

They also are typically prepared to pay more - when you create a relationship, your customers see your product as unique, even if it's not. You're probably not the only person out there doing what you're doing, but relationships are unique. Your customers pay for a relationship, not a brand, not a product. 

Roadmap to Love

1. Understand that your customers are the reason you exist. You might be a startup or a global brand, but because these people like what you do, you get to keep doing it. Be thankful, be awed.

2. Internalize this message, and spread it around the organization. This is easiest if you're a startup, because you can be selective with who you hire. Look to Zappos if you're not a startup.

3. Show your customers you love them. Think about what you'd have to do to prove to someone that you love them, without saying it out loud. Show them with actions. Prove to them they're your favorite customer. 

Human support agents, email response times, caring that issues are resolved, following up. Selling things at a reasonable price. Ad campaigns that take your customer seriously, as though they are smart, human, and have dignity. Messaging that talks about who you actually are as a company, as a group, instead of pandering. Compassion when your customer messes things up. These things and more come out of that simple principle, so prove you love your customers, and they'll love you back.

How to have an Awesomely Inclusive and Radically Transparent Hackathon

We had a hackathon last weekend, and we managed approach organization and inclusivity from a perspective of transparency and empathy, which made the event rock pretty hard.  We did it with not a huge amount of radical change, but rather a few subtle changes that made all the difference, and I thought I’d talk about them in case someone else wanted to deal with the same things we did.

These aren’t simply box-ticks, they’re different approaches borne of different attitudes, so I’ll also go ahead and explain why we made the small changes we did, and what we were hoping to achieve.

Events need user experience design too - someone who’s going to think about how the audience feels is key to have on staff. For that, @aerialdomo(main organizer), @undeRStandig and @janardanyri were critical members of our planning group, they were key to understanding how our audience would experience the event, and interface with the organizers.

A Clear Narrative

We wanted to invite our attendees to participate in a narrative about the event we were having. We couldn’t have thought properly about how to do that without writing the actual narrative first, so we wrote this:

My friends and some people I recently met (mostly women) formed a team of 5-7. We got some hardware to develop with, and were encouraged to bring our own parts. We brought something from home, and added it to our project to make it unique. We didn’t know much about hardware, but there were extremely helpful mentors at the event. Everyone learned something from the mentors, and everyone contributed to the project. Then, we presented our product to the audience, and everyone cheered. We won a prize, which wasn’t a huge prize, but helped us feel recognized for our efforts. In the end, our team made plans to meet up a few more times to work on our project, since the supplies are shared and we want to continue learning more about working with hardware.

Writing a story like this, where the story is generic to all teams, but is a basic template, will allow you to design the schedule and guide your audience to participate in the story. For more examples of this, look at storyboarding a game. What you’re creating is an experience, not just an event. Write a story, and invite people to participate.

Getting everyone ready for what was going to happen next was the main job of the organizers, and it kept us busy throughout the event. Clear communication was our goal, which gave our attendees prep time for everything from talks to dinner. Some tips for creating a narrative:

  • Write the story of the event you want people to tell. A template allows you to understand what you need to do in order to create that experience.
  • Post a highly visible schedule. Include food, speakers, presentations, and availability of mentorship. Set expectations about what attendees are supposed to be doing. 
  • Incentivise following the narrative, be clear about how to obtain the incentives.

In our case attendees, who were self-identified beginners, were supposed to be using a box we had given them and well as their own supplies to create a physical object to show to the other participants. They understood this as the storyline, and participated. Because of this, 90% of teams presented. 100% of teams created hardware-based projects. 80% of our audience was female, and 60% reported that they had never programmed before.

Removal of Barriers

A huge part of the success of our event was removal of barriers. Essentially, we did more experience design by thinking about common objections people might have to signing up and participating. We did a lot of brainstorming around “well, what if someone doesn’t want to come because”, and then we did our best to remove those barriers. I’ve included some examples from our hackathon.

Our first, and biggest biggest barrier to hardware hackathons is the hardware itself - it’s expensive, and most people don’t know where to buy it, or what to buy. Even those who are apt to dive in and purchase something usually don’t know where to start or what to buy, so we did that legwork for them. We bought SparkFun’s Inventor’s Kit - they have “lab” discounts for bulk purchases. The kit comes with some amazing things, the biggest one being the book that comes with the device with lots of examples to build, and colorful, large, easy-to-read diagrams. It also comes with a wide enough range of sensors to push the imagination, while keeping them simple enough to be approachable.

The next barrier is that, unlike software, circuitry does not have as tight of a feedback loop, or comprehensible error messages. It’s difficult to dive in on your own, so we saw a potential attendee imagining sitting at the hackathon, unaware of what to do next or how they could contribute, and then opting not to embarrass themselves. We made it clear that mentors would be walking around at the event. We kept the mentorship recruitment in the same social media channels as the attendee advertisement, so that our attendees could see what we expected of the mentors. We also kept the ticket count of mentors visible, so that attendees could guess about the ratio of mentors to attendees. We helped them form a clear picture of what it would be like to be completely new to hardware hacking and participate in this event, which I think is responsible for the ratio of people who had no experience we got to come to the event, as well as display of amazing projects that got pushed to completion.

Experience Design

The other main thing we payed a lot of attention to was the design of the rest of the experience. In order to be inclusive of the most people, we tried to keep the event entertaining, with speakers and prizes and lots of audience participation. We also needed to keep it family-friendly, and free of explicit imagery or inappropriate behavior. Some factors that kept women engaged without excluding other attendees:

  • Cleanliness, and calls-to-action surrounding cleaning and organization from the attendees - this helped drive home the idea that this was a community event, not just some corporate stunt.
  • A code of conduct enforced in a way that appealed to empathy over public shaming
  • Specific encouragement of minors and family participation
  • Inclusion of noted advocates for hardware and learning, like Highway 1 and Julia Grace

Enforcement: Empathy over policy

We had a code of conduct that stated no sexual imagery in presentations, as the event was family friendly, and the inclusivity aspect was very important to us. However, we had a team that wanted to bring together two pieces of hardware that weren’t appropriate in a family-friendly setting. The project was interesting, and the team was enthusiastic and genuine. Rather than kick them out, we had a conversation with them about how we could allow them to continue with their plan, while respecting everyone at the event. We settled on having them not use the hardware out in the open, so that no one (especially minors) would stumble upon it. Next, we had them do any testing they needed to do in an area we blocked off for explicit content. Last, we made it clear that though they would still be eligible to win prizes and pitch their demo, they would have to do it off of the main stage, and after the other teams had pitched.

We might have had the demo pitched on the main stage and asked minors and those who might be offended to leave. We chose instead to have the team pitch the demo in an area where attendees would have to explicitly go. The difference is subtle, but important. It sets a tone - one where we’re not forcing you usher your children out of the room, or visibly work your way out of a crowd of 200 people because you don’t feel comfortable or just don’t feel like seeing explicit content at the moment. Instead, we invited adults to come see content of a mature nature in a different area, which set the tone of getting to see something interesting and fun. The idea is an explicit opt-in, versus an explicit opt-out. This is the difference between a vulgar joke in a comedy show, and a vulgar outburst in a restaurant. One is something people are prepared for, one they have consented to. The other is intrusive if you’re not ready, and weren’t expecting it.

Empathy and Transparency

We were able to have a great deal of fun with the hackathon, without worrying about whether or not we were being “politically correct” or not, by changing the conversation. We approached each decision we made by thinking about how our attendees would experience the event, and by appealing to empathy, rather than strict rules. By communicating what we were going for, the experience we were trying to create, our audience helped us achieve our goals. We were clear about our thinking process, rather than seeming to make exceptions for some people, but not others. Our community developed a great deal of trust for us as organizers, and have a new expectation about how events can be managed.

Our code of conduct is posted here - feel free to use it for your hackathon. 

We hope you can join us for the next one, as a mentor or an attendee, or even as a sponsor. We sold out this event, so we’d love to offer it again for everyone on the waitlist, and the new batches of students that will be coming through Hackbright Academy. Let us know if you’re interested in getting involved

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.

Why does Hackbright only accept women into the program?

Another blog post transcribed (thanks @rebecca_standig) from the same conversation about @Hackbright Academy. It also covers some hostility I get from people about our policies.

EDIT: changed "where all but about 80% of women" to "20%" - that was a mix-up on phrasing. 20% of women who start in comp sci degrees finish them.

Note: Hey Hacker News readers! I'll be publishing something on pedagogy in a bit. Stay tuned. 

So, why do you admit only women to Hackbright?

I've gotten this question really often via email, as well as at coffee shops and any time that I walk around the Mission or SOMA in my Hackbright Academy t-shirt. Often, people ask me why we only admit women. They say things like, "It's discriminatory. Aren't you trying to fight discrimination?" Or they say, "You can't just admit women. That's illegal." Or they threaten to sue me. People think that they're very clever.

The reason we only admit women is because as it stands, we put more women into software engineering in one semester than Stanford and Berkeley do every year. Women start a computer science degree at maybe 1/3 the rate as men. Then there's this freshmen drop-off, where all but about 20% of women end up changing their major, usually to something involving design or business. Sometimes, they go into electrical or mechanical engineering, but that's actually pretty rare. Usually they leave the field of engineering altogether.

I have a theory about why this is. During a computer science degree, most women don't have a lot of friends to turn to who are also doing a computer science degree. Most computer science education is heavy on theory and light on implementation. So, you learn a lot about computer science, but you don't really learn how to code. That is something that you have to do on your own. Since [these women] don't have friends that sort of expect that of them and know that that's what they're supposed to be doing, they don't spend a lot of time in it. If you don't spend time implementing theory, you'll never really understand it. The courses get harder and harder, and they haven't spent a lot of time with their friends talking about these kinds of things. They're surrounded by people who are not like them, and don’t openly talk about struggling to learn [difficult programming concepts]. This reinforces the idea that they don't belong there, and is a common fear. All the time, women tell me that they feel like they don't belong in computer science, or they don't belong in engineering, or they don't belong in a company as a programmer.

The reason for that is there aren't many women, and that begets even less women wanting to get into computer science.

So, what’s the solution?

So what do we do about that? First, we create a community. There are lots of communities for women. I know this because I'm a woman in tech, and I am inundated (especially as a leader of several general organizations for women in tech) with people telling me all about all of the different organizations. The problem is, I meet 4-5 women every week that have never heard of any of these organizations. So outreach is a problem.

The next problem is that it's intimidating even to join these big organizations because they're for people who profess that they are software engineers already. Sometimes, they're about being software engineering majors or computer science majors, and that helps. But they're campus-specific, so if you're in college that's great for you.

Most women who get into computer science that I interface with are doing so after they've already completed a degree in some other area, be it business, marketing, biology, chemistry, sometimes journalism. There are a number of things that drive people away from those fields and into software engineering, or just drive people away from software engineering initially into those fields and then they realize that this wasn't what they wanted.

These are the people that most often make really amazing software engineers, yet have no real path into software engineering. They're not already software engineers, so they don't feel like they can join these organizations, but they're also not going to college for software engineering, because they've already gone to college. It would be ridiculous to expect them to go and get another four year degree or a two year master's degree that they may be ill-equipped for. So these are the people we serve. They're a minority that needs a leg up. Just like having a foundation that helps Asian Americans or Hispanic Americans or Indian Americans get a leg up in an unfamiliar place, a place where you are underrepresented and generally marginalized.

That's why we serve only women.

So, what about the people who think you “have to” admit people?

We don't have to admit people. We're not a school that is accredited by the US Board of Education, nor are we a non-profit. We are a for-profit company, but we're a for-profit company with a mission.

That mission is to bring equality to computer science. Our strategy for doing so is the following: One, only let in people who will contribute to equality in computer science. Right now, the smallest subgroup of people in computer science is women. Other than, potentially, transsexual people. They're a small enough group, though, that if we were only to serve them, I think we'd go out of business. Women make up half the population on the planet, yet only about 6% of computer science engineering jobs.

The second thing that we aim to do is promote the idea that women are competent in the field. They are smart and useful, and just as smart and useful as men, and should be taken seriously. Rather than admit literally everyone who comes in, we admit the top 5% of our applicants. Now, these might have been people who would have gotten into computer science some other way, and that's great. But what it does by producing a candidate of a consistently high quality is further promote the idea that women are just as competitive as men in computer science. By putting out really excellent women into computer science, we reinforce a positive stereotype. Stereotypes are not all bad; positive stereotypes are great. We would love to reinforce a positive stereotype, which will help combat all of the subtle biases that work against women in computer science.

The last thing we do is make sure the insecurities and vulnerabilities that causes women to leave computer science in the first place are patched. We do some drills in the safety of Hackbright on whiteboarding, on salary negotiation. We do some generalized therapy, just by talking out insecurities and fears. We get very involved in their emotional wellbeing, because it matters a lot. The most productive software engineers aren’t afraid all the time, or down on themselves - they feel empowered. So, we do our part to empower our students.

What do I look for in a potential Hackbright Student?

I had my cousin transcribe the following conversation, which answers a lot of the questions I get asked during interviews. I went through and added a few links to it, but it's generally unedited- it's just how I talk with the "um"s and "uhhh... [long pause]"s taken out.

So, what do you look for in a potential Hackbright student?

I get asked that a lot, actually. What is it that makes us see a person and say, "Yes, we're going to admit them into this program and ignore 95% of people. But this person, yes, we believe in them." The answer is simple. But the backstory is a little more complex.

Salon recently published an article called "School is a Prison - and Damaging Our Kids." It is. That's the biggest problem. School, as an institution, was created to teach children how to not question authority, and how to crush their own curiosity for the betterment of absorbing someone else's ideas. It is mostly about causing someone who might otherwise be compelled to learn whatever they wanted to on their own to instead accept what they're being taught. This system worked really, really well during the Industrial Revolution, when the highest demand was for low-skilled factory workers. Today, that’s not the case- knowledge worker jobs are on the rise, and are going unfilled, but not for the reasons you might think.

One of the biggest things that our school system does today is cause people to start thinking like factory workers. They start questioning the audacity to want certain things, like respect in their field. They stifle their own thirst for knowledge and think, "Well, I don't need to know that. I only need to know certain things - things I've been told that I need to know in order to get a job, or have the life I’ve seen on TV."

What we're looking for is somebody who was terrible at that kind of thinking. We're looking for somebody who isn't very good at being told what to do or doing what they’re told. We're looking for somebody who is actually often bad at school and bad at listening to directions. Instead, what we look for is someone who is very good at following their own thoughts about what it is they want to learn.

Now, usually someone who has always decided to follow 100% their own thoughts and feelings about what they want to do isn't what we're looking for. What we're really looking for is someone who has had to fight that system so hard and so long, and had no help doing it. What we want is to be that help. I say this to people often: "I take people that were always meant to be software engineers, and I rectify that mistake."

That's sort of the secret of what we're looking for at Hackbright, but often times the reason these people aren't software engineers is because they're just no good at identifying the fact that they should be software engineers. So, don't think that just because you think that you aren't a software engineer deep down inside that that means you can't be a successful Hackbright student. What we're looking for is somebody who fits the philosophical profile of a Hackbright student.

So then what’s the philosophical profile of [a Hackbright student]?

Well, the philosophical profile of a Hackbright student is somebody who is curious, is uncompromising in their search for answers, who has a questing approach to truth rather than an accepting approach to truth, and has a natural affinity for systems. They have an affinity for logical systems, for mechanical systems, for how things work. This often means biologists, but it also means mechanics, and it means people who are interested in law. We have a positive correlation with law a lot. Chemistry, physics, math.

The biggest thing that is often found lacking in people who would normally correlate  really well with being a Hackbright student, people who sound great, is the “why” factor. Why are you doing this? Why do you want to know? Why have you done everything else in your life? If you ask that question on a constant enough basis, it leads you to act a certain way. That's what we're looking for most of the time, when we ask you all about your background. We want to see evidence of you asking why. We want to see evidence of you looking at what you're doing, looking at the world you've gotten yourself surrounded in, saying "Why?" and in some cases being unable to answer that. That’s when you have to jump ship- to change what you’re doing. We see half-finished degrees and projects abandoned a lot. A lot of people are leaving what they thought would be their dream job to come here and change their life.

Jumping into a situation is the only way to really learn about it. By asking why, that shows that you've learned about it, you've sought out enough information to understand where you are, and to get to the point that you can critically assess whether or not you're in the right place. If you can critically assess that you're at the right point, you're fine, and you probably won't apply to Hackbright. If you do apply, that means that you've decided that you aren't. It's not about the money, although money can be nice. It's not about doing something fun every day. It's about questing for that fundamental truth constantly, as sort of the driving force of who you are, and being unsatisfied when you aren't there.

Week 10 Roundup

Well I certainly didn't keep up with blogging through the 10-week rollercoaster that is HackBright. I learned, laughed, cried, went through crazy emotional times, and made friends. I also drank a lot of alcohol. 

Week 2 was a blur, mostly lectures in which I trolled Christian to make sure certain points got across well, and to keep him human to our students, rather than some kind of job-bestowing godlike figure. I don't know that I fully succeeded with the second one.  We did a lot of breakout sessions, which I feel like were really helpful. They helped keep each lesson in context so that everyone understood that we may have been doing simple things, but that those things built up to me big deals.

Week 3, my son came to visit. By that point, our students had formed a bit of a bond with me, so me being not there was not too bad for morale. It was however, really tough on me, because I brought him in to work 3 out of the 5 weekdays he visited on. He enjoyed himself enough, and ingratiated himself with most of the students pretty well. Christian showed him the roof and talked to him about physics, which made him instantly reverent. It was pretty cute. 

Week 4, I was playing catch-up, in terms of energy (9yos are very tiring) and in terms of where everyone was in the program. I also stopped making progress on the project I was working on at this point - students needed too much outside help for me to spend time on it, so I was forced to just kind of back off. In the middle of the week, Donglegate came to a head and got really nasty online. Like many women in SV, I responded emotionally to the threats Adria was getting, especially as she's a friend of mine. Due to complexities and traumatic events in my past, seeing some of the images posted online and the vitriol spewed at her, I was emotionally drained and very upset for some time after. Even now, it's tough to write about. At some point, I'll post in detail on this.

Week 5 was a blur - bringing people up to speed on common web technologies and the idea of markup was a big deal. We explained HTML and how it was like Markdown or Wiki Markup, only with a lot more eccentricities helped them deal with what seemed like an impenetrable world. We covered a slight bit of CSS, and then I got to delve into JavaScript. At this point, my energy from the kid visit and ensuing trauma, plus 18 hour days were beginning to wear on me. The lesson I learned here was that we needed more instructors, and that I cannot take time off during Hackbright, or have visitors. Downtime is going to have to be the only time someone can come to SF to see me. 

During Week 5 we also began preparing for projects. We had to very explicitly state that we're not an accelerator. We're not an incubator. We're not here so that you can develop an amazing product vision and start a company. Our students are here to program and to learn things - you can't do that if you're worried about the marketability of a product. Sure, learning happens better when you're solving a specific problem for yourself - when you listen to a lecture on SQL and can imagine using it to solve the problem of how to get two rows of data to JOIN together, it makes sense. If you talk about JOINS in the abstract, it kind of sounds like a crazy, useless concept. So it's useful to have a project you're excited about - but focusing on becoming a crafts[wo]man means you have to focus on the craft, not the business. They're two separate disciplines, and we're not here to make companies, we're here to make developers.

Week 6 was the official start of projects - students were finishing up the final tutorials that would show them how to use SQLAlchemy. Many wouldn't end up using that kind of thing at all for their projects, but understanding the principles behind an ORM is important, because they're more than likely going to encounter them in the wild. 

One thing I wasn't prepared for was the scope of some of these projects. We had webapps of varying complexity - some that had to keep consistent state between two people, some that used multiple APIs and a lot of data, one even used single value decomposition to intelligently rate movies on millions of rows - dealing with datasets larger than the RAM on your computer is not a simple task. But the next tier of projects, things I've personally never even done (although, this does not mean I won't try), things like database engines that handle concurrency, written in a language we didn't teach, using concepts we didn't teach. Things like compilers, lexical parsers, people writing their own programming languages. 

We had a student who read a paper on someone who found correlations between genes and characteristics that had never been noticed before by doing Natural Language Processing on Pubmed papers. This paper kind of contained some abstract notions on how you might do this, but I watched her tear the paper apart, and put it back together in python. It was amazing. Her twitter is @cadeparade, and she's still for hire as of me writing this (but probably won't be for long.) I also got to learn a bit about Part of Speech Processing - which is incidentally really cool.

I had to mention at least one of them, not to show favoritism, but I feel like what happened wasn't real. Like it was somehow removed from the real world. It was like I was out of the country for 10 weeks, and my friends and family kind of watched this amazing thing occur from my excited tweets and late night rushed updates by phone. But it wasn't. It happened right here, in San Francisco. 

Tonight, some of them got offers, which were beyond anything I expected whatsoever. I have no doubt that every single one of them is employable, and would contribute a lot to the organization they end up at. Plus, I have 26 new best friends. 

In 4 weeks, I have to start all over again.