# Design-first software engineering: Craft – with Balint Orosz

An episode of [The Pragmatic Engineer](https://invisiblenetwork.ai/podcast/1769051199), 5 Mar 2025, 1 h 13 min.

Audio: https://api.substack.com/feed/podcast/158345077/b28a5a6cda08faff1af44fa5c67be9d7.mp3

Supported by Our Partners • WorkOS — The modern identity platform for B2B SaaS. • The Software Engineer’s Guidebook: Written by me (Gergely) – now out in audio form as well • Augment Code — AI coding assistant that pro engineering teams love — Not many people know that I have a brother: Balint Orosz. Balint is also in tech, but in many ways, is the opposite of me. While I prefer working on backend and business logic, he always thrived in designing and building UIs. While I opted to work at more established companies, he struck out on his own and started his startup, Distinction. And yet, our professional paths have crossed several times: at one point in time I accepted an offer to join Skyscanner as a Principal iOS Engineer – and as part of the negotiation, I added a clause to my contrac that I will not report directly or indirectly to the Head of Mobile: who happened to be my brother, thanks to Skyscanner acquiring his startup the same month that Skyscanner made an offer to hire me. Today, Balint is the founder and CEO of Craft, a beloved text editor known for its user-friendly interface and sleek design – an app that Apple awarded the prestigious Mac App of the Year in 2021. In our conversation, we explore how Balint approaches building opinionated software with an intense focus on user experience. We discuss the lessons he learned from his time building Distinction and working at Skyscanner that have shaped his approach to Craft and its development. In this episode, we discuss: • Balint’s first startup, Distinction, and his time working for Skyscanner after they acquired it • A case for a balanced engineering culture with both backend and frontend priorities • Why Balint doesn’t use iOS Auto Layout • The impact of Craft being personal software on front-end and back-end development • The balance between customization and engineering fear in frontend work • The resurgence of local-first software and its role in modern computing • The value of building a physical prototype • How Balint uses GenAI to assist with complicated coding projects • And much more! — Timestamps (00:00) Intro (02:13) What it’s like being a UX-focused founder (09:00) Why it was hard to gain recognition at Skyscanner (13:12) Takeaways from Skyscanner that Balint brought to Craft (16:50) How frameworks work and why they aren’t always a good fit (20:35) An explanation of iOS Auto Layout and its pros and cons (23:13) Why Balint doesn’t use Auto Layout (24:23) Why Craft has one code base (27:46) Craft’s unique toolbar features and a behind the scenes peek at the code (33:15) Why frontend engineers have fear around customization (37:11) How Craft’s design system differs from most companies (42:33) Behaviors and elements Craft uses rather than having a system for everything (44:12) The back and frontend architecture in building personal software (48:11) Shifting beliefs in personal computing (50:15) The challenges faced with operating system updates (50:48) The resurgence of local-first software (52:31) The value of opinionated software for consumers (55:30) Why Craft’s focus is on the user’s emotional experience (56:50) The size of Craft’s engineering department and platform teams (59:20) Why Craft moves faster with smaller teams (1:01:26) Balint’s advice for frontend engineers looking to demonstrate value (1:04:35) Balint’s breakthroughs using GenAI (1:07:50) Why Balint still writes code (1:09:44) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • The AI hackathon at Craft Docs • Engineering career paths at Big Tech and scaleups • Thriving as a Founding Engineer: lessons from the trenches • The past and future of modern backend practices — See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast — Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com.…

## Transcript

[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:01] $2 million on infrastructure cost or scale to a billion users.
[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: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:46] 0,
[20:46] 0 coordinate.
[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: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.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.