About this blog

Hi there. My name is John Kerl; I'm a software engineer working in the D.C. area.

I'm interested in nimble, polyglottal software design and implementation. The application domains (the goals, the what) I most gravitate toward are bimodal: low-level systems, and mathematical/numerical methods. But left to my own devices I'm as likely to engage in tool-building (this is the how, independent of application). I'm happy when my work has a multiplicative effect, enabling many people to work more efficiently.

Currently I'm most comfortable with Go, and more generally prefer strongly typed languages: TS/Flow over JS; Hack over PHP; Python's typing module is a powerful addition to the language. I say polyglottal because there are different tools for different problems. It's important to be able to pick up someone else's useful code, and leverage their time investment, in spite of a language difference. Moreover, I've always been fascinated by human languages: despite all their differences in word order, pronunciation, and so on, ultimately they all come to make sense when they are studied for a while. Ultimately they are all just superficially different ways to speak human. Programming languages, on the other hand, vary more in their capabilities: while most are good for many tasks -- any of them can print "Hello, world" or factor integers -- the differences run deep, from learning-curve time, to runtime, to the way they encourage project-busting worst practices or project-saving best practices. Nonetheless, what programming languages have in common is that they are all ways to systematically encode and automate human thought.

I say nimble because I believe we as software developers spend an awful lot of time being in our own way: debugging, head-scratching over others' code, head-scratching over our own code, waiting for compiles, and so on. Remedies include agile-scrum development, unit-testing, documentation, and self-explanatory code -- but also the choice (or invention) of the right tools and/or languages for the job. I've found that putting in small amounts of additional effort at carefully chosen points, early in a project, saves far more time than it costs. This creates more time for tomorrow.

The word exegetotrope is a compound of exegesis, meaning explanation (especially of holy texts), and the trope from heliotrope, meaning tending or turning toward. This is because when I figure something out, I have an innate tendency to want to explain it -- and in the simplest possible way (but no simpler).