Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Quitting CoffeeScript? First Teach Everybody Typescript | Ep. 02
10 Plays25 days ago
Hal Anil, Staff Engineer at Braze, joined just as the company hit a turning point: KnockOutJS and CoffeeScript were no longer cutting it. In this episode of Tern Stories, Hal walks through how they migrated to React and TypeScript—without pausing product work or losing developer trust.
We talk about:
• Why they started with workshops, not code
• How a single collapsible UI unlocked momentum
• The real value of tooling (hint: it’s not automation)
• Making migrations feel safe, even exciting
Recommended
Transcript
Introduction and Early Tech Landscape
00:00:00
Speaker
This is Turn Stories, and I'm your host, TR Jordan. If you were writing Frontend in 2013, you probably remember how great CoffeeScript and Knockout.js were. They're just light years ahead of early Angular or jQuery or anything else, but they didn't win.
Migration Journey to Modern Tech Stack
00:00:14
Speaker
So today, i got to talk to Hal and Neil. a staff engineer at Braze about their years-long journey migrating from Knockout and CoffeeScript to React and TypeScript. There's some amazing lessons in here.
00:00:25
Speaker
How to get started, what components get people to actually move to the new tech stack quickly, and even how to make adding types to JavaScript feel kind of fun. I think you're going to love it.
Braze's Growth and Migration Strategy
00:00:35
Speaker
Welcome, Hal. Glad to have you here.
00:00:36
Speaker
Hi, glad to be here. Excited to talk. Right on. So um i am I am excited to hear the the pain of ah and the glory of doing this migration. But before we get into it, tell me a little bit about what where Braze was when you joined. How big was the company?
00:00:56
Speaker
what it What did they do? What were they were the things that landed you there? Yeah. um So i guess just, you know, rewinding you slightly even further back, I actually have, um like, knew a bunch of people. I knew a bunch of people um from from college who work at Braze. And they were talking about, like, wanting to go into this migration. They kind of didn't really necessarily have a specific plan of how to tackle it in mind other than, you know, we need to move away from our existing tech stack, which at the time was
00:01:30
Speaker
Knockout, JS, and CoffeeScript to the new one, which was React and TypeScript. And it was mostly agreed upon that, you know, this was the direction that they were going to head down.
00:01:41
Speaker
And they were looking for someone to sort of especially help out in the beginning parts, which they saw as starting with like a shared design library that ah would be used throughout the application so that we can start standardizing what the UI looked like.
00:01:59
Speaker
And I had experience doing that at NASDAQ for the past two years or so. um And what ended up happening was like, I was kind of looking for so for a change, looking for something more interesting, more exciting.
00:02:13
Speaker
um And they were like, we need somebody who has a little bit of experience at least doing this so that we can just hit the ground running and build this design library. And that will enable and sort of supercharge hopefully our transition, our migration into React and TypeScript. So that was kind of the original cell, if you will.
00:02:31
Speaker
ah And then where was
Challenges and Reasons for Migration
00:02:34
Speaker
Braze at that time? So this is like like we just said, this is five years ago. So Braze was about half the size it was at this point. I think it was like just ah under...
00:02:47
Speaker
a thousand people globally. I remember, I think if if you look on Workday, my employee number is like 700 something. And right now we're in the high 1000s, like 16, 1700, I think is the latest number. I'm not exactly sure.
00:03:00
Speaker
ah So, you know, we've pretty much doubled during the time that I've been here and opened a lot of new offices that didn't exist when I joined. And Yeah, the migration has taken many forms, obviously. Like I said, it started with the design system and the design library, but it took it went down many different paths in many different directions. So yes, while we tend to use migration in a sort of singular, like a this is a one thing that we're doing, it actually also could be thought of as like a bunch of related migrations that all kind of come together to move us from a to b And that's kind of been my experience so far.
00:03:40
Speaker
that That totally makes sense. um What was from as you were as you were thinking about joining Braze and so learning about, like well, they wanted to do this change.
00:03:51
Speaker
um Makes sense to bring in someone with like outside expertise. What was the straw that broke the camel's back? Because it's not a it's not a small decision and to rewrite your front end.
00:04:05
Speaker
um Was there a single straw that was like, well, all right, that's what we need. Now we're gonna going to do the rewrite? Or was it more a i pile of reasons?
00:04:16
Speaker
I don't think it was necessarily a silly as straw that broke the camel's back. I think there were a bunch of things that kind of coalesced together. There was a technical piece of it, which was that both of the technologies we were using, Knockout.js and CoffeeScript, were dead and abandoned.
00:04:32
Speaker
there was a sort of recruiting aspect to it, which is that like when you're using dead and abandoned technologies, it's hard to find people that know how to use them. And even if people don't know how to use them, they don't necessarily want to learn how to use them. Like who wants to learn ah you know ah language or a library that is not really helping you sort of invest in your career growth when no one else is likely to use it in the future, or at least a diminishing number of people are likely to use it in the future.
00:04:58
Speaker
um So there was that piece. Another piece was developer velocity. It's simply harder to write things in a safe way in CoffeeScript and Knockout JS compared to React and TypeScript.
00:05:12
Speaker
And they definitely were looking to sort of build a lot more features with a lot more ah speed. So that that's definitely one piece the sort of technical side of it.
00:05:22
Speaker
There's also the design side of it, which is that our design folks were looking to sort of standardize the way our UIs looked and felt across the application. when there's so many different teams working simultaneously on so many different parts and so many different features of a platform that provides things like being able to send emails, being able to send push notifications, being able to create custom audiences and all these things,
00:05:49
Speaker
You don't want it to necessarily look like a patchwork of different applications that were all stitched together. And an easy way to accomplish that is through a design system, which was kind of the first thing that we embarked on when we decided to actually start the migration.
00:06:03
Speaker
And ah big proponent of that was our design team saying, hey, if we standardize things like buttons, things like form elements, things like you know, what have you, then not only will it make it easier and quicker for engineers to build um new features just because they'll just be able to, you know, pick Lego pieces essentially and put them on top of each other, but also the collective out what of what everybody's creating will be a consistent and unified experience that looks like a single well thought through application UI.
00:06:37
Speaker
So those were kind of, I think, the big um sort of technical as well as design specific reasons. There are also business reasons, which I guess kind of goes back to those technical and
Consensus and Initial Reactions
00:06:50
Speaker
design reasons. Ultimately, it's a good thing for your product to appear polished and for you to be able to launch features quickly without bugs and without getting constantly bogged down by, oh how do we do this? And it's very complicated and challenging and nobody really understands how we do this.
00:07:08
Speaker
So that also helped the business to invest in our ability to execute on our long-term vision and our objectives and things like that. So that's kind of the the coalescing of all of the different factors that led to this moment that moment um of the migration beginning.
00:07:25
Speaker
That makes sense. So you had you had engineers who were feeling less and less productive working in CoffeeScript and Knockout. You had a design team who was worried about the app looking like a ransom note because of file consistency. You had ah managers who couldn't hire because they were pitching outdated technologies to and engineers. and that all rolled up into the business's inability to ship as fast as they needed to.
00:07:50
Speaker
Yep. ah Very good. Total sense. So this might sound like a weird question, but when you arrived and started working on this, did you find that there was broad consensus about the need to do this migration right now?
00:08:04
Speaker
um
00:08:08
Speaker
That's a really good question. I would say immediately right off the bat...
00:08:14
Speaker
Yes and no. I would say compared to, for example, my experience at NASDAQ, there was definitely much more consensus. I would say NASDAQ, where we were building a design system and we're trying to get other folks to use it, there was a lot of resistance because a lot of these different teams didn't weren't used to collaborating with one another.
00:08:35
Speaker
And so they felt like coming to them and being like, here's a design system, please use it. was encroaching on their territory as opposed to being helpful. ah My experience at Braze was not like that. People were generally pretty open to using it. And if anything, they were like, hey, you know what, if this, especially from an engineering standpoint, if this makes my life easier on a daily basis, this sounds perfect, of course I will use it.
00:08:58
Speaker
At the very beginning, before we proved out that we could in fact help them, I think there was a bit of a sort of dissonance between people sort of Agreeing on principle that, yeah, of course, we want things to be easier, but then being skeptical that it will, in fact, make their lives easier.
00:09:19
Speaker
So... Perhaps in the beginning, there could have been a mismatch of like people saying that they would do it, but then not actually taking action immediately. Them being like, well, this is new, this is foreign.
00:09:32
Speaker
A lot of people at the time who worked in our engineering organization weren't familiar with React, TypeScript, or anything. So there's this natural sort of aversion to like wholesale, throwing out the things you know,
00:09:44
Speaker
even if they're not the best way to do things, just because you're sort of, it's your comfort zone, right? You're entrenched in what you know how to do. and And you're generally incentivized to be able to deliver on the these features that you need to move the business forward.
Education and Collaboration
00:09:59
Speaker
It's kind of scary to think, oh, the things that I had been doing all this time suddenly aren't necessarily going to be able to apply. I have to learn all these things while still being, um, um expected to deliver on these features for the business.
00:10:14
Speaker
So I think at the very beginning, there was a little bit a little bit of fear around that. Maybe not voiced like, you know, I don't think anybody was running around being like, oh my God, I'm terrified. But like, I think you can kind of see it in adoption or lack thereof when you build features You build like different pieces of the design system, and you see that like maybe it's not getting used as much as you expected it to.
00:10:40
Speaker
um And I don't think it came from a place of, I don't like this, I don't want to do this. I think it came from a place of, I'm not familiar with this, I don't even know where to start, and don't even know if it's going to be sufficiently...
00:10:53
Speaker
the helpful for me to be able to do the things that I need to do. um I think that was the beginning. and And one of the most important things I would say my team did at the time to sort of get over that hump wasn't just to be like, here's a design system.
00:11:11
Speaker
Enjoy. Goodbye. We'll see you the next time we have a release. It was more, okay, let's actually sit down and talk about React. How does this work? Let's do a little React training. Let's do TypeScript training.
00:11:22
Speaker
Like really going to the, starting with the basics because that's where everybody was. And we did, you know, um we did sort of ah workshops with individual teams. Like we would basically put all the team members. So this is also COVID. So not in a room, literally, but like, you know, ah in a Zoom together or a Google Meet together and kind of walk them through almost like a slideshow of like, this is really like literally starting from the basics of like, this is React. This is TypeScript. Here's how it all comes together.
00:11:50
Speaker
Here's how you do something that you would have done in Knockout. in React. So those are kind of the early steps in getting that buy-in.
00:12:01
Speaker
um I think an interesting thing that happens in those times, is especially early on when you just want people to use something that you're building, but they're maybe...
00:12:15
Speaker
not picking up as quickly as you would want them to is sometimes to feel like, okay, maybe I should just force them to use this. Maybe I should require them. um Maybe I should like, you know, go above their heads, talk to their managers and make them do this. But there's, that is absolutely the, so it might work in the short term, but that is not way a way to get people to A, like you or to, you know, invest in the longevity of whatever it is you're building.
00:12:40
Speaker
So really building a lot of goodwill, establishing competence and showing people that like, hey, we're trying to help you be better at your job um and not sort of abandoning them to their fate is is, I would say, the way to go, especially when the transition is ah is is a large migration such as this one. Smaller migrations, maybe you don't need that, like if it's a small library or whatever.
00:13:05
Speaker
But when it feels like you're changing the entire way you do things, um acting as a collaborator and helping people and making it clear that you want to help them succeed is is a really big part of the battle, I would say.
00:13:22
Speaker
That's awesome. So your first step wasn't even writing writing code or or design docs. You'd pick the technology, but the first like tangible step here really was, let's go pick what are the let's go find the teams that are going to use this and let's teach them what it's going to be like to live in the the new world.
00:13:40
Speaker
Which makes a ton of sense, honestly, that it's a big assumption that... Anybody who doesn't use React every day already knows how to use React. Yeah, of course. Yeah. And I would say, you know, some teams are je like, the nice thing is that not everybody has the same level of resistance to everything. some Some teams inherently, because of the people that are in them, because of the culture of the team itself, are more open to these sorts of things. They're more and open to like trying out new things, even if they're not sure that they're going to succeed ultimately.
00:14:09
Speaker
um All of that is fine. It's... it's you have to find the right person and the right team that is, you you know, like much like how you go out there and find design partners. You kind of have to find the right folks that will help you at the beginning stages who are more likely to go want to go out of their way to do try something new than maybe a team that's like, you know what we don't want this.
00:14:35
Speaker
Ultimately, they're going to get there too, but you're just going to make your life and their life miserable by attempting to go for the hardest thing first, you know?
Building Momentum Through Success Stories
00:14:46
Speaker
Absolutely. So as you were talking to people, you I really like this framing of people who are sort of more had more affinity to doing the project or were more resistant.
00:14:57
Speaker
or Where did you focus your energy? Did you did you double down on the people who were already excited? Did you try and convince the laggards? Did you do some mix? I would say we we doubled down on the people who were already excited, um especially in the beginning, because...
00:15:14
Speaker
our thinking was, hey, you know we have some folks in some of the teams that are really excited about this, that they themselves have been contributing to this effort. um you know Prior to the creation of what initially was called the dashboard infrastructure team, now it's called the front end infrastructure and experience team.
00:15:33
Speaker
um Prior to the creation of that team, there was like a ragtag group of engineers that had a vision. And this is even prior to me joining that, like set up the groundwork and those folks were interested in pushing this forward.
00:15:50
Speaker
So we already had some ah folks that weren't in the team directly, but who were kind of cheerleaders for the effort that were willing to sort of, be advocates for us within their own teams, which is very, very helpful.
00:16:02
Speaker
um in In that instance, we kind of started out by being in constant communication with them, talking with them about what it is they needed. um One of the big things that we did was, you know, kind of prioritizing which pieces of the design system to build based on the needs at that particular point in time of the potential customers, and that in this case, sort of those teams that are more likely to adopt.
00:16:28
Speaker
Obviously, certain things when you're building a design system from scratch are pretty obvious and pretty basic. You know you need buttons, you need text, you need you know these very basic things that you kind of you don't need to talk to anybody to build.
00:16:40
Speaker
But then there are other things that you start to get into where, hey, you know, we're kind of they the the other team kind of tells you we're stuck on this particular feature. We're trying to build this, but we don't have that.
00:16:51
Speaker
So then, you know, their design team and our design team would work ah to understand, like, what exactly it is that they need and how in what timeline they're How can we build and deliver features that can really help them?
00:17:07
Speaker
And as sort of we started to give them the functionality that they needed and they adopted it, two things happened. One, they themselves saw, hey, this is actually helping. You know, I'm i'm building things more easily ah with more velocity.
00:17:22
Speaker
And then other teams also saw them because people talk among themselves. And so ah it's it's kind of like free advertising in a way for that you're starting to get when you know, ah team A builds this feature.
00:17:36
Speaker
They hopefully have a good experience building the feature with the tools that you provided them. They talk to this other team who who says, oh, that that looks cool. Was that really hard to do? And they're like, no, it actually was easier.
00:17:49
Speaker
And that's kind of how it starts to snowball. um You know, you kind of have your one example. Other people see it. They're like, I want to try this out. And then that happens again and again and again. And eventually I feel like you reach sort of a ah what's the term I'm looking for? Like go over the hump activation energy, I suppose, ah where like, or critical mass, that's the word I was looking for, or term I was looking for. ah You reach your critical mass and suddenly you don't have to go out and try to convince people to use things anymore. They actually start
00:18:23
Speaker
coming to you and are like, hey, we need this from you. We need this other thing. We really want to do you know, this feature, but, um you know, for example, you don't currently provide XYZ.
00:18:34
Speaker
When can you provide that? um And then that's, it kind of goes from there. thats i I love that that way of thinking, that way of doing it. It's it's this like classic struggle of platform teams where you want to build something. and it has to be coherent and good, but at the same time, ah you work a company.
00:18:52
Speaker
This is the product. You are not selling it. you can You can't you know be visionary about it because there's only ever 10, 12, 20 teams who are going to use it. and You need to actually so serve their needs in the short term.
00:19:06
Speaker
yeah um How did... Let's get into the the details of some of the stuff you built. What was the first thing that you built into the design system where a team pulled you into building and you're like, wow, I didn't think we were going to need that?
00:19:28
Speaker
Sorry, to clarify, like pulled us in in terms of like... ah become part of their ah process of building it out? or um You knew you had to build text, you knew you had to build buttons, but you mentioned that there were there were some weirder things that you had to build and you would prioritize them yes as part of in the system. but was i'd I'd love an example of... ah Yeah, i mean I guess one thing that comes to mind, this isn't like a particularly like weird or esoteric ah component or anything like that, but
00:20:01
Speaker
um One that comes to mind is collapsibles. um So basically, like a little you have a little box, and then it has potential extra information that you can click to expand or collapse to as the as a user to see that.
00:20:15
Speaker
um I think one of the teams that needed it needed to see this collapsible in order to be able to like provide sort of real-time information about... whether the campaign, the marketing campaign that they were creating was, ah it had any errors or it had things that needed fixing and things like that.
00:20:33
Speaker
And we hadn't yet built it. And so that was one of the first things that we built um for them. That wasn't kind of in the obvious set of like buttons and text and stuff like that. Got it. not Not the most exciting component, admittedly. But again, this is like, you know, but when you say first, I feel like,
00:20:52
Speaker
Oftentimes, first really ends up being some of the most basic things. um And it it starts to build from there, essentially.
00:21:03
Speaker
How, if you you sort of zoom forward, what were some of the more more complex things that you ended up
Component Development and Migration Simplification
00:21:10
Speaker
building? And how did you navigate that line of where you needed to be part of the design? Something that should have been part of the design system versus something which is just like, look, that's just code. You should go write it yeah with the team that owns it.
00:21:22
Speaker
Yeah, yeah, for sure. um The one i always think about is is our data table component. ah So it's it spans all of the things you just said. So there's, I like to think there's kind of three pieces to it. And all these three pieces live in different places. So The first piece is the pure UI.
00:21:40
Speaker
You need tables, HTML tables. and need them In this case, they don't really do much other than look the way they should, so they're just mostly styled ah components that have a particular appearance, and then when you assemble them, they make a table.
00:21:53
Speaker
That was in our actual beacon design system and remains in our beacon design system repository that is distinct from our platform repository. Then the next step was, and the impetus for this was, okay, we need to continue rolling forward with the migration, but a big thing that's preventing us from continuing is SlickGrid. We're using SlickGrid for all of our tables in our platform dashboard, and there's many pages that where that's basically the main or essentially the only thing on that page.
00:22:23
Speaker
And until we have some sort of a legitimate replacement, ah we can't continue along and finish up this migration. And we definitely knew we didn't want to necessarily know continue to use SlickGrid for a bunch of reasons, um including technical and design and UI, UX, all that stuff.
00:22:42
Speaker
And so the next step then became, okay, how do we create a, we call them data tables, a data table that
00:22:52
Speaker
essentially feature teams can use to build custom tables that are specific for their use cases, but also one that uses the UI, create, generates the UI for you, for the most part, so you don't have to repeat the same things like putting in the body and the header and the cells and whatever ah every time.
00:23:14
Speaker
And also... give it enough flexibility such that you know wildly different instances of these tables can be implemented, yet at the same time not giving so much flexibility that, again, you end up in this place of you're basically just manually putting putting everything together anyway.
00:23:32
Speaker
So finding that balance is somewhat tricky. And that that actually, the data table component, was essentially a marriage of the UI elements that we had built in our design system and the React table now, I think it's called 10 stack React table library that stitched the two of them together and provided a relatively simplified interface, not altogether different from what there used to be the make it super easy for teams to be able to not only migrate their existing slick grids into this table, but also just create new ones and the into the future.
00:24:10
Speaker
One of the things that we did was, and this was kind of a point where like the front end kind of started to meet the backend um on our team was looking at how do we minimize the level of effort it will take to transition away.
00:24:25
Speaker
ah Jesus. um Sorry, I'll say that again. One of the challenges was how do we make it easier for people to transition away from Slickr to the data tables?
00:24:39
Speaker
And for that one, for example, we basically said, hey, you know, let's create some hooks and enforce a contract between the APIs of the backend for tables specifically.
00:24:51
Speaker
and the UI of the front end so that you can essentially take this new UI, but you can plug existing API endpoints to it so that you don't have to even worry about anything happening in the backend. And it's solely a front end project now.
00:25:06
Speaker
um And when you say those types of things, engineers tend to get pretty happy and excited because it's like, oh my God, yes, there's less work I have to do too to do this migration.
00:25:17
Speaker
um So that was... find is striking that right balance of like flexibility and interoperability um to create an experience for the developers that gives them the velocity and makes them want to actually adopt this, as opposed to feeling like it's going to be a slog.
00:25:37
Speaker
I think that that is the death knell of any migration effort is that if it feels like your life it's just going to make your life harder, especially long term, then people tend to be more resistant to them.
00:25:50
Speaker
But if you're like, hey, but you know even the process the process of doing this isn't going to be complicated. And when you're done, maintaining it is going to be super easy. People get pretty excited about that that sort of thing. And then I guess the third piece of that is actually the end engineers using this sort of middle layer of the data table to create their own specific instances of its usage, whether it's you know displaying and being able to navigate to all the various campaigns or you know seeing a bunch of reporting about ah how your campaigns have performed the past or creating new audiences and being able to select them and see them all in one place. so
00:26:26
Speaker
ah you know The possibilities are endless. i I love that insight about finding kind of the right the right like developer experience ah cut point of saying, like hey, if this becomes a front-end plus back-end project, all of a sudden, wo that's going to be a lot. Do you know like let's yeah you have to have two weeks, two quarters out to really do this?
00:26:51
Speaker
And all of a sudden, like your PM is involved and leadership is asking questions, but saying, like no, it's just a front-end project. We're just going to swap this, and it's going to work the same, and we're not going to have to change it. Does it feel like it'll just take...
00:27:02
Speaker
It sounded like it takes the temperature down. It 100% takes the temperature down. Yeah. I think it's like people like anytime you say the word migration, I think nowadays you get a sort of ah like a trigger response, like people like the heart rates start going up. I think it just freaks people out.
00:27:19
Speaker
At this point, I've resolved to not call something a migration until unless it's like huge and massive and multi-year. I'm like a refactor just just you know, keep the heart rates from raising rising too much.
00:27:31
Speaker
um But yeah, I think that is a big piece of like saying you should do this and it's not going to be that bad for you. ah like they need You need to fast follow with that. And if anything, yeah it's even it's even you know sweetening the deal by saying like, hey, the in end output is it's going to look better or it's going to be faster or you're going to write it more quickly or it's more understandable cor or whatever it is. like As long as you sweeten the deal with something um that positively impacts their lives in some way, I think people tend to be much more open to and much less defensive about moving away.
00:28:09
Speaker
Makes sense. I think one of the things that is frequently going through people's minds is you you don't know what you don't know. And it's not clear even if the it seems to drop incorrectly and, you know, the type checker passes that it'll work.
00:28:23
Speaker
How did you think about testing all the way out to like bringing it to production and and seeing that that component does work in all the ways that you expect it to work when it's in front of real users.
00:28:37
Speaker
Yeah, I think, you know, there's there's several layers to this, but generally speaking, one of the benefits of moving into this new world was that testing it was also easier than, you know, the old stack.
00:28:53
Speaker
um And when I say testing in this case, at least for for now, I mean automated testing, right? So you just write a bunch of like integration tests. um We first actually got this, you know, this is five years ago. So initially, you know, Jest and Enzyme was still...
00:29:08
Speaker
somewhat ah the standard way of testing React components. So that's how we started. Then we slowly transitioned over to Cypress testing and integration testing. We... layered it on top with end-to-end testing, although that one's a bit trickier because it tends to be a lot more flake that it encounters and sometimes it doesn't, you know, give you the signal that you want. And in worst case, because of all the noise you're getting, you tend to tune it out, which, you know, kind of feeds the whole purpose of having tests in the first place.
00:29:37
Speaker
um And kind of increasing the importance of testing in the organization, because I think at that stage,
00:29:49
Speaker
There was a lot of tests for the backend, but there weren't as many tests for the frontend. um And so pushing in that direction and kind of having that sort of shift of the thought process around like testing is important, even for the ui you know, if a user logs in and is unable to, you know, i don't know, schedule a campaign to send when they want to, that's not going to look very good for us. um you know I think there's always different levels of emergencies happening. you know
00:30:23
Speaker
I can't go onto this page. Could be ah problem, but it typically doesn't rise to the problem level of like, hey, we had we were scheduled to send, i don't know, a million messages and none of them are sending. That's that's like, you know, all hands on deck situation. So um I think it was also reframing the mindset of like the UI maybe...
00:30:48
Speaker
doesn't cause incident that everybody freaks out about. But at same time, it does influence how customers view our product, whether they find it to be reliable in general, whether they feel they can do the things that they are paying us to be able to do ah in an in a relatively easy way.
00:31:09
Speaker
um And so, yeah, I think a lot of that shift has happened towards the automated testing world. And I think we're we're much better tested as a result, both because of sort of like a, like I said, a mental shift, as well as the technology making it easier to test period.
00:31:26
Speaker
ah Do you feel like the testing was part of the migration? Because there's a different ecosystem around... i would say....than there was around Knockout.
00:31:40
Speaker
Yeah, 100%. I would say so. It's interesting because wild you know when you think of a migration, you think of going from a to B. And in the case of testing the front end on our application, we were going from zero to one, really, because there wasn't much testing to begin with.
00:31:55
Speaker
But at the same time, even though there is that slight distinction, I would say, yes, I 100% see it as part of the migration because I think a lot of the time, The hardest parts of a migration is usually not the technical piece. The technical piece is challenging, sure, not downplaying it.
00:32:16
Speaker
But I would say most of the time it's the social, it's the political, it's the convincing other people that this is the right thing to do. That is the piece. And convincing other people to change their ways. Going from not thinking about writing tests, usually for your front end,
00:32:31
Speaker
to starting to write these tests is a pretty big shift in how in your day to day, even as an engineer. um And i I don't think I'd be particularly controversial in saying that like writing tests is typically not the most exciting part part of any engineer's day.
00:32:49
Speaker
So that one especially is kind of hard because it's like, okay, there's this thing, you know, intellectually that you need to do because it makes
Importance of Testing in New Environment
00:32:57
Speaker
your product safer, hopefully, if you're writing good tests.
00:33:00
Speaker
ah And so you're bought in on an intellectual level. You're like, yeah, this is the right thing to do. But then on an emotional level, you're like, but it's boring. I don't want to do it. It's like not my favorite thing to do, whatever.
00:33:11
Speaker
And now I'm going to spend more hours of my day doing this thing. ah And so at that stage, we again go back to this question of like sweetening the deal. How do we make this work?
00:33:24
Speaker
better for you in some way. um So in our case, we were thinking about how do we make testing as easy to get started with and to maintain long term as possible so that, you know, on ah on a day to week to week basis, writing new tests, adding new tests, maintaining them, changing them, whatever feels like not a horrible slog, but that we've helped to sort of cut out some of the more annoying or frustrating or time consuming parts.
00:33:53
Speaker
And so we've built ah small pieces of tooling around that. And, you know, going back to your question, I very much see that as part of the migration. Um, building tooling to encourage new behaviors is part of any migration, I would say.
00:34:10
Speaker
um um Again, unless it's so simple, so straightforward that you don't need it. ah This is not one of those instances, though. Yeah, ideally, the migration is so straightforward that everyone, you can do a pure like API compatible or you know like you you found the cut points in the back end.
00:34:24
Speaker
We don't have to migrate the back end. but But we live in the real world. That's not always possible. Yeah, but we're all about it. Oh, sorry. Tell me a little bit more about tooling. I want to i want to understand but what worked. So what were some of the tools that you built that that worked really well?
00:34:40
Speaker
ah Some of the tools that we built that work really well. um One tool that I built was to, and this I think turn would have been really helpful if it existed back then, was to take, ah you know, plug, um was to take certain, these are called eco files. I forget what, I think they're like embedded coffee script, something or embedded coffee script. I think that's what they're called.
00:35:07
Speaker
They're essentially like template files, but, uh, for coffee scripts specifically. Um, And they were this weird type of file that we just wanted to get out of um because it basically meant that we had to continue to be able to support, you know, ah being able to template them, convert them into a real HTML file and all that stuff.
00:35:26
Speaker
And so we were like, okay, how do we write some sort of tooling that makes it easier for people to transition off of this? And then we, at the time, picked EJS as a suitable alternative. It's more modern, it's well-maintained.
00:35:39
Speaker
um doesn't have sort of these weird dependencies. So we were like, okay, ah this this helps us move away from copy scripts. So how do we think about writing scripts ah to look at these eco files and then turn them into EJS files?
00:35:56
Speaker
And we basically made that available and it was great. We we were pretty much done with all of the eco files after that in like a couple months, um which in the grand scheme of this entire nearly five-year migration is nothing.
00:36:08
Speaker
um That was an instance where it was relatively easy to do to the migration because the mapping is more or less one-to-one. um you know You're just representing, i don't know, template variables in one way and then you're representing them here in a different way.
00:36:22
Speaker
um There were other pieces of tooling, like going back to the testing example, where basically we built these sort of contexts that could make it easier, a little more declarative for you to select certain DOM elements. So you would essentially have them be like these objects that contain functions that are getters or finders or whatever, including actions.
00:36:46
Speaker
And so in the tests files, you just do like, don't know, context dot button dot click. as opposed to doing sci.get and then trying to figure out which class name or selector you're using and then click and things like that.
00:36:59
Speaker
So again, and then like I said, you can create click is an easy example, but there are certain actions where maybe you have to go through multiple steps. You have to open a modal, find the right button, click, select the right, I don't know, dropdown, whatever.
00:37:12
Speaker
um But it's a repeatable action. You're trying to test that like going through this chain of things ah has to happen more or less the same way every time. So for those, we also created like these sort of action encapsulations.
00:37:25
Speaker
which again, you could, you know normally you'd have to repeat over and over again. In this case, you would just do context dot, you know, button or context dot translation dot select English.
00:37:36
Speaker
And then it would just run through these various steps. And so again, you don't, you as a developer who's in this feature they on a daily basis, don't have to necessarily think about like, oh, I have to first, you know, get this, ah get this element, then click on this and do this, whatever. You just do it in one shot.
00:37:54
Speaker
um So those that's those. ah And then this one was harder, right? Because it's not a one to one transition. You're not taking one type of file that more or less describes the same thing underlying and turning into another file like you could to each as.
00:38:08
Speaker
In this case, you're saying, hey here is um you know Here's how you used to go through these things. Now you can encapsulate those in smaller pieces of logic and then do them much more ah efficiently.
00:38:23
Speaker
um So those are two examples. And a third example, I'll give you a third, bonus example. This one was hard, um remains hard. transitioning from CoffeeScript to JavaScript generally was fairly straightforward um because they're both fairly untyped languages. They're both untyped languages and CoffeeScript is essentially meant to be sugar. don't know if you would, I wouldn't call it that because I actually don't like CoffeeScript's syntax, but it's meant to be sugar on top of JavaScript. So it's like relatively straightforward.
00:38:59
Speaker
Doesn't the CoffeeScript compiler like spit out JavaScript? Essentially, yes. Yeah. um But going from JavaScript to TypeScript, which was the next step, was actually really challenging. um Because now you're suddenly having to infer all these types that ah is really hard to automate the migration for.
00:39:16
Speaker
Even if you could, your language was untyped for so long that like there are probably bugs in your code base that now the TypeScript is going to reveal...
00:39:28
Speaker
And now it won't compile because they were always there. I guess you never hit them, um but now you have to fix them. So there's this sort of weird cascade that might happen. And so automation we found was really, really challenging when it went from JavaScript TypeScript files.
00:39:44
Speaker
and And in a lot of those cases, unless those files were like very, very straightforward and simple, we ended up having to do many of them manually. Interesting. yeah did Did your team end up doing that? Or was that work that there was like was there enough domain knowledge necessary that you had to farm it out to other teams and get their input as well?
00:40:02
Speaker
Yes, both. So in some instances, we did it for them. In other instances, they did it themselves. And in sort of like a totally alternative scenario, rather than direct conversions, because also remember that we're also trying to migrate not only languages directly,
00:40:19
Speaker
from JavaScript to TypeScript, we're also trying to move from Knockout to React. In many cases, we ended up re-architecting those files altogether and then replacing them with a totally new approach of doing stuff.
00:40:30
Speaker
um So it was always a prioritization question of just like, ultimately, this file that if it if it has Knockout, it's probably going to go away at some point.
00:40:43
Speaker
But in the meantime, do we care about moving it to TypeScript? do we care about moving into, like, it's always a sort of a judgment call on, like, whether it's worth it to spend your time doing that sort of intermediary step or to just sort of you know wait until the the moment arrives when you can just kill the file altogether and replace it with something else.
00:41:05
Speaker
And that happened over and over again. And I know that that happened in our team as well as the teams that were doing their own migrations. Because we, you know, and I guess I haven't said this explicitly, but like the team was mainly my team, the fixed team was mainly there to provide tooling for the migrations. It wasn't there to do all of the migrations as one team.
00:41:26
Speaker
Ultimately, we sort of The plan was, here is the tooling, FIX maintains it and creates it and makes it easier for you to do your own migrations. And each team sort of, and on ah in a somewhat federated fashion, does it because they have the domain knowledge.
00:41:40
Speaker
You know, they also just, there's just more people to go around ah when you include the entire org, as opposed to just like, you know, give a group of five, six people, hey, take a million lines of code and move it into all into this new thing.
00:41:55
Speaker
There's no way that's ever going to happen, right? um So, yeah. ah Yeah, absolutely. that's and That makes a lot of sense as like a tool builder team as the as the kind of engine for the migration that you you can listen, you can you can work with teams and figure out what is going to be the biggest impact.
00:42:13
Speaker
um And in many ways, we did some migrations too. Like, that's not to say that we never did them ourselves. We did, especially when a certain team, like sometimes you would have teams that had a front end footprint, but then you know, 99% of the time they'd be up working on the back end and they wouldn't feel comfortable doing this new thing. So we maybe we would help those teams.
00:42:33
Speaker
um Or, you know, the team would have... would have the ah requisite knowledge and experience, but they just wouldn't have the time. They have to deliver a feature by a certain deadline or whatever.
00:42:44
Speaker
And so they're like, hey, can you help us pick this piece up and do it for us? And all those instances, we were very, very clear about being like, we but we if we can do it, sure, we'll do it, but you continue to own this.
00:42:56
Speaker
So should probably be involved in the review process. You shouldn't just like abandon it and be like, okay, they're doing it. We can forget. Because once this is done, you're going to maintain it
Support and Ownership During Migration
00:43:06
Speaker
afterwards. We're we're just here for like a little short while.
00:43:10
Speaker
um So that's that's kind of how we managed a lot of those relationships there. I'm sure everyone was enthusiastic about the idea of just handing off ownership of the entire front end to your team. Oh, I'm sure. Yeah, always. Yeah, it's like, especially like features people don't ah don't really care about that get touched very rarely.
00:43:29
Speaker
It's always a struggle to kind of say, no, no, just because you don't want it doesn't mean it's it's going to be dumped on us now. Like, it's still your feature. Absolutely.
00:43:40
Speaker
i If you could... um I got to imagine you've learned a ton about how to write migration tools over the last four or five years. um If you could, you build the perfect migration tool, but what would it look like?
00:43:55
Speaker
It would feel like staring into the face of God. um
00:44:04
Speaker
ah and That is a very, very hard question to answer. Yeah.
00:44:15
Speaker
Yeah, see, I'm stumped. um it It honestly, the the best way I can think of going about a migration and a migration tool, a perfect one, would probably be one that can help break a gigantic migration, such as this one, down into smaller logical pieces of work.
00:44:36
Speaker
um Help me think about what those things are um and then potentially do them sort of piecemeal. um There's... No way any migration tool that does everything in one shot or a couple shots is ever going to be sufficiently trustworthy, I would say, because you're you know the the scale of it is it' just going to freak you out. And also, you're just not going to be able to understand all the things that it's doing.
00:45:00
Speaker
you know I don't think anybody wants to sit there and read through thousands and thousands of lines of code that some you know AI or or whatever generated for you in one shot. um So I think the biggest...
00:45:12
Speaker
help that migration tool could give me is help me think about how to get from a to B, how to break it down into small pieces that are that feel individually actionable, that can be rolled out without a huge risk, and then help me to sort of either plan it help me to execute it um whatever. But that's kind of where I'm sort of landing.
00:45:40
Speaker
Just because of the nature of how how varied migrations can be and how different they look. you know ah in In the three examples I gave you, they were all in migrations but where one is like basically a one-to-one and ah the third one is like, oh, this is a migration, but really you you have one thing and you're creating a new thing to replace it and there isn't necessarily a direct code link. you know there's ah There's a sort of link from the perspective of the user, I guess. like you know they need They still need to be able to do the same things.
00:46:12
Speaker
um They still need to be able to um we still need to be able to support the functionality that they had previously. But the architecture might be completely different. The design might be completely different.
00:46:25
Speaker
The code logic might be completely different. So yeah, you're replacing something with something else. But it's so hard when you look at the code side by side to see how it ever could have felt like a migration even because they're just it's like, oh, this was one thing and now this is another.
00:46:40
Speaker
Right. it's at At that level, um migrations are just engineering. I needed i have this, want this, and how do I do it? So it's it's a hard question to answer. Yeah, exactly. I think your your point about you know, the fact that it is a hard question implies the answer, which is like I want it to help me understand what, what is worth doing amongst this big pile of problems I have. And then I want to make sure that those problems are properly being solved and you can, you can see what's happening as you go through each of those sub migrations, you can understand and, and work incrementally yeah against the the larger problem and ship incrementally. Right.
00:47:19
Speaker
But you don't, uh, i i I love the idea of waving a magic wand and having everything work, but ah anything that isn't like 100% that is totally useless.
00:47:32
Speaker
Right. And most hard problems are not 100% Right. Exactly. And I think, you know, this goes back to something I had also said earlier is that like, part of this breaking down process isn't technical. Part of it is to help you communicate what it is you're doing and what the migration is even going to look like.
00:47:52
Speaker
If you could wipe one technology off the face of the internet, never existed. What would you pick? Facebook. Right on. um And last one, where can folks find you on the internet if they want to ask questions?
00:48:07
Speaker
Folks can find me on LinkedIn, probably, is is the is the best one. ah i don't really I don't really do Twitter. i don't i don't really do so threads or Blue Sky or anything. Maybe I should.
00:48:21
Speaker
um But yeah, LinkedIn is probably the safest bet. All right, LinkedIn. Great. Well, thanks so much, Hal. I'm glad we could have this conversation. This was fantastic.
00:48:32
Speaker
Yeah, this fun.