Incremental TypeScript Migration Strategies with Nathalia Rus

Transcript

[00:00:00] Joe Previte: Today I have Natalia Rose, and she's going to introduce herself, right?

[00:00:07] Nathalia Rus: Hi Joe. Thanks so much for having me. I'm Ross I'm co-founder and engineer at Custodian. It's a platform for co-owners where we make it easy to own a car. We build a bunch of tools and we are working at the moment on our insurance offering.

[00:00:22] Nathalia Rus: We don't want to just compare insurance. We want to be an insurer. And I learned to code on my own. I've studied politics at university and I was working think tank banking. I've done very different types of careers in one already my age. And I fell in love with coding. I would say I think it's five years ago now.

[00:00:41] Nathalia Rus: And went through bootcamp and. Was lucky enough to have a mentor who was for 30 Y Combinator alumni, and he helped me in my first projects to make sure that I was learning how to go the right. And yeah, been doing some migrations to type script. A huge type script advocate since even if at [00:01:00] first it was not , something I was looking forward to, I've been forced thankfully and now I'm here advocating for it.

[00:01:08] Joe Previte: Yeah. That's awesome. And I feel like there's gonna be some good stories that we can get into, but I think the first thing we should start with is probably for the skeptics, like why type script, you said that you had to be convinced. Yeah. What how did that person, how to do your mentor convince you, and what were your hesitations?

[00:01:24] Nathalia Rus: Yeah, so my mentor is not a front end engineer. He's into data and object. Programming . And so he didn't really manage me to convince me logically because he, I didn't really trust him because he was not a front end engineer, if that makes sense. But he said, Oh my God, on a weekend app, I was making something in JavaScript and it scares me.

[00:01:45] Nathalia Rus: Because I'm coming from Ang, I'm getting from all of those languages where it's super strict and I can't believe you're, you are building our products from the ground up in JavaScript. This is not wise and and I made my research, et cetera, and it sounded all good [00:02:00] that, at the time I said JavaScript is, King for a reason, and I've learned in my boot camps and on my own react without type script that everything was going well,

[00:02:09] Nathalia Rus: And so I thought maybe, it looked super complex as well. I was looking at the codes and I was trying to have some examples where I changed my code to as scripts and it looked scary. And because I tried very superficial examples, I could not feel the benefit of text scripts. It's something that you feel when you start to have complexity in your code.

[00:02:30] Nathalia Rus: Basically, so that's why I was skeptical is because I had a superficial example. I didn't spend enough time basically trying to really get to the point where I could feel the benefits of D script. I tried it for, a week and after a week I didn't really see the benefits straight away outside of auto completion.

[00:02:47] Nathalia Rus: but to me it was like, okay, I'm learning how to think in a different way for it to completion. Is that worth it? And after three weeks, I would say I started, because I built a product from scratch, so there was no complexity at the [00:03:00] start, right? After three weeks, I realized, oh my God, that just saved my life.

[00:03:04] Nathalia Rus: The fact that type script was there, I couldn't remember exactly what I had done three weeks. And I just could see with auto completion, different choices, understand my api, understanding what could have been undefined, and I had to fall back all these things. So to the, to skeptics, I would say try to understand whether you really have a fair understanding of the benefits of test scripts and not just those that you read on paper and can't really comprehend.

[00:03:30] Nathalia Rus: Make sure that you have your opinion on whether type script is a good idea. After actually seeing it in action in a complex database. And that could be an example app that you make on your weekends, even if it takes more time, because you need to get to the point where it's complex but only say no to type script once you've tried it in a complex app, because then you actually no.

[00:03:53] Nathalia Rus: And seeing the benefits and then personally, you'll be able to say whether it was worth it or not, but at least you will be in a position [00:04:00] where I will believe you if you say, no, it's not. Yeah, . .

[00:04:06] Joe Previte: That's so interesting. So when you decided to, try it, what, like how did you pick it up?

[00:04:12] Joe Previte: How did you approach, bringing it into your stack? Sure.

[00:04:16] Nathalia Rus: I tried it first very easily just by having any everywhere, which by the way, I don't recommend now that I have a bit of. Of step back because by, by putting any everywhere at first I think I was faking the fact I was doing type scripts and understanding it.

[00:04:33] Nathalia Rus: I didn't have an error and it felt great. But that's not how you're going to learn. The, to be completely fair and transparent, when I learned the most, was when I got stuck because I was using sagas and redux. And to use those packages with type scripts was a different game because you can't just write your function.

[00:04:52] Nathalia Rus: You have to say, between those sort of triangular apprentices don't know how you call them. How you have to write the props, the specific type [00:05:00] of function that it is, that s and generate, for example, or a promise, et cetera. You have to specifically say those things. And again, because I was not writing a ga reading a guide or reading a blog because then you spend your whole time reading and you don't do right.

[00:05:13] Nathalia Rus: There's so much you can read and learn online. I was very stuck on how to write those. How to have those functions just not through an error, even if the code was correct. And it was when I got stuck on those things where you couldn't write any, when you couldn't write any, I got stuck.

[00:05:28] Nathalia Rus: And this is where by trying to go through it and make it work, I learned, I said, Okay, I understand I have to go to the source code of sagas, for example, and understand what actually this dysfunction. And then you learn and you're like, Ah, okay, I understand that what it means for thanks as well. You're like, Ah, I understand how it works, because I've seen the types, I've seen the different options.

[00:05:49] Nathalia Rus: I've seen the different functions available. I've seen what it is made of. And when you realize that everything that you use, for example, packages, et cetera, it's just, it's nothing. [00:06:00] It's nothing magical. It's building blocks of code which you could have written yourself, when you read it, it makes a lot of sense.

[00:06:06] Nathalia Rus: That made me a better developer in general, by the way, not just in JavaScript, but in general. It demystified so much. And so over time I could learn to understand why there was an error with a package or et cetera, and I could, on my own, basically understand the definition that it was expected of me based on sue code of the package.

[00:06:27] Nathalia Rus: And over time I didn't have any problem. Therefore, in, in migrating to type scripts it was easier way, way easier. And so I would say it's by getting stuck that you learn. So try to avoid any even if it's very you want to do it because you want it to work and he wants to cut , you have to stop yourself and force yourself, even if you have to get stuck the whole day, Get stuck the whole day and then you'll learn your lesson.

[00:06:54] Joe Previte: That's interesting. So you so you're working with these third party packages, third party libraries, and like [00:07:00] you said, like the way that you said it, just sounded so interesting, right? Where it's like most of the people say, Oh, adopt type scripts. Take the gradual approach, use any everywhere, and then fix it later.

[00:07:12] Joe Previte: And you were like when you get to a place where you can't use any and you get stuck, like you can't use that approach, so

[00:07:18] Nathalia Rus: I, there is one case where I use any and still use it now, by the way. And it's very specific. It's only one, it's only in, in parts of the code base, which I start from scratch.

[00:07:29] Nathalia Rus: Because you shouldn't use any in any way when you're migrating an existing database because you're meant to use already the function. So you're meant to already know what this function expects because it's written somewhere already. So using any, when you're migrating a project to use a NoGo because you're meant to know what something is.

[00:07:49] Nathalia Rus: And if you don't know, then. Remove this function because it's not used anywhere, and so it's confusing. However, in projects that you start from scratch or features that you start from scratch, I think it's okay to use [00:08:00] any, when you're not sure yet what you're going to do. So let's say for example, that you have a form and in the form you need to synchronize errors, which is something that I had where I used any for the first day.

[00:08:11] Nathalia Rus: I said, Okay, I will want to put all of the errors that are currently on the forms, which had different steps, and I want to put all the errors. I'm not sure yet whether I want the errors to be normalized with keys of the fields. Or if I wanted this error to be an array and if there was any element inside of the array, therefore there was somewhere an error and the person couldn't click submit.

[00:08:31] Nathalia Rus: I was not sure, but I knew that I wanted to have error as a property there. So that I knew that I had thought of that on the high level and I could focus on other properties of that object. And so I think using any is helpful when you want to get going. You're not really sure yet of the specificities of your properties or your types.

[00:08:52] Nathalia Rus: But to me it does not make sense when someone migrates an existing code base to tape scripts and has any in it [00:09:00] because you're meant to.

[00:09:03] Joe Previte: Okay let's dive into that. Cuz I've definitely heard the other side and I'm interested to hear this side. What do you do if you have a large code base that you're trying to migrate?

[00:09:13] Joe Previte: Like how do you do that piece by piece or how would you do that?

[00:09:18] Nathalia Rus: So there are different strategies on how you want to do a migration. And I think both are completely viable. Either you do the hybrid approach. Where, what the hybrid approach is basically you still have JavaScript allowed in your project and you still have JavaScript files in your code base.

[00:09:37] Nathalia Rus: And so you can have type scripts coexisting with JavaScript. That means that you basically can have some files which have been migrated in and translating in some far or not. So that's more like a gradual approach. And then you have the, all the migration. Where, as you say, any, there is, you have to have any other store, at least, because you're basically having you [00:10:00] run a command for example, ts migrate, which is an Airbnb tool, and it automatically translates all your refiling type script.

[00:10:06] Nathalia Rus: It does not mean that you've done it, you've done it on paper , but you actually haven't migrated the type script because you haven't got any benefits whatsoever. Just because you run this comment and and all of your files are in TSX does not mean that you are. It's false.

[00:10:21] Nathalia Rus: And so there, yes, I agree that by by default everything will have to be any, because Airbnb of course, can't do that work for you. But that is not because you manually yourself types any, it's because you run. A comment, a tool, a comment that made it so automatically you would not have errors, compiler errors and your files were written in type script.

[00:10:44] Nathalia Rus: It's not yourself who typed any, because you couldn't be bothered to check out whatever that was expecting. So I think that's where I'm against any, It's if you are supposed to know what is that? Yeah, Airbnb tool, ts [00:11:00] migrate. They don't know, so they have to write any, and that's.

[00:11:03] Joe Previte: Okay. So I haven't used that tool, but I'm assuming it's like a, it's like a cogen tool, which will migrate everything. Okay. Yes, correct.

[00:11:10] Nathalia Rus: Yeah. And and by the way, you can use migration. So there's a third strategy on which is basically hybrid, but which is my approach by the way.

[00:11:18] Nathalia Rus: It's hybrid, but that doesn't mean that you don't. So hybrids, a lot of large company may be scared of hybrid and that's why they use All In. So for example, Airable is a company that used codes and they used I think it was a version of Ts migrate as well, that they changed a bit and they've done all in.

[00:11:36] Nathalia Rus: So Airable, if you were interested in Allin migrations you could read Air Table GitHub and they made a very nice blog about that. But I think you could still use Airable strategies, which are code. What code modes are, they're not just for type script, the migrations. A lot of people, when you say code modes say, Oh yeah, that's what type script migrations.

[00:11:58] Nathalia Rus: But no code modes is basically just find [00:12:00] and replace on steroids. That's basically what it is. And so for example, you could use a hybrid approach and say, Okay, today I'm going to fix, to have, so that five files inside of this folder for thanks for example, alters to type script. You could manually the first even better if you do that as a pair programming exercise with a junior engineer.

[00:12:21] Nathalia Rus: You manually do it so that the other engineers see your channel thoughts cease from the scratch. How we arrive there and they. Completely thrown into a project that is all in type scripts, which is very overwhelming. So you can still do the first file as an example with someone. And then you say, Okay, we need to do exactly what we've done now for five other files, or 10 or 20 or whatever.

[00:12:43] Nathalia Rus: And that's a hybrid approach. What you can do is you don't use something like TS migrate. What you can do is write a script for on co mounts where you say, find and replace when you use, for example, this ES six this common GS export, for example, you would use another export or import in K instead.

[00:12:58] Nathalia Rus: Or when you have this [00:13:00] function with saga, for example, you replace. Putting the props. And so I call that a hybrid approach, but which is in between hybrid and or in the sense that the concerns for migration for hybrid migrations, not just training, it's also the fact that it's manual and takes time.

[00:13:16] Nathalia Rus: But then you can fill in those gaps and you can find tools which. Automate the process while still keeping the benefits of a hybrids. The benefits of a hybrid migration as well is the fact that it does not disrupt your work. You can keep going and you can have a backlog of issues.

[00:13:34] Nathalia Rus: You know how it works in companies. Sometimes you have sprints. Sometimes you have times where you completely cram so much work for a launch or something, and then you have times where it's a bit more quiet bit, more, a bit slower. And, you can always have those backlog issues where you do the files left to translate.

[00:13:55] Nathalia Rus: And a hybrid approach can work very well in making sure that you don't have to stop what you're doing[00:14:00] . And also your product doesn't break because you always can run your code as it was before, by doing one error at a time. And also the team is less threatened if they didn't do JavaScript type script before.

[00:14:11] Nathalia Rus: It gives them a lot of opportunity to. because again, with hybrids you can do pair programming where you can show how you're doing something and they don't just have everything in their face at once,

[00:14:22] Joe Previte: okay. So wait let's just summarize those three approaches, which is, so the first is like the going all in, right?

[00:14:27] Joe Previte: Where it's like, maybe it's a small code base or it's a new project and you're like, Okay, we have five engineers, like today we're gonna migrate everything to type scripts.

[00:14:36] Nathalia Rus: And Interesting. The only approach, I've seen more articles about that for large scale companies rather than small scales actually, which is interesting.

[00:14:46] Nathalia Rus: Interesting. So large scale, like scale company for example, what Airtable wanted to avoid was super slow transition where basically you'd have those backlog issues which stay there for months, years, but at the end, no one really do them.[00:15:00]

[00:15:01] Joe Previte: Okay. So that's what they're avoiding. Yeah.

[00:15:03] Nathalia Rus: Which I think could be avoided by the way, with leadership, if you put like priorities and you prioritize correctly, I think.

[00:15:09] Nathalia Rus: I believe, yeah. But that was what they. That's

[00:15:13] Joe Previte: interesting. Okay. That reminds me of, did you see that tweet maybe a month ago from Stripe, that over the weekend, I think they used like a code mod and they migrated like millions of code over the weekend. Yeah. Did you see that?

[00:15:26] Nathalia Rus: Yeah. I didn't see that, but I heard.

[00:15:27] Nathalia Rus: Similar. You heard about it. Companies instead of doing hybrid, which I had expected them to do because it's scary, it's very scary, , but actually they said, Let's just do it in one day. .

[00:15:39] Joe Previte: That blows. I think

[00:15:40] Nathalia Rus: any resources, to be fair, let's say that you do that in one, one command. You have thousands of errors, but you have hundreds of engineers to clean up those errors, that's true.

[00:15:50] Joe Previte: That's true. . I, yeah, I guess like you said, you hit it on the, you hit the nail on the head, with the resources. The large scale company, they probably have a dedicated Yes. JS in front [00:16:00] team or like developer productivity org, Yes, exactly. Yeah.

[00:16:04] Nathalia Rus: That's interesting.

[00:16:05] Nathalia Rus: Yeah. Okay, so there, there's no, interestingly enough it really depends on the leadership. I've seen big companies, Choosing to go hybrids, but also all in there is no stereotype of or big company. We will pick that one. For small teams. However, all of them used hybrids except one, which is a friend of mine has a startup, and they chose the all-in migration toward Ts migrate.

[00:16:29] Nathalia Rus: And it got them more headaches than not because again, they have a small resource team and it was harder for them to fix all the different errors that they had. One by one manually rather than, doing the migration themselves, having full control of what causes what, some people I think, make a mistake by trying the oil in migration when they don't need they very small.

[00:16:49] Nathalia Rus: And I think big companies, I don't know why they choose to have the oil in migration. They all say that it's for. But again, I guess if they have the resources, great. And if they have [00:17:00] the managerial capacities to make sure that those resources are used effectively. Sure. It is more risky though.

[00:17:05] Nathalia Rus: Yeah. It can break your product.

[00:17:07] Joe Previte: Yeah. Yeah, so I guess the trade off then if we put ourselves in a leadership position at a company, I know you are, but let's just say a fictitious company and we're making the decision whether to do an all in approach or like a gradual approach.

[00:17:21] Joe Previte: I guess we have to balance, right? Like you were saying, are we in a sprint where we're trying to get a product out quickly? If so, which approach should we.

[00:17:31] Nathalia Rus: I think it depends as well on the goals of the company. Okay. If you're such in a rush, what is your reason to be in a rush?

[00:17:36] Nathalia Rus: You see what I mean? Yeah. Is your reason that you need a huge cleanup? Because every day spent on JavaScript is making you lose money because there is a complex app that is not being maintained properly, and that means that it's urgent. If you don't have all of your code based in size scripts every day makes.

[00:17:54] Nathalia Rus: And that is okay, we're going to have an urgency day where experts are going to clean up the [00:18:00] whole code base, and we start from scratch with, everyone being trained at the same level, and then it's okay, resets. So if it is expensive for you to have JavaScript files somewhere and whatever, or you feels messy, et cetera, that might be worth it.

[00:18:13] Nathalia Rus: I think most use cases, however, would be more for the hybrid approach. Again, I think that fits more cases where there's no urgency, but it would significantly help build maintainable code over. When it's not like a short term goal of urgency, it's more long term. We've realized that we spent engineering resources on maintaining.

[00:18:38] Nathalia Rus: Rather than building new features. And the reason why is because it's very difficult to navigate and it creates a lot of random bug. . And then, you may say it's okay if it takes us three months to or even a year because we are a company on the long term. And also it may be a diff a question for the leadership team as well, for understanding what they want in terms of the engineering culture for training.

[00:18:58] Nathalia Rus: So again, Yeah.[00:19:00] You don't want to have. Engineers being thrown something completely different all at once. I think that's, it asks for a large coordinated efforts on training, making sure that from the day that the code base is in type script, you have guidelines over, what to do, training resources so that everyone is on the same page.

[00:19:21] Nathalia Rus: Gradually is a bit easier, I think, because you don't have to train everyone at the same. You can have, you can give some issues to some people where they start getting themselves familiar with type scripts and they can themselves then review PRS again to other people who are learning type scripts.

[00:19:37] Nathalia Rus: And you don't have to have everyone at the same level on the, from the same day. You can manage it's aro code, you can throttle, the amount of training that you need to give to.

[00:19:49] Joe Previte: Yeah, that makes total sense cuz I guess if you do the all in approach, day one we come into work, it's JavaScript, day two we come in, it's all type script, and it's shoot.

[00:19:58] Joe Previte: Like I didn't have any [00:20:00] time to like breathe and prep, yeah, exactly. Versus like the hybrid approach where it's okay I know some prs are gonna come in that have type script. I'm not familiar. I'm gonna review them anyway and start to get familiar. And I feel like that might lead to less burnout and more learning.

[00:20:17] Joe Previte: Yeah. And people will probably feel more comfortable,

[00:20:20] Nathalia Rus: more learning for sure. Because when we are onboarding another en engineer Angela She was a junior engineer. She still is, but if she's not junior anymore grew very fast in a year, but it was the first time that she was looking at type scripts.

[00:20:36] Nathalia Rus: And so when I onboarded her, I went through a pep many per programming sessions with three days where I showed her, Okay, turn that to Typescripts. Do that together. And then with her, I was basically looking through different files in our code base. I was like, How would you revert that to text group?

[00:20:50] Nathalia Rus: And like even like in any order, Because I think reverting to Joki was an interesting exercise for her. Once, you don't need to dialogue, just to have her understand the shift in think.[00:21:00] What does it feel like to work in JavaScript compared to, what does it feel like to work in type script just next to the other, And the difference is Mad , and yeah, and she was like, Wow, , how would I, how was I doing before the type iPad was like don't look at the file. You don't have to remember by heart. Now you can just how you to complete, what kind of type you are expecting, but doing those peer programming sessions. Were super important because she had so many questions like, and she was stuck sometimes, and I would let her be stuck.

[00:21:28] Nathalia Rus: And again, the way that I learned was to be stuck, even if it was slower, by being stuck and overcoming it. I learned a lot, which is not something that you have when you are given code, which is already in type script. You don't learn as much because you don't know how those saga or those things, for example, have been translated.

[00:21:48] Nathalia Rus: You haven't learned that. So basically your growth will not be very high. You will understand how to read tab script, how to write types, but Taki's not just about that.[00:22:00] We are using a lot of like complex types in whatever nowadays because we really enjoy doing stuff in that grade. But this is genuinely because I gave her the opportunity.

[00:22:09] Nathalia Rus: To do something from scratch. And that's not something if you spoon feds, you will only do those superficial level unless when you grow to like another level of engineering. But that may take more time. So I think for the culture, engineering culture, I think it's kinder on the personal growth of people to have a hybrid migration, in my opinion.

[00:22:30] Joe Previte: And on that same topic, I wanted to talk about like working at a smaller company. Were there any fears for you of adopting type scripts and then it being difficult to like, hire for, or train people for were there any thoughts around that?

[00:22:45] Nathalia Rus: Actually it gave me a lot of safety feeling in the sense that, onboarding a junior engineer is.

[00:22:55] Nathalia Rus: It's way easier to trust them, not on the personal level of course, you have someone who is a junior [00:23:00] engineer, you can't expect them to code without making mistakes somewhere, that has to happen, and that's part of the process. That's part of the growth, and I was there like, okay, I'd rather have type script because then one, like they will see, they will catch a lot of bisex themselves because there is the compiled time error. So that means that, the code that I will review at least runs , stuff like that. Or, at least I know that, for example if a object property is user underscore ID and not user Id ID and capitals, small things like that, that, when you are, you have so much work to do.

[00:23:35] Nathalia Rus: You're reviewing a pr, you're looking at the commit diff. I would not be able to know by heart whether user underscore ID was correct and whether they should have put user ID with ID capital. A lot of small things like that. So for hiring, I'm not talking about the talent here. I'm talking about from the point of view, like concerns regarding hiring.

[00:23:52] Nathalia Rus: I was more at peace by knowing that I would have junior engineers contributing to a type script, code base rather than [00:24:00] JavaScript code base where they could do a lot of stuff wrong, and I would be able to not see it all the time when I'm super over. Basically, so actually hiring in a small team, even, in small, the smaller the team as well, the less the resources and the more overworked you are.

[00:24:15] Nathalia Rus: So even in a small team, yes. Having type script for making sure that type safety is there. And is, and maintainability was, there was a plus regarding this. There's way more trust now regarding the actual talents. It was actually easier to hire because people who never did type. We're excited to learn because they said, I don't like type script personally, but there's a lot of trends, , and right now everyone is asking for a type script developer.

[00:24:46] Nathalia Rus: So even the people who didn't like type scripts we're excited to learn just because on Twitter and everywhere there was this pressure and they didn't want to be the only Java developers basically. So there was this [00:25:00] fomo. Even on people who didn't like that script physically, and they were happy that I was not asking for a type script experience person, which is a lot of jobs out there.

[00:25:09] Nathalia Rus: So actually it does give you an edge more than not. I've seen, I would say I only received one candidate who said, I wish there was not type scripts, and I received like hundreds of candidates, like 400 or something. Wow. . At least they didn't communicate that to me and they did apply. There's only one person who applied to me and said, I wish it was not.

[00:25:30] Nathalia Rus: And I think they could have been convinced .

[00:25:32] Joe Previte: That's an interesting thing to say though, I wish you weren't using, X language. I don't know. I dunno if that's gonna help you get the job.

[00:25:39] Nathalia Rus: Some skip tourists.

[00:25:40] Joe Previte: Yeah, I guess so. But yeah, for you, I wanna dive into what you were saying earlier.

[00:25:45] Joe Previte: I think that was really interesting. So you said, the person you hired to the team was a junior engineer and having typescripts gave you more confidence and their ability to succeed at the company. . . So it's almost I guess if we're to like dive into that a little bit, a [00:26:00] company that is using type scripts, like you might be more comfortable having a less experienced engineer.

[00:26:07] Joe Previte: Type script brings you confidence and trust. Is

[00:26:10] Nathalia Rus: that accurate? Yes, that is accurate. Confidence and trust in the fact that the code is auto documented in that way. When you read the tab script, code base again, that's the thing which I learned by trying to integrate the packages in tab script, right?

[00:26:25] Nathalia Rus: I looked into the source code, I go to definition, and I could see the node modules, what the package was made of. And so you are like, Okay, your code is easier to understand. So the chances that they understood the context without having a full on debrief meeting is, And the chance of them understanding the tools that they can use.

[00:26:50] Nathalia Rus: But for example, when I put like functions, when I create issues on linear, cause we were using linear for managing workflows, I would create an issue on linear before we were doing issues. But linear is great [00:27:00] as well. I would write for example, use X function, and I would not have to.

[00:27:04] Nathalia Rus: Documentation over what this function wants as an argument. They can, write the function automatically imports it, , and then, they hover on. And they can see what it's meant to receive and what it's meant to take out to return. So to me, it is possible to have complete trust regarding this with junior engineers, if you spend a lot of time documenting everything and writing super specific issues where they know exactly what is expected of them.

[00:27:33] Nathalia Rus: Sure that takes a long time. And as I said, smaller teams may also less resources. So realistically speaking, you know that something will go wrong at some point. So you have to spend way less time. Specking something for someone, because in some ways the code specs itself to some degrees. I'll give you so like a random example.

[00:27:51] Nathalia Rus: But, , we are using a file which I really love, . It's very simple, but it's pretty cool. It's index file index OTs within the icon [00:28:00] folder and basically all of our icon. That we use or define in that file. And there's a switch case and you have to pass the idea of the icon that you're trying to access.

[00:28:09] Nathalia Rus: So it can be copy, download, upload, and at first there's only three icons and when you grow the company and the product, you end up with a hundred of choices. It's like having your only little library of icons basically. Yeah. And again, thanks to type script, it's really cool because when I, when I pass design to someone I do the design as well, so I do the design, pass it on to Andrea, and when she sees an icon, for example, like it's very easy.

[00:28:35] Nathalia Rus: You can just literally in your code start to enter the the strings, right? And then you have the auto completion, which basically says it lists all of the ideas of the icons available so that I know that we are not creating. 20 different copy icons of different sizes all around the code base.

[00:28:52] Nathalia Rus: And she won't create a duplicate copy icon because she would know whether there is one already. And if it doesn't exist, then she can see that it doesn't exist in [00:29:00] the IDs and say, Okay, I know what is expected of me, it's expected of me that I go to that index file and I add the ID and I add the svg.

[00:29:11] Nathalia Rus: And so this is the kind of thing where if there was not type script, I would need to write what. Talked about, I would need to write, Okay, there is an index file where you do that to other thing. I want you to add the ID cetera, but because it's suggested, she like intuitively, you understand, Oh, that's how it's supposed to work.

[00:29:29] Nathalia Rus: Understood. . So that's how you can also grow the code base with the habits that you've built from the start, which are good habits. Hopefully if you've done your work and you know that those foundations that you put in the code base, because there are self documented that it's suggesting new engineers to adopt them and they have an example that is easy to find.

[00:29:51] Nathalia Rus: So for that reason, yes, there is more trust. In having type scripts, and it's not because they're bad engineers, it's purely because it's easier to understand the context. Even [00:30:00] for myself, it's better for me to go back to a feature which I've coded last year, and understand what I was trying to do, so it's not because they're bad engineers and there's no trust, it's because it's allows them to succeed.

[00:30:12] Joe Previte: Okay. So it's really like what you just highlighted there, right? Is the auto complete, the, in inte sense , that TypeScript gives you as a developer and like these patterns become, Documented and you don't need to have a separate markdown or like document like notion or whatever that explains, here are the patterns that we do, right?

[00:30:32] Joe Previte: Like the pattern is, it's almost embedded within the code. And a junior, a senior, like whoever can follow that. And it's just it, because it's a characteristic of the language, of a type language.

[00:30:43] Nathalia Rus: 100%. Something which is worth saying for documentation is there are some cases where, In migrations I documented, and that was that was the, that were the types that I created when I saw repetitions in the code.

[00:30:58] Nathalia Rus: And for example when we [00:31:00] migrated some files, what I had done is, okay, make sure before you create a new type. There's not a type that I did in another file, , another type definition file, which satisfies the same kind of properties because then you can reuse the same. And so I think in migrations it's important to document when you create a new type document, it don't expect that people will check all of the type definitions, files and modules to check what types they are.

[00:31:23] Nathalia Rus: There. You create a very neat documentation like collapses and whatever. When you say the types of type that you've done, for example, form. Data, for example, api data, all this sort of stuff. And so that people when they have to translate to JavaScript, five type scripts, they have a neat, very structured document next to them.

[00:31:44] Nathalia Rus: And when they have to create a new type, they can say, Is there anyone that, is there any type that repeating here? Or even for refactoring something that when I did that, I realized that in all forms, so we had very complex forms. Okay. When I say complex is complex in the [00:32:00] sense that there were many. Within one form with a final submit data and 10 steps.

[00:32:07] Nathalia Rus: And there were attachments, like photos, more than one. A lot of random different types of data, like dates, oh my god. Conversions for invoices with like currency conversions, and also like mouse conversion to kilometers. We had everything in those, like onboarding process for creating an entry we had to simplify at the end, but at the start I had designed it to be like a monstrous kind of 10 step.

[00:32:32] Nathalia Rus: So I was like, Okay. So I said, You know what? I just will code like the files that look the forms that look like each other. Like for example, some type of files, like for example, just text inputs, for example. I'm just going to create those, to make design and have repetitions amongst the different types of forms that, I don't see how I can generate all these ones, like automatically, without that.

[00:32:57] Nathalia Rus: And then when I was doing type script, then I [00:33:00] said, Wait a second. All of these forms, actually they were the same. It's just like conversion is optional. Stuff like that, like the type of error, for example, you can standardize all of that and you can have type of form, you can say, is it an end value for example, for a number?

[00:33:16] Nathalia Rus: Is it a text value for a text, all of this stuff. And I said, Whoa. Okay. How ? I said, The way to think of type script is you can superpower your occur to the level where you can go way faster. Initially would be a bit slower, but now, a year later I wanted to create I, I needed to create again, another form, which is a monster form with different steps.

[00:33:41] Nathalia Rus: I didn't have to rewrite anything. The only thing that I did is add an object. Which had the keys. The keys were the steps. Okay. And then within the steps, the keys were the properties of the fields. Okay. And inside of those properties, of the fields were exactly the same data. It was value, ever like conversion, [00:34:00] optional, stuff like that.

[00:34:01] Nathalia Rus: And so the only thing that I had to do a lot of what, for a lot of people would do a lot of code, I just had to write that object, define my steps, define what I expected inside of them. Boom. Done. It took me like 10. Wow. And and that I would not have been able to cut this thing without type script because one, you don't think in those terms, and two, like the ideas of the fields, for example, the ideas of the steps, you want to make sure that you are not thinking typos, which is very possible when you have like hundreds of forms.

[00:34:32] Nathalia Rus: And so mainly making sure that those are some. It works super fine. So yeah, like migrating to Cript also made us not just rewrite the same codes in Cript language, more safety. It actually made us better engineer in the sense that it, I think. Coding in different languages is like coding in type scripts to different language, right?

[00:34:57] Nathalia Rus: It does give you a more holistic approach [00:35:00] of programming in general because you see a new realm of possibilities. When you switch different between different languages, you see their flows and their strengths and regarding to their flows. You can try to understand how you can fill in those flows, fill those gaps.

[00:35:15] Nathalia Rus: And so I think that Taki does make you better developer in the sense that for Jarris Creek, people never really coded in object oriented languages before. And I think having a new paradigm, a new way of seeing how you define data, which is less functional and. Well-defined is really important because the weakness of JavaScript is chaos.

[00:35:35] Nathalia Rus: And I think so, yeah. And and I think that bringing a bit more order and not bringing the object oriented and I think. And by not fixing, but by enhancing a language, by fixing its weakness, which I think yes, does fix, I will own that type script. Will does fix the weakness of JavaScripts in that regard.

[00:35:55] Nathalia Rus: Then you have a better JavaScript and with better JavaScripts, you can leverage it trends and build [00:36:00] better code. And when I say better code is that, as I said, I could create those forms in 10 minutes instead of spending a week on it. Or if not I don't think it is too shy away in any way.

[00:36:14] Joe Previte: Yeah, that's the forms thing, like going from one week to 10 minutes, that's crazy. Yeah.

[00:36:20] Nathalia Rus: And imagine the maintenance behind that as well, Yeah. And it's not even difficult to maintain. At all because for example, as I said, at first we had at least 10 different steps for that one form, and we realized, obviously, but you realize afterwards, okay, that's too much.

[00:36:34] Nathalia Rus: Let's remove some, let's see, remove some fields. That was so easy to do because the only thing I needed to do was remove form the object that I created, which derives which from, which derives all of what you want to do. I just had to. From that object the key and the subject from, for example, the field, which was like, I dunno, like invoice name number two, something like that.

[00:36:54] Nathalia Rus: You just have to remove that, the data that you want from that object or edit, edit it, or just say, Okay, that I want to [00:37:00] be a number in for any reason rather than a number in number. You change the. That's it. And Andrea asked me the question. Andrea said, Oh my God, that looks like a man, like a nightmare to maintain because everything is too convolute.

[00:37:14] Nathalia Rus: And I said, It's not convoluted. Because it's very easy to navigate. You can see where everything comes from. And to maintain it's the dream because trying to like manually go through where every file is to change and copy and paste and whatever, something you just change the source data the data of truth where everything is defined at the start.

[00:37:35] Nathalia Rus: And you edit or. That's it. Super easy to maintain and I can say that with confidence cuz I did this whole thing last year and since then I've used that cons consistently both for modifying data, for creating new data and for delivering data. So it's not if I just found the solution last week and then I solve problems, or maybe they would be problems that I don't see yet because it's too early.

[00:37:57] Nathalia Rus: I've been using that same thing, which I coded last [00:38:00] year for a year, doing a lot of work on this and it's been a dream to.

[00:38:05] Joe Previte: Wow. So it's having this like single source of truth. Yeah. Yeah.

[00:38:11] Nathalia Rus: Having a single source of truth, which is, it's been like a reducer reduction user. Okay. You have like your reducer with.

[00:38:19] Nathalia Rus: Which contains like the object of your global state. And at any point, everything that's happening in your application, you can see where you are at in there. But obviously it's more flexible than Redux. But, it's the same principle of try to have like at a high level and then a lot of higher components.

[00:38:36] Nathalia Rus: And then something like atomic design where then you go down in, in the structure of your codes. Having basically at the low level, when I say low is from the bottom, what you have is purely UI components, no data. Okay. And then you have on top of the UI components, okay? Which are purely ui, purely functional components.

[00:38:56] Nathalia Rus: On top of that you have the thing which is more like a [00:39:00] ma, I call them the managers, basically. For example, this is where you'd have a switch statement, for example. Is your field property, something like, I'm expecting this to be a number. For sort of value and therefore you would render the UI component, which is a number type of form, with a number input.

[00:39:17] Nathalia Rus: Is this going to be a checkbox, And then, you would render your UI component, which is a checkbox and you would map through it. There's more than one stuff like that. And then so the manager is basically there, like there's no UI in the manager. It's purely there, like taking the data, which is above taking the object, getting the proper.

[00:39:36] Nathalia Rus: And understanding what you're trying to render that, and then above the manager, the da, you have the data which you pass through the manager, which goes through the UI basically. So an example of where something super cool as well is how I basically build something which is similar to what press for internal team in terms of I wanted people I wanted the marketing team to have their blog editor, the blog building [00:40:00] builder.

[00:40:01] Nathalia Rus: Their blog builder. Yeah, I think that's how it's called, Blog Builder. And because I didn't want to have like backlog issues where we would have to add more blog. So I wanted them to be able to create a blog post, but I also wanted them to create something which had like grids, image grids bullet points.

[00:40:19] Nathalia Rus: Bullet points were easy in terms of editing, but it was more around images, many different possible of possibility of over images. And there, how they would. And for that, I've built something which generates that. And again, I've used the power of test grid for that . It's exactly what I said.

[00:40:36] Nathalia Rus: When they click on a button on the grid, et cetera, I basically modify my object and the properties within, and then I pass that data, which I've created based on the ui, based on what the user chose. I complete an object with what is expected. And then that object goes to the managers. The managers have a lot of switched statements and based on what the object tells them is expected, they then puts like a, like Legos like [00:41:00] puzzle, like all the different UI bits, elements that were supposed to be rendered.

[00:41:04] Nathalia Rus: Again, without type scripts, no. I would have had to manually have a lot of code issues to create. Hey, Gil wants to create like a grid with seven images, which are of this width and this hate. It's. Okay, let's do that manually. . No. And that's how we were able to have the Apex, which is a very very known now hopefully in the uk publication for core owners, for specialist scars.

[00:41:30] Nathalia Rus: We had to pose it for the seed one, but now that we trust the seed one, we'll go back again. But we basically had people doing like so much work, more work on pushing contents every. Of high quality content which had a lot of images and all of the blog posts look different. Basically they have a different styling.

[00:41:48] Nathalia Rus: There's different grids agencies. And I've done zero work on it, . It's just been all generated and they chose every week drag and drop to to build it as they wanted. And again, [00:42:00] without type scripts, I would not have been able to do that. I think we would've had to hire another engineer, by the way

[00:42:05] Joe Previte: Wow.

[00:42:06] Joe Previte: TypeScript saving you engineering resources. . Yeah.

[00:42:11] Nathalia Rus: In that example, Yeah. Yeah.

[00:42:13] Joe Previte: Yeah. That's amazing. Okay, I know we're getting close some time, so I think let's end with one question, or I guess the final question, which would be, what advice do you have for teams who are thinking about migrating to types.

[00:42:30] Nathalia Rus: I think the advice that I have is very high level because I believe it's actually the best advice. One is prioritize. I think assuming that you are choosing the hybrid approach, which I believe is most cases out there you won't be able to or you shouldn't be able to just randomly pick a file and say, Oh, let's take these types of JavaScript file in 22 transcripts.

[00:42:51] Nathalia Rus: There are a lot of different places in the code base where type C will objectively be more suited to help you on the short. Act straight away.[00:43:00] And I think for example, a very important part of the project that you should be looking to prioritize, for example, would be the API first, that to define what you're meant to receive from the back.

[00:43:11] Nathalia Rus: Stuff like that because then you'll see that you will have to handle, for example, what happens is this returns undefined because maybe the user didn't give you this information yet. Would it be sometimes you realize, Oh, okay, this could be undefined, this could be, no, this could be an anterior array, et cetera.

[00:43:25] Nathalia Rus: And depending on how you are using your UI component, you don't want to just test it and define, Sometimes you will break something. So I think trying to find priorities in your code, Where you believe that it will do the, it will actually do your benefits to have that faster that's important.

[00:43:44] Nathalia Rus: And then I think setting code improvement goals or important, So when you're looking to migrate to task grid, I think you should think of it in a philosophical standpoint first because it will feel very overwhelming. and very messy. Cuz there's a [00:44:00] lot of work to be. And I think understanding, why am I here?

[00:44:04] Nathalia Rus: Why am I doing this? Because sometimes when you want, for example, to write an any, because then you could check box. The fact that you've translated a file, you know that it's on paper only because actually you haven't done a proper migration. So having the motivation to go through it is really important.

[00:44:20] Nathalia Rus: And the way to do that is by setting yourself goals. What do I want? Do I want to become a better engineer? Do I want to learn how to train a team? Do I want to make sure that it's more maintainable? Make sure that you pick your principles, you're guiding principles, and you revisit them when you do the migration to make sure that you are not cutting corners somewhere where you shouldn't really be cutting corners, basically.

[00:44:41] Nathalia Rus: And yes, getting principles as well. So it's a bit different and call improve. Getting principles are a bit more practical. They would be like, I think the leadership technical person should literally have a sort of like Wikipedia , where they just give snippets examples where they say, Okay, here you have different options.[00:45:00]

[00:45:00] Nathalia Rus: I would prefer this option. So for example, for when do you create a new type as opposed to adjust something to fit in a type by adding. Yeah. Cause you can technically, you could fit so many types into one by just having a lot of optional fields. There is a limit and there's a balance to how much is helpful and how much causes problems, especially with undefined health or a lot of things.

[00:45:24] Nathalia Rus: And I think having clarity over as a team what balance do you choose is important to make sure that you have a consistent code. So that, so basically three things. One, prioritization two is set code improvement goals, and three is getting principles on practical levels.

[00:45:44] Joe Previte: Awesome. That is fantastic.

[00:45:45] Joe Previte: And thank you for the summary there at the end. Last thing then. Where can people go to connect with you or find you online? Follow up on your work?

[00:45:52] Nathalia Rus: Sure. I'm at ER's code both on Instagram and Twitter. And it's quite cool because I had created this [00:46:00] account called ER's code when I started to code five years ago.

[00:46:03] Nathalia Rus: And at that time there was, you treat no girls in coding. Like I went to hackathons and whatever. There was no one. And I heard a lot of rose opinions, which were. Very strange for now, and five years later, it's weird to have ye skirt because I see women everywhere, , and it's super, super integrated, and and diverse and we are getting there, which is pretty cool.

[00:46:26] Nathalia Rus: So yeah, I have a archaic. Name of an account, but I keep it cuz I'm proud of it that we went through this . Yeah. It's, yeah. Gross

[00:46:33] Joe Previte: code. Awesome. Cool. Cool. We'll sh we'll put all those links in the show notes. We'll link to your startup custodian as well. Yeah. And thank you so much for taking the time to chat

[00:46:43] Nathalia Rus: with us.

[00:46:43] Nathalia Rus: Thanks for having me. Super happy.