Artsy Engineering Radio
Artsy Engineering Radio
31: Making big changes with Laura
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
This week, Artsy Engineer Laura Bhayani tells Steve Hicks how she approaches making large changes in a codebase, and why she enjoys that kind of work.
Hey, friends, welcome to another episode of Artsy Engineering Radio. I'm your host, Steve Hicks today. I'm here with my friend Laura. Laura, do you want to say hi to people?
Laura Bhayani:Hi, everybody.
Steve Hicks:Laura, what do you do at Artsy?
Laura Bhayani:My official job title is engineer 2. So I'm a full stack software developer.
Steve Hicks:Is there one side of the stack that you prefer over the others? Just out of curiosity?
Laura Bhayani:I like front end better? Because...
Steve Hicks:Because it's better.
Laura Bhayani:I mean, I'm not gonna say that. I'm not gonna say that, because I think that, you know, the front end doesn't work without the back. But the front end does have a much faster feedback loop. And so that makes it easier and sometimes more fun to work in.
Steve Hicks:Yeah, definitely. I'm similar. And it's a lot of the reasons that you just described. Okay, Laura, I invited you on this podcast, and I'm really excited to talk to you. You and I worked on a team together. The team that I'm on, it's called partner experience. It's a team that, we call them Artsy partners, for the most part, it's the art galleries. The partner experience team is a team that deals with this project that we call CMS, which is a way for the partners to manage all of the artworks that they're putting up on Artsy. You did a rotation on our team for about two weeks, you're not on our team anymore, which makes me really sad, but in that two weeks that you were with us...I told you this in person...but I think it was the most impactful two week rotation that I've seen, since I've been at Artsy. It was amazing how much change you were able to drive in that very, very short time.
Laura Bhayani:That is a huge compliment. So thank you, Steve, appreciate it,
Steve Hicks:Thank you. But like when it comes down to it, and I think about what it was that you were able to do that really helped us, I think it just really was clear that you're very, very well, (a), you're very excited by, and (b) you're very, very good at making large changes to a code base. So the artwork form is the thing that we deal with inside of the CMS project, which is massive, it's just a huge form that these partners have to navigate on a regular basis. And as a very huge form, it's really, really hard for them to use as a user, and then for us engineers to use as someone who's trying to maintain the code. So I guess that's really what I want to talk about is how are you so good at it? And why are you excited about this kind of work? I'll start with just that vague question.
Laura Bhayani:Oh, wow, that's vague. Um, I'm good at it, because I do it often, or as much as I'm able to as much as I have time to. And also maybe in part because I have a very different cognition than a lot of the developers that I have worked with in the past. Because most developers have a really great attention to detail and look at things on a very granular level. And I'm the exact opposite, where I have zero attention to detail, which has gotten me in a lot of trouble. But I see everything from the top down, and I see like things high level first, and try to figure out how the whole system works together before I start looking at, you know, line by line, the little pieces of everything. And part of the way I think about that also is is like pattern recognition. You know, I started working in a code base that was completely green-field. That's how I started my career. And it was built by one of the most brilliant developers or the effort was led by one of the most brilliant developers that I've ever worked with in my life. We had no technical debt at all, which I mean, it's impossible to say that, at any job, I feel like, you know, anyone or all developers I've talked to, there's always some legacy, something sitting somewhere. It was just a beautiful, beautiful code base. And so a lot of the patterns that I saw built from scratch there, and came to understand in that code base that maybe I didn't appreciate as much as I should have at the time. Now, when I see things done differently, I am always like, wait, but why didn't you, you know, why didn't you do it like this? Which sometimes is good and sometimes can get me in a little bit of trouble.
Steve Hicks:Right, it kind of sets you on that route that you've been before and maybe like there's a little bit of single track that you're thinking in terms of getting to that route? Is that accurate?
Laura Bhayani:Yeah, it is. And I've had to learn as I've taken other positions that sometimes you just have to make something work before you can make it perfect before you can make it beautiful. So sometimes you just have to work with things as they are, which can be an educational experience. And then sometimes you are given the leeway to undertake these large refactors. And then that's where you get to have a lot of fun. And suffering, a little bit too.
Steve Hicks:That's fun, I definitely want to talk about that duality of fun and suffering. But before we get there, you mentioned patterns as like, you look at this code, and you recognize these patterns that you've seen before. Or maybe you haven't, or you don't see the patterns that you expect to see. I was wondering if when you do or don't see the pattern, are you conscious of that? Are you thinking, Oh, this looks like this particular thing that I've seen before? Or are you just looking at something thinking, this looks kind of right and how I would expect it, or this looks wrong and not how I would expect it?
Laura Bhayani:I think it's more when things look wrong, that they jump out at me. Because I try to reserve judgment, right? If you if you immediately walk up, open a file and you're like, oh, everything sucks, then you're just never going to get any work done. So it's more just like, looking for things that are different. But then also looking for things that I know that can be detrimental to performance, and also detrimental to developer experience. Because that's always my top concern, which is probably not what my bosses want to hear. I should be more concerned about like the user experience, but I'm always very concerned about developer experience as well.
Steve Hicks:Yeah, as a developer that works with you, I very much appreciate that that is your top concern. For what it's worth. You mentioned this idea of you look at things from the very high level, and don't necessarily see the details. I'm completely the opposite. I see the details long before I see the overall picture. And I think a lot of people will hire, like And having people who are going to look at the problem from different perspectives come together, because I think it's really a huge benefit for you and I to be on the same team. they'll look for a front end developer to go with their back end developer, or whatever, but I think that one of the things I've always thought about it like carpentry. There are people that Artsy does a good job of and one of the things that I think is really important, when it comes to hiring, is making who are really good rough arpenters, and you don't hire sure you're covering all those different bases. he rough carpenter to do the inish carpentry. On the other ha d, there are people who are re lly good at the polish, the fi e tune, making the very small iece look very, very nice. nd you don't hire the rough arpenter to do that work. And I hink that's why it fits so well That's why it was so much un to have you on the team, hon stly.
Laura Bhayani:Yeah. You know, I mean, I felt very much the same way. And I think that that idea is also something that I've seen, when talking about making sure that you have enough diversity in your engineering team, or your organization as a whole, right? When people come from different perspectives, they see things in different ways. And then they allow you a much broader view of whatever it is that you're building, whether that's in design, or in your engineering patterns, or any of that stuff. So, yeah, diversity, making sure that it's also diversity of thought.
Steve Hicks:I can't remember the words you used back a little bit. You talked about that duality of this being very fun, and maybe it was painful. I can't remember exactly. But I want to touch on that a little bit. I definitely recognize the pain, but I kind of want you to talk a little bit more about it. Like what makes that difficult?
Laura Bhayani:Sometimes it's that you've surfaced a bug that maybe existed before that you just didn't realize because it was being disguised by some other pattern or something like that. Now you have to dig up and figure out where it's coming from. Sometimes it's just that some of the changes that you have to make are really tedious. It's not something that you can just say, okay, Find and Replace All. You have to go through a huge code base and make sure that you hit every spot where you're renaming something, or re typing something or switching one function out for another because if you miss one, then you've broken everything. And then you wrote the bug into the code. Just that sometimes these undertakings that you think might be small, you realize that they end up spidering out into the codebase in places that you had no idea that it touched and then you're like, Oh, well, yeah, maybe I'm gonna just stash these changes. And then I'll come back to this next Friday or something like that. Just that it can be larger than you expect. And then I guess also, I'm thinking as well of some of the refactorings that I've done, where it's turning something that's JavaScript into something that's TypeScript where you really have to dig through the code and through the data that's coming through and all this stuff in order to properly type things and make sure that you've looked at all the contingencies. So that you're not messing something up for the developer that comes behind you, because a mis-typing can be tragic.
Steve Hicks:Right. There's a very specific example to what you're describing. And that's something that you and I and Anna have talked about today, even, and something that you were involved with when you were doing the rotation on our team. And I'm not sure, do you think we should get into details of that? Do you want to get into the details of how that TypeScript renovation of the artwork form went?
Laura Bhayani:Yeah, we definitely can, we definitely can.
Steve Hicks:High level, what we're talking about is we had this gigantic artwork form, it's got lots of components to it. And it's legacy, it was written before modern react, so no function components, no concept of react context, at least not a publicly exposed one. And now we were going into this thing, and we want to make it more modern and apply TypeScript to it. As a person from the outside watching us do this, how did you feel about how we were approaching it? And then was there a place for us to pivot? And I think that we did, but I'm curious what you think about it. So it wasn't actually wasn't on what you and Anna were
Laura Bhayani:I think where I came in was a point where converting at the time, I think it's like when we started to dig everything had been converted to function components. And it was in to try and find what the types were of some of the things at the point where things needed to be typed. And the first thing I noticed was that we were trying to type things, but there that you were trying to strictly type, we realized that an was `any` in the code base. And there were TSLin exceptions th t were being made for certain th ngs like, Hey, don't type th s as any don't do this like thi. And even though those thi gs can seem necessary, when doin conversions, or maybe when y u're just working on something n a smaller scale, or something ranular... your like, Oh, w ll, I'm just making this one cha ge, and I don't really know wh t's coming through here and all these other files around it ar JavaScript, so I'm just gonna g ahead and type it as `any` beca se I don't, you know... But then that starts, right? And t en that `any` is like a mole in your codebase. And it just s arts going everywhere. And yo don't realize that that that one exception has really just s arted to basically defeat t e purpose of TypeScript. interface that was basically orchestrating the the form from the top down, had `any` and exceptions and things in it. So that was a kind of a red flag for me to say, hey, maybe the thing that you said about doing this incrementally might be the right way to go. Because right now, we don't have all the information. And until we can take the time to dig up what that information is, we maybe, this may just be a futile effort. So saying that just the conversion from the the class components to the function components at that point was good enough, and then maybe we should hit pause, and actually work up a tech plan or something that was more... So we could coordinate with each other instead of trying to shoehorn it in when it wasn't the righ time.
Steve Hicks:Right. I feel like you've just, at the end there, basically covered the issue I run into on every project that I work on. Which is, again, coming back to that not seeing the forest from the trees, having that vision of what's the whole thing versus what's the thing I'm trying to do right now. And I think that was a really useful thing to have you there to question us about and push back on. So that's a little bit of the painful side of this. But you also talked about it being fun. So I was thinking maybe you could talk a little bit more about what about it feels fun? And what's the joy that you get from this kind of work?
Laura Bhayani:Well, like I said, developer experience is just my top priority, right? So when you see these enormous files and these huge interfaces, and spread props getting thrown all over the place. It just makes things confusing. When I look at that, I don't see something that's clear and understandable. It's not easy for me to go in there and feel secure about making changes because I don't know what I'm changing. I can't see it. It's all obscured. So when you can break things down and make them more modular and make them more human readable, that's awesome. It's very gratifying to me because I feel like I'm helping my co workers at that point. So you know, helping other people is something that is important to me. Also. I don't know, I think when you really engineer things the right way, and you see the performance improvements, you see file sizes shrinking, you see composability improve, all of that. That's what's gratifying to me. It's also fun to just a little bit reinvent the wheel. I don't know, that's actually the wrong term, because I don't want to say like, oh, if something is working, and it's already engineered the right way, and it's doing its job exactly as we expect it to that we should just reinvent it for no reason. But more like, just getting to engineer a system at all, and seeing marked improvements in performance or whatever, that's fun. The engineering part of it is fun to me, which is why I like my job.
Steve Hicks:Right, building things and seeing them go from not existing to existing, and lots of people using it.
Laura Bhayani:Exactly, exactly. But we were talking about the form though, right, like the form itself, and what was the initial plan, when you and Anna decided to start doing this? Like, was it from class components to function components, and then from that to TypeScript? What was the impetus there?
Steve Hicks:I mean, the impetus, I think, is a lot of what you described in what you experienced, which is this thing is just really, really painful to deal with. And we have to figure out a way to make it easier for us to make changes to. The very first thing that we decided was, we know that we have some older stuff involved in the codebase, that is rails back ends and the views are all handled on the server side, and we've started moving towards this world where we're building things in react, and we're using relay to consume data from metaphysics, which is our main API gateway. And so the first start that we thought we would have with improving things was let's get an idea of what we want code to look like in the end. And we started moving some things around, I think there's an open PR that never got merged, that did that. And my take on this, and I can't speak for Anna. But my perspective on this is, it takes me a long time to figure out, to see the whole big picture of the code. And it takes me a long time to actually live in it, to know what the pain points are. And to get a sense of like, what are the things that we do a lot? What are the things that we do a lot and get wrong? And what are some things that we could do that would make it easier for us? And I think I wasn't personally at that point yet. I think I've gotten to that point recently, where I have more tangible ideas of what are some specific small iterations we can make to improve this thing. But the start was, TypeScript and functional components, those are no brainers. Let's get this thing up to basically modern times with react. And so I think that's where we had started, and Anna did a bunch of a bunch of solid work with converting that kind of stuff. And then we have another engineer, Sergei doing a bunch of TypeScript conversion, one little component at a time. Yeah, I think that's where it started. Does that make sense?
Laura Bhayani:Yeah, yeah, it definitely does. It sounds like a lot of the things that I see when I want to refactor code or a lot of the things that you just mentioned. So that actually, that does make perfect sense. And then you brought up TypeScript again, which, I think that TypeScript is one of the things that makes me good at refactoring. I've always lived in a TypeScript ecosystem, so I could go in and make changes that were broad, sweeping and large, like you were talking about and know exactly what those changes were doing to the rest of the code base, because of the fact that everything was so strongly typed. That code base that I was telling you about that had no tech debt in it whatsoever, we had every single one of the TypeScript rules turned on and we were conforming to every single one of them. We had no exceptions anywhere in the code base, which made it just, I could do anything. I could just rip entire components out and know exactly what the blowback was on that. And so having that as a safety net is just wonderful. So yeah, I can definitely see why you would have really been pushing for that conversion.
Steve Hicks:Yeah. So TypeScript helps you. Are there other tools, other strategies, other ways that you think about the problem or break it down, that helps you do this kind of work?
Laura Bhayani:I mean, I guess...I'm just sitting here shaking my head like I have no idea what you're talking about. I think that just a lot of the react recommended patterns are always super helpful. I think I always have them in the back of my mind whether or not I really harken back to Oh, I remember I read this on react js.org it's more like, when I see things...When I think see things being extended, and when I see the guts of a component being completely separated from the UI, or classes that exist that have no visual component that are being like extended for patterns that just don't fit in react, those things really jumped out at me. And even though I've seen them work in other ecosystems, I just know that react has this really amazing way of reasoning about their code that's very, very different than other frameworks. So trying to keep everything as modular as possible - when I see huge files that are 1000s and 1000s of lines long, I mean, I'm like, there's gotta be something that needs to change here. This is not, you know, it doesn't make any sense. There's got to be some repetition, there's got to be some logic that can be separated out and turned into its own component. So I guess really, that's a big thing is always looking to see how files that are huge, or components that are huge, can be broken down to be simpler and more readable. And how to separate them out into their own kind of containers, because it makes them easier to compose and easier to think about.
Steve Hicks:Yeah, composition is the thing that has been like the rock in my shoe right now. I'm looking around, and I just keep seeing these things where this is just trying to use the same component to do five different things, instead of having some things that we can compose, and have five different things that just compose all the different parts that they need. But that's been the thing that has been on my mind for the last week, honestly, where I'm just like, I want to go in and I want to take each one of these components, and there's a lot of them that are trying to handle multiple different states, and I want to break it up and spin it the other way, and have the states be separate. But have all the things that are common actually be something that we can compose together.
Laura Bhayani:Yeah, that makes sense. I was actually thinking about it while you were talking and saying "rock in your shoe." It's a great analogy. And it's also, there's a reason for that, right? If something really is kind of circling, it's kind of spinning the drain, and there's a reason for it. And it's probably because of these patterns that you're beginning to recognize that you're saying, Okay, I'm seeing this here, here, here, here, there's got to be some way that we can make this better. And I think that that's one of the things that kind of nags at me. I'm like, looking at a piece of code that I'm like, okay, we could really tear this apart and do it a different way.
Steve Hicks:Yeah. When it does come time, when you do see those patterns, and maybe there's a lot of work to do, how do you think about prioritizing things? Because obviously, sometimes you can have a big enough problem where if you just start doing it all, you'll end up way too deep in this thing. So how do you break that down?
Laura Bhayani:Man that that has changed so much over time. That has changed. Yeah, my first job, like I said, I didn't have to do any refactoring at all. And then my second job, we were so so feature forward or feature first that it was like, we're gonna just dump the entire change set in perfect working exactly how you needed it to be, then you just don't even bother doing it at all, because there's no time for there to be any hiccups if something like that happens. And then also, you're doing it in your spare time, and on the weekends and in the evenings, because we did not have time, we didn't have time to do anything that wasn't just building new features at that job. And now that I'm here, at Artsy, where it's like a weird fairy tale that I'm living in, I did not think that any engineering or tech company would really support its engineers having these kinds of side projects and these endeavors to make the codebase better, or to make developer experience better. But I think that I'm probably going to have to revamp the way that I think about these refactorings now because it seems like there is time for planning. There's time for looping other developers in there's time for, yeah, there's actually time to do it and on the clock when my brain is actually working. I really liked the way that you and Anna and I were working together during that rotation because we were working on actual sprint work, but then we would start to see some things, or I was starting to get familiar with the code because I've never looked at this particular codebase before. But starting to see the patterns starting to hear the things that the both of you were talking about that sounded like they were problems and the pieces kind of started to fall together. But then we also had these really great conversations about how things worked. I could ask questions, and we could kind of paint in these really broad strokes about what would be fun. And then I turn around and here Anna is like, Oh, I'm making a tech plan. We're gonna do it. So yeah, I guess tech plans are a thing now.
Steve Hicks:Yeah. I also remember a conversation that we were having where we were looking at this code base, and I said something like, Oh, that sounds like good work for a future Friday - future Friday is this thing that we do on Fridays, where we try to spend some time working on changes that aren't necessarily directly related to a product feature, paying back some of that technical debt. We were talking about one of these things, and your response to that was, I'm gonna start that tomorrow. And I had that very much similar reaction, as you just described with Anna, where it was like, Yeah, let's do it. This is great.
Laura Bhayani:Oh, yeah. Yeah. I think part of the reason that my response was as it was, it was because I was on rotation, right? So I didn't feel like I was really under the gun to get X number of tickets produced by the time I was done with my rotation, because that wasn't the thing. As far as the way onboarding at Artsy was explained to me. So I felt like I had the time. And then also, I don't think I remember it being a really big endeavor. I think I had just kind of reasoned about it in such a way that I was like, Okay, if I do this, this and this, then I'll be able to knock it out pretty quickly. So yeah, that was part of it.
Steve Hicks:That's great. Before we wrap this up, I just want to ask, if you have any stories you want to tell about this kind of work, anything that went really well, anything that didn't go well, or anything else that you want to share in regards to this topic?
Laura Bhayani:I don't know, I think that a couple of the really big refactorings that I did, were basically just making sure that we were leveraging some of the more modern react tools in the code base at one of my other jobs. And yeah, I think that refactors can be a lot more fun when you have something that you're you're looking to play with a little bit. So once I've done some research and really read up on something that react has come out with, like, I think at the time, it was like a context and this neat pattern that I'd found, I think, maybe by Kent C Dodds or something about how to really implement a good context to make sure it's memoized the right way, so you're not ruining performance in your app or whatever. I was able to build up a context for something that was just being spread props all the way down through a code base and it ended up really improving the developer experience for a couple of my co workers. And so that was a fun project that I worked on. Yeah. And then there was another one that a friend of mine did, and it was basically just a reskin for the application we were working on. And it turned out it was a lot of just CSS changes and things like that. But then it spiderwebbed out turned out to be a 400 file PR that was completely illegible, n t because his code wasn't good, but just because no one can fit that much in their brai at the same time. Yeah, when t ey get that big, it's too big Way too big. But yeah, no really specific nightmare stories or, or anything like that. But it's fun.
Steve Hicks:Laura, thank you for hanging out.
Laura Bhayani:Thanks for having me, Steve.
Steve Hicks:This was fun. Yeah. Thanks for listening, everybody. Thanks for listening. You can follow us on Twitter@artsyopensource. Keep up with our blog artsy.github.io. This episode was produced by Aja Simpson. Thank you Eve Essex for our theme music. You can find her on all major streaming platforms. Until next time, this is Artsy Engineering Radio.