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.