I learned to write software at Brown University’s Computer Science Department around 2008. I graduated in 2010, worked at Adobe Systems for about two years, and Google for one.

I’d say my interests are primarily in programming languages, though most of my professional experience is in the mid-level application domain, working on large projects in C++ and Java.


All these projects are available on my Github, but here’s for the descriptions/opinions that don’t belong in the README.


This is probably the coolest thing I’ve written, which wasn’t the original plan. I was playing Scrabble with my then girlfriend, and frustrated, stumbled out something like

“it’s just — I’m — I feel like —”

“Oh, I know, you could write a program that would beat me in like a weekend, right?”

"… actually, why not?"

Having written something like a spellchecking bot (for Facebook’s now-defunct engineering puzzles, problem spec reproduced here), I figured this would be pretty easy — create anagrams from your rack using a dictionary, then place the words onto the board. I’ll use a weird language for this. Hell, I’ll use Erlang!

Turns out, writing a decent bot for Scrabble is pretty hard. As expected, generating the anagrams from a rack was fairly trivial with Tries, but then I scratched my head for months on how to place words on the board. The problem explodes in complexity once you realize you have to form legal words using letters currently on the board as well.

The answer lies in a weird, custom data structure called a GADDAG (fun fact! I created that Wikipedia page for it!). It’s a variation on a Trie that lets you look for words starting from any point, rather than just the middle. This lets you traverse the board in a slightly complex, but deterministic, way.

It was one of the most rewarding projects I ever worked on. GADDAGS are memory-hungry, so I naively implemented them using Erlang data structures. This was fine for trying the algorithm, but was hardly workable in practice: it led to ~300MB allocations if you were to mutate them (and an edge case required that I did). Since it’s essentially a read-only structure, I defined a compact binary format for a GADDAG and wrote code on the Erlang side to interface with it. See code/server/lib/bingad for a C program to generate a binary blob GADDAG from a dictionary file, and code/server/src/bin_tries.erl for how we interface with it. This shrunk the structure to ~30MB, without superflous allocations at runtime.

I also learned about the Zen of Erlang. The first version of the program was naked executions of BEAM files, and I later worked to use proper OTP principles. Much of the codebase reeks of “Baby’s First Erlang,” but working through this taught me exactly why the Erlang VM and the OTP libraries form such a fantastic little environment.

I also wrote a Spaghettitacular Ruby client, using an ncurses library.

Altogether, so much fun.


This is a simple Markov chain bot, taking in a Twitter username as input, and posts tweets to an account where you have write access. There isn’t much to this one, but I did write all my own OAuth code for access, which was buckets of fun.

I wrote on Markov chains, trying to make it accessible to non-engineers here.

For a higher-level engineering audience, the most interesting part is the OAuth, since until you implement it yourself you can’t really get a proper appreciation for how it achieves it’s goals of verifying access credentials without revealing them to the third party. You also see the motivation for OAuth 2…


Most of us are pretty jaded having been on Hacker News or /r/programming and seeing a million “Why I switched to X” articles. That said, a few have really shaped how I approach programming in industry.