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

Episode Date: March 5, 2025

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 [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

So how do you find it being different, being both a founder with a lot more, should I say design focus, user focus, mobile focus? True engineers or hardcore engineers didn't really find me to be one of them. But then designers, product managers or others, they didn't find me to be one of them either. So you end up in this in-between period of you do a lot of engineering. They respect what you do, but somehow because my focus has never been on distributed systems, scalable algorithms, a lot of things. The innovation I bring to a team means that clicking on a button will take two milliseconds instead of 10 milliseconds.

Back-in the engineers will say they just save $2 million on infrastructure cost or scale to a billion users. My love for creating user-facing experience has kept me going and going on this path. Many people who started next to me who ended up moving a lot more toward back-end distributed systems, scaling, you know, engineering. That's where they thought and they found hard problems to be. Kraft is one of the most delightful text editors and an app that has previously received Apple's Mac app of the year award. I happen to know this app really well because its founder is my brother, Baden Taurus. Bind is probably the exact opposite of me. He's a designer at heart and is as good as someone can get him building amazing apps.

Today we talk about why it's hard to fit in as a design first engineer or engineering leader at most tech companies. Unique engineering decisions behind Kraft, like using custom components instead of the native iOS and Mac ones, and not using auto layout. How Kraft built an editor where everything animates, but nothing is jumping, and many more interesting topics like how most companies get design systems wrong and how to make local first software work well. If you're interested in how beautiful and highly opinionate software is built with a small team,

this episode is for you. If you enjoyed the show, please subscribe to the podcast on any podcast platform and on YouTube. Thank you. This really helps the show get to even more listeners and viewers. This is a very rare and special episode. especially that I only have one brother. So, so, Bading, first of all, welcome to the podcast. Thanks for having me.

So one of the topics that one of the reasons you're here is, recently I reflected on something interesting, how most CTOs that I know, and even most founders at tech companies, they're very back-end oriented. Their background typically, you know, they've been in engineering for 10 plus years. It's usually very back-end heavy. And this leads to a lot of interesting things.

Their approaches will prefer back in engineering approaches. For example, they'll often focus heavily on unit testing, automated testing, and so on. But what I've not really seen is a kind of more mobile, UX, design focused founder and especially engineering executive. And I have seen this with you because you're a lot more in this direction. And the two of us are pretty different. If I had to put myself, I'm form more of this back-end preference. And even when we did projects together many, many years ago, I was writing the unit test and the business logic,

and you were doing the front and side of things. And you still say it here. So how do you find it being different, being both a founder, previous you were an executive at SkyScanner with a lot more, should I say design focus, user focus, mobile focus? what would a good way to be to put it? Yeah, so, you know, I've been writing code, as you know, since I've been 12. But, you know, always when I've been writing code, my main goal was to put something on the screen

and to be able to interact with that. So for many people, it's... We can probably note the first few programs that you wrote, those were, you know, games, right? Yeah, they were games and visualization of graphs and... And I focused a lot on time on, you know, making sure the graph is drawn in an animated fashion. So those were always the very, very interesting parts for engineering for me. And this also led me to a number of different techniques over the time. For instance, utilizing Flash a lot.

I think Flash was a very interesting way of how code and design co-lived in the same tool and allowed a very strong creative expression. and I always tended to look at computers as an opportunity to draw on a canvas, right? You know, draw on your screen. Particularly as myself, I've never been able to draw by hand. Well, I always looked at how computers can enable me. And I think this was a very interesting way because despite being an engineer for such a long time in writing so many code, I always felt that true engineers or hardcore engineers didn't really.

find me to be, you know, one of them. But then, you know, designers or, you know, product managers or others, they didn't find me to be one of them either. So, so you end up in this, in the same between period of you do a lot of engineering. They respect what you do, but somehow because my focus has never been on distributed systems, scalable algorithms, you know, a lot of the innovation I, for instance, bring to a team means that clicking on a button will take two milliseconds instead of 10 milliseconds, while backend engineers will say they just save $2 million, you know, on infrastructure cost or, you know, scale to a billion users. And I think my love for creating user-facing experience has kept me going and going on this path. But I've seen many people who started next to me

who ended up moving a lot more towards, you know, back in distributed systems. them scaling, you know, engineering because that's where they thought and they found hard problems to be. And also, it's a lot in big companies, how competency frameworks, promotion, you know, structures are oriented towards those areas where it's a lot easier to validate the impact you've been doing because it's a lot more measurable. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine grade authorization. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app.

Their APIs are easy to understand, and you can ship quickly and get back to building other features. WorkOS also provides a free user management solution called OffKit for up to 1 million active users. It's a drop in a replacement for Alt Zero and comes standard with useful features like Domain Verification, Rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Versel, and Perplexity. Check it out at WorkOS.com to learn more.

That is WorkOS.com. Before we jump back into the episode, I want to let you know that the audiobook version of my best-selling book, the Software Engineers Guidebook, is out now. You can get it on all major audiobook platforms like Spotify, Audible, Liberal.fm, Applebooks, to Google Play, and also DRM-free mp3 files. I started writing this book after a decade of working as a software engineer when I was working as an engineering manager for a few years already at Uber. Here's a review from the book from Senior Principal Engineer Tanya Raley,

who is the author of the staff engineer's path. From performance reviews to P95 latency, from Team Dynamics to Testing, Gary Davisifies All Aspects of a Software Career. This book is well named. It really does feel like the missing guidebook for the whole industry. You can get the book at EngGuidbook.com or search for the Soverex Guidebook on your favorite audiobook platform. I hope you'll enjoy it. Can we talk about this for a second?

Because, you know, your path, like our path could have not been more different. You know, just to recap, like, you know, both of us went to university, right? Like, we actually went to the same university. I'm the older brother, so I was two years basically ahead. And then both of us did some side projects on the side. We actually did some side projects together, which was kind of fun slash interesting we built. some apps. And then when we came to graduation, I went into the workforce. I kind of, you know, went as an employee as a new grad to a consultancy, then a larger company and then, you know,

like even bigger companies in the end of it, but Uber. You started off as an entrepreneur to start with. You started off your startup. It was a small startup, then a mid-sized startup, and then it got acquired by a SkyScanter. And then you became a director of engineering. Yeah, it was head of app product, essentially. Head of app products. So you had like, you went from like a two-person startup or three-person startup to a 30-person startup, acquired and boom, you're inside a thousand-person company. So you said that it was kind of hard to get recognition.

And I'm interested in what happened, you know, this was clearly at SkyScanner. You came in as, you know, you went from running your startup to an executive. You know, you were now so some very important. Funny enough, we later both worked there. I was like levels below you. But what did this mean in terms of, you know, like having a little bit struggle to, you know, get recognized the same way as your kind of back and pierced it? So it was very interesting on that side of things because there were two phases, you know,

being at skyscran. I think the first part was our acquisition was mainly driven by the frustration or, you know, the desire to build a really amazing mobility. experience. So this was 2014. Mobile was on the rise. And the leadership at SkyScanner, which was a founder-driven leadership, you know, clearly said we need to be very, very good at mobile. At the same time, there was an understanding couple there that they are a web first company. You know, the entire generation of leadership was born in Web and they need a different perspective who can propel them in that mobile first future. So this meant kind of in the first year, it was a lot about just do whatever

you want to do. And in the second year, I think things a little bit changed because there was a new wave of leadership coming in from Amazon, Microsoft, Facebook, other, you know, larger institutions. And the primary goal of that leadership was to help scale the organizational structure of SkyScanner, you know, to make it a world-class engineering team. And I think this was where we're very interesting things, you know, started to happen in terms of agreements, disagreements, you know, what is important, what is not important, senior architects coming in, you know, setting up metrics and, and, you know, trying to measure output and performance in ways that I didn't feel are the right way to measure those things. It was interesting because I've been pushing back a lot. And I think the moment I

start having deeper discussions with the engineering leaders, again, you know, very, very senior or ones coming from big companies, I think there was a realization of, oh, my God, this is an area I am completely unequipped to deal with. So for now, I won't go super deep inside of that. But eventually, I think a lot of the behaviors through, again, competency frameworks, you know, measurement of throughput,

you know, general engineering principles and treating the engineering organization as which needs to work along the same set of principles, every engineer, propagated into, the app team and the organization as well, which led to a lot of different things on how we viewed performance, how we looked at throughput, and who was seen as someone worthy of a promotion. Yeah, so in Indian, you learned the big company ways. Yes, yes, and I learned tons. And for me, it was an amazing educational experience because

I've seen a lot of things. And I think I could really build up because of this a lot more solid understanding of what I believe is right. More likely what I believe is right should always be dependent on the context. So I got a lot more grander understanding of there's no right way of doing things. There are certain problems which have certain ways of solving them. Yeah, although I remember when, you know, earlier, before you joined Skysian, you were a lot more straight. You're like, no, this is the only way. This is the only way that we can do that. But you never lost that. You mentioned one thing that both of us were a sky scanner for a short time, a different organization, made sure I didn't report into your organization and indirectly to you. But I remember that there was always a focus whenever I went over about like, you know, when we talked about like mobile development, like with you or people on your team, it wasn't really about the usual stuff, you know, like cold quality unit test coverage.

the CICD build times. It was about user experience. How smooth does it feel? How fast is it? How many taps do you need? So you kind of kept this focus, even as you started your next startup, right? That was a mobile iOS first startup craft, craft docs. And by that time, you've seen in both.

You've seen the back end. What did you decide to bring in from day one from engineering on how you've built this startup from scratch. Yes, so I think the biggest takeaway I had there is there, if you want to create a really amazing product, you cannot really have one engineering culture inside of the company. And this is very interesting, right? Because when we look at, for instance, companies like Apple, they are a very, you know, UI first engineering culture, if you'd like.

but their backends and their web services and, you know, all of those are terrible. And then you look at Amazon and Google, who are, you know, very strong, you know, system design and, you know, back and engineering principle driven companies. They cannot seem to create, you know, meaningfully good or fluent, you know, UI experiences. Of course, you know, by the measurements they are there, but when you use them, they still don't feel concrete. And what I thought at the time specifically as we've been creating a piece of software that was, meant to be used hours a day. Like, you know, even today it's used, you know, our average users use it two, three hours a day that you just cannot compromise, right?

You need to make it feel very fluent. But we are dealing with data, important data in terms of, you know, what you're writing, how you're thinking, which needs to be synchronized seamlessly, very fast, you know, local first. So I think this was the first thing where I said of, we're going to have engineering principles for areas that touch data, right? because we need to ensure there's zero data loss. We need to ensure those are very fast, super efficient, you know, anytime we can switch parts.

And we don't really need to innovate there, if you know what I mean. I mean, we need to refine a lot of things, but it's something that with the right approach, we should be able to measure, iterate, and work on. And then there's the using-facing part of the things where, you know, what we set out to do is essentially we start creating a hyper-referencing, text editor for mobile. Now a hypertext editor even on the desktop is fairly complicated. You know, there's no very strong established patterns. It's not like, you

know, a shopping cart where it's very trivial what you need to do. So I knew it's going to require a lot of iteration and a lot of, you know, resets and figuring things out. And and that's where I didn't feel that established engineering patterns in the standard way of, you know, testing things, code coverage, you know, building, you know, even design components when, you know, tomorrow it might not be needed will be the right approach to that. So, so this was, I think, the approach of it came out with as neither is better than the other, right? You know, it's not, I'm not saying that, you know, one type of engineering is better than the other, but these can actually very well complement each other.

it brings an organizational complexity of the question of, okay, but what is engineering then? Is engineering them one domain or two domains? Or do we call front-end dangerous design engineers and have them compensated differently? But I felt very strongly about this coming out from there. So maybe let's start with the actual architecture of the app. Like when you started out, I remember, like, you knew I want to build an iOS app, which is going to be, you know, like you can take notes, you can use it, you can do whatever. You know, it's like every node plus plus or just a lot better than what existed.

And obviously, you already knew at that point that there's going to be an iPad app at some point. There's going to be Mac app, maybe a web app. What most teams would have done is you build an iOS app, you then build a Mac app, you build a web app. Okay, the iPad, I guess it might be the same code base. So you now have three code bases. And most teams would have just used, you know, existing native components. What did you do and why? Yeah, so I'm, you know, quite radical in terms of believing that actually everything we're doing today in front-end engineering, people could do maybe even better 20 years ago.

So, you know, when you look at the complexity of tools of, you know, Photoshop or, you know, just, you know, even when I look at just Visual Studio, right, you know, 20 years ago, how complex it was and, you know, how well it worked. But sometimes I even go to these stores where they have these DOS space, you know, blue screen windowing management solutions with all the keyboard shortcut QIs. So it's kind of a thing where I don't feel that there has been a significant improvement in terms of our ability to produce, you know, user interfaces. There's somehow, you know, we still try to figure out how to make them, but there hasn't been a significant complexity shift. For me, what was always, though, really, really important is whenever I have an idea, be able to execute on it.

And typically what happens is the closer you are to the core language pattern or the core framework elements, the bigger control over you have what you want to do. For instance, if you can create shade or code, you can create any type of, you know, very beautiful visual effects. if you want to, despite anything else. So for me- And just to a clear shaders, for those who are not listening, this is what renders like 3D or even 2D things on the screen and it basically runs on your GPU, right? And for me, I think this was the driving factor of I

wanted to have that freedom and flexibility, even if that comes with some sort of complexity later, because that will allow me to find the right solutions for the problems I have rather than being constrained. And there's another other important thing is, the more high-level abstractions and frameworks you use, the more time you spend figuring out the bugs and the things that those frameworks are good at

and allow or disallow versus actually building the things. So it's almost like there's, like, Alt-Tool Layout is a very good example, which Apple introduced in 2013-14, I think, you've been, you know, one of the early adopters of auto layout inside of SkyScanner, which problem is you no longer need to think in rectangles, right? You no longer need to specify that this label goes in this rectangle. You can just say it should be at the top. The problem happens then is, you know, it's very easy for one label,

but when you keep adding more things, the complexity increases. So when you want to do something more sophisticated, it can become very performance intensive or you change one thing and the other change starts to fall apart. So for those who don't know iOS and auto layout or how layouts work, could we just explain? Like, well, this isn't why auto layout was a big deal for developers and then, you know, the tradeoffs. Yep.

So, you know, back in the days, you know, an iOS generally has this principle coming back from of it gives you a canvas which you can draw on, which comes with a lot of advantages, but the other disadvantages is you don't think of components of a stack. Let's say where you just pack things in stack, like in the web browser, but you say, I want this view to be on the X, Y, 0,0 coordinate, and I wanted to have a width of 200 pixels and a height of 100 pixels. And this worked very well because early iPhones had all the same sizes. Right.

I think the iPhone... The same resolution, right? The same resolution. And I think the iPhone 4 or 5 was which, you know, became bigger. And that's where essentially you would have to start defining rectangles of, I want this rectangle to be the width, which is 20%. less wide than the enclosing container. And that's where Apple said, why don't we do something more elegant,

where you just specify, you know, this should snap in the middle, and it can, you know, automatically magically grow. And what happens here is the layout engine calculates all of these runtime. So you have a more abstract syntax that is easier, you know, to understand and define. But when it comes, for instance, to animations, to edge cases, you lose control because all of these dynamic you calculated things will end up with something. So it's a lot more implicit way of defining how you want things to look rather than being very explicit about this is exactly what I expect you to do as a layout element. Yeah. So you're trading off a lot easier to define and work with as a developer and more complexity on the device and just less control when you want to do.

do more advanced of, as you mentioned, animations. And in the release, it could feel jerky, laggy. Sometimes it would like go up and down, up and down, up and down. But they fix that part, right? Well, they didn't. They didn't. Because still when I run, you know, simulators, you know, Apple error messages coming from their internal components of, you know, the compiler couldn't figure out the layout.

So it's just, you know, falling back to something else. So there's always the more complex that you add in, your slave of what that engine can do. You're a slave of what it can. resolve and you know the more complex it gets the less likely it can resolve it in a in a reasonable set of time it got better but i still think it's it has you know significant challenges inside of it so you you never opted into it right you always said like let me choose the complexity and just to keep control no it this isn't the story so every time we hire an ios engineer they're like you guys are ancient right why don't you use these new technologies for a while it was all to lay out

now with swift ui and what i always do was I showed them one of our transitions and say, if you can do this with the same performance in Alto Layout, we're switching to Auto Layout. And I've done this at least 10 times, and they're always like, yeah, sure, like hell, I can. Some of them even succeed, but then when you look at the code and I tell them, OK, but now change this to that,

and they're going away for two weeks, and they still couldn't figure out how to change that. I'm like, you know, here that was two minutes to do. That's when I say, OK, this technology is not for us. So it's not about resisting things. It's about what I said, does it limit our capability to innovate? And does it limit our capability to express things in a reasonable time frame? Versus does it, you know, feel simple at the start?

But actually, when you're at the bleeding edge of what you want to do, it's holding you back. I think that is the main, you know, part of what I'm looking at. One interesting thing that you also did on top of not necessarily onboarding to these system components is how you organize your code. So you mentioned that you have one code base across mobile, iPad, desktop, and even Vision Pro. And as I understand, this is not normal, even in the iOS world or in the kind of Apple world, right? Usually there's different code bases and they reuse some parts of it.

Why did you decide to do the same and, you know, like what upsides and downsides have? Yeah, so it's very interesting. So I think we are the only app of this complexity, which actually has the same code basis. It's not just reuse components. It's like 99% the same code base with some native bindings on each platform, which are required to do that. And the reason we had that is, you know, when I started craft, I said we want to do a hypertext mobile editor. But we had this thing where mobile products shouldn't be just companion tools. You know, a big chunk of the world is mobile only.

and if we build the right software, like these mobile CPUs and GPUs are now so fast, there's no reason why you cannot have the full software there, maybe except you need to think about it differently. Because what happens is most companies try to shrink down their desktop product into mobile and try to cherry pick

which functionality you want to have there and which not. So for this was a really important thing that our desktop app always does the same thing as the mobile app. And of course, what better way is to do it than having itself a share code base. But I think, you know, what originally when I started craft, there wasn't this technology which enabled you to run UI kit code on the Mac. So when people were asking me about a desktop app, I were like, you know, maybe sometime we want to get it right on mobile first.

And then around in 2021, Apple introduced this thing called Mac Catalyst, which again, essentially allows you to write Mac apps with iOS, you know, you know, computer. components and code layouts because Mac used to have a different, you know, rendering engine and layout engine. Yeah, different API as well. Different APIs and all sorts of things. And, you know, with the introduction of the M1 processors, it all made sense because suddenly, instead of it running in a simulation as it had with the Intel-based processors, it kind of runs down natively. So you get the same performance benefits.

Now, the big problem for us was, of course, is Mac apps tend to look and behave very differently than iOS apps, right? So technically, we couldn't really have any examples of what is the right way of doing all of these responsive designs at this fidelity. So it feels native on any platform. So I think that's where our belief in we treat everything as a canvas made a lot of sense because we could build a toolbar that looks on the Mac like a Mac toolbar and on iPhone like an iOS toolbar. Or we could build buttons that, again, adapt to those behaviors. And I think we spent like a good two years of trying to understand how to structure our code, our components, to get the most reusability and be able to truly fulfill this vision of, let's say, you know, just building the feature for both platforms will always take a little bit more time.

But I think for us it's just like 5% more time rather than saying 50% more time as we optimize for both. Can we actually look at what that means? If you could show, you know, just the UI and just show us, you know, what some of your your own components are and then maybe how, how it connects with the code. I think actually, you know, the toolbar is a good example. So I'll just, you know, first show you visually what I'm going to talk about and then, you know, what are the benefits. So right in applications, this, you know, top area is called the tour bar where you have the tab bar, you have buttons and all sorts of things like that. And so, First of all, we wanted to have a lot more flexible tabbing experience,

but also we wanted to have specific capabilities like focus mode, where you have this immersive experience, so you're hiding everything. And then there was nice animation there, right? Can you do it again? Yeah, yeah, I can do it again. So everything moves in the same time, and then everything comes back to the same time. Now for most native developers doing this is kind of what you would call impossible.

I think when I showed this to Apple engineers, they themselves, to ask, how can you do this? Like, it's not being possible. Why would they say that? You know, what makes it so challenging on most things? It's just, you know, like, it's a nice animation, right? Just saying it's someone who's seen it, it is really smooth, but, you know, it's an animation, right?

Yeah, the problem is if you use the default toolbar, you cannot hide the default toolbar animated. You can definitely not say what curve it should hide with, right? So even if you hide the sidebar, you know, the toolbar is going to animate in a different, you know, sense so you won't have this consistent feeling. But again, as I said, we treat this as the canvas, so everything you see here is kind of own bias, drawn by us, we can just say, hey, toolbar, move out in that perspective. So that is what enables this. And a lot of people think that, hey, this must be, you know, super complex because, you know, recreating such a, you know, foundational thing as a toolbar, you know, is super complex. So, you know, I'll just think things show a little bit about, you know, how the code looks like.

In this time frame, it might be a little bit harder to understand, but I'll give my best to highlight the foundational parts. So kind of a lot of our, you know, back in the days, craft was still called Duki, so a lot of in the code, we have still the old code names. But this is kind of- You always have code names, right? Like every single company has code names.

Yeah, yeah. So essentially, you know, here we have kind of the toolbar class, and you can say that we needed to, and we could define, you know, some custom, you know, capabilities. Like in the toolbar, we might want to show your profile, you know, display, or we might want an iPhone. Specifically, it's important to have a bottom separator, but you know, when you scroll, we don't want to have that. You know, do we want to show, let's say, the title of the pager inside of that? And, you know, there's, you know, some of these part of things. And but then when you, you know,

run through the code itself, it's fairly similar, right? We have a bottom separator. We have a blur material so at the background of the toolbar has this nice little blurred feeling a done button we have this real-time cursor area where you know you see all those faces popping in a fuse that didn't get you know some other views like the title the left and kind of then it's like you know some basic command handling we use of you know what happens when you know somebody does something but if i go through this this is the layout code right so this is what i talked about it is we're saying it's kind of ugly because this would be more. And this is when I'm saying,

Guff, hey, we're saying the right area should be, you know, in this rectangle, and I'm doing the calculation of this rectangle. But it's again, it's drawing a rectangle, so it's not super complicated. I mean, this is what the code will probably be for a native component as well, roughly, and if we looked inside

of it. Yeah. And again, it's like 600 lines, but kind of none of those lines are really cognitively, you know, challenging. So we have junior engineers coming in and in the second day doing changes to this. So it's a very interesting thing because, again, it's, so this is where I come back to a backend engineer,

a season, you know, staff engineer will come look at this and say, I mean, where's the, you know, magic inside of here? And I think the core part of is you need to do a lot of iteration to get, you know, which components you build and how right. But then you can reap a lot of the benefits without having a super complicated thing. And the other really good thing is it's like having an open source library you can actually modify it, right? Because what I said, we're not working with close source components or even code base that is just so big.

You know, even let's say you're using a complex, you know, framework. Even if it's open source, you're afraid to modify it because there may be so many side effects is everybody is free to go in and do the changes and they can understand the impact of those changes very easily. And so when you're saying open source, you mean like open in terms of for the team to change? Because now you internal open source, if you will. Yeah, because most of the components you end up using native components or whatever, like if you use a native toolbar, you cannot be modified that at all. You get what's in there. Yeah, but this is really interesting, though, because I feel there's a very big divide between backend and kind of client side slash frontend engineering in the sense of, you know, as a backend engineer, it's kind of like obvious that, A, you choose. an open source library.

You might also just rebuild a lot of things from scratch. They're just this given thing that you go in and change it. You fork the library and you might make changes or try to submit them offstream. Whereas for, I worked on both sides. When I worked with mobile engineers, it was like, oh, you kind of, you just take the component that comes from Apple or from Google or jet brains. And you look at the API, what you can do. You try to tweak it.

And then that's it. I wonder why this is. Do you think Apple might have something to do with it? They have a very strict way that they don't say contributions. You can raise a, even if you have an obvious bug, it takes so long to resolve. You have to raise in their ticketing system and they might or might not look at it, but they're the only ones who can do it. Yeah, I think this is a lot about, you know, a lot of the communication of engineering companies,

to build tools for fronted engineers are about, we're going to simplify this for you because it is complex. So a really good example is there are things which we call virtualized lists. So what essentially means that you have a list of 1,000 items, you cannot create the 1,000 views because that's going to be very slow. So as you scroll, you detect which views should be on the screen, and you only have, let's say, 10 views on the screen at the time, and every time one of it disappears, you know, kind of you repurpose it.

And people are very afraid to create virtualized lists because they say, oh, it's so complicated. And I'm like, what is so complicated in understanding of which view is off-screen and then reusing it, adding it to an object pool and putting it back? And they're like, yeah, but Apple's UI Collection View or whatever, you know, list view has so many things it can do. I mean, yeah, it has so many things it can do, but which of those things actually do you need right now? and you know then why cannot you write that itself so i think front end engineering is a little bit like you might have thousand things a you know control supports right it can support you know small text big sex big text you know this background or that you know touch keyboard handling whatever that is and that is a lot of work um but assuming that you're going to need all of them isn't you know

probably the right thing to do but also then because you know because you never actually end up building lower level because you always just end up using these, you kind of lose your capability to create these. Very often front-end engineers will become an expert in their own domain. Like, you know, React engineers know how React works, but they don't necessarily understand the underlying, you know, solutions. Again, and back in the engineering, the university, and every people learn about how databases work at the core, you know, what do those mean and they can repurpose that. We don't learn that about, you know, front-end systems. So there's a lot more, I think, fear of doing anything custom and what that might result in.

This episode is brought to by Augment Code. Wish your AI co-pilot actually knew your code base? Augment code is different. Augment is built for professional engineering teams working on complex systems, not hobbyists building to-do apps. Other AI assistants struggle with context, Augment understands your entire code base, architecture, patterns, dependencies and all. We're talking instant understanding of systems with millions of lines of code in under 200 milliseconds. Teams like Webflow, Lemonade, and Kong use Augment to ship better code faster. No more context switching, no more generic suggestions, just an AI that works the way expert developers do, fast and in flow.

Plus, with enterprise-grade security and zero training on customer code, you can trust Augment with your systems. Start building with Augment in your favorite IDE and see what it's like when an AI actually understands your code. Try it free at Augmentcode.com slash pragmatic. When we talk about Fronten systems, one of the things that most companies would do is they would, if you're talking to mobile app or web app, create a design system. I've seen this so many times. That sky, sky scanner, every company, there's blog posts about it. Here's our new design system. And this is usually a pretty big undertaking, but it might involve creating custom components

or using system components, et cetera. What is your design system if you even have one? Do you have one? So we have systems, but we have a very different design system that most companies will do. And so what most companies do is there is this called atomic design system where you start with base colors as you know atoms and then you have buttons which combine you know colors and shapes as you know components and then you build you know bottom up from there and this has been very efficient and

design system started coming along when there was this saying that design needs to have a CXO seat at the table and kind of since you know most CXO is like like a C C level so chief design officer basically chief design officer or just kind of design starts saying we need to seat at the table And they found this very common language of systems and components because engineers, and again, you know, high-level executives and tech companies were often engineers in the past, rather than just saying, like, we feel this looks good, right? They could have this shared language of how this looks good.

And for companies which have a very established brand identities and guidelines, which is very static, this works well. And also it works very well for scaling quality. Now, we all know that scaling quality versus improving quality or, you know, innovating, are two very different systems. So, for instance, you know, I expect every front and engineer and craft in two minutes to be able to create the exact same button we have. Because what is the button we have? It's a rounded rectangle with a six pixel corner radius, eight on iPhone, with, you know, this background color and this font size. A light center.

Now, creating that doesn't require a PhD. What we do have systems for is, you know, more sophisticated, you know, parts. And these are, for instance, animation, right? So in animation, we figured out that it's not about the, I mean, you need to fine-tune some parameters, but really what happens is you animate multiple things at the same time. And the consistency of that experience, so it feels that's one movement. and every movement is harmonized together, it's like because it's this visual moving,

it's like a dance, right? So when you look at a team dance competition, if the dancers move in the same time, it looks good. But as each one of them move in a different time, it feels terrible. So for us, you know, having an animation engine, an animation library that synchronizes everything across everyone and we enforce usage of that,

you cannot do anything else, is something. Then I think there are other things, which are quite important for us because, you know, we realize some things that I think I might just, you know, show my screen here, share my screen for a minute. And then just to be clear, when you said like it's like a dance and multiple things need to move, this is because you animate like often everything on the screen, like all your components, right? Well, you know, when an area grows, others need to shrink, right? So it's kind of you have a fixed window size or when you change that window size, everything needs to adaptively fill that. And in craft, everything is animated. So I think this is also a very interesting thing of,

I think we're the only text editor where, for instance, when you enter a new line, right, or remove something, the entire document animates. It's not jumping. You don't have this, but rather everything, you know, flows down. So animation and everything by default when it's just like the bottom, like the bottom like document, for example, but it also moves down.

Like, you know, that's going to be a separate animation, right? Yeah, in the next paragraph and, you know, everything, like, you know, companies shy away from animating these because it's harder. Because the built-in, and also the built-in components don't allow to do this easily or nicely, right? No, they do know. Okay, so I'm starting to see that you're, like, did you know you're going to get all this advantages by building your own stuff? Or did it just happen?

So what we knew is when you draw on a canvas, you decide what you want to do. So I think this is the point of, you know, when you just think about something where you have full control over everything, you know, you can do whatever you do. And five years ago, I didn't know I want to have this type of animation or, you know, that type of thing. But what I wanted is to set up the environment in a way where I can do it if I want it. And I think this is a lot about having control over the basic parts of the system, which enables you to do these. And then it enables you to often do it very cheaply because often you can hack it into existing systems, but then those modifications, if they go against the original design principle of that system, it feels terrible. It will be buggy, hard to maintain, and so on. So then you said you don't have a design system, but you have systems.

like an animation system? Yep. And we also have, you know, some behaviors or components that we identified are generally relatively hard to implement, but we want to use them in multiple places. Like one of the things we realized is if you look at, you know, this part, you can see that the, you know, the question one doesn't fit. Now, what most, you know, front end systems will do is they crop the label and put an ellipsis. Now, what we realized is, yeah.

what we realized when you put three dots, you lose two characters. So if this were an ellipsis, I wouldn't see the O and the N. I would only see up to the question. And we found this both better aesthetic and more useful because in mobile and tiny spaces, those few characters matter. So we created a behavior which you can attach on any label, and then instead of it cropping itself, it will have this nice fading out experience.

And also, it's a little bit more complicated because it needs to work against any background because Kraft uses these tinted backgrounds, it takes over the document color and the likes of that. So it has complexity to create on its own. You have dark mode as well, right? Yeah, we have dark mode, light mode, you know, transfer in backgrounds.

It's, you know, color is quite complicated. And that's why we create this once and build it in a way where you can attach it to any label you have in the application, which means, again, you know, for engineers, it's very easy to create. these delightful experiences, because they can just take something and tweak it easily. So one thing that's interesting about Kraft is it is, as you told me before, it's personal

software. It's very kind of, you know, you work with your own documents, with your own stuff. And how, what difference does this make in how you engineer the application? What opportunities does it give you? You mentioned things like local first. And, you know, like, how does it impact the architecture back and the front end? Yeah, so this was something that I keep learning and relearning a lot of the time. So it's very clear, I think, that new technologies emerge on the server side.

And for a while, it wasn't clear for me of, you know, how much of the things we do can be local versus how much of them need to implement on the server side. So we have, you know, quite strong things on both parts, and I think that's the need in the long term. What's very important is, is when you're dealing with personal software, usually the amount of content you're dealing with, except for binary files like videos and media, but, you know, raw content, that can fit on the user's device, which is very interesting because when you're looking at, you know, B2B software, where there's, you know, a thousand, you know, individuals contributing to that is there's no way that's going to fit on.

your device. Now this is something very interesting because then if you think about it, a lot of the compute can be done locally, which is also interesting because how your cost-based will move across those things. And also what I'm seeing right now, for instance, LLMs, and AI is something that we're saying is like it's no way it's going to be on device, but just in the recent weeks we're seeing signals that actually in a couple of years, that might be also available. So one of the things we're building is we're building every service in a way and wrapping them in architectural components that we can replace them to local or remote components any time we feel now it's possible to do or not without significant infrastructural changes. And this also has impact on how we

architecture our back-ins. So for instance, a very concrete example would be search. Now, the traditional way of, you know, when you have, you know, let's say craft has more than two million users is you have a big, let's say, elastic search cluster. All of the, you know, users' data is indexed in that elastic search cluster, and, you know, you have logical separation, but you don't have physical separation. Now, the problem is, what if you just want to change, you know, the search algorithm for a few users or improve that and things like that? It gets complicated.

So what we're looking at is, could we, you know, have 2 million search indexes on a disk? you know, in the cloud. And every time somebody does a search, either they can download that search index locally and use it there to execute the search, or if we cannot download it because it's too big, maybe a, you know, Lambda or a serverless function can just read the search index.

And based on that, execute the search for the client, that needs to do that. Specifically for API use cases or, you know, whatever headless, you know, capabilities we want to implement, this might be very helpful. But thinking about how we can replicate and use the same infrastructure across client and back end is something you can only do when you're looking at personal scale data. And it's kind of impossible to think about when you're

looking at very deeply interconnected, thousands of individuals in the same data set. Yeah. And like it's interesting because like you mentioned local computing until now the traditional thinking was that, yeah, you should do every compute on the web because you have very thin clients, it might just be a web page, even if it's a mobile device, it doesn't have much computing capability, but this is all changing, isn't it? I think it's always a ping pong, right? You know, and this is what we realize when you're long enough in tech, it's you have cycles, right?

We used to come from, you know, the central computer with terminals. Then we came onto with the PCR of local computing. Then we went back with cloud of everything is computed in the cloud, you know, from websites being server-side rendered. And now we are seeing, I think, a new wave of personal computing. And I think it is powered by also processors getting a lot faster. Like, I believe the M4 Pro is a faster processor than anything you can buy on an AWS cloud. So, and if you can use those resources for it to execute code only for you,

and you as a user have an option to upgrade your level of service because of local computing, that is interesting. So I don't think it's ever going to be black and white. It's always gray. I think eventually people get tired of their own computers holding them back and they enjoy server-side components enabling them, and then they start feeling bad about how much a server-side project costs, and they want to have that power on their own computer.

So it's a pendulum swing, and I think now we're starting to see a lot of interest in moving that ownership of being able to decide the performance I want to have to my computer versus to the cloud. But I guess this can also help with, for example, just pricing. Just, you know, right now we're in the end of zero interest rates have ended. Efficiency is a lot more important. It's harder to raise money.

Basically, it's not really feasible to necessarily have, lose money on services. But if you can do this and you've switched that, you might be able to, for example, offer software where it's free or very cheap or like a one-off payment. if you use local, and if you want to use the server, okay, well, then it'll be a monthly fee of this or that, right? Like theoretically, this could be an option, but only with local compute in the sense of not losing money on it. Well, I think one of the big challenges is underlying operating systems

are changing a lot faster than they were, and consumers expect even free software to adopt that. So yes, you're right on the hosting perspective. Our biggest challenge is every time Apple reads to the new iOS version, It's like, you know, one and a half months of the full engineering team just to make it sure it's buck free. And if we don't do that, even free customers or one-time payment customers will be very upset that we're not updating the software. Yeah, I hear you. One thing you noticed is, one thing you mentioned is Local First.

And now this is, I feel this technology is making a comeback or a surge. What is your honest thoughts on it? Like, does Local First actually work for these, you know, like personal? software categories or is it still in its infancy? So local first is a very interesting thing because for it to make sense, you need to have a very high reliance on the content you have there. Because really the value of local first is when you don't have 5G on your devices, you can still access that information.

And I think local first is now experiencing a comeback because people are starting to travel again, right? when they're on their airplanes, they're on the tubes. And it gets very inconvenient when you need something badly and you don't have it. But I think it only makes sense for a very small subset of products out there. So it's very interesting because, for instance, Kraft is local first. But when adding comments, we could do it in a local first manner. But we figured the US would be very weird of you see a content.

You post a comment on it when you're on an airplane. three hours later when you land, the comments get added, but at that point, there might be other comments added, which make your comments feel super weird from a social perspective. So I think for us it's very important

because we store some of the information you always want to have access to, independent of when that is, but there aren't that many software categories which actually need to provide that with users for. How opinionated is craft and in generally personal software. It could compare to, you know, one thing that strikes me about craft, you know,

I've been using it since the alpha, right? Like, that's the advantage of being there. It just feels very kind of different. You know, you have these gestures. I don't know, maybe you can show some of them that it just doesn't exist. Like, and you know, you're pretty opinionated. And craft seems pretty much. I wonder if this is unique to craft or.

do you see more, more startups, personal software, potentially doing this and actually, you know, it being a good thing. Is it a good thing? Do people like it? You know, because I like it, but I'm never representative of, you know, the broader audience. So I think when it comes to personal buyers and personal software, it's very much around, you know, when you think, for instance, pricing,

so businesses are do what they call value-based pricing, right? So they say that, hey, this problem costs me $1,000, if you can do it for 900, it's a win for me. Consumers are a lot more emotional or anchoring around this. So different mental model. And also when looking at software to use, since software is now mainstream, it's not in early adopter phase. Everybody in the world or most of the population of the world uses software extensively,

a lot of the effect of consumerization in general, I think, taking place. And I look a lot at inspiration of non-software categories. of what that means. And when you look at some of, you know, the success stories and shoes, right, you know, I like to run. So I specifically look at running shoes. And there are new brands popping up. And they are very opinionated about what they represent and, you know, what are they values.

And because the objective performance isn't that difference between shoes or it's very, very hard to measure. Consumers choose a lot more on which one they feel resonates with them or which, you know, is around that. And again, software is becoming cheaper to create, right? We have a small team. We can create a complex software. Other companies out there can do the same, independent from the technology. I build something in three months, you know, anybody can probably build it. So it comes back to a lot around what you choose to put in front and, you know, what you choose to emphasize in, you know, your way of doing so with shoes that might be shapes and forms

and colors, and in productive A tools, it might be certain features or the way you access those features or the way you store your data, which are going to be very important for consumers. So I do see this thing yes of. In personal software, you need to be a lot more opinionated. In B2B, I think, a lot less, or big buyers will tell you what they need because they know what they need and you need to be able to fulfill that. That's why B2B softers tend to become complicated because everybody needs something and you add 50 buttons and it keeps working because they have what they need. In consumer, I think it's personal software. It's different than that.

And what is crafts kind of opinionated or values or how does it come across in the app? You can also share if you want to, if you want to show some visual examples because this is pretty visual as well, right? It is visual, but you need to touch the product. So I think this is kind of when we talk about our values, it's a lot about how craft makes you feel. And I think all of the animation and the custom solutions all are built so we can fine tune how the software makes you feel. Because again, like we believe a lot that the software use every day will influence, you know, you. You know, I think for this audience, a very good example could be we're trying to build what Visual Studio code is for engineers, but for, you know, knowledge workers in the sense of visual. Studio Code feels lightweight. After all of those super heavy IDs, which were non-expandable and

slow and everything, Visual Studio Code was a fresher breath air, which you are just happy to be in because it's responsive, it's fast, it does everything you need integrated. And of course, for non-technical people, there are slightly different angles. That's for animation, fluidness, you know, visual customization, you know, makes a lot of sense. But that's how I could, you know, you know, bring our type of positioning closer to this more engineering focused audience. So you built Kraft with a pretty small team. Can you tell me how, what the size of the team is? And then also how many people built, for example, the iPhone, the Mac apps? Yep. So we have a product engineering team is around 20 people. This in Q is, you know,

product engineering design and QA and we don't really have product. So it's mainly design engineering and QA. Well, you're a product. No. Well, kind of design, I think design has an overweight in product. And of course, I do product as well. But just to confirm, you do not have a dedicated product manager role. No, we do not have a dedicated product manager role.

No. And we're split now on platform teams. So this means we have a web team, a native app team, and a backend team. Each of those teams are like three for people. So, and that's kind of it. We tried to scale up, but it didn't work out. I think, you know, one of our parts problems of scaling up is we try to be a lot more systematic and a lot less flexible. And at the iteration speed, we want to grow, I think, our decision would have been either to grow, you know, fivefold.

And then we can reap the scalability benefits. but we ended up in this interim situation where we were neither flexible and fast enough nor structured enough and it was kind of a bad place to be so we find this you know around four up to five people platform teams understand the context are resilient you know they can step in for each other but can iterate very fast and it also puts a constraint on us on how complicated infrastructure we're willing to build because of course if you build complicated stuff maintaining that requires a lot of effort. And we only want to do that if the trade-offs are very attractive.

Like it's something truly special that our users were really love. So like you're saying there's like three or four people building the iOS app and then, sorry, the whole code base, all four code bases, iOS, Mac, iPhone, and iPad. And even Vision Pro? Yes. Yes. Yes. So on the native app side, people who are writing Swift code, it's only kind of three, four people.

That's surprising to hear, but also, I guess, encouraging that it does work and can work. And you're saying that in your experience, the smaller team worked better than a somewhat larger team because of, was it communications overhead, iteration, disagreements? What made it more challenging? So what happens is when you have a team over five people, right, the communication starts to break down. So then you ideally want to split it to two teams. And what we did at the time is we had, you know, more than five people in each platform. So we said, let's move to feature teams, you know, typically what companies refer to it. So each team has a specific goal.

They work on a specific feature. They execute on that. But we lost those holistic capabilities of everybody having full access to a full code base. If you get what I mean of, you know, what I showed if you want to create a focus mode, it's super easy because you just go down to the route and, you know, change that. and it works. And also these teams being, you know, not having sufficient team members from the same platform while you're working on that, slowed it down a lot.

So we noticed that a fellow iOS engineer can help a fellow iOS engineer better than a fellow web engineer or backend engineer. And that is what creates these very clever solutions when multiple people from the same domain have different ideas and they do understand the business context. We're providing a lot of context, and we really focus on every team fully understanding that.

But then they can really understand their technological limitations and how they can come through that, which for us increases velocity a lot. And the composition of the team is mostly, so if I understand mostly it will be of those 15-ish engineers, about like four or five back end, and the rest will be mobile, front-end focus. Yes. Yes. Which is interesting because it's usually, again, for most companies,

even mobile-focused companies, it's usually the other way around. At Uber, there were more backend engineers than the mobile engineers. So an interesting twist, but I'm glad that it's working. It clearly is. Now, what advice would you give to front-end or mobile engineers who are really passionate about what they do? They love the craft. They, you know, they love building these things, but they do feel a bit stuck. Both professionally, they're just not getting ahead. The next promotion will not be them. They will unlikely to be the team leader or if they want to go into engineering leadership.

It looks really hard. What could they do to be taken potentially more seriously and to be able to take this front end and user focus into a bigger organization and to have a larger impact? Yeah. Yeah, so, you know, it's very hard for us, again, front and dangerous to talk about if I do this project, we're going to save a million dollars. It's just not possible to articulate in that sense. So it's a lot about how, you know, it makes people feel.

Now, the thing I do, I still do this as CEO today a lot, is what I call building prototype apps. And I put it in the hand of decision makers. When I was at SkyScanor, I put it in the hand of the CEO, you know, the VPN during and showed him of this is what we could have, you know, touch it, feel it. Do we want to have this? And, you know, do we want to do it this way? And then these are the costs around that. And it's, of course, a limited prototype, but it's good enough. So they feel the value rather than just trying to objectively describe that value into that. And of course, it always helps if you have backup studies like when you press something and it appears in three milliseconds versus 10 milliseconds,

there are writings there that every millisecond that you decrease in terms of response timing, you know, increases conversion by 0.2%. So, you know, there are these type of things as well. But I think it's, because the whole, our goal is to interface with people, the only way we can explain, even to very senior decision makers is so they can experience it. And usually these senior decision makers are very good at identifying patterns and, you know, looking at what they're just going through. So that is kind of, for me, as always, don't talk about it, build a small prototype and show it in the way where it's not a video, it's that they can, on their own device, touch it and, you know, use it,

and you'll see a vastly different response. So I have this so often with the design team of I, you know, mock up something. I send it to them. They're like, no, it's not going to work. Versus I just build a small prototype, give it to them, and they're like, oh, my God, there's something special. So that is, for me, buy-in has always been about, you know, show, not tell. And by the way, I acquire so many interesting skills while doing so.

I think nowadays specifically when picking up new things, AI and LLMs can speed up this exploration process a lot. So I become faster in building prototypes. And that is my number one advice actually is. Again, show, not tell. Speaking of AI, Gen AI, how do you use it? And how do you think front-end engineers, mobile engineers, people building visual stuff, should use it? Because I do hear some hesitation like, you know, it's never going to be the craft that I can do.

It just spits out the, you know, the boilerplate like, nah, shouldn't bother. Right. There's some of those. Yeah, I think there's, you know, a lot of companies, you know, they don't want to be the top 1% of design. They want to be, you know, the top 25. And I think that's where, you know, AI code generation is good enough. But in the recent months, like I've had some, you know, very serious breakthroughs. And I'll tell you one example is, you know, in craft we have this capability where the apple pencil you can sketch and draw a circle.

But, you know, it's not going to be a perfect circle because you're drawing by hand. And we wanted to add something called shape recognition where you, we can detect if it's a circle. Now, this is a quite complex problem because it essentially has three stages, you know, from the point data creating, you know, shapes, from the shape, you know, estimating, you know, what it could be and then, you know, replacing that. And I think the latest reasoning models are very good at that. Like, I know nothing about this math. And previously I shied away of this problem because I estimated it's one or two weeks of my time. And, you know, last weekend in three hours, I had an end-to-end solution. What it gave to me was topics I don't understand about. So if I were expert in this maths field, I probably would have been able to write it in three hours

myself, but I wasn't. And just being able, it's not just giving me an algorithm, but I could iterate with it of saying, hey, this one doesn't work for the rectangle, try another algorithm, or this one isn't for the triangle. So just to be clear, you were talking with an LLM, if you could tell us which one, on, like, how to build this code that could, you know, like do an algorithm that would roughly recognize the shape and then, you know, turn it into an actual shape. Well, it was so this was the new 01 model from Chad GP team, and actually didn't go to that depth. I told him I'm a developer craft. I used pencil kit, which is kind of, you know, the framework.

And I want to do shape recognition similar to the Apple Notes app, what it does. This was the prompt I gave, and it gave me a very interesting solution, which I needed to iterate on a lot, like an engineering architect saying of, you know, I like this layer, but this layer seems to fail because I've been debugging in the meanwhile. So there was a lot of thinking there. But this was the first time where I said, AI helped me not just to be 20% faster, but in this problem, it made me 10 times faster. And I don't know how reproducible this will be. But for me, these are the things where another example is we're now playing a lot with shader codes.

Because shader code is very mathematical, you know, very much like assembly. It's very hard for even like engineers like me to write. But AI can help us write it, which. which can again open up a new dimension to how we present things. And it's a lot about the capabilities I did not have before I now have access to for me when it comes to AI. And also I think a lot of us in our team, like our backend engineers now can create prototypes with UI and the UI isn't that good, but it's good enough to showcase what they

want to showcase. And to close it off, you're still very hands-on, right? You write a lot of code. I, you know, there's two things there. One is at my time at SkyScanter where I've been, you know, at this product, you know, director, you know, leadership role, I really missed being close to what I call the metal or the product. So for me, I realize that I get a lot of intuition and positive, you know,

re-encouragement from being able to do things, you know, see a user feedback and act on it. And if I don't have this, when I get too far, and maybe not ready yet or not mature enough for what they call delay gratification, I like being there. That's one thing. The other thing, I think I am still quite good at it. So I think I have special skills, which would be very hard to acquire it in the market. And for me, having that ability of being able to connect deeply product, engineering, and design,

because I also do a lot of design, it helps me to think through problems and work with each individual domain to steer them towards, I'd say, a more efficient or more pragmatic solution, you know, finding those spots. And I'm getting a lot of criticism of as a CEO, this should not be your job. And I get for a lot of CEOs, this is not part of their job. But, you know, the team is okay. I don't know if they like or dislike, but they're okay me working with this way. And I enjoy it a lot.

And I feel I'm doing a lot of things that make the product better and me more satisfied. I mean, this is the benefit, right, of doing your company. There's a lot of risk to it. But if you're working within an existing organization, like you know, you need to take whatever their priority is and, you know, do the stuff that they're kind of assigning you. Obviously, there's freedom, but not always. And to wrap up, we'll do some rapid questions.

So I'll just shoot. And then you'll answer, what's your favorite programming language and why? So I would say SWIP, but I think it's actually Objective C. I hate Objective C syntax, but compilation speed for me is super important. And Objective C code just compiles super fast. So several times faster. I mean, the way it works, right? There's not many type checks and all those things.

What is the best design tool that developers might also want to use? I design in code. So I don't use design tools at all. You don't use design tools? No, I use very high-level sketching. But it's really just like rectangles and things like that. I go directly to code because I think you, again, we're talking about drawing rectangles, and that's quite fast to type rectangles.

So I do it directly in code. So for me, I really love, by the way, tailwind CSS because that I think with Visual Studio Code and Hot Reload, is the fastest pro-typing tool I have seen. And I think it's, for me, it's very natural the way you can express yourself there. That's awesome. I didn't think of it as a prototyping tool, but I guess, yeah, it is a really efficient way of doing stuff. And what are one or two books that you read on would recommend?

So one of the very, it's not engineering, but in some ways it is, is there's Ben Horowitz wrote this hard thing about hard things book. And it's been super interesting for me because a lot of the things, how it talks, for instance, about something called management depth, which is, you know, working with people who aren't working out and how he compares that to tech depth. So what that taught me is how my experience in engineering with coding and, you know, engineering systems can often be translated to human systems when people work together. I'm not sure if you look at that as a bad or a good thing, but it's very interesting in helping me understand. of these mental models live more and traverse across your immediate domain. Awesome. Well, thanks for sharing this less conventional way of developing software, developing opinionated software,

and also showing a little bit of behind the scenes of how in the end it's all code and reminding us engineers, especially front and engineers, you shouldn't be afraid of it. This is great. Really enjoyed that. Thank you very much. hope you enjoyed this pretty unique episode with my brother, Balind. I'm still amazed at how small teams can get so much done and how competent teams frequently can ignore best practices like

using operating system level components. You can check out Kraft and connect with Balint and the links listed in the show notes below. For related, the Pragmatic Engineer deep dives also see the show notes. If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast. Thank you if you leave a rating. Thanks and see you in the next one.