From Backend Engineer to Head of Mobile (Lessons from Uber)

The world is changing every month. It's scary to be a graduate engineer nowadays. AI is not going to take your job. A person who knows how to use AI better than you are, they will pick your buttons. This is a green commit. I love to build things. And it was tough to realize that you put so, so much effort into building something that people don't need. How do you build a career? Specifically a software engineer developing apps for mobile. That's what we discussed today. And we talk about AI-assisted co-tooling. How to leverage the to make yourself more productive and faster than ever before. Joining me today, he's head of mobile, is my good friend, Pasha. And previous guests and friends of mine have told me great things about Pasha. And I can see exactly why. So enjoy. I don't talk to many mobile engineers and the only experience I have has been in React Native specifically. But I'm very curious, in your work experience, or more on the productivity side nowadays on a day-to-day, what do you use in AI-tooting that makes you really productive in what you do? Or what is effective in the end? So it's mostly cloud. I've got a console or multiple consoles with a cloud open. And basically, I'm trying to use it as a junior/medium engineer, fellow engineer, who can help me bounce off ideas and who can help me with code reviews, for example, review my code in the first place. And obviously, to write some code as well. So as long as you have a solid foundation set up in terms of MD files that help to give context to the AI, I think it could be very helpful in these regards. Definitely-- so I recently joined that new company. And definitely, AI was super helpful when it comes to learning new code base. You can ask it anything. What kind of features do I have in this code? What are the entry points to these features? Please them out and point me to the files. And then I go there. I look at the code and I understand how it's all orchestrated and how it all works. So you do this with multiple terminals as well? Yeah. How do you manage that? So it's T-Mox, basically a split of four T-Mox windows. Yeah. And that's something also-- I started to use very recently before I didn't use Windows splits at all or terminals splits, rather. But with Cloud, it's actually very useful. Because in one window, in one pane, I guess it's called, you have a feature planner as an AI who is writing a spec. In another pane, you have an AI who is following the spec and is implementing the thing. In third one, you have an AI who would review things. And you don't pollute the context of each AI. So you have to remember which pane is responsible for what. But then in the end of the day, you get pretty fast workflow with that. Interesting. When you set multiple windows, my assumption was that each window would work on another feature in isolation. But this is not what you're doing. You're actually doing one feature. And then you have different purposes within a pane. Yeah. Yeah. And so I've got multiple repos of the same project set. So if a pull request is in review, if I consider feature done-ish, then I can move on to the next feature in another repos. So similar to what you described. Interesting. I haven't done that yet. Because I have been trying this thing out. I went from product management back to more hands-on software engineering. And this is one of the first things that I actually struggled with was, OK, one feature is done. I'm going. And I did definitely have some context pollution. Because then I go to another feature within the same conversation even without clear my context. And it goes, oh, all the changes that we had are gone. We need to add them again. And I was like, OK, so this is definitely user error here, basically. And then I do hear people with multiple terminals and indeed working on multiple features. But I'm like, how do you fix-- or how do you go in specific feature branches? And you've solved that with actually having multiple repositories. Yeah. Yeah. There are work trees. It can do work trees. One thing that I didn't try that yet, I did try work trees back maybe 10 years ago. And one thing that kind of put me off of using work trees is that you cannot have two different work trees checking out the same branch. I'm not sure if this is something that is fixed. So you cannot have two work trees checking out, develop, basically. And that's something that I usually do. I check out, develop, I pull latest changes. I work in develop. I don't push. And then I have a command that would just check out a new branch. And-- well, put a command that's out, the new branch. And finish it. But for that, I need to stay in develop. And that's kind of how I operate, how I use to it. So for me, it's easier to have multiple repositories. Gotcha. Is there more you can share that makes you effective with regards to AI assisted co-tooling? So I find that our case is pretty successful in terms of AI. Because I know that people-- sometimes they struggle. And there was a study that-- I don't know how many, 95% of organizations adopting AI that don't see efficiency increase. For me, personally, I see efficiency increase. But what I do is I actually use them as a junior engineer, not letting them do everything for me. But rather review their code, their AI's code. I heavily review specs, iterate on specs. I read what they write, basically. And that is-- I mean, I agree. It's something you-- or right now, it's not something that I want to let go yet, fully trust in autonomous agent. Maybe it's also the project that I mean. But I feel like it makes sense, right? The code that it spits out, I feel like I'm reading way more code than ever before. And I've also noticed that then me reading code specifically, I get better at reading and understanding code than actually writing. And even though I'm not writing as much, the skill of reading code has always been there. It's just more on the forefront now. And I actually enjoy doing that as well. Not just reviewing my own code, but reviewing other people's code. And AI is just another artifact of that. That's my own code. Absolutely. And then AI that assists you in reviews, like Copilot AI, right? It's a great way of pointing out places in code that you have to pay more attention to. Not necessarily agree with everything that it would say. But it would point out to a place where you probably would skim through and just say it's fine. But then you would stop and read the comment and start thinking if that's actually a legitimate issue or could be closed. So you mentioned Markdown files as well. What do you do? What do you put in the Markdown files within your project? We've got multiple Markdown files. There is a main Markdown Cloud.md. And then we have an architecture overview, a separate Markdown analytics overview issue reporting. And in Cloud.md, we reference to these files. We say whenever you implement this year reporting, read instructions from this file and follow it. Yeah. Would you recommend whenever you do AI assisted code tooling to set up kind of a similar structure in Markdown? I would definitely do that in the future. I like it. It works for me. I can definitely see how this could be an initial investment that you have to do. But it pays off for me. It pays off for us as a team. It pays off. What do you mean with an initial investment? As interested that out? Yes. OK. You definitely need to guide. You can write them yourself. You can generate them with Cloud as well. But it can hallucinate. It can put in things that do not exist in the code base. You have to be not fluent in the code base, but confident enough to review these files. And otherwise, if it puts some architecture patterns that you don't actually follow in architecture.md, all of a sudden you start getting very weird output. So these Markdown files, are they instructions? Or are they also something that it continuously adjusts and improves? Continuously adjusts and improves. Oh, interesting. OK. It's also a good kind of hygiene habit to whenever you work on a feature. If you do this with Cloud or whatever AI tool, you mention if there is any relevant changes that you have to do in these Markdown files, please do. Yeah. Interesting. Especially with your experience coming as a mobile engineer. You were first very fluent with regards to the iOS ecosystem. And now you're doing also-- I'm assuming Android ecosystem. How is that knowledge going to cross over? Which knowledge, sir? the knowledge of the iOS ecosystem and now the implementation on Android side. So I know as a mobile engineer and I did work with Kotlin before. Yeah. Atuber I wrote in Kotlin for half a year. So it's not that I'm coming with zero knowledge, but definitely not a lot of knowledge that would that that professional Android engineers would have. So with cloud it's a lot easier for me because I know how a feature should be done and integrated from the high level perspective. But I actually don't know SDKs and the Android way of doing things, right? Some of them are very alien to me. Some patterns are very alien to me. And then I lean on the cloud to actually write this thing for me. I will get to the bottom of it and understand what it did. But it helps me to get this over this initial hill of actually implementing the thing that that that would work. Yeah. It does the knowledge transfer like of the mobile ecosystem in one, let's say iOS versus Android. To a degree, I guess you can write, you can follow some patterns even on the back end, right? It's general programming, right? But I guess with UI and Compose, which are, I as an Android UI libraries, they follow somewhat similar principles. So it kind of transfers, but not to 100%. No, for people that are new in mobile engineering at all, how would they get up and running fast with the tooling that's available nowadays? Because I feel like because you have strong fundamentals, you can, like you know, the patterns in one ecosystem and then you can see what is alien to you, but you have that frame of reference. And most people that are new, they will not have that. It is a very interesting question. I think that nowadays, it's more important than ever to read and understand the fundamentals first, right? Not probably not leaning on AI to implement everything for you. I know how tempting it is to wipe code your first application. So tempting. That's what I want to do. Yeah. But then you're missing out on learning the actual thing. And maybe in two years, you wouldn't need to learn this. I don't know. But my take is that you have to set up for the mentors yourself. Yeah. When you onboard new people, whether it is either in the company or in the team, do you also check for those fundamentals specifically during interviews? Yeah. I would. So I didn't do main interviews lately. But I would definitely check for those fundamentals. Yes. And has the interview process evolved with AI tooling that's now available? Or how do you assess someone? So in my view, classic interviews, they are kind of, they should be gone. OK. I can definitely see how for bigger companies that would still be a way of understanding if the person is worthy of getting into the company. But for smaller companies, whenever a person comes to an interview, they would probably or engineering interviewer, other, they would probably do some lead coding for a month. Yeah. They would pass an interview and then they would completely forget everything they would do on lead coding because lead code because all they would do is change colors on the button to drive this revenue growth 0.1%. Right. I was like booking. Apparently. So it is kind of pointless. And for smaller startups, I hear more and more stories when they basically do some initial filtering and then they offer a trial week for the person to work with them to actually understand whether this person is good to work with. Right. Because that's the most important part, especially for smaller teams, for smaller startups that you still have the occasion that the other person has the work ethics, not that they can, I don't know, they know what a threaded binary trees. But yeah, I think that's the future of the thing because of interviews, because technical parts specifically, right, you would still probably want to have some filtering in terms of like behavioral interviews and whatnot. About for the technical part with AI, you don't need that much reversing linked list for a constant memory. No, you don't have to have a top of mind. So our interview process, and this is what I did six, seven years ago, was like a take home assessment for eight hours because indeed, like you mentioned, company doesn't quite believe that lead code and also in consultancy and software engineering, it doesn't translate to what you do on the day today. So the project is more in line with what you would do. And it's actually a project and you can choose if you focus on front and back. And if you actually deploy your things, if you make it up and running, you get a lot of room to experiment. And then AI is just go to and came around and we saw a lot of people within the funnel use that. And a lot of conversation was, okay, are we going to allow that or should we be explicit and say, don't use this? And then we made a conscious decision. People can use whatever tooling they want, but then be transparent about it. Actually, say that you've done this and we'll have a different type of conversation because then we're going to talk about how well you understood what it was generated. Right. And if you can actually read it or if you maintain it or how you set up your project to be able to execute on this and what you think of the efficiencies or the trade offs there specifically. So within the same interview process, it's still the same assessment. We've kind of tater made it towards people that do use AI assisted go tooling. And we've now even gotten to the point where we expect it. And when someone doesn't, then we feel like maybe you should because that's kind of where the industry is going quite interestingly and not looking at your code. Maybe you're not from that. That's right. But yeah, more than the general sense. I definitely like your take on or what you've seen other companies do in doing like a trial week. I don't know how possible that is with regards to like Dutch law and stuff. But in essence, if we disregard all of that, I would love to work with someone on a day to day for a week. And that form kind of the criteria of, do I want to work with this person or not because then we've already done it. Yeah. And I feel like the people that would go through a process like that. Maybe it's hard to put myself in the shoes because I do go from kind of assessment or from project to project more often. But I would feel more comfortable if I have a longer time to actually show what I'm worth rather than a one hour kind of system design or a conversation or lead code thing. Absolutely. It's a bit more lenient. Yeah. And nowadays a lot of companies are opting for remote interviews. Yeah. Not even on site where you can casually talk to a person where you can have lunch with them. And that's how I was, how my interview was at Uber. We had lunch together with the team I was interviewing for. And I guess that's a little bit of, like you have to spend time setting these things up. Right. But then you are that little bit more confident that the person is not. That's called a bad person. Still a week with a person in working context will give you a lot more insight than any kind of behavioral interview camp. Yeah. What specifically do you look towards or do you look for in the people that you work with or collaborate with on a day to day basis? Be nice. Be nice. Yeah. But that's if you're nice to other people that can open doors that you, you wouldn't have opened otherwise. Right. Other people can go extra mile for you if you ask them something. If you are nice to them. Yeah. Right. And I think I read this article that Google made a study that it's the ultimate key to working together. If you're nice to other people, you're successful. You're team is successful. Maybe it's the way I grew up. But for me, that's, have you been in an environment where people are not nice to each other? Because I do think that, I mean, we're knowledge workers. And if you have in depth knowledge and expertise within a certain topic, you might be arrogant and that might kind of take away from your kindness towards others. That's the thing that I've seen. I can definitely relate to that that people who have strong opinions and sometimes I do have strong opinions. It's not that I'm, you know, like a plushie. You go the way. But you definitely need to know where your opinion matters. Right. And then whenever if you're making an argument out of every single point, then your argument kind of diminishes, right? Your opinion. You will struggle to make a point. If you know what I mean, if that makes sense, that everybody would see you as a person who is always against some things who always wants to things be their way. - Yeah. - You cannot differentiate between what is important. - Exactly. - Yeah, exactly. But then whenever you are okay with, you know, one of the things that I love to follow is disagree and commit. If I'm in the minority, if I see that other people's marked people, they have different opinions, I'm fine saying, okay, I'm committing to following your path. I'm fine with that. But then whenever I actually feel something strongly about, then I will try to convince another people would listen because they're not used to me doing this kind of thing. So I think that's also important to pick your battles. - Yeah. I feel like I used to be very idealistic and like you can make a point out of a lot of things. And now I'm trying to be more, indeed, when does it matter? Is this going to be a key differentiating factor? And I understand disagree and commit. I feel like if you read about it, you will understand disagree and commit. But understanding and behaving according to that is very different. - Absolutely. - I've also seen people say, yes, I agree with you, but and then the butt completely, like just takes it out of the water from me. That kind of undermines it completely. And especially within a team where you have a lot of people with very great skills, let's start with that. But also because of that, very interesting opinions, discussions can just go and snowball. And you do need a specific either person or a team mindset that just says, okay, these discussions are no longer valuable. We need to cut it and we need to make a decision and we need to go with that decision until we find otherwise, basically, which is also fine. - Yeah, absolutely. And another thing that I learned in my previous jobs is that this state of analysis paralysis where different people, smart people in the same room, they cannot find the agreement. So most senior person has to stand up and say, okay, we are doing this. I see that this is not going anywhere, right? We are going to discuss this today and the same with the same passion, we are going to discuss this tomorrow. And in five days, nothing's gonna change. So we just follow this path and we disagree and commit. - Gotcha. You mentioned kindness and one of the things that you're looking for being nice to each other. What other things are you looking for? I guess that, well, obviously being smart and being proficient in what you're doing. On the other hand, I understand that some things, at Uber, my manager used to say a thing that stuck with me, probably forever, is we are hiring people for their strengths, not lack of weaknesses. And trying to identify those strengths during interview or the trial week or whatever you're following. I guess that's one of the key traits of any interviewer. And these strengths, they can be anything, right? And they actually have to be different because you want to have a variety of people, different people in your team. If you are hiring 10 little copies of yourself, you are only going that far. As I think it's Steve Jobs who used to say, if you want to go fast, go alone, if you want to go far, go together. If you are hiring copies of yourself, you're still alone in my books. I mean, me as a little kid, that made complete sense to me because if I copy myself, I would go and be more effective in nowadays, as an adult. I'm like, yeah, then you don't accommodate for any of the downsides that you have. How well aware are you of the strengths that you have, specifically you as an engineer? 'Cause if someone were to ask me what are your strengths, I would definitely have to think about it for a bit longer. Before I can say, this is really what I'm good at. - Yeah, I would definitely need to think about it the time I want to be. But I've talked to a lot of people and specifically about you, and they do say you're a great engineer, which I think is quite cool. (laughing) I would need to think about it. - No problem. Where do you see the mobile, and specifically the app industry going, that has it changed with regards to AI and some of the apps that are out there? I feel like a lot of people are creating little startups and then their artifacts and app that launches on the App Store more so nowadays than previously. But if I were to start my career, would a mobile engineer still be a good career choice from your perspective? - I think engineering in general is probably not the best career choice nowadays, given the amount of junior roles that are open. - Yeah. - And I have no idea how it's gonna go, but looking at how it is now maybe in 10 years, engineering is gonna be very sparse as a field. But yeah, it's such a difficult question with the, with the pace that the world is changing every month. I would refrain from giving any recommendations in that regard. And I definitely feel very, well, not bad, but it's scary to be a graduate engineer nowadays, I think. - Yeah, I didn't expect you to go on the side of, there might not be, I understand there's not as many job opportunities as let's say COVID, where I think that might be the peak with regards to job opportunity that we had. And now definitely when you talk about peaks and dips, we're definitely on the lowest side, I think with regards to job opportunity. And maybe I'm hopeful, maybe I'm naive, but I do think skills will evolve and there might be more emergent roles, even though a lot of the things that we do day to day, they are getting automated. - Absolutely. And I think I love an AI take, I don't remember who said that, but AI, the saying goes that AI is not going to take your job, the person who knows how to use AI, better than they will. So definitely the industry is evolving towards more AI usage and if you're not using AI, now probably you're missing out on something that in the future could be pivotal for your career. But well, you said that there are a lot less job opportunities nowadays, but there was actually a study, I think from Harvard, that there are a lot more, well not a lot, but there is a rise of senior plus opportunities, jobs, but a huge deep in junior roles. So it's much easier to get hired as a senior plus engineer. - Yeah, interesting. Talk about career perspective. Specifically, I know you have an interesting story and how you got into mobile. Let's start there. How did you get into mobile in the first place? - I think it's for everybody, they would not be able to pinpoint the moment in life that, well not for everybody, but most people would not be able to pinpoint the moment in life. For me, it was very clear, my manager back in 2008 or not in 2006, I think it was, they came into a room and they said our company got a contract for macOS application. And we didn't have macOS engineers, so they had Mac Mini in their hand and they put it on my desk and said, "You are going to be our macOS engineer." - Yeah, that's it, it's you. - And yeah, I was surprised to say the least, but yeah, I learned, I learned with, I made a lot of mistakes along the way and obviously there were no tooling that is similar to what we have now and the documentation was a lot more sparse. I had to learn Objective C on developer.appl.com and it wasn't great to say the least. So I made my fair share of mistakes and some of the mistakes were really bad for the company that I worked for. They lost the contract that they came, that got me into macOS because of the mistakes I made. But also, kind of when I, as iPhone SDK, it was called, when it came out, I didn't have to learn Objective C. everybody was struggling with those square brackets and trying to understand why the hell having Neil or Null as a pointer to Null, why can't we send messages to it and why the app is not crushing? It's just undefined behavior. And I was okay with that. I've been doing that for two years at that point. And obviously there were macOS engineers out there, a lot of them. But not nearly as many as the amount of people who wanted to get into IAS engineering. I have one engineering. So yeah, I was lucky enough to have this experience under my belt. I also had quite some experience with mobile at that point. So iPhone SDK, I think it came out in 2009. And I was doing macOS. I also was doing mobile, Windows, mobile, Symbian, it was a UAQ, I wrote apps for those. Obviously not in Objective C, but it's still mobile. So from the same ish area. So I was aware of some of the constraints that you have to keep in mind and well developing for mobile. - Yeah. - Do you think mobile industry, specifically for mobile engineer, you will more so work towards consumer facing technology? Like in consumer facing domain? Because I feel like as a back in engineer, I've worked in B2B settings. And then people learn, oh, I actually want to work towards something that is more consumer facing. I feel like if you're a mobile engineer, apps typically go to the consumers. - Yeah. - No, absolutely. And honestly, as a mobile engineer, and I know people are different and the mobile engineers are obviously different as well. But for me, it's very important to have something that I work on, I have in front of people and a lot of people, right? I definitely learned my lesson when I was working on an app that was not really needed by anyone and the company was developing it just because they wanted to have presence on the app store because competitors do. So every single company after that one, they were very consumer facing. And moreover, their mobile app was the core of their business. - So you actively sought out for apps that made impact for the consumers and where mobile was a core part of the business? - It's not that I sought that, but I actively reject companies or don't start conversation with companies that don't do that, basically. And that you still have that same mindset, that is the type of company and the industry you wanna work in. - Absolutely, yes, no, yes. So this is consumer facing. I understand that some B2B apps might also have the same, well, probably they would have the same scale in terms of the amount of people, but in terms of usefulness that every employee of the company would have this thing installed and they would open it regularly for whatever reason. But if you have an app like Workday on your phone, that's something, why would you have it on your phone? They do have a mobile app. - They do. - And I did have it just to get push notifications when my vacation request was approved. And that's pretty much it. I've never had a messaging queue. - Yeah. So that, again, not to say that it's not needed, but for me, it is way more important. And maybe behind the scenes, the technology that is powering this app is amazing and it's super interesting to work on. But for me, there is not enough motivation to work on such kind of stuff. - Yeah, I like that a lot. Like I feel like when it comes to an industry or a technology stack, I don't have the same level of clarity yet where I go to a company and I say, "This is really what I wanna be working on." And I feel like you had that. You had that throughout the learnings. Even though by chance, you were kind of the person that was brought forward to learn about this technology and then through that, you came into mobile specifically. You still found this industry or this type of company or you rejected any other. So there was no other option, basically. So I love that amount of clarity. I think the sooner you have that, the better it is for. Probably you're feeling of fulfillment because then you can get to that position and just by virtue of you being in that position, the position that fulfills you, you're motivated. - Absolutely, yeah. - I like that. And Uber was a big part in that, I'm assuming. - Absolutely. - Because Uber, when it comes to their mobile presence, it's like all in. - Yeah, you be good with this. And I think I was lucky enough to get into Uber in 2016, right before they started the big rewrite of their mobile app. - Yeah. - And it was a huge undertaking. You can imagine that for the company that is, that the mobile app is the core of their business, the only thing that brings revenue. And then all of a sudden, you start to rewrite this. And then you start to get a new thing from scratch. It is a risk-emove. And they wanted to do it very fast. The initial estimation was to rewrite it in three months, millions of lines of code, hundreds of engineers, mobile engineers. Yeah, it was crazy. But then it gave me so much experience with how those kind of things could be navigated. And actually also understanding that rewrite always the answer. - Okay. - Right. - So what did it not fix in the end? - What can you learn from that experience? - It fixed a lot. It broke a lot of people. - Oh, that's it. - Yeah, I mean, it's not even a joke 'cause people got burned out. - Okay. - That's straight up left. - Yeah. - But you were not one of these people. - That's another thing that I have very strong opinion about that I try to separate my personal life and my work life. And definitely when I get very involved into projects, I can do overtime. It's not a big problem for me, but I'm always aware where my line is. Right, I will not work during nighttime. Even if I'm super into it, I know that our future Pasha is going to regret this. So I'm not doing that. And I saw a lot of people who burned themselves to the ground just trying to push this thing out. And I understand probably that I had the luxury of having my approach for the expense of these people. Because they were doing work. I don't know if you could be efficient in like 3 a.m. and the night. - Yeah. - But on the other hand, the company would survive if the project would be postponed for three more weeks. It would have been fine. - Yeah, exactly. That's why I don't like the word deadline. No one ever dies when that deadline has passed basically. So things will move on. - Yeah. - Probably you lose a lot of money, but that's. - That's money is different though. No one dies. I hope otherwise is the wrong type of business to be in. - Yeah. - We'll talk to me about that experience specifically. I'm assuming that with an engineering culture, at least at the time that Uber had, I know a lot of great engineers that come from that. You're gonna have very interesting discussions on what do we do? How do we optimize or which decisions actually matter? Do you have a specific topic in mind where you were like, "This is actually where I had a very strong opinion on this is what we need to do?" - So from the times of the rewrite, I probably cannot recall such things because I just joined the company. - Yeah. - And it was really funny because I was interviewing in April and I specifically asked it was 2016. So Swift was already there for, I think, a couple of years at that point, but it wasn't mature, right? And I asked during the interview, "Do you use Swift?" And the answer was, "No, we are doing objective C. "100% Swift is not mature enough. "It cannot support our scale." Then I joined first of June and by the end of June, we got a message from CTO saying, "We are rewriting this thing in Swift." - That's quick. That's really quick. - So yeah, that was fun. But so that's for you to understand that I was in the company for a month at the point where you rewrite started and at that point, we were all hands heads down, actually execute here. There was no time to understand what's going on. - Yeah, exactly. - Well, any other specific time in your experience at Uber where you were like, "Okay, this was really an opinion "that I had to push for 'cause I'm curious how you did that." - So much, much later after we did the rewrite of the app and the team announced our down, we were focusing mainly on payments. We saw a huge inefficiency in terms of integrating of the payment framework into new apps and Uber started to acquire new businesses more and more often. So we had to integrate the framework into new apps. And long story short, we delivered the new USDK, which was much, much more efficient and pleasant to use. But I had a big struggle convincing people that we have to migrate existing usages of the payment framework of the old one until a new one, new approach, which was nicer, more efficient, allows for more monitoring, alerting and whatnot for a specific use case, for example. But since this doesn't bring any revenue, right, there is, you cannot put any money on these kind of migrations, metrics have to actually remain stable for the migration to be successful. - So you're neutral. - Exactly. Or negative because you are actually investing engineering time into that. It was really, really hard to convince people that this is something we actually have to focus on because now we have two different ways of integrating payments into the app. How do we explain engineers from other teams which way they should use? 'Cause they used to the old way, they've been doing that for, four years now. What do we do? So we had to actually go and educate people on what money SDK is, how to use it, what are the benefits we had to sell this to other teams. So they would either themselves put migration onto the roadmap or we would do that for them. - Okay. - Which in the end turned out to be the vast majority of cases and then I had to convince our leadership that this is worthy, that we have to do that. - Gotcha. How long did that take from your idea of, okay, we have to do this to eventually having people convinced that this is the way to go? - So the idea of the SDK itself, it was the end of 2019. The implementation took, I think, a year, to actually hide all the complexity behind the NYSAR APIs. First of all, to see what the NYSAR API is gonna look like. - Yeah. - And then hide it. And after that, it was like 2021 and the migration is still not done as far as I know. - Gotcha. - So, going. - It's a big organization for you. It's really, really hard to convince people to do things and sometimes they use and abuse your, your SDK in ways that make it a lot harder to maintain in the future. - Exactly. - And that's why I personally am a huge advocate of hiding as much API as possible, making it private, basically, not allowing to do anything from the outside as much as possible and opening it up only if there is a strong use case. - Yeah, you get that. That's really hard when it comes to them because I'm now working in a landscape where we're building a platform and we're trying to integrate with a lot of mobile applications through SDKs and they also have kind of a similar approach where not everything is exposed. But yeah, circling back to what you mentioned, this was really a topic where would you compromise on this? Or you wouldn't really compromise on this? - I would not compromise on this. I knew that, well, first of all, that was my baby, the thing that got started, I started from the, well, there were a bunch of people, but I was among the people who started this thing from zero essentially. And I knew that this will bring a lot of benefits along the way and in the future. And keeping two ways of doing the same thing is not it. - It's not sustainable. So the thing is that I've been working at that point for five years at the company, right? And usually when something, when people from other teams had questions, they would come to either me or my colleagues and we had an influx of messages all the time, "Hey, how I do this, why is this not working? Why is that not?" Well, because you're doing the old stuff, my great please, and then you wouldn't have those questions. No, we need to move fast, we need to. - This is it, we don't have a choice. - We don't have a choice. And then we had to migrate this case and then all of a sudden, "Ooh, that was easy, it's so much nicer to use." - Yeah. - All of a sudden. - Was this one of the reasons why in the end, you ended up leaving? Because the migration is still not finished this day. You've moved on since. - Well, definitely not because of the migration. - Not a single thing. - No, no, there was no one particular reason. - Yeah, there were a lot of little things, for example, a stupid reason that it was 2022. So COVID just kind of started to end. And I've been working from the office in next to Amstel station. It was quite close to my house, so I had to bike like 20 minutes. And Uber announced that they are opening this new and shiny office, which they planned to move in 2024. - Yeah. - And it was so far away. And I got so annoyed that they started to brag about accessibility. This office is so nice. It's so close to, well, not from here. - Everything else, yeah, everyone else. (laughing) - So, and again, I'm not saying that this was the reason, obviously, but it was one of the things that tipped me over. And I want that it's been six years at that point when I left. And it's definitely, it felt like the right time to move on. I found myself in meetings I felt that I had no business with, like, why am I there? Only because I knew how historically things were evolving and how they were made and why they're made a certain way. - Yeah. - Because of your knowledge and history. - Yeah, basically I saw the payment framework built from the ground up and then being migrated to the next money SDK. And I knew the reasons why certain things were done in certain ways or shortcuts been made. So I understood why I was needed or sometimes I didn't understand. - I was there enough, yeah. But yeah, it was definitely not something that I was very interested in. And some people are completely fine with this kind of work. I would say, but for me, I love to build things. I love to be an engineer, not like a meeting engineer. - Gotcha. You actually want to create, not just make sense. I don't think I would be happy being a historian of the code base, like explaining why we have things. But maybe once, maybe twice, but not continuously, like as a daily or a weekly thing. - And I found myself explaining certain things over and over again. At this, I definitely now see a lot more value than I saw back then actually. I see, for example, a CEO of my new company is repeating himself all the time. And I understand, like all of a sudden there is this light bulb. They're doing this to make sure that they convey the message that it's well received. 'Cause for me, it felt stupid. I've already said this thing once. - It's like, why do I need to do twice, twice, four times? (laughing) - It's such an engineering mindset, yeah, I agree. - Actually, it is so, so useful because some details, people don't pay attention because that's not their field, that's not what they are interested in. And then you have to put it out there multiple times to make sure that it's actually understood. - This is what I really learned in product. And maybe it's also the type of person I am. I, when it comes to product and why we do things, I will take all the time you need. I have all the patience to help you understand why we do things. Because I think from an engineering standpoint, that is incredibly valuable to understand why we do things so you can execute better, you can think along from a different perspective. In product, I really took as much time as we needed. And I mentioned that to every person in the team, don't worry about asking again. I will sit down and will explain and will go through it. Also because the domain was more complex, it was in sustainability, it had to do with ESG and metrics and KPIs. And I think that is valuable. I want that in my product person as well. So the fact that you see it in your CEO, I think that's quite admirable that they keep doing that. - Yeah, absolutely. - And understanding the way is actually, it was a revelation for me. For me, as an engineer, one of the most, I wouldn't say powerful, but one of the things that I'm not, that I keep saying, I'm sorry, I don't understand. If something I don't understand, I would call it a I call it out and ask the other person to explain to me that I actually understand. If that's something that is out of my field and they would go through some things that seem relevant, but then I have no idea what they're talking about. It's okay to not understand something. It's okay to say it out loud and ask them to explain because one of the things that people actually love to do is to explain something they know. And if you say, "I don't understand," they would love to explain this to you. Yeah, at least I hope so. I've also seen people where they said, "I've already explained it," and then they'd lose it. I really shouldn't be like this. Like, having an understanding. And also, especially early on, I felt bad saying I didn't understand things. Then I realized this is obvious. I was a junior in the team. It makes sense for me to not understand things. The worst thing I could do is saying, "I got it," when I actually didn't get it. That's even worse. 100%. Yeah. You worked in payments at Uber. Have you always worked in because I think payments is quite a crucial domain when we're talking about kind of habits, how it makes money, so probably it needs to work quite well. You always worked in more crucial sides of the app, they're beyond as well. It was mostly payments. We did develop kind of react native kind of thing framework because so initial struggle was the inefficiency that we saw that in different countries, drivers, whenever they want to fill in their bank account requisites, whatever it's called, they would have to fill in different forms in different countries. The regulations were different. It was initially done on the back end, the rendering part, and it was done in code. So basically, you have to be an engineer to add a new field onto this form. We wanted to make it easier. We wanted to actually build a system that would resemble react native. We were lucky enough that was a person who actually built react native at Facebook. They knew what kind of inefficiencies that system had. They came with this knowledge in Uber, in the company, and helped to shape this thing. But for me personally, this journey ended pretty quickly. I had to get back to payments. I got an offer I couldn't refuse from my director. So yeah, it was mostly payments. Gotcha. Have you worked a lot with cross-platform technologies like react native and stuff? No, no. I heard that TikTok opensource their framework. It's called links. They fixed some of the inefficiencies of react native. I did hear about that. I didn't try it. Because I'm interested. Why has it been that you've always worked with the native technologies respectively? Mainly because react native doesn't feel native. That's something that we tried to fix with our framework at Uber. I think we achieved pretty good results. I say I was not in the team when they achieved very good results with it. Unfortunately, they struggled a lot with adoption within the company. So they had to cancel the project. But the technology was amazing. For me, none of the back-then-modern cross-platform technologies felt native. And I love beautiful interfaces. I love good interactions that would not look like Android interface on IS app or vice versa. Sometimes you just have to go native. Yes, there are parts of applications that are less important, less relevant. But you still have to have them. So you probably can do them with react native and alike. But you have to be very picky if you want to deliver great user experience. Do you think nowadays the landscape has evolved to where cross-platform technologies have bridged that gap a little better? Maybe, but as I said, I didn't dive too deep into it lately. Probably, everything evolves. And I guess a lot of people, it's not only me who has this idea that cross-platform is actually not nice. So, I see that being fixed, but I didn't try it. No worries. I'm then wondering since you've really had this opinion of, I want to be at companies where mobile is core to their business, do you see yourself striving away from that? Or is this really just the career path for you also towards the future? Every day I, maybe two months ago, not two months ago, half a year ago, if someone would tell me that I would write Android code, I would be very surprised. And now look at me, I'm an Android engineer. But yeah, I'm joking, obviously. But yeah, I actually started back in 2005. I started as a backend engineer. I wrote in Java and then the destiny put me on that path of mobile engineering. But yeah, I can definitely see doing whatever is needed. And I'm in the luxury position of writing Android and learning new technology while being paid as a senior plus engineer. I think this is also very important if you want to change your career path. You either have to get a pay cut or you have to be in this luxury position where the company trusts you enough that you can learn while be less efficient, learn and excel at this new field later on. Yeah, absolutely. As a last question, I still had it in my mind. It might be a little bit of a personal one, but you've been in the mobile field very hands on for a long, long time. And now with AI, that's changing. Is it still fun for you or has the joy kind of evolved in a different way? You're less hands on typing, you're more orchestrating. Has the joy changed? Does this still fulfill you? I think that's what brought me some joy back. I love learning new things. I love doing something I've never done before and that's why I'm here. But yeah, learning doing Android while I have very little idea of what is happening is actually very exciting. It's actually really cool. I find this opportunity, I'm really grateful for the company to believe in me and to hire as a kind of cross-platform engineer, if you will, because that's something that brought me this joy back. I have in my previous company I definitely didn't have this much fun as I do know. I love it. Yeah, I love that. Thank you so much for coming on and sharing your, not just your perspective, but also your career path. I think there's a lot of interesting learnings for people that want to become mobile engineers or already on that path. So thanks for coming on. Thank you. It's been a pleasure. Cool. We're rounded off here. If you're still with us, let us know what you thought in the comment section below of this episode and we'll see you in the next one.