Trial by Fire

After several weeks of dreaming big and working through some conceptual difficulties, we Praxis fellows have returned to the concrete task of learning to code and program.   Currently, we are wandering our way through the world of Ruby on Rails.   It has been a while since I have had the opportunity to learn something completely new, and I’m finding the task both disorienting and rewarding.  Given that some of you out there might be experimenting with your own training programs, I thought I would take some time to discuss the approach to teaching and learning that we have been using.

Generally, I am not a fan of trial-by-fire method of teaching.  I was the kind of kid who learned to swim by practicing strokes in the grass, not by jumping head first in the water, figuring it would turn out all right.  I like to proceed methodically, slowly building up a familiarity with vocabulary, concepts, and skills.  Theory before application.

Given my preferred learning style, I was perfectly content when Wayne began the first lesson on Ruby, providing basic concepts, definitions, and reasons for choosing Ruby over other options.  But 20 minutes later, I was feeling pretty lost.   It wasn’t so much that the concepts or vocabulary were difficult—it was that I didn’t know what language we were speaking.  I had no grammar to help provide context, and I had no real world experience upon which I could map these new concepts.  So, even though, for example, definitions of the difference between a “language” and a “framework” were provided, those definitions were largely meaningless.

But luckily, the wise staff here at the scholars lab (read: Wayne) knew that we needed to pair our theory with practice in order to really make sense of Ruby.  We were sent to Learn Ruby the Hard Way to complete a series of exercises.   This ebook is arranged in the trial-by-fire manner.   Rather than explaining Ruby and following it up with practice, the user is instructed to copy code and then run the program to see what happens.  No explanations of commands are provided, just questions for the user to answer.    To my surprise, this was an incredibly effective way to learn.  I had to examine the commands and the resulting printed screen to figure out how the commands worked for myself.  At the same time, I was building muscle memory for frequently used commands and processes.   My hope is that learning to program in this way will help me to learn at a deeper level—really retaining the skill rather that “cramming” the information only to forget it later.  However, this learning method has its downfalls: there were several places where the exercises themselves do not clarify extensively enough how a command works or how it is distinct from another command.  Luckily, we have the Scholars Lab staff to fill in these holes, and after a subsequent session with them, I am feeling pretty comfortable (for now).

So, what have I learned about learning:  I am finding a new appreciation for the trail-by-fire method.  You learn differently and have to think deeper when the answers are not simply given to you.  It is no longer about memorization or referencing a guide, but about experiential knowledge.   At the same time, I find there is value talking theoretically and having face-to-face conversation with experts and teachers, especially when paired hands-on experience.