It's too bad that the term "hacker" has been exploited and redefined into something that has almost no resemblance to it's true and original meaning.
This Hacker School is essentially a training ground for startup programmers, focusing on everything from writing code to scheduling and managing expectations. This is a great idea, but it does not create a true "hacker".
A hacker de-assembles, re-assembles, engineers, and reverse engineers systems, on their own time, at their own pace, and is not motivated by profits and deliverables as much as the mere process.
But, I suppose if enough people re-define the word, then it must be.
This Hacker School is essentially a training ground for startup programmers, focusing on everything from writing code to scheduling and managing expectations.
I'm not sure where you got this impression, but this is definitely not what Hacker School is. We encourage students to work on projects and not "products" and certainly not startups. We especially encourage code that's written for other programmers to use (e.g., frameworks, libraries, command line utilities). We also focus purely on code and there's nothing at Hacker School about "scheduling or managing expectations" (that confusion might have come from our use of the word "shipping"? We use that to mean "getting code out and to a publishable state" because so many people -- ourselves included -- have a tendency do the first 90% of a project and then not put in the last bit of effort to put it on Github where others might benefit from it).
A hacker de-assembles, re-assembles, engineers, and reverse engineers systems, on their own time, at their own pace, and is not motivated by profits and deliverables as much as the mere process.
There are no profits or deliverables (at least in the traditional sense of the term) at Hacker School. We just build stuff we love and that we think will help us grow as programmers. For instance, last batch a Hacker Schooler and I wrote an Apple II emulator in JavaScript (https://github.com/nicholasbs/appletoo), simply because we'd never done it before. We also pair up and work through SICP, or do problems from K&R, or study different concurrency models.
As you state on your site, your revenue comes from recruiting programmers for startups. This fact suggests that you are highly incentivized to train startup programmers, not hackers.
"hackers" who don't meet deadlines, and don't manage product scope don't make very good recruits, which would affect your bottom line.
While on Hacker School time, it was made clear that startups are not the focus, and that we should worry more about the challenge of programming than building "Products".
I was in batch[1] and wrote a startup simultaneously in my non-HS time. One day I did a little work on it during HS hours and it was something of an open secret; we didn't talk about it, but we all knew it was happening, and it was clear to me that the consensus was that it was extremely uncool. Everyone is working together on projects, pairing or openly discussing things, and there I am sitting in the corner all by myself, keeping my work hidden. I wound up having to leave early or taking a day or two off to work on my startup during critical times (during the initial release), which made me feel like I was missing out on some HS time (because I was) and made working on the startup feel like a chore.
Yes we had a talk about a/b testing, but really that was just a talk about how to do interesting things with randomly assigned sessions, how to collect data, how to interpret the data, and how to build a system that takes action based on the data in a way that is both robust and easy to use. a/b testing is a step function for finding a local maxima based on some observable metric of user behavior over time. That's it. It's not some evil capitalist plot about manipulating user psychology with digital parlor tricks, it's an optimization strategy for improving user experience.
I don't recall a single HS discussion focusing on startup equity structures, legal issues, marketing, agile development, or lean startup methodology, but I do recall discussing generators in Python, the proper use of a JavaScript closure, the occasional Ruby vs Python argument, and how Scala's concurrency model differs from Erlang's (now that discussion went right over my head).
When we say shipping, we just mean that we have a show-and-tell every Saturday. During the show-and-tell, your project should be stable, it should show progress from the week before, and the code should be made available to the group. It's something of a weekly ritual at the end of every Saturday where we hang out, have a beer, and discuss our work. That's all we mean by shipping.
You willfully misrepresented what they're doing. "Focusing on everything from writing code to scheduling and managing expectations" sounds like How To Work For A Project Manager School.
It's obvious from everything they said that they're focused on writing code.
This Hacker School is essentially a training ground for startup programmers, focusing on everything from writing code to scheduling and managing expectations. This is a great idea, but it does not create a true "hacker".
A hacker de-assembles, re-assembles, engineers, and reverse engineers systems, on their own time, at their own pace, and is not motivated by profits and deliverables as much as the mere process.
But, I suppose if enough people re-define the word, then it must be.