Why it took 3 months, 90 changelists, and an auto-rollback in Google Maps to unlearn my bad coding habits.
I’m an Outcome Customer Engineer at Google Cloud, but I recently spent 3 months earning "TypeScript Readability"—Google’s notoriously rigorous code-quality certification. It took 90 PRs, completely unlearning my "move fast" startup habits, and surviving a massive auto-rollback while migrating a core Google Maps API. Here is what I learned about writing truly enterprise-grade TypeScript.
Yesterday, April 17, 2026, I achieved a milestone I’ve been grinding toward for months: I officially earned TypeScript Readability at Google.
For those outside the company, Readability is a peer-reviewed certification process. It ensures an engineer writes code that perfectly aligns with language idioms, strict style guidelines, and enterprise-scale architectural standards. Out of the tens of thousands of software engineers at Google, I’m roughly the 3,700th person to earn it for TypeScript.
The twist? I’m not even a full-time Google SWE. My day job is an Outcome Customer Engineer for Google Cloud—a role where we typically don’t commit to the core Google codebase at all.
Before joining Google, I spent a year working as a full-time software engineer at a startup. I thought my TypeScript skills were pretty solid. But transitioning from "startup speed" to "Google rigor" humbled me in the best way possible. Here is what it took to bridge that gap.
The Startup Hangover
At a startup, the primary directive is survival. You move fast, ship features, and if the code works and the linter doesn't yell too loudly, you merge it.
Google’s massive monorepo is a completely different beast.
At a startup, code is often written for a machine to execute. In a massive monorepo, code must be written for 100,000 other engineers to read, trust, and safely modify.
To earn Readability, the median Google engineer takes about 19 CLs (changelists).
It took me 44 readability-approved CLs!
In total, I authored 90 CLs over nearly three months. The delay wasn't because I didn't know TypeScript syntax; it was because I had to completely unlearn my startup habits. I lacked the necessary rigor in exhaustive documentation, code comments, and advanced type-system architectures.
Sweating the Micro-Details
Through relentless feedback from my reviewers, I learned to sweat the semantic micro-details. At enterprise scale, every keyword matters.
1. Semantic Intent: array find vs filter
In startup land, I’d often grab the first matching item in an array like this:
const activeUser = users.filter(user => user.isActive)[0];It works, right? But my reviewers quickly pointed out that this is an anti-pattern. .filter() iterates through the entire array and allocates a brand new array in memory, just for you to throw away everything but the first element.
const activeUser = users.find(user => user.isActive);Always optimize for semantic intent. .find() doesn't just perform better by short-circuiting; it instantly tells the next engineer, "I expect exactly one item here."
2. Safety First: The Dangers of “!”
I was guilty of occasionally using the non-null assertion operator (!) to silence the TypeScript compiler when I "knew" a value existed.
const userEmail = fetchUser()!.email;The non-null assertion operator (!) is a major code smell at enterprise scale. Forcing the compiler to "just trust you" that a value isn't null is a fast track to a global production outage.
Instead, I was pushed to master strict safety using optional chaining and proper type narrowing:
const userEmail = fetchUser()?.email;3. Exhaustive Documentation
I learned that writing code without explaining the "why" behind business logic is unacceptable. Consistent constant/variable naming styles and meticulous comments aren't "nice-to-haves"—they are the backbone of a maintainable monorepo.
The Cross-Company Tour
To prove I could apply these standards, I didn't just write dummy code. I contributed to actual production systems across multiple Google Product Areas:
- Migrating tests for Google Colab.
- Developing features and enforcing hermetic testing for the Google Cloud Console (NetApp Volumes).
- Migrating Angular core components to modern APIs like
inject()and signals.
But my final graduation project was the ultimate test.
The Final Boss: Maps API
To finish my certification, I joined the effort to migrate modules within the highly user-facing Google Maps JS API.
Early in my Maps contributions, I tackled the Overlay module. I wrote the types, got an approved CL, saw that my local and global presubmit tests were green, and submitted the code.
Almost immediately, the global CI/CD system detected a hidden downstream breakage in production caused by my change and triggered an auto-rollback.
Seeing your code automatically ripped out of the repository by a system safeguard is a deeply humbling experience. But it is also the ultimate safety net.
The hidden downstream dependencies that triggered my auto-rollback actually exposed edge cases that the core US-based Maps Engineering team wasn't fully aware of. My "failure" resulted in net-new architectural learnings for the very team that maintains the API. But more importantly, it taught me a crucial enterprise skill: respecting the blast radius.
Respecting the Blast Radius
I carried that hard-earned lesson into my ultimate graduation project: migrating the Maps Street View module.
Coming from a startup, I would have historically tried to migrate this entire module in one "big bang" changelist. But knowing what I now knew about Google-scale dependencies, I completely changed my strategy. I deliberately rescoped the effort to migrate just half of the Street View module to tightly isolate any downstream impacts.
Even with that reduced scope, migrating half of the module has taken 2+ months of rigorous global testing, defensive programming, and cross-timezone collaboration.
Moving fast and breaking things is great for a startup; but when you're working on Google Maps, you move deliberately, test globally, and split your changelists.
Bringing SWE Rigor to Customer Engineering
Earning TypeScript Readability was one of the most grueling technical challenges of my career, but doing it while balancing my day job as a Customer Engineer was entirely worth it.
I can now look my Google Cloud customers in the eye and advise them not just on high-level cloud architecture, but on the micro-details of enterprise-scale code quality, CI/CD rigor, and blast-radius management.
Huge thanks to my Readability reviewers and the amazing engineering teams across Colab, Cloud Console, Angular, and Maps who trusted me with their codebases.
Now, if you'll excuse me, I still have the other half of that module to migrate. 🚀