The path to my graduation has been a long one. For almost a year now different people have been asking me what I’m going to do once I graduate. For the most part my answer has been that I’m focusing on getting to graduation, and I’ll handle the rest as it comes.

While probably not the most satisfying answer, it seems to suffice. The truth is, I’ve made enough of a plan that I won’t have to scramble for a job once I do graduate. I have an offer from Sage Bionetworks - the company that I did an internship with - to do some part-time contract programming for them. The pay rate is low for my industry, but it is a very livable wage. The plan is that I can relax and decompress from the madness of my final weeks at Western while working for Sage. It will be another Vacation. Then, when I’m ready, I can start to apply for a more long term position at a place of my choosing.

I’ve been ruminating on the different possibilities for where I’d like to work. By and large, I have set my sights high, and I have a short-list of companies that I would like to work for. I was content with this loose plan; that is, until a few days ago.

On Monday, April 14 I was killing time between classes by browsing the internet, when I stumbled across something called Hacker School. Now, the mainstream media may have given you an idea of what the word hacker means. Let me define how it is used in programming circles.

A hacker is not someone who breaks into computer systems for fun or profit. Those people are known as crackers and are regarded among programmers as the criminals that they usually are. To programmers, “Hacker” signifies someone who is very good at coming up with clever and interesting solutions to any sort of problem. Eric Raymond writes about the definition of a hacker in his guide, “How to Become a Hacker”:

“There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first time-sharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term ‘hacker’. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers make the World Wide Web work.”

When I saw the name “Hacker School,” I was immediately intrigued and needed to investigate. The Hacker School website self-describes the program as “like a writer’s retreat for programmers.” It is organized into three “batches” per year, where each batch is made up of roughly 60 people. A batch consists of all the people coming together to work in a shared space in New York City for a period of three months. The primary purpose of Hacker School is to help participants grow significantly as programmers. This is what they have to say about their pedagogy:

“…Hacker School is largely unstructured, self-directed, and project-based. That’s because we value internal motivation over external motivation, and self-direction over coercion. We believe people learn best when they have the freedom to explore their interests and passions, surrounded by friendly and intellectually curious peers and mentors.”

I had two major emotional reactions as I read more of Hacker School’s website: elation, and frustration. Both emotions were highly familiar to me. These feelings were almost identical to my first experience with the Teenage Liberation Handbook.

This last year has been a trial for me academically. I have taken the heaviest loads of my entire college career during these last three quarters. I have sustained my motivation to do this by remembering how near I am to completing this dreadful prerequisite to the rest of my life. When I started to understand what Hacker School was, some crucial part of this motivation broke.

Through my experiences during the time I took off after my junior year I managed to convince myself that I needed to finish my Computer Science degree in order to find work as a programmer. That conviction is part of what I was looking for when I took that time off. I was unsure how meaningful my degree would be, and that was preventing me from being fully committed. The difficulty I had simply getting responses to my resume, and what I learned talking to professional programmers, managed to convince me of the utility of finishing my degree.

Hacker School promises that there is a different path. Once again, I find myself in the position of asking “Why didn’t I know about this?” The synchronicity of this is amazing: I dropped all my classes just weeks after the second Hacker School batch began. If I had known about it, I might have followed an entirely different path.

What is it about our society that these less travelled paths are so invisible? In much of our literature and art we venerate those who take these alternate paths. Daniel Quinn unintentionally proposes a partial answer in his books Ishmael, My Ishmael, and The Story of B. The basic idea that he writes about is that the dominant culture in the world today is essentially formed around a single idea: that there is one right way to live.

There is a great deal more to his analysis. One of the most important pieces to me is that our cultural paradigm is such that we can be told by others how we should live, but it is taboo to try and discover it for ourselves. Why is that so? Does it have to be that way? Or can we as a society learn to continually re-evaluate what we are doing and how we are living?

These questions are a fundamental part of the way I am trying to live my life. They are my companions. My guides.

There is a set of practices in the programming world today that have become something of a fad. It is most generally identified by the name “Agile Development.” One of the original co-authors of the Manifesto for Agile Software Development recently wrote a blog post entitled “Agile Is Dead (Long Live Agility).” In it he describes the genesis of the Manifesto and how the word Agile has subsequently been subverted to the point of losing all meaning. Several times throughout the article he mentions the four values that brought about the original Manifesto.

• Individuals and Interactions over Processes and Tools
• Working Software over Comprehensive Documentation
• Customer Collaboration over Contract Negotiation, and
• Responding to Change over Following a Plan

Along with these four key values, the manifesto also contained a list of practices that the founders associated with them. The second value is the most directly tied to programming. Both the second and third values are fairly tied to the world of business and programming. But I think that the first and fourth values may actually be excellent guides for living in a more universal sense.

The idea of living in a world were we value individuals and interactions more than we value processes and tools is highly appealing to me. I think it’s telling to look at the people who develop software and seeing them develop these ideas. Most of what we do is to develop tools! I don’t even know how to explain how important I think the fourth value is.

Most importantly, with minor creative adaptation, the ideas that surround these two values are applicable to the way that we inhabit this planet we call home. I have many vague future plans for my life. I know that something I feel strongly committed to is trying to help change our modern culture from being so destructive towards the planet. This sounds like a big job. But, as my friend Garrett likes to keep saying “You have to focus on the things that you can actually begin to address.” I whole-heartedly agree.

There are three problems that I’ve been pondering during the last few years. First, many people who are in the business of programming have talked about how difficult it is to hire programmers. Particularly, how it’s really hard to hire good programmers. Second, I turned 18 and entered the world of work just a year or two before the “great recession” hit. One thing that I have noticed is that entry-level jobs in pretty much every field out there have disappeared. What has replaced them are internships; often unpaid. Third, during my time working as a freelance programmer, I noticed that there was a certain size of problem that is very awkward to try and solve. Large enough to require experienced developers, but not quite large enough to justify the resources required to hire the right caliber of professional.

These three problems have led me to the idea of creating a company intended to address all three of these issues. I call it the Code Academy. There are three core values that have guided my thoughts about how the Academy would work.

First, everyone gets paid. In the society we live in today it simply isn’t feasible for most people to do work without being paid. It’s also incredibly unfair. The flip side to this is that everyone should be paid commensurately to how much they are contributing.

Second, everyone will work on real projects. One of the most detrimental things about the Computer Science program at Western - and in universities in general - is that they invariably have students work on “toy projects.” By this, I mean a couple of things. First, the time students have to work on any one project is very limited. Worse, it’s limited in an artificial way, constricted by the bounds of a single school “unit,” whether that is a quarter or a semester. Second, because of the need for the university to rank students with grades, most code is written by only one student. Collaboration, a key component of all real-world programming, is actively disallowed under the purview of academic dishonesty. Finally, somewhat corollary to the first two, students get to write all of their code from scratch.

This is probably the worst of the “toy code” effects. In the professional programming world, far less new code is written. In general, there’s a rule that “code is read far more often than it is written.” A large part of any programmer’s job is going to be dealing with pre-existing code. Whether that will be in order to modify it to do something new, or simply to fix minor imperfections or “bugs” in it, most programmers spend a substantial portion of their time attempting to read and understand code that other people have written. This is simply not a skill that is taught or even given a cursory mention in the typical Computer Science curriculum.

The final core value of my Code Academy is that the best way to learn is to teach. I’ve been a mentor for the CS department for nearly four years now. During that time I have helped other students overcome a wide range of issues. Many of the problems that they faced were issues I never encountered in my own work. In addition, having to explain complex programming topics to people with little background in it has been a challenging task. I’m reminded by a quote attributed to Albert Einstein: “If you can’t explain it simply, you don’t understand it well enough.” The efforts I have gone through to try and explain deep and complex topics in Computer Science to novices and laymen alike has deepened my own understanding of those topics immeasurably.

In the context of the Code Academy, teaching as learning will play an extraordinarily important role. I see a system where as novices become journeymen, they immediately become responsible for mentoring new novices. This will help them solidify their own understanding.

This Code Academy is a long term dream. My conception of it is still nascent. Also, I don’t feel that I’m currently qualified, or prepared to undertake this particular journey. I still have a lot of growing to do, both as a programmer. This is actually one of the reasons that I am so looking forward to going to Hacker School. My Code Academy springs from a desire to address similar problems that the Hacker School founders are trying to ameliorate. But our approach is in some ways fundamentally different. I hope to learn a lot from how Hacker School is structured in addition to what I get out of being there as a student.

Afterthought

For the non-programmers in the audience, there is a small amount of symbolism in the numbering of the sections. Since most programs grow and change substantially throughout their life time, they are given version numbers to help both the developers and their users communicate about which iteration of the software is being used, or has a problem. These version numbers typically have the form of two or three integers separated by periods (i.e. “1.0” or “1.0.0”).

Each position has a specific meaning. The leftmost number indicates the “major version number.” This is usually started at 1, and then increases monotonically when major changes to the software are made. I saw a picture on the internet recently that illustrates the level of change I’m talking about quite well. To explain what changes were made for version 2.0.0 of some piece of software, the author said “Rewrote everything.” It is usually expected that users will have to repurchase the software in some fashion after major version increments.

The middle number is the minor version number. This is reserved for significant updates to the product. Typically minor version updates are the addition of minor new features or fixes. The final version number, which is often omitted in software for “end users” - as opposed to software that developers themselves use - is the patch number. This is used for when very small fixes to minor flaws need to be released.

The life-cycle of a piece of software starts out usually with either no version number, or with a version of 0.1.0. The initial zero for the major version means that this piece of software is still a work in progress that is evolving too rapidly to justify updating the version number every time changes are made.

_{The original formatting of this paper (written in markdown, compiled to LaTeX with pandoc and then into a pdf with pdflatex, all orchestrated by a Makefile naturally :) had no major sections so every section had a leading “0.”}