{"id":50779,"date":"2026-01-22T16:51:59","date_gmt":"2026-01-22T21:51:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=50779"},"modified":"2026-01-23T17:46:06","modified_gmt":"2026-01-23T22:46:06","slug":"lessons-from-14-years-at-google","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/01\/22\/lessons-from-14-years-at-google\/","title":{"rendered":"Lessons From 14 Years at Google"},"content":{"rendered":"

Addy Osmani<\/a> (via Hacker News<\/a>):<\/p>\n

\n

User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock.<\/p>\n<\/blockquote>\n

I wonder how much this happens at Google and Apple these days.<\/p>\n\n

\n

The quest for perfection is paralyzing. I’ve watched engineers spend weeks debating the ideal architecture for something they’ve never built. The perfect solution rarely emerges from thought alone - it emerges from contact with reality. AI can in many ways help here.<\/p>\n

[…]<\/p>\n

Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance.<\/p>\n

[…]<\/p>\n

With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.<\/p>\n

This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n