Ceci n'est pas une pipe.

A description of a doctrine without words is not a doctrine without words.

Over the last few days, the internet saw a layered explosion of conversation regarding Adria Richards, and a conversation which happened near her at PyCon 2013. To me, it looked like this:

The first circle represents the initial event. The second circle represents Adria's public reaction. The third circle represents the reactions of HackerNews, Twitter, Playhaven, SendGrid, Anonymous, 4chan, and the internet at large to Adria's reaction. The fourth circle represents the analysis of the internet's reaction. And, for the sake of brevity, the last circle represents the analyses of this analysis. Some where in the middle of that rainbow pile there was some introspection. (Aside: I consider all of these articles worth reading.)

I'm the sort of person who likes to believe I'm above such flame wars, even before I know what they are about. And it was easy for me to nurture that unproductive belief in a little log cabin of silence. Fortunately, I was brought into a conversation in our office and knocked off my little throne of self-righteousness. Someone said something. Someone took offence. Someone else took offense on behalf of the offended (and, of course, themselves). It was discussed and the Original Someone took offense to the implications of that discussion. That's when I stepped in to "help out". Now our picture looks like this:

No need to thank me, friends. Glad I could help.

Keep in mind that this was a respectful and lucid discussion; everyone I work with is intelligent and thoughtful. But look at those layers: none of us could possibly share a context. It was difficult to nail down what we were even debating most of the time. Our own emotions? A specific incident? The reactions to an incident? The state of our industry? The incident as a microcosm of our industry at large? The state of gender roles and sexuality the world over? Some muddied mix? Anything we'd unravel seemed to hide another layer of experiential and emotional complexity which would quickly bury us again.

It wasn't until hours after Tejas stepped in and suggested we all take the weekend to sleep on it that I realized I was making precisely the mistake I presumed everyone else was making. I believed I understood. I believed I had clarity. I believed if they would just listen to me I could show them the answer. Specifically, I believed I had the one piece of advice everyone else was missing: "Maybe you should take some time to reflect on how she might feel." The irony still hurts.

I will continue to participate in this conversation. (And the related conversation about stopping rape, as it is ultimately more important.) Many of the links in this chain are ugly links. When a conversation is itself about our understanding of one another -- and thus how we treat one another -- those ugly event-links are (a) pointers to discussions we need to have and (b) proof the conversation is valuable, because we haven't stopped hurting each other yet. The recursive nature of the conversation shouldn't scare us but it might suggest we speak carefully.

But before I participate in the conversation, I'm peeling back all ten layers and taking stock: Who am I? A healthy, educated, middle-class, white man. I will never be a woman and I do not have the imaginative capacity to understand what a woman feels. I will never be another person and I do not have the imaginative capacity to understand what another human being feels. I can learn by listening with an open mind, even if I will never perfect my understanding. How beautifully this dovetails with my position of privilege! It's the perfect time to shut up and take some of my own medicine: Reflect.

How do I really see other people? How do I really see myself? When do I judge you? When do I desire you? When do I reject you? Why? When my perceptions take life in my actions and my words do you feel threatened, comforted, intrigued, or confused? Why? Which link in the chain am I? Am I making things better?

. . .

.

defining the test for rubymonk

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.

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.