A few co-conspirators and I are looking to change the way that companies develop and interact with distributed systems. With the push towards SaaS products and virtualized infrastructure, distributed systems are no longer the exclusive domain of minted mega-companies: indeed, they are now the bread and butter of software development at any and every scale. We see huge gaps in this new landscape and plan to fill them with an indispensable product or two.
If any of the above piques your curiosity and you want to talk shop, let's do it! I enjoy receiving emails out of the blue, so don't be shy: email@example.com.
I graduated from Brown in 2003 with a combined degree in Math and Computer Science. While in school, my studies focused on computer graphics, machine vision, and operating systems, and I worked most closely with Michael Black and Andries van Dam. I accepted a software engineering job offer from Google in my final semester at Brown, and I joined them immediately after a three month summer internship at Microsoft Research in Silicon Valley (where I worked under the direction of Michael Isard).
I spent my first two years at Google alternating between a state of awe regarding my new colleagues and a state of disappointment about my actual project work. To make a long story short, we were trying to solve too many problems at once, and though I learned a great deal about software engineering, technical leadership, and product positioning, I eventually decided to set sail for the land of large-scale distributed infrastructure.
From 2005-2008, I built an always-on distributed tracing project called Dapper; it began life as a proof-of-concept prototype, but over the years I fleshed out the technology stack and built a team of twelve (you can read the paper some colleagues and I later wrote about it at bit.ly/google_dapper). Dapper became — and still is — a core technology at Google; it helps developers make sense of distributed systems that often involve 10K-100K distinct processes.
In 2009, I brought together a small core group to build a large-scale (~100K process) and high-availability timeseries collection, storage, and query system, as well as a configuration and console toolchain layered on top. That group eventually grew into a 20-30 person engineering team that I led, and the technology we developed is rolling out as Google's company-wide monitoring architecture. I worked on this project (which must remain unnamed and largely undescribed in this public setting, unfortunately!) up through the end of my time at Google. It was fun engineering work, but...
When I left school I had intended to build products that could improve people's lives on a large scale, and yet I found myself building gigantic systems that, despite their importance to the company, were mostly invisible outside of Google. In late 2012 I took a position at a startup founded by an old colleague of mine. I worked there full-time for about 8 months, and although I am now focused on my own project, I am still involved as an advisor; I mainly help them with engineering strategy and architectural decisions. I treated my experience as a startup employee as a continuous learning opportunity, mostly in non-technical areas (marketing, PR, business development, recruiting), though I also valued the opportunity to catch up on non-Google technology stacks.
I would like to live in a world where technology facilitates introspection and meaningful new connections. Matter was an attempt to nudge our world in that direction. My team and I saw behavior within Matter that seems unprecedented, at least to us; it's a (still extant) community that shares anonymously and intimately, yet safely and non-judgmentally. This took a lot of hard work and iteration, and we're proud of what Matter represents. Download the app for iOS if you'd like to see for yourself.