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

The world is is changing every month. It's scary to be a a graduate engineer nowadays. AI is not going to take your job. The person who knows how to use AI better than your, they will pick your battles, disagree and commit. I 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 them 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 for more on the productivity side nowadays on a day-to-day, what do you use in AI tooling 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 a console or multiple consoles with with cloud open and basically I'm trying to use it as a junior slash medium engineer, fellow engineer who can help me bounce of ideas and who can help me with code reviews. For example review my code in in in the 1st 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 to to the AII think it could be very helpful in in this regards. Definitely. So I recently joined that new company and definitely AI was super helpful when it comes to learning new code base, right? You can ask it anything. What kind of features do I have in, in this code? What are the entry points to these features? List them out and point me to the files.

And then I go there, I look look at the code and I I understand how it's all orchestrated and how it all works. Can you do this with multiple terminals as well?

Yeah. How? How do you manage that? So it's T Max, basically a split of 4T Max windows. And that's something also I, I started to use very recently. Before I didn't use windows splits at all, or terminal splits rather. But with Clod, it's actually very, very useful because in one window, in one pane, I guess it's called, you have a feature planner, 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 kind of have to remember which pane is responsible for what. But then in the end of the day you 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 kind of purposes within a pane. Yeah, yeah. So I've got multiple repos of the same project setup. 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 another repo. 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 clearing 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, this is definitely a 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 there are work trees Git can do 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 off 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 to work with 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 a command that would just check out a new branch and well, put a command that the new branch and and finish it. But for that I need to stay in develop and that's kind of how I operate, how I used to it. So for 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 if efficiency increase. For me personally, I see efficiency increase, but what I do is I actually use them as a as a junior engineer, not letting them do everything for me, but rather review their code, their AIS code. How do we review specs, iterate on specs? I I read what they write basically and yeah.

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 an autonomous agent. Maybe it's also the project that I'm in, 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 than 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 artefact of that that's. 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 yeah, you. Mentioned markdown files as well. Well, what do you do? What do you put in the markdown

files within your project? We've got multiple markdown files there. There is a main markdown cloud dot MD and then we have an architecture overview, a separate markdown analytics overview, issue reporting. And in cloud dot MD we reference to these files. We say whenever you implement issue reporting, read

instructions from this file and and follow it. Yeah. Would you recommend whenever you do AI assisted gotooling 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 that initial investment as in to set

that up? Yes, OK, you would definitely need to guide, but 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 dot MD, all of a sudden you start getting very weird output so. These markdown files, are they instructions or are they like also something that it continuously adjusts and improves? Continuous continuously adjusts and improves interesting. And it's also a good kind of hygiene habit to whenever you

work on the feature. If you do this with cloud or like whatever a a tool you mentioned, 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, right? How is that knowledge kind of crossed over? Which knowledge?

Sorry, the. Knowledge of the iOS ecosystem and now the implementation on Android side. So I know as as a mobile engineer and I did work with Kotlin before, yeah, at Uber, I, I wrote in Kotlin for half a year. So it's not that I'm coming with 0 knowledge, but definitely not a lot of knowledge that would that that professional, professional Android engineers

would 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 SD KS and the Android D way of doing things right. Some of them are very alien to me and some patterns are, are very alien to me.

And then I lean onto Cloud 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, you know, get this over this initial heal of actually implementing the thing that that that would work. Yeah. Does the knowledge transfer like of the mobile ecosystem in in one let's say iOS versus Android? To a degree, I guess you can, right? You, 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 IS and 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 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 vibe code. Your first IS application, so. Tempting. That's what I want to do. But then you you're missing out on 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 you have to set up for the mentals 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 you mean? I would.

So I didn't do many 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. I can definitely see how for bigger companies that would still be a way of understanding if the person is worthy of, of getting into the company.

But for smaller companies, whenever a person comes to an interview, they would probably or engineering interview rather they would probably do some lead coding for, I don't know, 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 colours on the button to drive this revenue growth. 0.1% right? Yeah, that sounds like booking

apparently, yeah. So it is kind of pointless. And for smaller startups, I, I hear more and more stories when they basically do some initial filtering and then they offer a trial week for the, 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 start-ups, that you still have the cohesion that, that the other person has the work ethics.

Not that they can, I don't know. They know what a threaded binary tree is. But yeah, I, I think that's the future of the thing because of, of interviews, because technical part specifically, right? You would still probably want to have some filtering in terms of like behavioural interviews and whatnot about for the technical part with AI you don't need that much reversing. Linked linked list for a constant memory no. You don't have to have a top of

mind. So our our interview process and this is what I did 6-7 years ago was like a take home assessment for 8 hours. Because indeed like you mentioned, company doesn't quite believe that lead code and also in consultancy and software engineering doesn't translate to

what you do on a day-to-day. 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 end, if you actually deploy your things, if you make it up and running, you get a lot of room to experiment. And then AI assisted go to and came around and we saw a lot of people within the funnel use that and a lot of conversation was OK, 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?

If you can actually read it or if you maintained 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 tailor made it towards people that do use AI assisted Co tooling and we've not 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 enough, looking. At your code, maybe you should. Not, not from that, that's right. But yeah, we're in the general sense, Yeah.

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 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 sew 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 how I was, how my interview was a tuber. We 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, let's call them like, a bad person.

Still, a week with a person in working context will give you a lot more insight than any kind of behavioural 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, that's. If you're nice to other people that can open doors that you you wouldn't have open otherwise, right? Other people can go extra mile for you if you ask them something if you're nice to them. Yeah, right. And I think I read this article that Google made a study that it's the ultimate key to to working together. If you're nice to other people, you're successful, Your 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 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 plushy you go with. A win, yeah. But you definitely need to know where your opinion matters, right? And then whenever, if, if you are making an argument out of every single point, then your argument kind of diminishes, right? Your, your opinion, you will struggle to make a point, if you know what I mean. If, 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 OK with, you know, one, 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, smart people, they, they have different opinion. I'm fine saying, OK, I'm, I'm, I'm committing to following your path. I'm I'm fine with that. But then whenever I actually feel something strongly about, then I will try to convince and other people would listen because they're not used to me doing this kind of thing, right? So I think that's that's also important to pick your battles,

yeah. I feel like I used to be very idealistic and like you kind of 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 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, OK, these discussions are no longer valuable. We need to cut it and we need to make a decision and we need to go for with that decision until we find otherwise, basically, which is also fine, yeah. No, absolutely. And another thing that that I, I learnt 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, OK, we're 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're going to discuss this tomorrow and in five days, nothing's going to change. So we just follow this path and we disagree and commit. Gotcha. You mentioned kindness in 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 like being smart and being

proficient in in what you're doing. On the other hand, I understand that some things, you know, at, at Uber, my manager, he used to say thing that 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 trial week or whatever you're following. I guess that's one of the one of the key traits of of any interviewer. And these strengths, they can be anything, right?

And they actually have to be different because you, 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. Yeah, as, as I think it's Steve Jobs who who used to say if you want to go fast, go alone. If you want to go far, go together. But together. If if you're hiring copies of yourself, you're not, you know, you're still alone.

Yeah, in my books, I mean. Me as a a little kid, that made complete sense to me because if I could copy myself, I would go and be more effective. And nowadays as an adult, I'm like, yeah, then you don't accommodate for any of the the downsides that you have. How well aware are you of the strengths that you have, specifically you as an engineer?

Because if I were to, 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. Yeah, I think about a bit longer, 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, quite cool. I would need to think longer.

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 artifact is an 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 of junior roles that are open and I have no idea how it's going to go. But looking at how it is now, maybe in 10 years engineering is going to be very sparse. Yeah, as as a field, but yeah, it's it's such a difficult question with the with with this pace, with the pace that the world is is changing every

month. Yeah, I would refrain for from giving any recommendations that's for that regard. And I definitely feel very well, not bad, but like, 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 like I, I understand there's not as many job opportunities as let's say COVID where I think that might be the peak with reverse

the job opportunity that we had. And now definitely when you talk about peaks and dips, we are definitely on the lowest side. I think with reverse the 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, I love an AI take. I don't remember who who said that, but AI, the, the, the saying goes that AI is not going to take your job. The person who knows how to use AI better than you are, they will, Yeah. 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 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 in junior, junior roles. So it's much easier to get hired as a senior plus engineer. Yeah, yeah, interesting talking. About career perspective specifically, I know you have an interesting story and how you got into mobile. Let's let's start there. How did you get into mobile in

the first place? I think it's for for everybody. They would not be able to pinpoint the moment in life that that well, not for everybody, but most people would not be

able to pinpoint the the moment in life. For me, it was very clear. My manager back in 2008 or not 2000, 2006 I think it was, they came in into a room and they said our company got a got a contract for Mac OS application and we didn't have Mac OS engineers. So they had, you know, Mac mini in in their hand and they put it on my desk and said you are going to be our Mac OS engineer. Yeah. That's it. It's you. And yeah, I, I was surprised to

say the least. But yeah, I, I learned, I learned with, I made a lot of mistakes along the way. And obviously there were no, no tooling that is similar to what we have now. And documentation was a lot, a lot more sparse. I had to learn Objective C on developer.apple.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 I worked for.

They, they lost the contract that they came that got me into into macros because of the mistakes I made. But also kind of when iOS 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, Why the hell having Neil or null in as as a as a pointer to NULL, Why can we send messages to it and why the app is not crashing. It's just undefined behaviour.

And I was, I was OK with that. I've been doing that for two years at that point. And obviously there were Mac OS engineers out there, a lot of them, but not nearly as many as, as, as the amount of people who wanted to get into IS engineering, iPhone engineering. So yeah, I was lucky enough to have this experience under my belt and I I also had quite some experience with mobile at that point. So iPhone SDKI think it came out in 2009 and I was doing Mac OS.

I also was doing mobile Windows Mobile. Symbian was a UAQII wrote apps for for those obviously not in Objective C, but it's still mobile, right. So from the same ish area. So I was aware of some of the constraints that you have to keep in mind while developing for mobile, yeah. Do you think the mobile industry, specifically if you're a mobile engineer, you will more so work towards consumer facing technology like in the consumer

facing domain? Because I feel like as a back end engineer, I've worked in B to B settings and then people learn. 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, I as a mobile engineer and I know people are different and, and the mobile engineers are obviously different as well. But for me, it's very important to have something that I work on 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.

And it was tough to realise that you put so, so much effort into building something that people don't need. So every single company after that one, they were very consumer facing and moreover, they their mobile app was the core of their business. Yeah. 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 a conversation with companies that that don't do that basically and. That you still have that same mindset like that is the the type of company and the industry you want to work in. Absolutely, yes, yes.

So this is consumer face. I understand that some B2B apps might also have the same, well, probably they won't say 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, right. But if you have an app like work day on on your phone, right, 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, when my vacation request was approved. And that's pretty much it. I I never. Had like a messaging queue, yeah. So that again, not to 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 to do work on on

such kind of yeah, 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 want to 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 I the sooner you have that, the better it is for probably your, your feeling of fulfillment, because then you can get to that position and you're just by virtue of you being in that position, the position that fulfills you,

you're motivated. Absolutely. Yeah. 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, ubiquitous and. I think I, I was lucky enough to get into Uber in 2016, right before they started the big rewrite of, of their mobile app. And it is, 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, right? And then all of a sudden you start to rewrite this thing from scratch. It is a risky move. 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, was was crazy. But then it gave me so much experience with how how those kind of things could be navigated and actually also understanding that rewrite is not always the answer. OK, right? Why? Why is it so? What did it not fix in the end? What can you learn from that? Experience it. Fixed a lot it it broke a lot of

people. In that sense, yeah, I mean. It's it's not even a joke, 'cause people got burned out and there'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. Yeah. And definitely when I get very involved into projects I can do over time, it's it's not a big problem for me, but I'm always aware where my line is right. I will not work during night time.

Like, yeah, even if I'm super into it, I know that I future Pasha is going to regret this. So I'm not doing that. And I saw a lot of people who burned themselves to 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, right? Because they were doing work. I don't know if you could be efficient in like 3:00 AM in the night, right.

But on the other hand, the company would survive if the project would be postponed for three more weeks. Yeah, it's it would have been fine. Yeah. Exactly, that's why I don't like the word deadline. No one ever dies when the deadline has passed basically, so things will move on. Yeah, probably you lose a lot of money, but yeah, that's that's. Money is different though. No one dies. I hope. Otherwise it's the wrong type of business to be in. Yeah, well, 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 going to have very interesting discussions on what do we do, how do we optimize or which decisions actually mattered. 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 needed 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 percent. Swift is not mature enough.

It cannot support our scale. And then I joined 1st 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, that was fun. But it's so that's for you to understand that. I was in the company for a for a month at the point where rewrite started. And at that point we were all hands heads down actually executing. There was no time to understand what's going on. Yeah. Exactly. Wow. Yeah. Any other specific time in your experience at Uber where you were like, OK, this was really an opinion that I had that I had to push for because I'm curious

how you did that. So much, much later after we did the rewrite of the of the app and the team in Amsterdam, we were focusing mainly on payments. We saw a a huge inefficiency in terms of integrating of the 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 new SDK 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 onto a new one. New approach which was nicer, more efficient, allows for more monitoring, alerting and and what not for your specific use case for example. But since this doesn't bring any 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 to to be success. So you're.

Net neutral exactly. Yeah, 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? Yeah, because they used to the old way. They've been doing that for, I don't know, 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 had to sell this to other teams. So they would either themselves put migration onto the road map or we would do that for them, OK, Which in the end turned out to be the vast majority of of cases. And then I had to convince our leadership that this is worthy, that we have to do that. Gotcha.

Yeah. How long did that take from your idea of OK, we have to do this to eventually having people convinced that this is the way to go? So the idea of of the SDK itself, it was the end of 2019. The implementation took I think a year, the year to actually hide all the complexity behind the nicer API. So first of all, to see what the nicer API is going to look like and then hide it. And after that it was like 2021 and the migration is still not done as far as I know.

Gotcha. It's it's a big organizations for you. It's really, really hard to convince people to do things and sometimes they use and abuse 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 of hiding as

much API as possible, making it private, basically not 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. 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 similar approach where not everything is exposed.

But yeah, circling back to what you mentioned, this was really a topic where you 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 the thing that that got started like I started from the well, Collier. We there were a bunch of people, but I was among the the people who started this thing from 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. And I've. 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 have questions, they would come to either me or my colleagues. And we had an influx of of messages all the time. Hey, how I do this?

Yeah. Why is this not working? Why is that? Well, because you're doing the old stuff like my great place. And then you wouldn't have those questions. No, we need to move fast. We need to this. Is it? But we don't have a choice. We don't. Have a choice. And then we had to migrate this, this case. And then all of a sudden, oh, that was easier. Like 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 to this day. You've moved on since? Well. Definitely not because of the migration, not the single thing. No, no, there, there was no one particular reason. There were like 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, I had to bike like 20 minutes. And Uber announced that they are opening this new and shiny office, which they plan to move in 2024. Yeah. And it was so far away. And I got so annoyed that they, they started to brag about accessibility. This office is so nice. It's so close to, well, not everything. Else. Yeah, everyone else.

So, and again, I'm not saying that this was the reason, obviously, but it was one, one of the things that that tipped me over another one that it's been 6 years at that point when

when I left and it's definitely I, 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. Because of your knowledge and

history. Yeah, basically I saw the payment framework built from the ground up and then being migrated to to the next Money SDK and I knew the reasons why certain things were done in certain ways or shortcuts have been made so I understood why I was needed or sometimes I didn't understand. Fair enough. Yeah. But yeah, it was definitely not something that that I was very interested in. And some people are completely fine with this kind of kind of

work, I would say. But for me, I, I love to build things. I love to to be in engineer, not like a meeting engineer. Gotcha. Yeah, you actually want to create. Yes, not just makes 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 you know, I found myself explaining certain things over and over again.

And this I definitely now see a lot more value than I saw back then. Actually, I see for example, Aceo 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. Because for me, it felt stupid. I've already said this thing once. Like why do I need to do it twice, twice, four times? That's such an engineering mindset.

Yeah, I agree. Yeah. Actually, it is so, so useful because some details they 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 relearned in product and maybe it's also the 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 don't worry about asking

again. I will sit down and we'll explain and we'll go through it. Also because the domain was more complex, it was in sustainability. It had to do with ESG and metrics and KP is 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, quite admirable that they keep

doing that, yeah. I think it's a great thing and understanding the why is is actually was a revelation for me. And you know, for me as as an engineer, one of the most I, I wouldn't say powerful, but one of the one of the things that I'm not that I keep saying, yeah, I'm sorry. I don't understand. If something I don't understand, I would call it out.

I call it out and ask the other person to explain to me that I actually actually understand if, if that's something that is out of my field. And they would, you know, go through some things that seem relevant, but then I have no idea what they're talking about. It's OK to not to understand something. It's OK 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.

Right? And if you say I don't understand, they would love to explain this to you. Yeah. At least I hope so. I've, I've also seen people where they said I've already explained and then they 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 it's obvious I was a junior in the team. Like it makes sense for me to

not understand things. The worst thing I could do is saying I got it. Well, I actually didn't get it. Yeah, like that's, 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 app, it's how it makes money. So probably it needs to work quite well, yeah. Have you always worked in more crucial sides of the app there beyond as well? It's it was mostly payments.

Yeah, We did develop a 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, right? The regulations were different. So 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.

And we wanted to make it easier. So 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, what kind of inefficiencies that system had. So they came with their this knowledge in at at at Uber, in in the company and helped to shape this thing. But for me personally, this journey ended pretty quickly. I had to get back to to payments. I got a an offer I couldn't

refuse from my director. So yeah, it's it was mostly payments. Gotcha. Yeah. Have you worked a lot with cross-platform technologies like React Native and stuff? No, no, no, no. I heard that TikTok open source, their framework, it's called links where they they fixed some of the inefficiencies of React Native. I. Did hear about that? I didn't. Didn't try it. Yeah, yeah. 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 and that's something that we tried to fix with with our framework at Uber and I think we achieved pretty good result. I say we I was not in the team when 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 and for me none of the back then modern cross-platform technologies felt native. And I love beautiful interfaces, I love snappy animations, I love good interactions that would not look like Android interface on IS app or vice versa. Right. You sometimes you just have to go native. Yes, there are parts of applications that are less important, less relevant. So you can, but you still have

to have them. So you probably can do them with with React Native and the like, 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 didn't dive too deep into it lately. Yeah, probably, probably everything evolves, right.

And I guess a lot of people, it's not only me who has this, you know, idea that cross-platform is actually not nice. So that yeah, I I see that being fixed, but I didn't didn't try it. No, no worries. I'm then wondering, since you've really had this opinion of I want to be at companies where mobiles 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? With AI, maybe two months ago or

not two months ago, half a year ago, if someone would tell me that I would write Android code, I would be no way surprised. And now look at me, I'm an Android engineer. Yeah, but yeah, I'm joking obviously, but yeah, I actually started back in 2005. I started as a back end engineer and I wrote in Java and then the, you know, destiny put me on on that path of of mobile engineering. But yeah, I can definitely see doing whatever is needed.

And, you know, I'm in the luxury position of writing Android and and learning new technology while being paid as a senior plus engineer. So I think this is also very important. If you want to change your career path, you either have to, you know, 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. Yeah. Learn and, you know, excel at this new field later on. Yeah, absolutely.

As a last question I still had 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 it still fulfil you? I think that's what brought me, brought, 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 what is, what is happening is

actually very exciting. It's actually really cool. I I find with this opportunity, I'm I'm really grateful for the company to to believe in me and to hire as a kind of cross-platform engineer, if you will, because that's something that that brought me this joy back in my previous company. I definitely didn't have this much fun as I I do know I love that Amazing. 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 are already on that path. So thanks for coming on. Thank. You thank you. It's 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 comments section below of this episode and we'll see you in the next one.