Adopting TypeScript Across Systems and Teams with Milecia M.

Transcript

[00:00:00] Joe Previte: Hey, Malisha.

[00:00:01] Milecia M: Hey, how's it going?

[00:00:03] Joe Previte: Yeah, thanks for joining me. Do you wanna just give a brief overview of your background and all of that and how you got into coding and wherever you wanna start.

[00:00:12] Milecia M: Yeah, so my name's Maisha McGregor, and I think I finally summed myself up as a super software generalist, , because I've done some work with machine learning, front end engineering, back end data engineering, DevOps, security, pretty much whatever is in tech.

[00:00:33] Milecia M: I have touched it at some. So JavaScript, Python, c plus, C sharp.net, all of the things.

[00:00:45] Joe Previte: Wow. And where do you feel most comfortable Or I guess where, not most comfortable, but I guess, where do you enjoy spending your time the most?

[00:00:55] Milecia M: I would say right now I'm starting to get a little bit [00:01:00] back into the machine learning side of things, but if I can try to use JavaScript for anything, I probably will.

[00:01:10] Milecia M: Okay.

[00:01:11] Joe Previte: So you talked about a few different languages. What is your relationship with TypeScript or experience with TypeScript?

[00:01:19] Milecia M: TypeScript, To me is like the thing that tries to make JavaScript make more sense. Because there have been times where I've been working in just JavaScript files and I'm like, Why is this bullying now a number?

[00:01:37] Milecia M: That doesn't make any sense. And no errors were thrown, of course. So now it's crashing in pro. It, We don't know why, but with type script, it just it adds some kind of, little headaches up front. But when it's time to deploy things, it makes it feel a lot [00:02:00] safer. . .

[00:02:01] Joe Previte: Yeah. Yeah. I totally know that.

[00:02:03] Joe Previte: Of especially, when you're migrating something and you're like, wait this can take in a number or a bullying, it's, And so that can lead to production errors. Exactly. What you pointed out from the, you've worked in a lot of different roles. What, Have you been at a, at an organization or a company where they weren't using type scripts and they decided to adopt it?

[00:02:27] Milecia M: I have, That was like one of one of the earlier jobs that I had where they had this React project and one day they were like, Oh my gosh, we discovered this new thing called type Script. We should probably try to use that because we always have. Weird errors that get to production we never find locally.

[00:02:51] Milecia M: Kind of the approach there was to just slowly update the files. I think [00:03:00] we left that, What is it? I don't remember the exact thing, but it's JS allow or something like that. Oh, yeah. Yeah. So we just turned that flag on and we spent the better part of a year updating all of the JavaScript files to type script.

[00:03:18] Milecia M: We eventually went through and groomed out all of the ins that we had in there just to keep stuff from breaking. But that was my first time doing some kind of migration, the type script.

[00:03:32] Joe Previte: And so at this organization, who was the person that came to the team and said, Hey, we discovered this new thing called Type Script.

[00:03:41] Joe Previte: We should adopt

[00:03:42] Milecia M: it. So that was my boss at the time. And I don't know where he read about it or found out about it, but he was so excited because our backend was built with dot net. , and that already has typing [00:04:00] built into it. And one of his complaints was always, Oh, if only intelligence could tell me.

[00:04:06] Milecia M: What the method or what type or whatever it is I need to use here. It would make development so much easier. And it is true, it does make it easier. So you don't have to remember all of those method names, but different like values you have to work with. Yeah, it just cleans up a lot of mental clutter.

[00:04:30] Joe Previte: Yeah, no, I totally agree. I feel like, cuz you know, the type script brings this documentation, this kind of like meta level of understanding of what the code does and rather than having to juggle that in your head, it's right there. Documented. It's right there next to the code

[00:04:49] Milecia M: for sure.

[00:04:50] Milecia M: And a note that's helped a lot of new devs to projects I've been on, they don't have to. Hunt down somebody to figure out what file they need to [00:05:00] look in to find the methods that they have available. They can just start typing and hit the.in the control space or command space, and it's just there for you.

[00:05:13] Joe Previte: .

[00:05:13] Joe Previte: Yeah. I feel like we've touched on two benefits that, that a lot of people who I talk to, They, they bring it up as a reason that they like type scripts, right? One is avoiding production errors, which, you talked about in the beginning. And then now we're talking about onboarding.

[00:05:29] Joe Previte: Before we go deeper into that, one thing I wanna ask is, so your boss who brought type script into a project, what was their title? Were they an engineering manager or something else?

[00:05:42] Milecia M: I wanna say, That they were a tech lead, but they were the tech lead and the engineering manager. It was a smaller software development group, so I think he did both.

[00:05:58] Joe Previte: Okay. And how big [00:06:00] was that team? There

[00:06:02] Milecia M: were about maybe five of us on that project. .

[00:06:09] Joe Previte: And did anyone have any concerns about adopting

[00:06:13] Milecia M: type scripts? Oh, for sure, because , as much as my boss was just gung-ho, ready to switch everything over the type script and burn the app down , there were some other people that.

[00:06:29] Milecia M: Been doing a little reading, not as in depth as him, but where they stopped is when they noticed that you get all of these type errors as soon as you make that switch. So they were concerned that. If we switch over to type script, we're gonna have to fix all of these errors all at once before we're ever able to deploy Again.

[00:06:54] Milecia M: That means we'll have to keep some separate branch just to update type script, [00:07:00] and then it'll get outta sync with production and blah, blah, blah. So we did have some discussions about that before we came to the decision to just gradually switch the files over instead of make the jump all at once.

[00:07:18] Joe Previte: Yeah, I feel like, depending on the team size or depending on the code base, that gradual adoption allows you to take it piece by piece. That's usually more manageable for teams.

[00:07:29] Milecia M: And this project in particular was. A legacy type project. I think we were working on it around the time react switch from component like class components to functional components and it was just a whole technical debt mess.

[00:07:49] Milecia M: So we were like, Hey, why not throw type script in here? We already have to go through and rewrite everything anyways.

[00:07:57] Joe Previte: Yeah. And rewriting it, you [00:08:00] get that added type safety. Yeah. . Okay, so five team members. The team lead, or I guess, sorry, tech lead engineering manager brought this in.

[00:08:08] Joe Previte: What was the learning curve like? Was that something that people struggled with?

[00:08:14] Milecia M: I think once we got over that initial like hesitation to. Being blocked all and getting things deployed. The learning curve was not that bad. People picked it up pretty easily just because we were thankfully already following some best practices when it comes to working with modules, but.

[00:08:40] Milecia M: There wasn't a whole lot of Oh, what do I do here? We ran into some cases with some generic types that got a little tricky, but generics are always weird. Yeah. So once we did some reading on that, it it just flowed. Okay. It [00:09:00] did take a while to. Make some type definitions for different data, just because we realized we didn't know what we were getting from the back end.

[00:09:10] Milecia M: , but outside of that, it was a pretty smooth process.

[00:09:16] Joe Previte: Do you remember how long it took to migrate? Whew.

[00:09:20] Milecia M: I would say for that app, it probably took a good. Six or seven months just because it wasn't a super high priority to get everything switched over to type script. We had a lot of changes on the back end when it came to data.

[00:09:40] Milecia M: Since we were doing that restructure from class components to functional, there was some other technical debt we needed to pay off, but. It took us about six or seven months to get the app completely converted over, no JavaScript files left.

[00:09:58] Joe Previte: Okay. [00:10:00] And what was the strategy like? Was it, when each person on the team would do like one file a week or like how did you.

[00:10:07] Joe Previte: Spread that out.

[00:10:09] Milecia M: So we baked that into our sprint process. Like we have a, we had a certain number of points for every sprint, and we would just allocate, say, I don't know, 20 points of sprint to type script conversions. And basically people on the team could just go through. If they finished up a task a little early, they would pick a file that they wanted to convert, or if they were already working on some new feature, they would go ahead and make that a type script file.

[00:10:45] Milecia M: Or if they were, I don't know, if they were playing with the new library, they'd make sure we had the types package so we wouldn't get those errors. But for the [00:11:00] most part, yeah, it's just baked into our sprints. If you ran out of work or if you just needed some downtime, you pick a file, you update it to type script.

[00:11:10] Milecia M: If you're making a new file, you just make it a type script when, and that's pretty much how we kept things moving.

[00:11:19] Joe Previte: Yeah, it sounds pretty straightforward, like you weren't trying to do it, you weren't trying to crunch it out in a week or two. But you just you had I guess a, an ongoing backlog.

[00:11:31] Milecia M: Yeah, so we had this system where if you see some type of technical debt, you put a card in for it. So one day during some of our engineering planning, We just took an hour to write up cards for the type script conversions because some files were a little bit trickier than others cuz they had a lot of just stuff that we didn't know where it [00:12:00] was coming from.

[00:12:01] Milecia M: . But as far as the actual code part, it was pretty straightforward.

[00:12:08] Joe Previte: Yeah. That's awesome. And after you finished that, that whole conversion, did you, did the team celebrate or something?

[00:12:18] Milecia M: Definitely. So there were so many underlying bugs that switching over the type script helped us find, like we had always made some kind of modifications on the front end if there were some weird, tight mismatches or we weren't quite sure what the names of.

[00:12:42] Milecia M: Request parameters were, or the responses should be. It was, there was a lot of hacking this to try to make up for not knowing what we were working with. But after we got the types in place and on the React app, [00:13:00] that brought up a lot of inconsistencies with what was happening. In our api . So we were able to not just clean up the front end, but make a pretty specific backlog of technical debt for the back end to clean up.

[00:13:18] Joe Previte: Wow. That's awesome. That's I feel like I've talked to other people about migration. Migrations, and that is one, side effect that I hadn't really considered or hadn't heard before. And how did the, what did the back end team think? Were they happy or

[00:13:34] Milecia M: mad or ? Honestly, they were just surprised because, Okay.

[00:13:40] Milecia M: It was the project was, if I would be blunt about it, it was very quickly and happily put together. So a lot of times when we had bugs that would come up in production, we just had to get a fix out as fast as we could. So the front end deployed faster than [00:14:00] the back end, and we just decided to hack stuff together there.

[00:14:04] Milecia M: But the back end team didn't realize that since they had been. Rushed to get data from different sources mushed together in this middleware thing that they had just been randomly changing names on us and that types were changing from these different data sources because somebody was renaming columns and it just, it pulled out a lot of issues that we didn't know were issues.

[00:14:39] Joe Previte: Okay. Wow, that's, that is such a cool story. And you shipped less bugs to production. You caught a bunch of surprising things, and overall it sounds like it just, It, it forced you to be probably a little bit more consistent and ship a more high quality app for

[00:14:58] Milecia M: sure. It made us [00:15:00] slow down, which was something that project in particular really needed was just some time to breathe and by.

[00:15:10] Milecia M: Converting a few files to type script and then showing the rest of the company, how this impacts development, how it's going to impact future, future releases, and. Patches or bug updates or whatever, once they saw that type script, made our job easier for us. , they were Oh, we still don't know what that is.

[00:15:36] Milecia M: But if it's something that helps us get things out to our users faster, Sure. Take the time. If we need to push back and rethink features. But it's fine type script actually pushed a lot of underlying problems to the surface because even when we got to the back end, we [00:16:00] figured out there were just some, weird design decisions that were made, and it's crazy.

[00:16:07] Milecia M: All of that came from just adding types to the front. Wow.

[00:16:13] Joe Previte: Wow. That's amazing. That's that's probably one of the cooler migration stories that I've heard so far doing these interviews. So it sounds like it was, this, so recapping, right? You've got this tech lead engineering manager who's gung ho oh my gosh, like we gotta use this tool, hot tool, and you adopted, It brought up, fixed a bunch of things. It, like you said, it helped you slow down a little bit and I guess write more high quality code and then. The overall, I guess like larger stakeholders were saw it as the value that it was bringing to the organization.

[00:16:45] Joe Previte: And so then they became, type script fans.

[00:16:49] Milecia M: Yeah, they were it was funny because they were like, How's that type script going? And we're just like, Okay, we understand . [00:17:00] But it was just nice that they actually, Knew what we were doing and why? Because it did delay some features that they were pushing to get out pretty quickly.

[00:17:12] Milecia M: But we were like we can get 'em out, but that's gonna break this. And then we'll end up back in this situation where we have these bugs deployed that we could have caught if we were using types group.

[00:17:24] Joe Previte: Okay. And so I guess from that point on, was type scripts part of the default stack or,

[00:17:31] Milecia M: Yeah, we never really used just playing JS files.

[00:17:37] Milecia M: Again, I think a few times some stuff had to go out, like hot fixes that we just threw up a JS file for really quick. But that always went into our backlog for technical. So that we could come back and actually update it instead of just saying that, Oh, we'll do that later.

[00:17:59] Joe Previte: [00:18:00] Okay. And I guess that's something that we should highlight too, is part of the process that, that your team had, right?

[00:18:05] Joe Previte: Where it was like, Okay. We're gonna do this thing real quick and we're gonna take a shortcut and use js, but someone needs to create a ticket, add it to the backlog so that we can address this technical debt later.

[00:18:19] Milecia M: Yeah, cause. Like most developer teams, we just forget stuff over time. It's Oh yeah, that JavaScript file, we should fix that.

[00:18:30] Milecia M: But I'm working on this other feature, so it's fine. It's been working this whole time. It can sit a little longer. Yeah. But that team in particular, we were really good about just taking notes, even if a car didn't have full details on it, just being like, Update this file to type script. That would be good enough.

[00:18:54] Milecia M: So we'd be like, Oh yeah, that is what we're supposed to do. And then we [00:19:00] could talk through it if there's any shared types between files or something like that. . .

[00:19:07] Joe Previte: Yeah. And. Adding those notes in while they're fresh, you have the context. That's just going to help the next person who picks that up be able to knock it out faster.

[00:19:18] Joe Previte: . So I guess, okay, so that was at, let's say one company in your career, are there other companies where you've used types groups?

[00:19:27] Milecia M: Yeah, that was another company that I worked with and. They just went for it. There was no gradual update. They were like, We're using type script today and. We pretty much just stopped all new feature development.

[00:19:47] Milecia M: We, if there were any bugs that came in from support, we would handle those, but we had a separate branch that we were working on, all of these type script [00:20:00] updates. And honestly, that process was way. Way more painful than the gradual update because when you're looking at an entire code base, which you know has maybe hundreds of files in it, and you're like, Oh, I need to update all of these, it's a little overwhelming because you have to decide.

[00:20:25] Milecia M: What level do you wanna start at? Do we wanna start at the component level where we are pulling in the smallest amount of data and defined types there? Or do we wanna start at the page level or view level where we get. The overall type for what is being rendered and then break it down from there. And we just had a lot of discussions about which approach we wanted to do, and I think we ended up deciding to [00:21:00] actually start at the view level.

[00:21:03] Milecia M: So we would get. Like larger types. And that worked is our list to build the smaller types off of because it just was more in line with, design decisions and how we were currently working with the application.

[00:21:27] Joe Previte: . Yeah. That That's an interesting approach. So that would you say that was less planned and more use your best judgment?

[00:21:32] Joe Previte: Or like how did you how did you know if everything was done or like how were you tracking all of that?

[00:21:40] Milecia M: So the way that we kept track of everything was with the tiniest pool request we could come up with. Okay. So at the beginning of a week or sprint, we would go through the code base and decide, Okay, we're gonna update this.

[00:21:58] Milecia M: Particular page and [00:22:00] all the associated components with it this week. So we would divvy those files up. We'd be on constant calls just trying to make sure everybody's staying consistent with the typings that we were coming up with, naming conventions, the actual. Like data type we were expecting for variables.

[00:22:25] Milecia M: It just turned into more of there was probably more collaboration this way than there was with the gradual update. ,

[00:22:35] Joe Previte: was that beneficial?

[00:22:38] Milecia M: I'm not sure if I'd say it was like more beneficial. Then with the gradual update, it was more like we just had to do it that way because we were doing all of the type conversions at the same time.

[00:22:54] .

[00:22:54] Joe Previte: How do you, I, that's one thing that I've heard come up from some other teams is like, [00:23:00] how do you enforce those conventions about like similar naming patterns and like data structures and things like that for types.

[00:23:10] Milecia M: So we actually just. Would have meetings and write up, No, not notion.

[00:23:15] Milecia M: Whatever it was we were using before it was probably a Google Doc, but we would just meet and write up a Google Doc on, how to define types or how we are going to define a specific type for a component. And we would flush it out that way. So if any questions came up about why did we do it this way?

[00:23:39] Milecia M: We could just refer back to that doc.

[00:23:43] Joe Previte: Okay. And where did that. Doc Live, was that within the code base Or was it like within Google Docs, like you said?

[00:23:51] Milecia M: It was just within Google Docs. Okay. Like everybody on the team involved with that migration. We just had it [00:24:00] bookmarked.

[00:24:01] Joe Previte: And so for that migration, stepping back a little bit, who, who like voiced that or like who, who

[00:24:09] Milecia M: said you should do that?

[00:24:10] Milecia M: I wanna say that came from like the cto. It was a startup that I was working with and they were like we have a good chunk of functionality already built out, but it was just, At a stage that was a little bit more polished than the mvp, and they figured this was the perfect time to go ahead and switch over to type script because we didn't have as many files to convert.

[00:24:41] Joe Previte: Okay, that makes sense. So I guess it's a, rather than a large legacy code base, it's, mvp, kind of greenfield, and it's okay, we're at a good point where there's not too many files. Let's adopt this new technology. . Okay. Interesting. So you've had both experiences.

[00:24:56] Joe Previte: You've had the. Legacy code base, let's [00:25:00] migrate and take a gradual approach. And then you've had the, we have some, we have a little bit of code, but let's stop, drop everything. And a hundred percent of our focus is on the migration. I guess what advice do you have for somebody who is considering one of these two approaches?

[00:25:18] Milecia M: I would say the first thing to look at is just how much technical debt do you have? Because if you have a lot of outstanding technical debt, it does make the conversion process a little bit trickier. So I would start with just some research there and maybe getting the app to a point where it's a little bit more cleaned up code-wise.

[00:25:47] Milecia M: And then if you do have a, Actually I just kinda like the gradual approach more than the all in approach because it takes some of the stress off, off. [00:26:00] You can convert one file a sprint, and still eventually get the whole project converted all through. That might be slower, and of course you can do more than that, but.

[00:26:12] Milecia M: I think that's a good approach. That way you aren't blocking any of your deploys. You can still release features and fix plugs and things like that,

[00:26:24] Joe Previte: so you can do, your quote unquote normal dev work or engineering work. And this migration in, almost in parallel,

[00:26:32] Milecia M: yeah, it just.

[00:26:35] Milecia M: It breaks up the monotony and, getting features out, cleaning up technical debt, you get to do a little bit of everything at once.

[00:26:44] Joe Previte: . Okay. Yeah. No, that makes sense. That's helpful. So switching gears a little bit. One of the, one of the things when I was doing some research for, to prep for this is I read that you are writing a book for O'Reilly to help [00:27:00] mid-level JavaScript devs make the jump to Singer.

[00:27:03] Joe Previte: Is that right?

[00:27:04] Milecia M: Yeah, that is right. I think it actually just went out for early release yesterday or

[00:27:10] Joe Previte: today. Oh my gosh. Congrats. That's amazing.

[00:27:14] Milecia M: Yeah, pretty excited about it.

[00:27:17] Joe Previte: Yeah, so I guess I would love to hear your thoughts on is like how do you see type script in, we'll say the JavaScript industry.

[00:27:27] Joe Previte: Is it something that you need to make that jump to senior or are we not there yet? What do you think about

[00:27:33] Milecia M: that? I do think it's something that is good to have in the toolbox when you're making that jump to senior, because I've still worked on some projects that are completely in JavaScript, so you don't have to worry about typing.

[00:27:51] Milecia M: But I have noticed more of a trend towards type script. So it seems a lot of startups for sure are [00:28:00] leaning heavily on type script, but also some of the bigger companies are starting to see the benefit in type script. Like for example, when they are thinking about rolling out new features.

[00:28:13] Milecia M: If you have millions of users, you wanna make sure that feature is rolled out correctly and bigger companies are starting to invest in the. To convert, to type script to help with that problem. So if there's a mid-level developer or even a junior that's just looking to skip straight to senior, knowing some type script is definitely gonna be a huge benefit.

[00:28:42] Joe Previte: Okay. Yeah. And then going, I guess down the experience chain a little bit, if someone is newer to the industry like entry level junior, and they're looking to get their first role, is it worth them learning types group? Do you do you think they need it? What do you think about that? [00:29:00]

[00:29:01] Milecia M: I think as long as they have a good understanding of JavaScript and the basics there, adding type script on would definitely help them get that first role just because a lot of companies.

[00:29:15] Milecia M: Use type script. A lot of 'em are maybe even researching how to add typing, or even if they do something in the open source world, those packages need to be type script compatible. So knowing how type script works, understanding a little bit about those, what is it? The declaration files, whatever that dot d ts file is

[00:29:45] Milecia M: Yeah, that's definitely something juniors should spend some time learning about.

[00:29:51] Joe Previte: Awesome. Cool. I'm trying to think is there anything else that you think teams should consider [00:30:00] when they're thinking about adopting type. I think

[00:30:03] Milecia M: the number one thing I would push is just early documentation. A lot of times we make these decisions around, Oh, we're gonna migrate to type script.

[00:30:14] Milecia M: Okay, everybody go do that. And then all these questions come up with, again, like what is our strategy? What's the naming convention? What happens when we find tight mismatches? What happens? When there's certain methods we need that aren't defined the way we expect them to be, but sitting down as a team and having some discussions about it before you jump into the code changes that will make the process go a lot smoother.

[00:30:46] Joe Previte: So it's what would you call that? Is it like an adoption plan strategy?

[00:30:51] Milecia M: Yeah, I guess we could call it that, like an adoption strategy or a migration plan, something like [00:31:00] that, that just very clearly outlines why we're making this change, how it's gonna help us go forward. And the actual steps that we're gonna take.

[00:31:13] Milecia M: So are we gonna have a separate feature branch to merge all of these prs to so we can do whatever kind of testing? Do we need to update the test so that they take advantage of these type script types? Do we need to. Coordinate with the data team to see what the names and types of things are in the database is just making everything as clear as possible so when questions come up, we aren't remaking the same decision over and over again.

[00:31:50] Joe Previte: So it's it's like this prep work to make sure that you have the information so that you can do the migration quickly without I guess having to jump on a bunch of [00:32:00] different calls.

[00:32:01] Milecia M: So my background before software was in mechanical and aerospace engineering. And we live by measure.

[00:32:09] Milecia M: Twice cut once . And that's basically what we're trying to do when it comes to type script. We wanna make sure we've discussed everything, we've answered the questions, and now here's this document so that we don't have to keep talking about this. Over and over again.

[00:32:28] Joe Previte: Okay. That makes sense. Yeah I've heard that that saying so many times and I feel like, yeah, I feel like type script kind of embodies that, what you were saying.

[00:32:38] Joe Previte: Because. One might be like, if the front end team is working with the backend team, right? You're defining the contract of what the API response is gonna look like, the requests and that data structure, like we can represent it with a type or an interface or a in type script.

[00:32:54] Joe Previte: So Yeah. That totally makes sense. Is there [00:33:00] anything else that you think that we should cover or that you think would be helpful for teams or. Anyone in a position of leadership who wants to adopt type script at their organization.

[00:33:11] Milecia M: I think the main thing is that no matter what level you are, if you see that there are a lot of just bugs that consistently get out to production or even make it to the QA stage just because there's some weird type things going on or there's some bad error handling.

[00:33:35] Milecia M: It's okay to advocate for this kind of migration. Like one of the teams that I work with now, somebody was just pushing for us to do. Basically an overhaul of all of our packages so that we are up to date. And I think that they're a junior developer, but their [00:34:00] idea makes perfect sense. So if there's anything that you think Type script could help with or maybe it could fix, go ahead and speak up and just let that be known.

[00:34:12] Joe Previte: Yeah, I think that's great. A advice, Because it's like you, we talked about like you recommended before, right? Whether you're a junior or entry level developer, or mid or senior, if you have type scripts in your toolbox and you know what problems it solves, right? Like we talked about onboarding quickly, we talked about shipping less bugs to production.

[00:34:33] Joe Previte: We talked about helping with documentation. When you have that understanding and you see a problem at your organization, Like you said, you can speak up and say, Hey, I have experience with type script, or I know type script can help prevent these problems. And yeah, like you said, speaking

[00:34:50] Milecia M: up.

[00:34:53] Milecia M: Yeah, cuz that's one thing that I'll run into on almost every team is just that sometimes [00:35:00] developers don't speak up even when they see there's something that could be done easier or something that could be cleaned up. They just silently. Let it go. But typically if you speak up about something technical, debt related and you have a good case for how this is slowing down feature development or how every time you open a specific file, it makes your stomach drop a little bit cuz you're scared of the changes you're about to make.

[00:35:35] Milecia M: Just let that be known to the team so that this can be a thing that gets accounted for.

[00:35:43] Joe Previte: . Yeah. Cause if you notice it and nobody else does and you don't speak up, then it'll just continue to be a problem. Exactly.

[00:35:52] Milecia M: And then the problem always snowballs. Like once you understand how to work around it, then [00:36:00] somebody new starts and you forget that you've been doing a work around for the past year and a half, and then they're confused and you're trying to explain stuff, but it doesn't actually make sense because nobody's local environment should be like that.

[00:36:17] Milecia M: And yeah, just letting it be known that there's a problem somewhere. , as soon as you see it, it just helps with long term maintenance.

[00:36:29] Joe Previte: Yeah. Yeah. So I guess, the big takeaway there is, you see a problem yet if you don't know exactly how to solve it, one of the great things you can do is speak up.

[00:36:38] Joe Previte: . Alicia, thank you so much for joining us today. Where can people go to find you and read more about your.

[00:36:46] Milecia M: Probably the best place to find me would be on Twitter at flipped coding.

[00:36:52] Joe Previte: Cool. Thank you