Social media is supposed to foster meaningful human connections, but today it's dominated by posturing, superficiality, and popularity contests.
Matter is different: it's an anonymous environment where you can be candid about your experiences and connect with others in positive ways. You can learn more at mttr.to.
If this piques your curiosity and you want to talk shop, let's do it! I like getting emails out of the blue, so don't be shy: firstname.lastname@example.org.
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.