My last post here was about building a data binding framework for Android. That was March 2013. Android was on KitKat, React hadn’t been open-sourced yet, and I was still convinced that mobile apps needed XAML-style data binding to succeed.

Narrator: They didn’t.

What Happened?

Life, mostly. Looking at my old posts, I can trace the arc: I was evangelizing Parse, building pitch pipe apps for barbershop singers, and trying to make Android development feel more like Silverlight.

Then Facebook acquired Parse. I stuck around for the ride, helped with identity products, and eventually tried my hand at being a startup founder. I spent a year building Hoomi, an identity platform that gave users control of their digital identities. It didn’t work out—turns out competing with “Login with Google/Facebook” is tough when you’re a team of two, and when people still trusted Facebook with their privacy. Simpler times.

After that humbling education, I joined Firebase—Google had just acquired them, and it felt like fate. Here was the spiritual successor to Parse, the chance to pick up the backend-as-a-service mission where we’d left off. “We’ll help them democratize app development,” I thought. “How hard could it be to change how developers build software?”

Turns out the answer is: hard in the best possible way.

Oh, and somewhere in there I got married (2016) and had three amazing kids—now 7, 4.5, and 3 months old. Talk about transformative experiences. Nothing teaches you about scaling systems, managing resources, and graceful degradation quite like having three children. Or about the importance of clear documentation, for that matter. Try explaining why the sky is blue to a 4-year-old while debugging production issues and feeding a baby.

Last month, I hit my 10-year anniversary at Google.

The Missing Decade

Since my last post about Android data binding, I’ve had a front-row seat to some fascinating evolutions:

Firebase transformed from scrappy startup to the default platform for millions of developers. I led the SDK team through major developer experience overhauls, open-sourced everything, and somehow made real-time sync feel boring (in the good way). I also became an engineering manager here—turns out leading humans is harder than debugging race conditions. Though growing up with a therapist for a mother and sister meant I’d been training for this my whole life. Who knew that talking about feelings and relationships at every family dinner would become a professional superpower? Becoming a parent only reinforced this: the skills that make you good at helping a senior engineer navigate career anxiety are surprisingly similar to helping a 7-year-old process why their Magna-Tiles tower got destroyed by their sibling.

Over 5.5 years, I ran the API council that reviewed 800+ proposals across every language, ecosystem, database schema, CLI command, and REST API that Firebase shipped. If you’ve used Firebase and the APIs made sense, you’re welcome. If they didn’t, well, you should’ve seen the first drafts.

What I learned: You can think strategically for the organization—scale, revenue, market position—while still keeping developer empathy at the center of every decision. The best platforms win because they never forget who they’re building for.

Voice platforms promised to be the next frontier. I spent a year trying to help Google Assistant become a developer platform. We learned a lot about why some platforms take off and others… don’t. Spoiler: great technology isn’t enough—you need to meet developers where they are, not where you wish they were.

Android development completely transformed. Remember when I was trying to hack data binding onto Android? Now it’s built in. Along the way, I helped reshape how Google Play Services delivers developer features to billions of devices and millions of developers. The lesson? Sometimes the platform won’t solve your distribution problem—so you get creative and build a better delivery truck. Play Services became Android’s vital tool for reaching developers despite OS fragmentation.

Cloud platforms became the default. I now lead the team building client libraries for Google Cloud—helping developers navigate 100+ services without losing their minds. Here we’re learning to scale great developer experience across a massive portfolio, rather than crafting bespoke, artisanal APIs. It’s industrializing developer empathy.

The AI Inflection Point

But the biggest change? AI went from research papers to pair programmer.

Not just the obvious stuff—yes, Claude, GPT, and Gemini can fix my Python indentation. The profound shift is how AI rewires the entire stack of software development. What happens when every developer has a brilliant pair programmer? When code generation is instant but code understanding still takes years to develop? When the scarcest resource isn’t coding ability but taste and judgment?

Firebase and Parse made things that required a backend team suddenly achievable by a solo developer. AI is doing the same thing, just at a dramatically larger scale—making capabilities that used to require entire engineering organizations suddenly accessible to anyone with an idea. We’re not just removing friction; we’re collapsing the cost and complexity of building software by orders of magnitude.

As an engineering leader, these aren’t hypothetical questions anymore. They’re the decisions that shape how we build teams and products today. Which brings me to why I’m writing again.

Why Break the Silence Now?

Three things pulled me back:

1. AI is rewriting the rules. We’re living through the biggest shift in software development since Stack Overflow launched. I’m trying to figure it out too, and writing helps me think.

2. Platform lessons are evergreen. Whether it’s Silverlight at Microsoft, Parse at Facebook, Firebase at Google, or my own failed startup, the patterns repeat. After nearly two decades of building platforms at scale (and watching one fail up close), the lessons are worth sharing.

3. The barbershop principle still applies. In my 2013 post, I wrote about how barbershop harmony helped my tech career. Twelve years later, that’s even more true. The best engineering insights often come from outside engineering. The best leaders have lives beyond their laptops.

What’s Next

I’ll be writing about what I’ve learned at the intersection of developer tools, engineering leadership, and the AI transformation:

  • How to build engineering orgs where people grow, surprise themselves, and create artful solutions that developers love
  • Why some developer tools win hearts while others just win benchmarks
  • What AI actually changes about software development (and what it doesn’t)
  • Leadership lessons from the trenches of platform wars (and startup graveyards)

No posting schedule promises. But I have hard-won insights worth sharing.

The tools have changed—that Bindroid framework I was so proud of is hilariously obsolete—but the core challenge remains: How do we democratize development and give developers superpowers?

Nearly 20 years of building platforms. Ten years at Google.

Time to start sharing what I’ve learned. I’d love for you to join the conversation.

Find me on LinkedIn and X for more frequent thoughts, or dust off your RSS reader and subscribe. Yes, RSS still works. Yes, I’m keeping it.