Ruby on Rails on Udemy: A full stack!

If you have read some of my previous posts, you may recall that I dabbled in Ruby and Ruby on Rails a couple of years back. When I first began, I was quite enamored with the online learning platform offered by the Flatiron School in NYC. But that was when I tried out their free platform to learn Ruby. I had no idea what Ruby was good for, but I had heard about the Flatiron School, so I was interested in how they were teaching programming online. After a few weeks learning Ruby, I was hooked. So I decided to become a paid student, thinking that would open up additional resources that would help me learn–I wanted to see what the “full stack” was all about.

What happened was a bit confusing. As soon as I became a paid student, I no longer could access my previous “tracks”– I couldn’t continue whatever lessons I was working on. Instead, the full-stack lessons started with html and css. Then there was some Ruby exercises. Then Ruby on Rails. By the time I began Rails, things had started to shift at the Flatiron School–at least it felt that way. Help was hard to come by; the lessons began to feel not as fully developed and the transitions between units began to feel a bit rough. I stuck with it, mostly because I didn’t want to feel defeated– and partly because I wanted to get my money’s worth. And I had paid a good chunk of change for the massive headaches for wanting to go “full stack”.

The worst part was: I never understood what this full-stack business was about. Ok, I knew html and css dealt with the front end, the part that visitors to a webpage would see. So what did Ruby have to do with it? What did Rails have to do with it? And, despite having gone through some of the more complex units, I never knew where I was headed and how all of the ruby code would become a webpage, let alone a website.

As it turned out, I was one of the few people who hanged on to Flatiron’s online program – they had made a strategic decision to move away from it. To their credit, they didn’t shut it down but continued to let fools like me hang on. It must have been a relief to them when I quit. It certainly was to me–paying money only to get stuck on some idiotic code that who knew what was for made no sense, certainly when I got little help.

So in contrast, the $11 I paid, completely on a whim, for a Ruby on Rails course in Udemy, seems a ridiculously good bargain. So inexpensive, in fact, it could have easily been a “gag” purchase, like one of those exotic sounding pre-made meals that one gets for the heck of it–not much to lose if one didn’t like it.

Well, was I mistaken!

In terms of value, this was perhaps the best $11 I’ve ever spent. I’ve gotten every penny’s worth out of the $11 – and then some. And I feel guilty for having paid so little — and got so much in return.

I am at Lecture 215 out of  236 in the course called “The Complete Ruby on Rails Developer Course“, taught by Mashrur Hossain. For the first time, I understood the connection between Ruby on Rails and a working website. I understood how Bootstrap works. I learned, not long after starting, how to deploy a Rails project, and how to deploy a web app with a built-in authentication system. Lecture 213 and 215 are about setting up e-commerce to receive payments on a website.

In all my previous attempts at Ruby or Ruby on Rails, I’d get hopelessly stuck halfway, usually due to some idiotic user error that the user, me, couldn’t fix. So far, this hasn’t happened with this Udemy course. When I did get stuck, a tip or two from a teaching assistant (Evgeny) would get me moving again.

I have not researched on Mashrur Hossain to find out who he is, but, to me, he is one of the best instructors there is–well, I’d like to think Dr. Chuck is the best (he is!). I had exchanged a brief message with Rob Percival on a different topic, decided to take one of his courses (which was on sale). After I had signed up, I discovered it was taught by Mashrur Hossain. Thinking I had made a mistake, I almost backed out of the course. A short preview clip caught my attention, and $11 wasn’t that much, so I decided to watch a few lectures. And the rest, as they say, is history.

Advertisement

What Will Be Your Technology “Waterloo”?

My son once asked me a while ago whether I’d ever see myself be left behind by technology. My response was, “No… because I’ll always be learning new things.” His question was a fair one. My grandmother used to need help to make a phone call — on one of those old rotary phones. Granted, there was only one telephone in our neighborhood and most people hardly made any phone calls. Grandma was uneducated and in her early 80s, so technology-the rotary phone-was confusing. But I’ve used grandma as an example to illustrate the point that sometimes technology could advance so rapidly that some people wouldn’t be able to ever catch up.

One may laugh at my grandma, but for most of her life, grandma was one of those ahead of her time: When she was young, her father, a merchant, was traveling back and forth between her village and wherever he was doing business in northeast China. He would bring back facial creams–something village women barely heard of. Grandma also traveled occasionally to Harbin (northeast China), so in her village, her family were viewed with awe. When she moved to Beijing, she quickly adapted to the city life. She figured out how to read the numbers and characters on money and food ration tickets and how to make herself look fashionable, with the limited resources she had.

But the rotary phone became a permanent roadblock for her. She knew the numbers. She knew how to turn the dial. But she never quite got over the confusion and nervousness to pick up the phone and make a call, even after our family got our own phone installed.

(For those who aren’t familiar with rotary phones, here’s an example from “The Museum of Obsolete Objects”. And here’s a video teaching people how to use the newly released rotary phone.)

laobc-Very-simple-rocket-300px.png

Some will say, you can’t predict the future–How will you know what your permanent roadblock–my technology Waterloo–will be. I do try to dismiss such anxiety provoking queries: Oh yes, I have been learning and keeping up: I learned a bit Python, a bit Ruby; I learned how to use the git commands–not bad for someone whose career exclusively deals with reading and writing and languages. Plus, I am trying still to figure out Reddit–but did I tell you I think I more or less have understood Twitter?

Truth is: I know I have already met my “technology Waterloo” (“techloo”?). It’s called SnapChat. SnapChat is where I have drawn a line and taken my last stand. Of course I tried SnapChat–several years ago shortly after it caught on, my kids convinced me to try it. So I did, but gave up after a few minutes. The problem was simple: The image flashed on my phone screen so quickly that it disappeared before I could focus my eyes on the screen (those were the days when I didn’t have to use dedicated reading glasses.)

ppl-snap_laptop_sml1-e1516918835135.png

So the roadblock was real–using SnapChat was something that strained (if it wasn’t entirely beyond) my physical ability. In the split second when an image is displayed on the screen, people in their late teens and early 20s see the image, get the joke (or the point), and return a comment or two–while I am still focusing my eyes.

Sure SnapChat was built for young people–perhaps intentionally to exclude the 45+ crowd that have made their D-Day landing and invaded Facebook. But even if I could extend the display time long enough for my eyes to focus, will I be able to make use of–much less to enjoy–SnapChat? I am not sure I can get all the meaning a SnapChat image conveys. (HELLO English major! What happened to your ability to uncover and analyze overt and covert meaning in any text?)

snap_pills.png

If, unlike me, you have conquered SnapChat, have you met your technology “Waterloo” somewhere else? I am asking because, as an educator and a learner, I’d like to think it just might be possible to predict and identify the roadblocks to one’s learning – and apply an antidote, like how we use antibiotics on infections.

Some of the graphics are from OpenClipArt.org.

©YUMEI LEVENTHAL AND CODE BY LINE 2016- ALL RIGHTS RESERVED.

 

Hello World!

I’d like to take this opportunity to mark a special occasion in my life: Wednesday, September 1, 2016, my son, the younger of my two kids, began college. Thus I have concluded the most massive undertaking of my life: raising my kids. I know my role as a parent does not stop with college; nonetheless, I feel I have accomplished the most important task: To ensure my children grow into adulthood.

My own father died at the age of 49. I was several years out of college by then, but my younger brother had turned 18 only a few months prior. My father had always worried he’d die before my brother turn 18, so it must have been a relief for him that he’d lived long enough to see that happen.

So in my mind, it was always important that my kids would grow into adults before I die. I remember a tragic event in the 1980s, way before I had kids, in which a 6 year-old pilot (presumably a pilot-in-training) died while flying an airplane with her father on board. The kid’s stoic mother said few things publicly, but of the things she did say on TV, she said the child had died doing what she loved.

I remember feeling furious with that fool of a woman (and apparently many other people did too): What did this 6 year-old know about what would make her happy? Did she know about the excitement of starting college? Did she know the thrill of falling in love? Did she know the joy of having children of her own?

I became convinced that one of the most important goals in raising children was to ensure their safety and survival. Everything else comes after. When my kids were young, parenting books were the new rage. The hottest topic was how to raise happy children. Many preached the gospel of allowing a child maximum freedom to explore and experiment; Dr. Spock was considered too severe a disciplinarian. So what if kids got hurt while exploring? They learn from experience. So the advice went. Of course no one went so far as to say “let your child take risks with his/her life”, but taking risk was considered a virtue.

Needless to say, that child-rearing philosophy didn’t sit well with me. I remember thinking: These people who were dispensing such foolish advice must have never experienced loss – or even adversity – in their lives; they were like the mother of the 6 year-old pilot, believing gratification was the ultimate reward.

Obviously there is more to life than just the need for survival, and justifiably so: When I was a kid (in China), few people lived past 70. In the Western world today, the long lifespan is taken for granted, and so there is plenty of time for other pursuits in life than survival.

Still, for me, 28 years after my father’s passing, it is still an incredible milestone to see my youngest child turn 18, go to college – and to be alive and well myself.

It has not been an easy 20-some years. So now one chapter of my life has come to a close. Whatever is left of my mental acuity will be all mine. Yes, I did promise to take care of my cat and dog and keep them entertained. Other than that – Hello World! and I mean it!sunset_pano

My MOOC Explorations Continue

It’s been a few months since my last post. That’s because I got totally immersed in learning coding, specifically Ruby, far more seriously than I had expected. In the last two months, I got very sick. But now I am back.

First of all, the Capstone Python class on Coursera got postponed from a January start date. It finally started in early April and I have completed it and thus completed the excellent 5-course Python series, taught by Prof. Chuck Severance of the University of Michigan.

While waiting for the Capstone class to start, I stumbled upon the Flatiron School‘s  Learn platform which I really enjoyed and wrote about in my previous blog. In no time I found myself being pulled deeper and deeper into Learn. In February, I formally signed up as a fee-paying online student on Learn and have put in a good amount of time everyday (until I got sick.)

Like many of today’s online teaching / learning platforms, Learn has also been going through continuous changes. So not everything is 100% smooth – but then what is 100% trouble-free in life? The bottom line is: I have learned a tremendous amount through  Learn. I will write about it in my future blogs.

This entry is in response to Learn‘s assignment question: “Why did you decide to learn software development?”

It may be a while before I will call myself a “software developer,” but I am getting to understand what “software development” means. Computer technology permeates our lives, so we should, and we must, gain some basic understanding of how it works. Programming languages are also (surprisingly) interesting – so why not learn some programming? In a previous post, I argued that every teacher should learn to code a little. I have come to believe everybody should learn some programming, because, as Massimo Banzi, the creator of Arduino, succinctly said:

… it’s important to be masters of the technology.”
– Massimo Banzi –

Differentiated Instruction & the Flipped Classroom

A good teacher often anticipates difficult patches in learning and structure lessons accordingly. In the best case scenario, the amount of time devoted to course materials commensurate with the difficulty level.

My years of teaching have given me plenty of insights as to what particular assignment or exercise would cause the most headache. Still, if I have to convey anything to a new teacher, it is that the difficulty level of any given material cannot be “hard-coded” (to borrow from computer jargon): What is hard for one person may barely require any thought in another.

“Differentiated instruction”, therefore, has a great appeal. It holds great promise for teaching according to individuals’ intellectual ability. In the hands of well-trained teachers, differentiated instruction helps mitigate some of the issues our schools face, with large class sizes and wide range of preparedness among students.

I have been a fan of differentiated instruction, until now.

Having taken a few self-paced online programming classes (CodecademyCoursera, EdX, Flatiron) and observed how my fellow students – adults from different parts of the country (sometimes different parts of the world) – navigate different lessons along the way, I have come to see a fundamental fallacy in differentiated instruction.

The success of differentiated instruction is premised on various pre-conditions, including teacher training and institutional support – both should be there before implementation.

The onus of the task is entirely on the teacher, who must, in addition to identifying individual needs, devise plans to address such (often wide-ranging) needs.

In a traditional instructional environment, there is no way anyone, however, brilliant, can teach a class on such a massive scale as someone on MOOCS, such as Dr. Chuck Severance (University of Michigan) on Coursera. Even with MOOCS usual high attrition rate, “Programming for Everyone” had at least 50,000+ students completing the course. Yet, even a newbie like me, with no background in programming, was able to learn a huge amount, complete the course, and thoroughly enjoy it at the same time.

That is because, in the online learning environment, each learner must figure out her own way of grasping the course material – turning differentiated instruction on its head, making the process “differentiated learning” instead.genie_lamp-21st

There is your “flipped classroom” in flesh and blood!

 

 

©YUMEI LEVENTHAL AND CODE BY LINE 2016- ALL RIGHTS RESERVED.

A Dabbler in MOOCs

Ruby_Python_ed1

My accomplishments so far on Codecademy.

As of last night, I have completed as many Ruby lessons on Codecademy as Python lessons. Allow me to explain why this is significant.

I may be a “recreational” coder, but I am also a highly motivated learner. I may not know what I will do with my knowledge when I reach a certain level, but as of now, my objective is to learn as much programming as I can. Specifically which programming language I learn is of less importance. At this point in my life, not much stands in my way when it comes to learning, which is why self-paced, open platforms (such as Codecademy) makes eminent sense. Assuming the curriculum is well designed and engaging enough, I can see myself taking course after course. So I am very much an excellent test case on MOOCs retention.

Python badge1_edited

My very first Python badge from Codecademy.

I earned my first Python accomplishment badge on Codecademy way back in March 2015, nine months before I started on Ruby. When Codecademy lessons became impenetrable for me despite my dogged effort, I switched to Coursera to continue learning Python. My only goal on Coursera was to learn enough Python so that I could finish what I had started on Codecademy. As it happened, my Coursera Python class was taught by Dr. Chuck Severance. I loved Dr. Chuck’s class so much that I subsequently took more of his classes: “Internet History and Security” and more Python. I did return to Codecademy, finished the lesson that had stumped me (thanks to my Coursera course) – and then some! Let me tell you: That 70% accomplishment in Python was earned tooth-and-nail by a very determined learner who was simultaneously using two competing delivery platforms.

This all happened before I embarked on my Ruby journey using the Flatiron School’s Learn platform on December 1, 2015. Python was the only programming language I knew and I liked what I had learned. In fact, it never occurred to me that I’d be learning Ruby when I started on Flatiron. . So what happened?

Not much – not on Coursera at least, and that was the problem.

In the summer of 2015, I noticed some changes in Coursera. Among them were courses tagged as “Specializations”, which clustered groups of thematically related (free) courses along with a capstone course. One could still take the free courses individually, but in order to get the certificate, one must sign up for the Specialization series. And pay. Dr. Chuck’s Python class got rolled into a Specialization. Because I enjoyed Dr. Chuck’s class so much, I signed up for that Specialization. I had to warm up to the idea of signing up for a series of courses¹, but that was not a problem for me.

Then, there were other issues with Coursera during the summer. It took weeks, for example, before my enrollment was cleared. Apparently Coursera‘s new and improved platform did not make provisions for the “transfer credits” that they had promised to people who had completed prior courses. The discussion forums changed, too. I was no longer able to see all my own posts with an easy click–and therefore it was hard to see others’ responses (unless I scrolled through a lot of other posts). These were minor issues, but annoying ones. Students grumbled, but in the end, because we all liked Dr. Chuck, we all acted like good sports and carried on. After all, how many courses are taught by a master teacher with talents to match? Very few.   

It is worth noting, though, that this all took place during summer 2015, a time when schools were not in session, but precisely the time that learners such as myself, “dabblers”, were able to have a little “summer fun” by taking online classes. Bad timing. But I had enough good will towards Coursera that I was willing to put up with their growing pains.

When I finally was able to re-join Coursera in late for the second half of the Specialization courses, I went in with gusto. By mid November, I had finished “Using Python to Access Web Data” and “Using Databases with Python“. The scheduled start date for the capstone course was January 2016, perfectly timed for me to enjoy Thanksgiving and Christmas.

Then, sometime around late November, the start date for the capstone course was postponed to February. Not long after that, the date was changed to March 2016.

So what is an earnest and motivated learner to do? Sit around and twiddle her thumbs?

Turned out: No worries – not in the era of many MOOCs. The Flatiron School now had my full attention. The Flatiron School’s Learn platform turned out to be excellent. As soon as I began, I realized that it was going to be different. For that reason, it barely mattered that I’d be learning Ruby. In under two months, I have learned more Ruby than I thought possible – and without master teachers or any taped lectures.

Periodically, I go back to Coursera to check the course status. When the class begins – if it ever does, I shall devote myself to it. I am certain the capstone course will be just as good as all of Dr. Chuck’s courses. I only hope I will remember enough Python at that point to still enjoy the course.

So if you look at my official records, you might surmise that I bailed out on Python. Given MOOCs’ high attrition rate (between 90 – 98%)², no one would consider this unusual. But the fact is: I did not drop out. If I had to put my experience into a narrative, it will go like this, “I went to class at the appointed time and location, but there was no class. So I went to another class.” 

The professor, Dr. Chuck Severance, is a seasoned professor – I can’t imagine him being the one holding the class up. So what happened, Coursera?

 

Notes:

¹ To be fair: Coursera gave people credit for being a fee-paying student in Dr. Chuck’s previous Python course, so when Dr. Chuck’s Specialization series began, people like me  had already completed half of the courses.

² Check out this article by Harvard University researcher, , titled “Learner Intention Recasts “Low” MOOC Completion Rates”

©YUMEI LEVENTHAL AND CODE BY LINE 2016- ALL RIGHTS RESERVED.

Digitization and Losing the Art of Research

I’d like to deviate slightly from my usual theme, and comment on Research. Capital “R” research. On the January 22, 2016 article in The New York Times Book Review titled “Under No Certain Search Terms,” which is about the importance of archival research NOT mediated by the keyword search process which is part and parcel of using digitized archival materials today.

Janice P. Nimura argues that digitized archival material is helpful, but it eliminates the “serendipity” of simply browsing through archives and discovering unique, interesting, and important information that otherwise would not have been available to a researcher because it is not tagged with certain “keywords.” As Nimura succinctly puts it: The problem with keyword searches through archival materials is: “You find exactly what you’re looking for, and nothing you’re not.”

Unfortunately, as more and more archives get digitized – making possible unprecedented access to these archives, we are also missing out on the incidental discoveries, the serendipity of it all, that make research interesting. Worse, these skills are often not being imparted to the next generation of researchers.

When I was teaching freshman composition at the University of Cincinnati a few years ago, I assigned a series of exercises that took my students through the first few steps of doing real library research. One of the exercises required that students read through a newspaper published on the day they were born. Until the late 1990s, in order to read newspapers from 18 years earlier, students would most likely have used a microfilm reader, a cumbersome machine into which one fed a reel of microfilm and which projected an enlarged (and hence readable) image of the microfilm’s tiny (35mm) frame.

https://commons.wikimedia.org/wiki/File%3AMicrofilm_of_Toowoomba_Chronicle2.JPG

Microfilm reels. By Lhsunshine (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia Commons

https://commons.wikimedia.org/wiki/File%3A2004_microfilm_reader_1117365851.jpg

“In the Wroclaw University library” By David Lisbona from Haifa, Israel (Reading Brilling’s book about Jews in Silesia) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)%5D, via Wikimedia Commons

 

 

 

 

 

 

 

 

This was one of those assignments that few students took seriously at the beginning, but which would result in many students to come back totally ecstatic about the incidental tidbits they encountered in the research process. Some things they found curious, others profound: The cost of a microwave in the 1980s, the style of clothes in the advertisements, the name of a family member or a friend appearing in reports on local sports events, national or world events that corresponded with their birth… Inevitably, a few students would complain about the difficulties and frustrations of using the microfilm machine. But enough students loved the experience each semester that this particular assignment became a staple in my English 101 classes.

Eventually, digitized versions (i.e. with searchable text) of old (and recent) newspapers became available. Microfilm readers then began to disappear along with, of course, millions of reels of film. I made a point to tell my students that the microfilm version of a newspaper, which photocopied EVERY single page of a newspaper – advertisements and all – was the closest thing to reading an actual paper, and that they must not use the digitized online version. When a student did – they had to submit a copy of the front page of their chosen newspaper, I’d make them re-do that assignment. It was a painstaking process, but the reward was so rich that I braced myself each semester to deal with the “hassles” of having to explain to students, over and over again, why it was important to use the microfilm.

Around 2008, shortly after assigning this project again, I received an email from a university librarian, politely asking whether I was aware that the library had digital versions of many newspapers, and that students could very easily print out any article they wanted through a simple online search. A few students told me that librarians had shown them a more “efficient” way of using old newspapers.

It was obvious to me that some librarians thought I was a Luddite, an antiquarian who was unwittingly tormenting her students. So I wrote a long (carefully worded) email to our librarian to explain why I insisted on the use of microfilm.

The following year, I met with a librarian prior to the assignment, in order to head off another misunderstanding. The librarian informed me that the university library was well on its way to completely eliminating its microfilm collection. What are they going to do with the reels of microfilm? I asked. Unfortunately, they will be trashed, she said. The microfilm readers cost a fortune to maintain and storage for the microfilm reels, along with the readers, took up valuable space in the library. So out they went. Libraries all over the country were doing the same thing.

But don’t worry, my librarian said, everything is available in digital form, which is even better, because you can do searches.

I couldn’t help but making one last-ditch effort to plead the case for microfilm – to someone with absolutely no say on the matter – for the preservation of at least one microfilm reader.

I continued with watered-down versions of the assignment for a couple more years. Keyword searches go through the mediation of search algorithms which separate the researcher from the primary material – and from the thrill of incidental discoveries and the serendipity inherent in archival research. If one must do keyword searches, there is little justification to make students go through the extra steps when a simple Google search accomplishes exactly the same thing, and far more efficiently.

Now that I have learned a bit of programming–especially after the course I took with Dr. Chuck Severance on Coursera on using SQL to query data, I have come to appreciate the power of computer programs penetrate, manage, and give shape to large amount of data. Perhaps one day, artificial intelligence will advance to such a degree that machines can explain the meaning of data as well. But will a machine experience the joy of discovery? Will it squeal in a fruitful accidental encounter – if it is ever capable of accidental encounters?

“Sometimes the telling detail — the yeast that makes the whole lump rise — isn’t in the headline you’re reading. It’s in the gossip column on the next page, or in the classifieds tucked in the back.”  – Janice P. Nimura in “Under No Certain Search Terms”

P.S. The research assignment discussed above was one of the gems from my mentors at the Freshman Writing Program at the University of Maryland, College Park. Thank you, Gene Hammond!

©YUMEI LEVENTHAL AND CODE BY LINE 2016- ALL RIGHTS RESERVED.

Problem-based learning – what I learned from Learn.co

As I have stated repeatedly in other articles, I think it is worthwhile for language teachers (or teachers of other subjects, for that matter), to learn computer programming. For one thing, one may be surprised, as I was, by the sheer amount of creativity and collaborative effort among programmers, as well as innovative approaches used to teaching people to write code. Over the last year, I have taken numerous courses offered by Coursera, Codecademy and The Flatiron School’s digital platform Learn (as part of their “Prework”.)

One learns coding by coding, just as one learns language by speaking. On most learning platforms for coders, the pedagogical process is built in discreet parcels, with specific goals, targeting specific skills. This is all familiar terrain for most language teachers (be it French, Chinese or Esperanto). What may be different, however, is how the actual learning takes place, in the absence of “teachers”¹. On both the Codecademy and Learn, students participate at no cost and are self-paced. There is structure, however. Students must progress sequentially through the lessons. Operating in the background is an automated program, which assesses each student’s code as a pass or fail. If the student’s effort is a “fail”, an error message pops up, listing the reasons. Students who wish to progress must closely read and understand these error messages, and make relevant modifications to their code.

Working through error messages isn’t easy – but therein lies the learning opportunity and the contrast with traditional learning environments. In a traditional classroom, students look to teachers for validation that they have carried out a task correctly; if the task has not been correctly completed, students expect the teacher to explain the solution. In contrast, self-paced students on the Learn platform are focused on solving the problem and finding multiple ways to solve the problem. There is no emphasis on solving the problem “the correct way”.

I didn’t understand that coding is more art than science until I began to learn programming. Although skills are obviously involved, there is seldom a “correct” way to code. Although the very best code is efficient and parsimonious, running faster and requiring less computing power, code can be written in a myriad of ways to solve the same problem. An excellent programmer can write one line of code to accomplish what a novice might take five lines to accomplish. In that sense, computer languages behave similarly to human languages in that there are many ways to accomplish a simple task. In English, for example, “Hi,” “Hello,” “How are you?,” and “How do you do?” all serve essentially the same function. If I were teaching English to non-English speakers, I’d accept all of them as “correct” greetings (and, for that matter, “Good morning!”, “Good afternoon!”, or even, “Howdy!” would work too.) The same is true with computer languages.

Unless a specific skill needs to be learned, both Codecademy and Learn allow great latitude for the code students submit. I am always amazed by the many variations when I search for a solution online and read snippets of code posted by others. In the end, when I pass a lesson, I have solved the problem my way, which is rarely identical to other students’ solutions. When I am stuck and ask for help, help is delivered in response to the specific issues in my code.

THAT process, in my mind, is problem-based learning par excellence. I do learn specific coding skills – like everyone else learning through the same platform. Yet, I acquire each of those skills when a problem arises – so I master those skills in a different sequence and at different times from other students. On Learn as well as Coursera, I occasionally see other learners fly through the lesson while I am stumped, spending hours (sometimes days) trying to figure it out. Other times, I surprise myself by how quickly I finish a lesson.

Ideally, our foreign language classes should be conducted the same way, because this is how we’d learn a foreign language if we lived among native speakers of that language. We speak when we have a need to and corrections, when given, are contextualized.

For that reason (among others), I believe, foreign language instruction can benefit tremendously by borrowing philosophically from (the best) programming instructional platforms. Both have content that must be mastered, including grammar and syntax; both require “hands-on” learning; both require practice and repetition, and both can improve when people interact with each other – programmers may be “techies”, but, it turns out, the world of programming is an entirely collaborative universe where people willingly, freely, and unreservedly, share tips and offer solutions. Learning to code has given me a glimpse into the that universe, so I have begun to understand what gave rise to the (incredible) practice of “open source”. (See my post Why all teachers should learn to code a little).

While I wait impatiently for my next programming class to start on Coursera, I am now applying what I have already learned to programming an Arduino and Raspberry Pi. But that is not the point – I feel I have truly entered a unique world that has so much to offer to everyone.

For all my praise of self-paced learning online, I am not at all suggesting that we should get rid of teachers – a completely self-paced, self-directed course alone often is not sufficient, as I have discovered when I hit a difficult patch on Codecademy (see my earlier post). Without the excellent course taught by Dr. Chuck Severance (“Dr. Chuck”, of the University of Michigan) in which he succinctly explained away some of the most difficult concepts, I’d have given up a long time ago.

For that reason, the Learn platform offers an entirely unique solution, which mitigates what I see as a major roadblock for learners on Codecademy²: The lack of reliable help when one needs it most. A few months back when I first started this journey, I was often exasperated by how many discussion forum threads I had to sift through to pick up the tiny bits and pieces needed to advance in a lesson. Even on Coursera, help is often “Hit-and-Miss Help” – a learner can’t pick teaching assistants (and does Coursera track the efficacy of their TA’s anyways?) In any case, I often wished I could ask direct questions for a seemingly simple issue while the problem was fresh (and urgent) in my mind.

On Learn, however, there is synchronous, live help, usually from “Learn Experts” who are good at programming and who generally are excellent at offering explanations. The “Ask a Question”  window is present in every lesson. Usually within a few minutes (sometimes sooner) of posting, my question gets answered – in the most helpful way imaginable (and I am not talking about copying code to pass an exercise). Sometimes fellow students chime in. In fact, when one posts a question, one immediately sees the message that a “fellow student” will help soon. Now that I have been on Learn for a month, I have come to recognize these “fellow students” who are, at a minimum, advanced students, but who are vetted by Learn to be “Learn Experts” – they are different people with different personalities, but they all offer good, reliable help. Occasionally I do get surprisingly excellent help from advanced students: Once, a fellow student responded to my question with a series of (blunt) questions about my code; as I tried to answer her, I began to see what was wrong and learned a tremendous amount as a result. Help also comes through different media, depending on the need. A couple of times, my question required an elaborate answer, so the Learn Experts guided me through their screen-sharing utility and eventually initiated a voice chat session to walk me through the steps – all through Learn, which is free and open to all.

My Coursera professor, Dr. Chuck (as he calls himself) is fantastic – what I learned from him would have taken me a long long time to learn on my own (that is, if giving up was not an option). He made me – a person who has been teaching language for decades – feel good about the profession.

Learn.co allowed me to look at problem-based teaching and learning with fresh eyes – and to see how technology can seamlessly blend in with education.

The free Learn platform offers tremendous value.  What I learned there would have been worth a whole semester-long computer science class in a traditional institution. And I, relatively new to programming and definitely a complete newcomer to Ruby, am about to finish it in 5 weeks. To continue learning on Learn after I complete the free courses, I must become a paid student. I can only hope their formal instructional classes are just as good.

Footnote

¹ There are teachers in the traditional ‘face-to-face’ classes at The Flatiron School. Learn functions as Flatiron’s “qualifying platform” for those wishing to enroll in its face-to-face or online immersion classes.

² Codecademy has recently implemented a new system called “Codecademy Pro”, whereby for a monthly fee one can receive help from “Codecademy Advisors.”

©YUMEI LEVENTHAL AND CODE BY LINE 2016- ALL RIGHTS RESERVED.