Leaving Stanford Online Ed

Stanford

Friday was my last day building Stanford's open-source online education platform. What started as a lark turned out to be one of the most fun and rewarding times in my career. So I'll use this opportunity to reflect back on the project and what we accomplished.

First a Little History

    "MOOCs are just information technology happening to higher education." -- George Siemens

I joined Stanford in 2012, coming off of my self-imposed sabbatical. My goal then had been to get hands-on again, to sharpen the technical tools. I did a few online classes and hobby projects, but my friend Jane suggested I could do some good and have more fun working in a group back on the Stanford campus (I'm an alum, after all). So I joined her and a small group of engineers in a conference room in the fourth floor of Gates.

Recall what was happening in education in 2012. Stanford's first three big MOOCs had just made big splashes. Later that year the New York Times would famously declare 2012 to be the Year of the MOOC. What could consumer-grade web tech could do for higher education? Or even do to higher ed? The low cost and ease of cloud computing removed many of the barriers to trying new things out. You approach experimentation completely differently when things get 100x or 1000x cheaper. Profs were literally getting out their credit cards and buying Wordpress blogs or throw up virtual machines for automated grading. Wild stuff.

So this was the environment when I joined Stanford. That first summer we built Class2Go to host free online courses. We went from empty buffers to a live Python/Django site for hundreds of thousands of enrolled students in eleven weeks. Man, that was a fun ride.

We built Class2Go for a few reasons. First, we feel strongly that Stanford needs to control its destiny. There is no "file format" for online ed content, so every course development online is a bet on a platform. And we didn't want to be beholden to one platform vendor (still don't). In 2012 the technology that had powered the early MOOCs were becoming "platforms" and moving off-campus. While we were happy with the success of Udacity, Coursera, and (a year later later) NovoEd, we were also a bit wary. They were going to have to repay their investors at some point. The last thing we wanted was for online education to look like textbook publishing or academic journals. We know what happened there.

Second, we wanted to have a broad impact. We were lucky enough to have an engineering team at Stanford, but it makes no sense for every school to develop their own platforms. This kind of project is tailor made for open source development, and I've advocated strongly for that since the beginning. Not only would this mean many others could benefit form the software, Stanford would benefit from many more developers and see many more use cases (and we have).

And the third reason is the need to modify the platform. There are many reasons why you need to get hands dirty in the code. It could be just developing a point feature, like tracking changes in peer evaluation. Or it could enable a whole new use case, like authenticating on-campus students. Our teachers and researchers want to do interesting work online, not just put up courses. They have great ideas about using the things that make MOOCs unique (different cultures, scale, data-gathering, etc.) as powerful tools, not obstacles to overcome. (To hear more about interesting online ed projects, follow the Stanford VPOL Signal Blog).

Scaling Up With EdX

Come early 2013 we started seeing some interest from others to use Class2Go outside Stanford. While exciting, we were concerned about the quality of the code. There were giant missing features that were going to be hard to write (e.g. peer evaluation). And the code was quick and dirty, with nearly zero tests and other things a "real project" needs. We could have backfilled all of that, but it sounded like a lot of work.

It's around that time that we started talking with edX. Our academic ties to MIT, Harvard, and other edX consortium members are strong. We liked their philosophy and approach. And our technologies were similar: both Python/Django stacks running in Amazon, etc. We decided to work together. Rob Rubin and I got the deal done quickly, mostly between sessions at PyCon. In April 2013 we announced that we'd shutter Class2Go and adopt the Open edX platform.

Stanford didn't join the XConsortium. Rooted in our belief in the power of open source, we made open-sourcing their platform a condition of us working together. EdX didn't need convincing. But Stanford was of a forcing function to do it then, and it did take some work. They pushed the button on June 1 2013.

For the past year and a half the Stanford team has operated as a virtual member of the extended edX engineering team. They've been a fun group to work with, generous with their time and good collaborators. We've been running the platform successfully now for over a year, supporting dozens of courses for Stanford students, MOOCs, online high school students, and many other uses. We've contributed back many features, like theming, course email, instructor analytics to name a few.

I've spent a lot of my own time helping to make sure the Open edX project a healthy open source project. It's not enough to just open up the code, to have a thriving community you have to conduct your development out in the open. Beyond helping other institutions get up and running I've worked to drive the open-source agenda overall. With my friend Nate Aune last May we published recommended changes to technology, governance, and community. And with Paul-Olivier Dehaye this past June we hosted the first Open edX workshop, in Zürich. I think those efforts have made a difference.

Moving On

I've heard the siren's song of the startup. Last Friday August 29th was my last day at Stanford. I'll post about my next gig when the time is right.

But I do feel good about moving on. The Stanford engineering team is solid and productive. The engineers work well with each other and have a good breadth of skills. The course operations team is dedicated and strong. Jane Manning will do great running the team in addition to her day job as of product management -- she's done this before and knows the product inside and out. And Jason Bau, the Stanford Open edX tech lead, will continue to anchor eng and ops.

And what about the open source community? I do feel like the flywheel is starting to spin up. EdX is fostering this in several ways, I'll mention two. First, they are in the process of opening up their bug tracking database and sprint planning (Jira). That's a key step to doing true open development. And second, I'm really excited to see the first full-on Open edX conference happening this upcoming November. I expect that to be well attended.

EdX has asked me to continue on as a member of the Technical Advisory Board, which I am happy and honored to do. I look forward to staying plugged into the project and working with my friends on the board (Armando, Ike, Jim, Phil, Ross...)

Thanks to my many friends on the project: the Open edX engineering team, especially Jason and Jane; the team in the Office of the Vice Provost for Online Learning, especially Professor John Mitchell who made this possible; and my many friends at edX. There's a lot to be proud of over the past two years, and a lot of good work ahead.

Arthroscopy Is Amazing

My Left Knee

Three days ago I was hobbling around on a sore knee with a torn meniscus. But after just three days of icing and Ibuprofen and resting on the couch already my knee is almost better than it was before. This arthroscopic surgery stuff is amazing.

My knee had been getting progressively worse for the past few months. But the clincher was six weeks ago, when I was chasing around a dog that was loose in our front yard. A twist, pop, and I was down. The doctor I saw the next day confirmed that it wasn't anything "serious" like a torn ligament, but something was definitely wrong. When we went up to a week of family camping a few weeks back, I couldn't go on any hikes and could barely play ping pong. It was a real bummer.

So I met with a sports medicine doctor at Palo Alto Medical Foundation and got an MRI. He saw a few things wrong in there. A few days later, I was getting the procedure done. Viola.

Afterwards I was surprised that it didn't hurt. They did prescribe some pain medication (Hydrocodone plus Acetaminophen) that I've been taking when I go to bed, but haven't needed during the day. I've been using a machine that pumps ice water through a pad around my knee all day to keep it cool, and that's worked really well. So much better than ice packs. Totally recommend the ice machine.

Thanks to the good surgical team at Palo Alto Medical Foundation especially Dr. Colin Eakin. Their surgery center on Willow Road made the whole experience smooth and reassuring.

But one pro tip for you out there considering this. Don't read the wikipedia article on General Anesthesia the night before surgery. It's crazy stuff. Especially the parts about how we're still not really sure how it works, or the part about how the level of anesthesia where it is safe to operate is right between "excitement" where you vomit and twitch, and "overdose" where you stop breathing. Don't read that part.

I'm back to work tomorrow, and I expect to be back on my bike by next week!

David Bowie To The Rescue

Bowie JohnDancing1.jpg

I often wake up with a song going through my head. I don't know why this happens. The stranger thing the songs. Yesterday was good, I woke up to Led Zepplin's Immigrant Song — what a great way to start the day. But earlier in the week it was inexplicably the Golden Girls Theme Song. Gah!

I've heard them called earworms: songs that get stuck in your head and don't get out. So I'll share with you now the antidote, taught to me by my good friend Jane Manning. Thanks, Jane!

Sing David Bowie's song John, I'm Only Dancing. Not one of Bowie's better known songs, nor even one of his best, but remarkably well suited to this. I believe it's because the melody is kind of odd and not all that pleasant, so it's not going to get stuck itself. You kind of remember the melody and lyrics, but not quite, so that keeps you busy. It always does the trick.

Feedback Without Tips

Tip O'Neill

I really don't like tipping. I'm not like Mr. Pink. It's not that I don't want my server or driver to get something extra. I just don't like the awkward social situation of deciding if this is a tipping situation, and if so, how much.

Two services have come up recently where I will happily pay a premium to not have to fret about too much or too little:

  • Uber. Lots to like about this service but the act of just leaving out of my cab without paying is joyful. I always rate my drivers, good or bad. 98% of the time, it's good by the way.

  • OrderAhead. Are you supposed to tip when picking up takeout from a restaurant? I've never known. Neither way feels right, so I usually end up splitting the difference and rounding up to some amount, say leaving a 6% tip, which is the worst choice. Either that's 6% that wasn't expected, or I'm inadvertently shafting someone.

Both of these services decouple feedback from money. Both avoid awkwardly changing money. I'd definitely pay a premium for that.

I wonder what other service business would benefit from decoupling feedback from money?

CS Students: Learn to Write

Writing Hand

If I could do my college years over I would focus on writing. I would take courses that required a lot of writing, in the spirit of "learn by doing". I'd also take courses in the mechanics and craft: grammar, vocabulary, and rhetoric.

I used to consider myself a competent writer. And certainly good enough for an engineer, right? But I've learned that I have a long way to go. I've learned that engineers spend much more time writing than you expect. And I appreciate how hard it is to write well.

This came up just this past week. I came across a beautiful four page essay. It laid out the problem, described alternatives, and lead you concisely to a well-reasoned conclusion. Sure, it was about technology, but what carried the day was the good writing. Humbling!

You're saying: but wait, you're a pointy-haired boss now Sef, one of those guys who doesn't do Real Work anymore. You write email and boss people around. I understand why managers like you need to write, I'm an engineer. I write code. Well, there's some truth to that. But I'd like to convince you that even monster coders, if they're any good, write a lot, write well, and value good writing in others.

It is rare for someone to do their work in isolation and have it matter. Either you're working as part of a team, in a company or a community of developers, say on an open-source project. Sure, you build a great system or feature. But to have it matter to the world, for others to adopt it, you need to document, publicize, support, teach. 98% of that is writing.

I had a lunchtime conversation with Jacob Kaplan-Moss, Django's co-founder, at last year's PyCon. I asked him why Django caught on and was adopted by so many of us (including my last project and my current project). I was expecting him to point to features or timing. Instead he said it was "because we wrote good docs". The Django team didn't treat documentation as an afterthought. They have lots of docs, and they are good.

Consider that rare bird, the iconoclastic engineer working in isolation on their own project. I'm thinking of Antirez or Marco. (Maybe they aren't even truly on their own so much. Humor me!) They are prolific and strong coders. But they also write a lot of words! They write a ton about their project; also tech landscape and their place in it. Would their software have as much of an impact if they didn't write so much (and well)? I say no.

Case in point. Both Marco and I wrote blog posts riffing off the same topic two weeks ago. First, read mine, then his. It takes me a ton of words to get something basic out. His is concise and clear. Sheesh.

So kids, don't shortchange those liberal arts classes. It's not fluffy stuff on the side. That is core. You need to write well to be a good engineer.

Protip: the best way to do this is to major in the humanities. They write like crazy over there. Be like my friend Dan Chu and major in history, but secretly take CS courses on the side. If you're super smart like him, and can manage getting both degrees, then you're awesome. But don't sacrifice the BA for the BS. I would love to talk to a candidate with with a History BA and a Computer Science MS.

Chicken Soup

Yummy Bowl of Chicken Noodle Soup

My family hasn't avoided the colds that are going around now. My way of fighting back is making chicken noodle soup. It's not too hard, it's satisfying, and it tastes great. The recipe belongs to Peninsula School and gets used at our annual Craft Fair. It's benefited from years of refinement.

I add more salt. I don't do peas. I've tried with rice but it got starchy and weird, stick with egg noodles.

Consume vs. Produce vs. Produce Publicly

\

One of my goals for this year is to try to produce more and consume less. Not in the green, fixed-planetary-resources sense [1]. I mean to make more things, ideas, contributions. To be more creative. Creative in literal sense of that word: creating.

Rands said it well in his post this week, "The Builder's High'. If you haven't read it, go do so now. I'll wait. (and while you're at it, if you don't have him followed or bookmarked or whatever, do that too.)

I agree with pretty much everything he said in there. The good feeling that comes from actually making soemthing. How that's especially true now in light of the constant crush of everyone else's creations (he called them "moments").

Making takes many forms. Since I stink at woodworking and gardening and painting, I'll stick to the things I do enjoy, like writing and coding and cooking. Those fit less into the traditional mold of "building" or "making" but that's OK.

I want to take it one step further. Here are my three categories in value order. Numbers 1 and 2 we just spoke of, but 3 is new.

  1. Consume. This is watching TV, playing video games, trashy reading. Sure I'm going to keep doing that, but it's not energizing.

  2. Produce. Cooking a meal, learning something interesting. Maybe even reading something intellectually challenging, but that's pushing it.

  3. Produce, In Public. Now, this is the toughie. It's one thing to do something creative, another to put yourself out there and tell poeple what you did, and why. By sharing the product, by talking people through the choices you made to get there, you're opening yourself up to criticism. But why not!

That is part of the reason why I reworked my blog over the holiday break, so I'd have a nicer platform for writing. Anything to lower the bar to produce.


[1] I'm not anti-green. I really appreciate the environmental warriors out there who walk the walk with real life choices to consume less. That's just not my bailiwick, for now at least.

Switching to Static

Nikola Tesla

For those of you who frequently read this blog (n ≈ 0) you'll notice that it looks a bit different. I've moved it from my own hosted Wordpress instance to static pages generated by Nikola and hosted up on Github.

Why bother? I didn't like my blog being something I wouldn't be proud to write or operate myself. Wordpress was overkill and not worth the trouble:

  • Wordpress is database driven for dynamic sites. My little blog isn't dynamic at all. Once you buy into the static idea, lots of otehr things fall into place.

  • Comments and account spam are still is a nuisance. The nice people at Akismet have done a great job holding back the tide, but I still get at least one bogus registration a day. I expect a service like Disqus or Facebook or Google+ will be more likely to keep pace with the spammers.

  • I want to author in markdown; maybe even ReST someday. All this wysiwyg-ish stuff in browsers is for the birds.

  • I don't actually need to host anything. I'm not running my own IRC server or anything. Even though Dreamhost has been a perfectly good service, I just want something... well, less Wordpress-ey.

Choosing

So I need to pick a static web site hosting package, specifically one that is good for blogs. The big things I was looking for: static site generation, Markdown/ReST support, and ability to host on free services like Github Pages.

In additon I wanted these things (in no particular order):

  • active development

  • in real use on real sites

  • easy customization, ideally by theming

  • ability to move over posts and comments, probably via Wordpress's export function.

  • python, what I program in for fun

  • a bit extensible

I considered three options before settling on Nikola. There are a ton of static site generators, even when you limit them to Python. But the only alternatives I seriously looked at were Pelican and Hyde. Of these Nikola seems to have the most active development and the richest set of features. I ease especially drawn by their good documentation and theming.

Up and Running

Here are my notes of what it took. This isn't a nicely-written howto, but if you want to see the blow-by-blow, read on.

  1. The software was easy to set up and get started

    • pip install nikola did the right thing. Of course within a virtual environment, you have to keep the lab clean!

    • Along the way I found a few other requirements, like request, phpserialize, and markdown. These were easy to find/fix because of helpful error messages.

    • This is all now captured in the project's requirements.txt.

  2. Initial import from wordpress XML dump went ok but a fair bit of manual HTML prettification took some time.

    • The slugs aren't how I like them: 201311seven-things.wp instead of seven-things.wp. I tried a bit to do mass rewrite of those, but couldn't easily do that without breaking everything, so just decided to let this go for now. I'll just do slugs without dates going forward.

    • I considered html2text but figured I'd just let the HTML slide for now. Too much trouble to go back and clean all that up now.

    • The "wp" extension, by default, is mapped to markdown instead of html. Odd but easy to change.

    • Nikola has a nice simple redirect facility that the importer pre-populated for me.

  3. Migrate threads to Disqus - clean and simple, worked right out of the box.

    • wordpress plugin has a nice import facility. Said it'd take a day, but didn't take that long at all. Aside from one thread with 75 comments, not much else that should cause them much heartache.

    • nice simple URL mapping utility

  4. Publishing to github. Again, easy peasy. The way to make this work is to put all your static files in a repo titled USERNAME.github.io. In my case: sefk.github.io. Just a couple of "tricks" were needed to make this work smoothly:

    • So that it would correctly serve my own domain, you have to put a CNAME file in the root of the repo

    • I put my nikola themes and source files in the "src" subdirectory, and changed the OUTPUT_DIR configuration option to ... Github Pages wants things in the root.

  5. The final swich. I moved my domain from Dreamhost over to Gandi, which is the registrar I like to use. They throw in basic DNS with registration, which is sufficient for me.

So There You Have It

So far I am really pleased with the result. It's a bit more work to publish, but for me that's natural and what I want. I guess I wouldn't recommend this to someone who isn't adept with all these bits (virtual environments, DNS, github repos, etc.) but for me that's no problem.

Thanks to: