Skills

Please select a programming language, computer system, or miscellaneous skill below to get a brief description of my experience.

PythonJavaScript and ReactJavaHaskell
GitLaTeX
Blender(Neo)vim

Python

I’ve enjoyed using Python professionally since 2014, and personally since around 2011. It’s my almost-exclusive tool of choice for exploring a data set and for most one-off scripts or tasks. I’m consistently impressed by Python’s design: the abstractions that the language core chooses to support always seem to have a deceptively high power-to-weight ratio, and of course the standard libraries are excellent and abundant.

Most of my work on the Khan Academy website is in Python. Of that work, much is related to the core site infrastructure (in particular, the content model), to the streaks functionality, and to the thumbnails system.

My hobbies include chaining decorators, doing terrifying things with metaclasses, and linking people to hasattr: a dangerous misnomer.”

JavaScript and React

Some relevant projects include:

Java

Java is the language that I’ve used for the longest time. I’ve often used Java when I want it to be easy to write a GUI for a desktop application. (These days, I also use React for the same purpose.)

I was an editor on the third edition of Effective Java by Josh Bloch, published December 2017.

Some relevant projects include:

Haskell

I’m reasonably comfortable in Haskell after having dabbled in it since around 2013. I use Haskell frequently for pipes in Unix command lines, and also for standalone utility applications.

I’ve written such things as the game of Go (as well as a simpler Unix filter to colorize gnugo) and a Scheme-like language. I also wrote a Haskell program to solve a graph theory problem, which doubled as a Haskell tutorial for a CS-inclined math-major friend of mine. (The source is here.)

Git

I tend to use git for the vast majority of my work, even if I don’t intend to push it to any remote. My workflow is to rebase aggressively: I prefer to keep a clean history where each commit is atomic, minimal, and has no lint errors or test failures, instead of a more literal recording of my keystrokes. For example, I recently fixed all lint errors in every commit of a (local-only) repository easily via an interactive rebase.

Similarly, I prefer to keep coarse-grained branches, corresponding more to “project” than “feature,” so that I can more easily curate that history by bouncing around in a rebase. (If I want a literal history, I’ll consult my persistent undo files!)

I try to post most of my work on GitHub, unless restricted by confidentiality or academic integrity.

LaTeX

I’ve used LaTeX exclusively for all my documents—notes, homework, papers, presentations—since 2013, and haven’t looked back. When I have the time, I especially enjoy creating scientific diagrams with TikZ and related packages…here’s a gallery of some of my favorite pages over the years.

My personal style files are on GitHub.

Blender

I enjoy using Blender for all the 3D modeling that I do—which is not much—but I’ve also found it to be a valuable tool in many more contexts than one might expect. For example, I’ve used its powerful image compositing tools to perform batch transformations, used it as a simple cross-platform standalone video editor, and used its modeling and animation tools to mock up designs. It’s a beautiful and versatile software package that many developers could probably benefit from learning.

(Neo)vim

(Vim users are contractually obligated to announce this, right?) Anyway, I’ve used vim exclusively for a while, and have been even happier after moving to Neovim, primarily because of its excellent built-in terminal emulation, its significantly faster startup time, and all the little things that it fixes that make me smile.

Many people have asked me for my .vimrc file. To new users of vim, I always respond that my .vimrc file is on GitHub, and that they should feel totally free to read from it, and to type any portions of it into their own .vimrc files, but not to paste things in directly. The point of the file is to enable you to configure vim how you want it; if you don’t learn how to do that, you’ll be shirking its potential.