tags: None
categories: None

I am a software engineer specializing in API and Library design, distributed systems, and web applications development.

I currently work as a Senior Platform Engineer on Refinery29’s analytics team, where we are a building out our next-generation business intelligence infrastructure. We are using Scala, Akka, Aerospike, CouchDB, and BigQuery for our ETL pipeline, and are providing a REST API using Python for developers and data scientists to leverage our systems with, as well as client libraries in Python, Scala, and NodeJS (all technologies used at Refinery29).

Before working on my current project, I was on the mobile web team, working alongside our team lead to architect Refinery29’s brand new mobile experience. My primary responsibilities included overseeing technical architecture, as well as working on a lot of tooling around making things like test-driven development easier, leading to this presentation

The only technologies I use are the right ones for the job

While I love Scala, Javascript, and Go, the languages and tools I love the most are the ones that are the best fit for the job at hand. For example we were a bit skeptical on Scala at first at Refinery29 because it is typically harder to find developers for that language as well as maintain an infrastructure for it, but the benefits and out-of-the-box wins we got with Akka, as well as the enormous ecosystem inherited from the JVM far outweighed the costs. Currently I’m interested in exploring more on cooperative concurrency techniques and their benefits over traditional preemptive methods in I/O-Bound applications.

I have experience working on, and leading, agile, effective teams

I think it’s best when there’s just enough process to allow the developers to work effectively. I do not believe you can stroll onto a team for a few days and then slap a big label on how the team should operate, subjecting devs to all of this nonsense work that doesn’t at all benefit the product they are working so hard to build. Minimizing process overhead fosters a collaborative environment, an organic culture, and the opportunity for developers to take the time they would have labeling tickets and making graphs and putting it to use on much more beneficial ventures, such as working on open-source projects or writing blog posts. This is the process we use on the analytics team. That, and hard cider during our retros/sprint planning :)

I have devoted my life to developing software. Even if it that software just means less emails during lunchtime.

More on that here