Leo Dion (host): Thank you for joining
me for another episode at Empower Apps.

Today I'm joined by Tjeerd in 't Veen.

Tjeerd.

Thank you so much for coming on.

Tjeerd in 't Veen (guest): Yeah,
thank you so much for having me.

Really excited to be here.

Leo Dion (host): Yeah.

Before we begin, I'll let
you introduce yourself.

Tjeerd in 't Veen (guest): Okay.

Yeah, so my name is Tjeerd.

You may know me from maybe
writing Swift in depth.

I've been working at Twitter for
the last year, which circumstances

change most people may know.

And before that I also worked at i
g for five years, but I helped scale

up quite a substantial code base.

So yeah, been Swift, developed iOS
developer for, since iOS 4, I think.

So

kinda

Leo Dion (host): while.

Nice.

That's a, that's a long history.

So today we're gonna be talking
about a book you're working on.

You wanna talk about what
that book is and yeah.

Why people should be interested.

Yeah,

Tjeerd in 't Veen (guest): so it's,
it's kind of interesting cause so I'm

writing mobile system design but it's
more I, I guess a contemporary topic

because nowadays people are honestly
quite, quite a bunch of layoffs

and people are are applying to jobs
and and they really associated it.

With interviews, but, but what I find
interesting is if you ask someone what

mobile system design is, they kind
of go like, yeah, maybe it's about a

modular app, or it's, some say it's
about interviews and some say it's about

like UI flows or any type of answer.

But what.

What I think you see a lot is like,
it's usually backend associated, right?

Like if you think about mobile or
if you think about system design,

you think about backend, like,
like the backend interview process.

But I feel like, what about mobile itself?

Like I know the joke is we just make
JSON apps, we rendered them in some

scroll view, but like if you take a
serious app, that's totally not the case.

You have like view like thousands of
little decisions you're making just

to make features, to keep adding
features, like abstractions, et cetera.

So I figured like, yeah, like mobile
system designer would be nice to write.

I have been writing before, so
I'm just taking a step at it.

Leo Dion (host): Yeah.

So can I describe exactly what
you mean by mobile systems design?

Like, yeah.

Are we talk, are we talking UI design?

What do we mean by system?

Like kind of break that

down.

Leo Dion (host): Yeah.

So,

Tjeerd in 't Veen (guest): Well, the
fun part is it's not really defined,

so I'm just trying to defy it, right?

Like, like if you, if you look at
the dictionary, maybe you can find

something, but well, how I look at
mobile assistant design is You have,

you get like a requirement, something
to make as a mobile developer, right?

We make things obviously but
how you approach that can be,

can be well varied, right?

Some person just goes straight into
UI and just makes stuff and makes

it work and another person thinks
about maybe all the sks and draws the

diagrams and like thinks about like
all the domains that are happening.

So, When I think about mobile system
design, I think about like receiving

the specs and requirements and coming
up with some sort of system like,

like, yeah, almost like in a graph way.

Like what is needed to make
these requirements work.

So let's say, let's take an example.

For example let's say someone asks
Hey, can you make a video upload?

One person may think like, oh yeah, I'm
just gonna, this may seem fair ui, right?

Right.

They may think I'm gonna grab the
photo picker and fill it on video and

then I click and then we'll upload.

But another person may think, you
know, video upload videos they're

large files, so they need to be stored.

They need to be uploaded in a, it's
gonna take a long time cause they're

large files, so maybe we need to
chunk them whatever the app is,

backgrounded so they can think more
maybe in these edge cases and all these.

Constraints.

And I think that's more what I'm
leaning to with mobile design is like

you get like a requirement and like a
thing that needs to be made and you.

Figure out all the parts that are needed
and also all the problems you may hit.

Also working with your team,
like like how does it work for

backend and what do they need?

So for your, for your feature
to work and, and so on.

So I think it's maybe a long answer, but
I feel like that's kinda where it goes.

Right.

And sort of the domain times.

Leo Dion (host): Well, that's what
I found really interesting about the

book is one of the things you really
tackle is asking the right questions.

Because I feel like.

That's a real difficulty.

I think you use, used the line like, so
there's, there's known, known unknowns

and then there's unknown unknowns and
that's like the, one of the bigger

challenges with designing a mobile app.

Right.

Yeah.

Yeah.

Tjeerd in 't Veen (guest): Like
if you receive a feature, usually

as a mobile developer, you get
them by getting UI designs.

And I think the, the real power there
is to really dive deep because if you

ask the right questions, you can maybe
even skip a couple spins of work cause

you may already tackle on some problems.

So, yeah, like you said
there, like known unknown.

Like, like, I know, I don't know
yet how I'm gonna make this.

I dunno, back in call or I know, I
don't know yet how I will have to

cash this data, but I know I have to.

And then there are, like you
said, the unknown unknowns.

Like Yeah.

Like I'm gonna hit more
issues or maybe not.

And, and I'm, I have to
keep that into account.

And, and it's about asking proper
questions to sort of uncover

those during the briefing already.

Yeah.

Leo Dion (host): So like, what,
what do you think is a good way to

like, make sure you ask those right
questions before it's too late?

Tjeerd in 't Veen (guest): Yeah, so for
a couple ways you can do with this, I

think one thing I like to do is sort
of try to break the feature and like,

there's maybe like a negative view,
but like, like thinking like like

what can I do to make this feature?

Go bad.

Like, like so yeah, let's take an example.

Let's take again, again
this video uploader, right?

Like if I, if someone gives me screens
and says, here, make this video uploader,

I'm gonna, you know, open SwiftUI and I'm
gonna make a video uploader screen like

you are gonna hit some problems later on.

Cause like, video uploading
is this own kind of beast.

So it's about figuring out,
like going through the motions.

Like, okay, just pretending
like I have the feature working.

How would that look like?

I have No, no, I.

Think about like where does the data go?

What kind of data models do I need?

But how does that reflect in ui?

Is the video, for example, on my device?

And if not, well that maybe
needs to be downloaded.

Maybe the designer didn't
think about that first.

Maybe they think the videos are available.

Right?

So it's about.

Asking those kind of questions and
going through the feature and trying

to find those kind of pitfalls.

Because if, let's say the designer did not
think about, like the video needs to be

downloaded first and you figured it out,
like you, you can already get the designer

started on iterating their design while
you are already working all the things.

So you may save maybe a week of work.

Cause maybe if you do it
later, You're like, oh crap,

the videos are not downloaded.

Well then now the design has to
work more late in the process and

maybe you not delay the project.

So, right.

So yeah, it's about
finding those problems.

Leo Dion (host): One thing I
wanna talk about and especially

this could be the case with video
uploading is error handling.

. Some like designers think that the app
is gonna work all the time, but with

video uploading, that's as somebody
who's uploaded tons of video, trust

me, like you, oh, the upload quit
in the middle, or you lost internet

connection or the, the video coding.

Is it right for what the
service is expecting?

I mean, there's like tons of
issues we can run into that

just happen in the real world.

How can, how can you best address
those issues, both for yourself,

but also something that the
UI designer should consider?

Tjeerd in 't Veen (guest): Yeah, so
air handling is a very deep topic.

It can go from the ones in zeros all the
way to the customer ui facing errors.

I think from a designer perspective, I.

You're more in the realm of customer
facing ui, so like errors that cannot

be handled by the app and you have
to present something to the customer

for them to take action or from them.

I think it's good to think about like what
kind of things can go wrong with errors.

A couple things.

So.

Like, you have to think about like, what
kind of errors are customers gonna see?

How can they recover?

Can they recover?

But also maybe, what about partial errors?

Let's say you have a screen
that needs to fetch four types

of data to populate the screen.

What if we go three of those
API goes go, well, one doesn't.

We can be lazy and just throw up an alert.

Okay.

But we can maybe make it more like nice
where each component has its own little.

Error message option in there.

So it's more embedded.

Yeah.

And, and that may make the
component more reusable as well.

You can maybe put it somewhere else and
handles it can maybe show errors better.

So I think it's good to think
about like how your data loads, if

it's going go gonna be one package
or piecemeal pieces and how the

customer can, or your a user can.

I think there are already good
starting points other than more,

just more than just show alert.

I think that's the easy way, . Yeah.

Leo Dion (host): Right, right, right.

Yeah.

That's a, that's a
good, that's a good way.

Like just ha having a way that the
user can actually recover from that

error or retry or whatever it is.

Yeah.

Stuff like that.

Yeah.

Yeah.

Are there ways that a UI design
possibly could be misleading and

maybe also like, Well, let's, let's
address that one first before I jump

into the next question, but yeah.

How, how could UI designs be misleading?

Cuz that's something you
talk about in the book.

Tjeerd in 't Veen (guest): Yeah.

So a lot of people also wonder
sometimes, like is the design the truth?

Like if I get designed is do
I make this pixel perfect?

I know I'm gonna be on a touch subject
here, but like if you think about like,

especially nowadays, maybe not so much.

When I started, I was, iOS 4
but nowadays you have so many

variations with screens, right?

If time, dark mode, accessibility
left to right, right to left.

Like, like when the designer
gives you a screen, That's

not really always the screen.

Like you can make it pixel
perfect in the sense of.

You know, you, you make sure
the colors are correct and

the boards all it's correct.

But the side I I, I see a screen
way more as a as a thing that

is very dynamic nowadays, right?

And, and, and designer cannot give you
12,000 variations, be like all the dynamic

phone size times, all the dark mode
times, all the themes, times, whatever.

So I think it makes sense
to, to figure out with.

I guess the, the clue, the, the
part of the story is to really work

with a designer to figure out what
is really important and figure out

what is sort of set in stone, like
certain margins and certain mm-hmm.

Colors and themes and what
things are sort of like, Open for

interpretation and for variation.

So, I dunno, XE have like a, a large
device to test on, but the next

person may have a smaller iPhone.

For example, the xe may wanna do
another round for just those devices.

Like, so I guess it comes down to
really figure out like what is really

important for them, for the company.

And not take a design as sort of the the
truth because there is no one design.

And yes, you can scale up
the designs in some tools.

You can scale up so you can see how
everything stretches, but it's still not,

for example large font size with battery
left and I don't know, custom layout.

So you're still missing some versions.

So, yeah.

More

Leo Dion (host): closely, I guess , I'm
just thinking like if you've been doing

this since iOS seven when, or iOS 4 like.

the amount of devices.

I just re I was thinking the
other day about like size classes.

Remember Size classes?

Yeah.

Yeah.

Like we don't, like now we're SwiftUI.

I, we barely talk about that.

But like that was a big deal when they
added that because like they had all

these new phone sizes and iPad Yeah.

And all that stuff.

So yeah, it's, and the
accessibility stuff you talk about.

So one of the things you mentioned
in the book that I have not, I'm not

against them but I've found them to kind
of be abused a lot in the enterprise.

And you're a big fan of is diagrams.

Do you want to talk about how
maybe diagrams, like kind of in

your opinion, fixes a lot of the
issues with misleading UI designs?

Tjeerd in 't Veen (guest): So
you mean like diagrams in terms

of the landscapes drawing out
the components needed or mm-hmm.

, yeah.

Leo Dion (host): Yeah.

You had, yeah.

You have some really good stuff in the
book too, like you're talking about, okay,

this is the data flow and this like, yeah.

I, I guess I'll just get into it.

Like, my, my problem with the diagrams
is they kind of, they, they can be

misleading to in how they might show.

How we, we know exactly
how this app is gonna work.

Yeah.

But then when you actually get into it,
it's like, oh yeah, we had this one thing.

Now we have to change this whole diagram.

Yeah.

to me sometimes, like diagrams add more
work than help, but you have some really

good stuff in the book talking about
how diagrams can actually be helpful.

So,

Tjeerd in 't Veen (guest): So first of
all, first yeah, I'm using the diagrams in

the book for, for the book itself, right?

It doesn't mean whenever I'm opening
code I op I'm drawing diagrams.

But I do think, I do think they're
definitely a design tool for teams

to align on what needs to be built.

If, if you sort of, let's say
you have a team, of five iOS

developers or whatever developers,
they, they have to make something.

you can talk about what you need, but
you can also draw it on and diagram

could just be even a, a little post
note with a little a pencil sketch.

Mm-hmm.

just to get people online.

So because there's a lot of risk
of miscommunication, I think,

when you work with people.

Like everyone thinks they know what
they know, but actually they don't.

Yeah.

And, and they may and, and that.

And it's good to know what people
are working on, what diagrams

don't really capture the details.

I think this may be the, the problem
because I can draw in a diagram.

I can let's go back to the video
uploads just for consistency.

Let's, I can draw like, like a data
chunker and like a background upload

and I can draw it in the diagram.

Mm-hmm.

. But it's, The program, there's
a lot of details missing, right?

But I can at least align with someone,
like what are they gonna work on?

What am I gonna work on?

Right?

Right.

But how to do it is sort of yeah.

Fair platform specific, which is
kind of like how I see it at least

is there's room for interpretation.

How we may agree, someone makes a
video uploader and someone makes

the ui, but how you do it is maybe
outside of diamond, a diagram scope.

Leo Dion (host): Yeah.

Yeah.

Yeah.

So, I mean, it sounds to me like you
think the big plus with diagrams,

and I totally agree, is probably like
communication across like when you have

more than like maybe like three people.

I think a diagram, and like you
said, it could be a post-it note

and it is also, it sounds to me
like the diagram is Temporary, I

guess would be a good way to put it.

It's not, it's not
something right in stone.

And then it's like, okay, it goes into
the documentation and it's forever

there where Yeah, it's not in stone.

Sometimes it can

Tjeerd in 't Veen (guest): be.

So, so I've been in projects where
we had like tech, tech documentation

where you actually there was like a, a
complicated flow and this diagram was

really like great because it was sort
of the communication tool to decide

when data is loaded and uploaded.

Oh, yeah, yeah.

Yeah.

So it sort of was like a source of
truth in communication, but depends.

A company.

Leo Dion (host): Yeah.

Yeah.

Yeah.

And that I think makes a total
total sense when you have a big

team and not, you know, just, just
in case you're ever wondering,

nobody stays at a company forever.

So if you're gonna pass that information
down, like it's a good opportunity there.

Tjeerd in 't Veen (guest):
Yeah, of course.

The hard part of the
documentation is keeping it in.

Right.

Yeah,

Leo Dion (host): yeah, yeah.

With a lot of larger companies, what
are like some of the best ways that

mobile, web, whatever, honestly, can
align, especially with the backend

team and making sure that they get
what they need, but also like the,

the front end teams understand like,
what, why mobile is doing things the

way they do, if that makes sense.

Tjeerd in 't Veen (guest): Yeah.

So may maybe is good like talking
to like an in terms of example

Leo Dion (host): as, for example,
on video uploader, let's do video.

Yeah, let's take the video.

Uploader.

.
Tjeerd in 't Veen (guest):
That's a great iactually.

It's a great point.

So video uploading, let's say you wanna do
like a background uploading thing, right?

Cause you have to video.

That means you need some sort of
way to, to chunk of data, right?

And, and upload it.

So yeah.

So when working with backend, I
think there's a couple things I.

One thing you wanna focus on,
I would say is getting to the

integration as fast as possible.

Because I think with integration,
I mean making actual API calls.

And I know that's kind of like
the whole world of mobile,

like how to make API call.

But I do think sometimes people focus
too much on like the UI where they

get a design, for example, again, the
video uploader and they make it all

like nice with the shadows and then.

integrating it, and then they
realize, oh wait I have completeness

alignment here with the backend

Leo Dion (host): developer.

So I got this really cool swift UI
animation, but it's totally useless

because our backend doesn't support it.

Yeah, yeah, yeah.

Tjeerd in 't Veen (guest): Whatever.

So the, so one thing I, I.

Try to steer it towards and also
do the, in the book is to get the

integration as quickly as possible.

So when, when you do this, when
you make an actual API call, you

learn a lot and the backend doesn't
have to be ready, by the way.

They can just have like a mock response.

But you learn

Leo Dion (host): like, By the way,
I wanna, I wanna just say it like, I

like what you did in the book where
you had like the fake, the fake api.

And I was like, why is
he using threat sleep?

Like, why?

And then it's like, oh yeah, I see
what you're doing, because you wanna

like mock up the, the, the backend
call in your, in your, your app.

So yeah.

Sorry, I just wanted to mention that.

That's like a really good that's a really
good way to like, Get some velocity on

your mobile dev without necessarily, yeah,
depending on your backend, assuming that

you, you stay in sync with your backend.

Sorry, I just wanted to say
Yeah, that that was really cool.

Tjeerd in 't Veen (guest): Totally.

So, yeah, so what I want steer
towards to usually is to get a

the, the complete end-to-end sort
of call ready as soon as possible.

So like if you have data and it
needs to be uploaded common scenario,

but don't wait till UI is done.

Like do the way earlier because you're
gonna learn that you, for example

maybe the backend assess is ready.

But your laptop cannot connect to staging
and like, oh, oh wait, I need, I forgot.

You have to give you a token.

Oh wait, now you need some special rice.

You have to request and now you're weak.

Further depending on your company.

Yeah.

Right.

Or maybe, or maybe you need to get some
tokens from this third party SDK you

use and you're like, oh wait, I have to
actually get more budget now cause I'm a

new employee and I need the budget for it.

So whatever it is, like you, there,
there are these things you don't

know what's gonna happen when you
postpone the actual integration.

So I think by.

By moving them more forwards
in your development process.

And I know maybe it's not as
exciting as you are for some people.

You're gonna learn a lot quicker
what problems already there.

And what's nice about that is you can
sort of like quote unquote activate your

team members to, to fix these issues while
you're doing the rest of, as opposed to.

Getting everything ready and then you're
making your sorry, make a backup call and

then realizing it's actually not working
and then needing to add a couple more

weeks of time to get everything ready.

So that's one thing I would really
recommend is to do to, to talk to,

to integrate as soon as possible.

But regarding alignments, yeah, that to me
just comes down to regular communications.

Hard to give you p made
answer for the situation.

But like in case of video uploading,
you know, you have to think.

Like what could go wrong?

Like how would, what
performance do you expect?

Like how often like can
we hammer the server?

Like how, like uh, do we need to take
some measures or even loading data?

Like, like is there a, a problem
if you start loading a lot of

data from the back and like, do
we need to do some local storage?

Something you may wanna consider, right?

Yeah.

Common one is I have a screen
and I need four types of data.

Can you talk to the backender to
just give it in as one API call?

That's always gonna be in nice discussion.

I feel like it can be worth it.

For example, if you have more traditional
rest api, you can say, you know, can you

give me the data in one format, which
may me be more work for a backender

and they may not want to do it.

They can just say, make four API calls.

But if the Android developer also has
to do it, and now the web developer

also has to do it, it's actually
a lot of work for all of them.

So they can have those
conversations as well.

Like, how can you
consolidate certain data?

So that is more consumable from mobile.

So those are, I think,
discussions you can have.

Leo Dion (host): One thing I think
is really helpful is demos weekly

demos of like each team, like, okay,
let's see how the Android app works.

And then like the iOS folks are
like, oh, interesting you did this.

And the backend folks are like,
Let's not do that with the api.

If you upload like that, yeah,
it's gonna hammer our servers.

Like you need to do some and you know,
and I think that's really, like if we

talk about meetings, like meetings can
be awful, but like a good demo every

week just to show off a feature that
everybody is working on in parallel.

Yeah.

I think is gonna be super helpful.

Making sure everybody's on the same.

Tjeerd in 't Veen (guest): Yeah,
and or even internal bills.

I love internal bills because
it gets people excited.

I think people see, actually see their
work actually working in their own hands.

I think it's also an amazing tool

Leo Dion (host): on top of them.

Right, right.

Yeah.

So one, one term you used throughout
the book is holistic driven development.

What?

Yeah.

What does that mean exactly?

I made it up . We just, we need one more.

We need one more driven development.

we need more

Tjeerd in 't Veen (guest): ATDDs, TDDs.

I know it's so, I'm trying to, you

Leo Dion (host): should sell,
you should make a whole business

of selling certifications for
that, along with your book.

Yeah, yeah,

Tjeerd in 't Veen (guest):
yeah, that's true.

So well the thing is,
it's not really one thing.

So that's why I tried
to give it a new name.

But with what I call holistic driven
development is a way to start from

scratch so someone gives you a
feature requirement, and to have

something working really quickly.

On not only to just throw away in as
experiment, as an experiment, but also

to have it working for the long term.

So you think about the domains
that you need like which

types, which classes you need.

You think about API design, you think
about binary the, the boundaries

of APIs, and then with that, I
mean the APIs of your own types

but to make it more concrete Let's
talk about the video uploader.

It's, it's about sort of top down
design method, which is not a

new thing, but what what I really
propose is you work your way down.

So you start at the
top at sort API design.

How, how you would use
this video uploader.

So let's say I'm in let's, you have a
teammates that also does does the UI

part and you do the uploading part.

Your teammate would.

Only be interested in the
API of the video uploader.

It doesn't care if it
uses offline storage.

It doesn't care if it uses background
uploading like the, the, the, the UI

part only needs to know like, Hey, I'm
picking a video, I'm sending this video

to you and you handle the uploading.

So these kind of barriers
become really important.

So the holistic driven design,
what I try to share there is

you start this sort of top.

Driven development where you think about
what's most important from the API side,

but then internally it's our placeholders
because it doesn't matter to the call side

whether or not things are working right.

This can really speed up the,
the process for everyone.

But as soon as the, but as long as you
properly design the API boundaries of

these types, then what happens on the
water yeah, can just be updated over time

to like review implementation later on.

So this.

Yeah, it's so, so I guess what, what
you, what that means is like over time

you'll go deep and deep and deep in
your code base to actually hit the real

network calls and the real data storages.

But those problems will become
so trivial at that point.

All you have to do is quote unquote
just make a URL session call and make

a background task and you're done.

But cause you've thought of everything
else already and you've thought

of all the bits and pieces and how
everything is calling each other,

you can defer the complicated parts.

Maybe a long answer, but Yeah.

Leo Dion (host): Yeah.

It's kinda relative.

It's funny you're talking about the
complicated parts and, and breaking

things down because we were, we were
talking before the show about your

neighbor and our, like one of our 500
Dutch guests that we've had on the show.

And Donnie your neighbor had a tweet
about abstractions and, and how

abstractions can sometimes be unhelpful.

And you, you had some
interesting thoughts about like,

over-engineering and abstractions.

Yeah.

And, and, and like when they're
helpful, when they're not, you want

to kind of break that down as well?

Tjeerd in 't Veen (guest): Yeah.

Yeah.

So I dunno if I could do it in
a few minutes, but for sure.

So I've been involved with tons and
tons of teams who have made tons of

abstractions or lack of abstractions and
me included, where I've seen everything go

wrong and everything go right basically.

So I have a lot of I try
to distill a, a lot of.

Like best practices that you can
think of when you make your own code?

Like, should this be an
abstraction, like very common?

Like let's say you have another
team that has like a component.

You wanna use it, but it, it's slightly
different than what you really need.

Like, what are you gonna do?

Why are you gonna make an ex an
abstraction and take something out

for what you need and then offer like
a thing that you can build on top?

Or are you going to duplicate it
because it's too different and it's

going to be too different or you
know, I see people post these tweets

like if it's used three times then
it needs to be made reusable, but not

before, but like, that's kind of true.

But I think strike is such
a deep topic, like mm-hmm.

for example.

Just because, you know, just cause code
is reusable doesn't mean it's generic.

Vice versa.

Oh,

Leo Dion (host): interesting.

I like that.

Tjeerd in 't Veen (guest): Yeah.

Yeah.

And, and also sometimes it can
be a good thing to actually start

with the generic component, even
though everyone says not to.

Because like I give an example in
the book, like I make a little store.

And the store is generic.

It stores just, just generic things.

Like it stores data that in an
offline store, in an offline way.

Mm-hmm.

But it's generic right away.

It's not like used three times and
then it's extracted into its own thing.

It's already reusable
component, which isn't re reuse.

Yeah.

But then is Yeah.

But then is an over engineering.

And I go about I go
over that actually, and.

Depending on where you are in the
abstraction layer and where this

component lives, you can also decide
if it should be generic, if it should

be serving other features, and if so,
should it know about this other feature?

Right.

Why or why not?

So, so those are topics
I'd like to uh, touch upon.

Cause I think a lot of
stuff goes wrong there.

Yeah.

Leo Dion (host): Yeah.

What, what do you think is like the
biggest mistake one can have when they're

like abstracting an API in such a way?

Tjeerd in 't Veen (guest): I think.

Well, maybe not the biggest, maybe the
most common one is people con conflating

the type name with the instance name.

So I'm gonna give a classic
example and then maybe I'm

gonna maybe be a bigger example.

Leo Dion (host): Will it
involve a video uploader?

That's the important thing.

Yeah.

Tjeerd in 't Veen (guest): Oh yeah.

Has to . Exactly.

So let's say I have an image
description and I'm using it

for the video uploading, right?

Mm-hmm.

to show you what the image is about.

Yep.

People may call this type, they
make a component and they call

it video image description.

I have no better name right now.

But I think that's, that's actually
already the, the problem that I see

because that is how you would use it.

Because how you use the thing
is for your video image.

So there will be the instance name,
video description, for example.

Mm-hmm.

. There will be the instant, what
people call it, the type video

description or video image description.

And the problem with that is that
if you think about what the type

is, so it's nothing more than
an image with the description.

It has nothing to do with
videos at all, right?

Leo Dion (host): It
doesn't have to, right?

Tjeerd in 't Veen (guest): No.

No.

So what happens now is someone else
also needs an image and description for

an avatar, for like a person profile.

Can they use the video image
description or They could, but the

name doesn't make sense, right?

It has video in it, so something
went wrong, but it is the same thing.

Maybe the dimensions should
be configurable, whatever,

but like it's the same thing.

So, What I think goes wrong there
is that people give the name

of how it's used to the type.

Okay.

But it should be only
given to the instance.

But this is like a very maybe basic
example, but it goes really far.

Like you may have let's say you have
this payment flow and yeah, it uses

Screens that are backend driven.

So like, let's say the backend decides
which screens are used to render the, the

payment to render the payment flow, right?

This may be called like
payment flow backend I dunno,

call it backend ui, p b ui.

And then, and now, now everyone
is using this P B I system.

But guess what the, the whole flow doesn't
need to know about payments at all.

It's, it's about right, it's
about a backend UI driven thing.

It's used for payments.

So people call it payments ui back on
UI flow, but it's actually it's actually

standalone backend UI flow on its own.

So these naming things, they,
I see them go wrong a lot.

Because if you would call it backend
UI only now I can use it for anything.

And it's still just as reusable and,
and generic as before, but it's the

same thing, but the name is just better.

Right, right.

It doesn't sort of hint
at how you should use it.

I think thinking and more like an instance
name, so the instance name could be a

payment UI flow, but the type could.

Second UI flow or something.

Mm-hmm.

. Mm-hmm.

. That is really, that's gonna
solve I think, a lot of

problems already people have.

Yeah.

Cause now you can reuse it.

Now the name is more clear.

You know, you know, kind of where
it fits in the abstraction layer.

It's like, it's not really a feature
specific, it's more like a, a

tool to help features and so on.

Leo Dion (host): So let's talk a
little bit about everybody's fun.

Like favorite topic architecture patterns.

Yeah.

How.

How do the ar, how do
architecture patterns fit in

with the design of your app?

Like at what point should you be like,
okay, I need to use this pattern or

that pattern with, as you develop
the app or as you design the app.

Tjeerd in 't Veen (guest): Yeah.

So this is quite a, a
minefield of a topic.

I'm gonna step into it anyway.

, I think yeah, yeah, yeah.

So when mobile developers talk about
patterns and architectures, they usually

only mean UI architecture like, you
know, fiber perfume models you know,

post architecture, whatever, MVP and,
and you know, reactive, whatever.

But it's usually UI based and.

The problems are common.

Common problems are related
to binding data to ui.

Mm-hmm.

If I want to sort of maybe simplify it

Leo Dion (host): too much.

No, totally, totally.

Tjeerd in 't Veen (guest): But the
way I, sorry, what was your question?

Exactly?

Like how does it

Leo Dion (host): fit in the development?

Yeah.

When you're designing the app, like
how, how can you look at that UI

design or maybe the diagrams that
you've built and be like, okay.

Like this is the architecture pattern
we're gonna be using for developing that.

Yeah.

Tjeerd in 't Veen (guest): Yeah.

So well I made have a strange opinion, but
I feel like it usually doesn't matter in

my experience, it's more about preferences
from what I've seen cause I, I've seen

people make great apps from, with many
parents, but I feel like there are like

some, some guides there you can say.

If your app has a lot of like life
updating data, then maybe you're

more partial to using a reactive
pattern because it's hard, hard to

keep everything constantly updated.

But but, but I would say what I'm
usually leaning towards to is, Try

to keep things as simple as possible.

And that's easy to say.

But I feel like sometimes panels
can be too much of a crutch.

Like if someone says, I need like
a five acronym to make this app,

then I'm kinda getting nervous,

Leo Dion (host): like, hold on.

Like,

Tjeerd in 't Veen (guest): Like, like why?

Like, like some, to be
honest, sometimes screens are.

It can be simple, right?

We've had some data and you,
you render it like, right?

There's million of
tutorials on that already.

So why do we need like a, a six
letter acronym or something, or

five letter acronym to solve this?

But I think the view issues is,
are more related to different

issues that people face.

And I, I think pattern may help sort
of get people used to how to make an.

So there's sort of like a crutch,
like you like, oh, I'm used to

using MV mvpm, I'm used to using
street with architecture, whatever.

Like I'm gonna use that.

I'm gonna solve, it's gonna solve a
lot problem for that person, but I

feel like over in two years there's
gonna be next pattern and there's

gonna be next one after five years.

So, yep.

That's what hint as well.

Sorry.

No,

Leo Dion (host): I think
you're, you hit it on the notes.

I think it's helpful for teams like
larger teams where they need to agree on

like, okay, we need to add a new screen.

Okay, this is how we add a new
screen for this larger app.

I think that that's helpful.

I think.

Yeah.

Yeah, I mean, I, I agree with you.

I think it can be too much of a
crutch because like you said, you

a, they change a lot, which we'll
get into third party libraries.

It's the same situation and it's
sometimes over, like, it's sometimes

a bit of an over-engineering
of how something worked to me.

Like patterns come out of how you've
designed the app, not, it's not something

you go, okay, this is what we're gonna
do and we're gonna move forward with it.

Yeah, and then like there
are definitely anti patterns.

There are definitely, I think it's,
like I said, based on your team.

It's also based on the
underlining platform.

Like, like in Swift ui.

Like you never wanna do nbc.

Sorry.

You just, you don't,
yeah, like don't do nbc.

Like that's obvious.

But like there are.

Multiple patterns you could use.

So there are ways you can use
combinations of different patterns.

And I think like that's where, that's
where like how, you know, in my opinion,

architectural patterns fit in really.

Yeah, I do, I

Tjeerd in 't Veen (guest): do agree too.

It's a good alignment too.

In, in larger companies it is nice
to have like a sort of alignment.

Okay.

Like these are sort of the
payments we, we will use.

Yep.

because large company people
say, can I use combined?

Can I use RFI or mm-hmm.

or whatever.

Like they, they will ask and it doesn't
make sense to just make and match.

Cause everyone has different preferences.

I would say try to pick the parents
that work for your company, right?

If you have, if you just have a bunch
of table views, you know, why, why go

all overboard with all fancy stuff?

Just, just make a little small view model.

But maybe you have a live updating
chat service and maybe reactive copies.

Makes a lot of.

Leo Dion (host): You know, but Right.

Exactly.

What

Tjeerd in 't Veen (guest): makes
it all up, I would say try not

Leo Dion (host): to.

So let's talk also about like libraries
and like trends in development cuz that

kind of piggys back off of that, where
it's like sometimes using third party

libraries can be a crutch as well.

Sometimes it could be helpful
to get something done quick.

Yeah.

Like where do you fall on
that spectrum, I guess.

Tjeerd in 't Veen (guest): So early
in my career I was really like

excited about third party libraries.

Like, especially for did like
Ruby development and I could

just get, grab a couple gems and
it's working and I'm good to go.

But now I'm a bit more apprehensive
because well, the problem I find

is there's another couple problems.

I feel like the third party library
should really solve a major issue for you.

Cause if, if you just very easily add
a part, a third party library to your

application, then well, you list that
the main, the maintenance is slow,

so you have to do some due diligence.

There's maybe a legal department in
your app team that also has to approve.

There may be issues with, like,
I remember having had issues with

Swift releases then that impacted
some of their party libraries and

they were just one week too slow.

So now you were actually
depending on them to do the work.

People you don't know.

And it's kind of, I feel
like a problem, but.

There are safe bets for sure.

And for example, if I'm gonna wanna
do image catching on you like it, I'm

not gonna reinvent the view, I'm just
gonna grab kingfish or something.

Right, right, right.

Like basement time.

So some I would say be like treat,
like I say, treat like cinnamon

like a little bit here and there
is good, but not, not too much.

Yeah.

Don't wanna eat

Leo Dion (host): spare.

That's kinda my sense.

Yeah.

Yeah.

I think like, to me, like a good, a good
indication is an open source like, For

some reason people aren't like, you gotta
think like, if people aren't, aren't

maintaining it, then at least could you
take that for kit and put it in and use it

yourself and do whatever you need to do.

Yeah.

Because that's always an option.

Tjeerd in 't Veen (guest):
Well use investments.

You have to keep that in mind.

Yeah.

Leo Dion (host): Yeah.

So like, you know, is it worth building it
yourself or is it worth using the library

and then maintaining yourself if need be.

Like, yeah.

And like, is it, is it
used, is it updated?

You don't want to, I've seen
libraries that are still on Swift

four, swift three, and I'm just like,
yeah, okay, this is, this is dead.

Like and just, yeah, keeping that in.

Tjeerd in 't Veen (guest): Yeah, sometimes
teams are really, I mean, I, I think it's

wonderful that people work for and, and
you know, use their free time to build

something for people that they can use.

But I, I think we just have to be careful
to to make sure that yeah, things are not

slowing down your company, your business,
what that's then that's gonna be painful.

That time gain you get is gonna
be lost when teams are just

slow to update their stuff.

Yeah.

Yep.

If a helping hand, if you can
contribute stuff like that,

you gotta keep it all night.

Yep.

Leo Dion (host): Yeah.

Let's, so I wanna talk about, we'll
talk about testing first and then

I'll get into interviews last.

So one of my fields,

Yeah.

So you had some, you have.

Some interesting things you wanted to talk
about when it comes to testing and yeah.

That you wanted to talk about.

So, cuz I mean, I think
testing is super important.

I think.

Yeah, like code coverage is a nice
indication, but not the be all, end all.

No, but to me, like testing also
is a good way to have a healthy

architecture in the end as well.

What, what, what's your take on testing
when it comes to systems design?

Yeah.

So I feel like

Tjeerd in 't Veen (guest): it's good
to know kind of the, the things you're

really trying to solve in a mobile app.

I think a lot of people, they they make
something new and they write a test

for it, and they merge and then you
know, and then if there's something

in, during the release cutoff and
you like, make a release bill for

internal checks before you submit it.

I think that's where the real testing
happens sometimes where you make so

let's take about the process, right?

Like you have the main.

You're gonna make a release.

You cut off the branch,
you make a release branch.

And then maybe, let's say in a company
like a week long where people check

the co, they translate the copy, they
check the, the manual test, all stuff.

It's your the write
test or your unit test.

But the real issues usually come out there
because the hard part about mobile, what

I find is the whole release part process.

We can't just quickly roll back a release.

We just have to push forward and Right.

We can use feature flags and, and
stage rollout to sort of remedy

the shortcomings, but, Once the
crappy broken bill is out, you're,

Leo Dion (host): you have to be quick

Yeah, yeah, yeah, yeah.

Tjeerd in 't Veen (guest): So, so what
I wanna focus on is how can you get

more guarantees before you merge and
not just for your own piece of code.

And I think.

What I see a lot, which is also what I
used to do, is like I make a new class.

I have to test it.

So I, and interface, like a protocol
and now I can test it and now it's

swapable and looks green, it's great.

And the CI says everything's green.

I merge it and then it goes on the
release train and then we see like, oh,

it's actually not working as well as
we hoped, and it's already too late.

Mm-hmm.

. So what I wanna focus on what I've, what
I've seen a couple lot the results with.

Testing with more actual code,
which is, which goes against

the entire concept of units.

So a lot of people don't like it.

I know they don't, but it actually
does work well, if you can let's

say I have like a complete stack.

Let's take the video uploader and I
have like sort of data chunking logic,

and I have like uploading logic and
have like an API calls and I have like

the video uploader component itself.

Some people may say, you know what,
I'm gonna take the video uploader and

I'm gonna mark everything up below.

Cause now not cause that's the
only thing I need to really test.

It's the most important thing, and
my test will run quickly and so on.

What I would say is well test everything.

Test the video.

Uploader make, could
use all the real types.

Mm-hmm.

only, only mark out the tiniest part.

API call itself, not complete
API domain, only the tiny

function that makes the call.

And now when you test the uploader
component, you indirectly test everything.

So it's.

It's kind of like integration
tests almost, but without view API

calls, it's kind of like you can
make all the component testing.

Okay.

But I, but I wanna take it a bit further
and say you wanna test as much as your

code as possible, and that gives you
a lot more guarantees and how Yeah.

And how your code is actually used.

Okay.

Leo Dion (host): So is it different
from like, because it sounds like you

mock the api, the backend, but then you.

but you're not testing the individual
pieces, you're testing a whole

set of pieces as they integrate.

Yeah.

So except for the back, I guess.

Tjeerd in 't Veen (guest): Yeah.

But let's say also I'd like foul storage.

I would probably, in some
cases also test foul storage.

A lot of people would say, don't do that
because it's like global immutable state.

Mm-hmm.

. But well, I actually did work on a
few upload and I called issues by

actually testing the file storage.

Now the problem is it's slow,
it's io things go wrong.

But I'd rather know that during my unit
test phase than merging it, having Gotcha.

On my test screen and then go to the
release and then like, oh wait, it's

actually not working on Mac or something.

Yeah,

Leo Dion (host): yeah.

Yeah.

Oh, interesting.

Yeah, cuz I've, I've run into that before.

That's a really good, good point
where I've had like downloaded large

files or uploaded large files and
like yeah, if you can test that

out, would that be a good case?

Like in, in iOS world, would that be a
good case for like doing a UI test maybe?

Or would you still do it as a test case?

So,

Tjeerd in 't Veen (guest): so
I think rights are amazing.

And a lot of people
actually don't like 'em.

I like 'em a lot because if I
give a manual tester my new.

They will go, they'll grab, I know,
four phones and they'll test it for me.

Right.

And but they can only test so much.

They will not test that.

If I have like dark mode and a large
font size and right to left iPhone

five only, then there's a major bug.

Yeah.

But like it's hard to find, not saying
you right as will also find those, but

but like I said, I minimize my screen.

Like a background, the app at
one of the 60 screens and on one

of those screens, the app crash.

Like I've had that happen.

Manual testing is, is not really
gonna find that as quickly and I

find U are amazing that you can
really scale up all these variants.

You can do.

Like, let me just take 12 devices and all
these variants and, and just go ahead.

But people don't like
them for good reasons.

They don't like 'em cause they're slow.

They're slow to write.

They're slow to run.

Yep.

They, they, they're
brittle, they're flaky.

And I get all that.

Yep.

But I do do see a lot of value that
even running them like nightly.

And getting some reports can already be
like like a little bird in the coal mine.

Like it gives you already some warning,
like careful, like, like one week

before the release cutoff comes.

Yeah.

You already can get some problems.

Not even though maybe some tests are
flaky in the red, but maybe they're fine.

Yeah.

It tells you something, right?

I, I see a lot of
failure in that actually.

Leo Dion (host): Yeah.

Well, before we, sorry, I wanna, let's,
let's ask one more question about Sure.

So your book is actually pretty, like,
it's not focused on, I, like, obviously

your expertise is in iOS and Swift, but
it's not really focused just on that.

There's sample code mostly in Swift, but
you're, A lot of this could be applied to.

Web developers, Android
developers, et cetera.

Is there anything in particular iOS
and Swift folks can take advantage

of when building, building an app
in particular to their platforms?

Or

Tjeerd in 't Veen (guest):
in In regards to

Leo Dion (host): system design.

Yeah.

Yeah.

Is there something like you're like,
here's an example in Swift or an Xcode

or iOS development where it's like, you
definitely, this is one mistake I see

folks do when it comes to systems design
for iOS or Mac Os, or, I see whatever.

Tjeerd in 't Veen (guest): Yeah, exactly.

I think system design itself is more
it's not so much focus on the details,

it's more like language agnostic and
and like, yeah, like you said, like

the book is not specific for iOS.

But once you go into the details,
it does matter which language

and which platform you're using.

So I don't think there's
like one specific.

Problem that I developers do,
that energy developers don't.

I think it's more about the
constraints and limitations we have.

So how

Leo Dion (host): would you, like,
is there something about Xcode that

can maybe help you like be more
consistent with your design, I guess.

Tjeerd in 't Veen (guest): Yeah.

So I do think largescale iOS apps
are it's maybe not every company,

but it's not really something that
Xcode is really fantastic at yet.

Mm-hmm.

, like, I, I've file packages for years now.

Like, yeah, like I remember
when Swift came out, you can

only have six swift packages.

There was the.

The limitation.

Oh, you serious?

Oh my gosh.

Yeah, yeah.

Something like that.

So, cause the, it was all like you three
something, it was early, early days.

I didn't get that.

Yeah.

So I do find in iOS you're more
limited to having fewer packages, or

at least how it used to be, whereas
the could just have like 80 no problem.

Right, right.

So that, so that, those impact, like
how you think about like maybe larger

modules versus like lots of tiny
little interface modules everywhere.

Yeah.

So I do think that matters.

Leo Dion (host): One thing I've
I've started doing is breaking down.

So I, I, I don't know.

I'll call it's package driven
development because I, I want

the, I wanna make the Yeah.

That, trademark that so I can cash it one.

Yeah.

So one thing is like my, most of my
apps are all stored in swift packages.

There tends to be very little code
in the actual app, and I've started

breaking down my Swift package targets.

As much as I can both for faster
development, because obviously

you got parallelism going on,
but also just easier maintenance.

Like, okay, this is the
part that does networking.

This is the part and
it's a separate target.

Yeah.

And, and that I found a
bit like very helpful.

We can get into modularization.

That's a whole other episode, but I
think that's a big, big big thing.

And I, I don't, I can't speak for my, my
friends who do Kotlin or, or type script

or whatever, but like, When it comes to
Swift, like taking advantage of making

packages as as tight as possible and as
small into as small as possible, and then

making those dependencies much easier
to maintain I think is super helpful.

Easier.

Yeah.

Yeah.

Yeah,

Tjeerd in 't Veen (guest): absolutely.

I, I think it's not like a unique swift
io thing, but it's definitely helped

that Swift is so much easier now to
set up package environment for sure.

Right.

There may still be some issues with
object to c mixing and like other

problems people are having, but
like when it works, it works really.

Leo Dion (host): Right, right.

Yeah.

And I think like that's a, that's a
big thing, I think is just breaking

your things down as much as possible.

When we had aviel on, we talked
about like, don't, don't just

have one giant environment object.

Break it down, like and yeah, breaking
things down into smaller pieces is both

helpful for maintenance and helpful
for building and helpful for testing.

I mean, there's just so
much, so much you can get.

I definitely agree and,

Tjeerd in 't Veen (guest):
and, and creates these hard

boundaries between domains.

If you.

Grab the right domain, right?

It's, it's really powerful that
someone isn't accidentally inputting

UI in a, in sort of a data part,
you know, that can happen with, and

you don't have these boundaries.

So it's really great.

Yeah.

Leo Dion (host): Yeah.

So before we close out, I wanted to
talk about interviewing and interviews.

That's something you talk about a
little bit in the beginning of the book.

I know there's a lot of people who
are interested in interviews and

getting the right job nowadays.

So yeah, and you talk about
that a bit, especially in the

context of systems design.

Do you think, do you think
the process is broken?

Do you, what do you think as
developers who are interviewing,

we should be doing better?

Yeah.

When we are interviewed and
also interviewing, I guess.

Tjeerd in 't Veen (guest): Yeah, so,
so it's kind of interesting cause it's

sort of like a new thing where there are
already assisting design interviews for

backend and now more and more for mobile.

Mm-hmm.

, but it's not really sure
what you're gonna get.

So I've heard and seen interviews where
you get a, a, your UI screen and they're

saying like, Hey, how would you make this?

And you would write a pseudo code, right?

Mm-hmm.

Like, like a shared text editor and
you write some view controllers, but

it doesn't have to compile anything.

They would say like, oh, would you
use a table view or a collection view?

Like what if there's
lots of data in CB store?

Mm-hmm.

, how would that work?

But I've also seen interviews and also
been part of interviews where people

just just give you like a prompt.

They, they just say like,
Hey, make me this thing.

Like, click video, upload
it, , how would that work?

And, and they just give you nothing else.

And you have to ask questions,
figure out what they need, figure

out what the requirements think,
think about the limitations.

And they're really looking for
these signals that you come up with.

All the edge case, all the problems,
all the components that are needed.

What I find hard is to say, you
know, study these five things and

now you're ready for interviews
because first of all, you don't

know what you're gonna get a second.

The interviews all over.

All, all over the place.

Yeah.

So, so there are guys, like they
say, like, you know, learn about,

you know key chain versus core data
versus property list, you know, and,

and, and I think that's good to.

But it will not guarantee
you a good interview result.

What I think is really important,
which is also why I'm writing about

it, it's more like to be able to
come up with a solution for something

you've never done before, but.

That's one thing you can expect.

You're gonna have to make something

Leo Dion (host): you've
never made before, right?

Like, like,

Tjeerd in 't Veen (guest): yeah,
like if someone asks me like, Hey,

make an ar image video filter thing.

I've never made that before, but
like, how would I approach it?

Come up with, you know, components
and domains and like limitations.

Maybe mobile limitations
maybe processor capacity.

I dunno.

Those are kind the things
that interviewers wanna hear.

They want see you think about all
the important parts that are needed

and So, yeah, I guess one, one big
takeaway would be you cannot really

prepare for one interview, but you
can train yourself to to ask the right

questions back, to get like a better
idea of what's being asked of you.

You can use some tactics to
like design your application

without knowing the details.

And that's exactly what I've
been trying to help people with.

.
Leo Dion (host): So do you think it's
something that's easy to study for

or is it much suited for a mobile
developer with a current position

to build experience so that way they
can, because it seems like it's an

experiential thing more than a studying
thing to be a mobile systems designer.

You know what I mean?

I

Tjeerd in 't Veen (guest): think.

Yeah.

So I do think it's an
it's an awareness thing.

So if I give maybe someone just
starting out like a feature, they

may go straight to ui, for example.

And if I give like a staff engineer
feature, they may ask me if it should

support all the teams in the company.

I don't know.

Completely different angle, right?

And I do, I, I do think you can
you can study and prepare for.

Like asking kind of
what's required of you.

Mm-hmm.

, I think that gives that,
that goes a long way.

Yeah.

So if, if, if, if you know what to
ask for, like know, like, hey, they're

giving me half the information.

I need the full picture.

That's already a great step.

Yeah.

If you just start programming, I
think that's more of a problem.

So I think you can.

Train it to

Leo Dion (host): some extent, I think,
yeah, I think it's totally healthy

to have like a two-way conversation
when you're getting interviewed

on a complex question like that.

I think sometimes people who
are interviewed get a little

bit intimidated, like they think
they're supposed to know the answer.

Like it's just, here's the
question, here's the answer.

But yeah, I think sometimes when they
interesting, like, and as somebody

who's it done, the interviews
like I think it's important to

realize sometimes those open-end.

Questions are there because they
want to have a conversation with you.

They want to know that you're
asking the right questions.

Yeah.

And like, like it's just to get a
good feel of someone being, like,

having a little bit more confidence.

And instead of being like, okay,
I, I'm gonna go make the best video

uploader, it's like, no, slow down.

Like, The right questions.

It's not, it's not a
right and wrong answer.

It's much more of a yeah.

Of like, we're trying to get a good
feel of this person to see if he's gonna

work with us or she's gonna work with us
and she knows and has that experience.

Yep.

Yeah.

So.

Tjeerd in 't Veen (guest):
And, and they may test your

communication skills and Exactly.

Test your iOS knowledge.

You, you don't know,
but like, it's good to,

Leo Dion (host): It's not a binary,
there's no right answer, especially, no.

There, there is no right
answer to a video uploader.

Sorry about that.

If that's what you're looking for.

I think, I think we, we've
talked about everything except

the most important thing.

when is this book gonna come
out and how can I get it?

Well

Tjeerd in 't Veen (guest): I'll give
it one to you, , but it's coming out,

but it's coming out in 2023 somewhere.

Okay.

I'm definitely there.

So but I can't exactly give a
date yet, but I'll make very

few orders once they have the

Leo Dion (host): book is done.

Okay.

Do you have like a mailing
list folks can sign up for?

Tjeerd in 't Veen (guest):
Yeah, I do have one.

I can send you the link.

Leo Dion (host): Yep.

Yep.

And we'll put that in the show notes.

So, yeah, definitely.

Oh, This, this is awesome.

I'm so glad somebody's coming out with
this book because it needs to be done.

There's way, there's way too many
books about how to make Swift UI do,

do a shiny animation and we need more.

More.

Everything has its place.

, everything has its place.

That's true.

That's true.

Yeah.

But if you have a, will run a large team
or you have a large enterprise app and or

your mobile developer and you're looking
to take it, take it to the next level.

I highly, highly recommend
checking this out.

The link to the mailing list will
be in the show notes, so you can

check that out and get get an
update when that book is ready.

I've looked at it.

There's a lot of good, solid stuff in it.

Cheer.

Thank you so much for coming on.

This has been fantastic.

Thank you so much.

Tjeerd in 't Veen (guest):
I really appreci.

Yeah, it's fun.

Yeah.

Leo Dion (host): Where can
people find you online?

Tjeerd in 't Veen (guest): It's
probably better to spell but che in

Spain, t j e e r d i n t v e e n.

And yeah, I guess that's the best way to

Leo Dion (host): go.

Just find me on Twitter and we'll
have the links to, yeah, Twitter,

LinkedIn, as on all that fun stuff.

In our show notes.

People can find me on
Twitter at Leo g Dion.

My company.

Digit.

I'm on ma, I gotta say Ma,
on now I'm on massed on two.

At Leo G Dion, at cio,
IM and LinkedIn as well.

If you have any questions
or feedback, let us know.

We'd love to hear you from you
if you're listening to this.

On a podcast player, please take
some time to put in a review.

This, so you too, please
like and subscribe.

Really would appreciate that.

Next episode in two weeks, we'll be
with Marin on his new app Data Tile.

So definitely check that out.

Have hope everybody has a good
week, and we'll talk to you later.

Bye everyone.

Bye.