Design-first software engineering: Craft – with Balint Orosz

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 designer. 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 skill.

algorithms a lot of the innovation i bring to a team means that clicking on a button will take two milliseconds instead of 10 milliseconds back-end engineers will say they just saved two million dollars on infrastructure cost or scale to a billion users for creating user-facing experiences 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, engineering, that's where they thought and they found

hard problems to meet. Craft 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, Balintoros. Balint is probably the exact opposite of me. He's a

designer at heart and is as good as someone can get in 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 craft 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 jumpy. 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 opinionated 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, Balin, 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 backend oriented. Their background typically, you know, they've been in engineering for 10 plus years. It's usually... very backend heavy. And this leads to a lot of interesting things. Their approaches will prefer backend 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.

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 far more of this backend 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 end side of things and you still say it here so how do you find it being different

being both a founder, previously you were an executive at Skyscanner, with a lot more, should I say, design focus, user focus, mobile focus? What would a good way 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... We can probably note the first few programs that you wrote, those were games, right?

Yeah, they were games and visualization of graphs. And I focused a lot on time on 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. A very interesting takeaway, because despite being an engineer for such a long time and 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 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 back-end engineers will say they just saved two million dollars you know on infrastructure cost or you know scale to a billion users and i think my love for

for creating user-facing experiences 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-end distributed systems 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 was brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication, SKIM provisioning, and fine-grained 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 AuthKit for up to 1 million monthly active users. It's a drop-in replacement for Alt-0 and comes standard with useful features like domain verification, role-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design.

you get limited 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, Vercel, 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 Engineer's Guidebook, is out now. You can get it on all major audiobook platforms like Spotify, Audible, Liberal.fm, Apple Books, 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 Reilly.

who is the author of The Staff Engineer's Path. From performance reviews to P95 latency, from team dynamics to testing, Garagay diversifies 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 engguidebook.com or search for the Software Engineering 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 uh 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 it 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 Indiana, but Uber, and 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 Skyscanner. And then you became a director of engineering. Yeah, it was head of app product.

So you went from a 2-person startup or 3-person startup to a 30-person startup, acquired, and boom, you're inside a 1,000-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 sky scanner you came in as you know you went from a

running your startup to an executive, you know, you are now so very important. Funny enough, we later both worked there and, you know, 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 as your kind of back end pierce did so it was very interesting on that side of things because there were two phases you know being at sky screen i think the first part was

Our acquisition was mainly driven by the frustration or the desire to build a really amazing mobile 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. 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, to make it a world-class engineering team. And I think this was where very interesting things started to happen in terms of... Agreements, disagreements, what is important, what is not important, senior architects coming in, setting up metrics and 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 started having deeper discussions with... The engineering leaders, again, you know, very, very senior 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, measurement of throughput, 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.

uh you know performance how we looked at throughput and who who was seen as someone worthy of a promotion yeah so in indian you learned the big company way 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 granular 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 Skassian, 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 Skyscanner for a short time. A different organization. I made sure I didn't report into your organization and indirectly to you. 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.

cold quality, unit test coverage, CIC de-build times. It was about user experience. How smooth does it feel? How fast is it? How many taps do you need? You kind of kept this focus even as you started your next startup, right? That was a mobile iOS first startup, Kraft, Kraft Docs. And by that time, you've seen them both. You've seen the back and you've seen the front end.

What did you decide to bring in from day one from engineering on how you've built this startup from scratch? Yeah, 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 UI first entering culture, if you'd like. But their backends and their web services and 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 comfortable. 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 hypertext 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 kind of 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 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 even design components when tomorrow it might not be needed will be the right approach to that. So this was, I think, the approach of... I came out with is neither is better than the other, right? You know, 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 then one domain or two domains? Or do we call front-end engineers design engineers and have them compensated differently? But I felt very strongly. about this coming up 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 can take notes, you can use it, you can do whatever. It's like Evernote++ 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 a 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. OK, 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 existing native components. What did you do and why? Yeah, so. I'm 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-based blue screen windowing management solutions with all of 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 user interfaces. Somehow, 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 shader code, you can create any type of... very beautiful visual effects if you want to, despite anything else. So for me... And just to be 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? Yep. 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, you know, there's like auto layout is a very good example, which Apple introduced in 2013, 14, I think.

You've been one of the early adopters of AutoLayout inside of Skyscanner, which promised you no longer need to think in rectangles. 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 I guess, 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 trade-offs. Yep. So, you know, back in the days, you know, an iOS generally has this principle coming back from 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, zero, zero coordinate. I want it 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. The same resolution, right? The same resolution. And I think the iPhone 4 or 5 was which 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 run times. So you have a more abstract syntax that is easier to understand and define.

But when it comes, for instance, to animations, to edge cases, you lose control because all of these dynamically calculated things will end up with something. So it's a lot more implicit way of, you know, 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 more advanced stuff, as you mentioned, animations. And in the early days, it could feel jerky, laggy.

like go up and down up and down up and down but they fixed 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 complexity you add in you're 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 reasonable set of time. It got better, but I still think it has, you know, significant challenges inside of it. So you never opted into it, right? You always said, like, let me choose the complexity and just to keep control. No, 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 auto layout, now it's SwiftUI. And what I always do is I show them one of our transitions and say, if you can do this with the same performance in auto layout, we're switching to auto layout. right 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 okay 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, you know, 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 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.

As I understand, this is not normal, even in the iOS world or in the Apple world. Usually there's different code bases and they reuse some parts of it. Why did you decide to do the same? You know, like what upsides and downsides does it have? Yeah, so it's very interesting. So I think we are, you know, the only app of this complexity which actually has the same code base. It's not just reuse components. It's like 99% the same code base.

uh with you know some you know 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 shared code base? But I think, you know, what originally when I started Craft, there wasn't this technology which enabled you to run UIKit 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 components and code layouts because mac used to have a different you know

rendering engine and layout engine. 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, you know, responsive designs at this fidelity so it feels native on any platform. So I think that's where our... You know, 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, you know, adapt to those behaviors.

And I think we spent like a good two years of trying to understand how to structure our codes, 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 just the UI and just show us what some of your own components are, and then maybe 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 first of all, you know, we wanted to have a lot more flexible tabbing experience, but also we wanted to have, you know, specific capabilities like focus mode where you have this, you know, immersive experience. So you're hiding everything. And then, you know, there was nice animation there, right? Can you do it again? Yeah, I can do it again. So everything, you know, moves at the same time. And then, you know, 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 asked, how can you do this? It's not impossible. And why would they say that? What makes it so challenging on most things? You know, like it's a nice animation, right? Just saying as 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 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 owned by us, drawn by us. We can just say, hey, toolbar, move out.

in that perspective um 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 make things show a little bit about, you know, how the code looks like. It's, you know, in this timeframe, it might be a little bit harder to, you know, 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, Kraft was still called Duki. So a lot of in the code, we have still the old code names. But 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 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 when you scroll, we don't want to have that. Do we want to show, let's say, the title of the pager inside of that? And there's some of these part of things.

But then when you 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 and a fuse that didn't get, you know, some other views like the title, the left and kind of then it's like.

some basic command handling we use of what happens when somebody does something. But if I go through this, this is the layout code, right? So this is what I talked about. We're saying it's kind of ugly because this would be more. And this is when I'm saying of, 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, 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, you know, 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 back-end engineering season. Staff engineer will come look at this and say, I mean, where's the magic inside of here? And I think the core part of it 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, right? Because what I said, we're not working with closed source components or even code base that is just so big, even let's say you're using a complex 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 that open source, you mean like.

open in terms of for the team to change because now you internal open source if you will yep yeah because most of the components you end up using native components or whatever like if you use a native toolbar you cannot really modify 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 on and change. You fork. the library and you might make changes or try to submit them upstream whereas for

I worked on both sides. When I worked with mobile engineers, it was like, oh, you just take the component that comes from Apple or from Google or JetBrains, and you look at the API, what you can do, you try to tweak it. And that's it. I wonder why this is. Do you think Apple might have something to do with it? You know, they have a very strict...

They don't take contributions. 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 who build tools for front-end engineers.

are about we're going to simplify this for you because it is complex and so a really good example is there are things which we call virtualized lists right so what's essentially means is you have a list of 1000 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 a time, and every time one of it disappears, 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 you know apple's you know ui collection view or whatever you know this 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, you know, control supports.

It can support small text, big text, this background or that, touch, keyboard handling, whatever that is. And that is a lot of work. 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 never actually end up building lower level codes you always just end up using these you kind of lose your capability to

to create these uh 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, in back-end engineering, in the university and everywhere, 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 was brought to you by Augment Code. Wish your AI code 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 codebase, 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 front-end systems. One of the things that most companies would do is they would, if you're talking a mobile app or a web app, create a design system.

I've seen this so many times at Skype, Skyscanner, 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, etc.

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 systems 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... Like a C-level, so chief design officer, basically. Yeah, chief design officer, or just kind of design starts saying, we need a seat at the table. Yeah.

They found this very common language of systems and components because engineers, and again, high-level executives and tech companies were often engineers in the past, rather than just saying, 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 innovating are two very different systems. So, for instance... You know, I expect every front-end 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 align 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

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 as 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, you know, 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 it's like a dance and multiple things need to move, this is because you animate often everything on the screen, like all your components, right? Well, 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, you know, 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. So like the bottom document, for example, it also moves down. That's going to be a separate animation.

In the next paragraph and everything, 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 not. Okay. So I'm starting to see that you're like, did you know you're going to get all these advantages by building your own stuff or did it just happen? So what we knew is.

When you draw on a client bus, 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 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, right? 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, you know, 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, you know, 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 craft uses these tinted backgrounds. It takes over the document color and the likes of that. So it's...

It has complexity to create on its own. You have dark mode as well, right? Yeah, we have dark mode, light mode, transparent backgrounds. 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, for engineers, it's very easy to create these delightful experiences because they can just take something and tweak it easily.

One thing that's interesting about craft 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. What difference does this make in how you engineer the application? What opportunities does this give you? You mentioned things like local first. How does it impact the architecture back in 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 it on the server side. So we have, you know, quite strong teams on both parts. And I think that's needed 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 raw content, that can fit. on the user's device uh 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 computes can be done locally, which is also interesting because how your cost base will move across those things. And also what I'm seeing right now, for instance,

And AI is something that we're saying is like, it's no way it's going to be on device. But, you know, 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 anytime we feel now it's possible to do or not without significant infrastructural changes.

And this also has impact on how we architecture our backends, right? 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 Kraft has more than two million users. is you have a big, let's say, elastic search cluster. All of the users' data is indexed in that elastic search cluster, and you have logical separation, but you don't have physical separation.

Now, the problem is, what if you just want to change 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 have 2 million search indexes? on a disk 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 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 backend 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, you know, 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 on to the PC era 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. I don't think it's ever going to be black and white. It's always gray. I think they're...

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, you know, 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. 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 lose money on services. But if you can do this and you've switched it, 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, you know, it'll be a monthly fee of this or that, right? Like that 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 to that. So yes, you're right on the hosting perspective.

Our biggest challenge is every time Apple releases a new iOS version, it's like, you know, one and a half months of the full engineering team just to make sure it's bug 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.

I feel this technology is making a comeback or a surge. What is your honest thoughts on it? Does Local First actually work for these 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. 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, craft is local first, but when adding comments, we could do it in a local first manner, but we figured the UX would be very weird if 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 comment feel super weird from a social perspective.

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, you know, need to. provide that with users for how opinionated is craft and and in generally personal software One thing that strikes me about craft, I've been using it since the alpha, the advantage of being there. It just feels very different.

I don't know, maybe you can show some of them that it just doesn't exist. And you're pretty opinionated and craft seems pretty much. I wonder if this is unique to craft or do you see... more startups, personal software potentially doing this and actually it being a good thing. Is it a good thing? Do people like it? Because I like it, but I'm never representative of 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 do what they call value-based pricing. So they say that, hey, this problem cost 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 models. And also when looking at software they use.

since software is now mainstream it's not an early adopter phase everybody in the world or like 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 the success stories and shoes, 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 what are their values. And because the objective performance isn't that different between shoes, it's very, very hard to measure. consumers choose a lot more on which one they feel resonates with them or which is around them.

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 built 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 and, you know, your way of doing so with shoes that might be shapes and forms and colors.

And in productivity 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 softwares 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 how is... What is Craft's 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, we believe a lot that the software you use every day will influence you. 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, you know, non expandable and slow and everything. Visual Studio Code was a fresher breath there, 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 where animation, fluidness, visual customization makes a lot of sense. But that's how I could bring... uh our type of positioning closer to this more engineering focused audience so you you built craft with a Pretty small team. Can you tell me 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 our product engineering team is around 20 people. This thing cues, you know, product engineering design and QA, and we don't really have product. So it's mainly design engineering and QA. Well, you are a product. Well, kind of design, I think, you know, design has an overweight in product. And of course, I do product as well.

But kind of, then we have... 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 where... split now in platform teams so this means we have a web team a native app team and a back-end team and each of those teams are like three four people uh so and that's kind of it uh we try 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 a 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 are 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 will 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 Envision Pro? 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 what was it communications overhead iteration disagreements what what made it more challenging so what happens is

When you have a team over five people, 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 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. What I showed, if you want to create a focus mode, it's super easy because you just go down to the root and 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. 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 of the team is is mostly so if i understand mostly it will be of those you know like

15-ish engineers, about four or five back-end, and the rest will be mobile front-end focused. 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 back-end engineers than 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 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?

And to be able to take this front end and user focus into a bigger organization and to have a larger impact. 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 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 Skyscanner, I put it in the hand of the CEO, you know, the VP engineering and showed him if 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 3 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 use it.

and you'll see a vastly different response. So I have this so often with the design team of I mock up something, I send it to them, they're like, ah, 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 here. 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.

You know, 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, 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. 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 one percent 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 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 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 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 turn it into an actual shape. Well, it was so this was the new O1 model from KGP team.

And I actually didn't go to that depth. I told him I'm, you know, a developer at Craft. I use 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, 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, very much like assembly. It's very hard for even engineers like me to write. But AI can help us write it. 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, you know, what they want to showcase. And to close it off, you're... You're still very hands-on, right? You write a lot of code. There's two things there. One is, at my time at Skyscanner, where I've been at this product director, leadership role, I really missed...

being close to what I call the metal or the product. So for me, I realized that I get a lot of intuition and positive 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 delayed 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 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, 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 of doing your company there's a lot of risk to it but but you if you're working in existing within an existing organization like you know there 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 but not not 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 Swift, but I think it's actually Objective-C. I hate Objective-C syntax, but compilation speed. uh for me is super important and you know objective c code just compiles super fast so yeah several times faster i mean the way it works right there's not many type checks and all those things what 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, that is the fastest prototyping 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 and would recommend? So one of the very...

It's not engineering, but in some ways it is. 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

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 it's very interesting and 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, you know, like how in the end it's all code and reminding us engineers, especially front end engineers, you shouldn't be afraid of it. This is great. Really enjoyed that. Thank you very much.

I hope you enjoyed this pretty unique episode with my brother, Balint. 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 mobile components. You can check out Kraft and connect with Balint in 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.