I just read an interesting post by Rob Johnson called Why is Learning to Code So Hard?. With seven teachers in my immediate family and a little experience passing on what I have learned, this is a question I find really interesting.
One of the things that stood out to me was list list of “how developers spend their time”:
- Fixing bugs and making minor changes to an existing code base
- Adding new features to an existing code base
- Writing new software from scratch
- Refactoring (making a material architectural change to a code base without changing the functionality – very difficult)
When you look at that list, imagine the knowledge that is required to perform each task. Every one of them requires you to read someone else’s code and understand what it does.
Reflecting back on my own schooling, the emphasis was on writing; our assignments were little snippets of code in the language of the day. The other thing that stands out is that we never stuck with any language very long; a little C++, a smattering to Java, some Oracle style SQL, C# and two weeks of Perl.
I think I know why schools teach this way; businesses want people who write code and need their new hires to be flexible. Consequently the focus is on writing and you keep moving between languages to prevent a deep attachment to any particular one. The goal for the school is to produce a pool of fresh graduates that are going to pick up whatever is used by their employer quickly and without complaint without flooding the market in any particular niche. Turning out highly opinionated students who already wedded to the latest and greatest language/tool is not what most employers want from a school (unless maybe you live in Silicon Valley). Here in Ottawa most of the jobs are working with .Net, Java or Cobol (imagine learning Rails or Node.js in school and then landing a job at Revenue Canada only to realize they use Cobol!).
The problem here is that Rob’s list (and my own experience) suggests that most of the time what is required is to read code not write it. To me that indicates that learning to code might best be tackled as a literacy problem, rather than a complicated case of writers block. If that’s true the process should probably be: pick a language and read about it, and read code written in it until you have a solid idea of the mechanics of the language. Once you are able to read, then you can try your hand at writing. The drawback of course is that you won’t be able to avoid going deep enough into the language to develop an attachment to it which means a big school would be in danger of flooding a particular market.
I am pretty sure that anyone who teaches ESL or reading to kids would find the process we use to “learn to code” pretty strange; roughly the equivalent of teaching kids to read via writing short paragraphs. Focusing on literacy first would probably go a long way to addressing the barriers to learning that were pointed out, specifically the “leap in difficulty”.
While I think that there are certainly better/faster ways to learn computer programming than traditional schools I also feel like the recent wave of “0 to Rails dev” private schools like Rob’s MakerAcademy, App Academy, CodeFellows, GSchool and Bitmakers all rely heavily (probably to heavily) on the encapsulation of knowledge that tools like Git and Rails represent to ramp up students in such a short time. I suspect that such a method will probably create a crop of junior developers that are destined to remain junior developers.
While its certainly good for addressing a certain niche (like the current shortage of Rails developers) it will be interesting to see if what’s going on in those schools will make a broader impact on the field of education. In the mean time, my focus will be on code fluency.