Moving On From Hacker Schools

In a recent article, I expressed my concerns about the software industry's current methods of training and preparing new software developers to achieve proficiency in their professional work. Unfortunately, a great number of people immediately responded by pitting four-year CS degrees against self-directed learning or accelerated software development programs. My argument was not whether or not a four-year degree is a necessity for someone who wishes to become a professional developer. The value, and expense, of education is a complex subject -- a subject which, particularly in our current economic climate, has been repeatedly addressed by people with more experience in, and knowledge of, higher education.

To refocus the conversation, from my original article:

The question is not how existing courses of study fail to provide value, but how proficient developers actually do learn their skills.


The real question is how to provide a path from that open door [into software] to productivity and success. Many professions consider education programs - whether they result in a degree, a certificate, or a license - to be just the first step, followed by significant time doing real work, with dedicated supervision, and increasing autonomy based on performance.

Avi Flombaum, whom I quoted in my original article, seems to agree with me that we need to distinguish such a path:

Avi: Day 1, [Flation School students] start building something. After that, they're a developer, they may not be any good, but what else does being a developer mean besides building things? ...To become a great developer, that takes years.

Avi's comment clearly suggests agreement that novice developers need years to reach their full potential, but what exactly do those years involve? This is exactly my point. Imagine if we could shorten the time it takes a developer to reach their potential; if we could limit the impact of mistakes and inefficiency caused by their inexperience during their years of growth; if we could shave just one year off this learning curve from "not very good" developer to "great" developer. From carpentry apprenticeships to medical residency, mature professions have historically placed great value on the experienced teaching the inexperienced, doing real work with real clients. The classroom can prepare students to benefit from that experience; it cannot replace it.

Unfortunately, few, if any, software companies currently provide this type of mentorship. One reason is obvious: it has a high short-term cost. Businesses need their experienced developers building product, and they believe time spent mentoring inexperienced developers takes away from that goal. Unfortunately, a focus on short-term urgency causes long-term pain. As inexperienced developers struggle to learn on their own (or with limited mentorship) and the demand for developers rapidly grows, the supply of experienced developers shrinks in comparison. Businesses thus have even more need for their limited supply of experienced developers to focus on building product, compounding the problem.

A more subtle factor also contributes to the lack of effective mentorship. The software industry values highly technical and analytical thinking skills, generally to the exclusion of all else. Companies commonly emulate Microsoft and Google interviews, with their notoriously analytical questions. But an effective mentor needs more than just technical skills. Mentors need skills that software companies rarely, if ever, select for: patience, empathy, and communication. During the countless interviews I have had over the years I have never had an interviewer ask me to explain a solution to a problem in four different ways, reflecting four different learning styles, a skill expected for any teaching position. The unfortunate fact is that many senior software developers do not have the traits to act as effective mentors, and many more simply don't want to.

Avi Flombaum has suggested that Pivotal Labs should hire and train novice developers. Pivotal has some of the best developers -- and best mentors -- that I have had the opportunity to work with. However, Pivotal's business is high-end consulting; they provide a premium service for their clients, with rates that reflect that level of service. Suggesting that Pivotal hire novice developers is akin to suggesting that the Mayo Clinic hire classes of third-year medical students because it can provide a great learning experience. I'm sure the Mayo Clinic provides training opportunities, just as Pivotal provides a limited number of internships, but it is not their focus.

As it happens, I no longer work for Pivotal Labs, and haven't for well over a year. I currently work at Orchard, where my goal is precisely to provide mentorship opportunities. If Pivotal Labs is the Mayo Clinic, Orchard will be the Bellevue or Beth Israel Deaconess of software: an institution focused both on providing exceptional service and a learning environment where promising new developers can gain experience, learn from experienced mentors, and rapidly reach their potential while doing real work on real products for real clients with real challenges.

In addition, I hope to offer a new dimension of career growth for senior developers in a profession that has historically struggled with limited career paths. The software industry has a history of not valuing or rewarding the traits required for teaching and mentorship, but Orchard does, and will. And, just as public teaching hospitals have traditionally provided healthcare to the most underserved patients, Orchard aims to offer services to businesses that suffer most from the growing need for experienced developers: startups, non-profits, and foundations, especially those building unbuzzworthy -- but needed -- products.

I appreciate that the cause I'm championing will require a significant cultural shift in the software industry, and cultural change takes time. But, the fact that a thing takes time is not a reason to avoid it, nor an excuse for inaction. We know that aspects of the software industry change rapidly, and this is a new way for it to evolve. I hope both software professionals and educators will join the cause, for the benefit of developers, the businesses that employ them, and our increasingly technology-dependent society.