Seth Godin on The Tim Ferriss Show

Tim Ferriss has done a bunch of great interviews or, more to the point, interviewed a bunch of great people well. On the latest episode, he interviewed well-known marketer Seth Godin. I enjoyed the whole show, even the bit about how to make chocolate at the end. This part about education at about 1 hour 35 minutes into the show resonated strongly with me:

Sooner or later, parents have to take responsibility for putting their kids into a system that is indebting them and teaching them to be cogs in an economy that doesn’t want cogs any more.

I’m a huge fan of public school, I sent my kids to public school. I think everyone should go to public school. It’s the great mixmaster of our world, but from 3 o’clock to 10 o’clock those kids are getting homeschooled and their either getting homeschooled watching the Flintstones or they’re getting homeschooled in learning something useful, and I think we need to teach kids two things:

1. How to lead

2. How to solve interesting problems

Because the fact is there are plenty of countries on Earth where there are people who are willing to be obedient and work harder for less money than us. So, we cannot out-obedient the competition. Therefore, we have to out-lead or out-solve the other people. […] The way you teach your kid to solve interesting problems is to give them interesting problems to solve. And then, you don’t criticize them when they fail. Kids aren’t stupid. If they get in trouble every time they try to solve an interesting problem, they’ll just go back to getting an A by memorizing what’s in the textbook.

Remix OS for PC: Android on the Mac

I don’t have any Android devices at present, but I am sometimes curious about various things going on with Android. For example, it would be nice to be able to try out the Khan Academy app for Android. Remix OS is a way to run Android (with a desktop-like UI) on various Intel-based computers. People have had some success getting it to work on Macs and here are instructions for creating the disk on the Mac.

Update: dizzyviolet on Hacker News notes that the EULA for Remix OS is crazytown.

The Jai Programming Language

Jon Blow’s videos about the development of his new game are really interesting. To build the game he wants to build, he decided to create the language he wanted to use to build the game (kind of like Mozilla created the language they wanted to use to build a browser). Blow’s language Jai has not been released, but Jorge Rodriguez has created a primer for the language based on Blow’s videos:

Jai is a high-level programming language developed by Jonathan Blow, creator of indie games Braid and any-time-now-to-be-released The Witness. It is an imperative static/strongly typed C-style language, but with a variety of modern language that C lacks. Blow began work on Jai in late September 2014. It is still in development and as of yet is unavailable to the general public. Blow developed it with an eye towards video games, but in fact it’s a general purpose programming language that could be used for any task.

Ditching Scrum for Kanban

I’ve blogged about the switch we made on the Brackets project from Scrum to Kanban and also, more recently, on our use of Kanban at Khan Academy. This article by Grant Ammons mirrors my own experiences:

Peter told me that indeed, many companies follow the same path that we did. They go from no system to Scrum, which teaches them the disciplines they need to properly develop software. Then, as teams fully understand Scrum, its disciplines and rituals, teams have the option to move to Kanban.

Side Effects vs. Promises

This past weekend, I saw Chris Armstrong (@radix) talk about Side Effects as Public API. From the description on the Strange Loop page for the talk:

Haskellers have been isolating their side-effects from their pure code for decades, but most people write code in languages that allow ad hoc side-effects anywhere. In a lot of cases, these side-effects are practically a part of the public API — they put restrictions the way the code can be used, often obscurely, and have effects that are observable to the caller. It helps a lot to acknowledge this and explicitly treat them as a part of your public API. Here are the basic ideas that I’ll cover:

  • represent your side-effects as “intents to perform an action” — transparent objects that expose the details of the side-effect, without actually performing it
  • combine effects with pure code to describe the execution order and data dependencies (yes, like a monad)
  • write unit tests for your code without mocking, by specifying the expected content, results, and order of side-effects performed by a function

Chris has made a Python library called Effect that implements the ideas he was presenting.

In JavaScript-land, we’ve embraced the idea of promises now to the point that they’re a standard part of the language, already implemented in multiple browsers (about 66% of those in use!) and in Node. Promises can clean up your asynchronous code and if you’re not familiar with them, you should go read one of the many tutorials about them.

A promise is a placeholder for a value to come along at some point in the future. Using the then method on the Promise, you can pass in a function to be called when the value is ready. Here’s a hypothetical example:

function getItemOne() {
    let promise = get("http://foo.barbaz/api/item/1").then((value) => {
        // Do something with the result
    }, (error) => {
        // Do something with the error
    return promise;

This example above is not very different from the use of callbacks and isn’t intended to show off the nice attributes of promises. It is a good example to illustrate the use of an Effect rather than a Promise.

The first thing I’ll note is that getItemOne is not a pure function. Calling it produces a side effect: an HTTP request. Testing this function, or any function that calls it, is difficult because of that impurity. The usual solution for testing something like this is to replace get with a mock function. That doesn’t really fix the impurity of the function, but it at least makes it testable.

We can make getItemOne pure by making a small change like this:

function getItemOne() {
    return new SideEffect({
        type: "http-get",
        url: "http://foo.barbaz/api/item/1"
    }).on((value) => {
        // Do something with the result
    }, (error) => {
        // Do something with the error

I’m not suggesting that we’d use the API above, because I think we can do better than that. In fact, this version could look the same as the previous version, if we wanted it to. But, I wanted to clearly show the difference between promises and the side effects about which I’m writing.

The function above is pure. Every time you call it, it will return exactly the same value. Calling this from a test is easy and you can verify that the side effect returned matches your expectations. You can also pass in values to test what happens in the success or failure cases, which would also be pure functions.

In a real system, somewhere up the call chain there will be a dispatcher called to actually process the side effect. The Python Effect library points out that this approach allows you to easily swap out how any given side effect is processed.

I asked Chris if he knew of any JS implementations of Effect. He wasn’t aware of any, but he pointed out that it’s basically just the IO monad. Here’s an implementation of the IO monad in JS. If you look at the Python Effect library and its examples, though, I think there’s a need for a JS library that fits in better with the overall JS ecosystem (test runners and whatnot).

In practice, returning side effects rather than performing them and returning promises can increase the size of the “functional core” of your application, which is a win in my book.

My onboarding experience at Khan Academy

I’m in my third week at Khan Academy and thought I’d write a little about my experience with the onboarding process here. I’m a remote employee and my first two weeks have been here at home, 2,000+ miles away from most of my coworkers. This means that I don’t have the benefit of in-office osmosis of thought or lunchtime talk with the others. My quick summary is that onboarding at Khan Academy works very well indeed.

The starting point is a welcome email that arrives before your first day. This email provided me with a bunch of background even before I started. Part of that includes this Trello board:

This is the first time I’ve seen Trello used as a documentation format, but it works nicely in this instance. You work your way across the Trello board to:

  • get your paperwork in order
  • get everything you need to work productively
  • learn about company culture

The company culture information was especially good because it gave me a lens through which to look at everything I was seeing. Everything from Khan Academy’s mission (free, world-class education for anyone, anywhere) to our development core principles (“shipping beats perfection” and others) to the very deep way in which career development is approached is covered on the culture pages. This both sets expectations for me and helps me have a mindset to keep this wonderful culture going.

From there, I spent a good deal of time reading Google docs and our documentation site. Khan Academy’s documentation is great, covering from the highest level strategies down to details on our day-to-day development processes. One part of KA’s culture is that “everyone can fix everything”, so there was little about the documentation that was stale or out of date.

Alan Pierce ran a “dev crash course” that was recorded and that helped, but I do think a bit more documentation at the 10,000 foot level (what are the pieces and how do they fit together?) would help. I have some ideas in mind for that and hope to have something together soon.

Not getting lost and keeping in touch

I’ve been working with a couple of mentors (James Irwin and John Resig) since I started. Their help has been invaluable because any documentation will have some holes. I’ve also found it easy to get in touch with the right people by using git blame as I’m working on a piece of code. Going through code reviews and talking with the other developers has been very helpful in learning how things work, why they work as they do and some areas we might want to improve going forward.

We make heavy use of HipChat at Khan Academy. This is one thing that definitely makes me feel like a part of the team and less distant from everyone in California. Radical email transparency helps with shared context as well. I’ve been delighted at the quite reasonable pace of email so far, and I think that’s largely due to the split between HipChat and email. That’s something that many organizations seem to be finding as they adopt Slack, which is quite similar to HipChat.

We have meetings via Fuze or Google Hangouts. Video conferencing just gets better over time.

Developer Setup

As a developer with a new machine, you start by grabbing the khan-dotfiles project and running make in there. khan-dotfiles is nice because it gives you everything you need and if the requirements change, you just update the project and re-run make.

Re-running the khan-dotfiles setup is likely much more common than starting up a fresh machine, so it’s not entirely suprising that I ran into a problem setting up my brand new machine. One of the first bits of code I submitted was a fix for khan-dotfiles.

We use Phabricator and the workflow is quite different from the GitHub flow that I’m used to from day-to-day work on Brackets. Again, though, good docs save the day.

Or, I should say, good docs, tools and chats with coworkers save the day!


Khan Academy recently started a support rotation. Every three weeks, a different set of developers will take on support duties, responding to problems that people have filed. Having a set of developers designated (for a time) to work on support is good because it enables everyone else to focus on their project work rather than context switching between bugs and progress work. It also gives everyone a chance to see what people are encountering on the site and an opportunity to step out of their comfort areas in the code and into some other parts.

Newbies like me start out on support, which has worked out well because I have gotten to dig in to a few different areas of the code so far. The fixes I’ve made so far have not required me to change much code, but I have been reading quite a bit of code and learning different parts of the process and tooling along the way.

Elements of good remote developer onboarding

Though I still have a lot to learn (there’s a lot of code there!), Khan Academy’s onboarding process has worked well in getting me up and running. My summary of the key elements:

  • An overall welcoming attitude (seriously, everyone has been great!)
  • An assigned mentor that can handle all of the random questions that come up
  • Documentation of culture, tools, processes
  • Communications channels that work across time and space (HipChat/Slack, email with archives, video conferences with recordings)

It turns out that many of the elements that make an environment remote worker-friendly also make onboarding easier. In fact, this list of items would seem to be very similar to the techniques used in some large and successful open source projects. That’s probably not a coincidence.

The Tale of the Merry Squid: Teaching Programming with Minecraft

The Merry Squid

This past January and February, I taught a class that introduces children to programming through Minecraft. I called the class “The Merry Squid”, and this is my story of how it went. For the benefit of those who don’t want to read the whole thing, I’ll note up front that the class is available online.

Programming in Minecraft

There are so many things that I think are great about Minecraft. Since it’s written in Java, people could use a bit of perseverance (okay, a lot) to figure out how to hook in to Minecraft’s normal operation and change it. If you’ve played Minecraft, you’ve probably already heard about “mods” that do this.

One Minecraft mod is called ScriptCraft. ScriptCraft is a mod that lets you write mods, in JavaScript. Even better, it lets you run bits of JavaScript code from within Minecraft itself.

Minecraft is set up for multiplayer games, so there’s both the client part that runs the graphics and the server part which keeps track of the state of everything in the world. ScriptCraft is a server mod, so that means you can only change things that affect the state of the world and not the graphics that appear on screen. There’s an awful lot you can do within those boundaries, though!

Possibly the best thing about Minecraft for teaching programming is that many kids love it. There’s a strong built-in motivation for them to try things out and see what they can create.

From Logo to Minecraft

Logo was possibly the first “teaching” language that was geared toward kids. Using simple commands, children could draw pictures by moving a “turtle” around on the screen or even an actual physical robot on a piece of paper.

ScriptCraft includes a JavaScript object called “the Drone” that feels a bit like the turtle from Logo. Using functions on the Drone, you can “draw” with Minecraft blocks. Want to make a 10x10x10 cube? Normally, that would mean placing 1,000 blocks, one at a time. Using the /js command provided by ScriptCraft turns that into just a quick bit of typing.

That instant feedback of typing a command and immediately seeing the result in your Minecraft world is fantastic. This seemed like the perfect entry point for getting children to do some JavaScript.

Setup Pain

As easy as it was to start coding with ScriptCraft, getting ScriptCraft itself running was not easy for many.

Most of the parents of the children in my class are not “computer people”. I created step-by-step instructions to set up Minecraft with the required mods on both Windows and Mac, but setup was still not easy. An automated installer would have been nice, but I didn’t have time to build one.

To make matters more challenging, the class met in a building that has barely functional Internet access. USB flash drives are not quite a thing of the past yet.

Also, some of the computers launched programs very slowly. I didn’t have time to track those problems down either, because I had a class full of kids, so my focus was on making sure that everything could run, even if launching was slow.

It’s worth noting that Minecraft is a fairly resource intensive program. That’s probably why Minecraft Pocket Edition was a ground up rewrite in C++: desktop Minecraft takes a pretty beefy computer to run acceptably.

Other local people who teach Minecraft classes bring their own equipment and teach with Minecraft: Pi Edition. This certainly gets rid of the setup pain, but the Pi Edition is nowhere near as interesting as the things you can do with ScriptCraft.

LearnToMod launched just as my class was starting. It sounds like they run the server for you which certainly makes life easier for the participants.

Graduating to code in files

There’s a limit to how much you can do from Minecraft’s little command line. It’s like writing programs in tweets. To do anything really cool, you need to edit JavaScript code in files.

The experience of modding Minecraft with JavaScript is still pretty great. You don’t quite have the immediacy of entering code in the command line, but you can dynamically reload your code without having to restart Minecraft. The iteration loops are still quick.

I got everyone set up with Brackets because I knew the editor well and I knew that the out-of-the-box JavaScript listing would come in handy.

Everyone was successful in running the new scripts that I provided each week. Sometimes they made their own customizations to the scripts, and some of the children clearly were writing some code of their own with varying degrees of success.

My “flipped classroom” experience

I taught this class as a “flipped” class: I’d post a video each week which provided the new material to learn and then planned for us to do more together during class time. My thinking with this was that by doing the experimentation at home after watching the videos, the kids could spend as much time as they wanted playing around with it.

When class times came around, I found that sometimes I needed to do a fair bit of tech support and that the environment hadn’t quite encouraged the kids to work together on things. There was a bit of “hey! look what I did!” that happened, but not quite as much as I’d have liked.

My Egg Hunt mini game from the last session was ridiculously complicated, but I think it did serve well to show off what was possible and was a fun activity that we all did together on the last day in class.

The flipped classroom approach is great because I could put the class online once it was done. At least one parent and child have taken a look and found it helpful:

Fun was had by all!

These children were already fans of Minecraft, but were entirely new to writing code. I tried to balance doing fun things with Minecraft that they couldn’t have done before with learning some JavaScript, putting the greater emphasis on fun-with-Minecraft than learning-JavaScript.

Despite the challenges that I’ve mentioned here, I had a good time creating and running the class and the impression that I got from the kids was that they enjoyed taking the class.

What did I learn?

I learned as much as the children did through this experience.

  • The ScriptCraft drone with the in-game REPL is brilliant. Kids love it and can make good use of it.
  • LearnToMod sounds awesome. Their approach (run the servers on behalf of the learners) makes a whole lot of sense. Alas, with the poor Internet access we had, doing the class in conjunction with LearnToMod would not have been an option.
  • The creator of ScriptCraft has since published a book (A Beginner’s Guide to Writing Minecraft Plugins in JavaScript). Teaching a class based on pre-existing material like that could have made my life easier.
  • I shouldn’t sign up to do a class when I’m already oversubscribed. At the time that I started exploring the class, I thought there would be no trouble… but I had so much going on when the class started that it was a struggle to sneak in my work for the class. The timing was just not quite ideal.
  • Even though the flipped classroom approach wasn’t as smooth as I hoped, I would definitely do that again. Especially when it comes to homeschooled kids, it makes sense for the kids to spend as much time exploring as they want. I would want to make sure that the in-class activity time could be smoother than the way it went for this class.

Minecraft is used for teaching a wide variety of things, and ScriptCraft offers a lot for people who want to learn programming in Minecraft, once you get past the setup.