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.
- Don’t Call Yourself A Programmer, And Other Career Advice, by Patrick McKenzie. I was pretty bright-eyed and bushy-tailed as a college graduate, and I feel that this is a pretty no-nonsense look into what coding for industry can be like.
- How many Microsoft employees does it take to change a lightbulb? by Eric Lippert. Another ‘college is not industry’ one, it expresses very clearly how challenging working for a BigCo can be. The StarCraft community loves to tell Blizzard that they’re lazy for not implementing X, which should take 10 minutes, and I always link them to this article.
- Tough Times on the Road to StarCraft, Parts 1, 2, and 3. All of Patrick Wyatt’s articles on game development from that time at Blizzard are pretty amazing.
- A Generation Lost in the Bazaar, by Poul-Henning Kamp. I don’t care that ‘Worse is Better’ won the macro game, we should all still care about quality in the micro game.
- Don’t waste your time in crappy startup jobs., by Michael O. Church. The author had a bit of a reputation after a bad stint with Google as a bit of a self-important gasbag, and I don’t think that’s necessarily untrue, a) let’s forgive the young, as that was years ago, b) Google as a work environment, speaking from experience, can make you appear like someone you aren’t, and c) virtually everyone I know in tech who I’ve ever liked can be a self-important gasbag. I’ve appreciated many of his essays, and this one especially.