Note: this article was first published on the Huffington Post Code blog [here].
In recent years, the popularity of accelerated software development courses has exploded. While this boom is due to the increasing need to fill empty development positions, I think it is also in response to a burgeoning desire to demystify a developer's path to proficiency. Four-year computer science degrees have not provided the needed skills; many successful developers have degrees in unrelated subjects, or none at all. The absence of clear alternatives to traditional four-year programs has generated a lot of confusion about what it takes to work effectively in software.
Rob: Some people have criticized the notion that you can become a developer in 3 months... How do you respond to that?
Avi: I think you become a developer the day you start building something. That happens pretty quickly at Flatiron School. Day 1, [our 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?
The final emphasis is mine. Employers who pay high developer salaries expect their developers to demonstrate skills beyond "can build things."
To become a great developer, that takes years. But to become an efficient developer, or a productive developer, 8-12 weeks sounds about right.
Most people would agree you can learn to write software in twelve weeks - just as you can learn to play chess, paint with watercolors, or immobilize a dislocated shoulder. But how long does it take to become a chess master, a painter, or a medical provider?
...this isn't casual.... It's like 700 hours of coursework. How many Computer Science classes do you end up actually taking in a 4-year college? ... And they meet 3 days a week for 2 hours...?
The real issue is: What content does a four-year degree lack that an accelerated course provides in only three months? I don't know where Avi went to school, but my college classes required work outside the classroom totaling significantly more than 700 hours. If accelerated courses simply provide the same basics as college degree programs (without the less relevant theoretical topics and pesky humanities requirements), then it leaves graduates at least equally unprepared for professional development work.
The question is not how existing courses of study fail to provide value, but how proficient developers actually do learn their skills. Many experienced developers will tell you that they learned by making a lot of mistakes. In the best of cases, a more experienced developer helped to identify and explain their mistakes; in the more common cases, they simply made the same mistakes over and over before learning the lesson.
Learning from failure is not unprecedented, or even unusual. After graduating from college (with a degree in computer science), I shelved my diploma and worked for a couple years as a street paramedic. The paramedic school I attended required more than four times the classroom and practical time than the program Avi describes. Regardless, EMS providers know that newly-graduated medics are next to useless, so they pair them with senior medics. The mentor's role is to identify or anticipate the mentee's mistakes, mitigate or prevent them, and make certain that the mentee learns the necessary lessons to prevent them from happening again. The mentee's goal is to show that they can learn these lessons, and become more than useless within an acceptable period of time. Even those who excel in the classroom can fail to meet this bar.
A paramedic's job, while stressful, is reasonably straightforward. My job as a medic was to deliver patients to the hospital quickly, dealing with any immediately life threatening issues if possible. A medic's skills and knowledge are narrow and focused: treatment options limited; patient interactions measured in minutes; team size only two. Medical providers with significantly more training handle the processes of diagnosis, repair, recovery, maintenance, and prevention - some of which are measured in years.
Contrast this with software in which you cannot simply hand off your paperwork and move on. Developers need to build things that will grow, change, and continue to provide value. Developers have to work on teams with other developers without duplication, misunderstanding, or strife. Developers need to know existing tools and libraries, how to solve problems without existing solutions, and how to tell the difference. The opportunities to make mistakes are myriad.
I don't think that people who criticize (The Flatiron School) like that are really thinking about it carefully.
I think it's entirely reasonable to say that Flatiron School provides value and opens a door into the software industry; although, no one has proven whether their program does so more effectively than traditional programs. The real question is how to provide a path from that open door 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. In contrast, software developers take years to learn from mistakes they don't know they're making, each learning the resulting lessons - or incompatible variations thereof - individually. This is enormously redundant in a profession that frowns deeply on duplication of effort. We can dramatically improve the learning process with dedicated mentors who identify, prevent, and explain mistakes as they happen.
Lack of mentorship delays new developers' progression from beginner to journeyman, stunting the growth of their professional value, and generating attrition due to frustration. The overall ratio of beginning developers to proficient developers defines the average proficiency of the software development industry as a whole. As the demand for new software developers continues to grow, the growth of the ranks of beginners will outpace progression to proficiency, causing an industry-wide drop in productivity. We cannot tolerate such a step backward, as software continues to grow in demand and importance.