I wrote some time ago about defining the interface for rubymonk. Glancing at it again that post was a bit rambling. Sorry. However, it did introduce a concept I've been mulling over for the last half-decade: re-framing all software in terms of automation. Robots. I'll start with RubyMonk as an example, and then move on to others and counterexamples.
RubyMonk has quite a sophisticated back-end. The details aren't important for this discussion, but it is essentially a virtual sandbox which quickly and safely executes any programming language (not just Ruby) in isolation, preventing that code from interrupting other users' exercises, other processes running on the RubyMonk servers, other files on said servers, or the clean operation of rubymonk.com itself. Once this sandboxing technology is in place, the interesting question is no longer "how do we run arbitrary code submitted from a browser?" but "how do we teach someone Ruby?"
Everyone on the RubyMonk team has taught Ruby to classmates, colleagues, kids, and friends. The activity of "teaching Ruby" is a known quantity. In the world of yesteryear, however, these lessons always involved our physical presence. From our teachers we have learned how to recognize certain categories of mistakes and how to introduce a correction. From them we have also learned when not to correct someone -- sometimes feeling the pain of a mistake is more memorable. Conversely, they taught us to identify frustrations and to step away from an exercise when it becomes too emotionally taxing. They taught us to ask the right questions when someone doesn't appear to understand a concept. Or to employ humour, analogies, and anecdotes to colour a subject. Finally, they taught us to teach. And so, when we work with a new programmer, we also teach them to teach.
This is an incredibly human endeavour, teaching. But all software is an immaterial robot. We need to bridge the divide. How does the RubyMonk robot work? Today, when you attempt an exercise on RubyMonk, you are learning from an interactive book: first you read a blurb about lambdas or ActiveRecord or your topic de jour. Next, the robot quizzes you by offering up an exercise. Your solution to the exercise is sent to the RubyMonk server and executed against a small battery of tests -- each of your test results is returned to you with a brief explanation. If you pass all the tests, you pass the exercise. So what are we missing? Well, we can't teach you TDD with this method yet -- how do we test a test? And if the solution to that seems obvious, how about teaching SQL? Prolog? Portuguese? Calculus? And once you solve those problems (and we largely have), the real challenge emerges. So far the robot does not recognize categorical mistakes. The robot does not infer when to let you suffer through a mistake to make it stick (perhaps thankfully!) nor does it know when to tell you to step away for a tea break and give your mind a rest. It doesn't ask the student dynamic exploratory questions on difficult lessons. It doesn't remember the last time it forgot the order of parameters to the signature of Enumerable#inject.
Yet.
The challenge of RubyMonk -- as is of all useful software -- is to replace a human being. And while the task of teaching is surely orders of magnitude more complex than the task of photocopying documents or playing your favourite David Bowie track, the goal remains the same: Build robots. Free up human time. iTunes is a robot. Prismatic is a robot. RubyMonk is a robot.
I've only been back in the startup world for one year. There's a lot of great stuff going on around the world right now. The last time I lived in India there was no Cleartrip or Redbus, which are robotic replacements for travel agents and telephone booking. Online banking was a non-starter. In 2013, every country seems to have technology covering the basics. The better technology companies are geo-agnostic or are striving to be. I don't want to hire a robot I can't take with me to Thailand (it's always fun to see which part of my Rdio collection is missing when I land in a new country... but I'd still prefer if it were all there). The world is getting smaller and faster and more overwhelming -- but thankfully a generation of nerds is fighting to smooth the transition for you. When we can't build a robot to help you, we'll fight the antiquated laws which stifle progress. At least, some of us will.
I see a divide between the inevitable future of beautiful, helpful robots built by a new generation of businesses (and non-profits, for that matter) and the ephemeral world of peculiar toys established on a misguided premise. This hit me in the face as I read through The Lean Startup, agreeing with everything Ries had to say but feeling a peculiar unease throughout the entire book. Why was I getting such a barfy feeling in my guts reading a book of sensible advice? It only occurred to me once I'd finished that most of his experience was drawn from building IMVU, which was a robot version of human... what, exactly? I'm not sure, either.
RubyMonk has quite a sophisticated back-end. The details aren't important for this discussion, but it is essentially a virtual sandbox which quickly and safely executes any programming language (not just Ruby) in isolation, preventing that code from interrupting other users' exercises, other processes running on the RubyMonk servers, other files on said servers, or the clean operation of rubymonk.com itself. Once this sandboxing technology is in place, the interesting question is no longer "how do we run arbitrary code submitted from a browser?" but "how do we teach someone Ruby?"
Everyone on the RubyMonk team has taught Ruby to classmates, colleagues, kids, and friends. The activity of "teaching Ruby" is a known quantity. In the world of yesteryear, however, these lessons always involved our physical presence. From our teachers we have learned how to recognize certain categories of mistakes and how to introduce a correction. From them we have also learned when not to correct someone -- sometimes feeling the pain of a mistake is more memorable. Conversely, they taught us to identify frustrations and to step away from an exercise when it becomes too emotionally taxing. They taught us to ask the right questions when someone doesn't appear to understand a concept. Or to employ humour, analogies, and anecdotes to colour a subject. Finally, they taught us to teach. And so, when we work with a new programmer, we also teach them to teach.
This is an incredibly human endeavour, teaching. But all software is an immaterial robot. We need to bridge the divide. How does the RubyMonk robot work? Today, when you attempt an exercise on RubyMonk, you are learning from an interactive book: first you read a blurb about lambdas or ActiveRecord or your topic de jour. Next, the robot quizzes you by offering up an exercise. Your solution to the exercise is sent to the RubyMonk server and executed against a small battery of tests -- each of your test results is returned to you with a brief explanation. If you pass all the tests, you pass the exercise. So what are we missing? Well, we can't teach you TDD with this method yet -- how do we test a test? And if the solution to that seems obvious, how about teaching SQL? Prolog? Portuguese? Calculus? And once you solve those problems (and we largely have), the real challenge emerges. So far the robot does not recognize categorical mistakes. The robot does not infer when to let you suffer through a mistake to make it stick (perhaps thankfully!) nor does it know when to tell you to step away for a tea break and give your mind a rest. It doesn't ask the student dynamic exploratory questions on difficult lessons. It doesn't remember the last time it forgot the order of parameters to the signature of Enumerable#inject.
Yet.
The challenge of RubyMonk -- as is of all useful software -- is to replace a human being. And while the task of teaching is surely orders of magnitude more complex than the task of photocopying documents or playing your favourite David Bowie track, the goal remains the same: Build robots. Free up human time. iTunes is a robot. Prismatic is a robot. RubyMonk is a robot.
I've only been back in the startup world for one year. There's a lot of great stuff going on around the world right now. The last time I lived in India there was no Cleartrip or Redbus, which are robotic replacements for travel agents and telephone booking. Online banking was a non-starter. In 2013, every country seems to have technology covering the basics. The better technology companies are geo-agnostic or are striving to be. I don't want to hire a robot I can't take with me to Thailand (it's always fun to see which part of my Rdio collection is missing when I land in a new country... but I'd still prefer if it were all there). The world is getting smaller and faster and more overwhelming -- but thankfully a generation of nerds is fighting to smooth the transition for you. When we can't build a robot to help you, we'll fight the antiquated laws which stifle progress. At least, some of us will.
I see a divide between the inevitable future of beautiful, helpful robots built by a new generation of businesses (and non-profits, for that matter) and the ephemeral world of peculiar toys established on a misguided premise. This hit me in the face as I read through The Lean Startup, agreeing with everything Ries had to say but feeling a peculiar unease throughout the entire book. Why was I getting such a barfy feeling in my guts reading a book of sensible advice? It only occurred to me once I'd finished that most of his experience was drawn from building IMVU, which was a robot version of human... what, exactly? I'm not sure, either.
It's a good thing for those of us in the startup world that there is money to fund such endeavours: GroupOn, Instagram, the iPhone-ordered-artisanal-bread-aged-cheese-local-ingredient-biodegradable-packaging... grilled cheese sandwich. A cornucopia of startups whose primary customers are other startups. (Ever read a short story by an English Lit major about an English Lit major who suffered from writer's block during a short story assignment? Yeah. That.) A thousand other companies that lack a real goal, a real business model, a real raison d'être. If those companies can find enough money to feed their employees, surely so can those building software which solves real problems.
At C42 Engineering we're currently working on a process to help us identify meaningful problems and gaps in the solution space. We'll publish everything about this process because there are big, hard problems left to solve. And each of those problems is an opportunity for someone to build an elegant robot. We can't wait to see yours.
2 comments:
I'm currently working my way through the course and just finished the "Ruby Primer" section. I thoroughly enjoyed it, but the problems at the end were incredibly difficult. I had to click to see the answer on most, if not all, and then I could read what was happening but never would've solved it on my own.
My only piece of advice is to possibly add more of an explanation and dumb some of it down, even in the lessons. I think some of it is assumed to be known, since you're coming from a programming background and a lot of it is probably second nature at this point. However, for rookies like myself who are completely new to programming, some of it could've used a bit more babytalk. It's an awesome website though and I really appreciate everything you and your staff have built. Thank you!
Sidenote: Here's my website that highlights new music: http://wayuphere.com. I'm learning RoR along with my current co-founder, who coded it all in PHP, so we can rebuild it from scratch. Should be quite the journey.
Hey Ryan! Thanks for trying RubyMonk! Sorry you found some of the later exercises difficult. Unfortunately, I left the rubymonk.com team a couple months ago so I won't be able to help you. You can send the team feedback through the website, though.
Good luck with WayUpHere. Looks like a cool site!
Post a Comment