Scaling Mobile at Uber: Ty Smith on Community, Toolchains, and the Next Dev Productivity Wave

[00:00:00]

Matt Klein: Alright folks, welcome to Beyond the Noise Signals, stories, and Spicy Takes the show where we dig into the stories of 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 creator 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 wrap it all up with their hottest takes. So let's dive in.

I'm very excited today to have Ty Smith with us. He's a principal engineer at Uber. In the developer productivity org. He's a horizontal tech lead across many dev prod efforts including ai, mobile infrastructure, open source and [00:01:00] developer relations.

You may have seen him before in the wider developer community, especially around mobile, where he's been involved since the early days of Android. He's a frequent keynote and technical conference speaker, often appearing at Droidcons, DPE summit, Devox, Kotlin Conf, and many others. He helped organize the SF Android meetup and Droidcon SF for many years, and he's the co-chair of the Mobile Native Foundation, a group under the Linux Foundation, and a member of the Kotlin Foundation on the Ecosystem Committee, an Android Google developer expert, and spend some time as a startup advisor, angel investor, and technical lp.

Prior to Uber, he helped Twitter build Fabric before it acquired by Google into Firebase was one of the first Android engineers at Evernote and tried his hand as a startup founder at recap and built the first mobile versions for Zagat, also acquired by Google.

Ty, that is an impressive background. Thank you so much for coming on the show.

Ty Smith: Yeah. Thanks for inviting me. [00:02:00]

Matt Klein: Yeah, I, you know, there's so much that we can talk about from open source to mobile to, really lots of things. I know that we're gonna run outta time. I, I think, you know, where I'd like to start, especially for someone like yourself that has done so much and is now in a very senior position within Uber... I think a lot of listeners would like to learn about you and actually how you got to where you are today.

So if you could start and just, you know, we can start with the early days when you were young and got your first computer, or we can start wherever you want really. But I think if you could take us through a bit of your history, and wind up with how you got where you are today, that would be fantastic.

Ty Smith: Absolutely. Well, , I - I was born a - a twin, to a, a keyboard obviously, so I came out of the womb already programming. But no, in, in reality, I, I did get started with - with computers pretty early. I'm, I'm kind of one of those stereotypical engineers that's been doing it since I, I [00:03:00] can remember, I think I had... my first... computer... was my dad's old work... Pentium One in like '92, '93? Something like that.

Matt Klein: Yes. Now we're talking and we're walking back in history now.

Ty Smith: Exactly. It, they got fried in a storm, the motherboard died and, he got a, he got a new work machine, so we replaced the motherboard together and I had a machine to tinker on for, for a while. You know, got really interested in - in computers starting like game-, you know, old Windows three one games and things like that.

Matt Klein: Sorry. And when you say you replaced the motherboard, did you replace it yourself?

Ty Smith: Uh, well, I, I replaced it with my father at age six.

Matt Klein: Right.

Ty Smith: So, you know who mostly did it, but, you know, it was a learning - learning experience for sure. And it got, you know, it helped, it helped make me, you know, passionate and get the interest going.

And, and he saw that at an early age too. But then, you know, for, for years it was, it was tinkering and starting to, you know... [00:04:00] early days of programming, starting to do, you know, websites and, and other things like that. You know, when I was probably nine, ten years old... made some commercial websites for like, family members and got paid like, you know, pennies, but, you know, had like a, a bed and breakfast website around that age that I made for, uh, grandparents.

So had some exposure, like, you know, with, with that. Had swapped a, a couple computers out, like bought, bought them at garage sales, that sort of thing. So I, I was always on, on a, a computer and tinkering and upgrading and, and programming at that, at that age. But, you know, I was fortunate because, when high school started, I ended up getting to take a lot of technical classes that are pretty, unusual in most public high schools.

So I was in, high school in, in a rural town in Texas and, uh... called Weatherford, it's like a agriculture town, like 30,000 people, maybe less at the time. But they had three years of computer science and

Matt Klein: [00:05:00] Wow.

Ty Smith: Two years, uh, computer networking and three years of computer animation. So I ended up just

taking as much computer classes as I could in high school, and by the time I graduated high school, you know, I'd, I'd learned, Assembly and C and c plus plus and Java and like all your basic like data structure, algorithms, architecture stuff like everything in, in three years of CS that you would expect.

Had my CCNA, from networking. So I was doing a bunch of like networking stuff, had, you know, the basics of, 3D Studio Max and Maya. So I had, I was kind of well-rounded and I had spent two years in high school working for a local computer repair shop that also made like websites and small apps for like local businesses, churches, banks, restaurants.

So, I'd, I'd worked there for two years. So by the time I graduated high school, I had a pretty like fortunate set of, of kind of computer knowledge that was, was well above what most folks coming out of that age would have.

Matt Klein: Yeah, I was gonna say it, it's, it's [00:06:00] funny how similar our backgrounds are, actually.

I, I, I had a very similar upbringing. I took a lot of computer classes in high school, and I actually worked for a computer company before I even graduated from high school. So it is, it is funny and I agree, fortunate to be in that situation, to learn so many skills before you even enter college. But anyway, keep going.

Ty Smith: Right? So, so I, I then went to, uh, UT in Dallas for a software engineering degree. But, you know, I found quickly that a lot of the... tech courses that were being offered in the early years, I had already had a lot of the basics and I knew a lot of it. So I switched to doing night school and started working full-time.

So I was doing...

Matt Klein: wow. yeah

Ty Smith: like 12 to 15 semester hours, mostly at night. And, UTD has a lot of, um, like, uh, workers and commuter... it's a park commuter school. So, it had enough kind of night classes that I could take. And, I worked across a handful of, tech companies around the Dallas area, doing just like [00:07:00] full-time salaried, engineering work, through, through college.

So by the time I graduated, you know, I had had several years of full-time engineering experience. You know, leading teams, building major applications, and, you know, the degree and everything else. So it really, set me off for being in a better position than your normal new grad for trying to get into like, you know, more Silicon Valley companies or, you know, some startups, things like that.

So I, I moved to the Bay Area shortly after that, back in, uh, like the 2010 ish. And, started... I worked for Evernote, at first. So I was one of the first few, Android engineers. I'd been doing Android for one of those companies while I was working in, in college. So, you know, I'd been working on it, along with a little bit of iOS and, uh, web os, Blackberry doing, Zagat, which, you know, I, I mentioned, you mentioned in the, the background, which was acquired by Google became part of Google Maps later on.

It was one of those [00:08:00] restaurant, like very famous restaurant review services who used to print the books you would see at like gas stations.

Matt Klein: Yeah, I know. Yeah.

Did you, did you get into Android or, you know, just because that's what the company needed at the time, or did, did you have, you know, like a special interest in mobile?

Ty Smith: Yeah. That, that, that's a-

Matt Klein: I'm curious how you, how you got into that, because I mean, those were pretty, pretty early days. I mean, it was, Android had not been around for that long. iPhone had not been around for that long.

Ty Smith: 2008, right?

Matt Klein: Yeah.

Ty Smith: You know, I, I was skipping a little bit to the, to the - the Bay Area companies, but I realized I missed some pretty fun stories at, at this part.

So I, I was working in a little, um, contracting shop in Dallas, my senior year of college that had, bunch of mobile and, web developers. There's probably 10 or 11 of us. It was co-founded by, a guy who, uh, really good friend and mentor of mine who's now... the GM over the play store at Google.

But at the time it was a small little [00:09:00] contracting company, making early days mobile apps. And, I worked there with some, some great other engineers that were local in the area. And, we had had Zagat as a, as a customer to do, uh, their Blackberry version and the iOS version. So when Android wa- was coming out, it was... we already had the contracts in place and needed to produce the Android application.

And we had hired another contractor that was gonna be doing that work, but he, unfortunately had to, had to leave the project early. And so I was left with this position of the owner asking me, how do you feel about learning Android and shipping this, you know, by our deadline in three months? And I think I responded something like, I don't, I don't think this is a, a volunteer sort of situation, is it?

He's like, no, you, you get it. So, you know, I I ended up, rushing through that, learning Android, shipping that by either, right, right at the release of Android 1.0 or like very shortly after it. It was very,

very early days...

Matt Klein: I would imagine [00:10:00] too that, I mean, to do an app so early, uh, you were probably fighting platform bugs and not just your own bugs, right?

I mean,

Ty Smith: oh yeah. No, the days like it was

Eclipse ant, um. Very terribly performing devices and emulators, all kinds of platform bugs that we were hitting.

Matt Klein: Yeah.

Ty Smith: I think there was only one or two device, like there was the one reference device, the, I think the G one. And then, um, in later in the project, we, you know, there was a, a couple other devices that started to come out, but it was a mess of a tool chain.

It, it was... there hadn't really been well established practices for like, architecture and, and um, componentizing applications. Everybody was kind of figuring it out at the time. It, it was, uh... it was fun, wild west.

Matt Klein: Yeah. I was gonna say, was - was that your first exposure to programming in Java? Or, or had you had previous Java experience before that?

Ty Smith: No, no, no. I, I had, I definitely had Java experience, both in school, [00:11:00] significantly. And then, before I was doing Android, I was doing other, like generic... did some J2ME

Matt Klein: Got it. Okay.

Ty Smith: Java, um, had been doing some backend stuff, so did a little bit of Java on the backend. Bit of spring development, swing development, not spring development.

Matt Klein: There's also a spring.

Ty Smith: Yes, there is. There is, but not at the time. And then had had, like general like PHP and rails, so I was kind of all over the place, you know, contract.

Matt Klein: Yeah.

Ty Smith: But this was one of the bigger meaty Java projects outside of academia.

Matt Klein: Yeah.

Cool. Okay. Sorry. Keep going.

Ty Smith: Yeah, so that, that project... we shipped it was great.

Um, the, the group that contracted us for that then hired me away from the first company. They were like, 'Hey, we subcontracted this. You did a great job. Do you want to come build this for us full-time now? And, you know, we'll, we'll pay you more' and, you know, et cetera. I was... job hopped a lot. It was still in, still in college at the time.

Um, so spent some time with them, worked on, that a bit more, [00:12:00] Zagat. And then, Sprint, their native Messenger app. This was a, a company that was contracted by Sprint. So we did... if you remember Bacon Reader, the, the Reddit client that was, out of this group, it's called Hand Mark, um, FriendCaster, early days of like a third party Facebook app.

Matt Klein: Yes, okay. I'm like

going, going way back in my memory now. Yeah.

Ty Smith: So I was, I was at the company there, had had my hand in a few of those worked on PowWow the Sprint Messenger, like first group messaging application that was native on their device.

It was funny. I actually, that's when I met Chris Banes, who was pretty popular in the Android community for a long time because we- he had built Flow, which we acquired and turned into FriendCaster.

We flew him in from the uk and I, I met him, you know, back in 2009 or 10 before, you know, he had, he had, what did he have? ActionBarSherlock and some of the other things that No, that was Jake. Uh, I don't remember what Chris had, but it, it was a fun early days of the Android community before a bunch of the, the well-known names now, like [00:13:00] really had made a name for themselves.

Matt Klein: Yeah. Cool.

Ty Smith: We had to meet each other and, and connect in the Android community.

Matt Klein: Yeah. Fantastic. Alright, so you, so you moved to Silicon Valley, but it, it also sounds like at least by this point, you, you were doing primarily mobile development. So...

Ty Smith: I was

Matt Klein: I mean, you know, it, I'm assuming you enjoyed it or you would've stopped doing it right?

Ty Smith: ...enjoyed

and, you know, there's always a... the value of, of demand, right? Yeah. Like at the time, iOS was really hot. There was more iOS developers. Android was just coming up. You know, I definitely like some things about the ecosystem, it being open and some of the other things. And there was just a general demand for the, the experts.

So I was able to, you know, fulfill that demand. And there was a lot of startups and companies that were very aggressively trying to hire their first Android folks. And so, I, I came out then, um, interviewed with, Airbnb and, Evernote and a few others. I had a offer to be Airbnb's first Android engineer [00:14:00] that I unfortunately turned down.

That one could have been, fun in retrospect. But uh, ended up at Evernote for a few years. Got really involved in the tech community out in the Bay Area. Started running meetups, brought the - the Android community together through a Google io party that we ran called Meetup with, with another engineer where we invited a bunch of folks at a, a Brazilian steakhouse right before Google io.

So it's a really like, energetic, great time for mobile where, the, the energy was flowing. There was all the new developments coming in. Tons of people were, were coming out to the Bay Area and, and wanting to get involved in companies. There were meetups and drink ups and all kinds of stuff going on weekly.

Matt Klein: Yeah.

Ty Smith: We started, you know, several like Google Chat and, and Slack groups later on. That became kind of pretty critical to, the core of the Android community today. So it was just that time that the community really coalesced into, into kind of what it is today. Uh, so it was really fun being there for that [00:15:00] entire time, and getting to meet a lot of those folks and have my hand in, in helping shape that community in some ways.

But I was...

Matt Klein: Yeah, I - I was gonna say, it's, it's pretty interesting to me as a non, you know, I'm mostly a backend developer, so it's a very different, very different set of communities. But one thing that I've noticed, which I, I, I love to ask you about is, I might be wrong, but I do get a sense that Android has a much bigger community sense than the iOS community.

And I, I don't know if that's because Android started as an open ecosystem. Everything is open sourced or there's other reasons, but I'd actually love to ask you A. is that true? And if it is true, why is it true? Because, because it seems like, you know, there's so many developers that also work on iOS and the whole ecosystem that I, I just find it surprising that there doesn't seem to exist the same collective spirits that you see.

And the [00:16:00] only thing that I can come up with is that Apple is a pretty closed place and like they don't nurture this type of thing. But would love to get your opinion on that.

Ty Smith: It's a great question and it's, it's one I've had, a lot of opinions on over the years, and I would agree with your overall sentiment that from everything I can tell there's a much stronger sense of like community and togetherness in Android than I, than I see in iOS.

And I think you started to nail it with a couple of the reasons. One is I think Apple themselves being so closed off, has an effect where the community just kind of waiting for Apple to do things and they have some socialness and connection and, and meetups and conferences, but for the most part, they're kind of waiting for information flowing in a, a one way.

Whereas Android, especially during those days... uh, Google wasn't as receptive to like... two-way communication, but they were... the engineers were actively in the community. They were, they were available. The community itself was establishing a lot of like, patterns and paradigms that were, became, [00:17:00] like the normal way of doing Android things like Square became a very popular, open source contributor for Android and, and a bunch of like standard libraries at the time, you know, retrofit and Picasso and, you know, these different ones.

And the, the community was really empowered in more of an authority position than, than the iOS developers were in the Apple ecosystem. And I think that that allowed that to take shape. And because of that, you started seeing, you know, a lot of conferences and events and

Matt Klein: Yeah.

Ty Smith: Community speakers. And it started to create a, a connectedness where you look at that community now, and there's so many people, like their best friends, their, they met their husband and wives through the Android community.

their like, bridal party, was from the Android community, like, for sure. Yeah. Like, it really has created this like, strong sense of, of central community there that, uh, you know, I'm involved in a bunch of other tech communities, the, you know, the dev prod, I've been in iOS, I've been in a bunch of these.

And it really had something special. I mean, it still does, it's just [00:18:00] now it's, it's not really the hot moment for, for mobile anymore. So it's kind of settled, but it was novel at the time.

Matt Klein: I

think it's well. I think the reason that I'm asking is that a, again, my, my background is more on the backend side, but what I see has happened, if you look at really a lot of the organizations that live under the Linux Foundation, whether that be CNCF or Linux itself or whatever, you can say a lot of the same things about those, about those communities that you said about Android, right?

It's like really, if you look at the CNCF space, again, setting aside what you think about the Linux Foundation and CNCF, and we can have a whole other conversation about that, but just from a people perspective, so many people define their identity by that larger community, and so much good work has come from it that I can't help but think that Apple has left a lot on the table,

right? By not nurturing that, and, and it's even for me, again, like just purely, even selfishly from a [00:19:00] vendor perspective or from a person perspective. If I look at, as you said, you know, it's like there aren't really any good conferences for Apple because they control everything. Whereas Android has this great community of Droidcon and all this other stuff, so I don't know it, it just seems like a lost opportunity to me, I guess.

Ty Smith: I agree. And, and I think it also helped the platform mature in a lot of ways as well, because Google, you know, at first maybe they were a little more hands off with the community, but they started to get really engaged and really have that two-way conversation going on, is going as far as like adopting things like Dagger came out of the community and moved into Google.

There were plenty of things that they moved technology in, or they made, like community developed ways of Android, the standard way of doing things. They have, you know, their devrel and, and like the core OS engineers in like Slack channels, stuff with the community answering questions and at conferences talking to people.

So they, they really had... bringing people in as... on like advisory boards [00:20:00] and getting feedback to their execs. Like they have all of... that they participate in and it, it really did help Android mature in a lot of ways with the community having, having a hand in it at least.

Matt Klein: Yeah. Cool. All right, so let's, so let's go back to the Evernote time.

So, it - it does sound like you were starting to branch out a lot at that time and get more involved in all of the community organizing, but obviously you're still working for Evernote. So, yeah,

Ty Smith: I, I kinda split my time, half and half. So

going into that job, I wanted to create, I, I wanted to get involved in a community and I wanted to help make that, make that happen.

But I also wanted... I looked at a lot of folks that were doing community work and like speaking at conferences and, I, I was... really wanted to develop that skillset, but I, I was very intimidated by like public speaking. I was very nervous around it.

Matt Klein: Yeah

Ty Smith: I had trouble with that. And, so I, I was at Evernote and they... it was my first exposure to developer relations folks.

They had a couple of those. And so I ended up making great friends with a couple of the devrel and [00:21:00] voiced that, you know, that desire of like, growing that skillset. And they just like latched on. They're like, come, come on in the water's great. And helped... well the, the way that, that I was pushed into it was like, 'Hey, well let's get you to do one meetup.

You'll talk at like an Android meetup in the area.' And it, it went fine. I was nervous as hell, but it went fine. And then it was, 'now we're gonna submit you in a call for papers, to Droidcon UK.' So it went very quickly, all the way in the deep end. And the first few talks were, you know, really challenging because of the, the, the nervousness and not being comfortable with that.

And over time, that... building that muscle. It, you know, it became very kind of second nature. And so I was very fortunate that I had, you know, some mentors and some people that really helped push me in that direction at Evernote. So I ended up splitting my time, kind of half and half where I was working on the core product team on the Evernote application, for a chunk of the time.

And then I was working on our open source like auth SDKs and intent API SDKs and doing developer relations stuff for about [00:22:00] half the time.

Matt Klein: Yeah. You, you know what people have asked me a lot, and I would love to ask you this question, is I think when it comes to a lot of the open source work, like a lot of the stuff that, that we're talking about, it's, it's very difficult for companies, you know, companies all claim that they like to be very rigorous and results focused and measure everything and all of that stuff.

You know, how it goes. When it comes to these things, it's very hard to prove or disprove that your efforts or are helping the company, right? Because they're paying your salary. I mean, they're paying you to go do these things. And you know, when, when, especially for me, as I got more and more involved in open source and doing all these things, and then especially when I did Envoy, in the early days, especially like in the,

in the later days is obviously abundantly clear that doing Envoy and building that larger community and all those things had a lot of benefits towards Lyft, [00:23:00] right? But in the early days it's not so clear. So I, I guess I'd, I'd love to, you know, get your thoughts on, and I'm sure this applies to the work that you do now, so maybe we're jumping forward and backwards and that's fine.

But like, how do you think about, how do you justify or measure, like talk about all of this non-business specific work, which in my opinion, you don't have to convince me, has a tremendous amount of value, but some people don't see that value. So would love to talk to you about that and understand how you think about that.

Ty Smith: I mean, it, it's definitely a challenge, right? I, I think it's, it's not a solved problem in our industry either, you ask...

Matt Klein: no, it's not for, for sure

Ty Smith: open source or developer relations. It, it, you can get into all these different engagement metrics and everything else, and you'll find value of course in, in some of those, some of those metrics.

But I really like to look at it and, and this is how I try to measure a lot of things when it comes to development. People first, metrics second, where, I, you know, [00:24:00] I really, really like to look at the qualitative and the human side as the primary, and then move into all the trailing metrics that, that kind of get there and over periods of time, right?

You look at something like open source and developer relations... You, you start to hear all these anecdotes, all these stories of people that saw someone at a conference, and they were so impressed by the tech that they then went and looked them up, and then they found the, you know, the SDK that they were working on, and they gave it a try.

And even though the talk wasn't related, or, you know, I, I've... my, my partner, she's a, a developer relations as well. And she has stories where she left a company and later on someone will tell her, 'oh, I tried such and such two years later because of the talk you gave when you were working at Sentry' is where she was at.

And so you get these like long relationship building style stories in the developer community where you put a seed out and then those come do much later on. So if you're looking at like traditional business metrics, it becomes very hard to say, oh, I went and gave a talk and I had 10 [00:25:00] conversions on our signup page to this thing.

Like, it's not working, it's not sales. You're building your, your, your rapport with the community, you're building your trust there so that they then see you as an option for using in their business, for connecting, for integrating, for adding that. And, and so I think that's for, a... maybe like a tool or an SDK or a business, you know, something more like for you guys, but for open source it's even a bit different because if a company looks at open source they have, and they say, well, we're not selling open source.

Like, how are we getting value out of this? The, the, there's a, there's a couple ways that I typically try to sell this. One is, again, you start with kind of the first principles bit that we talked about and the, the human side, but then second. If your company is always building everything in-house, they are always one step away from a technical dead end.

They're building these bespoke solutions. Those solutions are never gonna get maintained or modernized or innovated in the way that an open source standard is going to be.

Matt Klein: Yep.

Ty Smith: So if [00:26:00] you are building entirely on in-house stuff, or you're building in-house solutions... you are on this path to having to migrate.

Eventually, it may be five years, it may be seven years. Your business may not be around at the time to worry about it, but you are on a technical dead end. But with, with open source, you can be in, in one of two positions. One, you can be using an existing open source product instead of building. And then you're inheriting all of the value that comes from that, from the free labor to the, you know, more tested code, you know, more secure because it has more visibility, all of this other stuff. Um, two, if you're building it yourself and you're putting it out there, it's you helping shape the industry so that the thing you built doesn't have to get migrated away

eventually you have a chance for it to be some, become some kind of standard and, you know, you're not on that technical dead end. It's... we, we call it the ecosystem principle here, where we should be building on ecosystems or building ecosystems, otherwise we're, we're heading down this path. And that's purely from the tech side, that's not the people side.

[00:27:00] Recruiting, building trust, you know, having a, a pipeline of folks that are already experienced with the technology that come in and, and are up to speed a bit faster. We have a lot of open source projects that have come out of Uber and, you know, we see often that we're getting this feedback, we're getting people that are familiar.

They're coming in and they've had experience before. So you get this multifaceted set of benefits across the board where you do have the tech, the business side, the efficiency. It's not short term, it's a long term play, but then you also have the eng community side and the, the, the trust side and the recruiting side.

So it becomes this very nuanced play at your, your ecosystem.

Matt Klein: Yeah. I I, I mean, you said it very, very well. You said it how I also typically say it. I, I think it's more, and I think we're gonna be in violent agreement that as an industry, I think we do a very terrible job of estimating what I would cost to... what I would call total cost of ownership.

It's very easy, obviously, to [00:28:00] say, this is my infrastructure bill this month, or, you know, this is the salary that I pay this person like, or this is my office cost. Like these are fixed costs. Like as humans, it's very easy to put those into a spreadsheet. It's very hard, and I think again, we do a terrible job, all of us of saying that, no, like all in, this is what it costs.

The cost of maintenance, the cost of migration, the cost of having to pay people that aren't doing something else, the opportunity cost. And I think I just find it interesting because all of this, it's very subjective. It takes people like you and me having some subjective thoughts and maybe convincing other people, but it's not like you can point to a spreadsheet and say, you know, these numbers add up in this way and I can prove to you that if I do it, this will be ultimately more cost effective to the business.

So I think it's a very interesting topic.

Ty Smith: I totally agree. And I, I think it comes back to, you know, we pay people, engineers a lot of money for their domain [00:29:00] expertise, and the businesses do need to utilize that domain expertise that's been built. We're not pure money- uh, pure number crunching machines.

It's not all data driven. There are subjective, you know, intuition, conclusions made, and, you know, maybe we'll get to that level of, of LLM uh, analysis. But in the meantime, businesses that are entirely driven by only things that can be measured, leave so much on the table for impact, for they not having, or making short term, uh, decisions that have long-term consequences that are not being accounted for.

And it's a real anti-pattern in, in a lot of companies, especially bigger companies that are, that are public and, you know, being driven by the markets.

Matt Klein: Yeah.

Ty Smith: And it really takes people with a, a, a strong personality and a strong will and deep, you know, understanding and, um, principles to really try to educate and, and drive and have those hard conversations and push for the things that aren't easily... always easily measurable in the short term.

Matt Klein: Yeah, for sure. Um, I, [00:30:00] I would like to talk about this more, but before we do that, just take us through the last little bit in terms of how you went from Evernote. I think you were at Twitter for a period of time. So just take us briefly through that stepping stone in terms of how you ultimately got to Uber.

Ty Smith: Yeah, that, that's actually another fun story because when I was interviewing to go to Evernote, I interviewed at a small company called Posterous, which, if you're familiar, they were like a competitor to Tumblr back in the day. And they were great folks. It was a tiny company. It was like 12 or 15 people. Um, and they gave me an offer and really wanted me to go there, but, but I turned them down.

I thought, you know, Evernote would be the better, uh, career decision at the time, but I, I made really good friends with the, the hiring manager and we, we stayed in touch. And, uh, you know, after a couple years, and I'd been doing like the, the public developer, SDK Con stuff, he, he was at Posterous... had gotten acquired by Twitter and he said, 'Hey,

I mean, I'm at Twitter now. We just acquired this company called Crashlytics. You should talk to the founder, Jeff Seibert. He's [00:31:00] great. And they need someone just like you to help, you know, with the public, um, developer...' and so I, I talked to them, it was a great fit. I was the first external hire after the acquisition to help, start their SF office, of Crashlytics within, within... Twitter.

So I ended up, doing like a, a really fast paced interview. They flew me out to Boston where the team was fully based at the time. Did like a red eye full day of, of interviews. At the end of it, they were like, 'Hey, come grab drinks with us. You were great. We're gonna give you an offer. Like, just come hang out, party with the team.'

You know, very like startup vibes. So I did that. Flew back the next day. And I had the offer. I'd signed the offer, I hadn't started yet. And then Twitter announced their IPO. So I was like, wow, that, that was like really nice timing. So joined Twitter, right? Like before the IPO happened, kind of saw Twitter through that phase.

It was really cool. But you know, there's a new company for me as well. 1500, couple thousand.

Matt Klein: Was it, was it, yeah, I was gonna [00:32:00] say, was it cool or since I was there at the same time, was it PTSD inducing? It's really hard to say, but

Ty Smith: yeah, that's great.

That corner of San Francisco has never been the, the, the interesting one, um, at, at civic center area.

But I was there for a few years and... I, I then got poached to, to Uber by... another guy and I'd left Twitter, uh, along with a couple of my co- at least one colleague. We, we went to Uber together. And, a couple months after. Twitter sold what was fabric, uh, Crashlytics became fabric to Google to become firebase.

Matt Klein: Well, sorry. And, and I was gonna say, for those that don't know the history, by go to Uber, you took the same elevator to a different floor, right?

Ty Smith: Yeah. I mean, uh,

across the street, but...

Matt Klein: oh, sorry, sorry. Across the street.

Ty Smith: Yeah. So I stayed on that corner of San Francisco working for seven years, eight years. I thought I'd never escape.

And it's a, it's a wind tunnel and it's, [00:33:00] it's...

Matt Klein: I must, I must be wrong. It were, didn't, weren't they in the same building or had some floors at a certain point, or... never. It was always in...

Ty Smith: I think so. Twitter

and

Microsoft were in, were in

that building.

Matt Klein: Oh, okay.

Ty Smith: And then...

Matt Klein: I must

be, I must be remembering wrong.

Okay.

Ty Smith: Across the street was Neva and then the Square Uber office, so...

Matt Klein: oh, okay. Got it. All right. Cool. All right.

Ty Smith: Square was in the same office, so another Jack Dorsey company.

Matt Klein: Yeah. Yeah. Okay... so what- so what made you jump to Uber? I guess, like what was the opportunity there that you were looking for?

Ty Smith: You know, it, it, it was a, it was a mix of things. Um, you know, I, I was, I, I think I was a senior engineer that was butting up against that conversion to staff and, um, which is like starting to lead the team, but still like developing some of the... nuanced and like collaboration and some of the other stuff that you see in that like phase of, of development in someone's career.

And, I had an opportunity where, Uber approached me, they said, we're [00:34:00] building a public developer platform. The feedback on fabric at the time people were saying Twitter's stock was going down. People were like, why is Twitter building fabric? Like they don't need a public observability platform that, so there were some concerns already that like they were gonna lay off for things like that.

I didn't see as much growth potential there because I, I mentioned like the, the kind of butting up against... the, the bits of the level. And so when Uber came and said, Hey, we're, we're building out like an open developer platform. We have an open API, we are building, at the time, like a full, integration into the, the rider application.

Uber was on this like hypergrowth trajectory. I'd had a lot of friends that had gone there and had, you know, great things to say. There was a lot of energy. So, you know, I, I decided it was time to like try something new, to get some diverse experience. And me and another engineer, on Fabric had been talking to them at the same time and we realized this and they, they hired both of us to the team.

So we, we started on their open platform. And [00:35:00] we worked on that for about a year and a half, which was great. I worked with a bunch of partners, but then Uber decided it was right after the Cambridge Analytica stuff with meta, and there was more scrutiny on like data use and other stuff. And, Uber, I think this was fall following like the, the Susan Fowler days and some of the other stuff.

So, there was more like public scrutiny and, I don't think it, they were hiring as much, so there was just a lot of things going on. And the, the business decided, hey, we're gonna like, focus more on some of the core stuff and, uh, we're gonna go from like an open platform to having something that's partner only.

So like whitelisted partners and there's, there's a huge amount of those, but I really had this passion for like the open developer ecosystem and like doing devrel and open source and all this. And, I had had a bunch of colleagues that were on our mobile platform team at Uber who had for a while, they're like, 'Hey, you're this well-known Android community guy,

why are you in this one-off team over here? Like, come be at the core of, of the company or of the mobile ecosystem at Uber.' And [00:36:00] so, I joined to become a TLM. It was also my first experience managing. So I, I came over, became a TLM over the, the frameworks part of mobile platform for iOS and Android.

Ran that for, a couple years, ended up leaving management, just finding at least it for me in that time. It wasn't, it wasn't the right fit, you know, in a big company there's a lot of, moving parts and paperwork and, and stakeholder management and we lack, yeah, so I'm the like TPM resources and a senior manager.

So I was very pulled then and decided, hey, like... just a, a tech lead IC role, is probably a better fit for my own headspace right now. So converted back to that... but that experience and management really gave me some of the tools that later helped me along the, the, the growth trajectory towards principal engineering because it's a lot about the organizational muscle of how these companies work.

And so I used to really like accelerate and, and have several promotions over maybe five years, [00:37:00] to, to, to principle where, where I've been now for a few years.

Matt Klein: Yeah. I was gonna say, I think, at least in my experience, what a lot of people get confused about from the career growth perspective, especially at larger companies, is that as you get to higher and higher levels.

The line gets pretty blurry, right? Between what you do as an IC and what you do as like a senior manager, director type person. Blurry to the level that sometimes there isn't even that much difference. So I agree. I, you know, it's like you can, you can gain a lot of skills. I mean, I, I have actually never in my career been a people manager.

Somehow I've managed to, to, to get through without doing it. I'd probably be a better contributor if I had, it just hasn't been, been an experience that I personally had. But yeah.

Ty Smith: Fun story.

When I was leaving, that manager role, we were looking for a new manager and I, I mentioned the guy who brought me to Twitter, who I had interviewed with Posterous and turned him down.

We were still connected and I ran into him at [00:38:00] a conference and I said, 'Hey, we're looking for a manager.' And he said, 'Hey, my startup's running out of money' and... so I, I brought him into Uber to, to be the manager of the team.

Matt Klein: Yeah.

Ty Smith: So that was our time actually working together after being friends and missed having this missed opportunity.

'cause even when he was at Twitter, we weren't on the same group. And so now we've worked together here for, the last five or six years. So it's, it's been an interesting... path for

Matt Klein: fantastic

Ty Smith: us.

Matt Klein: Yeah. Okay. So I, I mean, we've, we've gotten to roughly the current time. I, I think what I'd love to talk about now, just because obviously...

Uber is a mobile first company. I mean, it's one of the original mobile first companies. And obviously you have a lot of developers, a huge set of apps. I, I, I guess I, I'd love just to dig in, you know, and you can talk about it from a historical perspective or now, would love to learn more about what are the biggest challenges that you're facing right now, because I know, I mean, they're, they're so varied, right?

From [00:39:00] developer productivity to build speed to whatever, fixing bugs, observability, there's so many different issues, and I think teams face all of the above. But would love to learn more about kind of where, where you're focusing now, some of the things that you have focused on. So take us through that.

Ty Smith: So I, I would say

fundamentally, one of the challenges that... a company like Uber runs into in, in mobile is that the scale of our mobile needs are not met by the typical platform provided tool chains or ways of doing development. So, you know, you, you mentioned, we, we talked about like Apple and Android earlier as like two platforms that provide down pools and, and ecosystems and communities for, for folks.

And you compared it to like the CNCF. One thing I, I would say there's a difference here is when you look at something like the Linux Foundation or the C Ncf f, there isn't like a one way set of like, this is the authority and it puts down the tools. There are [00:40:00] so many fragmented communities trying different things.

There's, you know, container D versus Kubernetes versus Docker. And these different share communities develop JavaScript's the same way. There's not like one platform provider, like maybe some of the, the, you know, vendors work together, but in general, you have these different communities in the same tech ecosystem that develop and then, you know, compete and make each other better.

In Android and iOS both, even if the community's there, it is still a platform owned and provided, you know... technology. And so there is some expectation that Google or Apple is serving the needs of the businesses that are building on top of their platform. And that becomes... you know, especially years ago, that was a, a very...

big challenge for, for a company like Uber where when you looked at everything that was happening in the, the IDE scaling, the IDE, the performance, how the apps are architected and teams stepping on each other, how the, the builds are able to scale with hundreds of [00:41:00] developers, in a single application.

Like none of this was designed with us as the target demographic. You know, it's designed for like a small to mid-size, you know, team where they're working in Gradle and Android studio and Google's gotten much better and Apple as well is like scaling some of this over the years, but still we're, we're not the target demographic.

Matt Klein: Yeah. I mean, even now, I, I actually... for the, for those that are listening, I interviewed Keith Smiley, who you obviously know, you know, from the build and mobile, mobile native foundation perspective. And we were talking about this topic, which is... and I, I think it almost comes back to what we were saying before about, or what you were saying about

Apple and Google and just they have a specific focus or a specific set of business goals. It still surprises me though, that like in the, you know, we're, we're in 2025, almost 2026, and people are still fighting with Bazel or not Bazel and the [00:42:00] IDE hanging or not hanging and like I totally get that there is a reality that the Ubers of the world are at w- way far end of the spectrum.

But at the same time, I would still think that by now some of these problems would be better solved for everyone. You know, so, so would love to actually learn more from you about why is that not the case? I mean, why is it still so problematic?

Ty Smith: I can speak a little more to the Google side where I've been directly involved with so many of those conversations with, with Google leadership as well, but,

you know, there's, there's specific needs that big customers have and you called out Bazel, and that's definitely one of those, you know, a big company that ends up going toward a single monorepo or at least a lot of tooling, like Bazel becomes a very obvious decision for them, and they will end up wanting that for a bunch of their different technologies, not just one.

And so when you start to try to make the case of these bespoke standalone, like Gradle tools or, or you know, [00:43:00] Xcode build or whatever, it's an outlier from the rest of, of the company. Not to mention the scaling challenges Gradle might have or Android studio, but also this convergence of the, the company and how they think about their technology.

So you start to have this very common goal for Bazel, as an example, that is desired from companies of a certain scale and Google says 'Hey, Gradle is our first class, uh, tool chain. This is what we provide to developers. We- we're not going to block you from using Bazel, but we're not going to invest in that.

Just like you have li- you have limited resources, we have limited resources. We want to put all of it behind Gradle and make that a great experience for folks at the expense of a lot of their large customers.

Matt Klein: Yeah, sure.

Ty Smith: And we work with the other ones that are using Bazel, right? We have a commun- an active community of Bazel for Android and we're working with, you know, Spotify and Slack and Grab and Lyft and like all these folks that are

doing it, right? It's, [00:44:00] it's, we're on our own, we're working on the Kotlin rules or we're trying to get feedback to Google on the, the Android rules. And it's really challenging 'cause Google is funding Bazel only, you know, a very small amount. And they're really not thinking about Android for Bazel at all because internally they, they have their investments, but the external folks aren't, aren't a customer.

And then the android org is entirely focused on Gradle, so it's a Conway's law slash funding problem, and the community is on the receiving end of that pain. Fortunately, it's gotten a lot better for Bazel over when we started our migration three years ago to where we are today for another company that may getting started, but it's still not supported to the degree that, that you would

expect.

Matt Klein: Yeah. Would you say that build in general developer productivity has been the biggest set of issues that you've faced? Or are there, are there other large ones that you're tackling?

Ty Smith: No,

no, I would, I would call that one major one, but I would say that... area scales into a lot of other [00:45:00] similar problems. With that much code comes a lot of problems.

The IDE itself, like performing becomes very poor typically, but that's representative of the, the amount of code that it's needing to grok. So it's the, the build graph, essentially. If the more code you have, the more all the things need to deal with that amount of code, and it starts to get into a people problem as well.

You have to start compartmentalizing. You're building a mental model on all this code, and it starts to become more overhead for the developers in it. So now you're thinking about how do you architect and scale very, very large applications or very large monorepos in a way that are friendly for the tools, friendly for developers contributing without stepping on each other's toes.

Friendly for isolation and testing. Yeah. So like this entire bit of like modernization and industry alignment while having it something be scalable is, you know, it's a, a challenge we're working on with, with a, a new architecture and a lot of other companies have, you know, built similar Swift UI slash Jetpack [00:46:00] Compose-first architectures, but it's in part because of the build system and the other overhead.

But it all comes back to the end of the day of a really messy build graph. A lot of code that needs to get grokked, and then how do we put things together to help understand that.

Matt Klein: Yeah. And, and I guess one thing just for my personal curiosity is that because mobile applications are interesting to me, right?

Because at least in the, in the, server world, when you wind up with too much code, at least theoretically you can split them into microservices and you can do things to actually make that easier. At the end of the day, you are linking a giant application. It's like there's nothing that... stops that. And what I'm wondering if you can share is I, I can imagine in my mind a way that maybe you refactor the code, so it's more of like a hub and spoke model where like each of the features are kind of like self-contained with some core code and they can be developed in isolation, and then there's like a final linking stage.

I, I'm just trying to understand like what are [00:47:00] some of the techniques that you actually use to deal with that?

Ty Smith: You just, you

just nailed it at a, at a high level. So, I did an analysis several years ago to, our backend development, JVM repo, which uses microservices versus our Android JVM repo for the amount of build cache misses per iteration for a developer.

So what this gives us the information on is, when you make a change and you run built, how many targets were invalidated in the dependency graph because of that change? So when I ran that in our JVM microservice repo, the P75 number was two. Two targets are invalidated for most developers working when they make a change in a microservice.

Matt Klein: Yep.

Ty Smith: This is a 40 million, 50 million lines of code, you know, repo. For Android, depending on the app you are in... our rider app, driver app, pizza app, it ranged from 500 to 3000 targets.

Matt Klein: Wow. Okay. So there's a lot of interdependency between, the code is all like mixed together. Yeah.

Ty Smith: Monoliths like they're, they're [00:48:00] linking major monoliths.

There's a lot of depth in it. And so what, what you described is definitely a, a direction I've seen in a lot of companies, which is trying to build some sort of like sandbox or app slice or, you know, there's a lot of different names we've heard for this

Matt Klein: right

Ty Smith: You, you do need an opinionated architecture from the beginning, that lays your app out in a way that has a much flatter build graph so that you do this, and this is something we've been actively working on for a while, but it's less of just a restructuring your build graph for an automated, you know, migration.

It is the business logic linking and changes that are necessary for navigating throughout your app. But it is intentional in the design of our current architecture, in how we create this flat build graph where you have isolated, you know, strains and components that are siblings, not parent child relationships in the build graph to get a similar, approach that you described.

Matt Klein: I mean, and I would imagine too, obviously for an app like yours, which is huge, I mean, trying to, I mean, you can't do it from scratch, so you have to figure out a migration path and do it in [00:49:00] piecemeal and all of those things. I mean, it's a tremendously large effort. We, we, we could talk about all of the stuff for long time.

I, I, I would love to maybe even do a follow up episode with you to talk about some of these things. We, we are coming up at the end and I, I do wanna just talk a little more about, either, just, just so that people out there can, you know, learn from you and understand the larger issues that the industry is facing.

I'm assuming that you're looking at AI enhancements, you're probably looking at other things. I guess could you just briefly take us through, either now or in the next 5 or 10 years, you know, what, what do you think from the mobile perspective, what, what are going to be the major changes? Like what are gonna be the major investments?

Ty Smith: It's a great question. And, and right now I think AI is the hot topic everywhere, and that's... no exception for mobile. But what I see happening with AI and, and I'm, I'm very involved in that here is the expectation of speed and iteration is increasing. [00:50:00] And the com-, the composability and the consumption of your code base and your, your applications by AI is also needed.

So I think what we're starting to see, and this goes further when we move from like in IDE coding agents, like, like GitHub copilot to more standalone background agents, like, you know, Cursor's background agent or, or Claude code, that you start to need these autonomous units of work that get created across the feature or the toil spectrum.

And then you need to have a path that that's like introduced and validated automatically in the, the project that you're working on. So when it comes to mobile, what I expect is more and more contributions coming at a faster rate that need to have the mobile validation that's happening. So things like an MCP for controlling the emulator feature sets that's connected.

And so you'll end up, you know, if we're looking at 5 or 10 years with autonomous end-to-end feature orchestration going on into your application, and I suspect we're actually going to be to a place [00:51:00] where a lot of the native tech we're using today, we're less opinionated on that because we wanna move faster.

So you might see more things like react native, maybe Kotlin multi-platform, even web based technologies because of the speed that's desired. We'll see that become more popular and from the end user perspective, if we're moving fast because agents orchestrating more features and, and things through, I, I worry that it's gonna be about the consumer bottleneck on actually digesting and providing like XP data on all of the changes that you could put out.

Matt Klein: Yeah.

Ty Smith: As opposed to any building.

Matt Klein: I was gonna say, I mean, we, we haven't even got into the topic of observability or how do you know what's going on, but, you know, I feel like the bar becomes even higher as you put out more code. I mean, at, at least it, I, I guess. My personal experience might not be others, but what I find with the current set of tools is they tend to work very well from an agent perspective when I would, not necessarily green [00:52:00] field, but like when the context window is small, right?

It's like it works very well. I don't know your experience, but my experience of like doing changes over large code bases, it's, it's, it's not as good. And I would imagine for the reasons we were talking about before about this interconnected code and it goes over thousands or millions of files, I'm guessing the agents are not doing so well right now.

I would imagine they will increasingly do better and better and better. And then when they do though, how do you know that anything is actually working correctly? I mean, it's a,

it's a, it's a tough problem.

Ty Smith: It is, and it, it's why we need the investment in both the fundamentals that it's using today and the validation and everything else that you would expect so that you can start to take advantage of it in the small areas you mentioned, and then start to expand the scope and expand the scope and expand the scope with the right guardrails and additional context that's provided, that enables it.

And, and we'll get that incrementally as the models get better and we can provide more context to [00:53:00] them. And the, you know, rag and other, information becomes more easy to access. But I, I think it's just a matter of when we get there, not if,

Matt Klein: if,

Ty Smith: and so,

Matt Klein: yeah, for sure. Yeah.

Ty Smith: We have to be pushing now, otherwise we're gonna be way behind, when, when you know that that ship has sailed.

Matt Klein: Yeah. I, I mean, we're... at time, and again, I could talk about this all day. I, I do think, and partly I'm biased for obvious reasons, but I think as we produce more and more code in an automated way, the automation of observing the code to understand, to having the right analytic events, the right dynamic observability, all of these things, I, I don't know how you can ship code at much higher velocity without introducing tremendous amounts of bugs if you can't understand that the code is actually working,

right?

Ty Smith: Absolutely.

The planning, the observability, like the, the review process, you have all these other bottlenecks that we're gonna be dealing with challenges.

Matt Klein: Yeah.

Ty Smith: Um, and they need to be taken very explicitly [00:54:00] to avoid that, that... all the landmines that I think you just described.

Matt Klein: Yeah.

So I guess, prior to wrapping up, maybe I'll ask you my, my last and final question on this topic. You know, what, what will developer or what will development be like in 5 or 10 years, right? I mean, will it still be developers? Will the LLMs be tools?

I know people have vastly different takes on this, so would love to get your, your thoughts.

Ty Smith: Yeah. I, I don't think software engineers are gonna go away as a job, but I, I think it will look fundamentally different. And I, I think that right now, the overhead to becoming one of the specialists that we need in the field to create software is very high.

You know, you become a product designer, software engineer, specialized in one of the technologies or a product manager. All of these are needed because of the amount of time and expertise it takes for a human to get there. But at the end of the day, they kind of come together to produce high-end, you know, consumer facing software.

And what, what I think is gonna happen is we're gonna see much more of a blending [00:55:00] of the skill sets that are needed across the different roles that currently are used. And, you know, the, the typical like going deep into one specific bit of code that probably will shift, like that probably won't be the normal.

Just like you're probably not, you know, debugging Assembly or JVM bytecode daily, but occasionally you may need to look at a bug there. I think we'll be looking, working at higher surface areas, of, of the product building lifecycle. And because we'll have a lot more capabilities as an individual who's building this, there will also be skills that need to be developed that maybe typical engineers aren't comfortable with today.

If you're an engineer who just wants to stay really technically deep and not be connected to the, the end customer, the, the business, it might start to become challenging for some of those folks. I think. Maybe there's still pockets where that, that's fine. But I think in general, we will need to think at a higher level of abstraction that's similar to what more senior engineers [00:56:00] work like today, right?

The more senior you get, the more you have to think about the business impact and act like an owner and do jobs regardless of the job role to make sure it's done, right? Those are the things that you're kind of considering. And I think that we will be forced at lower levels, the, the product builders to act that way, where they're thinking about what are we actually building?

What do we need to do? Okay, is it design and I'm working with the agent on design. Is it feature sets? Am I going deeper to evaluate or debug one specific thing? I think that's gonna be your general polyglot product builder that is most common. There will probably be specialists in different

areas like you're gonna need people that really do need know one... like know the infra and can go deep and debug, you know, some of the API interactions or some of the other stuff that's not gonna go away. But it won't be common. Just like today, your platform engineers or your infra engineers are a smaller set.

It's probably gonna shrink and there will... that'll still exist. But your most common product [00:57:00] software, builder is probably gonna be that first archetype that I mentioned.

Matt Klein: Cool. Well, thank you. I will be fascinated to see how things turn out over the next decade or so. Thank you Ty. This was a fantastic conversation.

That's a wrap for this episode of Beyond the Noise Signals, Stories, and Spicy Takes. Huge thanks to Ty 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 and just make sure to tag us.

I'm Matt Klein and I will see you next time. Thank you again.