Hacker School User's Manual
About this document
This User's Manual was written for admitted Hacker Schoolers to help them navigate and understand Hacker School. We've decided to publish it in the hope that it will give the outside world a clearer picture of what Hacker School is like. You can read more about our motivations on our blog.
- Welcome to an unusual experiment
- The environment
- Traits of an awesome Hacker Schooler
- Pair programming
- Annoying stuff we debated including
- Struggling and mental health
- Jobs, recruiting, and how we make money
- Other resources
- Contact information
- A brief history of Hacker School
Welcome to an unusual experiment
Hacker School is unlike the rest of the world. This guide is designed to help you get settled in and get the most out of your batch.
One of the things that makes Hacker School different is that it's largely self-directed. This means you won't have someone telling you what to do, learn, etc, while you're here (though we do have a few social rules). This self-directedness is baked into the core structure of Hacker School, and is why we don't have grades, exams, curricula, or even classes. It comes from our belief that people learn best when given the freedom to explore what most interests them.
This doesn't mean Hacker School is a vacuum. The facilitators are here to help everyone in the batch learn as much as possible. We've been running Hacker School since the summer of 2011, and we've learned a good amount about what strategies have and have not worked for different types of people in the past.
In addition to the facilitators, you also have the rest of your batch to help you. Hacker Schoolers come from a tremendously diverse set of backgrounds: Some people come to Hacker School and only have a couple of months of programming experience. For instance, maybe you're learning Python and are just getting a grasp on basic programming concepts. Other people come to Hacker School and have programmed professionally for a number of years. For instance, maybe you have a computer science degree, and want to dive deep into an open source project you've started but haven't had time to fully develop.
Regardless of how much experience you have, we admitted you because we believed you would be a positive influence on the batch, and we think being at Hacker School can help you dramatically improve as a programmer. This is really important, so we'll say it again: Everyone is here because we want them to be here, so if you're reading this, don't worry about how much more or less other people in your batch know. You are here because we want you to be here and believe in you.
Another thing that makes Hacker School different is the amount of focus it gives you. It's rare to have such a large, uninterrupted chunk of time to focus on just one thing. Even at work, most of us have multiple responsibilities and priorities to juggle.
Ideally, that's not the case at Hacker School. One of our goals is to remove as many obstacles in the path of growth as possible. Giving people three months to focus on becoming better programmers is a huge part of that.
(A funny thing we noticed a few batches in: Hacker School is as much a social hack as anything. You could quit your job and spend a few months programming for its own sake, but most people would consider you pretty weird. Doing Hacker School is much more socially acceptable than sitting at home for three months. Of course, we also think Hacker School offers way more benefit than just being an easy answer to tell your friends and family when they ask what the heck you're doing with your life.)
Another obstacle we try to remove is fear. We think this is one of the most pernicious impediments to education. In most of the world, but especially school and work, people are afraid of looking stupid. This fear frequently keeps us from asking important questions like "how does that work?" or even just "why?" Worse, it keeps us from saying "I don't understand." That means many of us muddle on with a half-baked or entirely incorrect understanding of core concepts. This is particularly bad with programming, because these misunderstandings compound, and over time become harder and more embarrassing to admit to and address.
Did you know there's a well-documented phenomenon in which highly qualified people go through life feeling like they're a bunch of frauds and don't deserve the things they've achieved? It's common in work ("I can't believe I made it past the interviews. Surely someone will figure out I'm wildly incompetent and fire me soon!") and school ("Everyone here is so much smarter than me. I got in on a fluke."). This is called impostor syndrome.
This is why saying "I don't know" or "I don't understand" is a positive thing at Hacker School. It's an opportunity for you to learn something new, and for someone else to help you with it (or vise versa).
Another way we try to remove obstacles to learning is by having a small set of social rules. These rules are intended to be lightweight, and to make more explicit certain social norms that are normally implicit. Most of our social rules really boil down to "don't be a jerk" or "don't be annoying." Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy. That's why our social rules are designed to curtail specific behavior we've found to be destructive to a supportive, productive, and fun learning environment.
No feigning surprise
The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, this rule is tightly coupled to our belief in the importance of people feeling comfortable saying "I don't know" and "I don't understand."
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean Hacker School isn't about truth-seeking or that we don't care about being precise. Almost all well-actually's in our experience are about grandstanding, not truth-seeking. (Thanks to Miguel de Icaza for originally coining the term "well-actually.")
No back-seat driving
If you overhear people working through a problem, you shouldn't intermittently lob advice across the room. This can lead to the "too many cooks" problem, but more important, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically.
No subtle -isms
Our last social rule bans subtle racism, sexism, homophobia, transphobia, and other kinds of bias. This one is different from the rest, because it covers a class of behaviors instead of one very specific pattern.
Subtle -isms are small things that make others feel uncomfortable, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle -ism. Like the other three social rules, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on.
If you see a subtle -ism at Hacker School, you can point it out to the relevant person, either publicly or privately, or you can ask one of the faculty to say something. After this, we ask that all further discussion move off of public channels. If you are a third party, and you don't see what could be biased about the comment that was made, feel free to talk to faculty. Please don't say, "Comment X wasn't homophobic!" Similarly, please don't pile on to someone who made a mistake. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment.
We want Hacker School to be a space with as little bigotry as possible in it. Therefore, if you see sexism, racism, etc. outside of Hacker School, please don't bring it in. So, for example, please don't start a discussion of the latest offensive comment from Random Tech Person Y. For many people, especially those who may have spent time in unpleasant environments, these conversations can be very distracting. At Hacker School, we want to remove as many distractions as possible so everyone can focus on programming. There are many places in the world to discuss and debate these issues, but there are precious few where people can avoid them. We want Hacker School to be one of those places.
Why have social rules?
The goal isn't to burden Hacker School with a bunch of annoying rules, or to give us a stick to bludgeon people with for "being bad." Rather, these rules are designed to help all of us build a pleasant, productive, and fearless community.
If someone says, "hey, you just feigned surprise," or "that's subtly sexist," don't worry. Just apologize, reflect for a second, and move on. It doesn't mean you're a "bad" person, or even a "bad" Hacker Schooler. As we said above, these rules are meant to be lightweight. We've all done these things before. In fact, we originally adopted a no well-actually policy for our company because Nick and Dave well-actually'd each other all the time.
Traits of an awesome Hacker Schooler
Here are three principles we believe in. If you're living up to these principles, you're doing well at Hacker School.
Be rigorous. Understand how and why your code works. Understand your tools. If you're working with a framework (like Sinatra or Flask), learning to use it is just scratching the surface. Go deeper. Learn how it works.
Strive for greatness. You're all at Hacker School because we believe you can be great programmers. Becoming great takes a lot of work. All of us who work at Hacker School are trying to become great, too. We don't think we're there yet.
Reflect on your progress. We're all getting better at programming, but we should also be getting better at learning. Reflecting looks different for different people, but we recommend two primary things. First, write a blog! Even if no one else reads it, writing prose is a great way to crystallize concepts in your mind and deepen your understanding. Second, get code review! It's so much easier to get better when you're getting feedback and advice.
Ok, enough with all that. Now onto the real reason you're probably reading this: What the heck should you do with your time at Hacker School?
The answer to this question will vary significantly from person to person. In general though, a good question you should ask yourself is: How can I make my three months at Hacker School the three most productive and educational months of my life?
A few words about this guide
This guide is a primarily a collection of things we've found to be useful while working on Hacker School. Nothing in this guide should be treated as gospel, and all of it is subject to change. If you find other strategies work better for you, great! (But please make sure to share them so we can include them in future versions of this document!) What works for some people won't necessarily work for everyone.
If you're relatively new to programming
- Choose a text editor that is easy to learn and stick to it. If you're not sure which one to choose, Sublime Text is powerful, intuitive, and available on Mac, Windows and Linux.
- Avoid large frameworks like Rails and Django until you've got a decent grasp on the language you're using.
- Write lots of code. The specific code you write is less important than that you write lots of code.
- Don't worry about choosing the "perfect" project. It's easy to let the perfect be the enemy of the good when it comes to project selection.
- Have your code reviewed regularly, ideally by someone who knows the language you're working in well.
- Pair program, ideally with people who know the language you're working in well.
- Develop a good mental model of your code.
- Become a systematic debugger.
- Write small programs from scratch.
- Give yourself progressively larger challenges. For example, write a project you think will take an hour, then an afternoon, then a day, then two days…
- Become comfortable with your tools, but don't go overboard yak-shaving. Learn to use git, GitHub, a text editor and your language's debugger.
- Avoid distractions.
If you already have a good grasp of at least one language
- Learn a second (or third) language well, ideally one that's very different from the one you know best (e.g., if you know Python, it's probably more educational to learn Go or C or Scheme before you learn Ruby).
- Have your code reviewed regularly.
- Review other people's code regularly.
- Pair with people of all skill levels. You can learn a lot pairing with people at or above your level, and pairing with people who aren't as experienced (having to explain things to someone else forces you to deepen and clarify your understanding of them).
- Find the things you've always been a little scared of – e.g., multithreaded programming – and learn those (assuming they actually interest you).
- Avoid distractions.
If you're really experienced
- Contribute to open source projects, especially well-established ones with high code-quality standards.
- Consider starting your own open source project. Two good ways to find ideas: Scratch your own itch, or factor out code you've written multiple times previously into its own library.
- Continue doing most of the things above, including having your code reviewed by (and working with) stronger programmers. If you need help finding them, either inside or outside of Hacker School, we're happy to help.
- Avoid distractions.
Most Hacker School alumni wish they'd spent more time pair programming during their batch. We learned this after the second batch, and have shared this fact with every batch since. Despite this, lots of people still tell us after Hacker School that they really wish they'd paired more.
What is pair programming?
Pairing means two people working on the same code using a single computer. The latter part – using only one computer – is important, because pairing is about actively collaborating and not just two people working on the same project or sitting next to each other.
At any given time, one person will be the "driver" and the other person will be the "navigator." The driver is the one sitting in front of the keyboard actually typing the code. The navigator sits next to the driver and reads the same screen. The navigator is there to talk through ideas, direct the driver, and think about how the code currently being written fits into the larger project. You should switch roles (i.e., driver and navigator) regularly, minimally every two hours, and ideally even more frequently. Switching regularly helps with knowledge transfer, ensures that both people get to drive and know what's going on, and helps keep everyone energized.
Sometimes you'll hit a wall. For example, you could run up against a concept neither person understands, or not know what library is best to use for your project. In these cases, it's ok to take a break from pairing. If you do this, you should time-box it, e.g., "Let's spend 15 minutes on our own researching what the best library for this is, and then report back with what we've found." The important thing is to explicitly agree to take a break and set a specific time when you'll check back in. The one thing you should not do is pretend to keep pairing but really default back to just working next to each other. It's easy to do this and waste hours without even noticing it.
Another advantage is that the navigator can catch a lot of small errors immediately (typos, missing semicolons, incorrect variable names, etc). It's faster and easier to fix bugs the moment they're introduced than at any subsequent time, so this ends up being a big win. Plus, as the saying goes, with many eyes, all bugs are shallow.
Pairing is great for knowledge transfer and can help with everything from learning a language to picking up editor or command line tricks.
Also, it's fun!
One thing to consider before pairing
It's good to make sure you have similar (or at least compatible) goals before you start pairing. If one person thinks the goal is to learn Python, and the other thinks the goal is to fix a bug as quickly as possible, you can run into friction. Making sure you're on the same page or at least know where each other is coming from helps everyone get what they want.
Annoying stuff we debated including
We want everyone to be at Hacker School because they want to be here. And we want everyone to be happy, productive, and fulfilled in their work and time at Hacker School.
We don't want to (nor could we) enumerate every thing people "should" or "should not" do here. Instead, we prefer to assume everyone here is a responsible, respectful adult, and trust people to act accordingly and be able to work through differences as they arise.
Alas, people are complicated, and even reasonable people can have different ideas about what is respectful, and these pesky facts remain true despite our best efforts to simplify the world and abstract away the messy details of reality.
That's why we've included this section to lay out some broad expectations for how people will behave at Hacker School, and why they should (or should not) be here.
The first and most important thing: You should be here because you want to be here, not because someone else wants you to be here. It doesn't matter if that someone else is your parent, boss, or the President. Life's too short to be here for any other reason.
You should be here primarily because you want to become a better programmer and spend the majority of your time here programming and doing things directly related to programming.
So if you wake up one morning and realize Hacker School isn't where you want to be in your life right now (or isn't what you thought it was when you applied), talk to us! We won't be offended if it turns out we're not a fit for you.
Also, we all have trouble focusing at times. You will almost certainly have trouble focusing at some point during your batch. That's normal, but when you do, please try not to distract others.
Wait, this all seems really vague. Would you be more specific?
Well, we could ask you to pick up after yourself, be respectful of speakers, and keep conversations on-topic in Hacker School space during the day (i.e. if you want to take a break and chat about your weekend, go grab a coffee). But we think you all know that already. Just be respectful of your peers and act like the mature adults all of you are.
Struggling and mental health
Hacker School sometimes appears to be a place where everyone constantly has an amazing time, is perfectly productive, and instantly makes new friends. In reality, it's not always sunny. This section exists to acknowledge Hacker Schoolers' struggles and encourage everyone to seek support from the community for all kinds of problems and feelings. If you're considering applying and worried about any of these things, we hope you see this section as a show of support, not a deterrent to coming to Hacker School. Here are some of the things that Hacker Schoolers commonly struggle with.
Hacker Schoolers are sometimes lonely. They may have moved away from their friends and families to come to Hacker School, and making new friends here takes time and energy. They're sometimes overwhelmed by meeting so many new people. Hacker Schoolers sometimes feel guilty about spending time away from their children or other people they care for. If they have a long commute or a rigid schedule, they may feel excluded from after-hours social events.
Hacker Schoolers sometimes feel that everyone else is being much more productive than they are. (This is often a manifestation of impostor syndrome.) It's easy to see only the people who are doing particularly well, but in reality everyone's productivity ebbs and flows.
Hacker Schoolers sometimes struggle with the lack of structure. If you're coming from a more structured environment, expect this adjustment to be challenging at first.
Hacker Schooler sometimes struggle with mental health issues like depression. Smart, self-motivated people can have mental health issues, and there is no shame in getting support in dealing with them.
If you're struggling at Hacker School, you're not alone. You can reach out to facilitators, start a conversation on Hacker School's internal chat, or seek support from professionals. The Hacker School community wants to help you, whether you're in your first day here or your batch ended years ago.
Jobs, recruiting, and how we make money
Hacker School exists because companies pay us to recruit. Without this money, Hacker School could not exist, and if we're being completely honest, at any given point we are usually teetering on the edge of financial disaster (just kidding! Sort of). A lot of how we run Hacker School can be understood in the following way: We don't run Hacker School so we can recruit, we recruit so we can run Hacker School. Much of the world – mostly internet trolls – doesn't believe us when we say that. That's ok, but it's important that you do, and if you don't believe us now, we hope you will by the end of your batch.
(None of this is to say we don't want to make boatloads of money. We really hope to some day! At some point, Hacker School is going to need to make a heck of a lot more money than it currently does, if only to pay our employees market-rate salaries.)
So how exactly do we make money? Right now, we have recruiting agreements with a small set of companies, and for each Hacker School alum they hire, they pay us 25% of that person's first year salary, excluding bonus, as long as that person stays at the company at least 90 days. It's not always this simple – there are annoying special cases where we don't get paid or we get paid less than that – but that's the gist of it.
The way companies get introduced to our alumni is an evolving process. In the past, we've hosted a "job fair" where we've invited programmers from companies we work with to come talk about why their companies are good places to work. We usually provide dinner and drinks, and give everyone an opportunity to meet and talk with each other.
We also give companies we work with accounts on hackerschool.com. There they can see your profile and get in touch with you if they're interested in talking. Similarly, you can look at a company's profile on hackerschool.com and get in touch with them if you want to talk.
If the "visible to employers" checkbox is set on your Hacker School profile, companies we work with can see your info (GitHub, projects, etc). If you uncheck this box, you'll be invisible to employers (other Hacker Schoolers can always see your profile). Checking this box helps Hacker School significantly.
If you are looking for a job after Hacker School or as an alumni, we ask that you look through Hacker School first. Our survival depends on placements, and it costs nearly $12,000 for us to host each Hacker Schooler.
We generally encourage people not to think about jobs until the last couple of weeks of the batch. That's because when you start looking for a new gig, it can quickly become the top idea on your mind, which means becoming a better programmer won't be the top idea on your mind, which means you'll get less out of your time here. We host jobs events near the end of every batch where you will have the chance to meet company representatives.
(That said, if you're stressed out about jobs, or you can't get them off your mind, we're happy to chat with you earlier in the batch if you'd like. Just ask a facilitator or email the jobs team.)
Even if you don't go looking for them, job opportunities can and will find you during Hacker School. Friends will ask if you want to join their startups. Recruiters will contact you (some even specifically target Hacker Schoolers). Heck, even random people at meetups will try to hire you.
If you don't want a job after Hacker School, that's totally cool. But if you are going to take a programming job, either immediately after the batch or further down the line, please make your best effort to take a job through us. Hacker School's survival depends on it. If you’re an alumni working for a non-Hacker School company, we also ask you to consider this before actively recruiting Hacker Schoolers to work with you.
The short answer to "Can I bring a guest?" is no.
Our goal is to create a safe environment that is conducive to learning. Having unfamiliar people coming and going makes that harder, doubly so if they haven't been introduced at checkins.
There are four kinds of people you'll see at Hacker School other than members of the current batch: alumni, exceptional programmers who will enhance Hacker School (e.g., residents and speakers), hackers from companies we work with, and prospective Hacker Schoolers who we have explicitly invited. We do our best to announce guests ahead of time and make sure they're introduced at checkins, stay for the entire day, and know our social rules to minimize disruption. We will make exceptions, but only under unusual circumstances.
This might sound heavy handed, but it's not meant to be. If you have any questions about the policy, please let us know.
Alumni are welcome to come code for all or part of the day on Thursdays.
Alumni are also welcome at Hacker School in off-hours (anything other than 10am - 7pm, Monday - Friday). During this time, the Hacker School space is available for programming, and for social events. No guests are allowed, unless the event is specifically advertised as open to guests. Whether an event is open to guests is at the discretion of the faculty and will be announced ahead of time. There will be at least one faculty member at any social event that is open to guests and all guests must agree to follow the social rules.
As we ask of everyone at Hacker School, we ask that you work on open source software while you're here (i.e., don't work on proprietary code or code that you couldn't pair on or share with others). We also ask that you introduce yourself at checkins and on Zulip so that other Hacker Schoolers know who you are.
Additionally, alumni in from out of town are welcome to visit on other days if Thursday doesn't work for them. If you're an alum and have an upcoming trip to New York, let us know! We'd love to have you back.
Most alumni do not have keys to the space. A small number who have agreed to take on additional responsibilities to the Hacker School community have access to keys.
If you are in the current batch and would like to give your immediate family or significant other a peek at the Hacker School space, you may do so during off-hours. Please keep the visit brief, be conscious of the other people in the space, and accompany your guest at all times.
This section of the User's Manual has been modified for public release. In it, we talk about the various software and services we use to communicate. We've excluded the details because they don't give substantial insight into how Hacker School works and could conceivably cause headaches for us if they are revealed. We've included a summary below.
We use an unlaunched chat service for real-time communication during the batch. There is also a shared Google Calendar for events and various pieces of custom software we've written to handle all the little things that come up (RSVPs, dietary restrictions, etc.).
Everyone who attends Hacker School has access to Community, a private discussion forum for Hacker Schoolers. Community is used for announcements, discussion, and social events.
Community is private. The only people with access are Hacker Schoolers, facilitators, and residents. Content is not publicly searchable. While they may be online, the conversation on Community is akin to private talk amongst friends, so please use good judgement before sharing things people write there.
Please don't post job listings for companies that do not work with Hacker School.
This section contains the email addresses and phone numbers for all Hacker School employees, and is only visible to members of the Hacker School community.
A brief history of Hacker School
- Fall 2006. Nick and Dave meet during their Signals & Systems class.
- Summer 2007. Nick and Sonali meet at Shakespeare in the Park (Sonali is friends with one of Nick's coworkers).
- Spring 2008. Nick and Dave begin having "business meetings" after work to discuss starting a company.
- May 2010. Nick and Dave quit their programming jobs to start "OkCupid for jobs".
- June to October 2010. Nick and Dave live in Mountain View, CA and do Y Combinator. Paul Graham calls them "self-indulgent" for wanting to move back to New York.
- Fall 2010. Sonali starts working with Nick and Dave on weekends.
- February 2011. Sonali leaves her cushy corporate job and salary to join the team full-time!
- June 2011. Dave has a long talk with Paul Graham, Sam Altman and Paul Buchheit about a "school for hackers" and returns to New York ecstatic about the idea. We invite a small group of people to be part of an experiment called "hacker school" (we didn't capitalize it because we considered the name temporary – we weren't sure how we felt about calling it a "school").
- July 16, 2011. A third of the people who committed to doing the batch drop out two days before the start.
- July 18, 2011. The first day of "Batch" (aka the summer 2011 batch). The batch has only nine people including Nick, Dave, and Sonali, and is five weeks long. It's hosted in a small room at NYU with no windows. Alan is a Hacker Schooler and tries to explain monads to a very confused Nick and Dave. Sonali is the only woman.
- August 2011. John "workmajj" Workman suggests "Never graduate" as Hacker School's informal motto.
- September 2011. The second batch begins. We're hosted at Spotify in a slightly larger room with no windows.
- February 2012. The third batch begins with 20 Hacker Schoolers; Tom is among them. The batch is hosted at The Huffington Post. Danielle Sucher becomes the first Hacker School alumna.
- May 2012. We hire Tom and Alan as contractors to help facilitate the summer batch.
- June 2012. The summer batch begins with 53 Hacker Schoolers, among them are Allison, Zach and Mary. The batch is 45% women, and is hosted at Etsy.
- August 2012. Tom and Alan become regular employees and are joined by Zach and Allison.
- October 2012. Jessica McKellar, Peter Seibel, Alex Payne, Stefan Karpinski, and David Nolen are the first Residents.
- February 2013. We get our own space in Manhattan! The US government agrees that Mary is "extraordinary" and grants her a work visa.
- September 2013. We move to an nicer space with lots of natural light and no fruit flies.
- May 2014. To encourage traditions to persist from batch to batch, we move to overlapping batches.
- June 2014. We hire our first dedicated operations person, Rachel.
- November 2014. Allison goes west to join Dropbox: An unusual goodbye.
- – Initial public release.
- – Flesh out social rules.
- – Add contact information.
- – Add advice on text editors.
- – Add description of policy for space and modified guest policy.
- – Use "Hacker Schooler" instead of "student." More updates to guest policy.
- – Add translations section
- – Change fourth rule from "No subtle sexism" to "No subtle -isms" and flesh out explanation.
- – Remove ableist language. Update history of Hacker School.
- – Update with details of new mailing list system.
- – Add Rachel. Add struggles section.
- – Update with details of Community, which has replaced the mailing lists.
- – Additional notes for internal perks section.