Last updated in December of 2020.
It's taken me a while to acknowledge it, but I've eventually comes to terms with it: I like work. Well, at least when I have a big say in what I'm working on. I like thinking about difficult problems. I like building things that people can use. And I like putting finished products out for the world to see.
Currently, a lot of my work time is focused on two startups Wavve and Floom. Wavve is a tool for podcasters to turn their audio clips into videos for sharing on social media. I'm one of the three equity partners at Wavve. We've had a lot of success with Wavve - we recently passed $1M in ARR. The product itself is a simple enough idea, but we've managed to separate ourselves by doing it better. Having a relentless focus on the user experience and content marketing. And we've done some really cool things with serverless tech to keep our server costs minimal.
Floom is a API-driven platform built for developers to make launching SaaS products as easy as possible. When you're building a SaaS product, there is a ton of overhead. The goal of Floom is to cut this down as much as possible, so developers can focus on their unique product. I'll summarize this neatly in a venn-diagram below.
I did an MSc at Oxford in, and I quote, "Mathematics and the Foundations of Computer Science". This is a unnecessarily long name for some mix of machine learning, cryptography, and game theory. It was awesome to have a solid chunk of four months where I could work on my own research project. I developed a novel model to measure and reduce the effects of "teaching to the test". My model extended upon Stackelberg Security games, which have been recently developed and implemented to improve airport security. I appled the same theory within the context of student assessment to minimize the effect of teaching to the test. I then layered a model based on the knapsack problem to quantify the effects of teaching to the test for students of different proficiency levels. If you're feeling inspired, you can see the whole thesis here.
I did research at the Human Computer Interaction Lab at the University of Maryland under Jon Froehlich, who continues to create amazing work in this space. There, I worked on scalable methods for tackling accessibility problems that disabled travelers face. This included a project called Tohme, published in ACM's UIST which combined machine learning, computer vision, and custom crowdsourcing interfaces layered on top of Google Street View to scalably locate intersections with missing curb ramps.
Speaking of machine learning, I find it especially exciting because its making huge impacts but is still so much an unrefined and "bottom-up" science. We don't really know why a lot of it works. At the same time, its extremely accessible. Anyone with a laptop can modify existing network layouts or test out a new theory. I'm doing nights and weekends research on ordinal-categorical classification problems and recursive neural nets.
Data visualization is how I first got into coding. It has all the right components for me: math, design, stats, and great deal of psychology are all at play. My grounding philosophy when creating visualizations is show, don't tell. Many of the pioneers of data visualization (looking at you Tufte) tied the effectiveness of a graphic to its ability to accurately convey data. But data visualization is way more than just that. It should inspire, and captivate, and delight. Visualizations should get at some truth and make people feel that truth. Humans have a natural capacity for and seeing trends and understanding causal relationships (perhaps to a fault). On the other hand, we're terrible with big numbers and lots of numbers numbers. I create visualizations for humans, helping with what we're bad at, and allowing people to do what they naturally do best.
I'm very bullish on serverless technology. It's created a path for developers to deploy code without needing to know the ins and outs of spinning up a web server, managing load balancers, and SSH-ing into servers to track down logs. It's an order of magnitude improvement in the work required to go from code running locally on your machine to deployed (and scalable) code running on a server. I've doubled down on serverless tech with Floom. Not only is Floom built on serverless, but its entire premise bets on taking serverless to the next step - allowing developers not just to go from local code to deployed code, but also to productized (and monetized) code. Using this launch stack, I've been able to launch a dozen micro-products on Floom. You can read about how I went from 0 to launch in 14 hours with Squawk, the first Tweet to video tool.
My preferred front-end tech stack is VueJS and the Element UI component library. This stack is behind Wavve.co, Floom.app, Duplikit.app, and this site. I've spent significant time developing with both VueJS and React in a professional setting. I prefer VueJS over React 100% of the way. React is too agnostic. It doesn't make any decisions. And for every component you want there are 10 different open source libraries. Which is cool, but I don't want to have to make a decision every time across 10 components which are more or less the same. I think VueJS hits the perfect (or close to it) balance of convention and configuration. And single-file Vue components are awesome.