Latest / The Pragmatic Engineer / Design-first software engineering: Craft – with Balint Orosz

Transcript

Design-first software engineering: Craft – with Balint Orosz · The Pragmatic Engineer

• 0:00
  SPEAKER_0: So how do you find it being different?
• 0:03
  Being both a founder with a lot more,
• 0:05
  should I say design focus,
• 0:06
  user focus,
• 0:07
  mobile focus?
• 0:08
  True engineers or hardcore engineers didn't really find me to be one of them.
• 0:13
  But then designers,
• 0:14
  product managers or others,
• 0:16
  they didn't find me to be one of them either.
• 0:18
  So you end up in this in-between period of you do a lot of engineering,
• 0:22
  they respect what you do but somehow because my focus has never been on
• 0:27
  distributed system,
• 0:28
  scalable algorithms,
• 0:29
  a lot of the innovation I bring to a team means that clicking on a button will
• 0:34
  take 2 milliseconds instead of 10 milliseconds.
• 0:36
  Backend engineers will say they just saved $2 million on infrastructure
• 0:40
  cost or scale to a billion users.
• 0:42
  My love for creating user-facing experiences kept me going and going on this path.
• 0:47
  Many people who started next to me who ended up moving a lot more towards
• 0:51
  back-end distributed systems,
• 0:53
  scaling engineering,
• 0:54
  that's where they thought and they found hard problems to be.
• 0:58
  Craft is one of the most delightful text editors and an app that has
• 1:01
  previously received Apple's Mac App of the Year award.
• 1:04
  I happen to know this app really well because its founder is my brother Balint Orosz.
• 1:08
  SPEAKER_0: Balint is probably the exact opposite of me.
• 1:10
  He's a designer at heart and is as good as someone can get in building amazing apps.
• 1:15
  Today we talk about why it's hard to fit in as a design first engineer or
• 1:19
  engineering leader at most tech companies.
• 1:21
  Unique engineering decisions behind Craft,
• 1:23
  like using custom components instead of the native iOS and Mac ones and not
• 1:27
  using auto layout.
• 1:29
  SPEAKER_0: How Craft built an editor where everything animates but nothing is jumpy.
• 1:33
  And many more interesting topics like how most companies get design systems
• 1:36
  wrong and how to make local-first software work well.
• 1:40
  If you're interested in how beautiful and highly opinionated software is
• 1:43
  built with a small team,
• 1:44
  this episode is for you.
• 1:46
  If you enjoy the show,
• 1:46
  please subscribe to the podcast on any podcast platform and on YouTube.
• 1:50
  SPEAKER_0: Thank you.
• 1:51
  SPEAKER_0: This really helps.
• 1:51
  SPEAKER_0: The show gets to even more listeners and viewers.
• 1:54
  This is a very rare and special episode,
• 1:56
  especially that I only have one brother.
• 1:58
  SPEAKER_0: So Balint, first of all, welcome to the podcast.
• 2:02
  SPEAKER_1: Thanks for having me.
• 2:04
  So one of the topics that,
• 2:05
  one of the reasons you're here is recently I reflected on something
• 2:11
  interesting how most CTOs that I know and even most founders at tech companies,
• 2:17
  they're very backend oriented.
• 2:20
  Their background typically they've been in engineering for 10 plus years is
• 2:25
  usually very backend heavy.
• 2:27
  SPEAKER_0: And this leads to a lot of interesting things.
• 2:30
  SPEAKER_0: Their approaches will prefer backend engineering approaches.
• 2:35
  For example,
• 2:35
  they'll often focus heavily on unit testing,
• 2:38
  automated testing and so on.
• 2:39
  But what I've not really seen is a more mobile UX design focused founder and
• 2:46
  especially engineering executive.
• 2:48
  And I have seen this with you because you're a lot more in this direction.
• 2:54
  SPEAKER_0: And the two of us are pretty different.
• 2:55
  SPEAKER_0: If I had to put myself, I'm far more of this back-end preference.
• 3:00
  SPEAKER_0: And even one, we did projects together many, many years ago.
• 3:04
  I was writing the unit test and the business logic and you were doing the
• 3:07
  front-end side of things and you still say it here.
• 3:10
  So how do you find it being different,
• 3:14
  being both a founder,
• 3:16
  previously you were an executive at Skyscanner with a lot more,
• 3:20
  should I say design focus,
• 3:22
  user focus,
• 3:22
  mobile focus?
• 3:23
  SPEAKER_0: What would a good way to be to put it?
• 3:27
  Yeah,
• 3:27
  so I've been writing code as you know since I've been 12,
• 3:32
  but always when I've been writing code,
• 3:35
  my main goal was to put something on the screen and to be able to interact with that.
• 3:41
  SPEAKER_1: So for many people it's-
• 3:45
  SPEAKER_0: We can probably note the first few programs that you wrote.
• 3:48
  SPEAKER_0: Those were games, right?
• 3:50
  SPEAKER_1: Yeah, they were games and visualization of graphs.
• 3:53
  And I focused a lot on time on making sure the graph is drawn in an animated fashion.
• 3:59
  So those were always the very,
• 4:02
  very interesting parts for engineering for me.
• 4:05
  SPEAKER_1: And this also led me to a number of different techniques over the time.
• 4:09
  SPEAKER_1: For instance, utilizing Flash a lot.
• 4:10
  I think Flash was a very interesting way of how code and design co-lived in the
• 4:17
  same tool and allowed a very strong creative expression.
• 4:20
  And I always tended to look at computers as an opportunity to draw on a canvas,
• 4:27
  draw on your screen.
• 4:28
  SPEAKER_1: Particularly as myself, I've never been able to draw by hand well.
• 4:32
  SPEAKER_1: I always looked at how computers can enable me.
• 4:36
  And I think this was a very interesting way because despite being an engineer
• 4:41
  for such a long time and writing so many code,
• 4:44
  I always felt that true engineers or hardcore engineers didn't really find
• 4:50
  me to be one of them.
• 4:53
  But then designers or product managers or others,
• 4:57
  they didn't find me to be one of them either.
• 5:01
  So you end up in the same between period of you do a lot of engineering,
• 5:06
  they respect what you do,
• 5:07
  but somehow because my focus has never been on distributed systems,
• 5:13
  scalable algorithms,
• 5:15
  a lot of the innovation I for instance,
• 5:17
  bring to a team means that clicking on a button will take two milliseconds
• 5:21
  instead of 10 milliseconds while backend engineers will say they just saved
• 5:01
  $2 million on infrastructure cost or scale to a billion users.
• 5:31
  And I think my love for creating user facing experiences kept me going and
• 5:37
  going on this path.
• 5:39
  But I've seen many people who started next to me who ended up moving a lot more
• 5:45
  towards backend distributed systems,
• 5:47
  scaling engineering because that's where they thought and they found hard
• 5:52
  problems to be.
• 5:54
  And also it's a lot in big companies how competency frameworks,
• 5:57
  promotion structures are oriented towards those areas where it's a lot
• 6:02
  easier to validate the impact you've been doing because it's a lot more measurable.
• 6:07
  SPEAKER_0: This episode is brought to you by WorkOS.
• 6:09
  If you're building a SaaS app,
• 6:10
  at some point your customers will start asking for enterprise features like
• 6:13
  SAML authentication,
• 6:14
  SCIM provisioning,
• 6:15
  and fine-grained authorization.
• 6:17
  That's where WorkOS comes in,
• 6:19
  making it fast and painless to add enterprise features to your app.
• 6:22
  Their APIs are easy to understand and you can ship quickly and get back to
• 6:25
  building other features.
• 6:27
  WorkOS also provides a free user management solution called AuthKit for up
• 6:31
  to 1 million monthly active users.
• 6:33
  It's a drop in replacement for Auth0 and comes standard with useful features
• 6:36
  like domain verification,
• 6:38
  rule-based access control,
• 6:39
  bot protection and MFA.
• 6:41
  SPEAKER_0: It's powered by Radix components, which means zero compromises in design.
• 6:45
  You get limitless customizations,
• 6:46
  as well as,
• 6:47
  modular templates designed for quick integrations.
• 6:50
  Today,
• 6:50
  hundreds of fast-growing startups are powered by WorkOS,
• 6:53
  including ones you probably know like Cursor,
• 6:55
  Vercel,
• 6:56
  and Perplexity.
• 6:57
  SPEAKER_0: Check it out at workos.com to learn more.
• 7:00
  SPEAKER_0: That is Workos.com.
• 7:03
  Before we jump back into the episode,
• 7:05
  I want to let you know that the audiobook version of my best-selling book,
• 7:08
  the Software Engineer's Guidebook is out now.
• 7:10
  You can get it on all major audiobook platforms like Spotify,
• 7:13
  Audible,
• 7:14
  Liberal.FM,
• 7:14
  Apple Books,
• 7:15
  Google Play and also DRM-free MP3 files.
• 7:19
  I started writing this book after a decade of working as a software engineer
• 7:22
  when I was working as an engineering manager for a few years already at Uber.
• 7:26
  Here's a view from the book from senior principal engineer Tanya Reilly,
• 7:30
  who was the author of the staff Engineer's Path.
• 7:32
  From performance reviews to P95 latency,
• 7:35
  from team dynamics to testing,
• 7:37
  Gergely demystifies all aspects of a software career.
• 7:40
  This book is well-named,
• 7:41
  it really does feel like the missing guidebook for the whole industry.
• 7:45
  You can get the book at engguidebook.com or search for the software
• 7:48
  Engineer's Guidebook on your favorite audiobook platform.
• 7:50
  SPEAKER_0: I hope you'll enjoy it.
• 7:52
  SPEAKER_0: Can we talk about this for a second?
• 7:54
  SPEAKER_0: Because your path, our path could have not been more different.
• 7:57
  Just to recap,
• 7:59
  both of us went to university,
• 8:01
  we actually went to the same university.
• 8:03
  I'm the older brother,
• 8:04
  so I was two years basically ahead and then both of us did some side projects on
• 8:09
  the side.
• 8:09
  We actually did some side projects together,
• 8:11
  which was kind of fun/interesting.
• 8:13
  SPEAKER_0: We built some apps.
• 8:15
  And then when it came to graduation,
• 8:18
  I went into the workforce,
• 8:20
  I went as an employee,
• 8:22
  as a new grad to a consultancy,
• 8:24
  then a larger company and then even bigger companies in the end ended up at Uber.
• 8:29
  SPEAKER_0: You started off as an entrepreneur to start with.
• 8:31
  You started off your startup,
• 8:34
  it was a small startup,
• 8:35
  then a mid-sized startup,
• 8:36
  and then it got acquired by a Skyscanner and then you became a director of
• 8:41
  engineeringwhenyou-
• 8:42
  SPEAKER_1: Yeah.
• 8:43
  SPEAKER_1: It was head of app product, essentially.
• 8:45
  SPEAKER_0: Head of app product.
• 8:46
  So you went from a two-person startup or three-person startup to a
• 8:50
  thirty-person startup acquired and boom,
• 8:52
  you're inside a thousand-person company.
• 8:54
  SPEAKER_1: Yep.
• 8:55
  You said that it was kind of hard to get recognition and I'm interested in what happened.
• 9:00
  SPEAKER_0: This was clearly at Skyscanner.
• 9:03
  You came in as,
• 9:04
  you went from running your startup to an executive,
• 9:07
  you were now some very important.
• 9:09
  Funny enough,
• 9:10
  we later both worked there and I was like levels below you,
• 9:14
  but what did this mean in terms of having a little bit struggle to get
• 9:21
  recognized the same way as your backend peers did?
• 9:24
  So it was very interesting on that side of things because there were two
• 9:30
  phases being at Skyscanner.
• 9:31
  I think the first part was our acquisition was mainly driven by the
• 9:36
  frustration or the desire to build a really amazing mobile experience.
• 9:42
  So this was 2014,
• 9:43
  mobile was on the rise and the leadership at Skyscanner,
• 9:47
  which was a founder driven leadership clearly said,
• 9:50
  "We need to be very,
• 9:52
  verygoodatmobile."
• 9:53
  At the same time there was an understanding couple there that they are a web
• 9:57
  first company,
• 9:59
  the entire generation of leadership was born in web and they need a different
• 10:02
  perspective who can propel them in that mobile-first future?
• 10:07
  So this meant in the first year,
• 10:09
  it was a lot about just do whatever you want to do.
• 10:13
  And in the second year I think things a little bit changed because there was a
• 10:17
  new wave of leadership coming in from Amazon,
• 10:19
  Microsoft,
• 10:20
  Facebook,
• 10:21
  other larger institutions.
• 10:23
  And the primary goal of that leadership was to help scale the organizational
• 10:28
  structure of Skyscanner,
• 10:29
  to make it a world-class engineering team.
• 10:32
  And I think this was where very interesting things started to happen in terms
• 10:37
  of agreements,
• 10:38
  disagreements,
• 10:39
  what is important,
• 10:40
  what is not important.
• 10:42
  Senior architects coming in,
• 10:44
  setting up metrics and trying to measure output and performance in ways that
• 10:50
  I didn't feel or the right way to measure those things.
• 10:56
  It was interesting because I've been pushing back a lot and I think the moment
• 11:01
  I started having deeper discussions with the engineering leaders,
• 11:05
  again very,
• 11:06
  very senior ones coming from big companies,
• 11:09
  I think there was a realization of oh my God,
• 11:11
  this is an area I am completely unequipped to deal with.
• 11:15
  So for now,
• 11:16
  I won't go super deep inside of that,
• 11:19
  but eventually I think a lot of the behaviors through again,
• 11:22
  competency frameworks,
• 11:24
  measurement of throughput.
• 11:26
  General engineering principles in treating the engineering organization
• 11:30
  as which needs to work along the same set of principles every engineer
• 11:35
  propagated into the app team and the organization as well,
• 11:41
  which led to a lot of different things on how we viewed performance,
• 11:47
  how we looked at throughput and who was seen as someone worthy of a promotion.
• 11:53
  SPEAKER_0: Yeah.
• 11:53
  SPEAKER_0: So in end you learned the big company ways.
• 11:56
  SPEAKER_1: Yes, yes.
• 11:57
  SPEAKER_1: And I learned tons.
• 11:59
  And for me it was an amazing educational experience because I've seen a lot of
• 12:02
  things and I think I could really build up because of this,
• 12:06
  a lot more solid understanding of what I believe is right,
• 12:10
  more likely what I believe is right should always be dependent on the context.
• 12:14
  So I got a lot more grander understanding of there's no right way of doing things.
• 12:19
  SPEAKER_1: There are certain problems which have certain ways of solving them.
• 12:25
  SPEAKER_1: Of course.
• 12:25
  SPEAKER_1: Of course.
• 12:34
  SPEAKER_0: But you never lost that.
• 12:37
  You mentioned one thing that both of us were a Skyscanner for a short time,
• 12:42
  a different organization made sure I didn't report into your organization
• 12:46
  and indirectly to you,
• 12:49
  but I remember that there was always a focus whenever I went over about when we
• 12:55
  talked about mobile development with you or people on your team,
• 12:59
  it wasn't really about the usual stuff like code quality,
• 13:05
  unit test coverage,
• 13:08
  CICD build times.
• 13:10
  SPEAKER_0: It was about user experience.
• 13:12
  SPEAKER_0: How smooth does it feel?
• 13:14
  SPEAKER_0: How fast is it, how many taps do you need?
• 13:17
  SPEAKER_0: So you kind of kept this focus even as you started your next startup.
• 13:22
  SPEAKER_0: That was a mobile iOS first startup Craft, Craft docs.
• 13:29
  And by that time you've seen in both,
• 13:30
  you've seen the backend,
• 13:31
  you've seen the front end.
• 13:32
  What did you decide to bring in from day one from engineering on how you've
• 13:37
  built this startup from scratch?
• 13:40
  Yeah,
• 13:40
  so I think the biggest takeaway I had there is if you want to create a really
• 13:49
  amazing product,
• 13:51
  you cannot really have one engineering culture inside of the company.
• 13:56
  And this is very interesting because when we look at,
• 13:58
  for instance,
• 13:59
  companies like Apple,
• 14:00
  they are very UI first engineering culture if you'd like,
• 14:05
  but their backends and their web services and all of those are terrible.
• 14:10
  And then you look at Amazon and Google who are very strong system design and
• 14:15
  backend engineering principle driven companies,
• 14:18
  they cannot seem to create meaningfully good or fluent UI experiences.
• 14:22
  Of course by the measurements they are there,
• 14:25
  but when you use them,
• 14:26
  they still don't feel comfortable.
• 14:28
  And what I thought at the time specifically as we've been creating a piece of
• 14:33
  software that was meant to be used hours a day,
• 14:38
  even today it's used,
• 14:39
  our average users use it two,
• 14:40
  three hours a day that you just cannot compromise.
• 14:44
  SPEAKER_1: You need to make it feel very fluent.
• 14:46
  But we are dealing with data,
• 14:48
  important data in terms of what you're writing,
• 14:51
  how you're thinking,
• 14:52
  which needs to be synchronized seamlessly,
• 14:54
  very fast,
• 14:55
  local-first.
• 14:57
  So I think this was the first thing where I said of we're going to have
• 15:01
  engineering principles for areas that touch data because we need to ensure
• 15:07
  there's zero data loss.
• 15:08
  We need to ensure those are very fast,
• 15:10
  super efficient,
• 15:12
  anytime we can switch parts.
• 15:14
  SPEAKER_1: And we don't really need to innovate there, if you know what I mean.
• 15:17
  SPEAKER_0: Yeah.
• 15:18
  I mean we need to refine a lot of things,
• 15:21
  but it's something that with the right approach we should be able to measure,
• 15:25
  iterate,
• 15:26
  and work on.
• 15:27
  And then there's the using facing part of the things where what we set out to do
• 15:32
  is essentially we start creating a hypertext editor for mobile.
• 15:36
  SPEAKER_1: Now, a hypertext editor even on the desktop is fairly complicated.
• 15:42
  SPEAKER_1: There's no very strong established patterns.
• 15:45
  It's not like a shopping cart where it's very trivial what you need to do.
• 15:49
  So I knew it was going to require a lot of iteration and a lot of resets and
• 15:55
  figuring things out.
• 15:57
  And that's where I didn't feel that established engineering patterns in the
• 16:02
  standard way of testing things,
• 16:05
  code coverage,
• 16:07
  building,
• 16:08
  even design components when tomorrow it might not be needed,
• 16:12
  will be the right approach to that.
• 16:14
  So this was,
• 16:16
  I think the approach of it came out with is neither is better than the other.
• 16:23
  I'm not saying that one type of engineering is better than the other,
• 16:26
  but these can actually very well complement each other.
• 16:29
  It brings in organizational complexity of the question of,
• 16:32
  okay,
• 16:32
  but what is engineering then?
• 16:34
  Is engineering then one domain or two domains or do we call front-end
• 16:37
  engineer design engineers and have them compensated differently?
• 16:42
  SPEAKER_1: But I felt very strongly about this coming out from there.
• 16:46
  SPEAKER_0: So maybe let's start with the actual architecture of the app.
• 16:50
  When you started out,
• 16:51
  I remember you knew I want to build an iOS app,
• 16:54
  which is going to be,
• 16:56
  you can take notes,
• 16:57
  you can use it,
• 16:57
  you can do whatever,
• 16:59
  it's like Evernote++ or just a lot better than what existed.
• 17:05
  And obviously you already knew at that point that there's going to be an iPad
• 17:08
  app at some point there's going to be Mac app,
• 17:09
  maybe a web app.
• 17:11
  What most teams would've done is you build an iOS app,
• 17:15
  you then build a Mac app,
• 17:16
  you build a web app,
• 17:17
  okay,
• 17:18
  the iPad,
• 17:18
  I guess it might be the same code base.
• 17:20
  So you now have three code bases and most teams would've just used existing
• 17:24
  native components.
• 17:25
  SPEAKER_0: What did you do and why?
• 17:28
  SPEAKER_0: Tell me more.
• 17:46
  SPEAKER_1: ... of Photoshop.
• 17:47
  Or just,
• 17:48
  even when I look at just Visual Studio 20 years ago,
• 17:52
  how complex it was and how well it worked.
• 17:56
  But sometimes I even go to these stores where they have these DAS space
• 18:01
  blue-screen windowing management solutions with all the keyboard
• 18:04
  shortcut UIs.
• 18:06
  So it's kind of a thing where I don't feel that there has been a significant
• 18:13
  improvement in terms of our ability to produce user interfaces.
• 18:19
  There somehow,
• 18:20
  we still try to figure out how to make them,
• 18:23
  but there hasn't been a significant complexity shift.
• 18:26
  SPEAKER_1: For me.
• 18:27
  What was always though really,
• 18:29
  really important is whenever I have an idea,
• 18:33
  be able to execute on it.
• 18:35
  And typically what happens is the closer you are to the core language pattern
• 18:41
  or the core framework elements,
• 18:44
  the bigger control over you have what you want to do.
• 18:47
  For instance,
• 18:48
  if you can create shader code,
• 18:50
  you can create any type of very beautiful visual effects if you want to
• 18:56
  despite anything else.
• 18:58
  SPEAKER_1: So for me-
• 18:59
  And just to be clear,
• 19:00
  shaders for those who are not listening,
• 19:02
  this is what renders like 3D or even 2D things on the screen and it basically
• 19:09
  runs on your GPU,
• 19:10
  right?
• 19:11
  SPEAKER_0: Yeah, oh yeah.
• 19:56
  SPEAKER_1: ... which promised you no longer need to think in rectangles.
• 20:00
  SPEAKER_1: You no longer need to specify that this label goes in this rectangle.
• 20:03
  SPEAKER_1: You can just say it should be at the top.
• 20:06
  The problem happens then is it's very easy for one label,
• 20:11
  but when you keep adding more things,
• 20:13
  the complexity increases.
• 20:15
  So when you want to do something more sophisticated,
• 20:17
  it can become very performance-intensive or you change one thing and the
• 20:22
  other change starts to fall apart.
• 20:24
  SPEAKER_0: I guess.
• 20:25
  SPEAKER_0: So for those who don't know iOS and AutoLayout or how layouts work.
• 20:29
  SPEAKER_0: Could we just explain?
• 20:30
  Well,
• 20:31
  this is why AutoLayout was a big deal for developers and then the trade-offs.
• 20:35
  SPEAKER_1: Yep.
• 20:36
  So back in the days,
• 20:38
  and iOS generally has this principle coming back from,
• 20:42
  it gives you a canvas which you can draw on,
• 20:44
  which comes with a lot of advantages.
• 20:46
  But the other disadvantage is you don't think of components of a stack,
• 20:50
  let's say,
• 20:51
  where you just pack things in stack in the web browser,
• 20:53
  but you say,
• 20:54
  I want this view to be on the X,
• 20:56
  Y,
• 20:46
  0,
• 20:46
  0 coordinate.
• 20:58
  SPEAKER_1: I want it to have a width of 200 pixels and a height of 100 pixels.
• 21:02
  SPEAKER_1: And this worked very well because early iPhones had all the same sizes.
• 21:05
  SPEAKER_1: I think the iPhone-
• 21:06
  SPEAKER_0: The same resolution, right?
• 21:07
  SPEAKER_1: The same resolution.
• 21:08
  SPEAKER_1: And I think the iPhone 4 or 5 was which became bigger.
• 21:12
  And that's where essentially you would have to start defining rectangles of
• 21:17
  I want this rectangle to be the width,
• 21:19
  which is 20% less wide than the enclosing container.
• 21:24
  And that's where Apple said,
• 21:25
  "Why don't we do something more elegant where you just specify this should
• 21:30
  snapinthemiddleanditcanautomaticallymagicallygrow."
• 21:35
  And what happens here is the layout engine calculates all of these run times.
• 21:41
  So you have a more abstract syntax that is easier to understand and define,
• 21:48
  but when it comes,
• 21:49
  for instance,
• 21:49
  to animations,
• 21:50
  to edge cases,
• 21:51
  you lose control because all of these dynamically calculated things will
• 21:55
  end up with something.
• 21:56
  So it's a lot more implicit way of defining how you want things to look,
• 22:02
  rather than being very explicit about this is exactly what I expect you to do
• 22:07
  as a layout element.
• 22:09
  So you're trading off a lot easier to define and work with as a developer and
• 22:14
  more complexity on the device and just less control when you want to do more advanced,
• 22:18
  as you mentioned animations.
• 22:19
  And in the early days it could feel jerky,
• 22:22
  laggy,
• 22:22
  sometimes it would go up and down,
• 22:24
  up and down,
• 22:25
  up and down but they fixed that part,
• 22:26
  right?
• 22:27
  Well,
• 22:28
  they did and they didn't because still when I run simulators,
• 22:32
  Apple error messages coming from their internal components.
• 22:34
  So the compiler couldn't figure out the layout so it's just falling back to
• 22:39
  something else.
• 22:40
  So there's always the more complexity you add in,
• 22:43
  your slave of what that engine can do,
• 22:45
  you're a slave of what it can resolve.
• 22:48
  And the more complex it gets,
• 22:49
  the less likely it can resolve it in a reasonable set of time.
• 22:53
  It got better,
• 22:54
  but I still think it has significant challenges inside of it.
• 22:58
  SPEAKER_0: So you never opted into it.
• 23:01
  You always said like let me choose the complexity and just to keep control.
• 23:06
  SPEAKER_1: No, this is in the story.
• 23:07
  So every time we hire an iOS engineer,
• 23:10
  they're like,
• 23:10
  "You guys are ancient.
• 23:12
  SPEAKER_1: Why don't you use these new technologies?"
• 23:14
  SPEAKER_1: For a while it was AutoLayout, now it's SwiftUI.
• 23:16
  And what I always do is I show them one of our transitions and say,
• 23:20
  "If you can do this with the same performance in AutoLayout,
• 23:23
  we'reswitchingtoAutoLayout."
• 23:25
  And I've done this at least 10 times,
• 23:27
  and they're always like,
• 23:28
  "Yeah,
• 23:28
  sure.
• 23:28
  SPEAKER_1: Like hell, I can."
• 23:30
  Some of them even succeed but then when you look at the code and I tell them,
• 23:33
  "Okay,
• 23:33
  but now change this to that" and they're going away for two weeks and they
• 23:37
  still couldn't figure out how to change that.
• 23:39
  SPEAKER_1: I'm like, "HereDoc was two minutes to do."
• 23:42
  SPEAKER_1: That's when I say, "Okay, this technology is not for us."
• 23:45
  SPEAKER_1: So it's not about resisting things, it's about what I said.
• 23:50
  Does it limit our capability to innovate and does it limit our capability to
• 23:54
  express things in a reasonable timeframe versus does it feel simple at the
• 24:00
  start but actually when you're at the bleeding edge of what you want to do,
• 24:04
  it's holding you back.
• 24:05
  SPEAKER_1: I think that is the main part of what I'm looking at.
• 24:10
  One interesting thing that you also did on top of not necessarily onboarding
• 24:16
  to the system components is how you organize your code.
• 24:20
  You mentioned that you have one code base across mobile,
• 24:24
  iPad,
• 24:25
  desktop and even Vision Pro.
• 24:27
  And as I understand this is not normal,
• 24:32
  even in the iOS world or in the kind of Apple world,
• 24:35
  usually there's different code bases and they reuse some parts of it.
• 24:39
  SPEAKER_0: Why did you decide to do the same.
• 24:41
  SPEAKER_0: And what up upsides and downsides does it have?
• 24:45
  SPEAKER_1: Yeah, so it's very interesting.
• 24:46
  I think we are the only app of this complexity which actually has the same code bases.
• 24:51
  Not just reuse components,
• 24:53
  it's like 99% the same code base,
• 24:56
  which some native bindings on each platform,
• 24:59
  which are required to do that.
• 25:01
  And the reason we had that is when I started Craft I said we want to do a
• 25:04
  hypertext mobile editor,
• 25:06
  but we had this thing where mobile products shouldn't be just companion tools.
• 25:12
  A big chunk of the world is mobile only,
• 25:15
  and if we build the right software,
• 25:17
  these mobile CPUs and GPUs right now so fast,
• 25:19
  there's no reason why you cannot have the full software there maybe except
• 25:23
  you need to think about it differently.
• 25:25
  Because what happens is most companies try to shrink down their desktop
• 25:30
  product into mobile and try to cherry-pick which functionality you want to
• 25:33
  have during,
• 25:34
  which not.
• 25:35
  So for this was a really important thing that our desktop app always does the
• 25:39
  same thing as the mobile app.
• 25:41
  And of course what better way is to do it than having itself a shared code base.
• 25:46
  But I think what,
• 25:49
  originally when I started Craft,
• 25:50
  there wasn't this technology which enabled you to run UI kit code on the Mac.
• 25:56
  So when people were asking me about a desktop app,
• 25:58
  I were like,
• 25:59
  maybe sometime we want to get it right on mobile first.
• 26:02
  And then around in 2021,
• 26:04
  Apple introduced this thing called Mac Catalyst,
• 26:07
  which again essentially allows you to write Mac apps with iOS component and
• 26:15
  code layouts because Mac used to have a different rendering engine and
• 26:20
  layout engine.
• 26:21
  SPEAKER_0: Yeah, different API as well,
• 26:22
  SPEAKER_1: Different APIs and all sorts of things.
• 26:25
  And with the introduction of the M1 processors,
• 26:28
  it all made sense because suddenly instead of it running in a simulation as it
• 26:32
  had with the Intel based processors,
• 26:33
  it kind of runs down natively so you get the same performance benefits.
• 26:37
  Now the big problem for us was of course is Mac apps tend to look and behave very
• 26:42
  differently than iOS apps.
• 26:44
  So technically we couldn't really have any examples of what is the right way
• 26:50
  of doing all of these responsive designs at this fidelity,
• 26:54
  so it feels native on energy platform.
• 26:56
  So I think that's where our belief,
• 27:00
  and we treat everything as a canvas,
• 27:02
  made a lot of sense because we could build a toolbar that looks on the Mac,
• 27:06
  like a Mac toolbar and an iPhone like an iOS toolbar.
• 27:09
  SPEAKER_1: Or we could build buttons that again adapt to those behaviors.
• 27:13
  And I think we spent a good two years of trying to understand how to structure
• 27:18
  our codes,
• 27:19
  our components to get the most reusability and be able to truly fulfill this
• 27:26
  vision of let's say just building the feature for both platforms will always
• 27:32
  take a little bit more time,
• 27:33
  but I think for us it's just like 5% more time rather than saying 50% more time.
• 27:38
  SPEAKER_1: As we optimize for both.
• 27:40
  SPEAKER_0: Can we actually look at what that means?
• 27:42
  If you could show just the UI and just show us what some of your own components
• 27:49
  are and then maybe how it connects with the code?
• 27:52
  SPEAKER_0: And then there was nice animation there.
• 27:53
  SPEAKER_0: Can you use it again?
• 28:27
  SPEAKER_1: Yeah, yeah, I can do it again.
• 28:28
  So everything moves in the same time and then everything comes back to the
• 28:31
  same time.
• 28:32
  Now for most native developers doing this is kind of what you would call impossible.
• 28:36
  I think when I showed this to Apple engineers,
• 28:38
  they themselves ask,
• 28:39
  "Howcanyoudothis?"
• 28:40
  SPEAKER_1: It's not impossible.
• 28:42
  SPEAKER_0: Why would they say that?
• 28:44
  SPEAKER_0: What makes it so challenging on most things.
• 28:47
  SPEAKER_0: It's a nice animation, right?
• 28:48
  SPEAKER_0: Just saying as somewhat who's seen it?
• 28:50
  SPEAKER_0: It is really smooth, but it's an animation, right?
• 28:53
  SPEAKER_1: Yeah.
• 28:53
  The problem is if you use the default toolbar,
• 28:56
  you cannot hide the default toolbar animated.
• 28:58
  SPEAKER_1: You can definitely not say what curve it should hide with.
• 29:01
  So even if you hide the sidebar,
• 29:04
  the toolbar is going to animate in a different sense.
• 29:08
  SPEAKER_1: So you won't have this consistent feeling.
• 29:10
  SPEAKER_1: But again, as I said, we treat this as the canvas.
• 29:12
  SPEAKER_1: So everything you see here is kind of owned by us, drawn by us.
• 29:16
  SPEAKER_1: We can just say, "Hey, toolbar, move out in that perspective."
• 29:21
  SPEAKER_1: So that is what enables this.
• 29:23
  And a lot of people think that,
• 29:24
  hey,
• 29:25
  this must be super complex because recreating such a foundational thing as a
• 29:29
  toolbar is super complex.
• 29:32
  So I'll just take things,
• 29:34
  show a little bit about how the code looks like.
• 29:38
  In this timeframe it might be a little bit harder to understand,
• 29:43
  but I'll give my best to highlight the foundational parts.
• 29:47
  So a lot of our back in the days,
• 29:50
  Craft was still called [inaudible 00:29:51].
• 29:51
  So a lot of in the code,
• 29:52
  we have still the old code names,
• 29:54
  butthisiskindof-
• 29:55
  SPEAKER_0: You always have code names.
• 29:56
  SPEAKER_0: Every single company has code names.
• 29:58
  SPEAKER_1: Yeah, yeah.
• 29:59
  So essentially here we have kind of the toolbar class and you can say that we
• 30:03
  needed to,
• 30:04
  and we could define some custom capabilities.
• 30:08
  Like in the toolbar,
• 30:09
  we might want to show your profile,
• 30:10
  display,
• 30:12
  or we might want an iPhone specifically.
• 30:14
  It's important to have a bottom separator,
• 30:16
  but when you scroll,
• 30:17
  we don't want to have that.
• 30:19
  SPEAKER_1: Do we want to show, let's say the title of the pager inside of that.
• 30:23
  SPEAKER_1: And there's some of these part of things.
• 30:27
  SPEAKER_1: But then when you run through the code itself, it's fairly similar.
• 30:31
  SPEAKER_1: We have a bottom separator, we have a blur material.
• 30:35
  So at the background of the toolbar has this nice little blurred feeling,
• 30:39
  a done button.
• 30:40
  We have this real-time cursor area where you see all those faces popping and
• 30:44
  fuse editing it.
• 30:46
  SPEAKER_1: Some other views like the title, the left.
• 30:49
  And then it's like some basic command handling we use of what happens when
• 30:55
  somebody does something.
• 30:57
  But if I go through this,
• 30:59
  this is the layout code,
• 31:00
  so this is what I talked about.
• 31:01
  If we're saying it's kind of ugly because this would be more,
• 31:05
  and this is when I'm saying of,
• 31:07
  hey,
• 31:07
  we're saying the right area should be in this rectangle,
• 31:12
  and I'm doing the calculation of this rectangle,
• 31:14
  but again,
• 31:15
  it's drawing a rectangle,
• 31:16
  so it's not super complicated.
• 31:18
  I mean this is,
• 31:19
  but the code will probably be for a native component as well,
• 31:21
  roughly.
• 31:21
  SPEAKER_0: And if we looked inside of it.
• 31:23
  SPEAKER_1: Yeah.
• 31:24
  And again,
• 31:24
  it's like 600 lines,
• 31:26
  but none of those lines are really cognitively challenging.
• 31:31
  So we have junior engineers coming in in the second day doing changes to this.
• 31:35
  So it's a very interesting thing because again,
• 31:39
  this is where I come back to a backend engineering season,
• 31:42
  staff engineer will come look at this and say,
• 31:45
  "Where'sthemagicinsideofhere?"
• 31:48
  And I think the core part of is you need to do a lot of iteration to get which
• 31:54
  components you build and how right,
• 31:57
  but then you can reap a lot of the benefits without having a super complicated thing.
• 32:02
  And the other really good thing is it's like having an open source library you
• 32:07
  can actually modify.
• 32:08
  Because what I said,
• 32:09
  we're not working with closed source components or even code base that is
• 32:14
  just so big.
• 32:15
  Even let's say you're using a complex framework,
• 32:19
  even if it's open source,
• 32:20
  you're afraid to modify it because there may be so many side effects is
• 32:24
  everybody is free to go in and do the changes and they can understand the
• 32:28
  impact of those changes very easily.
• 32:31
  And so when you're saying open source,
• 32:33
  you mean open in terms of for the team to change because now,
• 32:36
  you internal open source if you will.
• 32:40
  SPEAKER_1: Yeah.
• 32:40
  Because most of the components you end up using native components or whatever.
• 32:44
  SPEAKER_1: If you use a native toolbar, you cannot really modify that at all.
• 32:47
  SPEAKER_1: You get what's in there.
• 32:49
  But this is really interesting though because I feel there's a very big
• 32:52
  divide between backend and kind of client-side/front-end engineering in
• 32:56
  the sense of as a backend engineer,
• 32:59
  it's kind of obvious that you choose an open source library.
• 33:02
  SPEAKER_0: You might also just rebuild a lot of things from scratch.
• 33:06
  SPEAKER_0: There's just this given thing that you go in and change it.
• 33:08
  You fork the library and you might make changes or try to submit them upstream.
• 33:12
  SPEAKER_0: Whereas for, I worked on both sides.
• 33:15
  When I worked on mobile engineers,
• 33:16
  it was like,
• 33:17
  "Oh,
• 33:18
  you just take the component that comes from Apple or from Google or JetBrains
• 33:24
  and you look at the API,
• 33:25
  what you can do,
• 33:26
  you try to tweak it and that's it.
• 33:30
  I wonder why this is,
• 33:32
  do you think Apple might have something to do with it?
• 33:34
  SPEAKER_0: They have a very strict way that they don't take contributions.
• 33:38
  You can raise a,
• 33:39
  even if you have an obvious bug,
• 33:41
  it takes so long to resolve.
• 33:43
  You have to raise in their ticketing system and they might or might not look at it,
• 33:46
  but they're the only ones who can do it.
• 33:49
  Yeah,
• 33:50
  I think this is a lot about,
• 33:54
  a lot of the communication of engineering companies who build tools for
• 33:59
  front-end engineers are about,
• 34:01
  we're going to simplify this for you because it is complex.
• 34:05
  So a really good example is there are things which we call virtualized lists.
• 34:10
  SPEAKER_1: So what's essentially means is you have a list of 1000 items.
• 34:13
  SPEAKER_1: You cannot create the 1000 views because that's going to be very slow.
• 34:17
  So as you scroll,
• 34:18
  you detect which views should be on the screen and you only have let's say 10
• 34:22
  views on the screen at a time.
• 34:24
  SPEAKER_1: And every time one of it disappears kind of you repurpose it.
• 34:30
  And people are very afraid to create virtualized lists because they say,
• 34:36
  "Oh,
• 34:36
  it'ssocomplicated."
• 34:38
  And I'm like,
• 34:39
  "What is so complicated in understanding of which view is off-screen and
• 34:43
  then reusing it,
• 34:44
  addingittoanobjectpoolandputtingitback."
• 34:47
  SPEAKER_1: And they're like, "Yeah, but Apple's UI collection view or whatever list.
• 34:50
  SPEAKER_1: You have so many things it can do."
• 34:52
  I mean,
• 34:52
  "Yeah,
• 34:53
  it has so many things it can do,
• 34:54
  but which of those things actually do you need right now?
• 34:57
  SPEAKER_1: And then why cannot you write that itself?"
• 35:01
  So I think front-end engineering is a little bit like you might have thousand
• 35:06
  things a control supports,
• 35:09
  it can support small text,
• 35:11
  big text,
• 35:12
  this background or that,
• 35:14
  touch keyboard handling,
• 35:15
  whatever that is.
• 35:17
  SPEAKER_1: And that is a lot of work.
• 35:19
  But assuming that you're going to need all of them isn't probably the right
• 35:24
  thing to do.
• 35:25
  But also then because you never actually end up building lower level codes,
• 35:29
  you always just end up using these,
• 35:31
  you kind of lose your capability to create these.
• 35:36
  SPEAKER_1: Very often front-end engineers will become an expert in their own domain.
• 35:40
  Like React engineers know how react works,
• 35:43
  but they don't necessarily understand the underlying solutions.
• 35:48
  Again,
• 35:48
  in backend engineering,
• 35:49
  the university and everywhere,
• 35:51
  people learn about how databases work at the core,
• 35:53
  what do those mean,
• 35:54
  and they can repurpose that.
• 35:56
  SPEAKER_1: We don't learn that about front-end systems.
• 35:59
  So there's a lot more,
• 36:01
  I think fear of doing anything custom and what that might result in.
• 36:06
  SPEAKER_0: This episode is brought to you by Augment Code.
• 36:09
  We share AI co-pilot,
• 36:11
  actually knew your codebase,
• 36:13
  Augment Code is different.
• 36:15
  Augment is built for professional engineering teams working on complex systems,
• 36:19
  not hobbyists building to-do apps.
• 36:21
  Other AI assistants struggle with context,
• 36:24
  Augment understands your entire codebase architecture,
• 36:27
  patterns,
• 36:27
  dependencies and all.
• 36:29
  We're talking instant understanding of systems with millions of lines of
• 36:32
  code in under 200 milliseconds.
• 36:35
  Teams like Webflow,
• 36:36
  Lemonade and [inaudible 00:36:38] use Augment to ship better code faster.
• 36:40
  SPEAKER_0: No more context switching, no more generic suggestions.
• 36:43
  SPEAKER_0: Just an AI that works the way expert developers do, fast and in flow.
• 36:49
  Plus what enterprise-grade security and zero training on customer code you
• 36:52
  can trust Augment with your systems.
• 36:55
  Start building with Augment in your favorite IDE and see what it's like when
• 36:58
  an AI actually understands your code.
• 37:01
  SPEAKER_0: Try it free at augmentcode.com/pragmatic.
• 37:06
  When we talk about front-end systems,
• 37:08
  one of the things that most companies would do is they would,
• 37:11
  if you're talking about mobile app or web app,
• 37:14
  create a design system.
• 37:15
  I've seen this so many times at Skype,
• 37:18
  Skyscanner,
• 37:20
  every company,
• 37:20
  there's blog posts about it.
• 37:21
  SPEAKER_0: Here's our new design system.
• 37:24
  And this is usually a pretty big undertaking,
• 37:25
  but it might involve creating custom components or using system components,
• 37:29
  et cetera.
• 37:30
  SPEAKER_0: What is your design system?
• 37:31
  SPEAKER_0: If you even have one, do you have one?
• 37:35
  We have systems,
• 37:36
  but we have a very different design system that most companies will do.
• 37:40
  And so what most companies do is there is this called atomic design system
• 37:45
  where you start with base colors as atoms,
• 37:48
  and then you have buttons which combine colors and shapes as components and
• 37:53
  then you build bottom up from there.
• 37:55
  SPEAKER_1: And this has been very efficient.
• 37:58
  And design systems started coming along when there was this saying that
• 38:02
  design needs to have a CXO seat at the table.
• 38:05
  SPEAKER_1: And since most CXO-
• 38:08
  SPEAKER_0: Like a C-level, so chief design officer basically?
• 38:11
  Yeah,
• 38:11
  yeah,
• 38:11
  chief design officer just kind of design started saying we need a seat at the table.
• 38:15
  And they found this very common language of systems and components because engineers,
• 38:20
  and again,
• 38:21
  high-level executives and tech companies were often engineers in the past.
• 38:25
  SPEAKER_1: Rather than just saying, "We feel this looks good."
• 38:28
  SPEAKER_1: They could have this shared language of how this looks good.
• 38:32
  And for companies which have a very established brand,
• 38:36
  identities and guidelines,
• 38:37
  which is very static,
• 38:39
  this works well,
• 38:41
  and also it works very well for scaling quality.
• 38:44
  Now we all know that scaling quality versus improving quality or innovating
• 38:50
  are two very different systems.
• 38:52
  So for instance,
• 38:54
  I expect every front-end engineering Craft in two minutes to be able to
• 38:59
  create the exact same button we have.
• 39:01
  SPEAKER_1: Because what is the button we have?
• 39:03
  It's a rounded rectangle with a six pixel corner radius,
• 39:06
  eight on iPhone,
• 39:08
  with this background color and this font size,
• 39:12
  a light center.
• 39:13
  SPEAKER_1: Now creating that doesn't require a PhD.
• 39:17
  What we do have systems for is more sophisticated parts,
• 39:24
  and these are for instance animation.
• 39:26
  So in animation we figured out that it's not about,
• 39:32
  I mean you need to fine-tune some parameters,
• 39:34
  but really what happens is you animate multiple things at the same time and
• 39:39
  the consistency of that experience so it feels as one movement and every
• 39:42
  movement is harmonized together.
• 39:45
  SPEAKER_1: It's like because it's this visual movement, it's like a dance.
• 39:48
  When you look at a team dance competition,
• 39:50
  if the dancers move in the same time,
• 39:53
  it looks good,
• 39:54
  but as each one of them move in the different time,
• 39:56
  it feels terrible.
• 39:58
  For us having an animation engine,
• 40:00
  an animation library that synchronizes everything across everyone and we
• 40:05
  enforce usage of that,
• 40:07
  you cannot do anything else is something.
• 40:10
  Then I think there are other things which are quite important for us because
• 40:15
  we realize some things that I think I might just show my screen here,
• 40:20
  share my screen for a minute.
• 40:23
  And then just to be clear,
• 40:24
  when you said like it's like a dance and multiple things need to move,
• 40:26
  this is because you animate often everything on the screen,
• 40:30
  all your components,
• 40:31
  right?
• 40:32
  SPEAKER_1: Well, when an area grows, others need to shrink.
• 40:35
  So it's you have a fixed window size or when you change that window size,
• 40:40
  everything needs to adaptively fill that.
• 40:42
  SPEAKER_1: And in Craft, everything is animated.
• 40:44
  So I think this is also a very interesting thing of I think we're the only text
• 40:49
  editor where for instance,
• 40:51
  when you enter a new line or remove something,
• 40:55
  the entire document animates.
• 40:57
  SPEAKER_1: It's not jumping.
• 40:58
  SPEAKER_1: You don't have this tick, tick, tick but rather everything flows down.
• 41:01
  SPEAKER_1: So animation and everything by default when it's moving, it's-
• 41:05
  SPEAKER_0: No.
• 41:05
  SPEAKER_0: So the bottom document for example, it also moves down.
• 41:12
  SPEAKER_0: That's going to be a separate animation, right?
• 41:15
  In the next paragraph and you know,
• 41:16
  everything,
• 41:18
  companies shy away from animating these because it's harder.
• 41:22
  SPEAKER_0: Because the built-in.
• 41:24
  And also the built-in components don't allow to do this easily or nicely,
• 41:28
  right?
• 41:29
  SPEAKER_1: No, no.
• 41:29
  SPEAKER_1: they do not.
• 41:30
  Okay,
• 41:31
  so I'm starting to see that you're,
• 41:32
  did you know you're going to get all this advantages by building your own
• 41:37
  stuff or did it just happen?
• 41:41
  So what we knew is when you draw on a client bus,
• 41:45
  you decide what you want to do.
• 41:47
  So I think this is the point of when you just think about something where you
• 41:52
  have full control over everything,
• 41:54
  you know can do whatever you do.
• 41:55
  And five years ago I didn't know I want to have this type of animation or that
• 41:59
  type of thing,
• 42:00
  but what I wanted is to set up the environment in a way where I can do it if I want it.
• 42:07
  And I think this is a lot about having control over the basic parts of the system,
• 42:13
  which enables you to do these.
• 42:14
  And then it enables you to often do it very cheaply because often you can hack
• 42:19
  it into existing systems,
• 42:20
  but then those modifications,
• 42:22
  if they go against the original design principle of that system,
• 42:26
  it feels terrible.
• 42:27
  SPEAKER_1: It will be buggy, hard to maintain and so on.
• 42:32
  So then you said you don't have a design system,
• 42:35
  but you have systems like an animation system?
• 42:39
  SPEAKER_0: Yeah, three dots.
• 43:06
  SPEAKER_1: Yeah.
• 43:06
  SPEAKER_1: What we realized when you put three dots, you lose two characters.
• 43:09
  So if this were an ellipsis,
• 43:11
  I wouldn't see the O and the N,
• 43:13
  I would only see up to the question.
• 43:14
  And we found this both better aesthetic and more useful because in mobile and
• 43:18
  tiny spaces,
• 43:19
  those few characters matter.
• 43:21
  So we created a behavior which you can attach on any label and then instead of
• 43:26
  it cropping itself,
• 43:27
  it will have this nice fading out experience.
• 43:31
  And also it's a little bit more complicated because it needs to work against
• 43:35
  any background because Craft uses these tinted backgrounds,
• 43:38
  it takes over the document color and the likes of that.
• 43:41
  SPEAKER_1: So it has complexity to create on its own.
• 43:44
  SPEAKER_0: Plus you have dark mode as well, right?
• 43:46
  SPEAKER_1: Yeah, we have dark mode, light mode, transparent backgrounds.
• 43:49
  Color is quite complicated and that's why we create this once and build it in a
• 43:55
  way where you can attach it to any label you have in the application.
• 43:59
  Which means,
• 44:00
  again,
• 44:00
  for engineers,
• 44:02
  it's very easy to create these delightful experiences because they can just
• 44:06
  take something and tweak it easily.
• 44:12
  One thing that's interesting about Craft is it is,
• 44:15
  as you told me before,
• 44:16
  it's personal software.
• 44:18
  SPEAKER_0: It's very, you work with your own documents, with your own stuff.
• 44:25
  And how,
• 44:28
  what difference does this make in how you engineer the application?
• 44:31
  SPEAKER_0: What opportunities does this give you?
• 44:32
  SPEAKER_0: You mentioned things like local-first.
• 44:35
  SPEAKER_0: And how does it impact the architecture back in the front-end?
• 44:42
  SPEAKER_1: So this was something that I keep learning and relearning all the time.
• 44:48
  SPEAKER_1: It's very clear, I think that new technologies emerge on the server side.
• 44:54
  And for a while it wasn't clear for me of how much of the things we do can be local
• 45:00
  versus how much of them need to implement it on the server side.
• 45:03
  So we have quite strong teams on both parts,
• 45:06
  and I think that's what you need in the long term.
• 45:08
  What's very important is,
• 45:10
  is when you're dealing with personal software,
• 45:12
  usually the amount of content you're dealing with except for binary files
• 45:17
  like videos and media,
• 45:19
  but raw content that can fit on the user's device,
• 45:24
  which is very interesting because when you're looking at B2B software where
• 45:27
  there's a thousand individuals contributing to that is there's no way
• 45:32
  that's going to fit on your device.
• 45:34
  Now this is something very interesting because then if you think about it,
• 45:38
  a lot of the computes can be done locally,
• 45:41
  which is also interesting because how your cost base will move across those things.
• 45:46
  And also what I'm seeing right now,
• 45:48
  for instance,
• 45:49
  LLMs and AI is something that we're saying is like it's no way it's going to be
• 45:53
  on device,
• 45:54
  but just in the recent weeks we're seeing signals that actually in a couple of
• 45:57
  years that might be also available.
• 46:01
  So one of the things we're building is we're building every service in a way
• 46:06
  and wrapping them in architectural components that we can replace them to
• 46:09
  local or remote components anytime we feel now it's possible to do or not
• 46:16
  without significant infrastructural changes.
• 46:18
  SPEAKER_1: And this also has impact on how we architecture our backends.
• 46:23
  SPEAKER_1: So for instance, a very concrete example would be search.
• 46:26
  Now the traditional way of when you have,
• 46:30
  let's say Craft has more than 2 million users is you have a big,
• 46:35
  let's say elastic search cluster,
• 46:38
  all of the user's data is indexed in that elastic search cluster and you have
• 46:43
  logical separation,
• 46:44
  but you don't have physical separation.
• 46:47
  Now the problem is what if you just want to change the search algorithm for a
• 46:51
  few users or improve that and things like that,
• 46:53
  it gets complicated.
• 46:55
  So what we're looking at is could we have 2 million search indexes on a disk in
• 47:02
  the cloud?
• 47:03
  And every time somebody does a search,
• 47:06
  either they can download that search index locally and use it there to
• 47:09
  execute the search.
• 47:11
  Or if we cannot download it because it's too big,
• 47:13
  maybe a Lambda or a serverless function can just read the search index and
• 47:18
  based on that execute the search for the client that needs to do that
• 47:22
  specifically for API use cases or whatever headless capabilities we want to
• 47:28
  implement this might be very helpful,
• 47:30
  but thinking about how we can replicate and use the same infrastructure
• 47:35
  across client and backend is something you can only do when you're looking at
• 47:39
  personal scale data.
• 47:41
  And it's kind of impossible to think about when you're looking at very deeply interconnected,
• 47:46
  thousands of individuals in the same data set.
• 47:50
  SPEAKER_0: And it's interesting, you mentioned local computing.
• 47:54
  Until now,
• 47:56
  the traditional thinking was that,
• 47:58
  yeah,
• 47:58
  you should do every compute on the web because you have very thin clients.
• 48:02
  It might just be a web page,
• 48:04
  even if it's a mobile device,
• 48:05
  it doesn't have much computing capability,
• 48:08
  but this is all changing,
• 48:10
  isn't it?
• 48:12
  SPEAKER_1: I think it's always a ping pong.
• 48:15
  And this is what we realize when you're long enough in tech is you have cycles.
• 48:19
  We used to come from the central computer with terminals,
• 48:23
  then we came onto with the PC of local computing,
• 48:26
  then we went back with cloud of everything is computed in the cloud from
• 48:30
  websites being server-side rendered.
• 48:32
  And now we are seeing I think a new wave of personal computing,
• 48:38
  and I think it is powered by also processors getting lost faster.
• 48:41
  I believe the M4 Pro is a faster processor than anything you can buy on an AWS cloud.
• 48:48
  And if you can use those resources for it to code only for you and you as a user
• 48:54
  have an option to upgrade your level of service because of local computing,
• 48:59
  that is interesting.
• 49:02
  SPEAKER_1: I don't think it's ever going to be black and white.
• 49:04
  SPEAKER_1: It's always gray.
• 49:05
  I think they're,
• 49:07
  eventually people get tired of their own computers holding them back and
• 49:11
  they enjoy server-side components enabling them and then they start
• 49:14
  feeling bad about how much the server-side project costs,
• 49:18
  and they want to have that power on their own computer.
• 49:20
  SPEAKER_1: So it's a pendulum swing.
• 49:22
  And I think now we're starting to see a lot of interest in moving that
• 49:25
  ownership of being able to decide the performance I want to have to my
• 49:31
  computer versus to the cloud.
• 49:34
  SPEAKER_0: But I guess this can also help with, for example, just pricing.
• 49:37
  SPEAKER_0: Just right now we're in the end of zero interest rates have ended.
• 49:41
  SPEAKER_0: Efficiency is a lot more important.
• 49:43
  SPEAKER_0: It's harder to raise money.
• 49:44
  Basically,
• 49:45
  it's not really feasible to necessarily lose money on services.
• 49:50
  But if you can do this and you switch that,
• 49:52
  you might be able to,
• 49:53
  for example,
• 49:54
  offer software where it's free or very cheap or a one-off payment if use local.
• 50:00
  And if you want to use the server,
• 50:02
  okay,
• 50:02
  well then it'll be a monthly fee of this or that,
• 50:05
  right?
• 50:05
  Theoretically this could be an option,
• 50:07
  but only with local compute in the sense of not losing money on it.
• 50:11
  Well,
• 50:11
  I think one of the big challenges is underlying operating systems are
• 50:15
  changing a lot faster than they were and consumers expect even free software
• 50:19
  to adapt to that.
• 50:20
  SPEAKER_1: So yes, you're right on the hosting perspective.
• 50:23
  Our biggest challenge is every time Apple releases a new iOS version,
• 50:26
  it's like one and a half months of the full engineering team just to make it
• 50:29
  sure it's bug free.
• 50:30
  And if we don't do that,
• 50:32
  even free customers or one-time payment customers will be very upset that
• 50:36
  we're not updating the software.
• 50:37
  SPEAKER_0: Yeah, I hear you.
• 50:39
  SPEAKER_0: One thing you noticed is of one thing you mentioned is local-first.
• 50:43
  SPEAKER_0: And now I feel this technology is making a comeback or a surge.
• 50:48
  SPEAKER_0: What is your honest thoughts on it?
• 50:52
  Does local-first actually work for these personal software categories or
• 50:58
  is it still in its infancy?
• 51:01
  Local-first is a very interesting thing because for it to make sense,
• 51:05
  you need to have a very high reliance on the content you have there because
• 51:09
  really the value of local-first is when you don't have 5G on your devices,
• 51:13
  you can still access that information.
• 51:16
  And I think local-first is now experiencing a comeback because people are
• 51:22
  starting to travel again when they're on their airplanes,
• 51:25
  they're on the tubes.
• 51:26
  And it gets very inconvenient when you need something badly and you don't
• 51:30
  have it.
• 51:31
  But I think it only makes sense for a very small subset of products out there.
• 51:37
  It's very interesting because for instance,
• 51:38
  Craft is local-first,
• 51:40
  but when adding comments,
• 51:43
  we could do it in a local-first manner,
• 51:45
  but we figured the UX would be very weird out.
• 51:47
  You see a content,
• 51:49
  you post a comment on it when you're on an airplane,
• 51:52
  three hours later when you land,
• 51:54
  the comments get added.
• 51:56
  But at that point there might be other comments added which make your comment
• 51:59
  field super weird from a social perspective.
• 52:02
  So I think for us it's very important because we store some of the information
• 52:07
  you always want to have access to independent of what that is,
• 52:11
  but there aren't that many software categories which actually need to
• 52:16
  provide that with users for.
• 52:20
  How opinionated is Craft,
• 52:23
  and in generally personal software,
• 52:27
  compared to because one thing that strikes me about Craft,
• 52:30
  I've been using it since the Alpha like this,
• 52:32
  the advantage of being there,
• 52:35
  it just feels very kind of different.
• 52:37
  You have these gestures,
• 52:39
  I don't know,
• 52:40
  maybe you can show some of them that it just doesn't exist.
• 52:45
  SPEAKER_0: You're pretty opinionated and Craft seems pretty much.
• 52:48
  I wonder if this is unique to Craft or do you see more startups,
• 52:55
  personal software potentially doing this and actually it being a good thing?
• 52:59
  SPEAKER_0: Is it a good thing?
• 53:00
  SPEAKER_0: Do people like it?
• 53:01
  SPEAKER_0: Because I like it, but I'm never representative of the broader audience.
• 53:07
  I think when it comes to personal buyers and personal software,
• 53:10
  it's very much around when you think,
• 53:12
  for instance,
• 53:12
  pricing.
• 53:13
  SPEAKER_1: So businesses are, do what they call value-based pricing.
• 53:17
  SPEAKER_1: They say that, "Hey, this problem costs me $1,000.
• 53:20
  SPEAKER_1: If you can do it for 900, it's a win for me."
• 53:23
  SPEAKER_1: Consumers are a lot more emotional or anchoring around this.
• 53:28
  SPEAKER_1: Different mental model.
• 53:29
  Also when looking at software they use,
• 53:32
  since software is now mainstream,
• 53:33
  it's not an early adopter phase.
• 53:35
  Everybody in the world or most of the population in the world uses software extensively.
• 53:41
  SPEAKER_1: A lot of the effect of consumerization in general, I think taking place.
• 53:46
  And I look a lot at inspiration of non-software categories of what that means.
• 53:52
  SPEAKER_1: And when you look at some of the success stories in shoes.
• 53:56
  I like to run so I specifically,
• 53:57
  I look at running shoes and there are new brands popping up and they are very
• 54:03
  opinionated about what they represent and what are their values.
• 54:08
  And because the objective performance isn't that difference between shoes
• 54:13
  or it's very,
• 54:13
  very hard to measure,
• 54:15
  consumers choose a lot more on which one they feel resonates with them or
• 54:20
  which is around them.
• 54:22
  SPEAKER_1: And again, software is becoming cheaper to create, right?
• 54:25
  SPEAKER_1: We have a small team, we can create a complex software.
• 54:27
  Other companies out there can do the same independent from the technology.
• 54:31
  SPEAKER_1: I build something in three months, anybody can probably build it.
• 54:36
  So it comes back to a lot around what you choose to put in front and what you
• 54:42
  choose to emphasize in your way of doing so.
• 54:46
  SPEAKER_1: With shoes that might be shapes, and forms, and colors.
• 54:49
  And in productivity tools it might be certain features or the way you access
• 54:53
  those features or the way you store your data,
• 54:55
  which are going to be very important for consumers.
• 54:59
  So I do see this thing,
• 55:00
  yes,
• 55:00
  of in personal software,
• 55:02
  you need to be a lot more opinionated.
• 55:04
  In B2B,
• 55:05
  think a lot less or big buyers will tell you what they need because they know
• 55:09
  what they need and you need to be able to fulfill that.
• 55:12
  That's why B2B softwares tend to become complicated because everybody
• 55:16
  needs something and you add 50 buttons and it keeps working because they have
• 55:20
  what they need.
• 55:21
  SPEAKER_1: In consumer I think it's personal software, it's different than that.
• 55:28
  What is Craft's opinionated or values or how does it come across in the app?
• 55:35
  You can also share if you want to,
• 55:37
  if you want to show some visual examples,
• 55:38
  because this is pretty visual as well,
• 55:40
  right?
• 55:41
  SPEAKER_1: It is visual, but you need to touch the product.
• 55:44
  I think this is kind of when we talk about our values,
• 55:47
  it's a lot about how Craft makes you feel.
• 55:50
  And I think all of the animation and the custom solutions all are built so we
• 55:54
  can fine tune how the software makes you feel.
• 55:57
  Because again,
• 55:58
  we believe a lot that the software you use every day will influence you.
• 56:04
  I think for this audience,
• 56:05
  a very good example could be,
• 56:07
  we're trying to build what Visual Studio Code is for engineers,
• 56:10
  but for knowledge workers in the sense of Visual Studio Code feels lightweight.
• 56:15
  After all of those super heavy IDs,
• 56:17
  which were non-expandable and slow and everything,
• 56:21
  Visual Studio Code was a fresher breath air,
• 56:23
  which you are just happy to be in because it's responsive,
• 56:27
  it's fast,
• 56:27
  it does everything you need integrated.
• 56:31
  And of course for non-technical people,
• 56:34
  they're slightly different angles.
• 56:35
  That's where animation,
• 56:36
  fluidness,
• 56:38
  visual customization makes a lot of sense.
• 56:41
  But that's how I could bring our type of position closer to this more
• 56:47
  engineering focused audience.
• 56:50
  SPEAKER_0: So you built Craft with a pretty small team.
• 56:54
  SPEAKER_0: Can you tell me how, what the size of the team is.
• 56:57
  And then also how many people build,
• 57:00
  for example,
• 57:00
  the iPhone,
• 57:02
  the Mac apps?
• 57:04
  SPEAKER_1: Yep.
• 57:04
  SPEAKER_1: So we have, our product engineering team is around 20 people.
• 57:09
  This includes product engineering,
• 57:10
  design,
• 57:11
  and QA,
• 57:12
  and we don't really have product.
• 57:14
  SPEAKER_1: So it's mainly design, engineering and QA.
• 57:16
  SPEAKER_0: Well, you are a product, no?
• 57:18
  SPEAKER_1: Well, kind of design.
• 57:19
  I think design has an overweight in product and of course I do product as well.
• 57:26
  SPEAKER_1: But then we have.
• 57:27
  SPEAKER_0: But just to confirm, you do not have a dedicated product manager role?
• 57:30
  SPEAKER_1: No, we do not have a dedicated product manager role, no.
• 57:33
  And we're split now in platform team,
• 57:36
  so this means we have a web team,
• 57:37
  a native app team,
• 57:39
  and a backend team.
• 57:39
  SPEAKER_1: And each of those teams are like three, four people.
• 57:44
  SPEAKER_1: That's kind of it.
• 57:46
  SPEAKER_1: We try to scale up but it didn't work out.
• 57:49
  I think one of our parts problems of scaling up is we try to be a lot more
• 57:55
  systematic and a lot less flexible.
• 57:58
  SPEAKER_1: And at the iteration speed we want to grow.
• 58:00
  I think our decision would have been either to grow fivefold and then we can
• 58:05
  reap the scalability benefits.
• 58:07
  But we ended up in this interim situation where we were neither flexible and
• 58:12
  fast enough,
• 58:13
  nor structured enough and it was kind of a bad place to be.
• 58:17
  So we find this around four up to five people platform teams,
• 58:22
  understand the context,
• 58:23
  are resilient,
• 58:24
  they can step in for each other,
• 58:26
  but can iterate very fast.
• 58:28
  And it also puts a constraint on us on how complicated infrastructure we are
• 58:32
  willing to build.
• 58:34
  Because of course if you build complicated stuff,
• 58:36
  maintaining that requires a lot of effort and we only want to do that if the
• 58:42
  trade-offs are very attractive.
• 58:43
  SPEAKER_1: Like it's something truly special that our users will really love.
• 58:49
  You're saying there's three or four people building the iOS app and then ...
• 58:53
  sorry,
• 58:54
  the whole code base,
• 58:55
  all four code bases,
• 58:57
  iOS,
• 58:58
  Mac,
• 58:58
  iPhone,
• 58:58
  and iPad.
• 58:59
  SPEAKER_0: And even a Vision Pro?
• 59:00
  SPEAKER_1: Yes.
• 59:00
  SPEAKER_1: Yes.
• 59:01
  SPEAKER_1: Yes.
• 59:01
  So on the native app side,
• 59:03
  people who are writing Swift code,
• 59:04
  it's only kind of three,
• 59:05
  four people.
• 59:07
  That's surprising to hear,
• 59:08
  but also I guess encouraging that it does work and can work.
• 59:12
  And you're saying that in your experience,
• 59:14
  the smaller team worked better than a somewhat larger team because of,
• 59:19
  was it communications overhead,
• 59:21
  iteration,
• 59:22
  disagreements,
• 59:23
  what made it more challenging?
• 59:25
  So what happens is when you have a team over five people,
• 59:29
  the communication starts to break down.
• 59:31
  SPEAKER_1: So then you ideally want to split it to two teams.
• 59:34
  And what we did at the time is we had more than five people in each platform.
• 59:39
  So we said,
• 59:39
  let's move to feature teams,
• 59:41
  typically,
• 59:42
  what companies refer to it?
• 59:44
  So each team has a specific goal,
• 59:45
  they work on a specific feature,
• 59:47
  they execute on that.
• 59:48
  But we lost those holistic capabilities of everybody having full access to a
• 59:55
  full code base.
• 59:56
  If you get what I mean,
• 59:57
  of what I showed,
• 59:58
  if you want to create a focus mode,
• 1:00:00
  it's super easy because you just go down to the route and change that and it works.
• 1:00:05
  And also these teams being not having sufficient team members from the same
• 1:00:12
  platform while you're working on that,
• 1:00:14
  slowed it down a lot.
• 1:00:16
  So we noticed that a fellow iOS engineer can help a fellow iOS engineer better
• 1:00:21
  than a fellow web engineer,
• 1:00:22
  backend engineer.
• 1:00:23
  And that is what creates these very clever solutions when multiple people
• 1:00:29
  from the same domain have different ideas and they do understand the
• 1:00:33
  business context.
• 1:00:33
  We're providing a lot of context and we really focus on every team fully
• 1:00:37
  understanding that.
• 1:00:38
  But then they can really understand their technological limitations and
• 1:00:42
  how they can come through that,
• 1:00:44
  which for us increases velocity a lot.
• 1:00:48
  And the composition of the team is mostly,
• 1:00:52
  so if I understand,
• 1:00:53
  mostly it will be of those 15-ish engineers,
• 1:00:57
  about four or five backend,
• 1:00:59
  and the rest will be mobile front-end focus.
• 1:01:03
  SPEAKER_1: Yes.
• 1:01:04
  Which is interesting because it's usually,
• 1:01:06
  again,
• 1:01:06
  for most companies,
• 1:01:09
  even mobile-focused companies,
• 1:01:10
  it's usually the other way around.
• 1:01:12
  SPEAKER_0: At Uber, there were more backend engineers than the mobile engineers.
• 1:01:16
  SPEAKER_0: So an interesting twist, but I'm glad that it's working.
• 1:01:19
  SPEAKER_0: It clearly is.
• 1:01:21
  Now,
• 1:01:21
  what advice would you give to front-end or mobile engineers who are really
• 1:01:25
  passionate about what they do?
• 1:01:26
  They love the craft,
• 1:01:27
  they love building these things,
• 1:01:29
  but they do feel a bit stuck both professionally,
• 1:01:33
  they're just not getting ahead.
• 1:01:34
  SPEAKER_0: The next promotion will not be them.
• 1:01:36
  They will unlikely to be the team lead or if they want to go into engineering leadership,
• 1:01:42
  it looks really hard.
• 1:01:44
  What could they do to be taken potentially more seriously and to be able to
• 1:01:50
  take this front-end and user focus into a bigger organization and to have a
• 1:01:56
  larger impact?
• 1:01:58
  SPEAKER_1: Yeah.
• 1:02:00
  So it's very hard for us,
• 1:02:01
  again,
• 1:02:02
  front-end engineers to talk about if I do this project,
• 1:02:04
  we're going to save a million dollars.
• 1:02:06
  SPEAKER_1: It's just not possible to articulate in that sense.
• 1:02:10
  SPEAKER_1: So it's a lot about how it makes people feel.
• 1:02:14
  Now the thing I do,
• 1:02:16
  I still do this as CEO today a lot is what I call building prototype apps.
• 1:02:21
  SPEAKER_1: And I put it in the hand of decision makers.
• 1:02:24
  When I was at Skyscanner,
• 1:02:25
  I put it in the hand of the CEO,
• 1:02:27
  the VP engineering and showed him of this is what we could have,
• 1:02:30
  touch it,
• 1:02:30
  feel it.
• 1:02:31
  SPEAKER_1: Do we want to have this and do we want to do it this way?
• 1:02:35
  SPEAKER_1: And then these are the costs around that.
• 1:02:37
  And it's of course a limited prototype,
• 1:02:38
  but it's good enough so they feel the value rather than just trying to
• 1:02:43
  objectively describe that value into that.
• 1:02:46
  And of course,
• 1:02:46
  it always helps if you have backup studies,
• 1:02:48
  like when you press something and it appears in 3 millisecs versus 10 millisecs,
• 1:02:52
  there are writings there that every millisecond that you decrease in terms
• 1:02:56
  of response timing increases conversion by 0.2%.
• 1:02:59
  SPEAKER_1: So there are these type of things as well.
• 1:03:03
  But I think it's because the whole,
• 1:03:05
  our goal is to interface with people,
• 1:03:08
  the only way we can explain even to very senior decision makers is so they can
• 1:03:14
  experience it.
• 1:03:15
  Usually,
• 1:03:15
  these senior decision makers are very good at identifying patterns and
• 1:03:19
  looking at what they're just going through.
• 1:03:22
  SPEAKER_1: That is for me, as always, of don't talk about it.
• 1:03:25
  SPEAKER_1: Build a small prototype and show it in the way where it's not a video.
• 1:03:29
  SPEAKER_1: That they can, on their own device, touch it and use it.
• 1:03:33
  SPEAKER_1: And you'll see a vastly different response.
• 1:03:35
  So I have this so often with the design team,
• 1:03:37
  if I mock up something,
• 1:03:39
  I send it to them,
• 1:03:39
  they're like,
• 1:03:40
  "Ah,
• 1:03:40
  no,
• 1:03:40
  it'snotgoingtowork."
• 1:03:41
  Versus I just build a small prototype,
• 1:03:43
  give it to them and they're like,
• 1:03:44
  "Oh my god,
• 1:03:44
  there'ssomethingspecialhere."
• 1:03:47
  SPEAKER_1: So that is, for me, buy-in has always been about show, not tell.
• 1:03:52
  SPEAKER_1: And by the way, I acquire so many interesting skills while doing so.
• 1:03:58
  I think,
• 1:03:58
  nowadays,
• 1:03:59
  specifically when picking up new things,
• 1:04:02
  AI and LLMs can speed up this exploration process a lot so I become faster in
• 1:04:07
  building prototypes.
• 1:04:09
  SPEAKER_1: And that is my number one advice actually is again, show not tell.
• 1:04:15
  Speaking of AI,
• 1:04:18
  gen AI,
• 1:04:18
  how do you use it and how do you think front-end engineers,
• 1:04:23
  mobile engineers,
• 1:04:24
  people building,
• 1:04:25
  visual stuff should use it?
• 1:04:27
  SPEAKER_0: Because I do hear some hesitation.
• 1:04:30
  SPEAKER_0: It's never going to be the Craft that I can do.
• 1:04:33
  SPEAKER_0: It just spits out the boilerplate like, nah, shouldn't bother.
• 1:04:37
  SPEAKER_0: There's some of those.
• 1:04:38
  Yeah,
• 1:04:39
  I think a lot of companies,
• 1:04:41
  they don't want to be the top 1% of design.
• 1:04:43
  SPEAKER_1: They want to be the top 25.
• 1:04:45
  SPEAKER_1: And I think that's where AI cogeneration is good enough.
• 1:04:49
  SPEAKER_1: But in the recent months, I've had some very serious breakthroughs.
• 1:04:53
  And I'll tell you one example is in Craft,
• 1:04:56
  we have this capability where the Apple Pencil,
• 1:04:58
  you can sketch and draw a circle,
• 1:05:01
  but it's not going to be a perfect circle because you're drawing by hand.
• 1:05:05
  And we wanted to add something called shape recognition where we can detect
• 1:05:09
  if it's a circle.
• 1:05:10
  Now,
• 1:05:11
  this is a quite complex problem because it essentially has three stages from
• 1:05:14
  the point data creating shapes,
• 1:05:16
  from the shape estimating what it could be,
• 1:05:20
  and then replacing that.
• 1:05:22
  SPEAKER_1: And I think the latest reasoning models are very good at that.
• 1:05:25
  SPEAKER_1: I know nothing about these maths.
• 1:05:27
  And previously,
• 1:05:28
  I shied away of this problem because I estimated it's one or two weeks of my
• 1:05:31
  time and last weekend in three hours I had an end-to-end solution.
• 1:05:38
  SPEAKER_1: What it gave to me was topics I don't understand about.
• 1:05:44
  So if I were expert in this maths field,
• 1:05:46
  I probably would have been able to write it in three hours myself,
• 1:05:49
  but I wasn't.
• 1:05:51
  And just being able,
• 1:05:53
  it not just giving me an algorithm,
• 1:05:54
  but I could iterate with it of saying,
• 1:05:56
  "Hey,
• 1:05:56
  this one doesn't work for the rectangle,
• 1:05:58
  try another algorithm,
• 1:05:59
  orthisoneisn'tforthetriangle."
• 1:06:01
  SPEAKER_0: So just to be clear, you were talking with an LLM.
• 1:06:04
  If you could tell us which one,
• 1:06:06
  on how to build this code that could do an algorithm that would roughly
• 1:06:12
  recognize the shape and then turn it into an actual shape?
• 1:06:15
  Well,
• 1:06:16
  so this was the new o1 model from ChatGPT and actually didn't go to that depth.
• 1:06:21
  I told him I'm a developer at Craft,
• 1:06:24
  I use PencilKit,
• 1:06:25
  which is the framework,
• 1:06:28
  and I want to do shape recognition similar to the Apple Notes app,
• 1:06:31
  what it does.
• 1:06:31
  This was the prompt I gave and it gave me a very interesting solution,
• 1:06:36
  which I needed to iterate on a lot like an engineering architect saying,
• 1:06:40
  "I like this layer,
• 1:06:41
  but this layer seems to fail because I've been debugging in the meanwhile" so
• 1:06:45
  there was a lot of thinking there.
• 1:06:47
  But this was the first time where I said AI helped me not just to be 20% faster,
• 1:06:52
  but in this problem,
• 1:06:53
  it made me 10 times faster.
• 1:06:56
  And I don't know how reproducible this will be,
• 1:06:58
  but for me,
• 1:06:59
  these are the things where...
• 1:07:00
  Another example is we're now playing a lot with shader codes because shader
• 1:07:05
  code is very mathematical,
• 1:07:07
  very much like assembly.
• 1:07:08
  It's very hard for even engineers like me to write,
• 1:07:13
  but AI can help us write it,
• 1:07:15
  which can again open up a new dimension to how we present things.
• 1:07:19
  And it's a lot about the capabilities I did not have before I now have access to,
• 1:07:25
  for me,
• 1:07:26
  when it comes to AI.
• 1:07:27
  And also,
• 1:07:27
  I think a lot of us in our team,
• 1:07:29
  our backend engineers now can create prototypes with UI,
• 1:07:32
  and the UI isn't that good,
• 1:07:34
  butit'sgoodenoughtoshowcasewhattheywanttoshowcase
• 1:07:38
  SPEAKER_0: And to close it off, you're still very hands on, right?
• 1:07:43
  SPEAKER_0: You write a lot of code.
• 1:07:47
  SPEAKER_1: There's two things there.
• 1:07:48
  One is at my time at Skyscanner where I've been at this product director
• 1:07:53
  leadership role,
• 1:07:55
  I really missed being close to what I call the metal or the product.
• 1:07:59
  So for me,
• 1:08:00
  I realized that I get a lot of intuition and positive re-encouragement from
• 1:08:07
  being able to do things,
• 1:08:09
  see a user feedback and act on it.
• 1:08:12
  And if I don't have this when I get too far and maybe not ready yet or not mature
• 1:08:17
  enough for what they call delayed gratification,
• 1:08:20
  I like being there.
• 1:08:21
  SPEAKER_1: That's one thing.
• 1:08:22
  SPEAKER_1: The other thing I think I am still quite good at it.
• 1:08:27
  So I think I have special skills,
• 1:08:28
  which would be very hard to acquire in the market.
• 1:08:31
  And for me,
• 1:08:32
  having that ability of being able to connect deeply product,
• 1:08:35
  engineering and design,
• 1:08:36
  because I also do a lot of design,
• 1:08:39
  it helps me to think through problems and work with each individual domain to
• 1:08:44
  steer them towards,
• 1:08:45
  I'd say,
• 1:08:45
  a more efficient or more pragmatic solution.
• 1:08:49
  SPEAKER_1: Finding those spots.
• 1:08:50
  And I'm getting a lot of criticism of as a CEO,
• 1:08:52
  this should not be your job.
• 1:08:54
  And I get for a lot of CEOs,
• 1:08:55
  this is not part of their job,
• 1:08:57
  but the team is okay.
• 1:09:00
  I don't know if they like or dislike,
• 1:09:01
  but they're okay,
• 1:09:02
  me working with this way and I enjoy it a lot and I feel I'm doing a lot of things
• 1:09:09
  that make the product better and me more satisfied.
• 1:09:13
  SPEAKER_0: I mean, this is the benefit of doing your company.
• 1:09:16
  There's a lot of risks to it,
• 1:09:17
  but if you're working within an existing organization,
• 1:09:23
  you need to take whatever their priority is and do the stuff that they're
• 1:09:28
  assigning you.
• 1:09:29
  SPEAKER_0: Obviously, there's freedom, but not always.
• 1:09:33
  And to wrap up,
• 1:09:34
  we'll do some rapid questions so I'll just shoot and then you'll answer.
• 1:09:38
  SPEAKER_0: What's your favorite programming language and why?
• 1:09:41
  SPEAKER_1: So I would say Swift, but I think it's actually Objective-C.
• 1:09:47
  I hate Objective-C syntax,
• 1:09:49
  but compilation speed for me is super important and Objective-C code just compiles.
• 1:09:56
  SPEAKER_0: It's a lot faster, isn't it?
• 1:09:56
  SPEAKER_1: Super fast so yeah.
• 1:09:58
  SPEAKER_0: Several times faster.
• 1:09:58
  SPEAKER_0: I mean the way it works, right?
• 1:09:59
  SPEAKER_0: There's not many type checks and all those things.
• 1:10:02
  SPEAKER_1: Yeah.
• 1:10:03
  SPEAKER_0: What is the best design tool that developers might also want to use?
• 1:10:07
  SPEAKER_1: I design in code so I don't use design tools at all.
• 1:10:11
  SPEAKER_0: You don't use design tools?
• 1:10:13
  SPEAKER_1: No.
• 1:10:13
  I use very high-level sketching,
• 1:10:16
  but it's really just like rectangles and things like that.
• 1:10:21
  I go directly to code because I think,
• 1:10:24
  again,
• 1:10:24
  we're talking about drawing rectangles and that's quite fast to type rectangles,
• 1:10:29
  so I do it directly in code.
• 1:10:31
  So for me,
• 1:10:31
  I really love,
• 1:10:33
  by the way,
• 1:10:33
  Tailwind CSS because that I think with Visual Studio Code and Hot Reload,
• 1:10:38
  that is the fastest prototyping tool I have seen.
• 1:10:42
  And I think,
• 1:10:43
  for me,
• 1:10:44
  it's very natural the way you can express yourself there.
• 1:10:47
  SPEAKER_0: That's awesome.
• 1:10:48
  SPEAKER_0: I didn't think of it as a prototyping tool, but I guess, yeah.
• 1:10:50
  SPEAKER_0: It is a really efficient way of doing stuff.
• 1:10:54
  SPEAKER_0: And what are one or two books that you read and would recommend?
• 1:10:58
  So one of the very,
• 1:11:00
  it's not engineering,
• 1:11:01
  but in some ways it is,
• 1:11:02
  is there's Ben Horowitz wrote this Hard Thing About Hard Things book,
• 1:11:07
  and it's been super interesting for me because a lot of the things,
• 1:11:12
  how it talks,
• 1:11:12
  for instance,
• 1:11:13
  about something called management depth,
• 1:11:15
  which is working with people who aren't working out and how he compares that
• 1:11:19
  to tech depth.
• 1:11:20
  So what that taught me is how my experience in engineering with coding and
• 1:11:25
  engineering systems can often be translated to human systems when people
• 1:11:31
  work together.
• 1:11:31
  I'm not sure if you look at that as a bad or a good thing,
• 1:11:34
  but it's very interesting in helping me understand of these mental models
• 1:11:39
  live more and traverse across your immediate domain.
• 1:11:43
  SPEAKER_0: Awesome.
• 1:11:44
  Well,
• 1:11:45
  thanks for sharing this less conventional way of developing software,
• 1:11:51
  developing opinionated software,
• 1:11:53
  and also showing a little bit of behind the scenes of how in the end,
• 1:11:58
  it's all code and reminding us engineers,
• 1:12:01
  especially front-end engineers,
• 1:12:02
  you shouldn't be afraid of it.
• 1:12:03
  SPEAKER_0: This is great.
• 1:12:04
  SPEAKER_1: Really enjoyed it.
• 1:12:05
  SPEAKER_1: And yes, thank you very much.
• 1:12:07
  SPEAKER_0: I hope you enjoyed this pretty unique episode with my brother, Balint.
• 1:12:10
  I'm still amazed at how small teams can get so much done and how competent
• 1:12:14
  teams frequently can ignore best practices like using operating system
• 1:12:17
  level components.
• 1:12:18
  You can check out Craft and connect with Balint in the links listed in the show
• 1:12:21
  notes below.
• 1:12:22
  SPEAKER_0: For related to Pragmatic Engineer deep dives, also see the show notes.
• 1:12:25
  If you enjoyed this podcast,
• 1:12:27
  please do subscribe on your favorite podcast platform and on YouTube.
• 1:12:30
  SPEAKER_0: This helps more people discover the podcast.
• 1:12:32
  SPEAKER_0: Thank you if you leave a rating.
• 1:12:34
  SPEAKER_0: Thanks and see you in the next one.