Beyond the Noise – Ryan Cooke
Matt Klein: Welcome to another episode of Beyond the Noise: Signals, Stories, and Spicy Takes, the show where we dig into the stories of the people shaping the future of app-based computing, with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as the founder of Envoy Proxy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and we'll wrap it all up with their hottest takes. So let's dive in.
Matt Klein: Today I'm thrilled to have with us Ryan Cooke, a Director at Pinterest, where he manages the Client Foundations org. His teams are responsible for the behind-the-scenes work necessary for Pinterest's Android, iOS, and web apps to be successful. Welcome, Ryan. Thank you so much for joining us.
Ryan Cooke: Glad to be here. Thanks for having me.
[00:00:53] GETTING INTO MOBILE ENGINEERING
Matt Klein: You've had a pretty epic career working at a variety of companies. I'd love to learn how you got into mobile engineering, what excites you about mobile, and how you got to where you are today.
Ryan Cooke: I went to an in-state college, and for my first couple of years of my CS degree I was fine, enjoying it. But something clicked around my junior year when I discovered I could actually build websites. It went from just doing the assignments to every weekend working on some silly side project.
Ryan Cooke: The switch to mobile happened because I did not like doing UI. This was before Bootstrap was popular, and I was not very good at it — it always looked hideous. I'd build cool functionality, scrape some API, and then it looked so bad I couldn't show anyone. Mobile had a more constrained design system that gave me a simpler path to something presentable. That's probably also a spoiler for why I always end up doing behind-the-scenes work on mobile.
Matt Klein: There are plenty of mobile apps with bad interfaces, so it's a spectrum.
Ryan Cooke: Right, I wasn't winning awards for my mobile UI either, but it was less distracting. I gravitated specifically toward Android because I was a poor college kid and didn't have a Mac. I enjoyed building the projects more than the idea of them being popular — it was half for my friends, half just for the love of building things.
[00:03:22] EARLY CAREER AND THE MOVE TO SAN FRANCISCO
Ryan Cooke: Entrepreneurship seemed like an intuitive route after college. I did an accelerator briefly, then joined a startup in Miami as their first hire. It's not one that's still in business. Being the first engineering hire at a company with a non-technical founder and iffy technical backgrounds wasn't the best learning ground — a lot was built on WordPress, for example.
Matt Klein: For your first job, were you doing mobile development or everything?
Ryan Cooke: They were full-stack at the time. I flirted with building a mobile app, but web was the first launch, so I was doing a lot of everything. That mentality served me well, but the actual technical learnings were limited — there were poor practices I didn't even know were poor practices. After that I built a side project app that got a few thousand users, and I thought, maybe this is something.
Ryan Cooke: I joined a small Southeast accelerator — not Y Combinator, but they helped with the legal pieces. Looking back, I wasn't in a tech ecosystem at all and didn't have a basis for comparison. I thought 5,000 users meant I was going to be big time. It isn't — not without a lot more revenue behind it.
Ryan Cooke: At the end of the accelerator I went to San Francisco to meet the tech ecosystem. In the Southeast I'd always heard "you don't need to go out west, we have our own hub here." But it was night and day. The investors I'd pitched in the Southeast didn't know anything about tech — one was a rich wine guy throwing money at random projects. In San Francisco, even the Uber driver was building a startup with a fascinating story. The people you meet spontaneously were more able to help than anyone in my whole previous ecosystem.
Matt Klein: Was there an app you were actively pitching, or did you go out because you thought it would be a better environment?
Ryan Cooke: I was near the end of the rope on an app. I'd burned through the accelerator money and hadn't seen growth from the initial user base. I was pitching an app called Track It — a tool to log everything in your daily life and generate insights, like correlating headaches with poor sleep. I still thought it was fun but it was maybe too hard to input data. I was also just seeing the ecosystem. What I loved about San Francisco was how many people genuinely believed they could change the world, combined with a lot of talent. I was staying in Airbnbs with four people to a room, and everyone had a "I'm going to change the world with my yoga video chat app" energy. I found that inspiring.
Ryan Cooke: I also realized I didn't have a lot of the building blocks for entrepreneurship. All my mobile development was self-taught, never done in a professional setting, and I'd never seen a successful fundraise up close. So I joined UrbanSitter as their first Android engineer. I built their Android app and eventually became Android tech lead as we hired more Android folks. I had some really great technical mentors there who helped me catch a lot of flaws in how I was thinking about coding.
Ryan Cooke: An amusing interview story: I interviewed at Goodreads and UrbanSitter on the same day, and they asked the exact same whiteboard question. When I walked into the UrbanSitter room and saw it laid out, I was honest and told them I'd just done this exact question that morning. They appreciated it, had me outline the solution, and then gave me a fresh one on the spot.
Ryan Cooke: I only stayed about a year and a half, which was a pattern at that point — I hadn't stayed anywhere longer than that. I'd also had a weird amount of leadership for someone with only two or three years of experience, because at both companies I made almost all the decisions myself.
[00:12:13] JOINING PINTEREST
Ryan Cooke: A friend who had left UrbanSitter for Pinterest told me Pinterest was going international and suddenly cared about Android. Pinterest was pre-IPO and very well-positioned, so the move made sense. It was a very different environment. UrbanSitter had nine engineers when I left; Pinterest had around 30 just on Android. I've been promoted quite a few times since.
Ryan Cooke: I was probably one of the most annoying junior engineers ever. In my first six months I made this huge document of things we needed to prioritize as an app. As a director now, I think I'd be thankful to get that and try to channel the energy in the right direction, but a lot of it was very impractical — like, let's redo all the architecture to add testing.
Matt Klein: Having been a younger annoying engineer myself, I don't think it's a bad thing. People who do well over time tend to share that trait, and fresh eyes can be valuable.
Ryan Cooke: I agree, especially past the junior levels — what we look for is people who own it and think about what should be done, not just what they're asked to do. But finding the right time and place to raise things is a skill you gain as you grow. I've had brilliant engineers stop a meeting to say "you've built this system completely wrong," and the answer is: I love that you're thinking about it, but right now we're trying to solve a bug.
Matt Klein: It's also hard for people to understand all the constraints that led things to be built the way they are. Now that I'm older I appreciate that things were often built a certain way because it made sense at the time. It may no longer make sense, but that doesn't make it wrong.
Ryan Cooke: Definitely. After nine years at Pinterest I can fall into "this is the way we always do it" too. Finding the timing and the place is the tricky part.
[00:17:02] THE IMAGE LOADING PROJECT
Ryan Cooke: My first project at Pinterest had very vague scope, which I enjoyed: make image loading better on Android. Pinterest does a lot of images, so it mattered. An interim manager who clearly preferred being an IC just handed me a list of five things that weren't as good as they should be. I asked whether he wanted two days or two months on it, and he said do it until you stop getting good improvements.
Matt Klein: To know it was bad, didn't you first have to measure it? Did you have enough analytics to know what was happening?
Ryan Cooke: There wasn't great analytics, which became one of the things I focused on. But the basics were visible — you'd see a lot of placeholder images, and the resolution wasn't great. My approach was very non-analytical: placeholders seem bad, let me try prefetching. I can see a difference with higher resolution, let me experiment. Maybe I can adapt to network conditions. I ran about a dozen experiments combining best practices with guess-and-check, and we got a big improvement — even gains in daily active users, which honestly still makes me a little suspicious, since these experiments shouldn't move DAU. There was a clear jump in impressions and engagement. It gave me credibility: put this person on a project and they'll solve it. I even gave a talk at ImageCon about it.
Matt Klein: First shocking thing — there's a conference called ImageCon?
Ryan Cooke: A small single-track conference. I was the guy saying "someone asked me to make images better, so I ran a dozen experiments, here's what worked," while everyone else was presenting on making JPEG 2% more efficient through some encoding deep-dive. Very different expertise levels.
Matt Klein: Could you dig into some of the things you changed? Prefetching seems obvious, but did you look at compression schemes too?
Ryan Cooke: Prefetching was far and away the biggest win. If you're not prefetching, just do it — same goes for network. I was on a performance team for a while, and prefetching is the secret to easy wins. After that we spent a lot of time on resolution. We were often fetching images larger than could be displayed at all, so we looked at the actual display size combined with network quality and found a balance where load time matters a bit more than image quality.
Matt Klein: Did you have your own network testing scheme to determine network quality in the moment and dynamically switch resolution?
Ryan Cooke: Exactly. We grouped network conditions and balanced that against the phone's resolution. None of it was mind-blowing. We tried different formats, but that got much more expensive for diminishing returns — server-side re-encoding, pulling in another team — so we didn't go far down that path.
[00:22:41] METRICS, DATA QUALITY, AND THE IPO
Ryan Cooke: Going back to that Google Doc I made after the image project — the top item was that I didn't trust our data. Little did I know we were preparing to IPO, so that caught someone's attention: you can't have bad data when you IPO. I was put on a tiger team, a code-red kind of group, tasked with making our metrics accurate enough to go public, specifically impressions and active users. It was a dream team, with strong engineers pulled from each platform. We built a system — I posted a couple of blogs on it — to certify a metric and catch issues as they came up.
Ryan Cooke: The first and hardest step is defining the metric. Every platform had a different definition of what counted as an active user, which sounds like the most basic thing in the world.
Matt Klein: You'd think, but it's funny — at bitdrift this comes up often, even from a product perspective. Our active users chart doesn't necessarily match what's in the Play Store. You'd think it's obvious, but it's not.
Ryan Cooke: Exactly. We'd been looking at a list of API requests — hit those, you're an active user. The problem is that every time the number moved, we assumed it was a logging issue, and it usually was, often caused by someone like me adding a background prefetch. It was very vulnerable to dramatic miscounting and hard to verify. So we moved the logic, made consistent definitions, and added layers of tests so inconsistencies would break the build. We also built what we call data checkers. One of the most successful for active users is "unexplained DAU" — if an active user doesn't have something like impressions, we find that suspicious and investigate.
Ryan Cooke: One case we caught: Facebook decided they didn't want to deal with auth tokens expiring, so they set up a system that auto-logged the Facebook-Pinterest extension in the background, roughly monthly. That was actually hitting the UI and refreshing the token, which triggered active-user events for us. We had a spike that was essentially just mobile web loading. That checker helped us narrow it down and find it.
Matt Klein: You learned a lot about the mechanics of effective telemetry and analytics from mobile. There are so many complexities people don't think about. What were the highest-level learnings you'd pass on to others trying to build effective telemetry?
Ryan Cooke: At a high level: document the actual definition of every metric. We've built a centralized tool where every metric links to both the plain-English definition and the official SQL query — for example, the official query to get repins. Without that, two people at the same company pull the same metric and get different numbers because one is spam-adjusting and the other is doing UTC adjustments differently. There's endless minutiae to get wrong, so just aligning on what you're measuring is the most basic, barely-technical thing you can do. Our other layers are UI testing and data checkers, which get harder.
Ryan Cooke: Beyond that: check your metrics. Startups are told to be data-driven, but they need to understand how easy it is to get these things wrong. If something looks fishy, double-check it. And where you can move logging to the server, do so — for saved pins, looking at the database change is more reliable than logging from each client. Database artifacts like the number of bookings are things a user would complain about if they were wrong, so they're more trustworthy. Nobody ever files a bug saying "I opened the app and it counted two impressions when I only saw one."
Ryan Cooke: Stepping back — for both these projects I assumed there'd be a specialist. There are research papers on image loading and on logging accuracy, and here I was, a college person who'd never done this. San Francisco was special here: I'd reach out to the community and talk to people who'd done it. For logging, we worked with Jonathan Maltz, who was at Yelp — they'd already IPO'd and were a step ahead of companies our size. You're often thrown into spots where you don't feel like a domain expert but are asked to be one for a huge user base. My main tip: don't try to figure it out alone in a meditative state. Talk to people, get information, see what's worked.
[00:32:04] THE MOVE INTO MANAGEMENT
Ryan Cooke: We'd also built the testing apparatus at Pinterest, so this became the Metric Quality and Test Tools team. I secretly think I was the third choice for tech lead — the other two were burnt out on the space — but I became the founding tech lead, defined the strategy, and was excited about it. I eventually became a staff engineer, level six, and then shifted into management.
Ryan Cooke: A pro tip: I'd always been transparent with my manager that I wanted to get promoted and was interested in management. On the IC-to-management transition — people go back and forth on it — my draw was that I cared more about impact than the technical complexity itself. I had a coworker deeply into functional programming who left to build a functional cryptocurrency, and that held zero interest for me. What I loved was making a one-line change that halved our out-of-memory issues — nothing clever, but a clear impact. Management was a way to scale that.
Ryan Cooke: My scope grew gradually. We brought in mobile builds because it was a real pain point and I was the closest team to CI. Builds went from people leaving because they took 15 to 30 minutes to rating well on our developer survey. With enough successes, and a strategy of being trusted when people leave, my manager left and I went from one team to three; another manager left and I got their team. Now I manage eight teams indirectly, with managers reporting to me.
Ryan Cooke: The challenge I'm still dealing with: on metric quality and mobile builds I was an expert and could arguably be a staff engineer. But as scope grows you own more — now I own iOS teams, where I would not be a staff engineer. Learning to manage teams beyond your expertise is the next level of management skill: knowing when to trust your partners, and what level of understanding you actually need to make informed headcount decisions.
Matt Klein: To some extent the same applies as you become a higher-level IC. As you move up — whether into management or toward principal or distinguished engineer — there's a lot of overlap. There's ambiguity, and you're leading on things you might not know deeply. At the highest levels it feels like the question is whether you're focused on nurturing people and teams or purely on technology, but there's a lot of overlap.
Ryan Cooke: I mostly agree. ICs have more variety of routes, and you do see people reach high levels as pure specialists. But a common route requires knowing outside your domain. Even specialists get asked to make a call — "I don't need you to be the performance expert, I need you to catch whether something sounds wrong." We have calibrations next week, and the most senior ICs are as important to them as the managers, even though they'd rather be coding. That's the nature of the role as it grows.
[00:38:45] CURRENT CHALLENGES AND AI
Matt Klein: Now that you're managing all these teams, what are the big challenges your teams and the mobile org are facing, from an industry perspective?
Ryan Cooke: Some are classical: all our apps were written ten years ago and we never threw them out to start again. One big initiative this year is getting almost entirely to Swift — the last milestone chunk of Swift code — to let people use the best technology. On the opposite end of boring, the exciting new thing is AI being everywhere, and figuring out how to use it and where it goes. I have a conflicted feeling — as someone always in the weeds, every few months I worry that if I'm not doing enough side projects I don't know how people code anymore. It's strange to feel more disconnected from the development process than before.
Matt Klein: How are you nurturing your engineers to learn these tools and be effective? Things move so fast. I'm neither an AI skeptic nor someone who thinks these are magical gifts from God — they're tools you have to learn to use well. Where we are, we have a Slack room where we teach each other what's working. At a larger org, how do you handle that rollout and make sure the investment is useful?
Ryan Cooke: There's a centralized team whose full mission is this, but I also manage a large group I want to be effective. A lot of what you're describing sounds familiar. We made a virtual team of the people most leaned into AI — the champions — who vet tools and share best practices in Slack channels, one of which I think is called How I AI. We've done pair-programming demos. Being remote adds a challenge: you can't walk past someone and ask why they have a bunch of terminals open instead of an IDE. So having sessions and visibility is most of what we're doing.
Ryan Cooke: As a big org, security is a constraint — we can't just hand out every tool the moment it ships, even if it sounds cool. At one point Cursor was in security review and we wanted to show how it could work on our codebase. So we had a developer work on one of our open source projects on their own device. The risk is code leaking, so this let us understand whether it would solve our problem without that risk.
Matt Klein: Things move fast — you can host models in your own AWS account now, so there are ways to mitigate the risk. But I agree with your security team that it's only a matter of time before there's a petrifying security incident from these tools.
Ryan Cooke: Finding that balance is tricky. The virtual group we put together leans toward "AI is changing everything." They don't literally say "if you type code you're an idiot," they're great people, but they're further along the spectrum. Part of the job is helping them show what they see while applying the right level of skepticism.
Matt Klein: In six months I've gone from thinking these tools were mostly a joke to generating substantial code with them. But they're still tools — they produce garbage if not guided well. There's considerable skill in using them effectively. I don't buy the talking heads who say we'll never have to think again.
Ryan Cooke: I'm similar. For a good while we'll have this "suddenly we can do a lot, suddenly we can get the work we weren't most interested in done" feeling. One recent example: we're migrating from Objective-C to Swift, a great target for AI. Nobody wants to put their promotion case on "I moved this many files." We gave an agent ten hours and it did a migration — landed and shipped. We'd estimated it at three weeks. I'm both terrified and impressed. We're still in the "everybody read the code this time" phase; I'm not yet at the point of having AI review the AI's work.
Ryan Cooke: Another interesting example: we gave the agent to a partner team and their initial take was that it didn't work — maybe for very small files. Then the person who wrote it tweaked it a tiny bit, worked on the same module, and got the whole thing migrated over a day. There's a bias that AI coding means "do all the code for me." There's real skill involved, and unfortunately you have to relearn how to use it every few months as it changes.
Matt Klein: Using these tools is in service of something larger. Beyond moving off Objective-C to Swift, are there other big initiatives your teams are working on?
Ryan Cooke: Test coverage is another prime spot — though we don't want dumb tests, and a lot of training data is dumb tests. Testing and Swift migrations are the two biggest. There are also smaller migrations that never made sense to fund because they'd take too much time. One example: our iOS internationalization handling isn't best practice. It works, maybe causes a bug twice a year — not painful enough to justify a month of work. But if AI can make those kinds of changes across many places, suddenly a project that wasn't worth funding becomes a relatively easy win. Our biggest focus, though, is the very long-running projects eating large amounts of engineering resources, like migrations.
Matt Klein: I meant more broadly than AI — you have a lot of infrastructure teams, so there are presumably build, IDE, or observability problems. Where do you see things going over the next few years?
Ryan Cooke: In the metric quality group, there's an ongoing debate about what it even means for a metric to be accurate, and a lot of partnering with teams and tools to make sure people use the correct metric. We have a short list of the really good ones, but how do we elevate all the boats? There's also a recurring question: what do we do about data that's right and wrong at the same time? For example, someone signs up with today's date as their birthday, or a suspicious number of people are born in 2000. How do we filter to the more trusted records for larger decision-making?
[00:52:11] BUILD TOOLING AND BAZEL
Ryan Cooke: On builds — Bazel was the hot topic maybe five years ago, and still is. We were actually one of the first to run our iOS builds on Bazel, and we moved back, focusing on a very lean build team.
Matt Klein: You used Bazel and then unadopted it? I love this story. Keep going.
Ryan Cooke: It's not that exciting. You generally get better results with Bazel, in my opinion, but you need more staffing and expertise, and every new iOS version requires an extra layer of work. We hadn't staffed the team to handle that, so our ability to update was overly compromised. We refocused on what we could do really well, leveraging native support tools. Each mobile app is in its own repo, so there's less need for Bazel everywhere. We moved back to Gradle on Android and standard toolchain solutions, and we've been generally happy with that, with a few nuances.
Matt Klein: We build the bitdrift SDK using Bazel. It's a complicated build because we have a lot of Rust code and other things going on. We constantly ask whether we should just have a Gradle build and an Xcode build and be done with it. You probably get faster speeds with Bazel, but there's a lot of maintenance.
Ryan Cooke: Yes, for sure. That's the trade-off you have to make.
[00:54:15] NATIVE VS. CROSS-PLATFORM
Matt Klein: Any last thoughts on where the mobile industry is going, or other interesting projects?
Ryan Cooke: In mobile there will always be the code-once-versus-code-per-platform conversation, and there's more exploration of hybrid solutions with Rust shims and the like. That conversation will continue as we keep up with the latest technologies.
Matt Klein: One last question — where do you land on WebView versus native, and the intermediate solutions like React Native and Flutter? There's a lot of circular thinking: WebViews are bad so go native, native takes a lot of resources so go back to React Native or Flutter, but then people make web faster. How do you think about it?
Ryan Cooke: As a default I lean native. We're a big enough company that the scale justifies it. If I were starting my own startup today I'd probably use Flutter or something similar for proof of concept and fast iteration. But once you've found product-market fit, native is still compelling — the ecosystem lets you better solve crashes and avoid mysterious issues. Where we're looking now is whether we can cut out layers of metric quality, since that needs to be perfectly identical across all apps, which is very hard to do in native. We're still exploring whether we can reduce that overhead, but native is the default where we are.
Matt Klein: That's as good a place as any to end. Thank you, Ryan — that was an awesome conversation. That's a wrap for this episode of Beyond the Noise: Signals, Stories, and Spicy Takes. Huge thanks to Ryan for joining and sharing his story. You can find this episode and all past ones on the bitdrift YouTube channel. If you had fun, drop us a review, tell your friends, or yell your favorite hot take into the void — just make sure to tag us. I'm Matt Klein, and I'll see you next time.
Ryan Cooke: Thanks for having me.
Matt Klein: Welcome to another episode of Beyond the Noise: Signals, Stories, and Spicy Takes, the show where we dig into the stories of the people shaping the future of app-based computing, with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as the founder of Envoy Proxy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and we'll wrap it all up with their hottest takes. So let's dive in.
Matt Klein: Today I'm thrilled to have with us Ryan Cooke, a Director at Pinterest, where he manages the Client Foundations org. His teams are responsible for the behind-the-scenes work necessary for Pinterest's Android, iOS, and web apps to be successful. Welcome, Ryan. Thank you so much for joining us.
Ryan Cooke: Glad to be here. Thanks for having me.
[00:00:53] GETTING INTO MOBILE ENGINEERING
Matt Klein: You've had a pretty epic career working at a variety of companies. I'd love to learn how you got into mobile engineering, what excites you about mobile, and how you got to where you are today.
Ryan Cooke: I went to an in-state college, and for my first couple of years of my CS degree I was fine, enjoying it. But something clicked around my junior year when I discovered I could actually build websites. It went from just doing the assignments to every weekend working on some silly side project.
Ryan Cooke: The switch to mobile happened because I did not like doing UI. This was before Bootstrap was popular, and I was not very good at it — it always looked hideous. I'd build cool functionality, scrape some API, and then it looked so bad I couldn't show anyone. Mobile had a more constrained design system that gave me a simpler path to something presentable. That's probably also a spoiler for why I always end up doing behind-the-scenes work on mobile.
Matt Klein: There are plenty of mobile apps with bad interfaces, so it's a spectrum.
Ryan Cooke: Right, I wasn't winning awards for my mobile UI either, but it was less distracting. I gravitated specifically toward Android because I was a poor college kid and didn't have a Mac. I enjoyed building the projects more than the idea of them being popular — it was half for my friends, half just for the love of building things.
[00:03:22] EARLY CAREER AND THE MOVE TO SAN FRANCISCO
Ryan Cooke: Entrepreneurship seemed like an intuitive route after college. I did an accelerator briefly, then joined a startup in Miami as their first hire. It's not one that's still in business. Being the first engineering hire at a company with a non-technical founder and iffy technical backgrounds wasn't the best learning ground — a lot was built on WordPress, for example.
Matt Klein: For your first job, were you doing mobile development or everything?
Ryan Cooke: They were full-stack at the time. I flirted with building a mobile app, but web was the first launch, so I was doing a lot of everything. That mentality served me well, but the actual technical learnings were limited — there were poor practices I didn't even know were poor practices. After that I built a side project app that got a few thousand users, and I thought, maybe this is something.
Ryan Cooke: I joined a small Southeast accelerator — not Y Combinator, but they helped with the legal pieces. Looking back, I wasn't in a tech ecosystem at all and didn't have a basis for comparison. I thought 5,000 users meant I was going to be big time. It isn't — not without a lot more revenue behind it.
Ryan Cooke: At the end of the accelerator I went to San Francisco to meet the tech ecosystem. In the Southeast I'd always heard "you don't need to go out west, we have our own hub here." But it was night and day. The investors I'd pitched in the Southeast didn't know anything about tech — one was a rich wine guy throwing money at random projects. In San Francisco, even the Uber driver was building a startup with a fascinating story. The people you meet spontaneously were more able to help than anyone in my whole previous ecosystem.
Matt Klein: Was there an app you were actively pitching, or did you go out because you thought it would be a better environment?
Ryan Cooke: I was near the end of the rope on an app. I'd burned through the accelerator money and hadn't seen growth from the initial user base. I was pitching an app called Track It — a tool to log everything in your daily life and generate insights, like correlating headaches with poor sleep. I still thought it was fun but it was maybe too hard to input data. I was also just seeing the ecosystem. What I loved about San Francisco was how many people genuinely believed they could change the world, combined with a lot of talent. I was staying in Airbnbs with four people to a room, and everyone had a "I'm going to change the world with my yoga video chat app" energy. I found that inspiring.
Ryan Cooke: I also realized I didn't have a lot of the building blocks for entrepreneurship. All my mobile development was self-taught, never done in a professional setting, and I'd never seen a successful fundraise up close. So I joined UrbanSitter as their first Android engineer. I built their Android app and eventually became Android tech lead as we hired more Android folks. I had some really great technical mentors there who helped me catch a lot of flaws in how I was thinking about coding.
Ryan Cooke: An amusing interview story: I interviewed at Goodreads and UrbanSitter on the same day, and they asked the exact same whiteboard question. When I walked into the UrbanSitter room and saw it laid out, I was honest and told them I'd just done this exact question that morning. They appreciated it, had me outline the solution, and then gave me a fresh one on the spot.
Ryan Cooke: I only stayed about a year and a half, which was a pattern at that point — I hadn't stayed anywhere longer than that. I'd also had a weird amount of leadership for someone with only two or three years of experience, because at both companies I made almost all the decisions myself.
[00:12:13] JOINING PINTEREST
Ryan Cooke: A friend who had left UrbanSitter for Pinterest told me Pinterest was going international and suddenly cared about Android. Pinterest was pre-IPO and very well-positioned, so the move made sense. It was a very different environment. UrbanSitter had nine engineers when I left; Pinterest had around 30 just on Android. I've been promoted quite a few times since.
Ryan Cooke: I was probably one of the most annoying junior engineers ever. In my first six months I made this huge document of things we needed to prioritize as an app. As a director now, I think I'd be thankful to get that and try to channel the energy in the right direction, but a lot of it was very impractical — like, let's redo all the architecture to add testing.
Matt Klein: Having been a younger annoying engineer myself, I don't think it's a bad thing. People who do well over time tend to share that trait, and fresh eyes can be valuable.
Ryan Cooke: I agree, especially past the junior levels — what we look for is people who own it and think about what should be done, not just what they're asked to do. But finding the right time and place to raise things is a skill you gain as you grow. I've had brilliant engineers stop a meeting to say "you've built this system completely wrong," and the answer is: I love that you're thinking about it, but right now we're trying to solve a bug.
Matt Klein: It's also hard for people to understand all the constraints that led things to be built the way they are. Now that I'm older I appreciate that things were often built a certain way because it made sense at the time. It may no longer make sense, but that doesn't make it wrong.
Ryan Cooke: Definitely. After nine years at Pinterest I can fall into "this is the way we always do it" too. Finding the timing and the place is the tricky part.
[00:17:02] THE IMAGE LOADING PROJECT
Ryan Cooke: My first project at Pinterest had very vague scope, which I enjoyed: make image loading better on Android. Pinterest does a lot of images, so it mattered. An interim manager who clearly preferred being an IC just handed me a list of five things that weren't as good as they should be. I asked whether he wanted two days or two months on it, and he said do it until you stop getting good improvements.
Matt Klein: To know it was bad, didn't you first have to measure it? Did you have enough analytics to know what was happening?
Ryan Cooke: There wasn't great analytics, which became one of the things I focused on. But the basics were visible — you'd see a lot of placeholder images, and the resolution wasn't great. My approach was very non-analytical: placeholders seem bad, let me try prefetching. I can see a difference with higher resolution, let me experiment. Maybe I can adapt to network conditions. I ran about a dozen experiments combining best practices with guess-and-check, and we got a big improvement — even gains in daily active users, which honestly still makes me a little suspicious, since these experiments shouldn't move DAU. There was a clear jump in impressions and engagement. It gave me credibility: put this person on a project and they'll solve it. I even gave a talk at ImageCon about it.
Matt Klein: First shocking thing — there's a conference called ImageCon?
Ryan Cooke: A small single-track conference. I was the guy saying "someone asked me to make images better, so I ran a dozen experiments, here's what worked," while everyone else was presenting on making JPEG 2% more efficient through some encoding deep-dive. Very different expertise levels.
Matt Klein: Could you dig into some of the things you changed? Prefetching seems obvious, but did you look at compression schemes too?
Ryan Cooke: Prefetching was far and away the biggest win. If you're not prefetching, just do it — same goes for network. I was on a performance team for a while, and prefetching is the secret to easy wins. After that we spent a lot of time on resolution. We were often fetching images larger than could be displayed at all, so we looked at the actual display size combined with network quality and found a balance where load time matters a bit more than image quality.
Matt Klein: Did you have your own network testing scheme to determine network quality in the moment and dynamically switch resolution?
Ryan Cooke: Exactly. We grouped network conditions and balanced that against the phone's resolution. None of it was mind-blowing. We tried different formats, but that got much more expensive for diminishing returns — server-side re-encoding, pulling in another team — so we didn't go far down that path.
[00:22:41] METRICS, DATA QUALITY, AND THE IPO
Ryan Cooke: Going back to that Google Doc I made after the image project — the top item was that I didn't trust our data. Little did I know we were preparing to IPO, so that caught someone's attention: you can't have bad data when you IPO. I was put on a tiger team, a code-red kind of group, tasked with making our metrics accurate enough to go public, specifically impressions and active users. It was a dream team, with strong engineers pulled from each platform. We built a system — I posted a couple of blogs on it — to certify a metric and catch issues as they came up.
Ryan Cooke: The first and hardest step is defining the metric. Every platform had a different definition of what counted as an active user, which sounds like the most basic thing in the world.
Matt Klein: You'd think, but it's funny — at bitdrift this comes up often, even from a product perspective. Our active users chart doesn't necessarily match what's in the Play Store. You'd think it's obvious, but it's not.
Ryan Cooke: Exactly. We'd been looking at a list of API requests — hit those, you're an active user. The problem is that every time the number moved, we assumed it was a logging issue, and it usually was, often caused by someone like me adding a background prefetch. It was very vulnerable to dramatic miscounting and hard to verify. So we moved the logic, made consistent definitions, and added layers of tests so inconsistencies would break the build. We also built what we call data checkers. One of the most successful for active users is "unexplained DAU" — if an active user doesn't have something like impressions, we find that suspicious and investigate.
Ryan Cooke: One case we caught: Facebook decided they didn't want to deal with auth tokens expiring, so they set up a system that auto-logged the Facebook-Pinterest extension in the background, roughly monthly. That was actually hitting the UI and refreshing the token, which triggered active-user events for us. We had a spike that was essentially just mobile web loading. That checker helped us narrow it down and find it.
Matt Klein: You learned a lot about the mechanics of effective telemetry and analytics from mobile. There are so many complexities people don't think about. What were the highest-level learnings you'd pass on to others trying to build effective telemetry?
Ryan Cooke: At a high level: document the actual definition of every metric. We've built a centralized tool where every metric links to both the plain-English definition and the official SQL query — for example, the official query to get repins. Without that, two people at the same company pull the same metric and get different numbers because one is spam-adjusting and the other is doing UTC adjustments differently. There's endless minutiae to get wrong, so just aligning on what you're measuring is the most basic, barely-technical thing you can do. Our other layers are UI testing and data checkers, which get harder.
Ryan Cooke: Beyond that: check your metrics. Startups are told to be data-driven, but they need to understand how easy it is to get these things wrong. If something looks fishy, double-check it. And where you can move logging to the server, do so — for saved pins, looking at the database change is more reliable than logging from each client. Database artifacts like the number of bookings are things a user would complain about if they were wrong, so they're more trustworthy. Nobody ever files a bug saying "I opened the app and it counted two impressions when I only saw one."
Ryan Cooke: Stepping back — for both these projects I assumed there'd be a specialist. There are research papers on image loading and on logging accuracy, and here I was, a college person who'd never done this. San Francisco was special here: I'd reach out to the community and talk to people who'd done it. For logging, we worked with Jonathan Maltz, who was at Yelp — they'd already IPO'd and were a step ahead of companies our size. You're often thrown into spots where you don't feel like a domain expert but are asked to be one for a huge user base. My main tip: don't try to figure it out alone in a meditative state. Talk to people, get information, see what's worked.
[00:32:04] THE MOVE INTO MANAGEMENT
Ryan Cooke: We'd also built the testing apparatus at Pinterest, so this became the Metric Quality and Test Tools team. I secretly think I was the third choice for tech lead — the other two were burnt out on the space — but I became the founding tech lead, defined the strategy, and was excited about it. I eventually became a staff engineer, level six, and then shifted into management.
Ryan Cooke: A pro tip: I'd always been transparent with my manager that I wanted to get promoted and was interested in management. On the IC-to-management transition — people go back and forth on it — my draw was that I cared more about impact than the technical complexity itself. I had a coworker deeply into functional programming who left to build a functional cryptocurrency, and that held zero interest for me. What I loved was making a one-line change that halved our out-of-memory issues — nothing clever, but a clear impact. Management was a way to scale that.
Ryan Cooke: My scope grew gradually. We brought in mobile builds because it was a real pain point and I was the closest team to CI. Builds went from people leaving because they took 15 to 30 minutes to rating well on our developer survey. With enough successes, and a strategy of being trusted when people leave, my manager left and I went from one team to three; another manager left and I got their team. Now I manage eight teams indirectly, with managers reporting to me.
Ryan Cooke: The challenge I'm still dealing with: on metric quality and mobile builds I was an expert and could arguably be a staff engineer. But as scope grows you own more — now I own iOS teams, where I would not be a staff engineer. Learning to manage teams beyond your expertise is the next level of management skill: knowing when to trust your partners, and what level of understanding you actually need to make informed headcount decisions.
Matt Klein: To some extent the same applies as you become a higher-level IC. As you move up — whether into management or toward principal or distinguished engineer — there's a lot of overlap. There's ambiguity, and you're leading on things you might not know deeply. At the highest levels it feels like the question is whether you're focused on nurturing people and teams or purely on technology, but there's a lot of overlap.
Ryan Cooke: I mostly agree. ICs have more variety of routes, and you do see people reach high levels as pure specialists. But a common route requires knowing outside your domain. Even specialists get asked to make a call — "I don't need you to be the performance expert, I need you to catch whether something sounds wrong." We have calibrations next week, and the most senior ICs are as important to them as the managers, even though they'd rather be coding. That's the nature of the role as it grows.
[00:38:45] CURRENT CHALLENGES AND AI
Matt Klein: Now that you're managing all these teams, what are the big challenges your teams and the mobile org are facing, from an industry perspective?
Ryan Cooke: Some are classical: all our apps were written ten years ago and we never threw them out to start again. One big initiative this year is getting almost entirely to Swift — the last milestone chunk of Swift code — to let people use the best technology. On the opposite end of boring, the exciting new thing is AI being everywhere, and figuring out how to use it and where it goes. I have a conflicted feeling — as someone always in the weeds, every few months I worry that if I'm not doing enough side projects I don't know how people code anymore. It's strange to feel more disconnected from the development process than before.
Matt Klein: How are you nurturing your engineers to learn these tools and be effective? Things move so fast. I'm neither an AI skeptic nor someone who thinks these are magical gifts from God — they're tools you have to learn to use well. Where we are, we have a Slack room where we teach each other what's working. At a larger org, how do you handle that rollout and make sure the investment is useful?
Ryan Cooke: There's a centralized team whose full mission is this, but I also manage a large group I want to be effective. A lot of what you're describing sounds familiar. We made a virtual team of the people most leaned into AI — the champions — who vet tools and share best practices in Slack channels, one of which I think is called How I AI. We've done pair-programming demos. Being remote adds a challenge: you can't walk past someone and ask why they have a bunch of terminals open instead of an IDE. So having sessions and visibility is most of what we're doing.
Ryan Cooke: As a big org, security is a constraint — we can't just hand out every tool the moment it ships, even if it sounds cool. At one point Cursor was in security review and we wanted to show how it could work on our codebase. So we had a developer work on one of our open source projects on their own device. The risk is code leaking, so this let us understand whether it would solve our problem without that risk.
Matt Klein: Things move fast — you can host models in your own AWS account now, so there are ways to mitigate the risk. But I agree with your security team that it's only a matter of time before there's a petrifying security incident from these tools.
Ryan Cooke: Finding that balance is tricky. The virtual group we put together leans toward "AI is changing everything." They don't literally say "if you type code you're an idiot," they're great people, but they're further along the spectrum. Part of the job is helping them show what they see while applying the right level of skepticism.
Matt Klein: In six months I've gone from thinking these tools were mostly a joke to generating substantial code with them. But they're still tools — they produce garbage if not guided well. There's considerable skill in using them effectively. I don't buy the talking heads who say we'll never have to think again.
Ryan Cooke: I'm similar. For a good while we'll have this "suddenly we can do a lot, suddenly we can get the work we weren't most interested in done" feeling. One recent example: we're migrating from Objective-C to Swift, a great target for AI. Nobody wants to put their promotion case on "I moved this many files." We gave an agent ten hours and it did a migration — landed and shipped. We'd estimated it at three weeks. I'm both terrified and impressed. We're still in the "everybody read the code this time" phase; I'm not yet at the point of having AI review the AI's work.
Ryan Cooke: Another interesting example: we gave the agent to a partner team and their initial take was that it didn't work — maybe for very small files. Then the person who wrote it tweaked it a tiny bit, worked on the same module, and got the whole thing migrated over a day. There's a bias that AI coding means "do all the code for me." There's real skill involved, and unfortunately you have to relearn how to use it every few months as it changes.
Matt Klein: Using these tools is in service of something larger. Beyond moving off Objective-C to Swift, are there other big initiatives your teams are working on?
Ryan Cooke: Test coverage is another prime spot — though we don't want dumb tests, and a lot of training data is dumb tests. Testing and Swift migrations are the two biggest. There are also smaller migrations that never made sense to fund because they'd take too much time. One example: our iOS internationalization handling isn't best practice. It works, maybe causes a bug twice a year — not painful enough to justify a month of work. But if AI can make those kinds of changes across many places, suddenly a project that wasn't worth funding becomes a relatively easy win. Our biggest focus, though, is the very long-running projects eating large amounts of engineering resources, like migrations.
Matt Klein: I meant more broadly than AI — you have a lot of infrastructure teams, so there are presumably build, IDE, or observability problems. Where do you see things going over the next few years?
Ryan Cooke: In the metric quality group, there's an ongoing debate about what it even means for a metric to be accurate, and a lot of partnering with teams and tools to make sure people use the correct metric. We have a short list of the really good ones, but how do we elevate all the boats? There's also a recurring question: what do we do about data that's right and wrong at the same time? For example, someone signs up with today's date as their birthday, or a suspicious number of people are born in 2000. How do we filter to the more trusted records for larger decision-making?
[00:52:11] BUILD TOOLING AND BAZEL
Ryan Cooke: On builds — Bazel was the hot topic maybe five years ago, and still is. We were actually one of the first to run our iOS builds on Bazel, and we moved back, focusing on a very lean build team.
Matt Klein: You used Bazel and then unadopted it? I love this story. Keep going.
Ryan Cooke: It's not that exciting. You generally get better results with Bazel, in my opinion, but you need more staffing and expertise, and every new iOS version requires an extra layer of work. We hadn't staffed the team to handle that, so our ability to update was overly compromised. We refocused on what we could do really well, leveraging native support tools. Each mobile app is in its own repo, so there's less need for Bazel everywhere. We moved back to Gradle on Android and standard toolchain solutions, and we've been generally happy with that, with a few nuances.
Matt Klein: We build the bitdrift SDK using Bazel. It's a complicated build because we have a lot of Rust code and other things going on. We constantly ask whether we should just have a Gradle build and an Xcode build and be done with it. You probably get faster speeds with Bazel, but there's a lot of maintenance.
Ryan Cooke: Yes, for sure. That's the trade-off you have to make.
[00:54:15] NATIVE VS. CROSS-PLATFORM
Matt Klein: Any last thoughts on where the mobile industry is going, or other interesting projects?
Ryan Cooke: In mobile there will always be the code-once-versus-code-per-platform conversation, and there's more exploration of hybrid solutions with Rust shims and the like. That conversation will continue as we keep up with the latest technologies.
Matt Klein: One last question — where do you land on WebView versus native, and the intermediate solutions like React Native and Flutter? There's a lot of circular thinking: WebViews are bad so go native, native takes a lot of resources so go back to React Native or Flutter, but then people make web faster. How do you think about it?
Ryan Cooke: As a default I lean native. We're a big enough company that the scale justifies it. If I were starting my own startup today I'd probably use Flutter or something similar for proof of concept and fast iteration. But once you've found product-market fit, native is still compelling — the ecosystem lets you better solve crashes and avoid mysterious issues. Where we're looking now is whether we can cut out layers of metric quality, since that needs to be perfectly identical across all apps, which is very hard to do in native. We're still exploring whether we can reduce that overhead, but native is the default where we are.
Matt Klein: That's as good a place as any to end. Thank you, Ryan — that was an awesome conversation. That's a wrap for this episode of Beyond the Noise: Signals, Stories, and Spicy Takes. Huge thanks to Ryan for joining and sharing his story. You can find this episode and all past ones on the bitdrift YouTube channel. If you had fun, drop us a review, tell your friends, or yell your favorite hot take into the void — just make sure to tag us. I'm Matt Klein, and I'll see you next time.
Ryan Cooke: Thanks for having me.
