Why I Don’t Like Code Schools

28. September 2015 Uncategorized 1

Now that I’ve gotten you to click the link, let me be a bit more explicit: Why I don’t think code schools in the midwest are helping their students in their current iteration.  But see, that’s not as exciting and nobody is going to think “I have to read that.”

Language

Let me set the stage by being clear. I know of 3 code schools, and so this is based on my interaction with them.  What I’ve noticed, though, is that all 3 have something in common. First, their language of choice: Ruby.

I understand this choice. It’s a nice, dynamic language, that has a tendency to read like an English statement, or at least more so than C-style languages. The fact that it’s dynamic means it has some advantages, like being easier to test. Additionally, there is a lot of literature about how easily testable Ruby apps are (in practice, I understand, they’re don’t often take advantages of that feature.)

In addition to the nice features of the language, it has the advantage that other code schools are using Ruby for their curriculum. What that means is, there are curriculums out there that can be followed. Others have developed and iterated their curriculum, so if you were to start a code school today, you could theoretically borrow from one of those.

However, Ruby is also a problem for the code schools that I know of.  As I said, I know of 3 schools, these 3 schools are in 2 separate towns in the Midwest (Omaha and Indianapolis.)  I am way more familiar with Omaha than Indy, but I spent a bit of time talking to people in Indy recently, and what I found was what I’ve seen in Omaha. Ruby is not a popular language in either town. In Omaha, I know of two places that do a fair amount of Ruby development. Neither are “big” shops, which means they don’t have dozens of openings.  The “big” places in Omaha are predictably using .Net and Java.

Concepts

I can almost hear you saying “They just use Ruby to teach, but the students can get a job in any language.”  Which is a noble goal. It sounds like something a 4 year university would say. When I graduated back before the dot-com bubble, my school offered 2 languages that I know of, Fortran and C++. From talking to students now I know that they use Java a lot more now than when I went through. But the point, at least in my school, was to learn how to program. That is, understand pointers, and data structures, and numeric approximations, etc.  That is, concepts in computer science.  Turns out once I decided to turn away from hardware and focus on software, I actually did use C++, but it looked basically nothing like what I learned in school. For example, I never heard of STL in undergrad, but used it extensively on my job. I’ve also never taken a class in .Net or JavaScript and have used both as my primary developing language over the years.

So why can I apply that lens to myself, but not to the code-school students?  It comes down to this, my school did not ever promise me that I would land a job programming in C++. To be fair, I was getting a degree in Electrical Engineering, not Computer Science, but even so, they didn’t tell the CompSci kids that either.  But that’s what code schools promise, essentially, “Come do our course for 12 weeks and we’ll help you land a job.” That’s a lot to promise in 12 weeks.

One of my hobbies, as I’ve discussed here in the past, is Brazilian Jiu Jitsu (check out my CouchJitsu blog if you’re interested.)  In that martial art, you start by learning specific techniques.  For example, “How to do an arm-bar from closed guard”, then “How to do an arm-bar from mount”, then “How to do an arm-bar from open guard” etc.  However, there is a saying in that sport that I’ve heard “techniques, then concepts.” What it means is, you start with techniques, because you don’t know anything. So you learn the five steps to arm-bar from closed guard. Over time, however, you realize there is a concept of an arm-bar, and once you learn that, you stop focusing on steps and techniques, and instead focus on the concept of hyper-extending an elbow.

The same thing is true with programming. You can teach someone how to retrieve a database entry using ActiveRecord. Then you can learn how to do the same thing using NHibernate or PetaPoco or some other ORM.  Eventually, you understand the concept of ORMs and data access. Once you understand that, you can start more easily pick up different ORMs. For example, I’ve used no less than 8 ORMs in the past 8 years, because I understand the concept of ORMs.

I have not seen this practice with graduates from Code School. The graduates I’ve talked to understand ActiveRecord, and how to use it, and in some cases, how to test it. That’s to be expected, because that’s the dominant package in Rails, and it’s what they’ve been taught in their code school.

Assurances

This last area, I first considered calling “promises” but I’m not sure any of the code schools actually make promises. So I changed it to assurances. That is, the school assures their students that they’ll be more marketable after taking this course.

For the most part that is true. A lot of people are doing reboots, they’ve left career paths where they’re at a dead end. Which means that they’d gone as far as they could go. By starting to get into development, they’re giving themselves a much higher ceiling and that’s great.

But as I’ve mentioned, based on the language of choice, as well as how they’re taught (given their time constraints) they don’t have a lot of options, at least not in the two towns I’m aware of.  First, it is unlikely, at least in Omaha, that they’ll go to a software company writing Ruby. Not impossible, mind you, just not likely.  Additionally, because of the limited amount of time they’ve spent developing software (even at 50 hours a week for 12 weeks, it’s still just 600 hours of total development) they’ll often find themselves in Junior level, at best. That’s not 100% their fault either, but most employers will look at the things they have to still teach these graduates and be unable to bring them on much higher than junior level.  And to be honest, our industry as a whole fails in hiring people with little experience (even those that gradated from a 4 year degree.)

Solution?

So that’s a lot of complaining. What kind of solution can we come up with?  For starters, what if we chose a different language?  JavaScript is largely becoming ubiquitous. Further, it’s not just the client. A school could teach NodeJS for the server side, and still teach either vanilla JS or even pick a framework (Ember, React, Angular, Backbone, etc) and teach that on the client. That alone would make them more marketable, because even if they were unable to find a backend job, having JavaScript as a skill would open up a lot of doors for them.

The other thing that I could help is to work with more companies in the communities that the schools are in.  I know in Omaha there are companies that help out and mentor, but perhaps a different approach would be to land someone an “internship” at a company and then have them sent to the code school.

Overall, each student I’ve talked to, I walked away feeling as if they had the impression that they would take this course and find a job writing code pretty quickly. And from what I’ve been able to tell, that’s not happening.


1 thought on “Why I Don’t Like Code Schools”

  • 1
    Nick on September 28, 2015 Reply

    I think Interface was trying to do some of that. They had a C# program, partnered with a big employer in town, all that stuff. I’ve interested with a free OCS grads too that seem to “get it.” They don’t see themselves as top-end folks but they can do what they need to. I like your points though and have similar concerns.

Leave a Reply

Your email address will not be published. Required fields are marked *