Hello everybody, and welcome to another episode of React Roundup. My name is TJ. Van Told and with me on the panel today is Jack Herrington. Hello, and our special guests today are Mark Story and Priscilla Alivera. Hopefully I pronounced her name correctly. Yeah, welcome, excellent, welcome to React Roundup. Why don't you introduce yourself and tell us who are what you do while you're famous those sorts of things.
I don't think I'm n okay okay 'all, thanks for having me. My name is Priscilla. I'm a software engineer based in Vienna, and I'm a grank To employee That's Sanctuary work on the user interface of our application, so I'm more like a front end engineer.
I'm Mark Story. I also work at Center It's Prisona. I work partially on the front time and then also a lot on the back end on their building system. And I'm in Toronto, Canada.
All right, So looks at y'all have an article out on converting from javascripts to typescript for your application and what the advantages work, and you kind of give us a bit of a high level synopsis on that.
Yeah, so the high level synopsis is we converted the application from JavaScript to typescript. To Typescript is a statically analyzed language that compiles that a JavaScript if you've not used to it before. And so over the coross of eighteen months, we converted the whole applicate, the whole front end application for Century from JavaScript from JavaScript into typescript, and then we wrote a blog post around how we did it and some of the challenges we had and some of the benefits of that.
So, what were some of the challenges you had.
Big code bases take a long time to migrate. I bet so for scale like Centuries, around ninety thousand lines of code in JavaScript, and yeah, it just took a really long time because we weren't allowed to stop delivering features. So yeah, the process we kind of documented was doing that without stopping. Because there's kind of like two approaches you can take with converting a large CUD base. You can like try and freeze the earth and do everything
at once and then not do any future work. And the other one is like do a re right, which is also very dangerous, and the other one is that we approach we took, which is like you modify the code in place and then incrementally kind of change things over.
I guess maybe we could start with what precipitated this change, like where you internally sold and typescript and decided it was the right move, because obviously putting in that whole effort, you must have saw some value in doing the work.
Yeah, I can answer that. I guess the impetus was we were having we had several kind of production incidents happened, customer facing pression incidents that were caused by front end problems and the after like in the retro for like why did we have this incident? A lot of the like paths forward where you know, if we had better tooling or static analysis, then we would be able to
prevent these kinds of problems. And so that was kind of that happened multiple times, and the solution came up multiple times was to you know, if we had better linting support or better static analyzation that could come from a tool like touch script, then we would be able to prevent these kinds of problems because they would be compiled tim errors versus runtime aerrors that we catch in production.
So that kind of came through and then a century overy year has like a hack week, like many companies and a bunch of engineers took the time to kind of start the genesis of touch script conversion and make it possible to incre mentally move the application over as part of their project, and then so we have kind of a proof of concept, and then from there we were able to get buy in on converting the rest of the application over.
I'm curious the setup because I sort of agree with your how you laid it out, Like when you're tackling something big like this, I think very often, at least in my experience, freezing everything, like for a big rewrite is almost never an option, just because like, if you have an app that's that much code, chances are it's doing something important, and chances are you have to keep
updating and working on it. And also, like business users don't tend to like things of like, yeah, we're going to spend two three months on this and you'll notice no changes. Hopefully you'll notice no changes because we might break something too, right like those those arguments don't go
over so well. But I am curious, like because I've absolutely never attempt this with Typescript specifically, I'm very curious of the architecture you came up with to make this possible, because I'm assuming like you were pushing out typescript files like or at least I'm assuming it's a mechanism where you could like convert one file the typeescript, push it up, push it to production or whatever, and then just like keep on working. So I'm curious, like, how like technically
you set that up to work. Is it just like some fancy webpack canfig or what was going on to make that possible?
Oh? Yes, So we decided on converting our files incrementally to type script, and so every day we were pushing files to production and we used our own.
Application to monitor errors.
Yes, and so we had to use some webpac confix some configuration to be able to do that. But this is something nice in type script. You don't need to convert the whole code base at once. You can do it incrementally. So this was also one of the reasons we decided to introduce typescript.
So how many developers are on your team and how did they fare in terms of learning pypescript And you mentioned in the articles some educational stuff. How did that work?
So I think we are twelve developers. Some of some of our colleagues.
They only work on the front end, and some of our colleagues they are FULLD stech. So the education was the key in this process because some colleagues they didn't know much about typescript and we would like to. First we created a documentation. In terms of documentation, we also tried to motivate the colleagues to adopt a typescript and once they saw the benefits, they started to use typescript by themselves. So we never used the tooling to block some on of pushing JSX COLDE to our code base.
This was naturally. This happened naturally.
So what were the big like aha, benefits for these front end developers on like, oh, now, yes, typescript, that's awesome. You know, it's so much better than JSX. Now I'm never going to do JSX again.
So auto completion for example.
Yeah, yeah, I would say like autocompletion and compile time checks were the two big ones. Also, like improved code navigation, so instead of having to get your editor to go up and find the symbol ref like most editors, when you have the language server setup, you can jump to symbols or like preview symbols in line with like little floating windows. And so because the editor ecosystem, the touch script team spent a lot of time making like the
dev experience really well. It was that like improved developer experience that really kind of like helped convert people over.
Just a quick follow up, so for editor we're talking vs code, we're talking web the Storm or what.
Yeah, so we have of the twelve to twenty people that work on the front end, there's a mix of people in bs CO. There's some Vim users and then there's some like web Storm or like pie Storm pie chterm users as well. So getting it to helping people get set up with vs cod is pretty straightforward. And then the VIM users have their own like flag channel where they all share a vimscript and you just hang out over there.
I don't know what you all are doing, hu, I imagine you a specially invite to and it's I'm.
One of those Vim people as well. So it was, yeah, we all work together to get it all working nice. So yeah, once once everyone had their editors set up, then the benefits become a lot more visible and a lot more tangible. And through that and like a code review like Priscilla was mentioning we're able to kind of
like a guide and educate people forward. And then there was also some pair programming along the way, like you should do this in in the persons I don't know, and then we're like, okay, well we can just sit with you and help you or like video chat with you sitting. But yeah, that's the kind of approach we took.
It's impressive that you did it over a pandemic, that's for sure.
Yeah. That affected the timelines. Yeah. When we started the project, the timelines were like RMVP was like, well when do you think you'll be finished? And we gave a timeline which was complete rubbish. The pandemic came and then the timelines were very much rubbish, and then we were dealing with like team burnout. So yeah, just like trying to keep people motivated was one of the harder parts. I would say.
One kind of nice thing or fun thing I see in your article is you have on here that it's certain points, like certain messier points. You would just leave in comments that were like to do use like tackle this later, And personally I kind of like that because it's like you're talking about like using the typescript like any, which is like the get out of jail free typescript trick.
But I'm curious about that approach. I think I actually kind of like it because I'm guessing your point was you want to get this conversion done right, like addressing some of the messier type script aspects would potentially break your code unnecessarily, when really you just wanted to get things changed and get things out there. Presumably.
Yeah, I would say we tried to use any sparingly. We tried really hard to do the proper typing, but there are some places, especially where our type striped interfaces, where with React, where you can't type it all properly. I think it's like create ref as the one that is really annoying, Like you can't put generics through create create ref it drops them. So we had we had a few things like that, And we have a lot of like higher order components because Century is a long
lived REACT applications, so there's many different patterns. There's a lot of higher artwork components, and we had a lot of problems with like default props not being able to tunnel their way through through a higher ardor component. So those are some of like the Typeescript challenges we kind of like had.
To hack around, yes, and we used to do so we can now after the conversion, we are doing that. Now we are checking those places, those places where we added to do, and we are trying to find a better type and yeah and remove to.
Do with the correct tack.
And we were using libraries that had some like not ideal typing support. So we're using create react class and some of the types get kind of squidgy when they go through create react class. So we went back and like removed all of create react class and like tried to simplify some of the higher components. And we still have a budget to Doo's love to do. So while we're while we're done, we're not like one hundred percent no any anywhere. There's still some.
So when just typescript it was it was kind of more generalized. Repass it with the whole system and refactor some of the old cruft it was stuck around in there kind of thing.
Yeah, we tried to try to focus, like when you're converting a file to type script or converting a module to typescript, like just do the typescript conversions, don't make too many run time changes unless the typing becomes really really challenging, because conflating the run time changes with the with the type changes kind of sets you up for more problem BOMs than what you you'd want to take on at this point in time.
Oh loo could go wrong.
Yeah yeah. Another thing that helped us make progress was to kind of put like a moratorium on any like other large scale refactoring. So another thing that we've been battling with is is enzyme is no longer being maintained as well as we would like to have, and we want to like be upgraded to REACT seventeen, and enzyme
required some workarounds to make that work. So we also wanted to shift off of enzyme for testing, but we didn't want to start that until the typescript was finished because we'd have too many like inflight projects, and you get everything half done and then everything is just awful for a long long period of time.
Yes, we also we agreed that we wouldn't.
Use reacted hooks before the conversion, before the conversion was complete. So this was one of the things that's motivated MEATS to convert to even more fires.
I think not only be but to many many other colleagues.
So finally, now after the conversion, we can use react to hooks.
Yay much better.
Yeah, all right. I mean it's only been a couple of three years since React Hooks came out. I think something like that two years. It's been a while. Yeah, yeah, it's nice. That's a long time. So interesting A question
for you about the educational side of the house. I've actually done a lot of Typescript education and written, done a bunch of videos on it and all that, and a lot of questions that I get are around the misconception that Typescript has a run time to it, that it's going to bloat your code because it's going to do all this type checking and things like that. And I find it challenging to kind of get through to folks that Typescript is just at compile time only. There
is no run time version of Typescript. How how much of a challenge was that for you to get that across to your team members and what do you say or do to make you get them to kind of grock that.
I don't remember that coming up as a big problem. We're fairly conscious of or bundle signs, so like just comparing bundle size from the code that webpacker's generating from, like the down compilation from like Yes six down to or whatever version we were on, but Yes current down to Yes five, and then comparing the typescripts compiled down. We'd be able like it was pretty easy to demonstrate,
like there's no significant runtime cost on bundle size. So I think that was the way to end that argument, was like the bundle size is actually the same or smaller, so it doesn't matter why typrip is doing it right.
Well, I think there's also things like like, for example, if you put it an interface around where you're saying, okay, this is what we expect from the server, right, and then you get a response from the server and it doesn't match the payload although the type that you have in the interface, and people kind of expect that. Oh wait, I thought typeseop was going to validate what was coming back from the server. And you're like, no, that's not the way that No, that's not type peop's not going
to do that for you. So is that something That kind of thing is something that I find challenging.
Yes, yeah, so we are fortunately actually don't we don't have our payload to type it. So many times we have to cast it or we already know what data we are going to get, so we we we add in the front end the correct type.
But that's that's what we do.
That's what everyone has to do, though, Like there has to be at the network boundary, you have to be like, this is what's coming in. I promise.
I think you swear, I promise. That's the thing, right. I think I think people have this understanding misunderstanding like oh, type that actually going to be like a joy or a yup which actually goes through and literally checks to make sure that like oh there should be an idea here and there's not that kind of thing. But it's not gonna do that. Yeah, no, it doesn't do that.
That's her.
Are there any other learning guides you would recommend, like any like you know, courses or books or anything that you use for for learning or teaching others that you might recommend teach typeescript. Yeah, and if not, that's okay too. It's just so I.
Think in my face. For example, I learned it on a daily basis. I needed to do something, so I googled it and then I found a solution. I tested and tried some things out, and yeah, I think it's pretty much it. That are a lot of materials on internet. Yeah, but I don't know one specific.
Yeah, I think we gave people like some links to like learning typescript guides, Like there's a couple of well published webbooks that are good. The official docs are really good, and there's a lot of like if you want to learn it, just like like message one of us on Slack, we'll sit with you and talk you through it, or like work with you on it. And that was a lot of how we did it. And like I learned
to strip through this commersion. I never used typescript before, so for me, it was just like learn on the job, how do I do this? Like, Yeah, a lot of a lot of that and my reading other people's code stealing ideas.
When I joined at the Center, the typescript convey ession was already happening, So I was happy because I had typescripts and knowledge, and I was glad they could help the team consequently speeding up the process so then we could use hooks for example.
Yeah, so I'm curious now that you have typescript out in production. Well, I guess, first of all, has it helped stop some of the random bugs that you got in with the first question? And I'm also curious, like, now that you have a complete typescript code base, are there any things that came up with typescript specifically that you maybe didn't think about early on.
I would say the promise of, you know, solving some of the runtime errors that could be caught by compilers has come true. We haven't had a front end code production incident that could have been caught by a compiler that wasn't anymore, so we still have like people still make mistakes. Type script is not a panalcya to solve all bugs and prevent all problems. Doesn't do that, But what it does do is stop you from like accessing
nulls and accessing undefines. So I would say those kinds of like very visible customer problems have not been happening, and it's forced people to think about types a little bit better. So I feel like it helps design a little bit ask for like things we didn't expect to happen. Bill times have gotten longer just because the compiler. We have a lot of Typescript, not a lot of touchcrip code, but we have a sizeable chunk of Typescript codes, so
there is some added compile time. So we've tried to mitigate that by like keeping as current as we can with Typescript so that we always get the fastest compiler. I guess how.
Much longer are we talking? How long does it take the typescript compiler and your year app a couple of minutes? Okay, and that's something you only experience. Like dev time is fine, right because it's like compiling as you go, But just when you build for like a release or whatever, I.
Think there's well, building for releases happens, like you merge to master and then holding stuff happens, and then Docker images have to be built, and like that whole Docker image build process is the is a long part. I would say the CI and local dev is the slower part, where like spinning up webpacks, it has a like an initial lead time of about a minute for it to get started, and then in CI, like the linting and type scripting checking takes a couple of minutes.
Interesting, Okay. I'm playing a lot with es build and SWC lately, which are like Rust and go jsts compilers, and in the right context, they can make a significant difference in those compiled.
Times good time. That's the thing I would like to do. We have a lot of we have a couple of custom webpac module like custom web pack plugins, which makes it hard because we're deeply entwined into Webpack. I've used VTA on our fight on a little side project and it was awesome. The compile times completely go away. But yeah, we were kind of deep in the webpack pool.
Yeah, VAT is amazing. So I've heard a lot of issues around a typescript and just kind of naysayers like I just don't want to do typescript when it comes to more comfortable jobascript. One of another complainert here is that it makes code ugly. So is that something that you had any resistance on folks saying I just don't like the look of it.
Yes, Yes, the CTO was very much like typescript just makes code ugly and hard to read, But we did it. Anyways. I would say that like we also, like Century is a is a mixed shop. So we have something we have a lot of JavaScript, we have Python, and then we also have Rust, and so typescript is not nearly as ugly as rust, so it's quite.
Palatable fighting words right there.
It's funny. It's all in the idea to beholder, because I worked for a company that was a long time dot net shop, and they considered typescript like the height of elegance, right because it's it's made by the same person behind like c Sharp, who's like the dot net guru. So they considered like tight script to be like an enlightened form of JavaScript. And so I think it's it's all relative to what your background is or what your personal preferences are.
Yeah, so like the touch script is ugly. Camp came from like Python, where everything is like very syntactically very like it's low low noise or like low volume, I guess, and touch script has a lot more like punctuation to it, and Rust has more punctuation. I don't think Rust or typescript are ugly, Like they're both very readable. They're just you just have to have a lot more like the dense they're just dense languages.
Oh no, I think we should stick with that because it makes a great subtitle for the podcast. Is you know once it again typescript, It's nowhere near as ugly as rust.
And that's it right there, not as ugly as rust. We should just call it is typescript code ugly. Just I think it's like bait title right there. What you're used to right like, you're not used to list list could be very ugly.
All yeah, I think you can. There can definitely be some readability issues when it comes to generics, and I don't think any language that supports generics has actually solved that challenge. But generics are incredibly important in retaining the type safety of your components or whatever you're you're using. So have you seen folks maybe almost go too far with generics. I mean I've definitely seen that. As another complaint, which is people saying, oh, you know, it gets really complex.
I would say we have we don't have a ton of generics. We have a lot of intersection types, and we've had typescript yell at us that the type is too complicated. This came up when with our like main event payload if you include all of the properties types trips like no, I don't want to really, I've never seen them. Yeah, Or that's another one we had was the top level form like form input, where you can push a type as a string, and then you can get to all of the various input types in that
we have in century. We were just trying to like intersection all of those types of like union, all of those different formats together with a discriminated field and a certain point too is like Noah, I don't want to do this, Like there's too many conflicts. Wow, type it's too big, please stop.
WHOA, I've never seen that.
It was not a good thing to say.
I don't think we have a lot of generics in our cult.
Yeah, we have some, but not as not many, not like there's not a lot of like three tier generics, like the like generic of a generic of a generic, Like we don't try just trying to do that.
One thing I've noticed from doing this podcast is that the people that struggle with typescript the most seem to be people like library authors that have these like general purpose APIs, because those are the ones that are really hard to configure, like if you're the person that's in charge of making the types for like reactor or like some of the libraries you were speaking of that had for support, I imagine part of the reason why they have pre support is that they have to get into
like crazy levels of like generics and intersection types because they're kind of designed for general purpose use. So that's where I think some of the struggles with typescript comes in.
But the thing is like in your average app, even like big apps, like the ones you're working on, like that, those are like fringe situations I feel like, because I mean, most of the time the types you're dealing with while you have objects to raise strings numbers, right, you're you're not doing anything like crazy, And it sounds like that's sort of the case with what you've been working on as well.
Yeah, I would say, like for a lot of like web applications, you're dealing with like API responses and then converting those around like munging that data and then turning it into into use state, right Like, so I would completely agree that you're not dealing with the crazy generics, I would say, yeah, And I think you're respont on with like the library the library author part, Like, especially if the library started off as as a JavaScript library
and then was converted to typescript. I think that's where you really run into it because they've leveraged the dynamic properties of JavaScript and like the ability to be very polymorphic on anything and not kind of bite someone they try and turn into the typeescript. Yeah.
I think it was last week. Week before, we were talking to an author of a form library and they were relaying horror stories of like it sounds like you have a similar experience as well, Like they had form things, but forms can contain all sorts of types, so they got into some insanity in terms of defining that.
Yeah, I could see a form library being really hard.
Yeah.
One of the nice things about that though, is sometimes you can kind of contain that in insanity. If you've got, for example, a set of shared components, like the button that you're using everywhere, right, the type definition of a button might be a little bit complex because you might be bringing in like detailed HTML props, which has a really weird complex signature, but you want to get all of the extra types for a button and you don't
want to define those yourself. So that's actually really nice. But the complexity is sort of contained within that that that library of your your share components, and then as as a user, right, you just pull you just import button and the next thing, you know, you get hinting for on click and everything just works, and so that's kind of nice. And sometimes, you know, you can hide the complexity a little bit of the of the typescript stuff. It's not in your face like all the time. I
feel like you get tuk with like well designed libraries. Yeah, but it is tougher, I guess for older libraries that were written in a style that was less kind of normalized. Maybe you know, you have to start using some of the weirder features of typescript to deal with that, like function overloading, which I don't even think people know exists inside typescript, but actually it does and you can use it.
We had to use it.
Oh there you go, Okay, you know when you need it. It's actually really handy, but it's a it's a weird implementation. It's not like C sharp or C plus plus or Java. It's a sort of it's it's just kind of like multiple signatures for actually what's really just one function.
But to use a lot of type guards to break down our unions too into those. Yeah, those are some of the like the weirder types of stuff we have to use. Was function overloading, a lot of like type guards, custom type guards and big unions and intersections.
Cool nice, So one thing it'd be fun to talk about because I'm I know we have a lot of listeners that are working on similar types of apps, right, large projects that have been around for a while, and that they also have a laundry list of things that they want done, whether you know, they want to be using hooks or they want to be using typescript or
whatever the case may be. So I'm curious, and we did discuss some of this, but I'm curious if you have any other advice for convincing like management that like, hey, like this is a worthwhile effort, because I know that can be a struggle for a lot of people to get time sort of approved to do this, and then also like seeing these projects through, because not every large scale effort like this ends with one hundred percent conversion and success, right, So it's kind of impressive that you
you push this to the finish line. So I'd be curious if you have any other advice in terms of how to make that sort of thing happen and how to see something of this scale through.
So how to convince management to adopt type script. I would say that only the possibility to catch errors on the compiled times.
It's amazing, you know, So this is amazing.
Also we could reduce the need for API documentation because type script it self self explain everything the type and also autocompletion. So I believe this type script the team, it's faster, the product productivity is faster than usual.
Guess on the like how do you get it to finish? We're really fortunate that we have we have like a front end steering community, and the main contributors to the Techica project were also part of that kind of steering committee, and so we just had to kind of stick to our guns, like no new big projects until this one is finished. And towards the end of the project, we were kind of like every week kind of asking people
like how many files are you going to convert? People would volunteer like convert a couple, or I'll convert two or I'll convert three, and then every week check in with those people like did you get your stuff done? What are you going to do next week? And that helps kind of like gamify lightly people's desire to be involved. I would say another thing that helped us finish was that we did it in the long term, and so we weren't rushing to meet a deadline. Instead, we were
just giving updates on like when we would finish. So instead of it being like you must be finished by December of twenty twenty, or your project is out of gas, it was more like we're just going to do this slow. We're going to do it the right way, like the right way for us, which is like not slap any
on everything and do a machine organization. We're going to take our time, going to do it, you know, so that we have something that we're proud of when we're finished, and then just give updates on when we will be done. And then as long as people were meeting their project delivery like deliverables, the front time folks were able to
focus as much as they wanted on tuch script. That was the kind of like their B project was converting to touch script, and all the managers, like all the team managers knew about it, all the engineering managers knew about it, knew who was contributing to it, and so they were kind of like on board, like this is this person's be project.
Yeah, I think all that is great, Like I like Priscilla's points of proving to management. It's like a lot of those points you made were really about proving that this is going to be long term a net positive right, like well, like the fewer bugs and more productivity will make this time like pay off and the long run.
And then I also like the points just in terms of keep seeing this through to the finish, like the accountability bit, like having someone that's in charge of the project that reaches out and forces people to say, I'm going to do this and almost gamifying it a little bit, or at least like holding people accountable so that there's that constant update, like it doesn't get lost because I know what, I've been involved in projects like this before.
Sometimes it's going well, but then some big feature comes down from business or some big bug happens, and then all of a sudden, like this thing that's very low priority gets sidetracked sometimes to never reappear. So I think having like someone on it and someone constantly checking in through all of that can make a big difference.
Yeah, I'd also say another thing that helped us was like, yeah, constantly checking in, constantly double checking, and then also making sure all the new code was written in touch shriped was a big monumental thing to get done, was like convince everyone that touch script is worth learning and then also get them to stop writing JavaScript, because if we never stopped writing.
JavaScript, we would never finish. And so for us to be able to complete, like and to prove that the tuchrip project was going to actually finish both through ourselves and up management, was to get everyone to stop writing cabscript. And we're way past that point now, but that was a that was a key turning point, was getting everyone on board.
Yeah, so that actually leads a question, So would you personally ever want to work on a streat JavaScript application?
Again, Yeah, it would. It's not as good as like typeshrip, Like you get a lot more benefits out of having it in type strip. And if I was to start a new project, I would definitely start it in typescript. Sure how about you, Priscilla?
Yeah, me too, Me too.
Last week we had again heck quick and I work it on two projects and I used typescript. So I started from scratch and I decided to use tapscript because yeah, I really like it.
And I think that's something again with talking to management, right, hiring is always an issue. It's a very hot hiring market right now. People can move between jobs very quickly, and people are evaluating what they're going to be going into. And if you're saying, hey, you know, we're doing React circa twenty fifteen in JavaScript, come on down, we were going to be like, I really enjoy you know, typescript
and hooks. I mean Rizilla's like, yes, hooks, you know, so you want to work in a modern code base. And I think that's the thing, you know, when you talk managements as a selling.
Point, Yeah, for sure, And I think that was something our like our vps knew as well, Like the VP that we were working with then is like very much understanding of that. People want to be on the vanguard and want to be working with new stuff when Century as a company does that a lot as well. So I think that's an important point to make if you're in an organization where that isn't part of the company's culture.
I'd like to addit that we are always trying to introduce new technologies and for example, now we just introduced reactive Testing Library, so we are planning of converting our tests to from ENSIGN to reacted Testing Library, and that's pretty cool.
Yeah, I was just going to say that the it's a really good point that like sometimes like you, you are not in control of your management and your your team or like entire organization. And not to put this to blunt, but I mean, if if your organization is really obstinate, if your managers aren't great, you know, it is a hiring markets. You know, there are other decent
teams out there. So if you really are like super super struggling and working on stuff you're not interested in, maybe you consider other things as well, because they're everybody's got like old code you know, bad code bases and such. But having a culture that encourages that sort of thing and allows you to you know, ramp up over time, I think is a really big deal.
Like century is an old code base, it's coming up on eight nine years. But at the same time, we also like to fix it and see the value in investing it and making it current and like keeping it up to day. Like on the on the not front time, we've just finished like a humongous amount of Python upgrades, like from Python two to Python three, from Jengle one to six, all the way to gay Go two point two. Like that's been eight months of work, and all of that is to get us up to a new version
of Pythons so we can get performance. Actually the main driver of that.
And I have to imagine too, like like pushing those things to production is immensely satisfying as well. Like it's it's like the same sort of things that like when you finish. Like for me, it's like if I'm I like if I mow my lawn, Like there's that moment like when you're done, Like I hate mowing my lawn, But at the same time, when I'm done, like looking out over it, it's like, yeah, I crushed that, Like look how good that grasped.
Yeah, I was gonna say, like that last puzzle piece, you know, when you got a thousand piece puzzle. I can only imagine like that last JSTS file, right, the last commit was like, yes, we did it, you know as a team. You know, if you're in slack, you're like, yeah, that last little.
Bit, Yes, we celebrate it.
I want Yeah, nice, Priscilla, was that your your file? Who was the last person to actually like do the last file?
I think it was vin a right of us. I think it was one of the other one of the other folks.
We let the lashest files, the most complex files.
To the end, and yeah, I can't remember the last to us.
Yeah, there's some like changing of tactics through it. It was like start with the biggest, start with the files that are important the most. Then start with the files that are imported with the least because these most important files are becoming annoying. And then it was like important you do like one whole view tree. There was a bunch of different tactics, but yeah, there was a bunch of big rocks at the end.
Yeah, you did mention that in the article where you mentioned, you know, there's sometimes you work from the core and other times you work from the leaves. And that's actually a very interesting question out there is, hey, we get the typescript is awesome, you know, how do we go and take our twenty thousand and thirty thousand file project and bring that over? Like, what what are some good strategies? And I don't unfortunately I think the answer probably there
is It depends terrible answer. Yes, yes totally.
I would say, like, try a bunch of different approaches and see which ones help you get progress, Like the if your goal is to convert that twenty thousand file project. Over do the things that are going to help you get progress, like if you're going to measure progress on number of files, aim for like choose whatever tactic is going to yield you the most amount of progress at the beginning, so you can get a good foothold so you can get people invested and get people ready to help out.
Yeah, you want to finish up on that. I feel like you left out. Okay, that's cool, all right, awesome, very cool. Well this has been really really fun. I think now is the time to get into this week's picks, So mark one, lead us off on your pick for this week.
Sure, yeah, I would say the new version of them, NEOHIM zero five has native language server support, so you can configure neovim with LUO, which is nice. You don't have to use vimscripts, which is my least favorite programming language, and you can use LUI descripted and then the native LSP look looks really good and works really well. So check out new of them and some of the new native LSP. Very cool about you, Bricella.
Oh I think so?
Yeah?
So that is this library D and D kit. I really like that one. It's They have an amazing documentation. It's very easy to customize and yeah, it's amazing the library. It's very light as well.
What did you do? D and D kit? Yeah, it's not disturbed.
So recently we had to introduce dragon drop in century and we founded this library and it's amazing.
We are really enjoying using it.
Cool.
Yeah, there's so many D and ds. There's dragon draw theres do not disturb Dungeons and Dragons. It's very very popular, you know, three letter combination.
I guess.
Yeah.
And for my pick, I am going to go with a bit more metaphorical. Just the power of saying no. I know that we just we talked a little bit about burnout in the beginning of this episode, and the I find the major key for me to avoid burnout is to just say no, you know, reduce the amount of stuff on your plate. You get less stressed out, and you just feel better about the attraction you make in a day by saying no to a lot of these small projects, even the ones that you want to
do for yourself. So I think that's really important.
I think here, I read a book about it, but I can't remember the title. How to give a sheet. I don't I cannot remember the time, but it was exactly about it the.
Power of no.
Yeah. I know we all want to be nice people, we all want to help out our friends and all that, but you know, you can just get snowed under on all these things, and work is just work alone is very stressful. So you know you don't want to take on too much. You want to live a happy and healthy life and you know, go out and do kayaking or whatever you enjoy. So take that time and be confident and say no, yes, definitely, TJ, you want to take us out.
Yeah. I will not be picking comcasts this week, as I hope this doesn't come through the editing, but my Internet has been catastrophic here lately. But I will pick a window manager for the Mac called Divvy dvv y, one thing that I am shocked the Mac still doesn't have it built in, just a way of snapping a window to a certain part of a screen. It's crazy to me that you have to like look out for
a third party app for that. But Divvy is a pretty decent one if you don't already have one, and I'd recommend it, especially if you have like a widescreen monitor just because being able to dock windows is super nice and super time saving.
Absolutely thanks for that. I'll check that out all right. Well, thank you so much for showing up. That was an awesome episode and we'll see you next week.
See